From report at bugs.python.org Fri Jan 1 00:04:18 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 01 Jan 2016 05:04:18 +0000 Subject: [issue19006] UnitTest docs should have a single list of assertions In-Reply-To: <1378914335.13.0.0543263347661.issue19006@psf.upfronthosting.co.za> Message-ID: <1451624658.59.0.115207561526.issue19006@psf.upfronthosting.co.za> Ezio Melotti added the comment: Here's a patch. ---------- assignee: docs at python -> ezio.melotti keywords: +patch stage: -> commit review versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4 Added file: http://bugs.python.org/file41462/issue19006.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 00:11:22 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 01 Jan 2016 05:11:22 +0000 Subject: [issue25256] Add sys.debug_build public variable to check if Python was compiled in debug mode In-Reply-To: <1443446100.69.0.307482207939.issue25256@psf.upfronthosting.co.za> Message-ID: <1451625082.07.0.889774325626.issue25256@psf.upfronthosting.co.za> Ezio Melotti added the comment: If there is consensus about adding this to sys, then the latest patch LGTM (module a couple of unaddressed comments on Rietveld). If not, you should probably bring this up to python-dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 00:12:35 2016 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 01 Jan 2016 05:12:35 +0000 Subject: [issue25637] Move non-collections-related ABCs out of collections.abc In-Reply-To: <1447701682.74.0.653642972551.issue25637@psf.upfronthosting.co.za> Message-ID: <1451625155.88.0.0510243552968.issue25637@psf.upfronthosting.co.za> Nick Coghlan added the comment: >From a documentation perspective, I'd suggest breaking the ABC module documentation at https://docs.python.org/3/library/abc.html into three subsections: 29.7.1 Defining Abstract Base Classes This would include the existing docs for ABC, ABCMeta, abstractmethod and get_cache_token. 29.7.2 Syntactic ABCs New section containing the documentation for the ABCs relocated from collections.abc 29.7.3 Deprecated decorator API The docs for abstractclassmethod, abstractstaticmethod and abstractproperty can be moved out of the main ABC definition docs, since the only reason to use them now is for single source Python 2/3 compatibility, or compatibility with Python 3.2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 00:29:28 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 01 Jan 2016 05:29:28 +0000 Subject: [issue13253] 2to3 fix_renames renames sys.maxint only in imports In-Reply-To: <1319437552.82.0.780264952493.issue13253@psf.upfronthosting.co.za> Message-ID: <1451626168.09.0.0169706343249.issue13253@psf.upfronthosting.co.za> Ezio Melotti added the comment: Nikita, did you manage to find a solution? If not, do you have a patch (even if not complete) to share? ---------- versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 00:32:56 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 01 Jan 2016 05:32:56 +0000 Subject: [issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError In-Reply-To: <1450150718.99.0.697293755498.issue25864@psf.upfronthosting.co.za> Message-ID: <1451626376.23.0.20897611726.issue25864@psf.upfronthosting.co.za> Martin Panter added the comment: If this patch goes ahead, I think the ABC documentation should clarify which methods are checked for None and which aren?t. The datamodel.rst file will suggest None for any method, but ABC will only support it for Iterable and Hashable (I think). Also, what is the point of the odd __getitem__() method in test_enumerate.py? Maybe you should use assertRaisesRegex() to check that the intended TypeError is actually raised. ---------- nosy: +martin.panter stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 00:34:09 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 01 Jan 2016 05:34:09 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1451626449.54.0.0151488220405.issue25958@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t think you need to define __len__() to get an iterable, only __getitem__(). Also, if I understand your problem, Container would also be susceptible in theory, because membership testing via ?in? and ?not in? falls back to iteration. If you only define __getitem__(), your class is both iterable and a container, but it is neither an Iterable nor a Container. :) ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 00:47:35 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 01 Jan 2016 05:47:35 +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: <1451627255.83.0.017914605735.issue17756@psf.upfronthosting.co.za> Ezio Melotti added the comment: I'm going to close this since the reported issue has been fixed. In the test sys.stderr was mocked, and Mock.method_calls simply records the calls done to the mock. Therefore the fact that 'NameError' and ':' were written on sys.stderr on two separate calls to write() is not a problem with mocks. ---------- nosy: +rbcollins resolution: out of date -> fixed stage: needs patch -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 02:45:04 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jan 2016 07:45:04 +0000 Subject: [issue25985] Use sys.version_info instead of sys.version Message-ID: <1451634303.31.0.471991642776.issue25985@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch replaces all occurrences of sys.version[:3] with '%d.%d' % sys.version_info[:2]. The former doesn't work with non-one-digit versions (such as 3.10 and 10.1). ---------- components: Distutils, Library (Lib) files: use_version_info.patch keywords: patch messages: 257279 nosy: dstufft, eric.araujo, lemburg, serhiy.storchaka, tarek priority: normal severity: normal stage: patch review status: open title: Use sys.version_info instead of sys.version type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file41463/use_version_info.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 02:59:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jan 2016 07:59:34 +0000 Subject: [issue25256] Add sys.debug_build public variable to check if Python was compiled in debug mode In-Reply-To: <1443446100.69.0.307482207939.issue25256@psf.upfronthosting.co.za> Message-ID: <1451635174.61.0.332656439334.issue25256@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Implementing sys.abiflags on Windows looks more general solution, and it doesn't increase the complexity of the stdlib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 03:14:34 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 01 Jan 2016 08:14:34 +0000 Subject: [issue23166] urllib2 ignores opener configuration under certain circumstances In-Reply-To: <1420406037.0.0.986455895168.issue23166@psf.upfronthosting.co.za> Message-ID: <1451636074.29.0.660183251413.issue23166@psf.upfronthosting.co.za> Martin Panter added the comment: I think these are essentially the same problem. It defeats any custom installed opener, not just custom HTTPS handlers. ---------- nosy: +martin.panter resolution: -> duplicate status: open -> closed superseder: -> urllib.parse.urlopen shouldn't ignore installed opener when called with any ca* argument _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 03:22:55 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 01 Jan 2016 08:22:55 +0000 Subject: [issue18543] urllib.parse.urlopen shouldn't ignore installed opener when called with any SSL argument In-Reply-To: <1374668818.72.0.697922032573.issue18543@psf.upfronthosting.co.za> Message-ID: <1451636575.87.0.0293050749639.issue18543@psf.upfronthosting.co.za> Martin Panter added the comment: I closed Issue 18543 as a duplicate, which points out this also affects Python 2.7.9+, and can also be triggered by setting the ?context? parameter. Overall, I am not comfortable with the complication and hacks in the current patch. Maybe it would be simpler to not fix the bug, and just document that you cannot use the SSL context parameters with a custom opener. If necessary, we could add a new API to pass the context to the handler properly, as suggested by Benjamin in , but that might have to be in 3.6+ only. Some specific comments on the patch: The url[:5] check should probably check for a colon as well. What?s the problem with multiple HTTPS handlers? Is it a side effect of your patch, or did it already exist? Is it only a problem for urlopen(), or also for calling open() directly? You can use any() instead of building a list and testing if it is empty. I think you can handle https: URLs without defining https_open(), for instance I have a handler that defines default_open() and checks the request manually. Does your patch account for that? The patch seems to modify the default installed opener with the supplied SSL parameters. Also I wonder if it would break any multithreaded usage that currently works. It would be good to have test cases integrated into the existing suite. ---------- nosy: +martin.panter stage: -> patch review title: urllib.parse.urlopen shouldn't ignore installed opener when called with any ca* argument -> urllib.parse.urlopen shouldn't ignore installed opener when called with any SSL argument versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 04:01:29 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 01 Jan 2016 09:01:29 +0000 Subject: [issue25942] subprocess.call SIGKILLs too liberally In-Reply-To: <1451006108.23.0.113868196098.issue25942@psf.upfronthosting.co.za> Message-ID: <1451638889.68.0.248338851045.issue25942@psf.upfronthosting.co.za> Martin Panter added the comment: Doesn?t this scenario apply equally to run(), or check_output() in 3.4? I suspect the explicit p.wait() call is not needed either. The context manager should already be calling wait(). One possible problem that I can think of: if you set a timeout, then interrupt the call with KeyboardInterrupt or similar, the context manager will now wait without without a timeout. Demo: # Hit Ctrl+C before the 3 s timeout, and it will delay 10 s call('trap "" INT && sleep 10', shell=True, timeout=3) ---------- nosy: +martin.panter stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 05:25:54 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 01 Jan 2016 10:25:54 +0000 Subject: [issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError In-Reply-To: <1450150718.99.0.697293755498.issue25864@psf.upfronthosting.co.za> Message-ID: <1451643954.18.0.279272714262.issue25864@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 05:39:52 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 01 Jan 2016 10:39:52 +0000 Subject: [issue19475] Add timespec optional flag to datetime isoformat() to choose the precision In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za> Message-ID: <1451644792.19.0.410654857947.issue19475@psf.upfronthosting.co.za> Martin Panter added the comment: I think there is a memory leak in the C code. I left some other minor suggestions as well, but it almost looks ready. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 05:47:00 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 01 Jan 2016 10:47:00 +0000 Subject: [issue25981] Intern namedtuple field names In-Reply-To: <1451505939.05.0.983054710729.issue25981@psf.upfronthosting.co.za> Message-ID: <1451645220.39.0.290402333079.issue25981@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The benefits are tiny, but if the one line patch looks good, we might as well intern the _fields and save a few bytes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 07:23:49 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jan 2016 12:23:49 +0000 Subject: [issue25981] Intern namedtuple field names In-Reply-To: <1451505939.05.0.983054710729.issue25981@psf.upfronthosting.co.za> Message-ID: <1451651029.64.0.0931504424344.issue25981@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Interesting, short string literals usually are interned, but they are not interned in tuple literal. >>> namespace = {} >>> exec('a = ["abc123"]\ndef abc123(): pass', namespace) >>> namespace['abc123'].__name__ is namespace['a'][0] True >>> exec('a = ("abc123",)\ndef abc123(): pass', namespace) >>> namespace['abc123'].__name__ is namespace['a'][0] False >>> namespace['abc123'].__name__ == namespace['a'][0] True I think it would be better to change the compiler to always intern short string literals. And patching namedtuple will be not needed. ---------- nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 07:48:50 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Jan 2016 12:48:50 +0000 Subject: [issue25256] Add sys.debug_build public variable to check if Python was compiled in debug mode In-Reply-To: <1451625082.07.0.889774325626.issue25256@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: The consensus was to add a new flag to sys.implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 07:50:31 2016 From: report at bugs.python.org (Alessandro Cucci) Date: Fri, 01 Jan 2016 12:50:31 +0000 Subject: [issue19475] Add timespec optional flag to datetime isoformat() to choose the precision In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za> Message-ID: <1451652631.87.0.867003616274.issue19475@psf.upfronthosting.co.za> Alessandro Cucci added the comment: Thanks @martin.panter, here is another patch made after your comments. ---------- Added file: http://bugs.python.org/file41464/issue19475_v12.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 07:56:10 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Jan 2016 12:56:10 +0000 Subject: [issue25942] subprocess.call SIGKILLs too liberally In-Reply-To: <1451321868.61.0.845959786585.issue25942@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: The issue explained in 12494 is that the caller doesn't have access to the subprocess.Popen object. I disagree to not kill the process when an exception is raised, even KeyboardInterrupt. I also disagree to say that we kill an "arbitrary" process. IMHO it's part of the API that the process is killed with SIGKILL on error. Maybe we need to flag to send SIGTERM on exception and then wait N wait until the child exited, or send SIGKILL after the timeout. Maybe it's overkill and such API should be developed in third party modules. Anyway, not sending any signal on exction is not a good idea. We must read the exit status to avoid zombi process. It's not a matter of sending a signal but of reading the exit status. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 08:30:05 2016 From: report at bugs.python.org (Ilya Kamenshchikov) Date: Fri, 01 Jan 2016 13:30:05 +0000 Subject: [issue2943] Distutils should generate a better error message when the SDK is not installed In-Reply-To: <1211455981.94.0.404413935613.issue2943@psf.upfronthosting.co.za> Message-ID: <1451655005.52.0.215573368829.issue2943@psf.upfronthosting.co.za> Ilya Kamenshchikov added the comment: please fix spent half a day to understand I need C compiler ---------- nosy: +Ilya Kamenshchikov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 13:15:03 2016 From: report at bugs.python.org (Zachary Ware) Date: Fri, 01 Jan 2016 18:15:03 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1451672103.92.0.104812763082.issue25778@psf.upfronthosting.co.za> Zachary Ware added the comment: Missed the boat on 3.4. I tried out the new test on 2.7, and it does not fail with no change to _winreg.c. Eryk, do you want to provide a patch for 2.7? I'm not interested enough to figure out what's going on there, but if you provide a patch I'll commit it. ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 15:09:45 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 01 Jan 2016 20:09:45 +0000 Subject: [issue24899] Add an os.path <=> pathlib equivalence table in pathlib docs In-Reply-To: <1440050617.44.0.44226546659.issue24899@psf.upfronthosting.co.za> Message-ID: <1451678985.18.0.742698430654.issue24899@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: docs at python -> ezio.melotti stage: needs patch -> patch review versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 15:13:25 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jan 2016 20:13:25 +0000 Subject: [issue25916] wave module readframes now returns bytes not str In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za> Message-ID: <1451679205.07.0.993778712233.issue25916@psf.upfronthosting.co.za> R. David Murray added the comment: Agree with Martin. Only the two audio module changes are correct. However, I think we can reduce ambiguity without compromising the meaning by changing "string of bytes" to "sequence of bytes" in both of those other cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 15:21:41 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 01 Jan 2016 20:21:41 +0000 Subject: [issue25942] subprocess.call SIGKILLs too liberally In-Reply-To: <1451006108.23.0.113868196098.issue25942@psf.upfronthosting.co.za> Message-ID: <1451679701.23.0.0632022736801.issue25942@psf.upfronthosting.co.za> Martin Panter added the comment: The reported problem is when no timeout is given. Perhaps it would be sufficient to: 1. Kill the child if any exception happens when a timeout is enforced 2. Never kill the child when there is no timeout If a timeout is specified, the current code is good enough, but if no timeout is specified, maybe we should just do the equivalent of: with Popen(...) as p: return p.wait() # If interrupted, the context manager will wait again. If the interruption is due to a terminal-wide SIGINT, the child may also have been interrupted. For comparison, the Posix system() function is supposed to ignore SIGINT and SIGQUIT (i.e. signals from the terminal). See the Gnu implementation: . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 15:24:03 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jan 2016 20:24:03 +0000 Subject: [issue25963] strptime not parsing some timezones In-Reply-To: <1451291533.28.0.979317956785.issue25963@psf.upfronthosting.co.za> Message-ID: <1451679843.88.0.729982873056.issue25963@psf.upfronthosting.co.za> R. David Murray added the comment: The code is shared by the two modules (it's in _strptime.py). So, yes. There is clearly a doc bug here (%Z needs a footnote in the table in the datetime docs), but there is no practical way to implement the parsing of arbitrary (non-locale) timezone strings, since it is not a one-to-one mapping. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, r.david.murray versions: +Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 15:32:09 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jan 2016 20:32:09 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1451680329.65.0.200866966563.issue25958@psf.upfronthosting.co.za> R. David Murray added the comment: Absolutely you do not need to define __len__ to get an iterable. Length is not a property of an iterable (iterables can be indefinite in length or infinite in length). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 15:41:00 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 01 Jan 2016 20:41:00 +0000 Subject: [issue25054] Capturing start of line '^' In-Reply-To: <1441887596.73.0.766811958538.issue25054@psf.upfronthosting.co.za> Message-ID: <1451680860.43.0.445767382862.issue25054@psf.upfronthosting.co.za> Ezio Melotti added the comment: AFAIU the problem is at Modules/_sre.c:852: after matching, if the ptr is still at the start position, the start position gets incremented to avoid an endless loop. Ideally the problem could be avoided by marking and skipping the part(s) of the pattern that have already been tested and produced a zero-length match, however I don't see any easy way to do it. Unless someone can come up with a reasonable solution, I would suggest to close this as wontfix, and possibly add a note to the docs about this corner case. ---------- versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 15:44:51 2016 From: report at bugs.python.org (SilentGhost) Date: Fri, 01 Jan 2016 20:44:51 +0000 Subject: [issue25916] wave module readframes now returns bytes not str In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za> Message-ID: <1451681091.4.0.21834561466.issue25916@psf.upfronthosting.co.za> SilentGhost added the comment: Here is the updated patch. ---------- Added file: http://bugs.python.org/file41465/issue25916_3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 15:47:27 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jan 2016 20:47:27 +0000 Subject: [issue25916] wave module readframes now returns bytes not str In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za> Message-ID: <1451681247.18.0.486180794376.issue25916@psf.upfronthosting.co.za> R. David Murray added the comment: In those contexts, bytes should not be linked to the bytes object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 15:48:20 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Jan 2016 20:48:20 +0000 Subject: [issue25986] Collections.deque maxlen: added in 2.6 or 2.7? Message-ID: <1451681300.68.0.792062287695.issue25986@psf.upfronthosting.co.za> New submission from Terry J. Reedy: https://docs.python.org/2.6/library/collections.html#collections.deque has this line "Changed in version 2.6: Added maxlen parameter." https://docs.python.org/2.7/library/collections.html#collections.deque kept the sentence above and added this entry after the list of methods. Deque objects also provide one read-only attribute: maxlen Maximum size of a deque or None if unbounded. New in version 2.7. Which is it? ---------- messages: 257299 nosy: rhettinger, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Collections.deque maxlen: added in 2.6 or 2.7? type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 15:51:34 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jan 2016 20:51:34 +0000 Subject: [issue25986] Collections.deque maxlen: added in 2.6 or 2.7? In-Reply-To: <1451681300.68.0.792062287695.issue25986@psf.upfronthosting.co.za> Message-ID: <1451681494.5.0.613133760921.issue25986@psf.upfronthosting.co.za> R. David Murray added the comment: 'parameter' and 'attribute' are two different things. I presume the documentation is accurate, but haven't checked :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 15:52:42 2016 From: report at bugs.python.org (SilentGhost) Date: Fri, 01 Jan 2016 20:52:42 +0000 Subject: [issue25916] wave module readframes now returns bytes not str In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za> Message-ID: <1451681562.08.0.148317796906.issue25916@psf.upfronthosting.co.za> Changes by SilentGhost : Added file: http://bugs.python.org/file41466/issue25916_4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 16:00:18 2016 From: report at bugs.python.org (Camilla Montonen) Date: Fri, 01 Jan 2016 21:00:18 +0000 Subject: [issue16731] xxlimited/xxmodule docstrings ambiguous In-Reply-To: <1355946646.69.0.259699636535.issue16731@psf.upfronthosting.co.za> Message-ID: <1451682018.02.0.0681909217296.issue16731@psf.upfronthosting.co.za> Camilla Montonen added the comment: Changed xxlimited.c to xxmodule.c in the xxlimited.c docstring. ---------- versions: +Python 3.5, Python 3.6 -Python 3.4 Added file: http://bugs.python.org/file41467/issue16731.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 16:24:18 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 01 Jan 2016 21:24:18 +0000 Subject: [issue25916] wave module readframes now returns bytes not str In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za> Message-ID: <1451683458.42.0.610008750536.issue25916@psf.upfronthosting.co.za> Martin Panter added the comment: Patch 4 looks fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 16:25:14 2016 From: report at bugs.python.org (Andrew Barnert) Date: Fri, 01 Jan 2016 21:25:14 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1451683514.66.0.370992724909.issue25958@psf.upfronthosting.co.za> Andrew Barnert added the comment: > I don?t think you need to define __len__() to get an iterable, only __getitem__(). The "old-style sequence protocol" means having a __getitem__ that works for values from 0 to __len__() and raises IndexError at __len__(). You don't need to be a complete old-style sequence to be iterable; just having __getitem__ makes you iterable (without being a collections.abc.Iterable or a typing.Iterable), and having __getitem__ and __len__ makes you reversible (without being a typing.Reversible). At any rate, this bug isn't about avoiding false negatives for the implicit ABCs, but false positives: defining __iter__ = None blocks the old-style sequence protocol, but makes isinstance(Iterable) true. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 16:27:19 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 01 Jan 2016 21:27:19 +0000 Subject: [issue24294] DeprecationWarnings should be visible by default in the interactive REPL In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za> Message-ID: <1451683639.4.0.541410944212.issue24294@psf.upfronthosting.co.za> Ezio Melotti added the comment: > It would help if there were some official guidance on what these things > mean -- I can't find anything written down anywhere that even documents > what you just said about how CPython proper uses them, so I imagine > people have come up with all kinds of interpretations. A while ago I proposed to document our deprecation process and the use of PDW/DW in a PEP: https://mail.python.org/pipermail/python-dev/2011-October/114199.html There I suggest that we (CPython) stop using PDW but leave it around for other projects to use as they see fit. I'm not sure CPython should do anything special to distinguish PDW from DW. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 16:29:09 2016 From: report at bugs.python.org (Andrew Barnert) Date: Fri, 01 Jan 2016 21:29:09 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1451683749.6.0.596457699138.issue25958@psf.upfronthosting.co.za> Andrew Barnert added the comment: > Also, if I understand your problem, Container would also be susceptible in theory You're right, but not in the details. Being iterable (whether via __iter__ or via the old-style sequence protocol) makes you a container. But, again, false negatives for Container aren't a problem. But blocking that by setting __contains__ = None makes you a Container but not a container, the same kind of false positive as #25864. That's exactly why I split off this bug from that one--that one only fixes __iter__ and __reversed__, but it's possible that a more general solution is needed. (Or, of course, maybe we don't need anything more general, we just need to expand it to __iter__, __reversed__, and __contains__.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 16:30:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jan 2016 21:30:54 +0000 Subject: [issue25916] wave module readframes now returns bytes not str In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za> Message-ID: <1451683854.22.0.355273561063.issue25916@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Another uses of this idiom: "string of 16 bytes" in uuid.rst and uuid.py "string of *n* random bytes" in os.rst "string of bytes" in bytesio.c And a number of uses "bytestring", "byte string" and "bytes string". I think that either all occurrences should be changed consistently, or nothing. Personally I'm good with all these "string of bytes", "bytestring", etc, it is clear to me that that mean bytes or bytes-like objects. What is a bug, it's using the term "string" without "bytes" for bytes strings (there are a lot of such Python 2 remnants in the documentation and comments). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 16:36:15 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jan 2016 21:36:15 +0000 Subject: [issue25916] wave module readframes now returns bytes not str In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za> Message-ID: <1451684175.71.0.538348087198.issue25916@psf.upfronthosting.co.za> R. David Murray added the comment: As I said, I think it's like fixing style issues in code: only do it if you touch the docs for some other reason. But this patch is fine. Although we should fix the 'string' when it is really 'bytes' issues, if we can find them. Those are real bugs, not style issues. But that should be a different issue or issues from this one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 16:38:30 2016 From: report at bugs.python.org (Andrew Barnert) Date: Fri, 01 Jan 2016 21:38:30 +0000 Subject: [issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError In-Reply-To: <1450150718.99.0.697293755498.issue25864@psf.upfronthosting.co.za> Message-ID: <1451684310.7.0.0101207368203.issue25864@psf.upfronthosting.co.za> Andrew Barnert added the comment: > If this patch goes ahead, I think the ABC documentation should clarify which methods are checked for None and which aren?t. That seems fair. Also, as you pointed out on #25958, at least one other ABC has the same problem as Iterable: you can block the "in" operator by setting __contains__=None, but you'll still be a Container. So, do we want to go through all of the existing ABCs and make sure they all do this negative check, instead of just Iterable? > Also, what is the point of the odd __getitem__() method in test_enumerate.py? Maybe you should use assertRaisesRegex() to check that the intended TypeError is actually raised. If an implementation doesn't raise a TypeError there, that's a failure. If it raises one with a different (possibly less helpful) message, I think that's just a quality-of-implementation issue, isn't it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 16:41:58 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 01 Jan 2016 21:41:58 +0000 Subject: [issue16379] SQLite error code not exposed to python In-Reply-To: <1351764878.68.0.13361347428.issue16379@psf.upfronthosting.co.za> Message-ID: <1451684518.29.0.398375237858.issue16379@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think the error message should display both the numeric code and also the error name if available. Instead of using a mapping, perhaps an Enum could be used instead. ---------- stage: needs patch -> patch review versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 16:59:29 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 01 Jan 2016 21:59:29 +0000 Subject: [issue24263] unittest cannot load module whose name starts with Unicode In-Reply-To: <1435031451.77.0.239152930978.issue24263@psf.upfronthosting.co.za> Message-ID: <1451685569.03.0.995486264525.issue24263@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Library (Lib) keywords: +easy stage: patch review -> test needed versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 17:00:33 2016 From: report at bugs.python.org (Andrew Barnert) Date: Fri, 01 Jan 2016 22:00:33 +0000 Subject: [issue25987] collections.abc.Reversible Message-ID: <1451685633.1.0.273350637631.issue25987@psf.upfronthosting.co.za> New submission from Andrew Barnert: This came up as a side issue in the -ideas discussion on deprecating the old-style sequence protocol that came out of Guido's suggestion on https://github.com/ambv/typehinting/issues/170 (http://article.gmane.org/gmane.comp.python.ideas/37599): > I also think it's fine to introduce Reversible as another ABC and carefully fit it into the existing hierarchy. It should be a one-trick pony and be another base class for Sequence; it should not have a default implementation. (But this has been beaten to death in other threads -- it's time to just file an issue with a patch.) I'll file a patch this weekend. But in case there's anything to bikeshed, here are the details: * Reversible is a subclass of Iterable. * It has a single abstract method, __reversed__, with no default implementation. * Its subclass hook that checks for __reversed__ existing and not being None. * Sequence is a subclass of Reversible, Sized, and Container rather than directly of Iterable, Sized, and Container. Builtins tuple and list, and any subclasses of them, will be Reversible because they register with Sequence or MutableSequence. Subclasses of collections.abc.Sequence will be Reversible (and should be, as they inherit Sequence.__reversed__). Custom old-style sequences will not be Reversible, even though reversed works on them. Builtins dict, set, and frozenset, and any subclasses of them, will not be Reversible (unless they add a __reversed__ method, as OrderedDict does). Subclasses of collections.abc.Mapping will not be Reversible (and should not be, as, assuming #25864 goes through, they inherit Mapping.__reversed__=None) (unless they add a __reversed__ method, as most third-party sorted-dict types do). I'll include tests for all of those things. I believe this is all exactly parallel with collections.abc.Iterable, and will make collections.abc.Reversible compatible with typing.Reversible[...] in exactly the same way collections.abc.Iterable is compatible with typing.Iterable[...]. Alternatives: We could make Reversible independent of Iterable. Alternatively, we could make it subclass both Iterable and Sized instead of just Iterable. But I think this is the simplest place to slot it in. ---------- components: Library (Lib) messages: 257310 nosy: abarnert priority: normal severity: normal status: open title: collections.abc.Reversible type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 17:18:59 2016 From: report at bugs.python.org (Andrew Barnert) Date: Fri, 01 Jan 2016 22:18:59 +0000 Subject: [issue25988] collections.abc.Indexable Message-ID: <1451686739.56.0.219134772531.issue25988@psf.upfronthosting.co.za> New submission from Andrew Barnert: In an -ideas thread, Guido suggested (http://article.gmane.org/gmane.comp.python.ideas/37599): > If we want some way to turn something that just defines __getitem__ and __len__ into a proper sequence, it should just be made to inherit from Sequence, which supplies the default __iter__ and __reversed__. (Registration is *not* good enough here.) If we really want a way to turn something that just supports __getitem__ into an Iterable maybe we can provide an additional ABC for that purpose; let's call it a HalfSequence until we've come up with a better name. (We can't use Iterable for this because Iterable should not reference __getitem__.) Later in the thread, Nick Coghlan suggested (http://article.gmane.org/gmane.comp.python.ideas/37614): > Perhaps collections.abc.Indexable would work? Invariant: > for idx, val in enumerate(container): > assert container[idx] is val > That is, while enumerate() accepts any iterable, Indexable containers have the additional property that the contained values can be looked up by their enumeration index. Mappings (even ordered ones) don't qualify, since they offer a key:value lookup, but enumerating them produces an index:key relationship. So, in particular: * Indexable is a subclass of Iterable. * Sequence is a subclass of Indexable, Sized, and Container instead of Iterable, Sized, and Container. (Or, if #25987 also goes through, of Reversible, Indexable, Sized, and Container.) * The abstract method __getitem__ and the concrete __iter__ implementation get moved up from Sequence to Indexable. * Indexable does _not_ have a subclass hook (to avoid making every Mapping, generic type, etc. accidentally Indexable). This means that you can write this (borrowing an example from Steven D'Aprano in http://article.gmane.org/gmane.comp.python.ideas/23369/): class Squares(collections.abc.Indexable): def __getitem__(self, index): return index**2 Because this no longer depends on the old-style sequence protocol, testing it with ABCs will work as expected. For related issues, see #25987, #25864, #25958, and https://github.com/ambv/typehinting/issues/170 ---------- components: Library (Lib) messages: 257311 nosy: abarnert priority: normal severity: normal status: open title: collections.abc.Indexable type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 17:31:30 2016 From: report at bugs.python.org (Camilla Montonen) Date: Fri, 01 Jan 2016 22:31:30 +0000 Subject: [issue15718] Possible OverflowError in __len__ method undocumented (when called via len() function) In-Reply-To: <1345202279.02.0.767068523185.issue15718@psf.upfronthosting.co.za> Message-ID: <1451687490.55.0.838298499481.issue15718@psf.upfronthosting.co.za> Camilla Montonen added the comment: The deficiency noticed by Terry has been at least partially corrected in the len() docs https://docs.python.org/2/library/functions.html#len Return the length (the number of items) of an object. The argument may be a sequence (such as a string, bytes, tuple, list, or range) or a collection (such as a dictionary, set, or frozen set). It doesn't mention the fact that the collection has to implement __len__, but I suppose that might be obvious to experienced Python users (isn't obvious to a beginner like me, though). So perhaps this might be a welcome clarification. The issue regarding OverflowError raised by Rostyslav still remains unresolved. ---------- nosy: +Winterflower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 17:57:02 2016 From: report at bugs.python.org (Camilla Montonen) Date: Fri, 01 Jan 2016 22:57:02 +0000 Subject: [issue24899] Add an os.path <=> pathlib equivalence table in pathlib docs In-Reply-To: <1440050617.44.0.44226546659.issue24899@psf.upfronthosting.co.za> Message-ID: <1451689022.22.0.842108670394.issue24899@psf.upfronthosting.co.za> Camilla Montonen added the comment: This is a good one for beginner patch reviewers, so submitted this to the core-mentorship mailing list. ---------- nosy: +Winterflower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 18:01:16 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Jan 2016 23:01:16 +0000 Subject: [issue15718] Possible OverflowError in __len__ method undocumented (when called via len() function) In-Reply-To: <1345202279.02.0.767068523185.issue15718@psf.upfronthosting.co.za> Message-ID: <1451689276.93.0.0417722394853.issue15718@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 18:05:28 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 01 Jan 2016 23:05:28 +0000 Subject: [issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError In-Reply-To: <1450150718.99.0.697293755498.issue25864@psf.upfronthosting.co.za> Message-ID: <1451689528.59.0.377494295026.issue25864@psf.upfronthosting.co.za> Martin Panter added the comment: IMO allowing any special method to be set to None seems to make more trouble than it is worth. Are there practical problems to address, or are they all theoretical? Ideally I think it would be better to require __reversed__() for reverse() to work, but such a change would break compatibility. Regarding test_enumerate.py, your class looks like this: class Blocked(object): def __getitem__(self): return 1 def __len__(self): return 2 __reversed__ = None The signature of __getitem__() is wrong, and causes a TypeError during iteration, although your particular test does not go that far. When I see someone using assertRaises() with a common exception like TypeError, I instinctively suggest checking the message to avoid these kind of test case bugs. I suggest either remove __getitem__() if it serves no purpose, or change it to something like this if you really want an unreversible sequence: def __getitem__(self, index): return (1, 1)[index] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 18:13:50 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 01 Jan 2016 23:13:50 +0000 Subject: [issue24033] Update _test_multiprocessing.py to use script helpers In-Reply-To: <1429748807.96.0.769250379827.issue24033@psf.upfronthosting.co.za> Message-ID: <1451690030.02.0.728986108955.issue24033@psf.upfronthosting.co.za> Ezio Melotti added the comment: Thanks for the patch. I left a review on Rietveld. ---------- nosy: +ezio.melotti, haypo, serhiy.storchaka versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 18:20:48 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 01 Jan 2016 23:20:48 +0000 Subject: [issue6500] urllib2 maximum recursion depth exceeded In-Reply-To: <1247819174.12.0.0313325803352.issue6500@psf.upfronthosting.co.za> Message-ID: <1451690448.29.0.227583457417.issue6500@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 18:40:03 2016 From: report at bugs.python.org (Eryk Sun) Date: Fri, 01 Jan 2016 23:40:03 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1451691603.02.0.302590154332.issue25778@psf.upfronthosting.co.za> Eryk Sun added the comment: The current test works for 3.x because we keep the full string length via PyUnicode_AsWideCharString(value, &len) when creating a REG_SZ value. OTOH, 2.x Py2Reg gets the length via strlen. I'd prefer to make this consistent with 3.x by using the full string length from PyString_AsStringAndSize. Expanding the range of supported values is less disruptive to existing code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 18:47:02 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 01 Jan 2016 23:47:02 +0000 Subject: [issue15718] Possible OverflowError in __len__ method undocumented (when called via len() function) In-Reply-To: <1345202279.02.0.767068523185.issue15718@psf.upfronthosting.co.za> Message-ID: <1451692022.77.0.313831784261.issue15718@psf.upfronthosting.co.za> Martin Panter added the comment: Issue 10289 proposes to link from len() to __len__() in the documentation. I think the limitation only needs to be documented for __len__(); there are other ways to invoke it as well. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 18:46:57 2016 From: report at bugs.python.org (Vincent Davis) Date: Fri, 01 Jan 2016 23:46:57 +0000 Subject: [issue25989] documentation version switcher is broken fro 2.6, 3.2, 3.3 Message-ID: <1451692017.71.0.123733949867.issue25989@psf.upfronthosting.co.za> New submission from Vincent Davis: >From the documentation pages for python 2.7 and 3.4, 3.5, 3.6 it is possible to select another python version in the breadcrumb at the top left of the page. This is not available for python 2.6, 3.2 and 3.3. See related issue which is closed. https://bugs.python.org/issue25113 I posted this on pythondotorg but I guess this is a cpython issue not a website issue. https://github.com/python/pythondotorg/issues/868 Berker Peksag response to the report "The version switcher is activated via a versionswitcher option in Doc/Makefile in CPython codebase. Docs are generated daily by using that Makefile, but 2.6, 3.2 and 3.3 are in security-fix-only mode (which means they won't even get documentation fixes) so the daily build script skips generating docs for those versions." ---------- assignee: docs at python components: Documentation messages: 257317 nosy: Vincentdavis, docs at python priority: normal severity: normal status: open title: documentation version switcher is broken fro 2.6, 3.2, 3.3 type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 18:52:51 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Jan 2016 23:52:51 +0000 Subject: [issue25959] tkinter - PhotoImage.zoom() causes segfault In-Reply-To: <1451171771.79.0.252031360467.issue25959@psf.upfronthosting.co.za> Message-ID: <1451692371.59.0.106535344324.issue25959@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Tk ticket update: '''aspect added on 2015-12-28 00:30:33: I can reproduce this crash on 8.5.18 and 8.6.4, but it appears to be fixed in trunk: "not enough free memory for image buffer".''' We should see fix in 3.6. Doc addition is not exactly trivial, as there is only the barest mention of images in https://docs.python.org/3/library/tkinter.html#images. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 19:10:17 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 02 Jan 2016 00:10:17 +0000 Subject: [issue25983] Add tests for multi-argument type() In-Reply-To: <1451575944.98.0.12158451128.issue25983@psf.upfronthosting.co.za> Message-ID: <1451693417.78.0.803848924144.issue25983@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I presume that there are existing tests that class statements work. Is so, these implicitly test type(name, bases, namespace). But I can see value to test testing the two phases of class creation separately. Test 'class' with a mock type that records the arguments passed, and separately test type explicitly. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 19:11:41 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 02 Jan 2016 00:11:41 +0000 Subject: [issue25984] Expose a simple "is IEEE 754" flag in sys.float_info In-Reply-To: <1451595590.68.0.197113034584.issue25984@psf.upfronthosting.co.za> Message-ID: <1451693501.43.0.193630146801.issue25984@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +eric.smith, lemburg, mark.dickinson, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 19:17:29 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 02 Jan 2016 00:17:29 +0000 Subject: [issue23404] 'make touch' does not work with git clones of the source repository In-Reply-To: <1423262765.96.0.527396909.issue23404@psf.upfronthosting.co.za> Message-ID: <1451693849.69.0.834375094388.issue23404@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 21:15:53 2016 From: report at bugs.python.org (Steve Litt) Date: Sat, 02 Jan 2016 02:15:53 +0000 Subject: [issue25990] Pydoc fails on Python file with nonlocal Message-ID: <1451700952.99.0.532162073876.issue25990@psf.upfronthosting.co.za> New submission from Steve Litt: Latest pydoc on Void linux 64 bit, I have no idea how to capture the version. Source file can be either Python 3.4 or 2.7, same result. ERROR MESSAGE: [slitt at mydesk ~]$ pydoc pydoc_fail problem in ./pydoc_fail.py - : invalid syntax (pydoc_fail.py, line 6) [slitt at mydesk ~]$ ---------- files: pydoc_fail.py hgrepos: 328 messages: 257321 nosy: stevelitt priority: normal severity: normal status: open title: Pydoc fails on Python file with nonlocal type: crash Added file: http://bugs.python.org/file41468/pydoc_fail.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 21:18:23 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jan 2016 02:18:23 +0000 Subject: [issue25990] Pydoc fails on Python file with nonlocal In-Reply-To: <1451700952.99.0.532162073876.issue25990@psf.upfronthosting.co.za> Message-ID: <1451701103.23.0.544383169308.issue25990@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- hgrepos: -328 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 21:23:27 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jan 2016 02:23:27 +0000 Subject: [issue25990] Pydoc fails on Python file with nonlocal In-Reply-To: <1451700952.99.0.532162073876.issue25990@psf.upfronthosting.co.za> Message-ID: <1451701407.74.0.0831512091188.issue25990@psf.upfronthosting.co.za> R. David Murray added the comment: Are you sure you are running pydoc using python3? That error looks like you are running it using python2, as does the command line you show (since on most systems the pydoc command comes from python2). (I don't know what you mean by "source file can be..."; nonlocal is python3 only.) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 21:47:47 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 02 Jan 2016 02:47:47 +0000 Subject: [issue20008] Clean up/refactor/make discoverable test_decimal In-Reply-To: <1387315472.11.0.523562380055.issue20008@psf.upfronthosting.co.za> Message-ID: <1451702867.32.0.720901793863.issue20008@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 22:17:56 2016 From: report at bugs.python.org (Steve Litt) Date: Sat, 02 Jan 2016 03:17:56 +0000 Subject: [issue25990] Pydoc fails on Python file with nonlocal In-Reply-To: <1451701407.74.0.0831512091188.issue25990@psf.upfronthosting.co.za> Message-ID: <20160101221909.17a035f5@mydesk.domain.cxm> Steve Litt added the comment: On Sat, 02 Jan 2016 02:23:27 +0000 "R. David Murray" wrote: > R. David Murray added the comment: > > Are you sure you are running pydoc using python3? That error looks > like you are running it using python2, as does the command line you > show (since on most systems the pydoc command comes from python2). > (I don't know what you mean by "source file can be..."; nonlocal is > python3 only.) > > ---------- > nosy: +r.david.murray Thanks R. David, You indeed got to the crux of the problem. I performed the following command and everything worked perfectly: python3 /usr/bin/pydoc pydoc_fail.py I tried to note on the bug tracker that the problem is solved by using Python3 to run pydoc and this wasn't a bug, but was unable to add anything to issue 25990. I saw no "reply" button, and "Edit" was a label, not a button. How do I reply on the bug tracker? Thanks, Steve Steve Litt November 2015 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 22:20:28 2016 From: report at bugs.python.org (Eryk Sun) Date: Sat, 02 Jan 2016 03:20:28 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1451704828.9.0.0213212539601.issue25778@psf.upfronthosting.co.za> Changes by Eryk Sun : Added file: http://bugs.python.org/file41469/issue25778_py27_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 22:20:49 2016 From: report at bugs.python.org (Eryk Sun) Date: Sat, 02 Jan 2016 03:20:49 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1451704849.89.0.216297382933.issue25778@psf.upfronthosting.co.za> Changes by Eryk Sun : Added file: http://bugs.python.org/file41470/issue25778_py36_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 22:28:16 2016 From: report at bugs.python.org (Eryk Sun) Date: Sat, 02 Jan 2016 03:28:16 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1451705296.15.0.21245155895.issue25778@psf.upfronthosting.co.za> Eryk Sun added the comment: I've added a patch for 2.7 that updates Py2Reg to use PyString_GET_SIZE instead of strlen and updates Reg2Py to use strnlen instead of returning strings with embedded NULs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 23:28:53 2016 From: report at bugs.python.org (Bruce Frederiksen) Date: Sat, 02 Jan 2016 04:28:53 +0000 Subject: [issue25991] readline example eventually consumes all memory Message-ID: <1451708933.83.0.797303528676.issue25991@psf.upfronthosting.co.za> New submission from Bruce Frederiksen: The Example in the readline documentation (section 6.7 of the Library Reference) shows how to save your readline history in a file, and restore it each time you start Python. The problem with the Example is that it does not include a call to readline.set_history_length and the default is -1 (infinite). As a Python developer, I start Python quite a lot and had a .python_history file that was 850M bytes. Just starting Python was causing my system to thrash before the first prompt (>>>) even appeared. I suggest adding the following line to the example to avoid this: readline.set_history_length(1000) I'm not sure how far back this goes in terms of earlier versions of Python, but probably quite far. ---------- assignee: docs at python components: Documentation messages: 257325 nosy: dangyogi, docs at python priority: normal severity: normal status: open title: readline example eventually consumes all memory type: resource usage versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 00:50:06 2016 From: report at bugs.python.org (Bryce Miller) Date: Sat, 02 Jan 2016 05:50:06 +0000 Subject: [issue25992] test_gdb fails Message-ID: <1451713806.34.0.803842118103.issue25992@psf.upfronthosting.co.za> New submission from Bryce Miller: test_gdb fails for me on OSX Steps I did to duplicate: Checked out fresh '2.7' branch from https://github.com/python/cpython.git >From the new cypthon dir ran: ./configure make make test ./Lib/test/regrtest.py -v test_gdb Attached the full verbose output. I am looking at Issue23137 and the output messages look different than mine, so I'm posting this as a separate issue. Perhaps it is duplicate. 34 tracebacks included in attachment, but below is a sample for reference: ====================================================================== FAIL: test_NULL_instance_dict (test.test_gdb.PrettyPrintTests) Ensure that a PyInstanceObject with with a NULL in_dict is handled ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_gdb.py", line 521, in test_NULL_instance_dict exptype='Foo') File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_gdb.py", line 459, in assertSane cmds_after_breakpoint=cmds_after_breakpoint) File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_gdb.py", line 239, in get_gdb_repr import_site=import_site) File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_gdb.py", line 224, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['Unable to find Mach task por... != [] First list contains 4 additional elements. First extra element 0: Unable to find Mach task port for process-id 53220: (os/kern) failure (0x5). ---------- components: Tests files: regrtest_test_gdb.log hgrepos: 329 messages: 257326 nosy: Bryce Miller priority: normal severity: normal status: open title: test_gdb fails type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file41471/regrtest_test_gdb.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 00:51:10 2016 From: report at bugs.python.org (Bryce Miller) Date: Sat, 02 Jan 2016 05:51:10 +0000 Subject: [issue25992] test_gdb fails In-Reply-To: <1451713806.34.0.803842118103.issue25992@psf.upfronthosting.co.za> Message-ID: <1451713870.13.0.462421955653.issue25992@psf.upfronthosting.co.za> Changes by Bryce Miller : ---------- hgrepos: -329 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 00:52:22 2016 From: report at bugs.python.org (Bryce Miller) Date: Sat, 02 Jan 2016 05:52:22 +0000 Subject: [issue25992] test_gdb fails In-Reply-To: <1451713806.34.0.803842118103.issue25992@psf.upfronthosting.co.za> Message-ID: <1451713942.41.0.350854996082.issue25992@psf.upfronthosting.co.za> Bryce Miller added the comment: Github repo version was 4935c6c381b196334b97aac4e9e4e8fee35b0947 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 00:54:13 2016 From: report at bugs.python.org (Stefan Krah) Date: Sat, 02 Jan 2016 05:54:13 +0000 Subject: [issue20008] Clean up/refactor/make discoverable test_decimal In-Reply-To: <1387315472.11.0.523562380055.issue20008@psf.upfronthosting.co.za> Message-ID: <1451714053.62.0.554549012057.issue20008@psf.upfronthosting.co.za> Stefan Krah added the comment: Is this a political nosying? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 01:02:16 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 02 Jan 2016 06:02:16 +0000 Subject: [issue25992] test_gdb fails In-Reply-To: <1451713806.34.0.803842118103.issue25992@psf.upfronthosting.co.za> Message-ID: <1451714536.44.0.870636717854.issue25992@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- components: +Macintosh nosy: +ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 01:43:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jan 2016 06:43:19 +0000 Subject: [issue25990] Pydoc fails on Python file with nonlocal In-Reply-To: <1451700952.99.0.532162073876.issue25990@psf.upfronthosting.co.za> Message-ID: <1451716999.25.0.353858215977.issue25990@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If you have installed Python 3, perhaps you have the /usr/bin/pydoc3 symlink. Just use the pydoc3 command. ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 02:27:48 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 Jan 2016 07:27:48 +0000 Subject: [issue25917] Fixing howto links in docs In-Reply-To: <1450610247.39.0.486318634402.issue25917@psf.upfronthosting.co.za> Message-ID: <20160102072744.8289.31405@psf.io> Roundup Robot added the comment: New changeset 521a402ae177 by Senthil Kumaran in branch '3.4': Issue25917 : Fix howto links in docs. Point the reference documentation instead of wiki. https://hg.python.org/cpython/rev/521a402ae177 New changeset 6b9d8957aeef by Senthil Kumaran in branch '3.5': merge from 3.4 https://hg.python.org/cpython/rev/6b9d8957aeef New changeset 3a6b1186745f by Senthil Kumaran in branch 'default': merge from 3.5 https://hg.python.org/cpython/rev/3a6b1186745f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 02:30:06 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 02 Jan 2016 07:30:06 +0000 Subject: [issue25917] Fixing howto links in docs In-Reply-To: <1450610247.39.0.486318634402.issue25917@psf.upfronthosting.co.za> Message-ID: <1451719806.81.0.64548172642.issue25917@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks for the helpful, patch. I modified it to include only the faq.rst and functions.rst and applied it. ---------- assignee: docs at python -> orsenthil nosy: +orsenthil stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 02:40:52 2016 From: report at bugs.python.org (Sonali Gupta) Date: Sat, 02 Jan 2016 07:40:52 +0000 Subject: [issue25909] Incorrect documentation for PyMapping_Items and like In-Reply-To: <1450525085.87.0.352365699992.issue25909@psf.upfronthosting.co.za> Message-ID: <1451720452.65.0.824489422659.issue25909@psf.upfronthosting.co.za> Sonali Gupta added the comment: The documentation in mapping.rst and the comments in abstract.h have been changed for PyMapping_Items, PyMapping_Keys and PyMapping_Values. ---------- Added file: http://bugs.python.org/file41472/bug.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 02:42:24 2016 From: report at bugs.python.org (Richard PALO) Date: Sat, 02 Jan 2016 07:42:24 +0000 Subject: [issue23315] tempfile.mkdtemp fails with non-ascii paths on Python 2 In-Reply-To: <1422183736.06.0.60780511869.issue23315@psf.upfronthosting.co.za> Message-ID: <1451720544.78.0.033502300781.issue23315@psf.upfronthosting.co.za> Richard PALO added the comment: I notice similar problems, as found when running the test suite for lxml 3.5.0 on python2.7 ====================================================================== ERROR: test_etree_parse_io_error (lxml.tests.test_io.ETreeIOTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/opt/local/lib/python2.7/unittest/case.py", line 329, in run testMethod() File "/tmp/pkgsrc/textproc/py-lxml/work/lxml-3.5.0/src/lxml/tests/test_io.py", line 276, in test_etree_parse_io_error dn = tempfile.mkdtemp(prefix=dirnameRU) File "/opt/local/lib/python2.7/tempfile.py", line 339, in mkdtemp _os.mkdir(file, 0700) UnicodeEncodeError: 'ascii' codec can't encode characters in position 40-53: ordinal not in range(128) ====================================================================== ERROR: test_etree_parse_io_error (lxml.tests.test_io.ElementTreeIOTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/opt/local/lib/python2.7/unittest/case.py", line 329, in run testMethod() File "/tmp/pkgsrc/textproc/py-lxml/work/lxml-3.5.0/src/lxml/tests/test_io.py", line 276, in test_etree_parse_io_error dn = tempfile.mkdtemp(prefix=dirnameRU) File "/opt/local/lib/python2.7/tempfile.py", line 339, in mkdtemp _os.mkdir(file, 0700) UnicodeEncodeError: 'ascii' codec can't encode characters in position 40-53: ordinal not in range(128) the code snippet is in test_io.py", line 276 266 def test_etree_parse_io_error(self): 267 # this is a directory name that contains characters beyond latin-1 268 dirnameEN = _str('Directory') 269 dirnameRU = _str('???\260?\032?\260?\273?\276?\263') 270 filename = _str('nosuchfile.xml') 271 dn = tempfile.mkdtemp(prefix=dirnameEN) 272 try: 273 self.assertRaises(IOError, self.etree.parse, os.path.join(dn, filename)) 274 finally: 275 os.rmdir(dn) 276 dn = tempfile.mkdtemp(prefix=dirnameRU) 277 try: 278 self.assertRaises(IOError, self.etree.parse, os.path.join(dn, filename)) 279 finally: 280 os.rmdir(dn) even if I change dirnameRU to a simple French 'R?pertoire' I still get errors... It is not an option to upgrade to 3.0, sorry. BTW, I tried passing dirnameRU.encode('utf-8') but that just generates a different error: ERROR: test_etree_parse_io_error (lxml.tests.test_io.ETreeIOTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/opt/local/lib/python2.7/unittest/case.py", line 329, in run testMethod() File "/tmp/pkgsrc/textproc/py-lxml/work/lxml-3.5.0/src/lxml/tests/test_io.py", line 278, in test_etree_parse_io_error self.assertRaises(IOError, self.etree.parse, os.path.join(dn, filename)) File "/opt/local/lib/python2.7/posixpath.py", line 73, in join path += '/' + b UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 40: ordinal not in range(128) ---------- nosy: +risto3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 02:58:22 2016 From: report at bugs.python.org (Richard PALO) Date: Sat, 02 Jan 2016 07:58:22 +0000 Subject: [issue23315] tempfile.mkdtemp fails with non-ascii paths on Python 2 In-Reply-To: <1422183736.06.0.60780511869.issue23315@psf.upfronthosting.co.za> Message-ID: <1451721502.09.0.459747647172.issue23315@psf.upfronthosting.co.za> Richard PALO added the comment: If I also add .encode('utf-8') to filename on line 278, that seems gets over the pathname problem. I guess it comes down to the fact that if sys.filesystemencoding() is utf-8, which in my case it is (on SunOS), I believe these conversion should be automatic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 03:14:28 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 02 Jan 2016 08:14:28 +0000 Subject: [issue23560] Group the docs of similar methods in stdtypes.rst In-Reply-To: <1425288490.4.0.288876913126.issue23560@psf.upfronthosting.co.za> Message-ID: <1451722468.57.0.912908502949.issue23560@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 03:15:52 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 02 Jan 2016 08:15:52 +0000 Subject: [issue16927] Separate built-in types from functions and group similar functions in functions.rst In-Reply-To: <1357883404.71.0.215467038207.issue16927@psf.upfronthosting.co.za> Message-ID: <1451722552.71.0.720789893003.issue16927@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: needs patch -> patch review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 03:20:33 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 02 Jan 2016 08:20:33 +0000 Subject: [issue24117] Wrong range checking in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1451722833.85.0.935987867421.issue24117@psf.upfronthosting.co.za> Ezio Melotti added the comment: Did you hear anything back from them? ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 03:25:36 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 02 Jan 2016 08:25:36 +0000 Subject: [issue16544] Add external link to ast docs In-Reply-To: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za> Message-ID: <1451723136.68.0.936100378591.issue16544@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: docs at python -> ezio.melotti versions: +Python 3.6 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 03:38:31 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 02 Jan 2016 08:38:31 +0000 Subject: [issue24036] GB2312 codec is using a wrong covert table In-Reply-To: <1429781381.54.0.113233811407.issue24036@psf.upfronthosting.co.za> Message-ID: <1451723911.99.0.816067415175.issue24036@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 03:41:51 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 02 Jan 2016 08:41:51 +0000 Subject: [issue24024] str.__doc__ needs an update In-Reply-To: <1429708426.75.0.208318155296.issue24024@psf.upfronthosting.co.za> Message-ID: <1451724111.26.0.338606115577.issue24024@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 versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 03:49:30 2016 From: report at bugs.python.org (Ralf Gommers) Date: Sat, 02 Jan 2016 08:49:30 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1451724570.87.0.586332681736.issue4709@psf.upfronthosting.co.za> Ralf Gommers added the comment: Hi all, There is now a much more concrete plan for the static MinGW-w64 based toolchain, and the first funding has materialized. Please see the announcement on the Numpy mailing list (http://article.gmane.org/gmane.comp.python.numeric.general/62207), the MingwPy site (http://mingwpy.github.io/) and in particular the "main milestones" in http://mingwpy.github.io/proposal_december2015.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 03:49:38 2016 From: report at bugs.python.org (Xiongzhi Gao) Date: Sat, 02 Jan 2016 08:49:38 +0000 Subject: [issue25993] Crashed when call time.time() after using _mm_xor_si64 Message-ID: <1451724578.62.0.704000687465.issue25993@psf.upfronthosting.co.za> New submission from Xiongzhi Gao: The version of windows is Windows 7 Service Pack 1. The version of Python is 2.7.11 (v2.7.11:6d1b6a68f775, Dec 5 2015, 20:32:19) [MSC v.1500 32 bit (Intel)] on win32. The version of compiler in visual studio 10 is 16.00.40219.01 for 80x86. I try to use SWIG to port a function that use _mm_xor_si64 like this: packed_sse.i > %module packed_sse > %{ > extern long long _packed_mm_xor_si64(long long m1, long long m2); > %} > extern long long _packed_mm_xor_si64(long long m1, long long m2); packed_sse.c > #include > > __inline __m64 int64_to_m64 (const long long i) { > union { > long long i; > __m64 v; > } u; > u.i = i; > return u.v; > } > > __inline long long m64_to_int64 (const __m64 v) { > union { > long long i; > __m64 v; > } u; > u.v = v; > return u.i; > } > > long long _packed_mm_xor_si64(long long m1, long long m2) { > __m64 m64_m1 = int64_to_m64(m1), m64_m2 = int64_to_m64(m2); > __m64 m64_result = _mm_xor_si64(m64_m1, m64_m2); > return m64_to_int64(m64_result); I use swig and compiler to port C to Python. I try to test like this, it works: test_swig.py > # -*- coding: utf-8 -*- > # !/bin/env python2 > > import random > > import packed_sse > > > if __name__ == "__main__": > for i in range(100000): > a, b = random.getrandbits(20), random.getrandbits(20) > _ = packed_sse._packed_mm_xor_si64( > a, b > ) > assert a ^ b == _ But when I try to profile the function like this, the output of first `print time.time() - _beg` is `nan` and Python crashed when run into second `print time.time() - _beg`: profile_swig.py > # -*- coding: utf-8 -*- > # !/bin/env python2 > > import random > import time > > import packed_sse > > > if __name__ == "__main__": > _beg = time.time() > for i in range(100000): > _ = packed_sse._packed_mm_xor_si64( > random.getrandbits(20), random.getrandbits(20) > ) > print time.time() - _beg # First > _beg = time.time() > for i in range(100000): > _ = random.getrandbits(20) ^ random.getrandbits(20) > print time.time() - _beg # Second I try to use `gdb` on MingGW to debug it, it said: > (gdb) stop > (gdb) c > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 7172.0xadc] > 0x534fbe6c in python27!_Py_dg_dtoa () from C:\Windows\system32\python27.dll ---------- components: Windows messages: 257337 nosy: Xiongzhi Gao, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Crashed when call time.time() after using _mm_xor_si64 type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 03:58:08 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 02 Jan 2016 08:58:08 +0000 Subject: [issue13814] Document why generators don't support the context management protocol In-Reply-To: <1326883396.25.0.884733470267.issue13814@psf.upfronthosting.co.za> Message-ID: <1451725088.05.0.395313842719.issue13814@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: needs patch -> patch review versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 03:59:45 2016 From: report at bugs.python.org (Richard PALO) Date: Sat, 02 Jan 2016 08:59:45 +0000 Subject: [issue23315] tempfile.mkdtemp fails with non-ascii paths on Python 2 In-Reply-To: <1422183736.06.0.60780511869.issue23315@psf.upfronthosting.co.za> Message-ID: <1451725185.37.0.895294284903.issue23315@psf.upfronthosting.co.za> Richard PALO added the comment: curiously enough, I was able to test with python3.5. The same errors result, and the same workaround seems to get over it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 04:05:45 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 02 Jan 2016 09:05:45 +0000 Subject: [issue12606] Mutable Sequence Type works different for lists and bytearrays in slice[i:j:k] In-Reply-To: <1311287495.04.0.0852522537211.issue12606@psf.upfronthosting.co.za> Message-ID: <1451725545.82.0.0125705676589.issue12606@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 04:22:31 2016 From: report at bugs.python.org (Ma Lin) Date: Sat, 02 Jan 2016 09:22:31 +0000 Subject: [issue24117] Wrong range checking in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1451726551.12.0.313903075109.issue24117@psf.upfronthosting.co.za> Ma Lin added the comment: I posted in a Taiwanese forum: https://groups.google.com/forum/#!forum/pythontw no reply yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 04:37:48 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jan 2016 09:37:48 +0000 Subject: [issue23315] tempfile.mkdtemp fails with non-ascii paths on Python 2 In-Reply-To: <1422183736.06.0.60780511869.issue23315@psf.upfronthosting.co.za> Message-ID: <1451727468.06.0.892759346136.issue23315@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The similar problem in Python 3 was addressed in issue24230. But this was a new feature. As for lxml tests, I suggest to use bytes names compatible with all Windows OEM encodings (consisting of ASCII + b'\xa9\xb0\xb2\xb3\xb4\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf\xc0\xc1\xc2\xc3\xc4\xc5\xc8\xc9\xe6\xf0\xf1\xf3\xf4\xf5\xf6\xf7') and with UTF-8. ---------- nosy: +gregory.p.smith, scoder, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 05:04:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jan 2016 10:04:23 +0000 Subject: [issue12606] Mutable Sequence Type works different for lists and bytearrays in slice[i:j:k] In-Reply-To: <1311287495.04.0.0852522537211.issue12606@psf.upfronthosting.co.za> Message-ID: <1451729063.06.0.811047679374.issue12606@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Note that adding this new feature to list adds a pressure to add this feature to other mutable sequences (deque, ElementTree.Element, etc). This is a burden for maintainers. array already supports this feature as well as bytearray. It may be a difference between arrays of unboxed values and general collections of Python objects. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 05:28:34 2016 From: report at bugs.python.org (Richard PALO) Date: Sat, 02 Jan 2016 10:28:34 +0000 Subject: [issue23315] tempfile.mkdtemp fails with non-ascii paths on Python 2 In-Reply-To: <1422183736.06.0.60780511869.issue23315@psf.upfronthosting.co.za> Message-ID: <1451730514.07.0.0116471096605.issue23315@psf.upfronthosting.co.za> Richard PALO added the comment: This turns out to be related to the locale environment set to 'C'. A UTF-8 locale seems to get over the issue. A fellow pkgsrc colleague filed an issue with lxml already relating to that fact for the test suite (https://bugs.launchpad.net/lxml/+bug/1522052) cheers ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 05:43:23 2016 From: report at bugs.python.org (Petri Lehtinen) Date: Sat, 02 Jan 2016 10:43:23 +0000 Subject: [issue12606] Mutable Sequence Type works different for lists and bytearrays in slice[i:j:k] In-Reply-To: <1311287495.04.0.0852522537211.issue12606@psf.upfronthosting.co.za> Message-ID: <1451731403.9.0.972761435562.issue12606@psf.upfronthosting.co.za> Changes by Petri Lehtinen : ---------- nosy: -petri.lehtinen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 06:11:02 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jan 2016 11:11:02 +0000 Subject: [issue25983] Add tests for multi-argument type() In-Reply-To: <1451693417.78.0.803848924144.issue25983@psf.upfronthosting.co.za> Message-ID: <2089255.WbG36n4TbY@xarax> Serhiy Storchaka added the comment: There is test_class, but it tests different things. There is test_metaclass, it contains doctests for class statements with metaclasses. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 06:22:03 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jan 2016 11:22:03 +0000 Subject: [issue25959] tkinter - PhotoImage.zoom() causes segfault In-Reply-To: <1451171771.79.0.252031360467.issue25959@psf.upfronthosting.co.za> Message-ID: <1451733723.86.0.867897481576.issue25959@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think it is enough just to update a docstring. Adding comprehensive RST documentation for Tkinter widgets is different issue. ---------- keywords: +patch Added file: http://bugs.python.org/file41473/tkinter_photo_zoom_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 06:55:27 2016 From: report at bugs.python.org (desbma) Date: Sat, 02 Jan 2016 11:55:27 +0000 Subject: [issue25156] shutil.copyfile should internally use os.sendfile when possible In-Reply-To: <1442520485.03.0.419427125487.issue25156@psf.upfronthosting.co.za> Message-ID: <1451735727.86.0.59938390911.issue25156@psf.upfronthosting.co.za> desbma added the comment: Can this patch be merged, or is there something I can do to improve it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 09:08:02 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jan 2016 14:08:02 +0000 Subject: [issue20008] Clean up/refactor/make discoverable test_decimal In-Reply-To: <1387315472.11.0.523562380055.issue20008@psf.upfronthosting.co.za> Message-ID: <1451743682.94.0.729723405628.issue20008@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added comments on Rietveld. The patch is slightly outdated, so I can't test it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 10:22:53 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jan 2016 15:22:53 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1451748173.23.0.92412199199.issue25596@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In general the patch LGTM. It allows to speed up glob by 5-10% in warn test. But much more gain we can achieve by using os.scandir(). Here are results of microbenchmarks: $ ./python -m timeit -s "from glob import glob" -- "glob('**/*', recursive=True)" Unpatched: 201 msec per loop Using isdir(): 181 msec per loop Using scandir(): 65.2 msec per loop $ ./python -m timeit -s "from glob import glob" -- "glob('/usr/lib*/**/*', recursive=True)" Unpatched: 2.06 sec per loop Using isdir(): 1.92 sec per loop Using scandir(): 820 msec per loop $ ./python -m timeit -s "from glob import glob" -- "glob('/usr/lib*/**/', recursive=True)" Unpatched: 1.77 sec per loop Using isdir(): 1.61 sec per loop Using scandir(): 431 msec per loop Yet one benefit is that iglob() now yields path names without the delay for reading the full content of a directory (see issue22167). ---------- nosy: +benhoyt, haypo priority: low -> normal Added file: http://bugs.python.org/file41474/glob_scandir.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 10:24:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jan 2016 15:24:23 +0000 Subject: [issue16620] Avoid using private function glob.glob1() in msi module and tools In-Reply-To: <1354736049.23.0.98660459286.issue16620@psf.upfronthosting.co.za> Message-ID: <1451748263.75.0.165334813663.issue16620@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: loewis -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 10:51:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jan 2016 15:51:35 +0000 Subject: [issue16620] Avoid using private function glob.glob1() in msi module and tools In-Reply-To: <1354736049.23.0.98660459286.issue16620@psf.upfronthosting.co.za> Message-ID: <1451749895.48.0.0699959863165.issue16620@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For now there is only one place left that uses glob1(). Here is a patch that inlines glob1() in that place. ---------- components: -Demos and Tools, Windows stage: needs patch -> patch review versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file41475/msilib_no_glob1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 10:52:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jan 2016 15:52:32 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1451749952.69.0.544877952903.issue25596@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Avoid using private function glob.glob1() in msi module and tools _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 10:54:04 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jan 2016 15:54:04 +0000 Subject: [issue16620] Avoid using private function glob.glob1() in msi module and tools In-Reply-To: <1354736049.23.0.98660459286.issue16620@psf.upfronthosting.co.za> Message-ID: <1451750044.4.0.307551256805.issue16620@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch for issue25596 removes glob1(), so we should get rid of its usage. ---------- priority: low -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 11:40:37 2016 From: report at bugs.python.org (Alessandro Cucci) Date: Sat, 02 Jan 2016 16:40:37 +0000 Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000 In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za> Message-ID: <1451752837.62.0.393908743797.issue13305@psf.upfronthosting.co.za> Changes by Alessandro Cucci : Added file: http://bugs.python.org/file41476/doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 12:45:54 2016 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 02 Jan 2016 17:45:54 +0000 Subject: [issue22499] [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636 In-Reply-To: <1411694670.5.0.645076106925.issue22499@psf.upfronthosting.co.za> Message-ID: <1451756754.04.0.858324424194.issue22499@psf.upfronthosting.co.za> Nikolaus Rath added the comment: *ping* Just letting people know that this is still happening regularly and still present in 3.5. Some reports: https://bitbucket.org/nikratio/s3ql/issues/87/ https://bitbucket.org/nikratio/s3ql/issues/109/ (last comment) ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 12:48:16 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jan 2016 17:48:16 +0000 Subject: [issue25994] File descriptor leaks in os.scandir() Message-ID: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: os.scandir() opens a file descriptor and closes it only in its destructor. This can causes file descriptor leaks in Python implementations without reference counting and if the scandir iterator becomes a part of reference loop or long living object. Since the number of open file descriptors is limited, this can leads to problems. We need to add the close() method to the scandir iterator (as in files and generators). It would be useful also to make it a context manager. In 3.5 we have to add a warning about this behavior. ---------- components: Extension Modules messages: 257351 nosy: benhoyt, haypo, serhiy.storchaka priority: high severity: normal status: open title: File descriptor leaks in os.scandir() type: resource usage versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 12:57:05 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jan 2016 17:57:05 +0000 Subject: [issue25995] os.walk() consumes a lot of file descriptors Message-ID: <1451757425.39.0.0524932176307.issue25995@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Since 3.5 os.walk() consumes a lot of file descriptors. Its number equals to the deep of directories tree. Since the number of file descriptors is limited, this can cause problems. This was the main reason for rejecting fwalk-based implementation of os.walk() (issue15200). ---------- components: Library (Lib) messages: 257352 nosy: benhoyt, haypo, larry, serhiy.storchaka priority: normal severity: normal status: open title: os.walk() consumes a lot of file descriptors type: resource usage versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 13:10:38 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jan 2016 18:10:38 +0000 Subject: [issue25996] Add support of file descriptor in os.scandir() Message-ID: <1451758238.49.0.729670752807.issue25996@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: For now os.scandir() on Unix is implemented using opendir()/readdir()/closedir(). It accepts bytes and str pathname. But most functions in the os module that accept a pathname, accept also an open file descriptor. It is possible to implement this feature in scandir() with using fdopendir() instead of opendir(). This would allow to add a support of the dir_fd parameter in scandir(). And that would allow to implement os.fwalk() with scandir() and make more efficient implementation of os.walk() (because we no longer need to walk long path for deep directories, see issue15200). ---------- components: Extension Modules messages: 257353 nosy: benhoyt, haypo, serhiy.storchaka priority: normal severity: normal status: open title: Add support of file descriptor in os.scandir() type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 14:49:16 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jan 2016 19:49:16 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1451764156.13.0.735077086084.issue25596@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think it is a good idea to break backward compatibility here even if the globN are internal functions. Better would be to continue to have globN functions that support the existing API and emit deprecation warnings. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 14:53:25 2016 From: report at bugs.python.org (Patrik Dufresne) Date: Sat, 02 Jan 2016 19:53:25 +0000 Subject: [issue25997] Tarfile.add with bytes path is failling Message-ID: <1451764405.28.0.333419880033.issue25997@psf.upfronthosting.co.za> New submission from Patrik Dufresne: With python 3.4, Tarfile doesn't properly support adding a files with bytes path. Only unicode is supported. It's failing with exception similar to: tar.add(os.path.join(dirpath, filename), filename) File "/usr/lib/python3.4/tarfile.py", line 1907, in add tarinfo = self.gettarinfo(name, arcname) File "/usr/lib/python3.4/tarfile.py", line 1767, in gettarinfo arcname = arcname.replace(os.sep, "/") TypeError: expected bytes, bytearray or buffer compatible object It uses os.sep, and u"/". Instead, it should use something like posixpath.py:_get_sep(path). ---------- components: Unicode messages: 257355 nosy: Patrik Dufresne, ezio.melotti, haypo priority: normal severity: normal status: open title: Tarfile.add with bytes path is failling type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 14:54:40 2016 From: report at bugs.python.org (SilentGhost) Date: Sat, 02 Jan 2016 19:54:40 +0000 Subject: [issue25997] Tarfile.add with bytes path is failling In-Reply-To: <1451764405.28.0.333419880033.issue25997@psf.upfronthosting.co.za> Message-ID: <1451764480.81.0.14666471345.issue25997@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Library (Lib) -Unicode nosy: +lars.gustaebel versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 15:01:26 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jan 2016 20:01:26 +0000 Subject: [issue25997] Tarfile.add with bytes path is failling In-Reply-To: <1451764405.28.0.333419880033.issue25997@psf.upfronthosting.co.za> Message-ID: <1451764886.32.0.179991579615.issue25997@psf.upfronthosting.co.za> R. David Murray added the comment: See also issue 21996. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 15:03:06 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jan 2016 20:03:06 +0000 Subject: [issue25997] Tarfile.add with bytes path is failling In-Reply-To: <1451764405.28.0.333419880033.issue25997@psf.upfronthosting.co.za> Message-ID: <1451764986.94.0.197399276621.issue25997@psf.upfronthosting.co.za> R. David Murray added the comment: Does using a surrogateescape encoded filename work? (You won't get the error you report...my question is, does that do the right thing when building the archive?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 15:12:28 2016 From: report at bugs.python.org (Patrik Dufresne) Date: Sat, 02 Jan 2016 20:12:28 +0000 Subject: [issue24110] zipfile.ZipFile.write() does not accept bytes arcname In-Reply-To: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za> Message-ID: <1451765548.83.0.201399629445.issue24110@psf.upfronthosting.co.za> Patrik Dufresne added the comment: I'm converting my project into python3. I'm encountering issue with zipfile encoding. Look like, it only support unicode path. This is a huge issue since path are, by definition, bytes. You may store a file name with an invalid character without issue on the filesystem. As such, arcname should support bytes. Like, Tar, zip file format doesn't define a specific encoding. You may store filename as bytes. ---------- nosy: +Patrik Dufresne _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 15:20:18 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jan 2016 20:20:18 +0000 Subject: [issue24110] zipfile.ZipFile.write() does not accept bytes arcname In-Reply-To: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za> Message-ID: <1451766018.53.0.746086490651.issue24110@psf.upfronthosting.co.za> R. David Murray added the comment: As noted, adding that support is the subject of issue 10757. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 15:29:36 2016 From: report at bugs.python.org (Brett Cannon) Date: Sat, 02 Jan 2016 20:29:36 +0000 Subject: [issue25711] Rewrite zipimport from scratch In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za> Message-ID: <1451766576.03.0.190758678127.issue25711@psf.upfronthosting.co.za> Brett Cannon added the comment: What are people's statuses on their various attempts? Since this is going to block my importlib.resources work I will do the work myself or work directly with someone in order to make sure this gets done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 15:45:09 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 Jan 2016 20:45:09 +0000 Subject: [issue22709] restore accepting detached stdin in fileinput binary mode In-Reply-To: <1414048560.8.0.0429092094688.issue22709@psf.upfronthosting.co.za> Message-ID: <20160102204506.77251.22119@psf.io> Roundup Robot added the comment: New changeset ded1336bff49 by R David Murray in branch '3.5': #22709: Use stdin as-is if it does not have a buffer attribute. https://hg.python.org/cpython/rev/ded1336bff49 New changeset 688d32cdbc0c by R David Murray in branch 'default': Merge: #22709: Use stdin as-is if it does not have a buffer attribute. https://hg.python.org/cpython/rev/688d32cdbc0c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 15:45:09 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 Jan 2016 20:45:09 +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: <20160102204506.77251.4148@psf.io> Roundup Robot added the comment: New changeset ded1336bff49 by R David Murray in branch '3.5': #22709: Use stdin as-is if it does not have a buffer attribute. https://hg.python.org/cpython/rev/ded1336bff49 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 15:46:26 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jan 2016 20:46:26 +0000 Subject: [issue22709] restore accepting detached stdin in fileinput binary mode In-Reply-To: <1414048560.8.0.0429092094688.issue22709@psf.upfronthosting.co.za> Message-ID: <1451767586.26.0.192942985355.issue22709@psf.upfronthosting.co.za> R. David Murray added the comment: Hopefully 'better late than never' applies to this. Sigh. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 16:25:13 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 02 Jan 2016 21:25:13 +0000 Subject: [issue24024] str.__doc__ needs an update In-Reply-To: <1429708426.75.0.208318155296.issue24024@psf.upfronthosting.co.za> Message-ID: <1451769913.85.0.448448680983.issue24024@psf.upfronthosting.co.za> Martin Panter added the comment: Slightly easier to read version: >>> pprint(str.__doc__) ("str(object='') -> str\n" 'str(bytes_or_buffer[, encoding[, errors]]) -> str\n' '\n' 'Create a new string object from the given object. If encoding or\n' 'errors is specified, then the object must expose a data buffer\n' 'that will be decoded using the given encoding and error handler.\n' 'Otherwise, returns the result of object.__str__() (if defined)\n' 'or repr(object).\n' 'encoding defaults to sys.getdefaultencoding().\n' "errors defaults to 'strict'.") I don?t exactly understand your complaint. Do you want to say encoding directly defaults to UTF-8, bypassing the getdefaultencoding() reference? Do you want to explicitly point out that bytes() and bytearray() expose a data buffer and can therefore be decoded? This is already hinted in the name bytes_or_buffer. Do you want to clarify that the Otherwise sentence applies when encoding and errors are not specified, rather than when the object does not expose a buffer? Maybe another thing to change could be fixing the second signature, to show that an explicit encoding can be omitted, and bytes_or_buffer is not a valid keyword name: str(object, encoding="utf-8", errors="strict") ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 16:27:32 2016 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 02 Jan 2016 21:27:32 +0000 Subject: [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451770052.04.0.891845217475.issue25813@psf.upfronthosting.co.za> Mark Lawrence added the comment: Clearly nobody is interested so closing. ---------- status: open -> closed versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 16:32:57 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 02 Jan 2016 21:32:57 +0000 Subject: [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451770377.41.0.883401423383.issue25813@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> needs patch status: closed -> open type: -> enhancement versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 16:34:50 2016 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 02 Jan 2016 21:34:50 +0000 Subject: [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451770490.28.0.0914010908692.issue25813@psf.upfronthosting.co.za> Mark Lawrence added the comment: I am the OP, this stays closed. If you couldn't be bothered to reply before please raise a new issue. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 16:35:32 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jan 2016 21:35:32 +0000 Subject: [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451770532.86.0.0644710317172.issue25813@psf.upfronthosting.co.za> R. David Murray added the comment: I think Yuri might be interested. ---------- assignee: docs at python -> yselivanov nosy: +r.david.murray, yselivanov stage: needs patch -> status: closed -> open type: enhancement -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 16:38:22 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jan 2016 21:38:22 +0000 Subject: [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451770702.82.0.823260998403.issue25813@psf.upfronthosting.co.za> R. David Murray added the comment: Mark, please don't close the issue. You raised a valid point, it got overlooked, but like I said I think Yuri will be interested in looking at it. This is a volunteer operation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 16:38:39 2016 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 02 Jan 2016 21:38:39 +0000 Subject: [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451770719.05.0.5367252532.issue25813@psf.upfronthosting.co.za> Mark Lawrence added the comment: For the final time, *I* am the OP and not one of you could be bothered before so this remains closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 16:39:32 2016 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 02 Jan 2016 21:39:32 +0000 Subject: [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451770772.34.0.951317716059.issue25813@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 16:44:10 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jan 2016 21:44:10 +0000 Subject: [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451771050.91.0.409558773895.issue25813@psf.upfronthosting.co.za> R. David Murray added the comment: I'll leave it closed, but I don't think that is best for the community. ---------- assignee: yselivanov -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 17:18:21 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 02 Jan 2016 22:18:21 +0000 Subject: [issue25609] Add a ContextManager ABC and type In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za> Message-ID: <1451773101.18.0.289920730915.issue25609@psf.upfronthosting.co.za> Martin Panter added the comment: What would your context manager base class do? I presume you supply a default __enter__() that does nothing, or perhaps just returns self. You mentioned having a default __exit__() but I am having trouble seeing how it would be useful. A context manager is only really useful if it does something interesting in __exit__(), and for that, the programmer has to write their own version and remember its signature. One option to simplify __exit__() that I used to use is a base class that defers to an abstract close() method with no parameters. But since ExitStack is now available, I am finding that is good enough instead. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 17:20:04 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 Jan 2016 22:20:04 +0000 Subject: [issue21815] imaplib truncates some untagged responses In-Reply-To: <1403275196.37.0.409307454531.issue21815@psf.upfronthosting.co.za> Message-ID: <20160102222001.126317.48900@psf.io> Roundup Robot added the comment: New changeset 54b36229021a by R David Murray in branch 'default': #21815: violate IMAP RFC to be compatible with, e.g., gmail https://hg.python.org/cpython/rev/54b36229021a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 17:23:14 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 02 Jan 2016 22:23:14 +0000 Subject: [issue6500] urllib2 maximum recursion depth exceeded In-Reply-To: <1247819174.12.0.0313325803352.issue6500@psf.upfronthosting.co.za> Message-ID: <1451773394.27.0.0613826966124.issue6500@psf.upfronthosting.co.za> Berker Peksag added the comment: Thank you Ezio, I'll commit this tomorrow. ---------- assignee: jhylton -> berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 17:24:37 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jan 2016 22:24:37 +0000 Subject: [issue21815] imaplib truncates some untagged responses In-Reply-To: <1403275196.37.0.409307454531.issue21815@psf.upfronthosting.co.za> Message-ID: <1451773477.09.0.355146250889.issue21815@psf.upfronthosting.co.za> R. David Murray added the comment: I rewrote the comments, and I changed the name of the test helper class from GmailHandler to BracketFlagHandler, since this is not gmail specific. (There was a review comment about that that was missed, I guess). I've applied this only to 3.6 because there is a backward compatibility concern, as I mention in the revised comments: if a server includes a ']' in the text portion, the new regex will parse it incorrectly. (Which is why the rfc restriction exists in the first place.) I'm hoping that this is very unlikely, but because it would be a nasty bug if it happens, I only feel comfortable applying it to 3.6. Thanks Lita, and everyone who reviewed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 17:24:50 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jan 2016 22:24:50 +0000 Subject: [issue21815] imaplib truncates some untagged responses In-Reply-To: <1403275196.37.0.409307454531.issue21815@psf.upfronthosting.co.za> Message-ID: <1451773490.01.0.53356586065.issue21815@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 17:25:26 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 02 Jan 2016 22:25:26 +0000 Subject: [issue25637] Move non-collections-related ABCs out of collections.abc In-Reply-To: <1447701682.74.0.653642972551.issue25637@psf.upfronthosting.co.za> Message-ID: <1451773526.19.0.444055301863.issue25637@psf.upfronthosting.co.za> Martin Panter added the comment: Did anyone consider moving these near the ?types? module, either directly inside, or as a ?types.abc? submodule? In my mind, these ABCs would fit reasonably well there. They are related to built-in types, but do not have built-in names. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 17:26:16 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 Jan 2016 22:26:16 +0000 Subject: [issue21815] imaplib truncates some untagged responses In-Reply-To: <1403275196.37.0.409307454531.issue21815@psf.upfronthosting.co.za> Message-ID: <20160102222613.105562.25550@psf.io> Roundup Robot added the comment: New changeset 53271aa4d84c by R David Murray in branch 'default': #21815: Make the doc change match what I actually did. https://hg.python.org/cpython/rev/53271aa4d84c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 17:26:20 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 02 Jan 2016 22:26:20 +0000 Subject: [issue25994] File descriptor leaks in os.scandir() In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za> Message-ID: <1451773580.55.0.0129656524332.issue25994@psf.upfronthosting.co.za> STINNER Victor added the comment: Hi, If I recall correctly, this issue was discussed in the long review of os.scandir(): issue #22524. "os.scandir() opens a file descriptor and closes it only in its destructor." Hopefully, it's incorrect: it's closed when the iterator is exhausted. See how ScandirIterator_close() is used. "This can causes file descriptor leaks in Python implementations without reference counting" Destructors are part of the Python language. Are you aware of a Python implementation *never* calls destructors? I know that PyPy can call destructors "later", not necessary when the last reference to the object is removed. Do you think that we may reach the file descriptor limit because of that? "We need to add the close() method to the scandir iterator (as in files and generators)." Is it part of the iterator protocol? Or do you mean to explicitly call close()? "It would be useful also to make it a context manager." If we decide to add a close() method, it like the idea of also supporting the context manager protocol. "In 3.5 we have to add a warning about this behavior." Yeah, maybe we can elaborate the doc to explain how the file descriptor / Windows handle is used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 17:30:43 2016 From: report at bugs.python.org (Lasse Schuirmann) Date: Sat, 02 Jan 2016 22:30:43 +0000 Subject: [issue25998] doctest crashes when accessing __wrapped__ fails other than AttributeError Message-ID: <1451773843.64.0.986014558431.issue25998@psf.upfronthosting.co.za> New submission from Lasse Schuirmann: You can see this when importing the Flask `request` object in a file that is doctested. The `request` object will throw a RuntimeError when one tries to access any attribute. Doctest tries to `inspect.unwrap` all objects in the file in order to find out if they're doctestable functions - and apparently only catches the `AttributeError` exception. Thus it crashes :) ---------- components: Tests files: shell messages: 257378 nosy: Lasse Schuirmann priority: normal severity: normal status: open title: doctest crashes when accessing __wrapped__ fails other than AttributeError type: crash versions: Python 3.5 Added file: http://bugs.python.org/file41477/shell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 17:35:33 2016 From: report at bugs.python.org (Lasse Schuirmann) Date: Sat, 02 Jan 2016 22:35:33 +0000 Subject: [issue25998] doctest crashes when accessing __wrapped__ fails other than AttributeError In-Reply-To: <1451773843.64.0.986014558431.issue25998@psf.upfronthosting.co.za> Message-ID: <1451774133.62.0.958663640594.issue25998@psf.upfronthosting.co.za> Lasse Schuirmann added the comment: (Closed) issue at the flask repository of this: https://github.com/mitsuhiko/flask/issues/1680 Also IIRC this worked back with Python 3.4 but do not consider this a fact yet. (At least the tests ran on Fedora...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 17:38:59 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 02 Jan 2016 22:38:59 +0000 Subject: [issue25996] Add support of file descriptor in os.scandir() In-Reply-To: <1451758238.49.0.729670752807.issue25996@psf.upfronthosting.co.za> Message-ID: <1451774339.98.0.207054250747.issue25996@psf.upfronthosting.co.za> STINNER Victor added the comment: Yeah, it was discussed when the PEP 471 was designed, but it was already hard to design os.scandir() without supporting fd as os.scandir() parameter. It's more complex because we have to handle the lifetime of the file descriptor especially if it's exposed in a public attribute. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 17:39:07 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 02 Jan 2016 22:39:07 +0000 Subject: [issue25997] Tarfile.add with bytes path is failing In-Reply-To: <1451764405.28.0.333419880033.issue25997@psf.upfronthosting.co.za> Message-ID: <1451774347.98.0.568720640998.issue25997@psf.upfronthosting.co.za> Martin Panter added the comment: Is the tarfile module designed to support bytes for file names in general? The documentation doesn?t seem to mention bytes anywhere relevant. This seems more like a new feature rather than a bug to me. ---------- nosy: +martin.panter title: Tarfile.add with bytes path is failling -> Tarfile.add with bytes path is failing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 17:42:01 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 02 Jan 2016 22:42:01 +0000 Subject: [issue25996] Add support of file descriptor in os.scandir() In-Reply-To: <1451758238.49.0.729670752807.issue25996@psf.upfronthosting.co.za> Message-ID: <1451774521.11.0.45262705927.issue25996@psf.upfronthosting.co.za> STINNER Victor added the comment: Supporting file descriptor was also discussed when pathlib.Path was designed, but there was similar questions on the lifetime of the file descriptor. (Who is able to close it? When? Is it ok to close it using os.close? etc.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 17:55:38 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 02 Jan 2016 22:55:38 +0000 Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000 In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za> Message-ID: <1451775338.69.0.688440701936.issue13305@psf.upfronthosting.co.za> Martin Panter added the comment: At the bottom of it suggests that this four-digit field width specifier is not portable. Does that also hold for the datetime version? It seems like a bad idea to recommend an unportable workaround for a portability problem. Also, in the patch it is not clear if you are referring to strptime(), strftime(), or both. On Linux, datetime.strptime(..., "%4Y") fails for me. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 18:03:57 2016 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 02 Jan 2016 23:03:57 +0000 Subject: [issue25637] Move non-collections-related ABCs out of collections.abc In-Reply-To: <1447701682.74.0.653642972551.issue25637@psf.upfronthosting.co.za> Message-ID: <1451775837.5.0.11831900307.issue25637@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Did anyone consider moving these near the ?types? module, either directly inside, or as a ?types.abc? submodule? In my mind, these ABCs would fit reasonably well there. They are related to built-in types, but do not have built-in names. Big -1. Let's avoid nesting 'abc' modules throughout the standard library. One of the good practices in Python is to import modules, not classes from modules. With 'types.abc' I'll have to import 'from types import abc', and then, in the code, I won't be so sure which 'abc' is it -- 'abc', 'types.abc', 'collections.abc' etc. Putting ABCs in the 'types' module directly also doesn't feel right and can confuse users. 'types' already contains things like 'GeneratorType', 'CoroutineType' etc, which are actual types (not ABCs). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 18:23:30 2016 From: report at bugs.python.org (Patrik Dufresne) Date: Sat, 02 Jan 2016 23:23:30 +0000 Subject: [issue10757] zipfile.write, arcname should be allowed to be a byte string In-Reply-To: <1293021846.1.0.84362256489.issue10757@psf.upfronthosting.co.za> Message-ID: <1451777010.57.0.54581850809.issue10757@psf.upfronthosting.co.za> Patrik Dufresne added the comment: This bug is very old, any development on the subject. This issue is hitting me trying to port my project (rdiffweb) to python3. It received a lot of broken filename with invalid encoding and I need to create a meaningful Zip archive with it. Currently, it just fail because zipfile doesn't accept arcname as bytes. ---------- nosy: +Patrik Dufresne _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 18:39:36 2016 From: report at bugs.python.org (Patrik Dufresne) Date: Sat, 02 Jan 2016 23:39:36 +0000 Subject: [issue25997] Tarfile.add with bytes path is failing In-Reply-To: <1451764405.28.0.333419880033.issue25997@psf.upfronthosting.co.za> Message-ID: <1451777976.68.0.105686526896.issue25997@psf.upfronthosting.co.za> Patrik Dufresne added the comment: > Is the tarfile module designed to support bytes for file names in general? The documentation doesn?t seem to mention bytes anywhere relevant. This seems more like a new feature rather than a bug to me. I'm using bytes in Unix to represent a path. From `os.path` docs : The path parameters can be passed as either strings, or bytes. Applications are encouraged to represent file names as (Unicode) character strings. Unfortunately, some file names may not be representable as strings on Unix, so applications that need to support arbitrary file names on Unix should use bytes objects to represent path names. Vice versa, using bytes objects cannot represent all file names on Windows (in the standard mbcs encoding), hence Windows applications should use string objects to access all files. As such, I'm expecting to use bytes to represent a path with tarfile. Also, tar file format doesn't define any specific encoding for filename. I'me xpecting to but any kind of bytes data for a given filename... since this was wokring in tarfile with py2. > Does using a surrogateescape encoded filename work? (You won't get the error you report...my question is, does that do the right thing when building the archive?) I will need to have further look into surrogateescape. I read somewhere it was an experimental feature, so I didn't try it. Thanks both for your quick feedback in this holidays. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 18:43:35 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 02 Jan 2016 23:43:35 +0000 Subject: [issue25998] doctest crashes when accessing __wrapped__ fails other than AttributeError In-Reply-To: <1451773843.64.0.986014558431.issue25998@psf.upfronthosting.co.za> Message-ID: <1451778215.57.0.723836122029.issue25998@psf.upfronthosting.co.za> Steven D'Aprano added the comment: doctest doesn't crash -- it is a regular exception, not a crash. "Crash" means "Hard crashes of the Python interpreter ? possibly with a core dump or a Windows error box." In other words, a segmentation fault or other low-level crash, not an exception. I'm not convinced that this is a problem with doctest, it looks to me like a broken-by-design flaw in requests. If you try to access an attribute that doesn't exist, you should get AttributeError, not RuntimeError. I don't understand the justification given on the requests tracker for why the attribute access fails, but I would expect that any exception other than AttributeError, or a subclass of such, is a clear bug in requests. I don't think it is doctest's responsibility to have special handling for an ill-designed proxy class, but I'll hold off closing the ticket for a few days in case anyone makes a good argument for why this is a doctest bug. ---------- nosy: +steven.daprano type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 19:16:35 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 03 Jan 2016 00:16:35 +0000 Subject: [issue25997] Tarfile.add with bytes path is failing In-Reply-To: <1451764405.28.0.333419880033.issue25997@psf.upfronthosting.co.za> Message-ID: <1451780195.28.0.412953763193.issue25997@psf.upfronthosting.co.za> Martin Panter added the comment: It looks like surrogate-escaped bytes should be supported thanks to Issue 8390, although this is not so useful if you use the ?pax? format (which always uses UTF-8 internally). To generate a surrogate-escaped string, you can ?decode? it with the following error handler: >>> b"non-as\xA9ii".decode("ascii", "surrogateescape") 'non-as\udca9ii' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 19:40:37 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 03 Jan 2016 00:40:37 +0000 Subject: [issue24104] Use after free in xmlparser_setevents (2) In-Reply-To: <1430489742.91.0.610954411273.issue24104@psf.upfronthosting.co.za> Message-ID: <1451781637.27.0.37636702475.issue24104@psf.upfronthosting.co.za> Martin Panter added the comment: Serhiy, you mentioned your Issue 24103 patch also fixes this. Should we close this one now as well, or is there more to do? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 20:00:32 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 03 Jan 2016 01:00:32 +0000 Subject: [issue1753718] base64 "legacy" functions violate RFC 3548 Message-ID: <1451782832.23.0.557933918207.issue1753718@psf.upfronthosting.co.za> Martin Panter added the comment: I was waiting for you to finish here to avoid any new merge conflicts. Now that you have committed your patch, I will try and work on mine in the next few days, and I am happy to update the doc strings at the same time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 20:24:46 2016 From: report at bugs.python.org (Ben Hoyt) Date: Sun, 03 Jan 2016 01:24:46 +0000 Subject: [issue25994] File descriptor leaks in os.scandir() In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za> Message-ID: <1451784286.68.0.221590675984.issue25994@psf.upfronthosting.co.za> Ben Hoyt added the comment: I'm not sure this is actually a leak, because (looking at the code) ScandirIterator_close() is called not just in the destructor, but also at the end of iterating, just before raising StopIteration. Is the issue that if an exception is raised or you stop iterating before the end, then it's less determined when the destructor/close is called? I think we could fairly easily add an explicit close method to the iterator and make it a context manager (add __enter__ and __exit__ methods to the iterator). Is this what you're thinking of: # manual close it = scandir.scandir(path) first_entry = next(it) it.close() with scandir.scandir(path) as it: first_entry = next(it) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 21:03:00 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 03 Jan 2016 02:03:00 +0000 Subject: [issue25944] Type confusion in partial_setstate and partial_repr leads to control flow hijack In-Reply-To: <1451016760.11.0.799942941118.issue25944@psf.upfronthosting.co.za> Message-ID: <1451786580.44.0.0897325301168.issue25944@psf.upfronthosting.co.za> Martin Panter added the comment: I presume you meant Issue 25945, also about partial_setstate(). Issue 25943 is about the bsddb module. ---------- nosy: +martin.panter superseder: Integer overflow in _bsddb leads to heap corruption -> Type confusion in partial_setstate and partial_call leads to memory corruption _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 22:25:29 2016 From: report at bugs.python.org (Zachary Ware) Date: Sun, 03 Jan 2016 03:25:29 +0000 Subject: [issue25348] Update pgo_build.bat to use --pgo flag for regrtest In-Reply-To: <1444346245.0.0.569960292546.issue25348@psf.upfronthosting.co.za> Message-ID: <1451791529.87.0.678319737086.issue25348@psf.upfronthosting.co.za> Zachary Ware added the comment: Here's a patch that folds PGO into PCbuild\build.bat (removing PCbuild\build_pgo.bat) and defaults to using "python -m test --pgo" for training. This should apply to all branches, but will need some slight adjustment for 2.7 (namely, s/-m test/-m test.regrtest/). It might also be nice to leave a stub build_pgo.bat on 2.7 and 3.5 in case anyone actually uses it. This patch also switches the default build environment to 'amd64' rather than 'x86_amd64' for -p x64 when it looks like it's running on a 64 bit OS. PGO requires 'amd64' for 64 bit builds, and if x86_amd64 is available, 'amd64' should be as well. 'x86_amd64' is still used for non-PGO builds when -p x64 is specified and it looks like a 32 bit OS. I considered switching the default platform target to x64 when running on 64 bit, but that's a separate issue. It uses "%ProgramFiles(x86)"=="" to detect 32-bit, and gives a helpful message in the case of a false positive on that check. ---------- keywords: +patch stage: -> patch review versions: +Python 2.7, Python 3.5 Added file: http://bugs.python.org/file41478/windows_pgo.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 22:28:47 2016 From: report at bugs.python.org (Upendra Kumar) Date: Sun, 03 Jan 2016 03:28:47 +0000 Subject: [issue21592] Make statistics.median run in linear time In-Reply-To: <1401279098.1.0.387904478686.issue21592@psf.upfronthosting.co.za> Message-ID: <1451791727.35.0.236045957898.issue21592@psf.upfronthosting.co.za> Upendra Kumar added the comment: This is my first attempt to contribute. I have used the Median of Medians with n/5 groups of 5 elements each. It has linear time complexity. But, still I am not sure about it, because constants may be high. Therefore, if anyone can please benchmark it with other methods or check that can this method be a viable solution to finding median more efficiently? I will like it to be checked before I make attempts to convert it into a patch. ---------- nosy: +upendra-k14 Added file: http://bugs.python.org/file41479/effmedian.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 22:33:01 2016 From: report at bugs.python.org (Upendra Kumar) Date: Sun, 03 Jan 2016 03:33:01 +0000 Subject: [issue21592] Make statistics.median run in linear time In-Reply-To: <1401279098.1.0.387904478686.issue21592@psf.upfronthosting.co.za> Message-ID: <1451791981.84.0.0559471631353.issue21592@psf.upfronthosting.co.za> Upendra Kumar added the comment: This method can also be further used to implement multiselect functionality with slight changes in the nth-order function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 23:36:19 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 03 Jan 2016 04:36:19 +0000 Subject: [issue25992] test_gdb fails In-Reply-To: <1451713806.34.0.803842118103.issue25992@psf.upfronthosting.co.za> Message-ID: <1451795779.66.0.708280380415.issue25992@psf.upfronthosting.co.za> Ned Deily added the comment: As you may know, GNU gcc and gdb have not been included in the standard development tools shipped with Apple as part of Xcode and the Command Line Tools for a number of releases, in favor of llvm/clang and lldb. So test_gdb is typically automatically skipped on current OS X releases. That said, if you install gcc and gdb from a third-party and build a current Python with it, it would be good if test_gdb passed. However, the log file you attached hints that gdb may not be functional, at least with the Homebrew Python you appear to be using (built with Clang); note the'Unable to find Mach task port' message. Can you verify that the gdb you are using does or does not work with the Python in question, perhaps by trying some of the examples in the Developer's Guide (https://docs.python.org/devguide/gdb.html)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 01:20:49 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 06:20:49 +0000 Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000 In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za> Message-ID: <1451802049.14.0.852114428632.issue13305@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Also, using %4Y seems to consistently produce zero-padded values across > different platforms. Actually I was wrong. Based on some more testing I did on Linux and Windows 8 and the previous comments in this thread, it seems that, with 1 as year: * '%4Y' does produces '0001' on Linux but gives a value error on Windows and '4Y' on OS X; * '%Y' produces '1' on Linux and '0001' on Windows and OS X; So the problem is only on Linux and only with years <1000, where to have a zero-padded value %4Y can be used instead. I don't know if these results are true for all versions of Linux/Win/OSX, so the note could just say that: 1) some platforms (e.g. Linux) don't zero-pad years <1000; 2) some platforms (e.g. Linux) support %4Y to add padding, but this doesn't work on other platforms. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 01:22:14 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Jan 2016 06:22:14 +0000 Subject: [issue24104] Use after free in xmlparser_setevents (2) In-Reply-To: <1430489742.91.0.610954411273.issue24104@psf.upfronthosting.co.za> Message-ID: <1451802134.93.0.490722408939.issue24104@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> Use after free in xmlparser_setevents (1) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 01:27:23 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 06:27:23 +0000 Subject: [issue23951] Update devguide style to use a similar theme as Docs In-Reply-To: <1429030125.69.0.476464501234.issue23951@psf.upfronthosting.co.za> Message-ID: <1451802443.58.0.704025681343.issue23951@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 01:31:51 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Jan 2016 06:31:51 +0000 Subject: [issue25994] File descriptor leaks in os.scandir() In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za> Message-ID: <1451802711.13.0.65815497815.issue25994@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, it's what I mean. Add methods close, __enter__ and __exit__ to the iterator. The scandir iterator is not just iterator, it is like file object. And as in file object, we perhaps have to emit a ResourceWarning in the destructor if close() or __exit__() were not called. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 01:32:32 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 06:32:32 +0000 Subject: [issue23942] Explain naming of the patch files in the bug tracker In-Reply-To: <1428966137.48.0.790822523429.issue23942@psf.upfronthosting.co.za> Message-ID: <1451802752.51.0.404556625314.issue23942@psf.upfronthosting.co.za> Ezio Melotti added the comment: FWIW I use e.g. issue1234.diff and if further patches are needed I add an increasing suffix: issue1234-2.diff, issue1234-3.diff, etc. Since the name doesn't matter too much, I'm not sure it's worth documenting and/or enforcing a specific convention. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 01:35:40 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 06:35:40 +0000 Subject: [issue23890] assertRaises increases reference counter In-Reply-To: <1428518225.53.0.665360255509.issue23890@psf.upfronthosting.co.za> Message-ID: <1451802940.14.0.733815039577.issue23890@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python stage: -> needs patch versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 01:37:29 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 06:37:29 +0000 Subject: [issue22831] Use "with" to avoid possible fd leaks In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za> Message-ID: <1451803049.61.0.292505123687.issue22831@psf.upfronthosting.co.za> Ezio Melotti added the comment: Serhiy, what's the status of this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 01:41:09 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 06:41:09 +0000 Subject: [issue22623] Port Python to 3DS: micro kernel, homebrew, newlib (Missing guards for some POSIX functions) In-Reply-To: <1413204243.21.0.451981347417.issue22623@psf.upfronthosting.co.za> Message-ID: <1451803269.7.0.938627634852.issue22623@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- status: open -> pending versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 01:42:42 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Jan 2016 06:42:42 +0000 Subject: [issue25944] Type confusion in partial_setstate and partial_repr leads to control flow hijack In-Reply-To: <1451016760.11.0.799942941118.issue25944@psf.upfronthosting.co.za> Message-ID: <1451803362.81.0.964458179989.issue25944@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, thank you Martin. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 02:00:39 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Jan 2016 07:00:39 +0000 Subject: [issue22831] Use "with" to avoid possible fd leaks In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za> Message-ID: <1451804439.55.0.278746674785.issue22831@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Only the most important patch for the stdlib was committed. Patches for distutils, tests and tools are not committed still. fd_leaks_distutils.patch fd_leaks_tools1_2.patch fd_leaks_tools2_2.patch fd_leaks_tests1_2.patch fd_leaks_tests2_2.patch ---------- Added file: http://bugs.python.org/file41480/fd_leaks_tests2_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 03:23:29 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Jan 2016 08:23:29 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1451809409.62.0.362631356509.issue25596@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think so too. I just wanted someone to confirmed that it is not overcautiousness. For now glob1() is used only in one place in the stdlib (issue16620). But there was other problem with previous patch, the same as with current implementation of os.walk() (issue25995). It makes glob to use a lot of file descriptors. Updated patch lefts deprecated glob1() and glob2() and makes glob to consume all scandir iterator before starting to yield values (but the problem with fd leaks on non-refcounted implementations is still left, issue25994). This doesn't affect performance, but lefts the issue with delaying (issue22167). ---------- dependencies: +File descriptor leaks in os.scandir() Added file: http://bugs.python.org/file41481/glob_scandir_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 03:48:40 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Jan 2016 08:48:40 +0000 Subject: [issue25995] os.walk() consumes a lot of file descriptors In-Reply-To: <1451757425.39.0.0524932176307.issue25995@psf.upfronthosting.co.za> Message-ID: <1451810920.97.0.325801936588.issue25995@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here are two alternative solutions for this issue. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file41482/walk_consume_fds_opt1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 03:49:03 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Jan 2016 08:49:03 +0000 Subject: [issue25995] os.walk() consumes a lot of file descriptors In-Reply-To: <1451757425.39.0.0524932176307.issue25995@psf.upfronthosting.co.za> Message-ID: <1451810943.91.0.669783611967.issue25995@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file41483/walk_consume_fds_opt2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 04:04:15 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jan 2016 09:04:15 +0000 Subject: [issue21221] Minor struct_time documentation bug In-Reply-To: <1397500160.88.0.743491348049.issue21221@psf.upfronthosting.co.za> Message-ID: <20160103090411.77241.28750@psf.io> Roundup Robot added the comment: New changeset fae779a811ec by Senthil Kumaran in branch '3.4': Issue21221 - Explain the usage of tm_isdst attribute of mktime, with valid https://hg.python.org/cpython/rev/fae779a811ec New changeset 3b7a7ea1214c by Senthil Kumaran in branch '3.5': merge from 3.4 https://hg.python.org/cpython/rev/3b7a7ea1214c New changeset b729e7ae2747 by Senthil Kumaran in branch 'default': merge from 3.5 https://hg.python.org/cpython/rev/b729e7ae2747 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 04:04:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jan 2016 09:04:24 +0000 Subject: [issue21221] Minor struct_time documentation bug In-Reply-To: <1397500160.88.0.743491348049.issue21221@psf.upfronthosting.co.za> Message-ID: <20160103090422.70421.44240@psf.io> Roundup Robot added the comment: New changeset f7324e5935f8 by Senthil Kumaran in branch '2.7': Backport doc improvements for Issue21221 - Explain the usage of tm_isdst https://hg.python.org/cpython/rev/f7324e5935f8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 04:14:29 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 03 Jan 2016 09:14:29 +0000 Subject: [issue21221] Minor struct_time documentation bug In-Reply-To: <1397500160.88.0.743491348049.issue21221@psf.upfronthosting.co.za> Message-ID: <1451812469.91.0.0582884648019.issue21221@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- assignee: docs at python -> orsenthil nosy: +orsenthil resolution: -> fixed status: open -> closed versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 04:27:27 2016 From: report at bugs.python.org (py.user) Date: Sun, 03 Jan 2016 09:27:27 +0000 Subject: [issue12606] Mutable Sequence Type works different for lists and bytearrays in slice[i:j:k] In-Reply-To: <1311287495.04.0.0852522537211.issue12606@psf.upfronthosting.co.za> Message-ID: <1451813247.69.0.313671981676.issue12606@psf.upfronthosting.co.za> py.user added the comment: Also memoryview() doesn't support: >>> m = memoryview(bytearray(b'abcde')) >>> m[::2] = () Traceback (most recent call last): File "", line 1, in TypeError: 'tuple' does not support the buffer interface >>> m[::2] = b'' Traceback (most recent call last): File "", line 1, in ValueError: memoryview assignment: lvalue and rvalue have different structures >>> m[::2] = b'123' >>> m.tobytes() b'1b2d3' >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 04:54:58 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 09:54:58 +0000 Subject: [issue23664] Modernize HTML output of difflib.HtmlDiff.make_file() In-Reply-To: <1426375374.93.0.948523072227.issue23664@psf.upfronthosting.co.za> Message-ID: <1451814898.54.0.609782558207.issue23664@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 04:57:23 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 09:57:23 +0000 Subject: [issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title In-Reply-To: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za> Message-ID: <1451815043.13.0.94409363309.issue23675@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> docs at python components: +Documentation keywords: +easy nosy: +docs at python, ezio.melotti stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 04:58:14 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 09:58:14 +0000 Subject: [issue23677] Mention dict and set comps in library reference In-Reply-To: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za> Message-ID: <1451815094.31.0.169014053083.issue23677@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> patch review type: -> enhancement versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 04:58:39 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 09:58:39 +0000 Subject: [issue23702] docs.python.org/3/howto/descriptor.html still refers to "unbound methods" In-Reply-To: <1426708114.47.0.635748134131.issue23702@psf.upfronthosting.co.za> Message-ID: <1451815119.06.0.0792931008503.issue23702@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 05:01:40 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 10:01:40 +0000 Subject: [issue23762] python.org page on new-style classes should be updated In-Reply-To: <1427207285.84.0.436806674049.issue23762@psf.upfronthosting.co.za> Message-ID: <1451815300.34.0.284797571263.issue23762@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- resolution: -> third party status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 05:06:50 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 10:06:50 +0000 Subject: [issue23986] Inaccuracy about "in" keyword for list and tuple In-Reply-To: <1429255378.08.0.140067438597.issue23986@psf.upfronthosting.co.za> Message-ID: <1451815610.53.0.505132020853.issue23986@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 05:11:55 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 10:11:55 +0000 Subject: [issue24056] Better expose closure, generator & coroutine status of functions In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1451815915.71.0.250331522166.issue24056@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 05:16:53 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 10:16:53 +0000 Subject: [issue21593] Clarify re.search documentation first match In-Reply-To: <1401287966.38.0.860641123785.issue21593@psf.upfronthosting.co.za> Message-ID: <1451816213.46.0.975223893012.issue21593@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett stage: resolved -> commit review versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 06:45:05 2016 From: report at bugs.python.org (SonokoMizuki) Date: Sun, 03 Jan 2016 11:45:05 +0000 Subject: [issue25999] Add support of native number in bin() Message-ID: <1451821505.72.0.958245773106.issue25999@psf.upfronthosting.co.za> New submission from SonokoMizuki: Add support of negative number in bin(). Currently, bin(-5) returns '-0b101', It is not intuitive. I think bin() should return two's complement. I suggest new bin(). New second argument is bit size. if first argument is negative number and bit size is given, bin() will return two's complement. example) >>> bin(12) '0b1100' >>> bin(-12) '-0b1100' >>> bin(-12,8) '0b11110100' >>> bin(-12,3) # if not enough bit size, bin will return value as usual. '-0b100' ---------- components: Argument Clinic messages: 257408 nosy: larry, mizuki priority: normal severity: normal status: open title: Add support of native number in bin() type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 06:58:03 2016 From: report at bugs.python.org (Julian Taylor) Date: Sun, 03 Jan 2016 11:58:03 +0000 Subject: [issue21592] Make statistics.median run in linear time In-Reply-To: <1401279098.1.0.387904478686.issue21592@psf.upfronthosting.co.za> Message-ID: <1451822283.56.0.107509040278.issue21592@psf.upfronthosting.co.za> Julian Taylor added the comment: the median of median of 5 is quite significantly slower than a quickselect. numpy implements an introselect which uses quickselect but falls back to median of median of 5 if not enough progress is done. In the numpy implementation for 100000 element median (multiselect with 2 selections, one median one min) quickselect is around 3 times faster than mom5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 07:03:58 2016 From: report at bugs.python.org (SilentGhost) Date: Sun, 03 Jan 2016 12:03:58 +0000 Subject: [issue25999] Add support of native number in bin() In-Reply-To: <1451821505.72.0.958245773106.issue25999@psf.upfronthosting.co.za> Message-ID: <1451822638.49.0.629885151123.issue25999@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Interpreter Core -Argument Clinic versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 07:16:06 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Jan 2016 12:16:06 +0000 Subject: [issue25999] Add support of native number in bin() In-Reply-To: <1451821505.72.0.958245773106.issue25999@psf.upfronthosting.co.za> Message-ID: <1451823366.6.0.979728062985.issue25999@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Use bin(n & (2**bitsize-1)). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 07:32:39 2016 From: report at bugs.python.org (SonokoMizuki) Date: Sun, 03 Jan 2016 12:32:39 +0000 Subject: [issue25999] Add support of native number in bin() In-Reply-To: <1451821505.72.0.958245773106.issue25999@psf.upfronthosting.co.za> Message-ID: <1451824359.5.0.0087051234433.issue25999@psf.upfronthosting.co.za> SonokoMizuki added the comment: It is nice solution. I can get negative number all right. thanks but, I feel bad that bin(-5) returns '-0b101' sorry ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 07:47:03 2016 From: report at bugs.python.org (Peter Otten) Date: Sun, 03 Jan 2016 12:47:03 +0000 Subject: [issue25999] Add support of native number in bin() In-Reply-To: <1451821505.72.0.958245773106.issue25999@psf.upfronthosting.co.za> Message-ID: <1451825223.43.0.0660459213829.issue25999@psf.upfronthosting.co.za> Peter Otten added the comment: How would you disambiguate -1 and (for example) 2**64-1 on a 64-bit machine? Python's int is not limited to a specific number of bits. ---------- nosy: +peter.otten _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 08:08:40 2016 From: report at bugs.python.org (Stefan Krah) Date: Sun, 03 Jan 2016 13:08:40 +0000 Subject: [issue22499] [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636 In-Reply-To: <1411694670.5.0.645076106925.issue22499@psf.upfronthosting.co.za> Message-ID: <1451826520.67.0.229876233306.issue22499@psf.upfronthosting.co.za> Stefan Krah added the comment: As I said in msg254389, the read/write handling for non-blocking sockets is far from trivial. I'm not sure that this is a Python bug: Looking at dugong/__init__.py, I don't think this implements the recommendations in the OpenSSL book that I mentioned. The book recommends to keep a state ... struct iostate { int read_waiton_write; int read_waiton_read; int write_waiton_write; int write_waiton_read; int can_read; int can_write; }; ... a check_availability() function that sets 'can_read', 'can_write' ... a write_allowed() function that determines whether a write is even possible to attempt ... int write_allowed(struct iostate *state) { if (state->read_waiton_write || state->read_waiton_read) return 0; if (state->can_write) return 1; if (state->can_read && state->write_waiton_read) return 1; return 0; } ... and finally, the glorious loop: while (!done) { while (check_availability(ssl, &state) == -1 || !state.can_write) nanosleep(&ts, NULL); if (write_allowed(&state)) { state.write_waiton_read = 0; state.write_waiton_write = 0; retval = SSL_write(ssl, wbuf, strlen(wbuf)); switch (SSL_get_error(ssl, retval)) { case SSL_ERROR_NONE: done = 1; break; case SSL_ERROR_ZERO_RETURN: log_sslerr(); return -1; break; case SSL_ERROR_WANT_READ: state.write_waiton_read = 1; break; case SSL_ERROR_WANT_WRITE: state.write_waiton_write = 1; break; default: log_sslerr(); break; } } } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 08:09:42 2016 From: report at bugs.python.org (SonokoMizuki) Date: Sun, 03 Jan 2016 13:09:42 +0000 Subject: [issue25999] Add support of native number in bin() In-Reply-To: <1451821505.72.0.958245773106.issue25999@psf.upfronthosting.co.za> Message-ID: <1451826582.59.0.611078055202.issue25999@psf.upfronthosting.co.za> SonokoMizuki added the comment: That's right. currently python can not distinguish positive number or negative number. >>> a = bin(-5,10) >>> int(a,2) 1019 I think reason of ambiguity is decode function( int() ). So, I suggest new decode function. (example) >>> b2i('0b1011',negative=True) -5 >>> b2i('0b1011',negative=False) 11 ( I do not know whether it is good to add special function for binary..., sorry) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 08:16:16 2016 From: report at bugs.python.org (Eryk Sun) Date: Sun, 03 Jan 2016 13:16:16 +0000 Subject: [issue25999] Add support of native number in bin() In-Reply-To: <1451821505.72.0.958245773106.issue25999@psf.upfronthosting.co.za> Message-ID: <1451826976.73.0.70254070375.issue25999@psf.upfronthosting.co.za> Eryk Sun added the comment: bin() returns a Python literal, which thankfully requires an explicit sign. 2's complement literals would be prone to human error. If you want 2's complement, you can write your own function. For example: def mybin(number, nbits=None, *, signed=True): if not signed and number < 0: raise ValueError('number must be non-negative') if nbits is None: return bin(number) bit_length = number.bit_length() if signed and number != -2 ** (bit_length - 1): bit_length += 1 if nbits < bit_length: raise ValueError('%d requres %d bits' % (number, bit_length)) number &= 2 ** nbits - 1 return format(number, '#0%db' % (nbits + 2)) >>> mybin(12) '0b1100' >>> mybin(-12) '-0b1100' >>> mybin(12, 8) '0b00001100' >>> mybin(-12, 8) '0b11110100' >>> mybin(12, 4) Traceback (most recent call last): File "", line 1, in File "", line 10, in mybin ValueError: 12 requres 5 bits Obviously when parsing a number you need to know whether it's two's complement or unsigned. >>> mybin(12, 4, signed=False) '0b1100' >>> mybin(-4, 4) '0b1100' ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 08:37:37 2016 From: report at bugs.python.org (SonokoMizuki) Date: Sun, 03 Jan 2016 13:37:37 +0000 Subject: [issue25999] Add support of native number in bin() In-Reply-To: <1451821505.72.0.958245773106.issue25999@psf.upfronthosting.co.za> Message-ID: <1451828257.69.0.969994174528.issue25999@psf.upfronthosting.co.za> SonokoMizuki added the comment: I see. I grasp to write own function is best. thanks (^-^) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 08:50:57 2016 From: report at bugs.python.org (William Bowling) Date: Sun, 03 Jan 2016 13:50:57 +0000 Subject: [issue26000] Crash in Tokenizer - Heap-use-after-free Message-ID: <1451829057.23.0.675213101615.issue26000@psf.upfronthosting.co.za> New submission from William Bowling: Similar to https://bugs.python.org/issue25388 the following causes a crash on 3.5.1 and the latest 3.5 branch: ./python -c 'with open("vuln.py", "wb") as f: f.write(b"\x61\x73\x00\x0a\x79\x6e\x63\x5c\x0a\xef")' ./python vuln.py Python 3.5.1+ (default, Jan 4 2016, 00:05:40) ================================================================= ==24400==ERROR: AddressSanitizer: heap-use-after-free on address 0xf270f100 at pc 0x080ad09e bp 0xffef5ee8 sp 0xffef5ac0 READ of size 2 at 0xf270f100 thread T0 #0 0x80ad09d in strncpy (/home/will/python/cpython/python+0x80ad09d) #1 0x8589b56 in parsetok /home/will/python/cpython/Parser/parsetok.c:235:13 #2 0x858b301 in PyParser_ParseFileObject /home/will/python/cpython/Parser/parsetok.c:134:12 #3 0x8439e0b in PyParser_ASTFromFileObject /home/will/python/cpython/Python/pythonrun.c:1150:15 #4 0x843aa37 in PyRun_FileExFlags /home/will/python/cpython/Python/pythonrun.c:916:11 #5 0x8438a98 in PyRun_SimpleFileExFlags /home/will/python/cpython/Python/pythonrun.c:396:13 #6 0x84382a6 in PyRun_AnyFileExFlags /home/will/python/cpython/Python/pythonrun.c:80:16 #7 0x813f194 in run_file /home/will/python/cpython/Modules/main.c:318:11 #8 0x813f194 in Py_Main /home/will/python/cpython/Modules/main.c:768 #9 0x8138070 in main /home/will/python/cpython/./Programs/python.c:69:11 #10 0xf7558496 in __libc_start_main (/usr/lib32/libc.so.6+0x18496) #11 0x80715b7 in _start (/home/will/python/cpython/python+0x80715b7) 0xf270f100 is located 0 bytes inside of 8194-byte region [0xf270f100,0xf2711102) freed by thread T0 here: #0 0x810c2a4 in __interceptor_cfree.localalias.1 (/home/will/python/cpython/python+0x810c2a4) #1 0x8139560 in _PyMem_RawFree /home/will/python/cpython/Objects/obmalloc.c:90:5 #2 0x813852b in PyMem_Free /home/will/python/cpython/Objects/obmalloc.c:349:5 #3 0x8596b05 in error_ret /home/will/python/cpython/Parser/tokenizer.c:198:9 #4 0x8596b05 in decoding_fgets /home/will/python/cpython/Parser/tokenizer.c:636 #5 0x8594df0 in tok_nextc /home/will/python/cpython/Parser/tokenizer.c:1016:21 #6 0x858ebba in tok_get /home/will/python/cpython/Parser/tokenizer.c:1457:13 #7 0x858fc79 in tok_get /home/will/python/cpython/Parser/tokenizer.c:1524:34 #8 0x858e1da in PyTokenizer_Get /home/will/python/cpython/Parser/tokenizer.c:1804:18 #9 0x85899a7 in parsetok /home/will/python/cpython/Parser/parsetok.c:208:16 #10 0x858b301 in PyParser_ParseFileObject /home/will/python/cpython/Parser/parsetok.c:134:12 #11 0x8439e0b in PyParser_ASTFromFileObject /home/will/python/cpython/Python/pythonrun.c:1150:15 #12 0x843aa37 in PyRun_FileExFlags /home/will/python/cpython/Python/pythonrun.c:916:11 #13 0x8438a98 in PyRun_SimpleFileExFlags /home/will/python/cpython/Python/pythonrun.c:396:13 #14 0x84382a6 in PyRun_AnyFileExFlags /home/will/python/cpython/Python/pythonrun.c:80:16 #15 0x813f194 in run_file /home/will/python/cpython/Modules/main.c:318:11 #16 0x813f194 in Py_Main /home/will/python/cpython/Modules/main.c:768 #17 0x8138070 in main /home/will/python/cpython/./Programs/python.c:69:11 #18 0xf7558496 in __libc_start_main (/usr/lib32/libc.so.6+0x18496) previously allocated by thread T0 here: #0 0x810c784 in realloc (/home/will/python/cpython/python+0x810c784) #1 0x8139541 in _PyMem_RawRealloc /home/will/python/cpython/Objects/obmalloc.c:84:12 #2 0x8138506 in PyMem_Realloc /home/will/python/cpython/Objects/obmalloc.c:343:12 #3 0x8594f1c in tok_nextc /home/will/python/cpython/Parser/tokenizer.c:1058:31 #4 0x858e4c9 in tok_get /home/will/python/cpython/Parser/tokenizer.c:1354:17 #5 0x858e1da in PyTokenizer_Get /home/will/python/cpython/Parser/tokenizer.c:1804:18 #6 0x85899a7 in parsetok /home/will/python/cpython/Parser/parsetok.c:208:16 #7 0x858b301 in PyParser_ParseFileObject /home/will/python/cpython/Parser/parsetok.c:134:12 #8 0x8439e0b in PyParser_ASTFromFileObject /home/will/python/cpython/Python/pythonrun.c:1150:15 #9 0x843aa37 in PyRun_FileExFlags /home/will/python/cpython/Python/pythonrun.c:916:11 #10 0x8438a98 in PyRun_SimpleFileExFlags /home/will/python/cpython/Python/pythonrun.c:396:13 #11 0x84382a6 in PyRun_AnyFileExFlags /home/will/python/cpython/Python/pythonrun.c:80:16 #12 0x813f194 in run_file /home/will/python/cpython/Modules/main.c:318:11 #13 0x813f194 in Py_Main /home/will/python/cpython/Modules/main.c:768 #14 0x8138070 in main /home/will/python/cpython/./Programs/python.c:69:11 #15 0xf7558496 in __libc_start_main (/usr/lib32/libc.so.6+0x18496) SUMMARY: AddressSanitizer: heap-use-after-free (/home/will/python/cpython/python+0x80ad09d) in strncpy Shadow bytes around the buggy address: 0x3e4e1dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x3e4e1de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x3e4e1df0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x3e4e1e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x3e4e1e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x3e4e1e20:[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3e4e1e30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3e4e1e40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3e4e1e50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3e4e1e60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x3e4e1e70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==24400==ABORTING ---------- components: Interpreter Core messages: 257417 nosy: William Bowling priority: normal severity: normal status: open title: Crash in Tokenizer - Heap-use-after-free type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 08:56:15 2016 From: report at bugs.python.org (Dimitri Papadopoulos Orfanos) Date: Sun, 03 Jan 2016 13:56:15 +0000 Subject: [issue26001] Tutorial: write() does not expect string in binary mode Message-ID: <1451829375.45.0.0188699168911.issue26001@psf.upfronthosting.co.za> New submission from Dimitri Papadopoulos Orfanos: About section "7.2.1. Methods of File Objects" of the tutorial: 1. Method read() is documented as follows: reads some quantity of data and returns it as a string or bytes object. Indeed read() returns a string in text mode and bytes in binary mode. For the sake of clarity, I suggest changing to: reads some quantity of data and returns it as a string (in text mode) or bytes object (in binary mode). This might seem long-winded but I believe it would help those moving from Python 2 to Python 3. 2. Method write() is documented as follows: To write something other than a string, it needs to be converted to a string first While this is correct in text mode, it is wrong in binary mode. May I suggest: To write something other than a string (in text mode) or bytes object (in binary mode), it needs to be converted first ---------- assignee: docs at python components: Documentation messages: 257418 nosy: Dimitri Papadopoulos Orfanos, docs at python priority: normal severity: normal status: open title: Tutorial: write() does not expect string in binary mode versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 09:21:58 2016 From: report at bugs.python.org (Upendra Kumar) Date: Sun, 03 Jan 2016 14:21:58 +0000 Subject: [issue26002] make statistics.median_grouped more efficient Message-ID: <1451830918.88.0.211778162331.issue26002@psf.upfronthosting.co.za> New submission from Upendra Kumar: statistics.median_grouped currently uses cf=data.index(x) to find the leftmost position of x in data ( line number 445 ). Here, data.index() has linear time complexity, which may not be good for long lists. But, here since the list 'data' is sorted beforehand, we can use binary search ( bisect_left() ) to find the leftmost occurrence of 'x' in 'data'. Similarly, for counting number of occurrence of 'x' in data after sorting, we can find the position of rightmost occurrence of 'x' in data[l1....len(data)], where l1 is position of leftmost occurrence of 'x' (line number 447 ) ---------- components: Library (Lib) files: median_grouped.patch keywords: patch messages: 257419 nosy: upendra-k14 priority: normal severity: normal status: open title: make statistics.median_grouped more efficient type: performance versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41484/median_grouped.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 09:27:26 2016 From: report at bugs.python.org (Larry Hastings) Date: Sun, 03 Jan 2016 14:27:26 +0000 Subject: [issue25999] Add support of native number in bin() In-Reply-To: <1451821505.72.0.958245773106.issue25999@psf.upfronthosting.co.za> Message-ID: <1451831246.16.0.389091946602.issue25999@psf.upfronthosting.co.za> Larry Hastings added the comment: Even if this was a good idea, it's too late to change the behavior of the builtin function. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 09:33:51 2016 From: report at bugs.python.org (SilentGhost) Date: Sun, 03 Jan 2016 14:33:51 +0000 Subject: [issue26002] make statistics.median_grouped more efficient In-Reply-To: <1451830918.88.0.211778162331.issue26002@psf.upfronthosting.co.za> Message-ID: <1451831631.31.0.452880329614.issue26002@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +steven.daprano versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 09:55:45 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 03 Jan 2016 14:55:45 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1451832945.37.0.400862269293.issue25596@psf.upfronthosting.co.za> Xavier de Gaye added the comment: os.scandir() is called recursively in the last patch and the file descriptors are not closed until returning from the recursion. The glob functions should fail explicitly when scandir() raises OSERROR with posix errno set to EMFILE (The process has too many files open), or even better, silently ignore only the PermissionError exception instead of ignoring OSERROR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 10:33:45 2016 From: report at bugs.python.org (Patrik Dufresne) Date: Sun, 03 Jan 2016 15:33:45 +0000 Subject: [issue25997] Tarfile.add with bytes path is failing In-Reply-To: <1451764405.28.0.333419880033.issue25997@psf.upfronthosting.co.za> Message-ID: <1451835225.83.0.0618697076399.issue25997@psf.upfronthosting.co.za> Patrik Dufresne added the comment: It's a bit tricky, but with help of surrogateescape I get the expected result. I'm closing this bug. Thanks ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 11:30:28 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 03 Jan 2016 16:30:28 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1451838628.95.0.489283921105.issue25596@psf.upfronthosting.co.za> Xavier de Gaye added the comment: I may be missing something, anyway here are few comments on the patch: Is the call to entry.is_symlink() in _iterdir() necessary since is_dir() follows symlinks ? If _iterdir() would yield the DirEntry instance instead of DirEntry.name, then _rlistdir() could use x.is_dir() to know whether it is correct to iterate over _rlistdir(x.path, dironly) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 11:32:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Jan 2016 16:32:52 +0000 Subject: [issue26000] Crash in Tokenizer - Heap-use-after-free In-Reply-To: <1451829057.23.0.675213101615.issue26000@psf.upfronthosting.co.za> Message-ID: <1451838772.86.0.00833772206079.issue26000@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 12:20:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Jan 2016 17:20:34 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1451841634.36.0.130925695511.issue25596@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > os.scandir() is called recursively in the last patch and the file descriptors are not closed until returning from the recursion. No, os.scandir() is called non-recursively in _iterdir(), and since _iterdir() results are always accumulated in a list, a recursion starts only after exhausting the os.scandir() iterator and closing the file descriptor. We need first to resolve issue25994 to close the file descriptor explicitly. > The glob functions should fail explicitly when scandir() raises OSERROR with posix errno set to EMFILE (The process has too many files open), or even better, silently ignore only the PermissionError exception instead of ignoring OSERROR. Patched code passes existing tests. Do you have additional tests? > Is the call to entry.is_symlink() in _iterdir() necessary since is_dir() follows symlinks ? Ah, I thought is_dir() doesn't follow symlinks. Yes, now the call to entry.is_symlink() is not necessary. > If _iterdir() would yield the DirEntry instance instead of DirEntry.name, then _rlistdir() could use x.is_dir() to know whether it is correct to iterate over _rlistdir(x.path, dironly) Yes, but this can complicate the rest of the code. _rlistdir() is called with dironly=False only when the pattern ends with '**'. I'm not sure this is enough important case for optimization. In most cases '**' is used in the middle of the pattern, and all names yielded by _iterdir() are directory names (or broken symlinks). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 14:04:26 2016 From: report at bugs.python.org (tzickel) Date: Sun, 03 Jan 2016 19:04:26 +0000 Subject: [issue26003] Issues with PyEval_InitThreads and PyGILState_Ensure Message-ID: <1451847866.91.0.926666566382.issue26003@psf.upfronthosting.co.za> New submission from tzickel: A few issues regarding threads: A. (Python 2 & 3) The documentation (https://docs.python.org/3/c-api/init.html) about initializing the GIL/Threading system does not specify that calling PyEval_InitThreads actually binds the calling thread as the main_thread in the ceval.c, meaning that the thread will be in charge till the process goes down for handling Py_AddPendingCall calls, and if it ends/dies, they won't be handled anymore. This ceval.c's main_thread is different BTW from the one in signalmodule.c which is bound to the thread that called Py_InitializeEx. Maybe there is sense for both main_thread to be the same one and initialized in the same time ? (even without a GIL existing) B. (Python 3) Besides the bad documentation regarding this, python 3.4 added issue #19576 which actually hides the call for PyEval_InitThreads inside PyGILState_Ensure. Without careful care and knowledge by the programmer, this might cause for a short lived thread created in C to actually bind the ceval.c's main_thread and when the thread dies main_thread will never be changed again. The reason this is important is beforehand, the programmer needed to think about PyEval_InitThreads now it's hidden and not even mentioned in the documentation. C. (Python 2 & 3) In PyEval_InitThreads documentation it's written "It is not safe to call this function when it is unknown which thread (if any) currently has the global interpreter lock." Thus it should be mentioned that PyGILState_Ensure is now calling it in the documentation ? Also I believe the reason this quote exists is because a potential race condition between thread A which might be running code in PyEval_EvalFrameEx (before PyEval_InitThreads is called, and thus is not GIL aware), and thread B which calls PyEval_InitThreads then calls PyGILState_Ensure, then running Python code, while thread A is still running python code as well. I think it should be explained more clearly in the documentation the implications (race condition). I think there might be a way to make an PyEval_InitThreads variant which can overcome this race condition. Basically it involves using Py_AddPendingCall to a C function which calls PyEval_InitThreads, and notifies the calling command/thread when it's done. This way we can be sure that the GIL is taken by one thread, and all the others are blocked. (maybe a signal should be sent as well, in case the main_thread is blocked on an I/O operation). D. (Python 2) If the main_thread finishes it's job, while other python threads are still alive, signal handling isn't processed anymore (Example will be added as a file). ---------- components: Interpreter Core files: signalexample.py messages: 257425 nosy: tzickel priority: normal severity: normal status: open title: Issues with PyEval_InitThreads and PyGILState_Ensure versions: Python 2.7, Python 3.6 Added file: http://bugs.python.org/file41485/signalexample.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 14:07:00 2016 From: report at bugs.python.org (tzickel) Date: Sun, 03 Jan 2016 19:07:00 +0000 Subject: [issue26003] Issues with PyEval_InitThreads and PyGILState_Ensure In-Reply-To: <1451847866.91.0.926666566382.issue26003@psf.upfronthosting.co.za> Message-ID: <1451848020.89.0.905537763806.issue26003@psf.upfronthosting.co.za> Changes by tzickel : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 14:08:17 2016 From: report at bugs.python.org (tzickel) Date: Sun, 03 Jan 2016 19:08:17 +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: <1451848097.97.0.398904358311.issue19576@psf.upfronthosting.co.za> tzickel added the comment: I think that the document regarding PyGILState_Ensure and PyEval_InitThreads should be clarified better, written in issue #26003 ---------- nosy: +tzickel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 14:20:22 2016 From: report at bugs.python.org (tzickel) Date: Sun, 03 Jan 2016 19:20:22 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1451848822.82.0.212907211823.issue25083@psf.upfronthosting.co.za> Changes by tzickel : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 16:19:48 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 03 Jan 2016 21:19:48 +0000 Subject: [issue23677] Mention dict and set comps in library reference In-Reply-To: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za> Message-ID: <1451855988.66.0.17143178365.issue23677@psf.upfronthosting.co.za> Martin Panter added the comment: The distiction about non-empty sets is a bit misleading. You can create an empty set via comprehension: >>> {x for x in ()} set() ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 16:28:19 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 03 Jan 2016 21:28:19 +0000 Subject: [issue25609] Add a ContextManager ABC and type In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za> Message-ID: <1451856499.82.0.471395821039.issue25609@psf.upfronthosting.co.za> Guido van Rossum added the comment: The abstract base class would be an ABC providing documentation and a template for implementations, and a way to test using isinstance(). This is how several other ABCs are used that have no particularly useful default implementation. In addition, the presence of the ABC provides a reference for corresponding class in the typing module (used to express type hints using PEP 484) -- again this is just following the example of the other ABCs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 16:49:55 2016 From: report at bugs.python.org (Andrew Turner) Date: Sun, 03 Jan 2016 21:49:55 +0000 Subject: [issue24520] Stop using deprecated floating-point environment functions on FreeBSD In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za> Message-ID: <1451857795.04.0.844196087286.issue24520@psf.upfronthosting.co.za> Andrew Turner added the comment: Can this be applied? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 17:00:14 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 03 Jan 2016 22:00:14 +0000 Subject: [issue25919] http.client PUT method ignores error responses sent immediatly after headers In-Reply-To: <1450729223.96.0.301570875049.issue25919@psf.upfronthosting.co.za> Message-ID: <1451858414.65.0.740437864685.issue25919@psf.upfronthosting.co.za> Martin Panter added the comment: Curl uses ?Expect: 100-continue?. This is the relevant output from it: $ curl -v -T 300mb --no-fail https://api.onedrive.com/v1.0/drives/me/root:/test.file:/content [. . .] > PUT /v1.0/drives/me/root:/test.file:/content HTTP/1.1 > Host: api.onedrive.com > Content-Range: bytes 0-314572799/314572800 > User-Agent: curl/7.43.0 > Accept: */* > Connection: TE > TE: gzip > Content-Length: 314572800 > Expect: 100-continue > < HTTP/1.1 413 Request Entity Too Large < Content-Length: 0 < Server: Microsoft-HTTPAPI/2.0 < P3P: CP="BUS CUR CONo FIN IVDo ONL OUR PHY SAMo TELo" < X-MSNSERVER: DM2302____PAP179 < Strict-Transport-Security: max-age=31536000; includeSubDomains < X-ThrowSite: 7c11.e25d < Date: Sun, 03 Jan 2016 20:04:27 GMT * HTTP error before end of send, stop sending < * Closing connection 0 See Issue 1346874 about support for 100-continue mode. When I tried your test code on Linux, it hung for two minutes, and then raised ConnectionResetError. I guess the server refused to receive data, and then timed the connection out. The patch should handle this in most cases, but I think there could still a race between select() returning an empty rlist, and then the server sending a request and causing the upload to hang. Also, there is nothing to protect from sendall() partially uploading a chunk, and then hanging. It should be more robust to check for both send and receive sides of the socket with select(), and only use send(), not sendall(), to avoid blocking. I would consider this a new feature, so I don?t think it should go into 3.5. It would be good to add documentation and test cases as well. Wiktor?s problem is similar to the situations in Issue 5542. There, the original poster seemed happy to wait for a broken pipe error, and then inspect a 401 Unauthorized response. This apparently was made to work with plain HTTP over TCP, but not HTTPS. I wonder if having request() silently return is the best API design. Is there a possibility that the caller would want to distinguish a successful upload from an aborted one? I can?t think of one, but it seems plausible. Another related enhancement I would like is the ability to detect an error response (e.g. 408 Request Timeout) or dropped connection _before_ even sending a request. This is useful with persistent connections; see items 1 and 2 in . ---------- nosy: +martin.panter stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 17:45:35 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 03 Jan 2016 22:45:35 +0000 Subject: [issue25919] http.client PUT method ignores error responses sent immediatly after headers In-Reply-To: <1450729223.96.0.301570875049.issue25919@psf.upfronthosting.co.za> Message-ID: <1451861135.08.0.543690479768.issue25919@psf.upfronthosting.co.za> Martin Panter added the comment: For non-blocking SSL sockets, the Python documentation suggests the results of select() do not directly indicate if data can be sent or received: . I guess this would also apply to blocking SSL sockets. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 18:51:24 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 23:51:24 +0000 Subject: [issue24612] not operator expression raising a syntax error In-Reply-To: <1436628233.38.0.197597566636.issue24612@psf.upfronthosting.co.za> Message-ID: <1451865084.53.0.133101762767.issue24612@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 18:55:20 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 23:55:20 +0000 Subject: [issue24632] Improve documentation about __main__.py In-Reply-To: <1436856841.67.0.538500952598.issue24632@psf.upfronthosting.co.za> Message-ID: <1451865320.66.0.915201335852.issue24632@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ncoghlan versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 19:03:50 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 00:03:50 +0000 Subject: [issue24715] Sorting HOW TO: bad example for reverse sort stability In-Reply-To: <1437817871.39.0.0442628081402.issue24715@psf.upfronthosting.co.za> Message-ID: <1451865830.33.0.0654543705083.issue24715@psf.upfronthosting.co.za> Ezio Melotti added the comment: LGTM, however I would also show the sorted output too. ---------- nosy: +ezio.melotti stage: -> commit review type: -> enhancement versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 19:04:33 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 00:04:33 +0000 Subject: [issue24733] Logically Dead Code In-Reply-To: <1437991750.04.0.826367640936.issue24733@psf.upfronthosting.co.za> Message-ID: <1451865873.96.0.073301525755.issue24733@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 19:06:50 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 00:06:50 +0000 Subject: [issue24780] unittest assertEqual difference output foiled by newlines In-Reply-To: <1438534169.3.0.814109265012.issue24780@psf.upfronthosting.co.za> Message-ID: <1451866010.21.0.0853339680866.issue24780@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti, michael.foord, rbcollins stage: -> test needed versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 19:13:33 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 00:13:33 +0000 Subject: [issue24896] It is undocumented that re.UNICODE affects re.IGNORECASE In-Reply-To: <1439987891.31.0.547960058443.issue24896@psf.upfronthosting.co.za> Message-ID: <1451866413.72.0.763762321097.issue24896@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett stage: -> needs patch type: -> enhancement versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 19:14:06 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 00:14:06 +0000 Subject: [issue24898] Documentation for str.find() is confusing In-Reply-To: <1440038088.25.0.955584919768.issue24898@psf.upfronthosting.co.za> Message-ID: <1451866446.07.0.54569501195.issue24898@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy stage: -> needs patch type: -> enhancement versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 19:15:47 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 00:15:47 +0000 Subject: [issue24918] Docs layout bug In-Reply-To: <1440361207.71.0.0873906255469.issue24918@psf.upfronthosting.co.za> Message-ID: <1451866547.21.0.946196425619.issue24918@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 19:16:40 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 00:16:40 +0000 Subject: [issue24922] assertWarnsRegex doesn't allow multiple warning messages In-Reply-To: <1440425748.63.0.780438690591.issue24922@psf.upfronthosting.co.za> Message-ID: <1451866600.81.0.814709410126.issue24922@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, michael.foord, rbcollins stage: -> needs patch versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 19:18:15 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 00:18:15 +0000 Subject: [issue24959] unittest swallows part of stack trace when raising AssertionError in a TestCase In-Reply-To: <1440864914.24.0.799928607113.issue24959@psf.upfronthosting.co.za> Message-ID: <1451866695.64.0.287757707259.issue24959@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, michael.foord, rbcollins versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 19:56:48 2016 From: report at bugs.python.org (SonokoMizuki) Date: Mon, 04 Jan 2016 00:56:48 +0000 Subject: [issue25999] Add support of negative number in bin() In-Reply-To: <1451821505.72.0.958245773106.issue25999@psf.upfronthosting.co.za> Message-ID: <1451869008.55.0.101375504398.issue25999@psf.upfronthosting.co.za> Changes by SonokoMizuki : ---------- title: Add support of native number in bin() -> Add support of negative number in bin() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 21:00:42 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 04 Jan 2016 02:00:42 +0000 Subject: [issue24898] Documentation for str.find() is confusing In-Reply-To: <1440038088.25.0.955584919768.issue24898@psf.upfronthosting.co.za> Message-ID: <20160104020039.9620.63037@psf.io> Roundup Robot added the comment: New changeset 7150e8a38c63 by Senthil Kumaran in branch '3.4': Issue24898 - Improve str.find documentation. https://hg.python.org/cpython/rev/7150e8a38c63 New changeset 164b564e3c1a by Senthil Kumaran in branch '3.5': merge from 3.4 https://hg.python.org/cpython/rev/164b564e3c1a New changeset 136adbcefa5f by Senthil Kumaran in branch 'default': merge from 3.5 https://hg.python.org/cpython/rev/136adbcefa5f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 21:07:17 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 04 Jan 2016 02:07:17 +0000 Subject: [issue24898] Documentation for str.find() is confusing In-Reply-To: <1440038088.25.0.955584919768.issue24898@psf.upfronthosting.co.za> Message-ID: <20160104020713.124866.38477@psf.io> Roundup Robot added the comment: New changeset da934a19855b by Senthil Kumaran in branch '2.7': Backport documentation improvement. https://hg.python.org/cpython/rev/da934a19855b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 21:08:31 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 04 Jan 2016 02:08:31 +0000 Subject: [issue24898] Documentation for str.find() is confusing In-Reply-To: <1440038088.25.0.955584919768.issue24898@psf.upfronthosting.co.za> Message-ID: <1451873311.65.0.752781903281.issue24898@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Updated the docs as per Georg's suggestion. Thank you Ted Lemon for bringing this up. ---------- assignee: docs at python -> orsenthil nosy: +orsenthil resolution: -> fixed stage: needs patch -> resolved status: open -> closed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 21:13:59 2016 From: report at bugs.python.org (Upendra Kumar) Date: Mon, 04 Jan 2016 02:13:59 +0000 Subject: [issue26001] Tutorial: write() does not expect string in binary mode In-Reply-To: <1451829375.45.0.0188699168911.issue26001@psf.upfronthosting.co.za> Message-ID: <1451873639.2.0.830589775297.issue26001@psf.upfronthosting.co.za> Upendra Kumar added the comment: I also think that for better clarification, binary mode and text mode should be specified clearly for both methods read() and write(). For read(), I have changed it to: ' some quantity of data and returns it as a string (in text mode) or bytes object (in binary mode).' For write(), I have changed it to: ' To write something other than a string (in text mode) or bytes object (in binary mode), it needs to be converted first to string or bytes object respectively. ' Please if someone could review it, as I have not submitted a patch related to docs before. And I am not sure, if I have made correct changes at right place. ---------- keywords: +patch nosy: +upendra-k14 Added file: http://bugs.python.org/file41486/fileiotutorial.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 21:40:13 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 04 Jan 2016 02:40:13 +0000 Subject: [issue25641] urllib/request.py/getproxies_environment() throws "dictionary changed size during iteration" error occasionally In-Reply-To: <1447713968.83.0.231956831244.issue25641@psf.upfronthosting.co.za> Message-ID: <1451875213.75.0.696612628345.issue25641@psf.upfronthosting.co.za> Senthil Kumaran added the comment: os.environ is never changed by getproxies_environment() Like Martin Panter, I will curious to know as how the user experienced this issue in the place. @Raymond Hettinger: If the dict is only read and never modified in the fuction, does it still make sense to have a defensive list() as you suggested? If yes, then there will be couple of places in the stdlib code that will need this change. ``` $ ag os.environ.items Lib Lib/distutils/_msvccompiler.py 80: for key, value in os.environ.items() Lib/test/test_os.py 679: for key, val in os.environ.items(): Lib/test/test_wsgiref.py 427: os_environ = dict(os.environ.items()) Lib/urllib/request.py 2453: for name, value in os.environ.items(): Lib/wsgiref/handlers.py 47: for k, v in os.environ.items(): ``` My understanding is, if the function is not manipulation and only reading the dictionary, a defensive list or copy is not required. And, this bug report should be closed. ---------- nosy: +orsenthil status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 21:42:34 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 04 Jan 2016 02:42:34 +0000 Subject: [issue8728] 2.7 regression in httplib.py: AttributeError: 'NoneType' object has no attribute 'makefile' In-Reply-To: <1273960882.3.0.07398568579.issue8728@psf.upfronthosting.co.za> Message-ID: <1451875354.46.0.101938006898.issue8728@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Closing this since no further update was available from the original reporter. If this bug is still present, please open a new issue with test case to reproduce. ---------- nosy: +orsenthil resolution: -> not a bug stage: -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:02:20 2016 From: report at bugs.python.org (William Bowling) Date: Mon, 04 Jan 2016 03:02:20 +0000 Subject: [issue26000] Crash in Tokenizer - Heap-use-after-free In-Reply-To: <1451829057.23.0.675213101615.issue26000@psf.upfronthosting.co.za> Message-ID: <1451876540.89.0.967511214892.issue26000@psf.upfronthosting.co.za> William Bowling added the comment: Also a very similar source causes a slightly different crash (heap-buffer-overflow instead of heap-use-after-free): ./python -c 'with open("vuln2.py", "wb") as f: f.write(b"\x61\x73\x00\x0a\x79\x6e\x63\x5c\x0a\x00\x0d\xdd")' ./python vuln2.py Python 3.5.1+ (default, Jan 4 2016, 00:05:40) Attached the asan report ---------- Added file: http://bugs.python.org/file41487/asan2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:23:41 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:23:41 +0000 Subject: [issue25179] PEP 498 f-strings need to be documented In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za> Message-ID: <1451877821.51.0.464240997366.issue25179@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:25:32 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:25:32 +0000 Subject: [issue25197] Allow documentation switcher to change url to /3/ and /dev/ In-Reply-To: <1442780092.62.0.798906880968.issue25197@psf.upfronthosting.co.za> Message-ID: <1451877932.97.0.980909228068.issue25197@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, georg.brandl stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:30:52 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:30:52 +0000 Subject: [issue25282] regex: Support for recursive patterns In-Reply-To: <1443628033.35.0.583237537087.issue25282@psf.upfronthosting.co.za> Message-ID: <1451878252.56.0.701429230344.issue25282@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:34:18 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:34:18 +0000 Subject: [issue25347] assert_has_calls output is formatted inconsistently In-Reply-To: <1444342123.9.0.512399656595.issue25347@psf.upfronthosting.co.za> Message-ID: <1451878458.85.0.629115706756.issue25347@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:36:12 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:36:12 +0000 Subject: [issue25381] Doc: Use of old description of raise in Python3 In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za> Message-ID: <1451878572.58.0.881010078361.issue25381@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti type: -> enhancement versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:37:01 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:37:01 +0000 Subject: [issue25403] urllib.parse.urljoin is broken in python 3.5 In-Reply-To: <1444823340.35.0.0533245258476.issue25403@psf.upfronthosting.co.za> Message-ID: <1451878621.41.0.751841402596.issue25403@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:40:17 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:40:17 +0000 Subject: [issue25423] Deprecate benchmarks that execute too quickly In-Reply-To: <1445016719.35.0.429724365495.issue25423@psf.upfronthosting.co.za> Message-ID: <1451878817.12.0.912584364881.issue25423@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:41:04 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:41:04 +0000 Subject: [issue25433] whitespace in strip()/lstrip()/rstrip() In-Reply-To: <1445170536.34.0.94220475409.issue25433@psf.upfronthosting.co.za> Message-ID: <1451878864.55.0.89348856594.issue25433@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti stage: -> needs patch versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:42:46 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:42:46 +0000 Subject: [issue25517] regex howto example in "Lookahead Assertions" In-Reply-To: <1446199646.71.0.249231376897.issue25517@psf.upfronthosting.co.za> Message-ID: <1451878966.98.0.342987582922.issue25517@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:45:13 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:45:13 +0000 Subject: [issue25547] Improve repr for files to show whether the file is open or closed. In-Reply-To: <1446572940.81.0.863832720658.issue25547@psf.upfronthosting.co.za> Message-ID: <1451879113.86.0.855259968398.issue25547@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- resolution: -> not a bug stage: needs patch -> resolved status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:52:01 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:52:01 +0000 Subject: [issue25743] Clarify exactly what \w matches in UNICODE mode In-Reply-To: <1448639458.78.0.12264064003.issue25743@psf.upfronthosting.co.za> Message-ID: <1451879521.56.0.304128121011.issue25743@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett stage: -> needs patch type: -> enhancement versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:55:57 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:55:57 +0000 Subject: [issue25810] Python 3 documentation for eval is incorrect In-Reply-To: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za> Message-ID: <1451879757.42.0.819252092718.issue25810@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti type: -> enhancement versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:56:32 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:56:32 +0000 Subject: [issue25866] Reference 3. Data Model: miscellaneous minor cleanups on the word "sequence". In-Reply-To: <1450167167.45.0.614001159878.issue25866@psf.upfronthosting.co.za> Message-ID: <1451879792.45.0.102789199432.issue25866@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti stage: -> needs patch versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 23:55:59 2016 From: report at bugs.python.org (Kushal Das) Date: Mon, 04 Jan 2016 04:55:59 +0000 Subject: [issue19006] UnitTest docs should have a single list of assertions In-Reply-To: <1378914335.13.0.0543263347661.issue19006@psf.upfronthosting.co.za> Message-ID: <1451883359.57.0.196616457754.issue19006@psf.upfronthosting.co.za> Kushal Das added the comment: The patch looks good to me. Commit :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 00:07:00 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 04 Jan 2016 05:07:00 +0000 Subject: [issue24733] Logically Dead Code In-Reply-To: <1437991750.04.0.826367640936.issue24733@psf.upfronthosting.co.za> Message-ID: <1451884020.82.0.599262826517.issue24733@psf.upfronthosting.co.za> Martin Panter added the comment: This looks like some leftover cruft after refactoring the code: . Removing it looks fine to me. This does not seem to be applicable to Python 3. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 00:52:02 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 04 Jan 2016 05:52:02 +0000 Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL certificate In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za> Message-ID: <1451886722.6.0.494024603706.issue25940@psf.upfronthosting.co.za> Martin Panter added the comment: Assuming it is practical, would it be appropriate to convert the failing tests to connect to a local server running in a background Python thread? Perhaps using the existing ThreadedEchoServer. That way the tests wouldn?t require an internet connection, and the certificates used etc should be all contained within the Python source tree. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 02:43:07 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 04 Jan 2016 07:43:07 +0000 Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL certificate In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za> Message-ID: <1451893387.8.0.980729541102.issue25940@psf.upfronthosting.co.za> Martin Panter added the comment: In the meantime, this patch changes the tests to use the new DST root certificate. This seems to be the minimum to make the tests pass again, but someone else should probably review it because I?m not too experienced with SSL certificate stuff. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file41488/svn-cert.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 03:25:09 2016 From: report at bugs.python.org (koobs) Date: Mon, 04 Jan 2016 08:25:09 +0000 Subject: [issue20397] distutils --record option does not validate existence of byte-compiled files In-Reply-To: <1390746014.88.0.900467086198.issue20397@psf.upfronthosting.co.za> Message-ID: <1451895909.18.0.139889322487.issue20397@psf.upfronthosting.co.za> Changes by koobs : ---------- keywords: +easy versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 03:26:30 2016 From: report at bugs.python.org (koobs) Date: Mon, 04 Jan 2016 08:26:30 +0000 Subject: [issue20397] distutils --record option does not validate existence of byte-compiled files In-Reply-To: <1390746014.88.0.900467086198.issue20397@psf.upfronthosting.co.za> Message-ID: <1451895990.75.0.605025341969.issue20397@psf.upfronthosting.co.za> koobs added the comment: setuptools and therefore pip are also affected by this ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 03:45:06 2016 From: report at bugs.python.org (Debashish Maity) Date: Mon, 04 Jan 2016 08:45:06 +0000 Subject: [issue26004] pip install lifetimes - throwing error and unable to install packages Message-ID: <1451897106.72.0.251427221401.issue26004@psf.upfronthosting.co.za> New submission from Debashish Maity: Not able to install "lifetimes" package using pip script. Need urgent help. Followed the following links for help, but still no success http://blog.ionelmc.ro/2014/12/21/compiling-python-extensions-on-windows/ http://stackoverflow.com/questions/26473854/python-pip-has-issues-with-path-for-ms-visual-studio-2010-express-for-64-bit-ins/26513378#26513378 ---------- components: Windows files: log.txt messages: 257445 nosy: dudestc, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: pip install lifetimes - throwing error and unable to install packages type: compile error versions: Python 3.5 Added file: http://bugs.python.org/file41489/log.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 03:54:10 2016 From: report at bugs.python.org (Richard Clifford) Date: Mon, 04 Jan 2016 08:54:10 +0000 Subject: [issue26005] Denial of Service in SimpleHTTPServer and BaseHTTPServer Message-ID: <1451897650.58.0.64883073344.issue26005@psf.upfronthosting.co.za> New submission from Richard Clifford: The issue comes when there is a malformed HTTP request not ending in a new line, it causes the server to hang, not timeout and causes a DoS. The request that I sent to the server was as follows: const char *headers = "GET / HTTP/1.1\r\nHost: localhost:8000\r\n"; Which should have been: const char *headers = "GET / HTTP/1.1\r\nHost: localhost:8000\r\n\r\n"; This causes a the application to await the second set of new-line sequences and hang until they are received which prevents any further connections from being made. I have just tested this against the latest versions of the library and I can supply a proof of concept code if that would be useful - just let me know. A recommended fix would be to ensure that all HTTP requests are received in full and in the correct manor prior to being parsed. ---------- components: Extension Modules files: basehttpdos.c messages: 257446 nosy: Richard Clifford priority: normal severity: normal status: open title: Denial of Service in SimpleHTTPServer and BaseHTTPServer type: security versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41490/basehttpdos.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 04:28:06 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 04 Jan 2016 09:28:06 +0000 Subject: [issue26005] Denial of Service in SimpleHTTPServer and BaseHTTPServer In-Reply-To: <1451897650.58.0.64883073344.issue26005@psf.upfronthosting.co.za> Message-ID: <1451899686.4.0.92026933085.issue26005@psf.upfronthosting.co.za> Martin Panter added the comment: I expect the server _is_ waiting for the end of the headers before handling the response. The problem is if you do not send the blank line, the server cannot know if you have ended the headers or if there are more to come. Perhaps you could set a socket timeout in the server. But an attacker could still send little bits of the header very slowly (called Slow Loris attack or something I think). I think a server robust against that sort of stuff would be out of scope for SimpleHTTPServer. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 04:35:07 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Jan 2016 09:35:07 +0000 Subject: [issue26005] Denial of Service in SimpleHTTPServer and BaseHTTPServer In-Reply-To: <1451897650.58.0.64883073344.issue26005@psf.upfronthosting.co.za> Message-ID: <1451900107.38.0.437340106496.issue26005@psf.upfronthosting.co.za> STINNER Victor added the comment: "I think a server robust against that sort of stuff would be out of scope for SimpleHTTPServer." We can probably enhance SimpleHTTPServer but I agree that the server should remain simple. Maybe we should be more explicit in the documentation that the server requires to trust users? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 04:42:13 2016 From: report at bugs.python.org (Dimitri Papadopoulos Orfanos) Date: Mon, 04 Jan 2016 09:42:13 +0000 Subject: [issue25433] whitespace in strip()/lstrip()/rstrip() In-Reply-To: <1445170536.34.0.94220475409.issue25433@psf.upfronthosting.co.za> Message-ID: <1451900533.26.0.027212012044.issue25433@psf.upfronthosting.co.za> Dimitri Papadopoulos Orfanos added the comment: In Python 2, as far as I can understand, string.whitespace and str.isspace() are different: * str.isspace() is built upon the C isspace() function and is therefore locale-dependant. Python heavily relies on isspace() to detect "whitespace" characters. * string.whitespace is a list of "ASCII whitespace characters" carved in stone. As far as I can see string.whitespace is defined but not used anywhere in Python source code. See source code: * Modules/stringobject.c around line 3319: [...] string_isspace(PyStringObject *self) { [...] e = p + PyString_GET_SIZE(self); for (; p < e; p++) { if (!isspace(*p)) return PyBool_FromLong(0); } return PyBool_FromLong(1); [...] * Lib/string.py near line 23: whitespace = ' \t\n\r\v\f' Functions strip()/lstrip()/rstrip() use str.isspace() and have nothing to do with string.whitespace: * Modules/stringobject.c around line 1861: [...] do_strip(PyStringObject *self, int striptype) { [...] i = 0; if (striptype != RIGHTSTRIP) { while (i < len && isspace(Py_CHARMASK(s[i]))) { i++; } } [...] Therefore I suggest the documentation of Python 2.7 points to str.isspace() wherever the term "whitespace" is used in the documentation - including this specific case of strip()/lstrip()/rstrip(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 05:06:11 2016 From: report at bugs.python.org (Dimitri Papadopoulos Orfanos) Date: Mon, 04 Jan 2016 10:06:11 +0000 Subject: [issue25433] whitespace in strip()/lstrip()/rstrip() In-Reply-To: <1445170536.34.0.94220475409.issue25433@psf.upfronthosting.co.za> Message-ID: <1451901971.2.0.716238404036.issue25433@psf.upfronthosting.co.za> Dimitri Papadopoulos Orfanos added the comment: In Python 3 the situation is similar: * The Py_UNICODE_ISSPACE macro is used internally to define str.isspace() and wherever Python needs to detect "whitespace" characters in strings. * There is an equivalent function Py_ISSPACE for bytes/bytearray. * The bytearray.strip() implementation for bytearray relies on hardcoded ASCII whitespaces instead of Py_ISSPACE. * string.whitespace is a list of "ASCII whitespace characters" carved in stone. As far as I can see string.whitespace is defined but not used anywhere in Python source code. Therefore I suggest the documentation of Python 3 points to str.isspace() wherever the term "whitespace" is used in any documentation related to strings - including this specific case of strip()/lstrip()/rstrip(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 05:14:57 2016 From: report at bugs.python.org (Thomas Arildsen) Date: Mon, 04 Jan 2016 10:14:57 +0000 Subject: [issue24313] json fails to serialise numpy.int64 In-Reply-To: <1432801951.51.0.0124262456045.issue24313@psf.upfronthosting.co.za> Message-ID: <1451902497.3.0.422517526004.issue24313@psf.upfronthosting.co.za> Thomas Arildsen added the comment: Is there any possibility that json could implement special handling of NumPy types? This "lack of a feature" seems to have propagated back into Python 2.7 now in some recent update... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 05:32:06 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 04 Jan 2016 10:32:06 +0000 Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL certificate In-Reply-To: <1451893387.8.0.980729541102.issue25940@psf.upfronthosting.co.za> Message-ID: <568A4A22.8030503@egenix.com> Marc-Andre Lemburg added the comment: On 04.01.2016 08:43, Martin Panter wrote: > > In the meantime, this patch changes the tests to use the new DST root certificate. This seems to be the minimum to make the tests pass again, but someone else should probably review it because I?m not too experienced with SSL certificate stuff. Thanks. I still think that we should use a more stable resource for this other than svn.python.org, e.g. the https://www.pythontest.net/ setup which was created specifically for stdlib tests and which can more easily be adapted to fit the needs of the tests than a public resource which is meant for other purposes. The local server idea may also work, but would have to run on a non-privileged port. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 05:43:39 2016 From: report at bugs.python.org (koobs) Date: Mon, 04 Jan 2016 10:43:39 +0000 Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL certificate In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za> Message-ID: <1451904219.39.0.93129687531.issue25940@psf.upfronthosting.co.za> koobs added the comment: Can't / Shouldn't these be mocked? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 05:57:27 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 04 Jan 2016 10:57:27 +0000 Subject: [issue24036] GB2312 codec is using a wrong covert table In-Reply-To: <1429781381.54.0.113233811407.issue24036@psf.upfronthosting.co.za> Message-ID: <1451905047.3.0.35683440498.issue24036@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I think we can close this issue as "won't fix". It's a bug, but one which is present in a lot of other systems as well, so we'd potentially make it impossible to write GB2312 data which is supposed to be read back by these other systems. Ma Lin: Do you agree ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 06:20:23 2016 From: report at bugs.python.org (Nathaniel Smith) Date: Mon, 04 Jan 2016 11:20:23 +0000 Subject: [issue24313] json fails to serialise numpy.int64 In-Reply-To: <1432801951.51.0.0124262456045.issue24313@psf.upfronthosting.co.za> Message-ID: <1451906423.95.0.535709328822.issue24313@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Nothing's changed in python 2.7. Basically: (a) no numpy ints have ever serialized in py3. (b) in py2, either np.int32 *xor* np.int64 will serialize correctly, and which one it is depends on sizeof(long) in the C compiler used to build Python. (This follows from the fact that in py2, the Python 'int' type is always the same size as C 'long'.) So the end result is: on OS X and Linux, 32-bit Pythons can JSON-serialize np.int32 objects, and 64-bit Pythons can JSON-serialize np.int64 objects, because 64-bit OS X and Linux is ILP64. On Windows, both 32- and 64-bit Pythons can JSON-serialize np.int32 objects, and can't serialize np.int64 objects, because 64-bit Windows is LLP64. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 06:20:36 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 04 Jan 2016 11:20:36 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1451906436.08.0.268129357539.issue25596@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > and since _iterdir() results are always accumulated in a list Right, I failed to note that point. And so, since the file descriptor opened by os.scandir() is closed within each call to recursive _rlistdir(), then my other comment about EMFILE does not stand as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 06:30:55 2016 From: report at bugs.python.org (Ma Lin) Date: Mon, 04 Jan 2016 11:30:55 +0000 Subject: [issue24036] GB2312 codec is using a wrong covert table In-Reply-To: <1429781381.54.0.113233811407.issue24036@psf.upfronthosting.co.za> Message-ID: <1451907055.58.0.357144118351.issue24036@psf.upfronthosting.co.za> Ma Lin added the comment: I agree with you, "won't fix". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 06:37:52 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 04 Jan 2016 11:37:52 +0000 Subject: [issue24036] GB2312 codec is using a wrong covert table In-Reply-To: <1429781381.54.0.113233811407.issue24036@psf.upfronthosting.co.za> Message-ID: <1451907472.72.0.106779954645.issue24036@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Thanks, Ma Lin. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 06:44:21 2016 From: report at bugs.python.org (Thomas Arildsen) Date: Mon, 04 Jan 2016 11:44:21 +0000 Subject: [issue24313] json fails to serialise numpy.int64 In-Reply-To: <1432801951.51.0.0124262456045.issue24313@psf.upfronthosting.co.za> Message-ID: <1451907861.68.0.873878535753.issue24313@psf.upfronthosting.co.za> Thomas Arildsen added the comment: Thanks for the clarification. ---------- versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 06:56:45 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Jan 2016 11:56:45 +0000 Subject: [issue17394] Add slicing support to collections.deque In-Reply-To: <1362972021.66.0.443403979058.issue17394@psf.upfronthosting.co.za> Message-ID: <1451908605.94.0.216036283398.issue17394@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch implements getting, deleting and setting slices in deque. Getting a slice returns a list, but this can be changed if needed. ---------- assignee: -> rhettinger keywords: +patch stage: needs patch -> patch review versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file41491/deque_slices.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 07:06:49 2016 From: report at bugs.python.org (Artur Korobeynyk) Date: Mon, 04 Jan 2016 12:06:49 +0000 Subject: [issue26006] 32 bits python ctypes creates 64 bits process from 32 bits executable Message-ID: <1451909209.14.0.184769502954.issue26006@psf.upfronthosting.co.za> New submission from Artur Korobeynyk: Hi, I have a 32 bits python on 64 bits Windows and 32 bits executable (compiled from native C). When I do kernel32.CreateProcessA(path_to_exe, ...) python creates a process which is 64 bit (ctypes IsWow64Process returns true). I expect it to be 32 as well. Am I wrong or that is a bug? I attached testprog.exe but it requires testdll.dll The sources of testprog.c: #include #include int main() { Sleep(15000); printf("%d", testSum(5,10)); return 0; } testdll.c #include __declspec(dllexport) int __cdecl testSum(int a, int b) { return(a+b); } compiled as: /usr/bin/i686-pc-mingw32-gcc.exe -c testdll.c /usr/bin/i686-pc-mingw32-gcc.exe --shared -o testdll.dll testdll.o /usr/bin/i686-pc-mingw32-gcc.exe -o testprog testprog.c -L. -ltestdll Process creation: if kernel32.CreateProcessA(path_to_exe, None, None, None, None, creation_flags, None, None, byref(startupinfo), byref(process_information)) ---------- components: ctypes files: testprog.exe messages: 257461 nosy: Artur Korobeynyk priority: normal severity: normal status: open title: 32 bits python ctypes creates 64 bits process from 32 bits executable versions: Python 2.7 Added file: http://bugs.python.org/file41492/testprog.exe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 07:55:29 2016 From: report at bugs.python.org (Artur Korobeynyk) Date: Mon, 04 Jan 2016 12:55:29 +0000 Subject: [issue26006] 32 bits python ctypes creates 64 bits process from 32 bits executable In-Reply-To: <1451909209.14.0.184769502954.issue26006@psf.upfronthosting.co.za> Message-ID: <1451912129.09.0.496252446428.issue26006@psf.upfronthosting.co.za> Artur Korobeynyk added the comment: the Wow64Process output parameter is true for a 32-bit process. WOW64 is short for Win32 running on Win64 (i.e. the environment used to run 32-bit programs in 64-bit Windows). Even a 32-bit WOW64 process has some 64-bit modules, such as ntdll.dll, wow64.dll, wow64win.dll, and wow64cpu.dll ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 10:19:39 2016 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 04 Jan 2016 15:19:39 +0000 Subject: [issue25702] Link Time Optimizations support for GCC and CLANG In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za> Message-ID: <1451920779.85.0.205509510046.issue25702@psf.upfronthosting.co.za> Alecsandru Patrascu added the comment: Hello, I've added an updated set of patches (v03) for the current CPython2 and CPython3 codebase. Also made some small changes to reduce the number of places where the flags are set. ---------- Added file: http://bugs.python.org/file41493/lto-cpython2-v03.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 10:19:46 2016 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 04 Jan 2016 15:19:46 +0000 Subject: [issue25702] Link Time Optimizations support for GCC and CLANG In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za> Message-ID: <1451920786.46.0.467020251065.issue25702@psf.upfronthosting.co.za> Changes by Alecsandru Patrascu : Added file: http://bugs.python.org/file41494/lto-cpython3-v03.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 11:13:13 2016 From: report at bugs.python.org (Phil Thompson) Date: Mon, 04 Jan 2016 16:13:13 +0000 Subject: [issue26007] Request for Support for Embedding the Standard Library in an Executable Message-ID: <1451923993.52.0.708853061063.issue26007@psf.upfronthosting.co.za> New submission from Phil Thompson: The use case is a packaging tool that can create a single executable for a Python application. Like similar tools it embeds frozen Python code (including the standard library) and is linked (often statically) against the interpreter library. Executables are usually configured so that they cannot import packages from the filesystem. They can only import packages embedded in the executable. This is done directly, ie. the package is not written out to the filesystem and imported from there. This is done by a specially written importer. The importer is installed by adding it to sys.path_hooks. However this must be done early on in the bootstrap process so that the parts of the standard library that are implemented as Python packages can be found by the installer. For example, the point at which the zipimport importer is added to sys.path_hooks is too late. Currently a modified version of bootstrap_external.py is embedded in the executable which updates sys.path_hooks at the end of the _install() function. What I would like is some way to avoid having to modify bootstrap_external.py to install a new importer sufficiently early in the bootstrap process to allow it to import the standard library. ---------- components: Interpreter Core messages: 257464 nosy: philthompson10 priority: normal severity: normal status: open title: Request for Support for Embedding the Standard Library in an Executable type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 11:13:56 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Jan 2016 16:13:56 +0000 Subject: [issue17394] Add slicing support to collections.deque In-Reply-To: <1362972021.66.0.443403979058.issue17394@psf.upfronthosting.co.za> Message-ID: <1451924036.12.0.562892531581.issue17394@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file41491/deque_slices.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 11:14:10 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Jan 2016 16:14:10 +0000 Subject: [issue17394] Add slicing support to collections.deque In-Reply-To: <1362972021.66.0.443403979058.issue17394@psf.upfronthosting.co.za> Message-ID: <1451924050.7.0.189196087474.issue17394@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file41495/deque_slices.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 11:23:06 2016 From: report at bugs.python.org (Paul Moore) Date: Mon, 04 Jan 2016 16:23:06 +0000 Subject: [issue26007] Request for Support for Embedding the Standard Library in an Executable In-Reply-To: <1451923993.52.0.708853061063.issue26007@psf.upfronthosting.co.za> Message-ID: <1451924586.2.0.563070009757.issue26007@psf.upfronthosting.co.za> Paul Moore added the comment: Why is it too late to install a new importer to sys.path_hooks when zipimport is installed? As far as I am aware, running the stdlib from a zipfile works fine, which seems to be equivalent to your use case. ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 11:50:52 2016 From: report at bugs.python.org (Phil Thompson) Date: Mon, 04 Jan 2016 16:50:52 +0000 Subject: [issue26007] Request for Support for Embedding the Standard Library in an Executable In-Reply-To: <1451923993.52.0.708853061063.issue26007@psf.upfronthosting.co.za> Message-ID: <1451926252.5.0.744629647287.issue26007@psf.upfronthosting.co.za> Phil Thompson added the comment: The problem is the import of the encodings module in _PyCodecRegistry_Init(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 11:51:45 2016 From: report at bugs.python.org (Lasse Schuirmann) Date: Mon, 04 Jan 2016 16:51:45 +0000 Subject: [issue25998] doctest crashes when accessing __wrapped__ fails other than AttributeError In-Reply-To: <1451773843.64.0.986014558431.issue25998@psf.upfronthosting.co.za> Message-ID: <1451926305.32.0.940535466175.issue25998@psf.upfronthosting.co.za> Lasse Schuirmann added the comment: Sorry for giving it the wrong category. I personally think both projects should solve this. IMO it would be nice if doctest is robust against modules that for some reason (be they ill designed or not; I guess if you search a lot you find a project that needs to raise a custom exception when accessing `__wrapped__`). At the same time I do think the Flask request object could handle this better but lack the ability to explain that to them with substantial reasoning. The problem is that both of you don't want to solve this problem at their side, @steven.daprano, would you mind speaking with the Flask people directly? I'm not affiliated to them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 11:51:53 2016 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 04 Jan 2016 16:51:53 +0000 Subject: [issue17006] Add advice on best practices for hashing secrets In-Reply-To: <1451618657.96.0.304750754668.issue17006@psf.upfronthosting.co.za> Message-ID: Ramchandra Apte added the comment: It is good to add warnings; if they are ignored it is little worse than the status quo. On 1 January 2016 at 08:54, Ezio Melotti wrote: > > Ezio Melotti added the comment: > > > People are going to skip warning boxes if they occur too often. > > I'm not sure I agree. This would be true if they were abused for trivial > things ("Warnings: using .pop() on a empty list will return an > IndexError!"), but I don't think they are. > > I think warnings are ignored only by people that are already familiar with > the module and its limitation/issues, and that know what they are doing. > If the warning is not evident, people are going to miss it [0]. > > If warnings are used correctly, people will spot them easily and read them > (or ignore them if they already know what they are warning against). > > [0]: I know I missed it in e.g. https://api.jquery.com/die/ -- the > function is deprecated, but (currently) this is only written in the top > right corner and in small in the category at the top -- two places that are > easily overlooked. https://api.jquery.com/toggle-event/ on the other > hand has a clearly visible yellow box at the top that immediately says that > the method is deprecated. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 12:07:47 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 04 Jan 2016 17:07:47 +0000 Subject: [issue26007] Request for Support for Embedding the Standard Library in an Executable In-Reply-To: <1451923993.52.0.708853061063.issue26007@psf.upfronthosting.co.za> Message-ID: <1451927267.19.0.287230705277.issue26007@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: So the use case is that you want to explicitly prevent the file system from being used for imports ? You might want to look at how eGenix PyRun works, since this does embed the Python stdlib into the executable (including the encodings package). While it does allow imports from the file system, it only looks there for things it cannot find embedded in the binary. PS: I'd suggest to make the issue title more specific to what you are actually after, which seems to be a way to install importers from C at a very early stage during initialization. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 12:17:26 2016 From: report at bugs.python.org (Phil Thompson) Date: Mon, 04 Jan 2016 17:17:26 +0000 Subject: [issue26007] Request for Support for Embedding the Standard Library in an Executable In-Reply-To: <1451923993.52.0.708853061063.issue26007@psf.upfronthosting.co.za> Message-ID: <1451927846.53.0.53056889171.issue26007@psf.upfronthosting.co.za> Phil Thompson added the comment: Yes, preventing the filesystem being used for imports would be another way of expressing the issue. Regarding the title I specifically didn't want to suggest a solution as I'm not expert enough to know what the best solution might be. If, as Paul implies, it should be possible to run the standard library from a zipfile then it suggests that this should actually be a bug report. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 12:18:51 2016 From: report at bugs.python.org (=?utf-8?q?Antonio_=C3=81lvarez?=) Date: Mon, 04 Jan 2016 17:18:51 +0000 Subject: [issue26008] Different behaviour platform.linux_distribution() on Python2.7 and 3.6 Message-ID: <1451927931.59.0.302771657902.issue26008@psf.upfronthosting.co.za> New submission from Antonio ?lvarez: Hi! I have a doubt, is this behaviour in Python2.7.11 usual, or is it a bug? >>> import platform >>> platform.linux_distribution() ('', '', '') In Python3.5.1 I get >>> import platform >>> platform.linux_distribution() ('arch', 'Arch', 'Linux') I work with Archlinux x86_64 with lsb-release installed. Thanks! ---------- components: Extension Modules messages: 257471 nosy: analca3 priority: normal severity: normal status: open title: Different behaviour platform.linux_distribution() on Python2.7 and 3.6 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 12:20:07 2016 From: report at bugs.python.org (=?utf-8?q?Antonio_=C3=81lvarez?=) Date: Mon, 04 Jan 2016 17:20:07 +0000 Subject: [issue26008] Different behaviour platform.linux_distribution() on Python2.7.11 and 3.5.1 In-Reply-To: <1451927931.59.0.302771657902.issue26008@psf.upfronthosting.co.za> Message-ID: <1451928007.72.0.150891494431.issue26008@psf.upfronthosting.co.za> Changes by Antonio ?lvarez : ---------- title: Different behaviour platform.linux_distribution() on Python2.7 and 3.6 -> Different behaviour platform.linux_distribution() on Python2.7.11 and 3.5.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 12:35:38 2016 From: report at bugs.python.org (Jason Sachs) Date: Mon, 04 Jan 2016 17:35:38 +0000 Subject: [issue26009] HTMLParser lacking a few features to reconstruct input exactly Message-ID: <1451928938.48.0.712719588041.issue26009@psf.upfronthosting.co.za> New submission from Jason Sachs: The HTMLParser class (https://docs.python.org/2/library/htmlparser.html) is lacking a few features to reconstruct input exactly. For the most part it can do this, but I found two items where it falls short (there may be others): - There is a get_starttag_text() method but no get_endtag_text() method, which is necessary if the end tag is not in canonical form, e.g. instead of

it is

or - The effect of the parse_bogus_comment() internal method is to call handle_comment(), so content like cannot be distinguished by subclasses of HTMLParser from actual comments Suggested changes: - Add a get_endtag_text() method to return the exact endtag text - change parse_bogus_comment to call self.handle_bogus_comment(), and define self.handle_bogus_comment() to call self.handle_comment(). This way it is backwards-compatible with existing behavior, but subclasses can redefine self.handle_bogus_comment() to do what they want. ---------- messages: 257472 nosy: jason_s priority: normal severity: normal status: open title: HTMLParser lacking a few features to reconstruct input exactly type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 12:36:45 2016 From: report at bugs.python.org (Jason Sachs) Date: Mon, 04 Jan 2016 17:36:45 +0000 Subject: [issue26009] HTMLParser lacking a few features to reconstruct input exactly In-Reply-To: <1451928938.48.0.712719588041.issue26009@psf.upfronthosting.co.za> Message-ID: <1451929005.54.0.0334534978864.issue26009@psf.upfronthosting.co.za> Jason Sachs added the comment: sample file attached containing VerbatimParser ---------- Added file: http://bugs.python.org/file41496/test2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 12:43:41 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 04 Jan 2016 17:43:41 +0000 Subject: [issue26005] Denial of Service in SimpleHTTPServer and BaseHTTPServer In-Reply-To: <1451897650.58.0.64883073344.issue26005@psf.upfronthosting.co.za> Message-ID: <1451929421.31.0.754427255611.issue26005@psf.upfronthosting.co.za> Brett Cannon added the comment: A warning directive at the start of http.server about needing to trust users would work? ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 12:44:59 2016 From: report at bugs.python.org (Jason Sachs) Date: Mon, 04 Jan 2016 17:44:59 +0000 Subject: [issue26009] HTMLParser lacking a few features to reconstruct input exactly In-Reply-To: <1451928938.48.0.712719588041.issue26009@psf.upfronthosting.co.za> Message-ID: <1451929499.79.0.260355258634.issue26009@psf.upfronthosting.co.za> Jason Sachs added the comment: sample file test1.html attached. When running test2.py on it, the output is identical except for two things: test1.html contains test1b.html contains test1.html contains end tags that are capitalized e.g.

or have spaces test1b.html contains end tags that are canonicalized to lowercase and without spaces e.g.

and ---------- Added file: http://bugs.python.org/file41497/test1.html _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 13:01:17 2016 From: report at bugs.python.org (Mike Romberg) Date: Mon, 04 Jan 2016 18:01:17 +0000 Subject: [issue17633] zipimport's handling of namespace packages is incorrect In-Reply-To: <1365070223.85.0.365511954484.issue17633@psf.upfronthosting.co.za> Message-ID: <1451930477.81.0.101839073072.issue17633@psf.upfronthosting.co.za> Mike Romberg added the comment: I have expanded on the issue17633-2 patch to fix an issue with the enumerated value returned by find_loader(). The patch (issue17633-3.diff) is against 3.5.1. I have also added more test cases that cover spreading a namespace package across two zip files and between a zip file and a filesystem. The expanded tests cover the iterable __path__ member of a namespace package. No new failures in 'make test' (gdb and ssl were broken with in 3.5.1 before this patch). The expanded test cases should continue to be relevant even if zipimport is rewritten. ---------- nosy: +romberg Added file: http://bugs.python.org/file41498/issue17633-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 13:06:06 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 04 Jan 2016 18:06:06 +0000 Subject: [issue26007] Request for Support for Embedding the Standard Library in an Executable In-Reply-To: <1451923993.52.0.708853061063.issue26007@psf.upfronthosting.co.za> Message-ID: <1451930766.24.0.762758655496.issue26007@psf.upfronthosting.co.za> Brett Cannon added the comment: What Phil is after is a hook at the C level that will allow him to modify the sys module to add something to sys.meta_path to remove PathEntryFinder and put in his own importer (assuming he isn't simply freezing everything). And yes, you should be able to run the stdlib from a zipfile, but the issue here is all the stuff Python imports as part of startup before the first bit of user Python code is executed, e.g. the encodings module. Since zipimport is added by importlib it gets special treatment to be usable ASAP. Since Phil wants to completely skew standard import mechanisms this does require a C hook. What this all means is that Phil really needs https://www.python.org/dev/peps/pep-0432/ to happen so that he can easily get his hook point added into the startup sequence. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 13:10:14 2016 From: report at bugs.python.org (Ethan Furman) Date: Mon, 04 Jan 2016 18:10:14 +0000 Subject: [issue26005] Denial of Service in SimpleHTTPServer and BaseHTTPServer In-Reply-To: <1451897650.58.0.64883073344.issue26005@psf.upfronthosting.co.za> Message-ID: <1451931014.64.0.61857528361.issue26005@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 13:36:22 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Jan 2016 18:36:22 +0000 Subject: [issue25998] doctest crashes when accessing __wrapped__ fails other than AttributeError In-Reply-To: <1451773843.64.0.986014558431.issue25998@psf.upfronthosting.co.za> Message-ID: <1451932582.87.0.526167756893.issue25998@psf.upfronthosting.co.za> R. David Murray added the comment: No, I don't think doctest should be made robust against RuntimeErrors. doctest's purpose is to check for bugs, and IMO this is a bug in flask. In particular, it is not doctest that flask is not cooperating with, it is hasattr. It used to be that hasattr would mask errors raised, and this caused a number of both debugging and production problems, to the point where hasattr was not considered safe to use. But it eventually got fixed: http://www.gossamer-threads.com/lists/python/dev/856859 ---------- nosy: +r.david.murray resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 13:42:43 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Jan 2016 18:42:43 +0000 Subject: [issue25998] doctest terminates when accessing __wrapped__ raises an error In-Reply-To: <1451773843.64.0.986014558431.issue25998@psf.upfronthosting.co.za> Message-ID: <1451932963.71.0.773998213146.issue25998@psf.upfronthosting.co.za> R. David Murray added the comment: Gah. Having hit send I of course had second thoughts. doctest is suppose to *report* bugs, so there *is* a doctest bug here: it should be capturing that and probably other errors and reporting them, instead of just producing a traceback, I think. ---------- resolution: third party -> stage: resolved -> needs patch status: closed -> open title: doctest crashes when accessing __wrapped__ fails other than AttributeError -> doctest terminates when accessing __wrapped__ raises an error versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 14:18:24 2016 From: report at bugs.python.org (Phil Thompson) Date: Mon, 04 Jan 2016 19:18:24 +0000 Subject: [issue26007] Request for Support for Embedding the Standard Library in an Executable In-Reply-To: <1451923993.52.0.708853061063.issue26007@psf.upfronthosting.co.za> Message-ID: <1451935104.86.0.855383887432.issue26007@psf.upfronthosting.co.za> Phil Thompson added the comment: At the moment my importer does the same as zipimport and gets added to sys.path_hooks rather than sys.meta_path. While waiting for the PEP, how about a table of (externally modifiable) importer installers that is worked through where _PyImportZip_Init() is currently called? By default _PyImportZip_Init() will be the only entry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 14:22:04 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 04 Jan 2016 19:22:04 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1451935324.29.0.840363611808.issue25958@psf.upfronthosting.co.za> Guido van Rossum added the comment: I propose to solve the narrow problem by indeed supporting the setting of certain special methods to None similar to __hash__. This should be limited to those methods for which this adds value, e.g. where the complete absence of the method causes a fall-back to a different API (e.g. __getitem__+__len__ in the case of __reversed__) -- the None value should just block the fallback. This will require some changes in the ABCs that test for the presence of a given method (Iterable/__iter__, Container/__contains__, Reversible/__reversed__ -- the latter ABC should be added) and in implementations such as reversed(), iter() and 'in'. Maybe we should just do this for every ABC in collections.abc (plus Reversible) that has a __subclasshook__ that tests for the presence of the special method. Oh, probably some more, like Iterator/__next__, Sized/__len__ and Callable/__call__. But for those there isn't a fallback in the corresponding bytecode, so I'm only +0 for those -- it doesn't seem to harm anything to be consistent with those for which it does matter, but it doesn't cost much either, and the consistency is slightly useful -- it provides a pattern to follow for future ABCs. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 14:22:22 2016 From: report at bugs.python.org (Hamza T Khan) Date: Mon, 04 Jan 2016 19:22:22 +0000 Subject: [issue25496] tarfile: Default value for compresslevel is not documented In-Reply-To: <1446021567.06.0.820338275323.issue25496@psf.upfronthosting.co.za> Message-ID: <1451935342.74.0.422537427208.issue25496@psf.upfronthosting.co.za> Hamza T Khan added the comment: Here is trivial fix for this issue. This is my first patch and I hope that it gets accepted and integrated. hamza at hamza-ub94:~/git/cpython$ grep compresslevel Lib/tarfile.py def gzopen(cls, name, mode="r", fileobj=None, compresslevel=9, **kwargs): fileobj = gzip.GzipFile(name, mode + "b", compresslevel, fileobj) def bz2open(cls, name, mode="r", fileobj=None, compresslevel=9, **kwargs): compresslevel=compresslevel) hamza at hamza-ub94:~/git/cpython$ ---------- hgrepos: +330 keywords: +patch nosy: +hamzatkhan94 Added file: http://bugs.python.org/file41499/Issue25496.v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 14:22:54 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 04 Jan 2016 19:22:54 +0000 Subject: [issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError In-Reply-To: <1450150718.99.0.697293755498.issue25864@psf.upfronthosting.co.za> Message-ID: <1451935374.46.0.0452330200355.issue25864@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think I tried to address all questions in #25958. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 14:53:10 2016 From: report at bugs.python.org (Andrew Barnert) Date: Mon, 04 Jan 2016 19:53:10 +0000 Subject: [issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError In-Reply-To: <1450150718.99.0.697293755498.issue25864@psf.upfronthosting.co.za> Message-ID: <1451937190.97.0.351759853555.issue25864@psf.upfronthosting.co.za> Andrew Barnert added the comment: > IMO allowing any special method to be set to None seems to make more trouble than it is worth. That's exactly why allowing _any_ special method to be None is a separate issue (#25958). Most special methods don't have any corresponding problem to the one with __reversed__. > Ideally I think it would be better to require __reversed__() for reverse() to work, but such a change would break compatibility. See the -ideas thread "Deprecating the old-style sequence protocol" (http://article.gmane.org/gmane.comp.python.ideas/37588). > Regarding test_enumerate.py, your class looks like this: Please look at the two classes directly above it in the same function. The new Blocked exactly parallels the existing NoLen. > I suggest either remove __getitem__() if it serves no purpose It very definitely serves a purpose. The whole point of the new test is that reversed will not fall back to using __getitem__ and __len__ if __reversed__ is None. So __getitem__ has to be there; otherwise, we already know (from the NoGetItem test) that it wouldn't get called anyway. This is exactly the same as the NoLen test, which verifies that __reversed__ will not fall back to __getitem__ and __len__ if one is present but not both. > , or change it to something like this if you really want an unreversible sequence: Sure, if I wanted a real class that could be used as a sequence but could not be reversed. But all I want here is a toy class for testing the specific method lookup behavior. Again, exactly like the existing classes in the same test. Finally, from your previous comment: > I think the ABC documentation should clarify which methods are checked for None and which aren?t. Looking at this a bit more: The ABC documentation doesn't even tell you that, e.g., Container and Hashable have subclass hooks that automatically make any class with __contains__ and __hash__ act like registered subclasses while, say, Sequence and Set don't. So, you're suggesting that we should explain where the hooks in some of those types differ, when we haven't even mentioned where the hooks exist at all. Maybe collections.abc _should_ have more detail in the docs, but I don't think that should be part of this bug. (Practically, I've always found the link to the source at the top sufficient--trying to work out exactly why tuple meets some ABC and some custom third-party sequence doesn't, which is a pretty rare case to begin with, is also pretty easy to deal with: you scan the source, quickly find that Sequence.register(tuple), read up on what it does, and realize that collections.abc.Sequence.register(joeschmoe.JoeSchmoeSequence) is what you want, and you're done.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 14:58:42 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 04 Jan 2016 19:58:42 +0000 Subject: [issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError In-Reply-To: <1451937190.97.0.351759853555.issue25864@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Agreed that improving the docs doesn't belong in this bug, but in general if the docs aren't clear enough and only a visit to the source helps you understand, something's wrong. Because the source may do things one way today and be changed to do things differently tomorrow, all within the (intended) promises of the API. But without docs we don't know what those promises are. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 15:13:02 2016 From: report at bugs.python.org (Wiktor Niesiobedzki) Date: Mon, 04 Jan 2016 20:13:02 +0000 Subject: [issue25919] http.client PUT method ignores error responses sent immediatly after headers In-Reply-To: <1450729223.96.0.301570875049.issue25919@psf.upfronthosting.co.za> Message-ID: <1451938382.05.0.690805061508.issue25919@psf.upfronthosting.co.za> Wiktor Niesiobedzki added the comment: I've checked how it behaves, when I do: $ openssl s_client -host api.onedrive.com -port 443 The server then works like that (using curl debug log style): > PUT /v1.0/drives/me/root:/test.file:/content HTTP/1.1 > Host: api.onedrive.com > Content-Range: bytes 0-314572799/314572800 > User-Agent: curl/7.43.0 > Accept: */* > Content-Length: 314572800 > < HTTP/1.1 413 Request Entity Too Large < Content-Length: 0 < Server: Microsoft-HTTPAPI/2.0 < P3P: CP="BUS CUR CONo FIN IVDo ONL OUR PHY SAMo TELo" < X-MSNSERVER: DM2304____PAP130 < Strict-Transport-Security: max-age=31536000; includeSubDomains < X-ThrowSite: 7c11.e25d < Date: Mon, 04 Jan 2016 18:44:28 GMT > 0000000000000000000000000000000000000000000000000000 [...] And I may continue sending the data. As for 100-continue - it looks like Microsoft server is not supporting Expect: 100-continue header, and it just waits for data, when content is shorter (like 100 bytes). I do not see clear indications how the client should behave in such situation (response received before sending complete request). I do not understand, where you see the race condition. As we are sending in blocks of 8kb, if we missed the select on first block, we will catch something in next select. If server would close down the socket immediately, we should receive failure in sock.sendall() -> writing to socket that is closed for writing by remote party. As I understand, right now my patch breaks uploads, when server returns HTTP 100 response. Contrary to Issue 1346874 I'd recommend to check - if server returned 100 response, then continue the upload of the file or prepare error response for get_response(). I do not see why this behaviour should be implemented in code using http.client. Status of upload should be (and it is right now) done using get_response() anyway, as any upload request might end in HTTP error response, so I vouch for empty return value - it is complaint with current interface. I'm in progress of preparation of the test cases for such scenario using SocketServer, to keep it close to how network behaves, but maybe I'll manage to prepare testcases using FakeSocket. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 15:26:38 2016 From: report at bugs.python.org (Vincent Legoll) Date: Mon, 04 Jan 2016 20:26:38 +0000 Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL certificate In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za> Message-ID: <1451939198.35.0.589030175771.issue25940@psf.upfronthosting.co.za> Changes by Vincent Legoll : ---------- nosy: +vincent-legoll _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 15:30:05 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 04 Jan 2016 20:30:05 +0000 Subject: [issue25988] collections.abc.Indexable In-Reply-To: <1451686739.56.0.219134772531.issue25988@psf.upfronthosting.co.za> Message-ID: <1451939405.1.0.0450660305098.issue25988@psf.upfronthosting.co.za> Guido van Rossum added the comment: Interesting. I just hope the name doesn't confuse people into connecting this with the Index type (a type of integer that can't be cast from float). ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 15:31:37 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 04 Jan 2016 20:31:37 +0000 Subject: [issue25987] collections.abc.Reversible In-Reply-To: <1451685633.1.0.273350637631.issue25987@psf.upfronthosting.co.za> Message-ID: <1451939497.42.0.0466315032266.issue25987@psf.upfronthosting.co.za> Guido van Rossum added the comment: Yes please. Thanks for thinking about all the edge cases here! ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 15:36:37 2016 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 04 Jan 2016 20:36:37 +0000 Subject: [issue26008] Different behaviour platform.linux_distribution() on Python2.7.11 and 3.5.1 In-Reply-To: <1451927931.59.0.302771657902.issue26008@psf.upfronthosting.co.za> Message-ID: <1451939797.83.0.00532722252941.issue26008@psf.upfronthosting.co.za> Eric V. Smith added the comment: This is a duplicate of issue 20454. ---------- nosy: +eric.smith resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> platform.linux_distribution() returns empty value on Archlinux and python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 15:43:10 2016 From: report at bugs.python.org (Andrew Barnert) Date: Mon, 04 Jan 2016 20:43:10 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1451940190.1.0.20137240948.issue25958@psf.upfronthosting.co.za> Andrew Barnert added the comment: > I propose to solve the narrow problem by indeed supporting the setting of certain special methods to None similar to __hash__. This should be limited to those methods for which this adds value, e.g. where the complete absence of the method causes a fall-back to a different API (e.g. __getitem__+__len__ in the case of __reversed__) -- the None value should just block the fallback I believe that currently, except for the minor problem in #25864, you can set any special method to None and it _will_ block any fallback (and also block inheritance, of course, the reason it's used with __hash__): * __iter__ and __reversed__ directly fall back to another method. * __contains__ falls back to iterating, which will indirectly fall back on __iter__ (or on __getitem__, of course). * __iadd__ and friends fall back on __add__ and friends. * __add__ and friends fall back on __radd__ (on the other operand, but typically it will be of the same type). * __lt__ and friends are similar to __add__. * __getattr__ and friends are a pile of special cases. * I think everything else doesn't have a fallback, and would just raise a TypeError anyway--although setting to None is still useful as a way to block inheritance, as used for __hash__. In all cases, if the primary method exists but is None, the implementation will try to call it, and let the TypeError from NoneType.__call__ escape, which blocks the fallback. (And, of course, it blocks the MRO search for an inherited method.) Of course the message is the useless and cryptic "'NoneType' object is not callable" rather than the nice one you get from hash. But technically, it's all already working as desired. We probably need to document that setting special methods to None blocks any fallback implementation (both for people who write such classes, and to ensure that other Pythons do the same thing as CPython). Practically, I think we need to improve the error message for the ones that are likely to come up, but probably not for all of them. I think this means either just reversed, or reversed+iter, or maybe reversed+iter+in. (Plus hash, of course, but that code is already there.) Also, I suppose we should have tests for this behavior. > This will require some changes in the ABCs that test for the presence of a given method (Iterable/__iter__, Container/__contains__, Reversible/__reversed__ -- the latter ABC should be added) and in implementations such as reversed(), iter() and 'in'. Maybe we should just do this for every ABC in collections.abc (plus Reversible) that has a __subclasshook__ that tests for the presence of the special method. Now that I think about it, I'm +0.5 on changing all of them. Imagine, as a reader, trying to guess why some do the check and some don't. Also, I think they should test for None instead of falsiness like Hashable does. (Hopefully nobody ever writes something that's falsey but callable, but why tempt fate?) --- I'll write a patch that expands the #25864 patch: * collections.abc.Reversible added (as in #25987). * All collections.abc.* subclass hooks check for None. * Mapping.__reversed__ = None. * One paragraph added to datamodel docs. * iter, reversed, and 'in' operator all raise a custom TypeError when the special method is None the same way as hash (but everything else will continue to implicitly raise the ugly TypeError). * Unit tests for None blocking fallback on all special methods I can think of (treating all the __ispam__, add the __rspam__, all inheritance except for __hash__, etc. as a single method each, rather than copying-pasting a half-dozen times). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 15:48:08 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 04 Jan 2016 20:48:08 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451940190.1.0.20137240948.issue25958@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I like all of that. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 15:53:37 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 04 Jan 2016 20:53:37 +0000 Subject: [issue26004] pip install lifetimes - throwing error and unable to install packages In-Reply-To: <1451897106.72.0.251427221401.issue26004@psf.upfronthosting.co.za> Message-ID: <1451940817.15.0.0774904743338.issue26004@psf.upfronthosting.co.za> Steve Dower added the comment: Since you're on Python 3.5, you'll need Visual Studio 2015 to build extensions. However, since the extension in question is numpy, you'll need to find prebuilt binaries since you won't be able to compile it yourself just yet. I believe Continuum has builds for 3.5 in Anaconda now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 16:08:16 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 04 Jan 2016 21:08:16 +0000 Subject: [issue26007] Request for Support for Embedding the Standard Library in an Executable In-Reply-To: <1451923993.52.0.708853061063.issue26007@psf.upfronthosting.co.za> Message-ID: <1451941696.49.0.995897989717.issue26007@psf.upfronthosting.co.za> Brett Cannon added the comment: I personally would rather wait until PEP 432 happens before adding any such hook. This sort of thing is extremely hard to test and the startup sequence for Python is already quite complicated and honestly too tightly bound to the magical sequence of steps it current has. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 16:25:15 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 04 Jan 2016 21:25:15 +0000 Subject: [issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError In-Reply-To: <1450150718.99.0.697293755498.issue25864@psf.upfronthosting.co.za> Message-ID: <1451942715.85.0.823882047666.issue25864@psf.upfronthosting.co.za> Martin Panter added the comment: I?m sorry I only read your patch and did not see the NoLen class above Blocked. (I blame the lack of Reitveld review link.) I still think __getitem__() should have a valid signature, but I acknowledge that it?s not really your fault. :) My main concern about the documentation was that in your patch you say _all_ special methods are now allowed to be None, but in your code you only check __iter__(). This is adding new undocumented inconsistencies e.g. with Iterable vs Container. Maybe it would be better to only say that setting __iter__ to None is supported, instead of setting any special method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 16:32:15 2016 From: report at bugs.python.org (Phil Thompson) Date: Mon, 04 Jan 2016 21:32:15 +0000 Subject: [issue26007] Request for Support for Embedding the Standard Library in an Executable In-Reply-To: <1451923993.52.0.708853061063.issue26007@psf.upfronthosting.co.za> Message-ID: <1451943135.79.0.649385704155.issue26007@psf.upfronthosting.co.za> Phil Thompson added the comment: I don't see why it would be hard to test. The change suggested wouldn't alter the default behaviour at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 16:38:55 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 04 Jan 2016 21:38:55 +0000 Subject: [issue26007] Request for Support for Embedding the Standard Library in an Executable In-Reply-To: <1451923993.52.0.708853061063.issue26007@psf.upfronthosting.co.za> Message-ID: <1451943535.3.0.491402405132.issue26007@psf.upfronthosting.co.za> Brett Cannon added the comment: It might not change the default behaviour, but we still have to make sure it works and doesn't accidentally break. If we add official support for a C API to specify callbacks to execute during interpreter startup before any stdlib Python code then we are making a promise that it will work and so we have to worry about it even if the vast majority of users will never use it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 16:43:19 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 04 Jan 2016 21:43:19 +0000 Subject: [issue26010] document CO_* constants Message-ID: <1451943799.55.0.170174957696.issue26010@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- assignee: docs at python components: Documentation keywords: needs review nosy: docs at python, r.david.murray, yselivanov priority: normal severity: normal stage: patch review status: open title: document CO_* constants type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 16:45:11 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 04 Jan 2016 21:45:11 +0000 Subject: [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451943911.98.0.423747373953.issue25813@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- superseder: -> document CO_* constants _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 16:47:03 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 04 Jan 2016 21:47:03 +0000 Subject: [issue26010] document CO_* constants Message-ID: <1451944023.51.0.951612152691.issue26010@psf.upfronthosting.co.za> New submission from Yury Selivanov: Hi David, This is a follow up to issue #26010. Please review the attached patch. I've skipped the CO_NESTED flag since it's no longer used, and CO_OPTIMIZED because I don't know too much about it. ---------- keywords: +patch Added file: http://bugs.python.org/file41500/Issue26010.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 16:56:24 2016 From: report at bugs.python.org (Georg Brandl) Date: Mon, 04 Jan 2016 21:56:24 +0000 Subject: [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451944584.47.0.140180960929.issue25813@psf.upfronthosting.co.za> Georg Brandl added the comment: > For the final time, *I* am the OP and not one of you could be bothered before so this remains closed. Are you quite all right? Continuing behavior of that sort will get your tracker account disabled. ---------- nosy: +georg.brandl status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 17:09:32 2016 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 04 Jan 2016 22:09:32 +0000 Subject: [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451945372.33.0.695434327136.issue25813@psf.upfronthosting.co.za> Mark Lawrence added the comment: It's all ready been superceeded, or haven't you woken up to that fact either? ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 17:25:00 2016 From: report at bugs.python.org (Andrew Barnert) Date: Mon, 04 Jan 2016 22:25:00 +0000 Subject: [issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError In-Reply-To: <1450150718.99.0.697293755498.issue25864@psf.upfronthosting.co.za> Message-ID: <1451946300.12.0.514183572336.issue25864@psf.upfronthosting.co.za> Andrew Barnert added the comment: > My main concern about the documentation was that in your patch you say _all_ special methods are now allowed to be None, but in your code you only check __iter__(). This is adding new undocumented inconsistencies e.g. with Iterable vs Container. No it isn't. We already have undocumented inconsistencies between, e.g., Hashable vs. Container; we're just moving Iterable from one set to the other. (Notice that there's an even larger inconsistency between, e.g., Hashable and Container vs. Sequence and Set. As Guido suggests, that probably _does_ need to be fixed, but not as part of this bug, or #25958.) And, as for the docs, it's already true that you can block fallback and inheritance of special methods by assigning them to None, but that isn't documented anywhere. So, this bug doesn't add fix any of those inconsistencies, but it doesn't add any new ones, either. If you think we actually _need_ to fix them, see #25958 as at least a starting point. (Notice that Guido seems to want that one fixed, so, assuming I can write a decent patch for it, this bug would then become a one-liner: "__reversed__ = None" inside Mapping.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 17:26:45 2016 From: report at bugs.python.org (Georg Brandl) Date: Mon, 04 Jan 2016 22:26:45 +0000 Subject: [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451946405.69.0.697166223435.issue25813@psf.upfronthosting.co.za> Georg Brandl added the comment: > It's all ready been superceeded, or haven't you woken up to that fact either? Excuse me for not having all issues in my head. (And that #26010 states that it's a followup to #26010 doesn't help.) In the future, please accept that the core developers are who decide about issues being closed or not. Submitters are only given privilege to close their own issues because it lightens the load on coredevs if issues become obsolete (and no, no answer in less than 30 days does not mean obsolete). As I already said, abusing that privilege will eventually get you banned - so much the sooner with your past history taken into account. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 17:58:20 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 04 Jan 2016 22:58:20 +0000 Subject: [issue17633] zipimport's handling of namespace packages is incorrect In-Reply-To: <1365070223.85.0.365511954484.issue17633@psf.upfronthosting.co.za> Message-ID: <1451948300.41.0.495211265984.issue17633@psf.upfronthosting.co.za> Brett Cannon added the comment: Any chance you can do the diff against an hg checkout, Mike? That way we can use our review tool to do the code review, else we have to work only from the raw diff file which isn't as nice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 18:14:29 2016 From: report at bugs.python.org (Phil Thompson) Date: Mon, 04 Jan 2016 23:14:29 +0000 Subject: [issue26007] Request for Support for Embedding the Standard Library in an Executable In-Reply-To: <1451923993.52.0.708853061063.issue26007@psf.upfronthosting.co.za> Message-ID: <1451949269.38.0.992419872911.issue26007@psf.upfronthosting.co.za> Phil Thompson added the comment: Understood, but the only promise here is to call a function (with no arguments, and returning no result). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 18:15:23 2016 From: report at bugs.python.org (Mike Romberg) Date: Mon, 04 Jan 2016 23:15:23 +0000 Subject: [issue17633] zipimport's handling of namespace packages is incorrect In-Reply-To: <1365070223.85.0.365511954484.issue17633@psf.upfronthosting.co.za> Message-ID: <1451949323.22.0.698207158568.issue17633@psf.upfronthosting.co.za> Mike Romberg added the comment: Yes. I can do this. I've not used hg before. But I bet I can figure it out. I'm assuming hg has a diff/pach genterator of some kind ('hg diff' perhaps). Lemme try and find the hg repository and check out a copy... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 18:32:19 2016 From: report at bugs.python.org (Karl Richter) Date: Mon, 04 Jan 2016 23:32:19 +0000 Subject: [issue26011] Document necesities for cmp argument of sorted Message-ID: <1451950339.23.0.203915233375.issue26011@psf.upfronthosting.co.za> New submission from Karl Richter: The docstring of `sorted` doesn't explain what can be passed to the `cmp` and `key` argument of `sorted`. ---------- assignee: docs at python components: Documentation messages: 257505 nosy: docs at python, krichter priority: normal severity: normal status: open title: Document necesities for cmp argument of sorted type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 19:04:57 2016 From: report at bugs.python.org (Mike Romberg) Date: Tue, 05 Jan 2016 00:04:57 +0000 Subject: [issue17633] zipimport's handling of namespace packages is incorrect In-Reply-To: <1365070223.85.0.365511954484.issue17633@psf.upfronthosting.co.za> Message-ID: <1451952297.23.0.549030048597.issue17633@psf.upfronthosting.co.za> Mike Romberg added the comment: Try issue17633-hg.diff. Caution it was made after literally minutes of experience with hg. :) I checked out the source applied the changes, compiled and ran 'make test' (gdb still fails), and did an hg commit. The diff was made following the instructions here: https://docs.python.org/devguide/gitdevs.html It seems to have worked. But again, I have literally minutes of hg experience. If this needs to be redone let me know. ---------- Added file: http://bugs.python.org/file41501/issue17633-hg.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 19:46:34 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 05 Jan 2016 00:46:34 +0000 Subject: [issue17633] zipimport's handling of namespace packages is incorrect In-Reply-To: <1365070223.85.0.365511954484.issue17633@psf.upfronthosting.co.za> Message-ID: <1451954794.59.0.30713187703.issue17633@psf.upfronthosting.co.za> Brett Cannon added the comment: Nope, looks like it worked! I will try to have a look at the patch some time this week. And for future reference, you can also use https://docs.python.org/devguide/patch.html as a guide. ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 19:50:07 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 05 Jan 2016 00:50:07 +0000 Subject: [issue25919] http.client PUT method ignores error responses sent immediatly after headers In-Reply-To: <1450729223.96.0.301570875049.issue25919@psf.upfronthosting.co.za> Message-ID: <1451955007.89.0.24897417258.issue25919@psf.upfronthosting.co.za> Martin Panter added the comment: As I see it, if the client receives an early response (when 100-continue is not used) but needs to make more requests, the only choices are: * Complete sending the request if possible, after which the connection may still be usable for a second request. But I?m not sure how many servers would support this; for your Microsoft server this would not be useful. * Abort the connection and start a new one. Perhaps the race condition would be more obvious if you sent the upload as a single 300 MiB bytes() object rather than a file. Then the sendall() call will be a 300 MiB chunk rather than 8 KiB. If the response is received after sendall() starts, I expect you will see the original two minute delay again. If this were plain TCP, you could replace sendall() with fine-grained select() and send() calls in a loop. Here is a demonstration of the SSL renegotiation issue. I used separate client and server terminal windows. I don?t know if there is a way to force renegotiation purely in Python?s SSL module, so I used an external Open SSL server. 1: In the server window, start an SSL server on port 4433: $ openssl s_server -cert Lib/test/keycert.pem 2: In the client window, start a request in the Python interpreter. It will pause to read stdin: >>> import http.client, ssl, sys >>> context = ssl.SSLContext(ssl.PROTOCOL_SSLv23) >>> context.load_verify_locations("/usr/lib/python3.5/test/keycert.pem") >>> conn = http.client.HTTPSConnection('localhost', 4433, context=context) >>> conn.request("PUT", "/", headers={"Content-Length": "4"}, body=sys.stdin.buffer) 3: In the server, the request header is received. Type lowercase ?r? to force a renegotiation: Secure Renegotiation IS supported PUT / HTTP/1.1 Host: localhost:4433 Accept-Encoding: identity Content-Length: 8 r SSL_do_handshake -> 1 4: In Python, type in upload data and repeat Ctrl+D to signal EOF until the request() call stops reading from stdin and you get the Python prompt back: abc <== 3 letters + newline + Ctrl+D >>> 5: Notice that the no body has been uploaded to the server. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 20:55:09 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 Jan 2016 01:55:09 +0000 Subject: [issue22062] Fix pathlib.Path.(r)glob doc glitches. In-Reply-To: <1406239862.0.0.293742999811.issue22062@psf.upfronthosting.co.za> Message-ID: <1451958909.53.0.541229119253.issue22062@psf.upfronthosting.co.za> Guido van Rossum added the comment: Classifying as easy doc bug. ---------- assignee: -> docs at python components: +Documentation keywords: +easy nosy: +docs at python, gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 20:56:22 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 Jan 2016 01:56:22 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <1451958982.92.0.771277746383.issue24120@psf.upfronthosting.co.za> Guido van Rossum added the comment: I just ran into this issue. What's keeping it from being committed, except perhaps that Antoine decided to leave core developments? ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 21:13:51 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 Jan 2016 02:13:51 +0000 Subject: [issue26012] pathlib.Path().rglob() is fooled by symlink loops Message-ID: <1451960031.51.0.813695149526.issue26012@psf.upfronthosting.co.za> New submission from Guido van Rossum: I created a symlink loop as follows: mkdir tmp cd tmp ln -s ../tmp baz cd .. Then I tried to list it recursively using rglob(): >>> list(pathlib.Path('tmp').rglob('**/*') This caused an infinite regress: Traceback (most recent call last): File "", line 1, in File "/Users/guido/src/cpython36/Lib/pathlib.py", line 1065, in rglob for p in selector.select_from(self): File "/Users/guido/src/cpython36/Lib/pathlib.py", line 549, in _select_from for p in successor_select(starting_point, is_dir, exists, listdir): File "/Users/guido/src/cpython36/Lib/pathlib.py", line 548, in _select_from for starting_point in self._iterate_directories(parent_path, is_dir, listdir): File "/Users/guido/src/cpython36/Lib/pathlib.py", line 538, in _iterate_directories for p in self._iterate_directories(path, is_dir, listdir): [...] File "/Users/guido/src/cpython36/Lib/pathlib.py", line 538, in _iterate_directories for p in self._iterate_directories(path, is_dir, listdir): File "/Users/guido/src/cpython36/Lib/pathlib.py", line 537, in _iterate_directories if is_dir(path): File "/Users/guido/src/cpython36/Lib/pathlib.py", line 1303, in is_dir return S_ISDIR(self.stat().st_mode) File "/Users/guido/src/cpython36/Lib/pathlib.py", line 1111, in stat return self._accessor.stat(self) File "/Users/guido/src/cpython36/Lib/pathlib.py", line 371, in wrapped return strfunc(str(pathobj), *args) OSError: [Errno 62] Too many levels of symbolic links: 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz' ---------- messages: 257511 nosy: gvanrossum priority: normal severity: normal status: open title: pathlib.Path().rglob() is fooled by symlink loops versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 21:14:14 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 Jan 2016 02:14:14 +0000 Subject: [issue26012] pathlib.Path().rglob() is fooled by symlink loops In-Reply-To: <1451960031.51.0.813695149526.issue26012@psf.upfronthosting.co.za> Message-ID: <1451960054.45.0.79538816685.issue26012@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- components: +Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 21:28:44 2016 From: report at bugs.python.org (Andrew Barnert) Date: Tue, 05 Jan 2016 02:28:44 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1451960924.25.0.119443468167.issue25958@psf.upfronthosting.co.za> Andrew Barnert added the comment: Is an hg export patch usable? If not, let me know and I'll flatten it. Anyway, the attached patch fixes #25987 and #25864 as well as this one, as follows: * Every ABC in collections.abc that has a subclass hook now treats None as blocking, instead of a few checking falsiness and others not checking anything. (And all the hooks are now identical, which eliminates any unintended inconsistencies.) * collections.abc.Mapping.__reversed__ = None (fixes #25864). * collections.abc.Reversible added (fixes #25987). * iter(), reversed(), and in operator all have custom text in their TypeError instead of the generic "'NoneType' object is not callable". * Unit tests for all of the above, plus that None blocking also works appropriately (i.e., same as in CPython 2.3-3.6) for __spam__ -> __rspam__, __ispam__ -> __spam__. * I didn't try to write tests for _everything_ with fallback. For example, blocking fallback from __str__ to __repr__, or anything to do with __*attr*__, does work, but I can't think of any conceivable case where you'd ever do such a thing. (The fact that you can write a class that isn't repr-able isn't a feature of Python we want to guarantee, it's just a side-effect of other stuff that will hopefully never come up, so it seems wrong to write a unit test to guarantee it.) * Data Model docs document that you can set a special method to None to block behavior (including blocking fallback to old-style sequence protocol, inheritance from superclass, etc.). (Note that this patch is not yet fully tested, because my Windows and Cygwin builds are for some reason taking forever. But if I don't post an update tomorrow, that will mean they passed the overnight tests. I doubt anyone was going to commit this tonight anyway, but, just in case...) ---------- keywords: +patch Added file: http://bugs.python.org/file41502/patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 21:39:44 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Jan 2016 02:39:44 +0000 Subject: [issue26012] pathlib.Path().rglob() is fooled by symlink loops In-Reply-To: <1451960031.51.0.813695149526.issue26012@psf.upfronthosting.co.za> Message-ID: <1451961584.45.0.42450950245.issue26012@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 22:10:55 2016 From: report at bugs.python.org (Jonathon Reinhart) Date: Tue, 05 Jan 2016 03:10:55 +0000 Subject: [issue10496] Python startup should not require passwd entry In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za> Message-ID: <1451963455.9.0.281825166783.issue10496@psf.upfronthosting.co.za> Jonathon Reinhart added the comment: I have another scenario where this happens: Running Python in a Docker container, passing the --user option to 'docker run'. This sets the UID in the container, which has its own /etc/passwd. Couple this with the fact that $HOME might not be set (e.g. when Python is invoked from SCons which deliberately clears the environment for sub-processes), and *boom*, Python is non-functional. Regardless of where the fix is done, the ideal behavior is straightforward: if Python can't determine the home directory, don't try to add user site packages. This bug is now over 5 years old, and people have identified real-life various scenarios where this bug manifests itself, and submitted patches. Could we please address this? ---------- nosy: +Jonathon Reinhart _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 22:40:28 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 05 Jan 2016 03:40:28 +0000 Subject: [issue23677] Mention dict and set comps in library reference In-Reply-To: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za> Message-ID: <1451965228.56.0.353746354698.issue23677@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Heck, with the addition of additional unpacking generalizations in 3.5, you can make an empty set even without a comprehension: {*()} Not really recommending the "one-eyed monkey operator", but the addition of unpacking generalizations undoes several of the limits on literals that previously existed. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 00:15:49 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 05 Jan 2016 05:15:49 +0000 Subject: [issue26011] Document necesities for cmp argument of sorted In-Reply-To: <1451950339.23.0.203915233375.issue26011@psf.upfronthosting.co.za> Message-ID: <1451970949.13.0.154622224116.issue26011@psf.upfronthosting.co.za> Josh Rosenberg added the comment: The docstring doesn't give details, but many docstrings don't. The docs themselves do; not sure it's a good idea to expand every docstring into complete documentation; if you don't know the function you read the real docs, the docstrings are useful as a reminder for stuff like argument order and names, higher logic, etc., without getting into details. cmp is almost certainly not going to be documented further in the docstrings; 2.7 is in bug fix only mode IIRC (and even then, mostly security fix only), and tweaking docstrings that aren't wrong, just less detailed than you might like isn't likely to meet the bar. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 00:25:17 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 05 Jan 2016 05:25:17 +0000 Subject: [issue26012] pathlib.Path().rglob() is fooled by symlink loops In-Reply-To: <1451960031.51.0.813695149526.issue26012@psf.upfronthosting.co.za> Message-ID: <1451971517.7.0.288043575894.issue26012@psf.upfronthosting.co.za> Josh Rosenberg added the comment: So would the goal of a fix be something like dev/inode memoization to prevent traversing the same link twice? To provide an argument to prevent following symlinks at all (as in stuff like os.walk), possibly defaulting to followlinks=False? It looks like languages like Ruby never follow symlinks when performing recursive globs to avoid this issue ( https://stackoverflow.com/questions/357754/can-i-traverse-symlinked-directories-in-ruby-with-a-glob ). It's probably easiest to just block recursing through symlinks (at least by default); memoizing risks unbounded memory overhead for large directory trees. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 00:30:14 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 05 Jan 2016 05:30:14 +0000 Subject: [issue26005] Denial of Service in SimpleHTTPServer and BaseHTTPServer In-Reply-To: <1451897650.58.0.64883073344.issue26005@psf.upfronthosting.co.za> Message-ID: <1451971814.3.0.153998845446.issue26005@psf.upfronthosting.co.za> Senthil Kumaran added the comment: SimpleHTTPServer is never meant to be used in production. I was of the understanding that we already inform users about it in the documentation, but I do not find any such note. Only in wsgiref's simple_server.py example, we state that in the module header https://hg.python.org/cpython/file/tip/Lib/wsgiref/simple_server.py#l1 For SimpleHTTPServer, we could add a similar warning in docs. "SimpleHTTPServer is meant for demo purposes and does not implement the stringent security checks needed of real HTTP server. We do not recommend using this module directly in production." If an alternate wording is desired, please suggest in that in comments. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 00:48:21 2016 From: report at bugs.python.org (diana) Date: Tue, 05 Jan 2016 05:48:21 +0000 Subject: [issue25711] Rewrite zipimport from scratch In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za> Message-ID: <1451972901.02.0.282356581255.issue25711@psf.upfronthosting.co.za> Changes by diana : ---------- nosy: +diana _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 01:03:37 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 05 Jan 2016 06:03:37 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1451973817.88.0.0942148753787.issue25958@psf.upfronthosting.co.za> Martin Panter added the comment: A Mercurial export patch should work with the Reitveld review thing if it is a single revision (and based on a public revision). Or you could try getting a plain diff from the base revision. Or for changes that are independent, separate patches based off a common public revision. Please at least fold your fixup commits into the original commits; that would make it a lot easier to review. You have a stray print() call, probably in Hashable.__subclasshook__(). For a the do-nothing __reversed__() implementation, do you think ?yield from ()? would be clearer than ?while False?? Or even ?return iter(())?? What?s the advantage of having Reversed inherit Iterable? How does the subclass hook interact with classes that implement __reversed__() but not __iter__()? I don?t see how the self.assertFalse(issubclass(K, Reversible)) test could pass. Should the new Reversed class be excluded from collections.__all__, or is it not worth it? I find the lambda generator a bit quirky in test_Reversible(). Maybe it would be better as an ordinary non-lambda generator with a yield statement. It would be good to have a versionadded notice for Reversible. I think there should also be one for allowing None for all special methods. Instead of self.assertEqual(list(reversed(R())), list(reversed([]))), why not check it is equal to an empty list directly? In test_contains.py, I would either write lambda: 0 in bc, or use the ?with self.assertRaises()? form. Finally, if setting a binary operator method to None means that operation is not available, I find it a bit surprising that doing this prevent the other operand?s method from being tried. I guess you don?t want to change the implementation, but perhaps the documentation of the binary operator methods could be clarified. ---------- stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 01:21:55 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Jan 2016 06:21:55 +0000 Subject: [issue26012] pathlib.Path().rglob() is fooled by symlink loops In-Reply-To: <1451960031.51.0.813695149526.issue26012@psf.upfronthosting.co.za> Message-ID: <1451974915.38.0.509139033764.issue26012@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: glob.glob() just stops too deep recursion. >>> import glob >>> glob.glob('tmp/**/*') ['tmp/baz/baz'] >>> glob.glob('tmp/**/*', recursive=True) ['tmp/baz', 'tmp/baz/baz', 'tmp/baz/baz/baz', 'tmp/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz', 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz'] ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 01:41:35 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 05 Jan 2016 06:41:35 +0000 Subject: [issue24733] Logically Dead Code In-Reply-To: <1437991750.04.0.826367640936.issue24733@psf.upfronthosting.co.za> Message-ID: <20160105064131.17317.69019@psf.io> Roundup Robot added the comment: New changeset f2a846c1b593 by Senthil Kumaran in branch '2.7': Issue24733 - Remove unreachable code in traceback.c https://hg.python.org/cpython/rev/f2a846c1b593 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 01:43:17 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 05 Jan 2016 06:43:17 +0000 Subject: [issue24733] Logically Dead Code In-Reply-To: <1437991750.04.0.826367640936.issue24733@psf.upfronthosting.co.za> Message-ID: <1451976197.92.0.407818566176.issue24733@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks for the report, Pankaj Sharma. Removed in 2.7.11+. ---------- assignee: -> orsenthil nosy: +orsenthil resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 02:03:20 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 Jan 2016 07:03:20 +0000 Subject: [issue26012] pathlib.Path().rglob() is fooled by symlink loops In-Reply-To: <1451974915.38.0.509139033764.issue26012@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I agree it's easiest just not to traverse symlinks matching **. glob.py avoids the errors (but not the senseless recursion) by simply ignoring OSError coming out of listdir(). That might be a good idea anyways (it might even be a simpler way to avoid the PermissionError reported in #24120). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 02:33:18 2016 From: report at bugs.python.org (Andrew Barnert) Date: Tue, 05 Jan 2016 07:33:18 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1451979198.22.0.84826645528.issue25958@psf.upfronthosting.co.za> Andrew Barnert added the comment: > A Mercurial export patch should work with the Reitveld review thing if it is a single revision (and based on a public revision). Well, it's 7 separate commits on a work branch, so I could check in each piece and test it separately, and then I just compared the branch to its parent (default) for the export. But, as I said, I can flatten it into a single diff if the review system can't handle this way. Sorry for making the first patch hard to review, and thanks for reviewing it anyway; I'll fix that with the next one. > You have a stray print() call, probably in Hashable.__subclasshook__(). Thanks; fixed for the next patch. > For a the do-nothing __reversed__() implementation, do you think ?yield from ()? would be clearer than ?while False?? Or even ?return iter(())?? Maybe, but this way is identical to the definition for the do-nothing Iterable.__iter__. > What?s the advantage of having Reversed inherit Iterable? This was discussed briefly... somewhere, maybe the -ideas thread? Pro: If they were independent types, more people would probably register with/inherit from Reversible but not Iterable in error than intentionally. Pro: One less thing for Sequence to inherit from. This was mentioned in the context of adding both Reversible and HalfSequence (or whatever it ends up being called): "class Sequence(Iterable, Reversible, HalfSequence, Sized, Container) seems a little much; "class Sequence(Reversible, HalfSequence, Sized, Container)" is slightly better. Con: It's not completely impossible that a type could be reversible but not iterable. For example, you might have a reversible, and even indexable-with-negative-indicies-only, infinite collection of all the negative numbers. (But nobody could think of an actual _useful_ example of such a type.) Those are all pretty trivial points. When Guido said someone needs to work out where Reversible fits into the hierarchy, and there'd been enough talk without a patch. So I looked at where the discussion seemed to be leaning, couldn't find any additional problems with it when I looked into it further, and did it that way. Guido said he liked it on the Reversible bug, so I did it the same way here. So, no strong arguments or even feelings from anyone; if you've got one, definitely chime in. > How does the subclass hook interact with classes that implement __reversed__() but not __iter__()? I don?t see how the self.assertFalse(issubclass(K, Reversible)) test could pass. Exactly the same way Iterator's handles a class that defines __next__ but not __iter__. I'll double-check that it actually is implemented right before the next patch (and verify that the tests run), but it should be "return _check_methods(C, "__reversed__", "__iter__"). > Should the new Reversed class be excluded from collections.__all__, or is it not worth it? It's Reversible, not Reversed. It's in __all__, and I'm pretty sure it should be there--if it's not worth exporting, it's not worth creating in the first place, or documenting, right? > I find the lambda generator a bit quirky in test_Reversible(). Maybe it would be better as an ordinary non-lambda generator with a yield statement. This is taken from an identical test in test_Iterable, in the same file. > It would be good to have a versionadded notice for Reversible. Definitely; thanks for the catch. I'll add that for the next version of the patch. > I think there should also be one for allowing None for all special methods. I'm assuming you mean in collections.abc, not in the data model, right? The problem is where to put it. The collections.abc docs don't even mention that some of the ABCs have subclass hooks that detect "implicit subclasses", much less tell you which ones do and don't, much less tell you which among those that do treat None specially. Until we add that documentation, there's really nothing to contrast with. Maybe this means we need another bug where we rewrite the collections.abc docs to include all that information, and in the new documentation we can note what prior versions of Python did (or maybe prior versions of CPython--I doubt any major implementations were different, but without checking them all I wouldn't want to guarantee that)? > Instead of self.assertEqual(list(reversed(R())), list(reversed([]))), why not check it is equal to an empty list directly? This might be a case of following the parallelism with test_Iterable too far; I can change it. > In test_contains.py, I would either write lambda: 0 in bc, or use the ?with self.assertRaises()? form. That makes sense; I'll do it. > Finally, if setting a binary operator method to None means that operation is not available, I find it a bit surprising that doing this prevent the other operand?s method from being tried. I guess you don?t want to change the implementation, but perhaps the documentation of the binary operator methods could be clarified. I definitely don't want to change the implementation unless there's a very good reason. Also, if you think it through, from either angle, the way it's always worked makes perfect sense. None (in fact, anything that raises a TypeError when called) always blocks fallback, so it blocks fallback to other.__radd__. Alternatively, the rules for when + looks for __radd__ are very specific and reasonably simple, and TypeError is not one of the things that triggers it. Making None trigger __radd__ would require making one of those two rules more complicated. And what would the benefit be? If you want to trigger fallback, there's already a simple, well-documented, readable way to do that; we don't need another one. And I think the note would be more likely to confuse someone who didn't need it (and maybe make him think he should be defining __add__ = None where he really shouldn't) than to help someone who did. Actual reasonable use cases for __add__ = None are rare enough that I think it's OK that someone has to understand what they're doing and be able to think through the rules and/or know what combinations to test via trial and error before they can use it. But maybe a footnote would work? For example, in the sentence "These functions are only called if the left operand does not support the corresponding operation and the operands are of different types. [2]", we could add another footnote after "does not support the corresponding operation", something like this: > [2] "Does not support" here means has no such method, or has a method that returns NotImplemented, as described above. Do not assign the method to None if you want to force fallback to the right operand's reflected method--that will instead have the opposite effect of explicitly _blocking_ such fallback. Again, thanks for all the notes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 02:39:45 2016 From: report at bugs.python.org (Anil Kulkarni) Date: Tue, 05 Jan 2016 07:39:45 +0000 Subject: [issue26013] Pickle protocol 2.0 not loading in python 3.5 Message-ID: <1451979584.96.0.927777070704.issue26013@psf.upfronthosting.co.za> New submission from Anil Kulkarni: Pickles created with python 3.4.X will not load with python 3.5.X if they include a collections.OrderedDict To reproduce this issue, simply create a pickle of an OrderedDict on python 3.4.3 with protocol=2 and try to open it on 3.5. I have included a simple script to demonstrate this issue. I believe this is related to this bug: https://bugs.python.org/issue18473 As to the real-world implications: The python package Celery uses protocol=2 by default when serializing with pickle, and thus a celery web running 3.5 cannot receive the results of a worker running 3.4 For celery specifically, there is a workaround by setting the PICKLE_PROTOCOL environment variable, but this is a core python issue. P.S. This is the first bug I've filed with python so please let me know if there's something else I should be including. Thanks! ---------- files: b.py messages: 257524 nosy: anilredshift priority: normal severity: normal status: open title: Pickle protocol 2.0 not loading in python 3.5 type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file41503/b.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 03:24:49 2016 From: report at bugs.python.org (Eryk Sun) Date: Tue, 05 Jan 2016 08:24:49 +0000 Subject: [issue26004] pip install lifetimes - throwing error and unable to install packages In-Reply-To: <1451897106.72.0.251427221401.issue26004@psf.upfronthosting.co.za> Message-ID: <1451982289.02.0.319760049145.issue26004@psf.upfronthosting.co.za> Eryk Sun added the comment: You can build NumPy with only a C compiler, but it won't have accelerated BLAS/LAPACK. However, lifetimes requires SciPy, which in turn requires Fortran. This is a common requirement with a lot of the scientific-computing stack, so you may as well choose a complete solution such as Anaconda. That said, if you just need a few packages, then Christoph Gohlke provides an extensive collection of wheels [1]. For example, I have a directory with the following wheels downloaded from Christoph's site: C:\>dir /b Z:\Python\wheel matplotlib-1.5.0-cp35-none-win_amd64.whl numpy-1.10.2+mkl-cp35-none-win_amd64.whl pandas-0.17.1-cp35-none-win_amd64.whl scipy-0.16.1-cp35-none-win_amd64.whl I'll test installing lifetimes and matplotlib in a virtual environment: C:\>py -3 -m venv --symlinks C:\Temp\env35 C:\>C:\Temp\env35\Scripts\activate.bat The command-line option "-f directory" makes pip look for packages in a local directory: (env35) C:\>pip install -f Z:\Python\wheel lifetimes matplotlib Collecting lifetimes Using cached Lifetimes-0.1.6.3.tar.gz Collecting matplotlib Collecting numpy (from lifetimes) Collecting scipy (from lifetimes) Collecting pandas>=0.14 (from lifetimes) Collecting pyparsing!=2.0.4,>=1.5.6 (from matplotlib) Downloading pyparsing-2.0.7-py2.py3-none-any.whl Collecting pytz (from matplotlib) Using cached pytz-2015.7-py2.py3-none-any.whl Collecting python-dateutil (from matplotlib) Using cached python_dateutil-2.4.2-py2.py3-none-any.whl Collecting cycler (from matplotlib) Downloading cycler-0.9.0-py2.py3-none-any.whl Collecting six>=1.5 (from python-dateutil->matplotlib) Using cached six-1.10.0-py2.py3-none-any.whl Installing collected packages: numpy, scipy, six, python-dateutil, pytz, pandas, lifetimes, pyparsing, cycler, matplotlib Running setup.py install for lifetimes Successfully installed cycler-0.9.0 lifetimes-0.1.6.3 matplotlib-1.5.0 numpy-1.10.2 pandas-0.17.1 pyparsing-2.0.7 python-dateutil-2.4.2 pytz-2015.7 scipy-0.16.1 six-1.10.0 [1]: http://www.lfd.uci.edu/~gohlke/pythonlibs ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 04:18:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Jan 2016 09:18:35 +0000 Subject: [issue26013] Pickle protocol 2.0 not loading in python 3.5 In-Reply-To: <1451979584.96.0.927777070704.issue26013@psf.upfronthosting.co.za> Message-ID: <1451985515.78.0.997536531372.issue26013@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your report Anil. Python 3.4.3 creates incorrect pickle with protocol 2 (it can't be load in Python 2). issue18473 fixed pickling with protocol 2 in Python 3, but broke loading broken pickles created in unpatched versions of Python 3. Here is a patch that allows to load such broken pickles. But it is too late to fix Python 3.4, it can get only security fixes. You have Celery specific workaround. More general workaround is to update _compact_pickle.IMPORT_MAPPING, e.g.: import _compact_pickle _compact_pickle.IMPORT_MAPPING.update({ 'UserDict': 'collections', 'UserList': 'collections', 'UserString': 'collections', 'whichdb': 'dbm', 'StringIO': 'io', 'cStringIO': 'io', }) Note that you have to set mapping not just for one module name like 'UserList', but for all 'UserDict', 'UserList', and 'UserString', because it is not predicable to what module name 'collections' is mapped in Python 3.4.3. ---------- assignee: -> serhiy.storchaka components: +Library (Lib) keywords: +patch nosy: +alexandre.vassalotti, pitrou, serhiy.storchaka stage: -> patch review versions: +Python 3.6 Added file: http://bugs.python.org/file41504/unpickle_broken_import.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 06:29:55 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Jan 2016 11:29:55 +0000 Subject: [issue20440] Use the Py_SETREF macro In-Reply-To: <1391019258.76.0.341506038923.issue20440@psf.upfronthosting.co.za> Message-ID: <1451993395.21.0.386201482655.issue20440@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The final patch replaces the code that equivalent to the Py_SETREF macro by using the Py_SETREF macro. There are no bugs, the patch only makes the correct code cleaner. If I'll not got a review, I'll just close this issue. ---------- versions: -Python 2.7, Python 3.5 Added file: http://bugs.python.org/file41505/py_setref_extra3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 07:11:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Jan 2016 12:11:19 +0000 Subject: [issue17394] Add slicing support to collections.deque In-Reply-To: <1362972021.66.0.443403979058.issue17394@psf.upfronthosting.co.za> Message-ID: <1451995879.73.0.554480086158.issue17394@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file41495/deque_slices.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 07:11:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Jan 2016 12:11:34 +0000 Subject: [issue17394] Add slicing support to collections.deque In-Reply-To: <1362972021.66.0.443403979058.issue17394@psf.upfronthosting.co.za> Message-ID: <1451995894.62.0.265769257235.issue17394@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file41506/deque_slices.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 07:54:21 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 05 Jan 2016 12:54:21 +0000 Subject: [issue26010] document CO_* constants In-Reply-To: <1451944023.51.0.951612152691.issue26010@psf.upfronthosting.co.za> Message-ID: <1451998461.34.0.109447809704.issue26010@psf.upfronthosting.co.za> Yury Selivanov added the comment: > This is a follow up to issue #26010. The correct issue # is 25813 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 08:04:26 2016 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 05 Jan 2016 13:04:26 +0000 Subject: [issue26014] Guide users to the newer package install instructions Message-ID: <1451999065.99.0.467691766338.issue26014@psf.upfronthosting.co.za> New submission from Nick Coghlan: The up to date module installation docs are at: * https://docs.python.org/2/installing/index.html * https://docs.python.org/3/installing/index.html However, legacy deep links still resolve to the old docs: * https://docs.python.org/2/install/index.html * https://docs.python.org/3/install/index.html Those link out to packaging.python.org, the link is buried in a longish note, rather than being highlighted as a more obvious See Also link. The top level landing page in the Python 2.7 docs also still links to the legacy docs rather than the new ones, and the "(Legacy)" notation hasn't been appended to the headings on the legacy docs the way it has in 3.x. There's a few long hanging fruit for cleanup here: * add See Also links to the modern docs from the legacy docs * append the (Legacy) suffix in the 2.x docs * fix the 2.x top level docs page to link to the new docs rather than the legacy ones * link to the legacy docs from the distutils package docs in 2.7 (as has already been done in 3.x) ---------- assignee: docs at python components: Documentation messages: 257529 nosy: docs at python, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Guide users to the newer package install instructions type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 09:47:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Jan 2016 14:47:37 +0000 Subject: [issue26015] Add new tests for pickling iterators of mutable sequences Message-ID: <1452005257.2.0.950563811675.issue26015@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch updates tests for iterators of mutable sequences. Now tested iterators in all four states (initial, running, empty and exhausted), and tested that unpickled iterator is linked with a sequence, not with an independed copy (as in case of dict iterators). Note that there is a difference in the behavior of exhausted array iterator from other iterators. Perhaps this should be changed. ---------- components: Tests files: iterators_pickle_tests.patch keywords: patch messages: 257530 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Add new tests for pickling iterators of mutable sequences type: enhancement versions: Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41507/iterators_pickle_tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 09:47:59 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Jan 2016 14:47:59 +0000 Subject: [issue25776] More compact pickle of iterators etc In-Reply-To: <1449052155.68.0.447852149746.issue25776@psf.upfronthosting.co.za> Message-ID: <1452005279.39.0.992809374233.issue25776@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Add new tests for pickling iterators of mutable sequences _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 09:52:01 2016 From: report at bugs.python.org (Jason Madden) Date: Tue, 05 Jan 2016 14:52:01 +0000 Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL certificate In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za> Message-ID: <1452005521.25.0.63607816923.issue25940@psf.upfronthosting.co.za> Changes by Jason Madden : ---------- nosy: +jmadden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 10:05:36 2016 From: report at bugs.python.org (=?utf-8?b?7J207Iuc66eMIChFY21hWHAp?=) Date: Tue, 05 Jan 2016 15:05:36 +0000 Subject: [issue26016] io.TextIOWrapper.tell() report 65bit number when mix readline() + tell() Message-ID: <1452006336.5.0.310653434385.issue26016@psf.upfronthosting.co.za> New submission from ??? (EcmaXp): I did test on - Python 3.5.1 on Windows 64 Bit and 32 Bit (Machine A) - Python 3.4.4 on Windows 32 Bit (Machine A) - Python 3.4.3+ on Ubuntu 15.10 64 Bit (Virtual Machine on Machine A) - Python 3.4.2 on Machine B and C - Python 3.3.5 on Windows 32 Bit (Machine A) I did test but not produce bug. (report 8 correctly) - Python 3.2.5 on Windows 32 Bit (Machine A) - Python 3.1.4 on Windows 32 Bit (Machine A) - Python 2.7.10 on Windows 64 Bit (Machine A) Machine A: i7-5775C with Windows 10 (build 10586.36) 64 Bit Machine B: http://www.tutorialspoint.com/execute_python3_online.php Machine C: https://repl.it/languages/python3 Code are here import io with io.TextIOWrapper(io.BytesIO(b'.\r\n...\r\n\r\n\r\n')) as fp: fp.readline() # '.\n' fp.readline() # '......\n' print(fp.tell()) # 18446744073709551628 = 0x10000000000000009 Not only those string produce bug, also adding more dot make produce bug sometimes. ---------- components: IO, Library (Lib) messages: 257531 nosy: ??? (EcmaXp) priority: normal severity: normal status: open title: io.TextIOWrapper.tell() report 65bit number when mix readline() + tell() type: behavior versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 10:07:12 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 05 Jan 2016 15:07:12 +0000 Subject: [issue26016] io.TextIOWrapper.tell() report 65bit number when mix readline() + tell() In-Reply-To: <1452006336.5.0.310653434385.issue26016@psf.upfronthosting.co.za> Message-ID: <1452006432.58.0.101351547026.issue26016@psf.upfronthosting.co.za> STINNER Victor added the comment: Yeah, it's expected that tell() can return big numbers. It returns a black box "cookie". https://docs.python.org/dev/library/io.html#id3 https://docs.python.org/dev/library/io.html#io.TextIOWrapper ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 10:10:24 2016 From: report at bugs.python.org (=?utf-8?b?7J207Iuc66eMIChFY21hWHAp?=) Date: Tue, 05 Jan 2016 15:10:24 +0000 Subject: [issue26016] io.TextIOWrapper.tell() report 65bit number when mix readline() + tell() In-Reply-To: <1452006336.5.0.310653434385.issue26016@psf.upfronthosting.co.za> Message-ID: <1452006624.44.0.955607455333.issue26016@psf.upfronthosting.co.za> ??? (EcmaXp) added the comment: second fp.readline() # '......\n' is actaully '...\n' mistake ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 10:30:32 2016 From: report at bugs.python.org (Alessandro Cucci) Date: Tue, 05 Jan 2016 15:30:32 +0000 Subject: [issue19475] Add timespec optional flag to datetime isoformat() to choose the precision In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za> Message-ID: <1452007832.17.0.445708199483.issue19475@psf.upfronthosting.co.za> Alessandro Cucci added the comment: up ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 12:33:15 2016 From: report at bugs.python.org (Nikolaus Rath) Date: Tue, 05 Jan 2016 17:33:15 +0000 Subject: [issue22499] [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636 In-Reply-To: <1411694670.5.0.645076106925.issue22499@psf.upfronthosting.co.za> Message-ID: <1452015195.15.0.737115507049.issue22499@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Stefan, sorry for ignoring your earlier reply. I somehow missed the question at the end. I believe that users of the Python module are *not* expected to make use of the WANT_READ, WANT_WRITE flags. Firstly because the documentation (of Python's ssl module) doesn't say anything about that, and secondly because the code that's necessary to handle these flags is a prime example for complexity that is imposed by the C API that should be hidden to Python users. That said, could you give a more specific reference to the O'Relly book (and maybe even page or chapter)? At the moment it's a little hard for me to follow the rest of your message. Essentially, if I'm trying to write to a non-blocking, Python SSL socket, I would expect that this either succeeds or raises SSL_WANT_WRITE/READ. Not having read the book, it seems to me this is the only information that's useful to a Python caller. In what situation would you need the more exact state that your C example tracks? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 12:43:16 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 05 Jan 2016 17:43:16 +0000 Subject: [issue26017] Update https://docs.python.org/3/installing/index.html to always quote arguments Message-ID: <1452015796.73.0.274069830205.issue26017@psf.upfronthosting.co.za> New submission from Brett Cannon: If you look at https://docs.python.org/3/installing/index.html it lists two commands: python -m pip install SomePackage==1.0.4 # specific version python -m pip install 'SomePackage>=1.0.4' # minimum version If you notice that beyond the change from `==` to `>=`, you will notice one quotes its argument while the other one doesn't. This is a UNIX shell thing due to what `>` means. But if you don't know how the UNIX shell works this could be easily overlooked. It would be best to simply quote both examples and avoid people messing up by leaving off the quotes. ---------- assignee: docs at python components: Documentation messages: 257536 nosy: alexis, brett.cannon, docs at python, dstufft, eric.araujo, lemburg, ncoghlan, paul.moore, tarek priority: normal severity: normal stage: needs patch status: open title: Update https://docs.python.org/3/installing/index.html to always quote arguments type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 12:55:43 2016 From: report at bugs.python.org (Zachary Ware) Date: Tue, 05 Jan 2016 17:55:43 +0000 Subject: [issue26017] Update https://docs.python.org/3/installing/index.html to always quote arguments In-Reply-To: <1452015796.73.0.274069830205.issue26017@psf.upfronthosting.co.za> Message-ID: <1452016543.62.0.287802425324.issue26017@psf.upfronthosting.co.za> Zachary Ware added the comment: I'd also suggest using double quotes ("); single quotes don't work on Windows. C:\>echo 'test>=test' C:\>dir /b test* test' C:\>type "test'" 'test ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 14:23:49 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 Jan 2016 19:23:49 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1452021829.32.0.368995033327.issue25958@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm regenerating the patch in the hope that it will trigger the code review hook. ---------- Added file: http://bugs.python.org/file41508/abarnert-patch-regenerated.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 14:28:47 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 05 Jan 2016 19:28:47 +0000 Subject: [issue20440] Use the Py_SETREF macro In-Reply-To: <1391019258.76.0.341506038923.issue20440@psf.upfronthosting.co.za> Message-ID: <20160105192843.30354.10224@psf.io> Roundup Robot added the comment: New changeset 1118dfcbcc35 by Serhiy Storchaka in branch 'default': Issue #20440: Cleaning up the code by using Py_SETREF. https://hg.python.org/cpython/rev/1118dfcbcc35 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 14:34:57 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Jan 2016 19:34:57 +0000 Subject: [issue20440] Use the Py_SETREF macro In-Reply-To: <1391019258.76.0.341506038923.issue20440@psf.upfronthosting.co.za> Message-ID: <1452022497.41.0.545878517323.issue20440@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The commit doesn't include changes for dictobject.c, setobject.c and _sqlite/cache.c (I had forgot to exclude them from the patch before uploading). Dict and set code is performance critical, and using Py_XDECREF instead of Py_DECREF can affect performance. The code in _sqlite would use Py_SETREF in less obvious way, it is better to left it as is. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 14:53:28 2016 From: report at bugs.python.org (Anil Kulkarni) Date: Tue, 05 Jan 2016 19:53:28 +0000 Subject: [issue26013] Pickle protocol 2.0 not loading in python 3.5 In-Reply-To: <1451979584.96.0.927777070704.issue26013@psf.upfronthosting.co.za> Message-ID: <1452023608.82.0.370649145641.issue26013@psf.upfronthosting.co.za> Anil Kulkarni added the comment: Hi Serhiy, I have done some more investigation this morning and I have come across two distinct issues. The first is that pickles (specifically the pickle in my earlier message) created in python 3.0->3.4.3 do not load on python 2.7.10. The exception is 3.5.1, which produces a pickle that DOES load on 2.7.10 This is unfortunate but not a regression The second issue is that pickles created by python 3.0->3.4.3 do NOT load in python 3.5 This is a regression, in the sense that the pickle created by 3.0->3.4.3 is compatible with every other version of python (I haven't tested every single combination here, but several) >From the language perspective, it may be that 3.4.X has incorrect code, but from a compatibility perspective, 3.5 is breaking the promise that pickles are compatible across versions of python. I write this as justification that python 3.5 should fix this regression in compatibility with 3.0 -> 3.4.3. At the very least 3.5 should have a shim behavior to fallback and allow it to import these pickles correctly. Thanks, Anil ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 15:04:18 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Jan 2016 20:04:18 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1452024258.3.0.528772909263.issue25958@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Note that setting some special methods (such as __copy__, __deepcopy__, __reduce_ex__, __reduce__, __setstate__, etc) to None has different meaning. The value None is just ignored and corresponding operation is fall back to other methods. For example copy.deepcopy() uses __reduce_ex__ if __deepcopy__ is None, __reduce__ if __reduce_ex__ is None. May be this should be changed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 15:06:02 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 Jan 2016 20:06:02 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1452024362.19.0.644074874027.issue25958@psf.upfronthosting.co.za> Guido van Rossum added the comment: FWIW, Martin's review was much more extensive. I'm looking forward to the flat version of your next patch, Andrew! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 15:13:22 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 Jan 2016 20:13:22 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1452024362.19.0.644074874027.issue25958@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: In response to Serhiy's comment regarding __copy__ etc.: while the distinction is somewhat unfortunate, I think it's too late to make this more consistent. I think it's fine that the special methods used by copy and pickle protocols behave somewhat differently -- that's a totally different area anyways (and not directly supported by the core language). In contrast, __hash__, __iter__, __contains__, __reversed__, __iadd__ etc. are much more core to the language (representing either builtin functions or operations). Plus here we really need a way to signal the difference between "not defined here so fall back on either a superclass or a different protocol" and "defined here as not existing so cause an error when used". So I don't think there's anything actionable here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 15:20:23 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 05 Jan 2016 20:20:23 +0000 Subject: [issue26016] io.TextIOWrapper.tell() report 65bit number when mix readline() + tell() In-Reply-To: <1452006336.5.0.310653434385.issue26016@psf.upfronthosting.co.za> Message-ID: <1452025223.53.0.708427167737.issue26016@psf.upfronthosting.co.za> Martin Panter added the comment: The documentation for tell() says that it returns an opaque number. Depending on the codec used, it might have to record the state of the text decoder, CRLF decoder, byte position, etc, all in that number. So I don?t think the return value being large is a bug. Perhaps the change in behaviour from Python 2 is due to Issue 11114. Also, Issue 25849 was recently opened about text file seeking. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 15:32:55 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 05 Jan 2016 20:32:55 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1452025975.05.0.92778002423.issue25958@psf.upfronthosting.co.za> Raymond Hettinger added the comment: There is already a precedent for None, but it would have been nicer to use NotImplemented. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 15:33:16 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 Jan 2016 20:33:16 +0000 Subject: [issue25637] Move non-collections-related ABCs out of collections.abc In-Reply-To: <1447701682.74.0.653642972551.issue25637@psf.upfronthosting.co.za> Message-ID: <1452025996.39.0.0787532179597.issue25637@psf.upfronthosting.co.za> Guido van Rossum added the comment: Honestly I think this such a slippery slope that I prefer keeping them in collections.abc. The main reason that we have Iterable and Iterator is that they are closely related to real collections (e.g. Sequence, Set, Mapping). And generators are related to iterators. And so on. To me the force that wants to keep abc.py purely about *implementing* ABCs is stronger than the desire to have only things that really are ABCs for collection types in collections.abc. The types.py module is a bunch of crap that we can't get rid of yet but it should not be used for anything new. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 15:34:42 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 Jan 2016 20:34:42 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1452025975.05.0.92778002423.issue25958@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: The idea of using NotImplemented was already discussed (IIR in python-ideas). I really don't like it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 15:58:18 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Jan 2016 20:58:18 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1452027498.35.0.904192342844.issue25958@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Needed tests for Hashable, Awaitable, Coroutine, AsyncIterable, AsyncIterator, Iterator, Generator, Sized, Container, Callable. The patch adds some tests for __iadd__ and __eq__. I think needed tests for a number of other special methods. In particular should be tested a classes without __iadd__, but with __add__ but to None; with __radd__, but with __add__ set to None; without __add__, but with __radd__ set to None; with __eq__, but with __ne__ set to None, etc. Added other comments on Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 16:02:46 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Jan 2016 21:02:46 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1452027766.77.0.0574029175424.issue25958@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What if use None and NotImplemented as different signals: "not defined here so fall back on either a superclass or a different protocol", and "not defined here so fail without falling back"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 16:05:59 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 Jan 2016 21:05:59 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1452027766.77.0.0574029175424.issue25958@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: No. Simply No. Nobody will be able to remember which means which. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 16:09:02 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 05 Jan 2016 21:09:02 +0000 Subject: [issue25637] Move non-collections-related ABCs out of collections.abc In-Reply-To: <1447701682.74.0.653642972551.issue25637@psf.upfronthosting.co.za> Message-ID: <1452028142.55.0.585662191904.issue25637@psf.upfronthosting.co.za> Brett Cannon added the comment: So leave Callable and Coroutine there and if I add a context manager ABC put it in collections.abc as well? Or should we put Callable and Coroutine in functools and a context manager one in contextlib (or Coroutine in asyncio)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 16:14:10 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 Jan 2016 21:14:10 +0000 Subject: [issue25637] Move non-collections-related ABCs out of collections.abc In-Reply-To: <1452028142.55.0.585662191904.issue25637@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I think ContextManager should be in contextlib. I don't want to put anything in functools. Coroutine doesn't belong in asyncio, it's more fundamental (closely related to Generator). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 16:14:59 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 05 Jan 2016 21:14:59 +0000 Subject: [issue25637] Move non-collections-related ABCs out of collections.abc In-Reply-To: <1447701682.74.0.653642972551.issue25637@psf.upfronthosting.co.za> Message-ID: <1452028499.5.0.521101223625.issue25637@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the input everyone! ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 16:18:09 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Jan 2016 21:18:09 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1452028689.79.0.129049128121.issue25958@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: True, even I were not sure which should mean which. ;) > When I manually trigger the code in typeobject.c:5827, I get a segfault; I'm surprised no test triggered that. I think this triggered one of Victor's guards, added to catch such sort of errors. In this case the function both raises an exception and returns a result. If not catch such sort of error, it can cause unexpected errors or very strange results during executing unrelated code, so crashing as early as possible is lesser evil. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 16:19:54 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 05 Jan 2016 21:19:54 +0000 Subject: [issue25609] Add a ContextManager ABC and type In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za> Message-ID: <1452028793.99.0.658348889526.issue25609@psf.upfronthosting.co.za> Brett Cannon added the comment: In issue #25637, Guido said he didn't want to move stuff out of collections.abc, so the context manager ABC will go into contextlib. To answer Martin's point, I could make __exit__ abstract to begin with to make people override it properly. The only reason I thought of providing a default implementation is that it inherently isn't required to be implemented to match the context manager interface/protocol. But as you pointed out, the usefulness of a context manager is derived from doing stuff in __exit__(), so I will make it abstract. ---------- dependencies: +Move non-collections-related ABCs out of collections.abc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 16:20:14 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 05 Jan 2016 21:20:14 +0000 Subject: [issue25609] Add a ContextManager ABC and type In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za> Message-ID: <1452028814.29.0.731693386022.issue25609@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 16:23:59 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Jan 2016 21:23:59 +0000 Subject: [issue26013] Pickle protocol 2.0 not loading in python 3.5 In-Reply-To: <1451979584.96.0.927777070704.issue26013@psf.upfronthosting.co.za> Message-ID: <1452029039.83.0.761542653585.issue26013@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I agree, and the provided is purposed to fix this issue. In the previous message I just proposed a workaround for those who can't wait 3.5.2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 16:57:42 2016 From: report at bugs.python.org (Anil Kulkarni) Date: Tue, 05 Jan 2016 21:57:42 +0000 Subject: [issue26013] Pickle protocol 2.0 not loading in python 3.5 In-Reply-To: <1451979584.96.0.927777070704.issue26013@psf.upfronthosting.co.za> Message-ID: <1452031062.77.0.950303115734.issue26013@psf.upfronthosting.co.za> Anil Kulkarni added the comment: Ah, sorry I misunderstood. Thanks for the quick turnaround! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 17:06:44 2016 From: report at bugs.python.org (Andrew Barnert) Date: Tue, 05 Jan 2016 22:06:44 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1452031604.81.0.0594264611438.issue25958@psf.upfronthosting.co.za> Andrew Barnert added the comment: The second patch takes into account all the issues raised by Martin and Guido, as well as some other changes that didn't make it into the first patch because Windows hates me. And it should be flattened into a single commit, and therefore should hopefully work with Rietveld out of the box. It passes the test suite on Windows and Cygwin (and on OS X, but that's a slightly older version of the changes than what's in this flattened patch). I think it's still an open question whether Reversible should inherit Iterable. In the current patch, as in the first, it does. I'll go over Serhiy's Reitveld comments to see if there's anything I missed, and, if so, address it in a third attempt. On Serhiy's test suggestions: * I don't think we need to repeat the same tests on every ABC. That seems more likely to introduce copy-paste bugs than to catch anything, especially since the ABCs now all share the same code, but the tests couldn't. * Likewise for adding repetitive tests on more __spam__, __ispam__, and __rspam__ methods. * However, he's definitely right that there are other kinds of fallback worth testing, like __ne__ -> __eq__. I'll review the different kinds of fallback more carefully and make sure we have tests for each case. ---------- Added file: http://bugs.python.org/file41509/patch2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 17:12:20 2016 From: report at bugs.python.org (Andrew Barnert) Date: Tue, 05 Jan 2016 22:12:20 +0000 Subject: [issue22268] add dedicated functions mrohasattr and mrogetattr In-Reply-To: <1408918667.95.0.696624554898.issue22268@psf.upfronthosting.co.za> Message-ID: <1452031940.6.0.649143763938.issue22268@psf.upfronthosting.co.za> Andrew Barnert added the comment: See #25958, which incorporates a similar refactoring in service of making all of the subclasshooks in collections.abc handle None the same way. We definitely do want something public in the abc module like this, rather than the private function in collections.abc that I wrote, especially given the discussion about moving a bunch of the ABCs to other modules. ---------- nosy: +abarnert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 17:23:45 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 Jan 2016 22:23:45 +0000 Subject: [issue22268] add dedicated functions mrohasattr and mrogetattr In-Reply-To: <1408918667.95.0.696624554898.issue22268@psf.upfronthosting.co.za> Message-ID: <1452032625.86.0.767835416468.issue22268@psf.upfronthosting.co.za> Guido van Rossum added the comment: Honestly I don't think this is worth it. The proposed functions seem to fall firmly in the territory of "not every three useful lines of code are worth a stdlib function". ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 17:33:28 2016 From: report at bugs.python.org (Stefan Krah) Date: Tue, 05 Jan 2016 22:33:28 +0000 Subject: [issue22499] [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636 In-Reply-To: <1411694670.5.0.645076106925.issue22499@psf.upfronthosting.co.za> Message-ID: <1452033208.62.0.81882254268.issue22499@psf.upfronthosting.co.za> Stefan Krah added the comment: https://books.google.com/books?id=IIqwAy4qEl0C&redir_esc=y , page 159 ff. Modules/_ssl.c:_ssl__SSLSocket_write_impl() just raises PySSLWantReadError etc. if the socket is non-blocking. IOW, it's a thin wrapper around SSL_write(). So yes, I think you do need complete error handling on the Python level. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 17:39:41 2016 From: report at bugs.python.org (John Szakmeister) Date: Tue, 05 Jan 2016 22:39:41 +0000 Subject: [issue14574] SocketServer doesn't handle client disconnects properly In-Reply-To: <1334358462.67.0.980544384901.issue14574@psf.upfronthosting.co.za> Message-ID: <1452033581.32.0.882455445403.issue14574@psf.upfronthosting.co.za> John Szakmeister added the comment: FWIW, I'm seeing the same issue as Jason too, and his solution seems reasonable to me. ---------- nosy: +jszakmeister _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 17:57:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Jan 2016 22:57:35 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1452034655.13.0.578820880323.issue25958@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Without tests you can't be sure that there is no special case in some abstract classes or operators, or that it can't be introduced in future. To decrease the copy-pasting you can use code generation for testing. But I don't know what is the best place for tests. Tests for special methods are scattered though different files: test_binop, test_class, test_compare, test_descr, test_richcmp, test_augassign, test_contains, test_iter, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 18:57:36 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 Jan 2016 23:57:36 +0000 Subject: [issue25966] Bug in asyncio.corotuines._format_coroutine In-Reply-To: <1451321916.38.0.909641421844.issue25966@psf.upfronthosting.co.za> Message-ID: <1452038256.21.0.516240122372.issue25966@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks! I've fixed this in the git repo now (https://github.com/python/asyncio/commit/0c3e6ec0340f45d5f6989391358d44b8e974858e). It will be merged into the CPython repo at the next opportunity (before 3.5.2). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 18:57:50 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 Jan 2016 23:57:50 +0000 Subject: [issue25966] Bug in asyncio.corotuines._format_coroutine In-Reply-To: <1451321916.38.0.909641421844.issue25966@psf.upfronthosting.co.za> Message-ID: <1452038270.79.0.39246220032.issue25966@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- assignee: -> gvanrossum resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 19:05:01 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 Jan 2016 00:05:01 +0000 Subject: [issue6500] urllib2 maximum recursion depth exceeded In-Reply-To: <1247819174.12.0.0313325803352.issue6500@psf.upfronthosting.co.za> Message-ID: <20160106000458.8281.32671@psf.io> Roundup Robot added the comment: New changeset fbea8ff8db5e by Berker Peksag in branch '2.7': Issue #6500: Fix "maximum recursion depth exceeded" error caused by Request.__getattr__() https://hg.python.org/cpython/rev/fbea8ff8db5e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 19:05:36 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 06 Jan 2016 00:05:36 +0000 Subject: [issue6500] urllib2 maximum recursion depth exceeded In-Reply-To: <1247819174.12.0.0313325803352.issue6500@psf.upfronthosting.co.za> Message-ID: <1452038736.42.0.200877656979.issue6500@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 19:06:41 2016 From: report at bugs.python.org (Martin von Gagern) Date: Wed, 06 Jan 2016 00:06:41 +0000 Subject: [issue26018] documentation of ZipFile file name encoding Message-ID: <1452038801.7.0.594053315947.issue26018@psf.upfronthosting.co.za> New submission from Martin von Gagern: https://docs.python.org/3/library/zipfile.html#zipfile.ZipFile.write writes: ?Note: There is no official file name encoding for ZIP files. If you have unicode file names, you must convert them to byte strings in your desired encoding before passing them to write(). WinZip interprets all file names as encoded in CP437, also known as DOS Latin.? I think this is wrong in many ways. Firstly, APPNOTE.TXT used to explicitely define CP437 as the standard, and it's still the standard in the absence of general purpose bit 11 and a more specific description using the 0x0008 Extra Field. On the other hand, we do have that general purpose bit these days, so there are now not just one but two well-defined file name encodings. And thirdly, encoding the string to bytes as suggested will in fact lead to a run time error, since ZipInfo expects to do this conversion itself. See work towards issue1734346, starting at commit 8e33f316ce14, for details on when this was addressed in the source code. ---------- assignee: docs at python components: Documentation messages: 257567 nosy: docs at python, gagern priority: normal severity: normal status: open title: documentation of ZipFile file name encoding type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 19:10:26 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 06 Jan 2016 00:10:26 +0000 Subject: [issue25802] Finish deprecating load_module() In-Reply-To: <1449274063.93.0.451300544059.issue25802@psf.upfronthosting.co.za> Message-ID: <1452039026.72.0.708886042726.issue25802@psf.upfronthosting.co.za> Berker Peksag added the comment: issue25802.diff looks good to me (just added a minor comment on Rietveld) ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 19:12:06 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 06 Jan 2016 00:12:06 +0000 Subject: [issue25917] Fixing howto links in docs In-Reply-To: <1450610247.39.0.486318634402.issue25917@psf.upfronthosting.co.za> Message-ID: <1452039126.6.0.176899435289.issue25917@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 19:19:43 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 06 Jan 2016 00:19:43 +0000 Subject: [issue6500] urllib2 maximum recursion depth exceeded In-Reply-To: <1247819174.12.0.0313325803352.issue6500@psf.upfronthosting.co.za> Message-ID: <1452039583.94.0.806842862851.issue6500@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Hi @Berker, This patch breaks the unit tests. Could you confirm (or reject) this? Thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 20:00:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Jan 2016 01:00:13 +0000 Subject: [issue26018] documentation of ZipFile file name encoding In-Reply-To: <1452038801.7.0.594053315947.issue26018@psf.upfronthosting.co.za> Message-ID: <1452042013.1.0.772716252094.issue26018@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 20:02:15 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 01:02:15 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <1452042135.72.0.198905539506.issue22570@psf.upfronthosting.co.za> Guido van Rossum added the comment: Random idea: what if pathlib.Path defined a .path attribute that was a plain string? Then you could write p.path instead of str(p), and "if hasattr(p, 'path'): p = p.path". This would be the new protocol. Advantage is also that DirEntry (returned by the new os.scandir()) already supports it. :-) ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 20:05:03 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 01:05:03 +0000 Subject: [issue23076] list(pathlib.Path().glob("")) fails with IndexError In-Reply-To: <1418860780.4.0.558535328721.issue23076@psf.upfronthosting.co.za> Message-ID: <1452042303.0.0.0810888493417.issue23076@psf.upfronthosting.co.za> Guido van Rossum added the comment: This should be easy to fix. It should raise ValueError. ---------- keywords: +easy nosy: +gvanrossum versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 20:08:21 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 Jan 2016 01:08:21 +0000 Subject: [issue6500] urllib2 maximum recursion depth exceeded In-Reply-To: <1247819174.12.0.0313325803352.issue6500@psf.upfronthosting.co.za> Message-ID: <20160106010817.8289.44904@psf.io> Roundup Robot added the comment: New changeset e2faa18802bb by Berker Peksag in branch '2.7': Issue #6500: Reverting fbea8ff8db5e since it broke tests https://hg.python.org/cpython/rev/e2faa18802bb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 20:10:02 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 06 Jan 2016 01:10:02 +0000 Subject: [issue6500] urllib2 maximum recursion depth exceeded In-Reply-To: <1247819174.12.0.0313325803352.issue6500@psf.upfronthosting.co.za> Message-ID: <1452042602.23.0.537689715739.issue6500@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks, Senthil. I've just reverted fbea8ff8db5e. Sorry for the noise! ---------- resolution: fixed -> stage: resolved -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 20:19:19 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 01:19:19 +0000 Subject: [issue22558] Missing hint to source code - complete In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1452043159.59.0.19354709612.issue22558@psf.upfronthosting.co.za> Guido van Rossum added the comment: Actually uploading a patch for this should be easy, right? ---------- keywords: +easy nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 20:56:14 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Jan 2016 01:56:14 +0000 Subject: [issue6500] urllib2 maximum recursion depth exceeded In-Reply-To: <1247819174.12.0.0313325803352.issue6500@psf.upfronthosting.co.za> Message-ID: <1452045374.95.0.522486007731.issue6500@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: __getattr__() was purposed to handle two lazily created private attributes: __r_type and __r_host. They are set in corresponding get_-methods. Here is a patch that makes __getattr__() to handle only these attributes. ---------- nosy: +serhiy.storchaka stage: needs patch -> patch review Added file: http://bugs.python.org/file41510/issue6500_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 21:03:48 2016 From: report at bugs.python.org (Andrew Barnert) Date: Wed, 06 Jan 2016 02:03:48 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1452045828.9.0.43353216351.issue25958@psf.upfronthosting.co.za> Andrew Barnert added the comment: The attached patch fixes the one wording change from the patch2 review, and makes all the error messages consistent as suggested by Serhiy, and also adds a lot more tests: every way that a special method can fall back should now be tested. (Of course it would be good if someone else went through and made sure I didn't miss anything.) However: > Without tests you can't be sure that there is no special case in some abstract classes or operators, or that it can't be introduced in future. Yes, but there's clearly a cost to maintaining and running 13 copies of each __ispam__ test, and 20 copies of each __rspam__ test. And the benefit is minuscule--if all 13 methods share the same code; it's far more likely that someone will break the __isub__ test than that they'll break the __isub__ code. > But I don't know what is the best place for tests. Tests for special methods are scattered though different files: test_binop, test_class, test_compare, test_descr, test_richcmp, test_augassign, test_contains, test_iter, etc. Yeah, they pretty much have to be scattered around the code. As they are in the attached diff. But I don't think that's a huge problem, except for the poor sap who has to review the patch. :) ---------- Added file: http://bugs.python.org/file41511/patch3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 21:05:12 2016 From: report at bugs.python.org (Andrew Barnert) Date: Wed, 06 Jan 2016 02:05:12 +0000 Subject: [issue26019] collections.abc documentation incomplete Message-ID: <1452045912.74.0.509683701942.issue26019@psf.upfronthosting.co.za> New submission from Andrew Barnert: Some of the modules in collections.abc have a subclass hook that implicitly registers any type that declares the right methods, like Iterator. Others do not, like Sequence. For those that do have the hook, it's not always obvious what methods are tested. And some of them test the methods for truthiness, others only for existence (although #25958 will fix that last bit). The documentation doesn't even mention this, much less describe which ABCs are of which kind. For someone who just wants to know how to write isinstance(arg, Iterable), that's fine. But anyone who wants to create new classes, or integrate third-party classes that weren't ABC-friendly, has to read the collections.abc module source to figure out what they want to do. ---------- assignee: docs at python components: Documentation messages: 257577 nosy: abarnert, docs at python priority: normal severity: normal status: open title: collections.abc documentation incomplete type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 21:18:24 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 06 Jan 2016 02:18:24 +0000 Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL certificate In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za> Message-ID: <1452046704.2.0.242476638618.issue25940@psf.upfronthosting.co.za> Martin Panter added the comment: Koobs: What thing are you suggesting to mock? The remote server perhaps, which is what I want to do too? Here is a patch that implements my local SSL server idea by reusing ThreadedEchoServer. There is one problem with local-server.patch, and I don?t know how to fix it properly. At the end of test_bio_handshake() and test_bio_read_write_data(), the unwrap() call keeps raising SSL_ERROR_SYSCALL and the test hangs in an infinite loop. I could work around this by making the server call unwrap() before shutting the socket down. But it would be better to fix ssl_io_loop() if anyone understands what is going wrong. ---------- Added file: http://bugs.python.org/file41512/local-server.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 21:42:21 2016 From: report at bugs.python.org (Hamish Campbell) Date: Wed, 06 Jan 2016 02:42:21 +0000 Subject: [issue26020] set_display evaluation order doesn't match documented behaviour Message-ID: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> New submission from Hamish Campbell: It looks like the behaviour of set displays do not match behaviour in some cases. The documentation states: "A set display yields a new mutable set object, the contents being specified by either a sequence of expressions or a comprehension. When a comma-separated list of expressions is supplied, its elements are evaluated from left to right and added to the set object. When a comprehension is supplied, the set is constructed from the elements resulting from the comprehension." Note the following: >>> foo = { True, 1 } >>> print(foo) {1} However, if we add elements 'left to right': >>> foo = set() >>> foo.add(True) >>> foo.add(1) >>> print(foo) {True} Note that similar documentation for dict displays produces the expected result. "If a comma-separated sequence of key/datum pairs is given, they are evaluated from left to right to define the entries of the dictionary: each key object is used as a key into the dictionary to store the corresponding datum. This means that you can specify the same key multiple times in the key/datum list, and the final dictionary?s value for that key will be the last one given." >>> foo = {} >>> foo[True] = 'bar' >>> foo[1] = 'baz' >>> print(foo) {True: 'baz'} Which matches the dict display construction: >>> foo = { True: 'bar', 1: 'baz'} >>> print(foo) {True: 'baz'} Note that I've tagged this as a documentation bug, but it seems like the documentation might be the preferred implementation. ---------- assignee: docs at python components: Documentation messages: 257579 nosy: Hamish Campbell, docs at python priority: normal severity: normal status: open title: set_display evaluation order doesn't match documented behaviour versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 21:45:04 2016 From: report at bugs.python.org (Hamish Campbell) Date: Wed, 06 Jan 2016 02:45:04 +0000 Subject: [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452048304.01.0.370334889654.issue26020@psf.upfronthosting.co.za> Hamish Campbell added the comment: Apologies, that first line should read "It looks like the documentation of set displays do not match behaviour in some cases". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 21:50:22 2016 From: report at bugs.python.org (Andrew Barnert) Date: Wed, 06 Jan 2016 02:50:22 +0000 Subject: [issue26019] collections.abc documentation incomplete In-Reply-To: <1452045912.74.0.509683701942.issue26019@psf.upfronthosting.co.za> Message-ID: <1452048622.01.0.232307042196.issue26019@psf.upfronthosting.co.za> Andrew Barnert added the comment: The attached patch is, I think, the smallest change that includes all the necessary information. Of course it will need to be redone if #25958 goes through, with a version-changed note explaining that prior to 3.6 some of the implicit ABCs (maybe with a list) treated None as an abstract method implementation while others didn't. So, this patch is basically a throwaway. But any review comments would still be useful, of course. ---------- keywords: +patch Added file: http://bugs.python.org/file41513/patch26019.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 21:54:07 2016 From: report at bugs.python.org (Hamish Campbell) Date: Wed, 06 Jan 2016 02:54:07 +0000 Subject: [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452048847.64.0.13359194332.issue26020@psf.upfronthosting.co.za> Hamish Campbell added the comment: Note also the differences here: >>> print(set([True, 1])) {True} >>> print({True, 1}) {1} >>> print({x for x in [True, 1]}) {True} ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 22:18:49 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 06 Jan 2016 03:18:49 +0000 Subject: [issue22558] Missing hint to source code - complete In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1452050329.01.0.695957028018.issue22558@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Guido, should we take your comment as approving linking every source, as opposed to only some? This scope issue is the main sticking point for this issue. Otherwise, the standard patch is 3 easy new lines after the :synopsis: (and any 'New in Version x.y' note for the module -- see argparse). The following is Benjamin's patch for #22528. --- a/Doc/library/pdb.rst +++ b/Doc/library/pdb.rst @@ -6,6 +6,9 @@ .. module:: pdb :synopsis: The Python debugger for interactive interpreters. +**Source code:** :source:`Lib/pdb.py` + +-------------- .. index:: single: debugging Friedrich, were you planning to write a patch, once the list of modules is decided on? Or should we invite submissions on the core-mentorship list? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 22:40:53 2016 From: report at bugs.python.org (Emanuel Barry) Date: Wed, 06 Jan 2016 03:40:53 +0000 Subject: [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452051653.27.0.874198643731.issue26020@psf.upfronthosting.co.za> Emanuel Barry added the comment: Set displays appear to be the culprit here: >>> class A: ... count = 0 ... def __init__(self): ... self.cnt = self.count ... type(self).count += 1 ... def __eq__(self, other): ... return type(self) is type(other) ... def __hash__(self): ... return id(type(self)) ... >>> e={A(), A(), A(), A(), A()} >>> e {<__main__.A object at 0x002BB2B0>} >>> list(e)[0].cnt 4 >>> list(e)[0].count 5 >>> A.count = 0 >>> q=set([A(), A(), A(), A(), A()]) >>> q {<__main__.A object at 0x002BB310>} >>> list(q)[0].cnt 0 >>> list(q)[0].count 5 I'm guessing this is an optimization and/or set displays just don't keep ordering at definition time. Do you have a use case where `x == y`/`hash(x) == hash(y)` does not mean that `x` and `y` should be interchangeable? True and 1 are 100% interchangeable, minus their str() output, and my example is very unlikely to ever appear in actual code. Probably just better to fix the docs to specify that sets literals don't check ordering. ---------- nosy: +ebarry versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 23:35:22 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 06 Jan 2016 04:35:22 +0000 Subject: [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452054922.75.0.920029380642.issue26020@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The culprit is the BUILD_SET opcode in Python/ceval.c which unnecessarily loops backwards (it looks like it was copied from the BUILD_TUPLE opcode). ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 00:11:58 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 05:11:58 +0000 Subject: [issue22558] Missing hint to source code - complete In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1452057118.69.0.667059089543.issue22558@psf.upfronthosting.co.za> Guido van Rossum added the comment: It's fine to add a source link to any module for which there is Python source code. I suppose this adds a slight maintenance burden when a module moves (e.g. when a module is turned into a package, or when the subdirectory structure of the Lib directory changes). I'm a little confused about the "New in x.y" note -- why is that connected to the source code link? Of course, the source tells a different story from the docs -- e.g. undocumented implementation details may change, and sometimes the source is hard to understand (on occasion I've been confused myself :-). But Python is open source, so people can always read the source -- I don't see why we should try to make reading the source harder for people who don't yet have the chops to just read it on their own computer! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 00:43:33 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 06 Jan 2016 05:43:33 +0000 Subject: [issue22831] Use "with" to avoid possible fd leaks In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za> Message-ID: <1452059013.44.0.36419650146.issue22831@psf.upfronthosting.co.za> Martin Panter added the comment: I had another look at the five patches you mentioned. I made a couple review comments about expanding the scope of some ?with? statements. There are a couple changes that add explicit file closing, where it was previously up to the garbage collector. I.e. code like open(...).read(). I think those changes are the most important, although they are scattered over the various patches. On the other hand, some of the changes in the test suite, particularly test_dbm_dumb.py and test_xmlrpc.py, hardly seem worth it. The main benefit of the ?with? statement would be if the test code fails, which hopefully won?t happen that often. :) In the test suite, perhaps it would be better to call self.addCleanup(f.close) or similar in many cases. That way you wouldn?t need contextlib.closing() as much, and there would be less file history clutter and ?cavern code?, due to the extra indentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 00:43:39 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 06 Jan 2016 05:43:39 +0000 Subject: [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452059019.95.0.300390532224.issue26020@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +patch Added file: http://bugs.python.org/file41514/build_set.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 02:21:25 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 06 Jan 2016 07:21:25 +0000 Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL certificate In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za> Message-ID: <1452064885.02.0.108579386209.issue25940@psf.upfronthosting.co.za> Martin Panter added the comment: After looking into the unwrap() problem more, I think I understand the problem, and believe making the server call unwrap() is the correct way forward. SSL_ERROR_SYSCALL is Open SSL?s way of saying the connection was shut down insecurely (among other things). So I propose local-server.v2.patch which passes all the tests without hanging. I am inclined to commit my first patch soon, which is fairly simple and should make the buildbots happy. Then people can have a chance to review the second (now third) patch, which is more involved. Does the problem really need to be fixed in the 3.2 branch, or is 3.5+ and 2.7 good enough? ---------- Added file: http://bugs.python.org/file41515/local-server.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 03:10:16 2016 From: report at bugs.python.org (koobs) Date: Wed, 06 Jan 2016 08:10:16 +0000 Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL certificate In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za> Message-ID: <1452067816.84.0.664098313613.issue25940@psf.upfronthosting.co.za> koobs added the comment: As many branches as we can muster, ideally all, at least 3.4, 3.5 default and 2.7 please. Back porting is a massive pain, and downstream OS's want to retain integrity of tests to ensure quality of Python in their respective ecosystems ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 03:46:13 2016 From: report at bugs.python.org (Hamish Campbell) Date: Wed, 06 Jan 2016 08:46:13 +0000 Subject: [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452069973.3.0.759929011441.issue26020@psf.upfronthosting.co.za> Hamish Campbell added the comment: > Do you have a use case where `x == y`/`hash(x) == hash(y)` does not mean that `x` and `y` should be interchangeable? True and 1 are 100% interchangeable, minus their str() output, and my example is very unlikely to ever appear in actual code. No I don't have a use case :) > The culprit is the BUILD_SET opcode in Python/ceval.c which unnecessarily loops backwards (it looks like it was copied from the BUILD_TUPLE opcode). Incidentally, pypy seems to behave the same as reported here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 04:06:00 2016 From: report at bugs.python.org (Brendan Molloy) Date: Wed, 06 Jan 2016 09:06:00 +0000 Subject: [issue20397] distutils --record option does not validate existence of byte-compiled files In-Reply-To: <1390746014.88.0.900467086198.issue20397@psf.upfronthosting.co.za> Message-ID: <1452071160.08.0.19319283482.issue20397@psf.upfronthosting.co.za> Changes by Brendan Molloy : ---------- keywords: +patch Added file: http://bugs.python.org/file41516/20397-head.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 04:06:47 2016 From: report at bugs.python.org (Brendan Molloy) Date: Wed, 06 Jan 2016 09:06:47 +0000 Subject: [issue20397] distutils --record option does not validate existence of byte-compiled files In-Reply-To: <1390746014.88.0.900467086198.issue20397@psf.upfronthosting.co.za> Message-ID: <1452071207.25.0.725589137728.issue20397@psf.upfronthosting.co.za> Changes by Brendan Molloy : Added file: http://bugs.python.org/file41517/20397-py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 04:07:05 2016 From: report at bugs.python.org (Brendan Molloy) Date: Wed, 06 Jan 2016 09:07:05 +0000 Subject: [issue20397] distutils --record option does not validate existence of byte-compiled files In-Reply-To: <1390746014.88.0.900467086198.issue20397@psf.upfronthosting.co.za> Message-ID: <1452071225.45.0.0209333406445.issue20397@psf.upfronthosting.co.za> Brendan Molloy added the comment: I've just uploaded patches for head and 2.7, with relevant unit tests. ---------- nosy: +bbqsrc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 04:07:34 2016 From: report at bugs.python.org (koobs) Date: Wed, 06 Jan 2016 09:07:34 +0000 Subject: [issue20397] distutils --record option does not validate existence of byte-compiled files In-Reply-To: <1390746014.88.0.900467086198.issue20397@psf.upfronthosting.co.za> Message-ID: <1452071254.46.0.746383324212.issue20397@psf.upfronthosting.co.za> Changes by koobs : ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 04:37:23 2016 From: report at bugs.python.org (=?utf-8?q?Torsten_Z=C3=BChlsdorff?=) Date: Wed, 06 Jan 2016 09:37:23 +0000 Subject: [issue26021] Missing IPv6 support for pypi.python.org Message-ID: <1452073043.01.0.523357649838.issue26021@psf.upfronthosting.co.za> New submission from Torsten Z?hlsdorff: Hello, i'm done some research about the impact of missing IPv6 support at the FreeBSD ports-tree, which is the list of supported software for FreeBSD. Python and many libs written in python are supported for FreeBSD, but if you have an IPv6 only server, they are not usable at all. Currently python has the biggest impact on the ports-tree: (https://wiki.freebsd.org/IPv6PortsTODO#TOP_25_hosts_with_missing_IPv6_support) This is because the server pypi.python.org lacks support for IPv6. There is also no AAAA record in DNS: $ drill pypi.python.org aaaa ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 9429 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; pypi.python.org. IN AAAA ;; ANSWER SECTION: pypi.python.org. 6983 IN CNAME prod.python.map.fastly.net. prod.python.map.fastly.net. 5 IN CNAME prod.python.map.fastlylb.net. ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: ;; Query time: 33 msec ;; SERVER: 192.168.0.23 ;; WHEN: Wed Jan 6 10:34:12 2016 ;; MSG SIZE rcvd: 112 Please add IPv6 support to your server(s). If you need any help/feedback/tests i will gladly help you! Thank you very much, Torsten ---------- messages: 257592 nosy: thorny priority: normal severity: normal status: open title: Missing IPv6 support for pypi.python.org type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 04:38:08 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Jan 2016 09:38:08 +0000 Subject: [issue26021] Missing IPv6 support for pypi.python.org In-Reply-To: <1452073043.01.0.523357649838.issue26021@psf.upfronthosting.co.za> Message-ID: <1452073088.23.0.13515268798.issue26021@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 04:38:47 2016 From: report at bugs.python.org (Ram Rachum) Date: Wed, 06 Jan 2016 09:38:47 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <1452073127.82.0.264182529507.issue22570@psf.upfronthosting.co.za> Ram Rachum added the comment: I thought about it some more, and personally I'd prefer each function to do `str(path)` internally rather than `if hasattr(p, 'path'): p = p.path`. Even if it means we'll have to deal with "where did that file named '' come from?!" errors. I think it's clumsy that the path protocol is to access `path.path`. We already have a protocol for getting a string out of an object and it's `str(object)`. I think we should use it even if it makes debugging harder in the case where someone mistakenly passes a non-path object to a function that wants a path. (And without using `isinstance` either.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 04:39:15 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Jan 2016 09:39:15 +0000 Subject: [issue26021] Missing IPv6 support for pypi.python.org In-Reply-To: <1452073043.01.0.523357649838.issue26021@psf.upfronthosting.co.za> Message-ID: <1452073155.99.0.0324374227717.issue26021@psf.upfronthosting.co.za> STINNER Victor added the comment: FYI pypi.python.org is now managed by the Python infra team. See for example https://mail.python.org/mailman/listinfo/infrastructure and https://status.python.org/ ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 05:41:45 2016 From: report at bugs.python.org (Donald Stufft) Date: Wed, 06 Jan 2016 10:41:45 +0000 Subject: [issue26021] Missing IPv6 support for pypi.python.org In-Reply-To: <1452073043.01.0.523357649838.issue26021@psf.upfronthosting.co.za> Message-ID: <1452076905.79.0.858989651396.issue26021@psf.upfronthosting.co.za> Donald Stufft added the comment: This isn't a CPython issue and doesn't really belong on the issue tracker. To answer the question though, PyPI will support IPv6 as soon as our CDN provider has support for IPv6 and until they do, it will be IPv4 only. ---------- resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 05:57:42 2016 From: report at bugs.python.org (=?utf-8?q?Torsten_Z=C3=BChlsdorff?=) Date: Wed, 06 Jan 2016 10:57:42 +0000 Subject: [issue26021] Missing IPv6 support for pypi.python.org In-Reply-To: <1452073043.01.0.523357649838.issue26021@psf.upfronthosting.co.za> Message-ID: <1452077862.29.0.131030759268.issue26021@psf.upfronthosting.co.za> Torsten Z?hlsdorff added the comment: Thanks for your response Donald! Which one is your CDN and how will contact it about the missing IPv6 support? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 06:05:16 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Jan 2016 11:05:16 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <1452078316.64.0.845821385911.issue22570@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: `str(object)` is not a protocol for getting a string out of an object. It's a protocol for getting a string for print(). __str__ is defined for every object and therefore is useless for getting a string out of "string-like" object (as __float__ for floats and __bytes__ for bytes). Perhaps we need a new special method __string__ that relates to __str__ as __index__ to __int__. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 06:08:01 2016 From: report at bugs.python.org (Donald Stufft) Date: Wed, 06 Jan 2016 11:08:01 +0000 Subject: [issue26021] Missing IPv6 support for pypi.python.org In-Reply-To: <1452073043.01.0.523357649838.issue26021@psf.upfronthosting.co.za> Message-ID: <1452078481.75.0.668164487849.issue26021@psf.upfronthosting.co.za> Donald Stufft added the comment: Our provider is Fastly, I don't believe contacting them will do any good though. They are working on getting IPv6 support but there is no ETA at the moment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 06:08:21 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Jan 2016 11:08:21 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <1452078501.63.0.296947355834.issue22570@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here the aim is really to distinguish path-like objects from other objects, not to accept arbitrary strings. A ".path" attribute sounds like the wrong name, though: a Path has a path? And the Path's path is not a Path? Ouch :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 06:54:26 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 Jan 2016 11:54:26 +0000 Subject: [issue18918] help('FILES') finds no documentation In-Reply-To: <1378269620.52.0.763555902483.issue18918@psf.upfronthosting.co.za> Message-ID: <20160106115423.8269.16703@psf.io> Roundup Robot added the comment: New changeset 0792a0ad7f22 by Senthil Kumaran in branch '2.7': Fix issue18918 : Attach the pydoc documentation for 'FILES' topic. https://hg.python.org/cpython/rev/0792a0ad7f22 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 06:57:41 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 06 Jan 2016 11:57:41 +0000 Subject: [issue18918] help('FILES') finds no documentation In-Reply-To: <1378269620.52.0.763555902483.issue18918@psf.upfronthosting.co.za> Message-ID: <1452081461.28.0.599831229635.issue18918@psf.upfronthosting.co.za> Senthil Kumaran added the comment: The bltin-file-objects was not referenced in pyspecific.py from which this data was generated. Added it and fixed it. Verified that it is available in 2.7 now. ---------- nosy: +orsenthil resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 07:05:24 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 06 Jan 2016 12:05:24 +0000 Subject: [issue22558] Missing hint to source code - complete In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1452081924.81.0.263051157453.issue22558@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If there is a New-in note (which follows Synopsis), then (to be consistent) the Source note should follow it. If not (the normal situation), then Source follows Synopsis directly. A point in favor of linking all Python sources from the docs is that default single users installs are much harder to access on Windows than they used to be: /Users/Name/[Appdata - hidden by default]/Roaming?/Python/Pythonxy (I believe) versus the old /Pythonxy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 07:05:35 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 06 Jan 2016 12:05:35 +0000 Subject: [issue22558] Missing hint to source code - complete In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1452081935.76.0.190340623749.issue22558@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 07:26:47 2016 From: report at bugs.python.org (Roland Eichman) Date: Wed, 06 Jan 2016 12:26:47 +0000 Subject: [issue26022] string.replace(' ', ' ') has to be called 2 times before it works Message-ID: <1452083207.08.0.345721672406.issue26022@psf.upfronthosting.co.za> New submission from Roland Eichman: Windows 10 python 3.5 small function in a small module contained a string len(str1) == 5000 {approx} str1 = str1.replace(' ',' ') did not work added, via copy & paste, a second identical line str1 = str1.replace(' ',' ') str1 = str1.replace(' ',' ') AND IT WORKED ---------- components: Interpreter Core messages: 257603 nosy: roland_eichman priority: normal severity: normal status: open title: string.replace(' ',' ') has to be called 2 times before it works type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 07:31:03 2016 From: report at bugs.python.org (SilentGhost) Date: Wed, 06 Jan 2016 12:31:03 +0000 Subject: [issue26022] string.replace(' ', ' ') has to be called 2 times before it works In-Reply-To: <1452083207.08.0.345721672406.issue26022@psf.upfronthosting.co.za> Message-ID: <1452083463.19.0.726642861771.issue26022@psf.upfronthosting.co.za> SilentGhost added the comment: Could you provide us with a sample file that demonstrates this behaviour? ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 07:43:22 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 06 Jan 2016 12:43:22 +0000 Subject: [issue26022] string.replace(' ', ' ') has to be called 2 times before it works In-Reply-To: <1452083207.08.0.345721672406.issue26022@psf.upfronthosting.co.za> Message-ID: <1452084202.86.0.778425962508.issue26022@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Please use stackoverflow or python-tutor list to get help on this. https://mail.python.org/pipermail/tutor/ This is unlikely a problem as you are using replace the send time on new string object. ---------- nosy: +orsenthil resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 08:07:55 2016 From: report at bugs.python.org (Freddy Rietdijk) Date: Wed, 06 Jan 2016 13:07:55 +0000 Subject: [issue26023] Missing signatures operator module Message-ID: <1452085675.2.0.944148741894.issue26023@psf.upfronthosting.co.za> New submission from Freddy Rietdijk: The operator module has no signatures for (most) of the functions defined in it. Use case: The multipledispatch module uses inspect.getfullargspec and therefore the functions in operator cannot be used in combination with the @dispatch decorator ---------- components: Library (Lib) messages: 257606 nosy: Freddy Rietdijk priority: normal severity: normal status: open title: Missing signatures operator module type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 08:55:01 2016 From: report at bugs.python.org (Ethan Furman) Date: Wed, 06 Jan 2016 13:55:01 +0000 Subject: [issue26022] string.replace(' ', ' ') has to be called 2 times before it works In-Reply-To: <1452083207.08.0.345721672406.issue26022@psf.upfronthosting.co.za> Message-ID: <1452088501.54.0.61941294403.issue26022@psf.upfronthosting.co.za> Ethan Furman added the comment: The .replace() method is not recursive (it only makes one pass through the string), so for example: >>> example = ' ' # three spaces >>> example = example.replace(' ', ' ') # replace two spaces with one space >>> example # should be two spaces ' ' >>> example = example.replace(' ', ' ') # replace two spaces with one space >>> example # should be one space ' ' ---------- nosy: +ethan.furman resolution: rejected -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 09:28:10 2016 From: report at bugs.python.org (Vidar Fauske) Date: Wed, 06 Jan 2016 14:28:10 +0000 Subject: [issue26024] Non-ascii Windows locale names Message-ID: <1452090490.23.0.240691672935.issue26024@psf.upfronthosting.co.za> New submission from Vidar Fauske: The Norwegian locale on Windows has the honor of having the only locale name with a non-ASCII character ('Norwegian Bokm?l_Norway', see e.g. https://wiki.postgresql.org/wiki/Changes_To_Norwegian_Locale). It does not seem like python 3 is able to handle this properly, as the following code demonstrates: >python Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.setlocale(locale.LC_TIME, 'swedish') 'Swedish_Sweden.1252' >>> loc_sw = locale.getlocale(locale.LC_TIME) >>> locale.setlocale(locale.LC_TIME, 'norwegian') 'Norwegian Bokm?l_Norway.1252' >>> loc_no = locale.getlocale(locale.LC_TIME) >>> locale.setlocale(locale.LC_TIME, loc_sw) 'Swedish_Sweden.1252' >>> locale.setlocale(locale.LC_TIME, loc_no) Traceback (most recent call last): File "", line 1, in File "C:\prog\WinPython-64bit-3.4.3.7\python-3.4.3.amd64\lib\locale.py", line 593, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting As can be seen, this can be worked around when setting the locale manually, but if the locale has already been set to Norwegian, the value returned from getlocale is invalid when passed to setlocale. Following the example of postgres in the link above, I suggest changing the behavior of locale.getlocale to alias 'Norwegian Bokm?l_Norway.1252' as 'Norwegian_Norway.1252', which is completely ASCII, and therefore fine. ---------- components: Unicode, Windows messages: 257608 nosy: ezio.melotti, haypo, paul.moore, steve.dower, tim.golden, vidartf, zach.ware priority: normal severity: normal status: open title: Non-ascii Windows locale names type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 09:41:28 2016 From: report at bugs.python.org (Rose Ames) Date: Wed, 06 Jan 2016 14:41:28 +0000 Subject: [issue25711] Rewrite zipimport from scratch In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za> Message-ID: <1452091288.22.0.303480944943.issue25711@psf.upfronthosting.co.za> Rose Ames added the comment: Sorry for the late response. I didn't have much time over the holidays. I think I better let someone else take this one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 10:15:53 2016 From: report at bugs.python.org (A. Jesse Jiryu Davis) Date: Wed, 06 Jan 2016 15:15:53 +0000 Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za> Message-ID: <1452093353.66.0.467733860865.issue25924@psf.upfronthosting.co.za> A. Jesse Jiryu Davis added the comment: In Apple's Libinfo version 222.4.12 (corresponding to the last OS X 10.4 release), the man page says getaddrinfo isn't thread-safe: http://www.opensource.apple.com/source/Libinfo/Libinfo-222.4.12/lookup.subproj/getaddrinfo.3 And here's its source: http://www.opensource.apple.com/source/Libinfo/Libinfo-222.4.12/lookup.subproj/getaddrinfo.c Glancing at the source na?vely, I might see the data race: getaddrinfo calls gai_lookupd, which reads and writes the global static variable "gai_proc". I can't see what will go wrong as a result of the race, but it sure LOOKS bad. In the next release, version 278 (OS X 10.5.0), the thread-safety warning is gone from the man page: http://www.opensource.apple.com/source/Libinfo/Libinfo-278/lookup.subproj/getaddrinfo.3 And getaddrinfo is largely rewritten: http://www.opensource.apple.com/source/Libinfo/Libinfo-278/lookup.subproj/getaddrinfo.c It calls a new function, "ds_getaddrinfo". But ds_getaddrinfo still accesses the global static variable "gai_proc"; I wonder why this is considered thread-safe now? ---------- nosy: +emptysquare _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 10:28:16 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Jan 2016 15:28:16 +0000 Subject: [issue26024] Non-ascii Windows locale names In-Reply-To: <1452090490.23.0.240691672935.issue26024@psf.upfronthosting.co.za> Message-ID: <1452094096.9.0.112598364346.issue26024@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This can be related to issue25812. Python supposes that locale settings in all categories use the same encoding (set by LC_CTYPE). Try first to set LC_CTYPE to ASCII-named locale with the 1252 codepage. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 10:54:55 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 06 Jan 2016 15:54:55 +0000 Subject: [issue26024] Non-ascii Windows locale names In-Reply-To: <1452090490.23.0.240691672935.issue26024@psf.upfronthosting.co.za> Message-ID: <1452095695.69.0.114494700321.issue26024@psf.upfronthosting.co.za> Eryk Sun added the comment: PyLocale_setlocale in Modules/_localemodule.c is incorrectly passing the locale as a UTF-8 string ("z") instead of using the codepage of the current locale. As you can see below "?" is passed as the UTF-8 string "\xc3\xa5": >>> locale._setlocale(locale.LC_TIME, 'Norwegian Bokm?l_Norway.1252') Breakpoint 0 hit MSVCR100!setlocale: 00000000`56d23d14 48895c2408 mov qword ptr [rsp+8],rbx ss:00000000`004af800= 0000000002ad2a68 0:000> db @rdx l0n29 00000000`02808910 4e 6f 72 77 65 67 69 61- 6e 20 42 6f 6b 6d c3 a5 Norwegian Bokm.. 00000000`02808920 6c 5f 4e 6f 72 77 61 79- 2e 31 32 35 32 l_Norway.1252 The CRT's setlocale works fine when passed the locale string encoded with codepage 1252: >>> msvcr100 = ctypes.CDLL('msvcr100') >>> msvcr100.setlocale.restype = ctypes.c_char_p >>> loc_no = 'Norwegian Bokm?l_Norway.1252'.encode('1252') >>> msvcr100.setlocale(locale.LC_TIME, loc_no) b'Norwegian Bokm\xe5l_Norway.1252' ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 11:13:46 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Jan 2016 16:13:46 +0000 Subject: [issue26024] Non-ascii Windows locale names In-Reply-To: <1452090490.23.0.240691672935.issue26024@psf.upfronthosting.co.za> Message-ID: <1452096826.05.0.743803723792.issue26024@psf.upfronthosting.co.za> STINNER Victor added the comment: > PyLocale_setlocale in Modules/_localemodule.c is incorrectly passing the locale as a UTF-8 string ("z") instead of using the codepage of the current locale. Do you mean that the function must encode the locale name to the *ANSI codepage*? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 11:19:53 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 06 Jan 2016 16:19:53 +0000 Subject: [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452097193.82.0.242768261799.issue26020@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file41518/build_set2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 11:20:06 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 06 Jan 2016 16:20:06 +0000 Subject: [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452097206.77.0.689543482563.issue26020@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 11:21:05 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 06 Jan 2016 16:21:05 +0000 Subject: [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452097265.93.0.378521197181.issue26020@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 12:06:03 2016 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 06 Jan 2016 17:06:03 +0000 Subject: [issue22499] [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636 In-Reply-To: <1411694670.5.0.645076106925.issue22499@psf.upfronthosting.co.za> Message-ID: <1452099963.56.0.904001352325.issue22499@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Would you be willing to review a patch to incorporate the handling into the SSL module? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 12:30:22 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 17:30:22 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1452078501.63.0.296947355834.issue22570@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I think it's actually very reasonable for a Path to have a path attribute that's a string. The DirEntry has two string attributes: name (the last component) and path (the full path). The Path object already has the former. Adding the latter makes sense to me. After all you've gotta give it *some* name, and 'path' is used (unsurprisingly) in this meaning already in many places. The shortest idiom in libraries wanting to support this would be path = gettattr(arg, 'path', arg) This extracts the path attribute from a DirEntry or Path object, and assumes the argument is a string otherwise. I think this is relatively reasonable to encode in C as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 12:35:26 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 06 Jan 2016 17:35:26 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <1452101726.29.0.894883702023.issue22570@psf.upfronthosting.co.za> Brett Cannon added the comment: Would `location` work as an attribute name? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 12:39:34 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 06 Jan 2016 17:39:34 +0000 Subject: [issue26025] Document pathlib.Path.__truediv__() Message-ID: <1452101974.47.0.473485918535.issue26025@psf.upfronthosting.co.za> New submission from Brett Cannon: I noticed that the documentation for pathlib only mentions the overloading of __truediv__ in examples and not anywhere in the actual docs for the Path object itself. ---------- assignee: docs at python components: Documentation messages: 257617 nosy: brett.cannon, docs at python, pitrou priority: normal severity: normal stage: needs patch status: open title: Document pathlib.Path.__truediv__() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 12:42:33 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 17:42:33 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <1452102153.34.0.366623509931.issue24120@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm just going to commit this. ---------- assignee: -> gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 12:43:04 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 06 Jan 2016 17:43:04 +0000 Subject: [issue25672] set SSL_MODE_RELEASE_BUFFERS In-Reply-To: <1447957027.04.0.0951767236546.issue25672@psf.upfronthosting.co.za> Message-ID: <1452102184.93.0.057841252078.issue25672@psf.upfronthosting.co.za> Brett Cannon added the comment: I assume this can be checked in, MAL? If you need someone to do it for you, feel free to assign it to me and I can do it when I have a chance. ---------- nosy: +brett.cannon stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 12:45:20 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 17:45:20 +0000 Subject: [issue26012] pathlib.Path().rglob() is fooled by symlink loops In-Reply-To: <1451960031.51.0.813695149526.issue26012@psf.upfronthosting.co.za> Message-ID: <1452102320.96.0.799330165481.issue26012@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm going to fix this by skipping all symlinks in _RecursiveWildcardSelector. ---------- assignee: -> gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 12:51:06 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 17:51:06 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1452101726.29.0.894883702023.issue22570@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Only if we changed DirEntry to support that too. But it's a kind of high-falootin' word that also has some other connotations (e.g. geographical location, and the HTTP Location header). I've never heard it use in relation to filenames -- those are invariably called some variant of file, file name, path, full path. Really, the argument Antoine brings up doesn't hold much weight. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 12:53:48 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 06 Jan 2016 17:53:48 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <1452102828.82.0.945033703205.issue22570@psf.upfronthosting.co.za> Brett Cannon added the comment: Personally I thought the name `path` fit; just trying to see if some other option might work that Antoine would also like. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 12:54:12 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 Jan 2016 17:54:12 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <20160106175407.7756.9082@psf.io> Roundup Robot added the comment: New changeset bac18cb7b011 by Guido van Rossum in branch '3.4': Issue #24120: Ignore PermissionError in pathlib.Path.[r]glob(). Ulrich Petri. https://hg.python.org/cpython/rev/bac18cb7b011 New changeset 224a026b4ca1 by Guido van Rossum in branch '3.5': Issue #24120: Ignore PermissionError in pathlib.Path.[r]glob(). Ulrich Petri. (Merge 3.4->3.5) https://hg.python.org/cpython/rev/224a026b4ca1 New changeset f6ae90450a4d by Guido van Rossum in branch 'default': Issue #24120: Ignore PermissionError in pathlib.Path.[r]glob(). Ulrich Petri. (Merge 3.5->3.6) https://hg.python.org/cpython/rev/f6ae90450a4d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 12:55:03 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 17:55:03 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <1452102903.07.0.0290524935706.issue24120@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 12:56:08 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Jan 2016 17:56:08 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <1452102968.39.0.536706119359.issue22570@psf.upfronthosting.co.za> Antoine Pitrou added the comment: In any case I don't think "location" is any better ;-) If "path" fits other people then good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 13:09:08 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 06 Jan 2016 18:09:08 +0000 Subject: [issue26024] Non-ascii Windows locale names In-Reply-To: <1452090490.23.0.240691672935.issue26024@psf.upfronthosting.co.za> Message-ID: <1452103748.96.0.797644027818.issue26024@psf.upfronthosting.co.za> Eryk Sun added the comment: Yes, it's ANSI. I should have said "system locale" instead of "current locale". To find the requested locale, the CRT function __get_qualified_locale calls EnumSystemLocalesA. The passed callback calls GetLocaleInfoA for each enumerated locale to get the country (SENGLISHCOUNTRYNAME) and language (SENGLISHLANGUAGENAME). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 13:14:07 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 06 Jan 2016 18:14:07 +0000 Subject: [issue25672] set SSL_MODE_RELEASE_BUFFERS In-Reply-To: <1447957027.04.0.0951767236546.issue25672@psf.upfronthosting.co.za> Message-ID: <1452104047.88.0.170928392268.issue25672@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Thanks, Brett. I'm too busy with other things at the moment. ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 13:19:31 2016 From: report at bugs.python.org (Gregorio) Date: Wed, 06 Jan 2016 18:19:31 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1452102153.34.0.366623509931.issue24120@psf.upfronthosting.co.za> Message-ID: <568D5AA2.6080801@gmail.com> Gregorio added the comment: thanks On 01/06/2016 06:42 PM, Guido van Rossum wrote: > Guido van Rossum added the comment: > > I'm just going to commit this. > > ---------- > assignee: -> gvanrossum > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 13:36:40 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 Jan 2016 18:36:40 +0000 Subject: [issue26012] pathlib.Path().rglob() is fooled by symlink loops In-Reply-To: <1451960031.51.0.813695149526.issue26012@psf.upfronthosting.co.za> Message-ID: <20160106183637.9636.9691@psf.io> Roundup Robot added the comment: New changeset 18f5b125a863 by Guido van Rossum in branch '3.4': Issue #26012: Don't traverse into symlinks for ** pattern in pathlib.Path.[r]glob(). https://hg.python.org/cpython/rev/18f5b125a863 New changeset 9826dbad1252 by Guido van Rossum in branch '3.5': Issue #26012: Don't traverse into symlinks for ** pattern in pathlib.Path.[r]glob(). (Merge 3.4->3.5) https://hg.python.org/cpython/rev/9826dbad1252 New changeset 36864abbfe02 by Guido van Rossum in branch 'default': Issue #26012: Don't traverse into symlinks for ** pattern in pathlib.Path.[r]glob(). (Merge 3.5->3.6) https://hg.python.org/cpython/rev/36864abbfe02 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 13:37:14 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 18:37:14 +0000 Subject: [issue26012] pathlib.Path().rglob() is fooled by symlink loops In-Reply-To: <1451960031.51.0.813695149526.issue26012@psf.upfronthosting.co.za> Message-ID: <1452105434.11.0.443019165287.issue26012@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 13:38:14 2016 From: report at bugs.python.org (Hristo Venev) Date: Wed, 06 Jan 2016 18:38:14 +0000 Subject: [issue26026] True%2==True Message-ID: <1452105494.05.0.152464370821.issue26026@psf.upfronthosting.co.za> New submission from Hristo Venev: Should be 1. This comes from the (a%b=a if a _______________________________________ From report at bugs.python.org Wed Jan 6 13:38:29 2016 From: report at bugs.python.org (Hristo Venev) Date: Wed, 06 Jan 2016 18:38:29 +0000 Subject: [issue26026] True%2 is True In-Reply-To: <1452105494.05.0.152464370821.issue26026@psf.upfronthosting.co.za> Message-ID: <1452105509.2.0.555688451811.issue26026@psf.upfronthosting.co.za> Changes by Hristo Venev : ---------- title: True%2==True -> True%2 is True _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 13:38:47 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 18:38:47 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1452102968.39.0.536706119359.issue22570@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: OK, I'll add 'path' to unblock changes to the stdlib (but I won't close this issue). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 13:52:58 2016 From: report at bugs.python.org (SilentGhost) Date: Wed, 06 Jan 2016 18:52:58 +0000 Subject: [issue26026] True%2 is True In-Reply-To: <1452105494.05.0.152464370821.issue26026@psf.upfronthosting.co.za> Message-ID: <1452106378.18.0.859326884267.issue26026@psf.upfronthosting.co.za> SilentGhost added the comment: Arithmetic operations should not be used with booleans, they happen to work due to boolean bean a subclass of int. ---------- nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 14:04:31 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 Jan 2016 19:04:31 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <20160106190418.53690.1948@psf.io> Roundup Robot added the comment: New changeset 7e9605697dfc by Guido van Rossum in branch '3.4': Issue #22570: Add 'path' attribute to pathlib.Path objects. https://hg.python.org/cpython/rev/7e9605697dfc New changeset 9c49c417a68a by Guido van Rossum in branch '3.5': Issue #22570: Add 'path' attribute to pathlib.Path objects. (Merge 3.4->3.5) https://hg.python.org/cpython/rev/9c49c417a68a New changeset d5f96a5da219 by Guido van Rossum in branch 'default': Issue #22570: Add 'path' attribute to pathlib.Path objects. (Merge 3.5->3.6) https://hg.python.org/cpython/rev/d5f96a5da219 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 14:24:25 2016 From: report at bugs.python.org (Georg Brandl) Date: Wed, 06 Jan 2016 19:24:25 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <1452108265.25.0.767857072899.issue22570@psf.upfronthosting.co.za> Georg Brandl added the comment: No docs? ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 14:38:39 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 Jan 2016 19:38:39 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <20160106193834.53718.86584@psf.io> Roundup Robot added the comment: New changeset 2e3c31ab586a by Guido van Rossum in branch '3.4': Docs for issue #22570. https://hg.python.org/cpython/rev/2e3c31ab586a New changeset 408f8b255b56 by Guido van Rossum in branch '3.5': Docs for issue #22570. (Merge 3.4->3.5) https://hg.python.org/cpython/rev/408f8b255b56 New changeset 759b2cecc289 by Guido van Rossum in branch '3.4': Add versionadded (3.4.5) to docs for issue #22570. https://hg.python.org/cpython/rev/759b2cecc289 New changeset 1a6b485e717f by Guido van Rossum in branch '3.5': Add versionadded (3.4.5) to docs for issue #22570. (Merge 3.4->3.5) https://hg.python.org/cpython/rev/1a6b485e717f New changeset eab349b5c6d7 by Guido van Rossum in branch '3.5': Cross-reference os.DirEntry and pathlib.Path for issue #22570. https://hg.python.org/cpython/rev/eab349b5c6d7 New changeset 97ab0ccac893 by Guido van Rossum in branch 'default': Docs for issue #22570. (Merge 3.5->3.6) https://hg.python.org/cpython/rev/97ab0ccac893 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 14:50:24 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 19:50:24 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <1452109824.45.0.696996112336.issue22570@psf.upfronthosting.co.za> Guido van Rossum added the comment: So, I added docs, mentioning the getattr(arg, 'path', arg) idiom, and (for 3.5 and 3.6) also cross-referencing with DirEntry. I'm not sure whether to now close this issue or whether to leave it open to remind people of adding patches using the new idiom to various stdlib modules. Opinions? Also, since pathlib is provisional, I felt okay with adding this to 3.4.5 and 3.5.2. ---------- versions: +Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 15:02:55 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 20:02:55 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1452110575.63.0.149666044409.issue25958@psf.upfronthosting.co.za> Guido van Rossum added the comment: Uploading a flattened version of patch3.diff. ---------- Added file: http://bugs.python.org/file41519/patch3-regenerated.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 15:34:38 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 06 Jan 2016 20:34:38 +0000 Subject: [issue26023] Missing signatures operator module In-Reply-To: <1452085675.2.0.944148741894.issue26023@psf.upfronthosting.co.za> Message-ID: <1452112478.96.0.503564889336.issue26023@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps the patch in Issue 20186 (Argument Clinic conversion including the module) will help. I noticed there was some concern about reduced performance; I?m not sure if that is still a problem or not. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 15:44:27 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 06 Jan 2016 20:44:27 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <1452113067.72.0.512295341127.issue22570@psf.upfronthosting.co.za> Brett Cannon added the comment: We could leave this open as a meta issue and spin off individual issues for any specific module people choose to update to support Path objects, setting those new issues as dependencies here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 15:46:02 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 20:46:02 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1452113162.31.0.190692328524.issue25958@psf.upfronthosting.co.za> Guido van Rossum added the comment: FWIW, it looks fine to me -- but I'm hoping to get Serhiy's agreement first. Serhiy: feel free to commit when you're happy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 15:48:32 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 20:48:32 +0000 Subject: [issue26019] collections.abc documentation incomplete In-Reply-To: <1452045912.74.0.509683701942.issue26019@psf.upfronthosting.co.za> Message-ID: <1452113312.09.0.101071786083.issue26019@psf.upfronthosting.co.za> Guido van Rossum added the comment: LGTM. Do you want me to commit it now or wait until you've redone it after #25958 has gone through? ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 15:56:51 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Jan 2016 20:56:51 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1452113811.79.0.425384523959.issue25958@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added few stylistic nitpicks and asked few questions on Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 16:05:30 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Jan 2016 21:05:30 +0000 Subject: [issue26027] Support Path objects in the posix module Message-ID: <1452114329.99.0.617690911804.issue26027@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: path_converter should be changed to accept objects with the "path" attribute. See issue22570 for details. ---------- assignee: serhiy.storchaka components: Extension Modules messages: 257642 nosy: serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Support Path objects in the posix module type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 16:08:42 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Jan 2016 21:08:42 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <1452114522.18.0.17593077441.issue22570@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Opened issue26027 for adding support in the posix module. Should the path attribute be only string, or other types are acceptable (bytes, file descriptor, and even None if the function accepts None)? ---------- dependencies: +Support Path objects in the posix module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 16:33:53 2016 From: report at bugs.python.org (Hassan Mahroof) Date: Wed, 06 Jan 2016 21:33:53 +0000 Subject: [issue26028] .sort() Causing Strings to Be Listed on the same line Message-ID: <1452116033.54.0.131066296483.issue26028@psf.upfronthosting.co.za> New submission from Hassan Mahroof: I am a student @ Burnley College and we were learning how to use the .write(), .close(), .readlines() and .sort(). I have a list of names within a text file which I am trying sort, These are random names generated using my Random Mind. However, when the sorted text file is created, what seems to be under certain circumstances with my list only (or words similar, This bug did not occur within my whole class till I stumbled upon it) it seems to instead of writing each term to seperate lines, it seems to connect two of the words (in this case names) on the same line. I have tried to find a pattern in this madness however being the rookie student I am I can only seem to break things aha. I have attached the 2 files which I am using and Hopefully someone can correct this cause I am confused. This is a list of the names: Robertas Hassan Bob Connor Camera Billy Maz Richard Mo ---------- components: IDLE files: SortFile2.py messages: 257644 nosy: Hassan Mahroof priority: normal severity: normal status: open title: .sort() Causing Strings to Be Listed on the same line type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file41520/SortFile2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 16:44:08 2016 From: report at bugs.python.org (Julien) Date: Wed, 06 Jan 2016 21:44:08 +0000 Subject: [issue26029] Broken sentence in extending documentation Message-ID: <1452116648.24.0.989848174126.issue26029@psf.upfronthosting.co.za> New submission from Julien: Hello, While translating the documentation to French, I found a bug here : https://docs.python.org/3/extending/building.html#building-c-and-c-extensions-with-distutils The sentence: "Normally, a package will contain of addition modules:" Should probably be: "Normally, a package will contain additional modules:" Bests. ---------- assignee: docs at python components: Documentation messages: 257645 nosy: docs at python, sizeof priority: normal severity: normal status: open title: Broken sentence in extending documentation type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 16:52:24 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 06 Jan 2016 21:52:24 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1452117144.62.0.138260197144.issue22995@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I'm reopening this issue because we're starting to see a bunch of regressions in Debian and Ubuntu we think is caused by the changes here. We've definitely started seeing them with 3.5.1, where packages that use Cython built just fine in 3.5.0 but now fail with TypeError in 3.5.1. I haven't been able to completely debug the problem yet, but here's what I know. Here's a build log for s3ql that shows the failure: http://paste.debian.net/361351/ Here's a bug report showing a build failure for kivy, leading to the same problem: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810139 Nothing immediately jumps out at me as problematic with the NameAssignment class, which afaict is defined in Cython/Compiler/FlowControl.py as thus: class NameAssignment(object): def __init__(self, lhs, rhs, entry): if lhs.cf_state is None: lhs.cf_state = set() self.lhs = lhs self.rhs = rhs self.entry = entry self.pos = lhs.pos self.refs = set() self.is_arg = False self.is_deletion = False self.inferred_type = None def __repr__(self): return '%s(entry=%r)' % (self.__class__.__name__, self.entry) def infer_type(self): self.inferred_type = self.rhs.infer_type(self.entry.scope) return self.inferred_type def type_dependencies(self): return self.rhs.type_dependencies(self.entry.scope) @property def type(self): if not self.entry.type.is_unspecified: return self.entry.type return self.inferred_type I suppose it's possible that something outside the class is poking an unpicklable attribute into the instance, but wouldn't that show up as a pickling error of a different class? The TypeError is being raised in deepcopy() in copy.py, where it is getting x's __reduce_ex__ and then calling reductor(4) (see ~line 174). If you catch the TypeError on that line and set a breakpoint, then call `copy(x)` you see the TypeError. I tried calling copy.deepcopy() on all the attributes of the NameAssignment instance I could find, and they all copied just fine. I'm going to try to set up a gdb to figure out exactly which of the new picklability tests is failing, but I definitely think we have a regression here. I suppose it's also possible that it's a legitimate bug in Cython, but then how did it ever work before? ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 16:55:28 2016 From: report at bugs.python.org (Scott Kitterman) Date: Wed, 06 Jan 2016 21:55:28 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1452117328.46.0.0394401454792.issue22995@psf.upfronthosting.co.za> Changes by Scott Kitterman : ---------- nosy: +kitterma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 16:59:22 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 21:59:22 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1452114522.18.0.17593077441.issue22570@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Let's say that the path attribute should be str or bytes -- this matches the behavior of DirEntry. (But for pathlib.Path it is always a str.) It cannot be None or FD. But note that the getattr(x, 'path', x) idiom returns x unchanged if x is None or an FD (or a stream, for that matter). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 17:01:53 2016 From: report at bugs.python.org (SilentGhost) Date: Wed, 06 Jan 2016 22:01:53 +0000 Subject: [issue26028] .sort() Causing Strings to Be Listed on the same line In-Reply-To: <1452116033.54.0.131066296483.issue26028@psf.upfronthosting.co.za> Message-ID: <1452117713.58.0.23249154537.issue26028@psf.upfronthosting.co.za> SilentGhost added the comment: Please use stackoverflow or python-tutor list to get help on this. https://mail.python.org/pipermail/tutor/ What it looks like is the problem with your text editor not being able to support EOL characters from a different OS. ---------- nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 17:06:04 2016 From: report at bugs.python.org (Julien) Date: Wed, 06 Jan 2016 22:06:04 +0000 Subject: [issue26030] Use PEP8 in documentation examples Message-ID: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> New submission from Julien: Hi, Shouldn't Python use PEP8 in its examples in the documentation ? I found a lot of missing spaces around binary operators, and things like "setup (name = 'PackageName'," (found in the Distributing section, but that's just a single example) which hurt my eyes and will probably teach bad practices to newcomers reading it. If everybody agree documentation examples should be PEP8 compliant, I'll can gladly provide some patches. I also found http://bugs.python.org/issue23921 which is probably not merged as it's still open, and the patch don't fix my example, so there is probably some problems left. ---------- assignee: docs at python components: Documentation messages: 257649 nosy: docs at python, sizeof priority: normal severity: normal status: open title: Use PEP8 in documentation examples type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 17:13:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Jan 2016 22:13:37 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1452118417.4.0.321051515733.issue22995@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What return __reduce_ex__(4) for the NameAssignment instance in 3.5.0? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 17:41:29 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 22:41:29 +0000 Subject: [issue26031] Add stat caching option to pathlib Message-ID: <1452120089.84.0.0792910513701.issue26031@psf.upfronthosting.co.za> New submission from Guido van Rossum: There are concerns that pathlib is inefficient because it doesn't cache stat() operations. Thus, for example this code calls stat() for each result twice (once internal to the glob, a second time to answer the is_symlink() question): p = pathlib.Path('/usr') links = [x for x in p.rglob('*') if x.is_symlink()] I have a tentative patch (without tests). On my Mac it only gives modest speedups (between 5 and 20 percent) but things may be different on other platforms or for applications that make a lot of inquiries about the same path. The API I am proposing is that by default nothing changes; to benefit from caching you must instantiate a StatCache() object and pass it to Path() constructor calls, e.g. Path('/usr', stat_cache=cache_object). All Path objects derived from this path object will share the cache. To force an uncached Path object you can use Path(p). The patch is incomplete; there are no tests for the new functionality (though existing tests pass) and __eq__ should be adjusted so that Path objects using different caches always compare unequal. Question for Antoine: Did you perhaps anticipate a design like this? Each Path instance has an _accessor slot, but there is only one accessor instance defined that is used everywhere (the global _normal_accessor). So you could have avoided a bunch of complexity in the code around setting the proper _accessor unless you were planning to use multiple accessors. ---------- files: statcache.diff keywords: patch messages: 257651 nosy: gvanrossum, pitrou priority: normal severity: normal stage: test needed status: open title: Add stat caching option to pathlib type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file41521/statcache.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 17:47:01 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Jan 2016 22:47:01 +0000 Subject: [issue26031] Add stat caching option to pathlib In-Reply-To: <1452120089.84.0.0792910513701.issue26031@psf.upfronthosting.co.za> Message-ID: <1452120421.78.0.905855579083.issue26031@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Let me first mention the stat caching question was asked during the PEP discussion and ultimately it was decided it's not a good idea to meld it in the Path design :-) Early versions of pathlib were more complex as they were able to keep some file descriptors around, for example for openat() support. You can probably find them by digging in the original repo. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 17:55:27 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 22:55:27 +0000 Subject: [issue26032] Use scandir() to speed up pathlib globbing Message-ID: <1452120927.04.0.31788168865.issue26032@psf.upfronthosting.co.za> New submission from Guido van Rossum: The globbing functionality in pathlib (Path.glob() and Path.rglob()) might benefit from using the new optimized os.scandir() interface. It currently just uses os.listdir(). The Path.iterdir() method might also benefit (though less so). There's also a sideways connection with http://bugs.python.org/issue26031 (adding an optional stat cache) -- the cache could possibly keep the DirEntry objects and use their (hopefully cached) attributes. This is more speculative though (and what if the platform's DirEntry doesn't cache?) ---------- messages: 257653 nosy: gvanrossum priority: normal severity: normal status: open title: Use scandir() to speed up pathlib globbing type: performance versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 17:56:03 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 22:56:03 +0000 Subject: [issue26032] Use scandir() to speed up pathlib globbing In-Reply-To: <1452120927.04.0.31788168865.issue26032@psf.upfronthosting.co.za> Message-ID: <1452120963.13.0.34619239139.issue26032@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 17:57:12 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Jan 2016 22:57:12 +0000 Subject: [issue26032] Use scandir() to speed up pathlib globbing In-Reply-To: <1452120927.04.0.31788168865.issue26032@psf.upfronthosting.co.za> Message-ID: <1452121032.65.0.986154891615.issue26032@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 17:57:35 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Jan 2016 22:57:35 +0000 Subject: [issue26032] Use scandir() to speed up pathlib globbing In-Reply-To: <1452120927.04.0.31788168865.issue26032@psf.upfronthosting.co.za> Message-ID: <1452121055.18.0.941696656346.issue26032@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +benhoyt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 17:58:53 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Jan 2016 22:58:53 +0000 Subject: [issue26032] Use scandir() to speed up pathlib globbing In-Reply-To: <1452120927.04.0.31788168865.issue26032@psf.upfronthosting.co.za> Message-ID: <1452121133.24.0.285700555006.issue26032@psf.upfronthosting.co.za> STINNER Victor added the comment: Related issue: issue #25596 "regular files handled as directories in the glob module". ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 17:59:13 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Jan 2016 22:59:13 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1452121153.2.0.0678320559609.issue25596@psf.upfronthosting.co.za> STINNER Victor added the comment: Related issue: #26032 "Use scandir() to speed up pathlib globbing". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 18:00:01 2016 From: report at bugs.python.org (Ethan Furman) Date: Wed, 06 Jan 2016 23:00:01 +0000 Subject: [issue26032] Use scandir() to speed up pathlib globbing In-Reply-To: <1452120927.04.0.31788168865.issue26032@psf.upfronthosting.co.za> Message-ID: <1452121201.3.0.00787101704286.issue26032@psf.upfronthosting.co.za> Ethan Furman added the comment: As I recall, if the platform's DirEntry doesn't provide the cacheable attributes when first called, those attributes will be looked up (and cached) on first access. ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 18:03:57 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Jan 2016 23:03:57 +0000 Subject: [issue26032] Use scandir() to speed up pathlib globbing In-Reply-To: <1452120927.04.0.31788168865.issue26032@psf.upfronthosting.co.za> Message-ID: <1452121437.47.0.436078655626.issue26032@psf.upfronthosting.co.za> STINNER Victor added the comment: > As I recall, if the platform's DirEntry doesn't provide the cacheable attributes when first called, those attributes will be looked up (and cached) on first access. scandir() is not magic. It simply provides info given by the OS: see readdir() on UNIX and FindFirstFile()/FindNextFile() on Windows. DirEntry calls os.stat() if needed, but it caches the result. DirEntry doc tries to explain when syscalls or required or not, depending on the requested information and the platform: https://docs.python.org/dev/library/os.html#os.DirEntry ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 18:06:25 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 23:06:25 +0000 Subject: [issue26031] Add stat caching option to pathlib In-Reply-To: <1452120421.78.0.905855579083.issue26031@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: That's fair, though I don't know what kind of caching design was considered (until Ram's suggestion on python-ideas I had thought the cache would simply use a slot on the Path instance to hold the stat() result). If we want pathlib to become pervasive we may have to accept that its implementation may become more complex in order to support more use cases. (I'm so far holding off a walk() method, but who knows for how long...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 18:08:37 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 23:08:37 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1452121717.21.0.320212987563.issue25596@psf.upfronthosting.co.za> Guido van Rossum added the comment: (IOW once this patch has been applied maybe you can do the same for globbing in pathlib as requested in issue #26032.) ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 18:12:11 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 23:12:11 +0000 Subject: [issue26032] Use scandir() to speed up pathlib globbing In-Reply-To: <1452121437.47.0.436078655626.issue26032@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: The DirEntry docs say for most methods "In most cases, no system call is required" which is pretty non-committal. :-( The only firm promise is for inode(), which is pretty useless. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 18:39:46 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 06 Jan 2016 23:39:46 +0000 Subject: [issue26030] Use PEP8 in documentation examples In-Reply-To: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> Message-ID: <1452123586.52.0.39256569891.issue26030@psf.upfronthosting.co.za> Martin Panter added the comment: In general I agree with fixing style problems in the documentation, especially if you supply patches :) ---------- nosy: +martin.panter stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 18:45:32 2016 From: report at bugs.python.org (Laurence Rowe) Date: Wed, 06 Jan 2016 23:45:32 +0000 Subject: [issue21159] configparser.InterpolationMissingOptionError is not very intuitive In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za> Message-ID: <1452123932.03.0.794856496905.issue21159@psf.upfronthosting.co.za> Laurence Rowe added the comment: This change is causing a problem for boto under 3.5.1 (works on 3.5.0): TypeError: get() got an unexpected keyword argument 'raw' > /usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/configparser.py(406)_interpolate_some() -> rawval = parser.get(section, option, raw=True, fallback=rest) boto bug report: https://github.com/boto/boto/issues/3433 This is because boto is subclassing ConfigParser and its get method does not include the raw argument. A quick search shows that this also affects Kazam am circus. Circus fixed it by adding **kwargs to the method. https://github.com/circus-tent/circus/commit/d0d2ac4fd843bb9f050a8c678956fe3682371001 ---------- nosy: +lrowe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 19:32:48 2016 From: report at bugs.python.org (Stefan Seefeld) Date: Thu, 07 Jan 2016 00:32:48 +0000 Subject: [issue26033] distutils default compiler API is incomplete Message-ID: <1452126768.68.0.403890898516.issue26033@psf.upfronthosting.co.za> New submission from Stefan Seefeld: I'm trying to use the distutil compiler to preprocess some header (to be used with the cffi package). The code is compiler = distutils.ccompiler.new_compiler() compiler.add_include_dir(join(sys.prefix, 'include')) compiler.preprocess(source) This raises this exception (on Linux): File ".../distutils/unixccompiler.py", line 88, in preprocess pp_args = self.preprocessor + pp_opts TypeError: unsupported operand type(s) for +: 'NoneType' and 'list' caused by 'set.preprocessor' to be set to None (with the preceding comment: # The defaults here # are pretty generic; they will probably have to be set by an outsider # (eg. using information discovered by the sysconfig about building # Python extensions). Seems that code never got fully implemented. Further, the MSVC version of the compiler (msvccompiler.py) doesn't even implement a "preprocess()" method, so this falls back to the CCompiler.preprocess() default, which does nothing ! ---------- components: Distutils messages: 257663 nosy: dstufft, eric.araujo, stefan priority: normal severity: normal status: open title: distutils default compiler API is incomplete type: behavior versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 20:06:53 2016 From: report at bugs.python.org (Ben Hoyt) Date: Thu, 07 Jan 2016 01:06:53 +0000 Subject: [issue26032] Use scandir() to speed up pathlib globbing In-Reply-To: <1452120927.04.0.31788168865.issue26032@psf.upfronthosting.co.za> Message-ID: <1452128813.43.0.0294991548565.issue26032@psf.upfronthosting.co.za> Ben Hoyt added the comment: Guido, it's true that in almost all cases you get the speedup (no system call), and it's very much worth using. But the idea with the docs being non-committal is because being specific would make the docs fairly complex. I believe it's as follows for is_file/is_dir/is_symlink: * no system call required on Windows or Unix if the entry is not a symlink * unless you're on Unix with some different file system (maybe a network FS?) where d_type is DT_UNKNOWN * some other edge case which I've probably forgotten :-) Do you think the docs should try to make this more specific? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 20:29:30 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 07 Jan 2016 01:29:30 +0000 Subject: [issue26032] Use scandir() to speed up pathlib globbing In-Reply-To: <1452128813.43.0.0294991548565.issue26032@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Ben, I think it's worth calling out what the rules are around symlinks. I'm guessing the info that is initially present is a subset of lstat(), so if that indicates it's a symlink, is_dir() and is_file() will need a stat() call, *unless* follow_symlinks is False. Another question: for symlinks, there are two different possible stat results: one for stat() and one for lstat(). Are these both cached separately? Or is only one of them? (Experimentally, they are either both cached or the cache remembers the follow_symlinks flag and re-fetches the other result.) Related, "this method always requires a system call", that remark seems to disregard the cache. I'd be happy to review a doc update patch if you make one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 20:44:45 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 07 Jan 2016 01:44:45 +0000 Subject: [issue23921] Standardize documentation whitespace, formatting In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za> Message-ID: <1452131085.83.0.644204275974.issue23921@psf.upfronthosting.co.za> Martin Panter added the comment: I do prefer extra space before a comment, otherwise it looks too much like some kind of ?x # y? binary operator. So I think those changes are worthwhile. I left some review comments, mainly minor suggestions. Most of the other changes look worthwhile. Others I don?t mind either way, but I can understand others may prefer them, such as lining up hanging indents for fixed-width fonts. David: did you end up looking this? Are there any particular bits you think are not worth it? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 21:36:21 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 07 Jan 2016 02:36:21 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1452118417.4.0.321051515733.issue22995@psf.upfronthosting.co.za> Message-ID: <20160106213612.65adafe3@limelight.wooz.org> Barry A. Warsaw added the comment: On Jan 06, 2016, at 10:13 PM, Serhiy Storchaka wrote: >What return __reduce_ex__(4) for the NameAssignment instance in 3.5.0? I'm not sure yet (it takes some time to set up the right environment to test this), but I do know which TypeError is getting triggered. In typeobject.c, it's this stanza in _PyObject_GetState(): assert(slotnames == Py_None || PyList_Check(slotnames)); if (required) { Py_ssize_t basicsize = PyBaseObject_Type.tp_basicsize; if (obj->ob_type->tp_dictoffset) basicsize += sizeof(PyObject *); if (obj->ob_type->tp_weaklistoffset) basicsize += sizeof(PyObject *); if (slotnames != Py_None) basicsize += sizeof(PyObject *) * Py_SIZE(slotnames); if (obj->ob_type->tp_basicsize > basicsize) { Py_DECREF(slotnames); Py_DECREF(state); PyErr_Format(PyExc_TypeError, "can't pickle %.200s objects", Py_TYPE(obj)->tp_name); return NULL; } } I don't yet know why the basicsize isn't matching up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 23:09:21 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jan 2016 04:09:21 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <1452139761.68.0.827305295168.issue22570@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 23:09:52 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jan 2016 04:09:52 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1452139792.22.0.825735683083.issue25958@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 23:11:13 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jan 2016 04:11:13 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1452139873.63.0.357774347151.issue25596@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 23:11:57 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jan 2016 04:11:57 +0000 Subject: [issue21159] configparser.InterpolationMissingOptionError is not very intuitive In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za> Message-ID: <1452139917.15.0.00856983587347.issue21159@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 23:12:49 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jan 2016 04:12:49 +0000 Subject: [issue23921] Standardize documentation whitespace, formatting In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za> Message-ID: <1452139969.38.0.465024278861.issue23921@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 23:13:58 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jan 2016 04:13:58 +0000 Subject: [issue23921] Standardize documentation whitespace, formatting In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za> Message-ID: <1452140038.3.0.907172497845.issue23921@psf.upfronthosting.co.za> R. David Murray added the comment: Sorry, I'm not going to have time to look at it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 23:14:17 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jan 2016 04:14:17 +0000 Subject: [issue23921] Standardize documentation whitespace, formatting In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za> Message-ID: <1452140057.28.0.247011983222.issue23921@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 23:38:52 2016 From: report at bugs.python.org (Dan Sadowski) Date: Thu, 07 Jan 2016 04:38:52 +0000 Subject: [issue26034] venv documentation out of date Message-ID: <1452141532.31.0.700374014076.issue26034@psf.upfronthosting.co.za> New submission from Dan Sadowski: The listing for the --clear option in the documentation is outdated. This is from the actual current 3.5 usage text: --clear Delete the contents of the environment directory if it already exists, before environment creation. ---------- assignee: docs at python components: Documentation messages: 257669 nosy: docs at python, dsadowski priority: normal severity: normal status: open title: venv documentation out of date versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 23:47:35 2016 From: report at bugs.python.org (Nicholas Chammas) Date: Thu, 07 Jan 2016 04:47:35 +0000 Subject: [issue26035] traceback.print_tb() takes `tb`, not `traceback` as a keyword argument Message-ID: <1452142055.04.0.968906484949.issue26035@psf.upfronthosting.co.za> New submission from Nicholas Chammas: Here is traceback.print_tb()'s signature [0]: ``` def print_tb(tb, limit=None, file=None): ``` However, its documentation reads [1]: ``` .. function:: print_tb(traceback, limit=None, file=None) ``` Did the keyword argument change recently, or was this particular doc always wrong? [0] https://github.com/python/cpython/blob/1fe0fd9feb6a4472a9a1b186502eb9c0b2366326/Lib/traceback.py#L43 [1] https://raw.githubusercontent.com/python/cpython/1fe0fd9feb6a4472a9a1b186502eb9c0b2366326/Doc/library/traceback.rst ---------- assignee: docs at python components: Documentation messages: 257670 nosy: Nicholas Chammas, docs at python priority: normal severity: normal status: open title: traceback.print_tb() takes `tb`, not `traceback` as a keyword argument versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 00:31:20 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Jan 2016 05:31:20 +0000 Subject: [issue16544] Add external link to ast docs In-Reply-To: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za> Message-ID: <20160107053117.53718.70317@psf.io> Roundup Robot added the comment: New changeset 94b0e5e9b6e8 by Senthil Kumaran in branch '3.4': Issue16544 - Add a link to an external documentation resource in ast module docs. https://hg.python.org/cpython/rev/94b0e5e9b6e8 New changeset ebf164b07be1 by Senthil Kumaran in branch '3.5': merge from 3.4 https://hg.python.org/cpython/rev/ebf164b07be1 New changeset 62e88e5a61c0 by Senthil Kumaran in branch 'default': merge from 3.5 https://hg.python.org/cpython/rev/62e88e5a61c0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 00:34:32 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 07 Jan 2016 05:34:32 +0000 Subject: [issue16544] Add external link to ast docs In-Reply-To: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za> Message-ID: <1452144872.82.0.180623190016.issue16544@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks for patch and the work on Green Tree Snakes, Thomas. It is a great resource. I agree that a lot could be included directly in stdlib docs, but till then, as suggested/recommended by Andrew and Ezio, a see also link is a good addition. ---------- assignee: ezio.melotti -> orsenthil nosy: +orsenthil resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 00:35:20 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 07 Jan 2016 05:35:20 +0000 Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL certificate In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za> Message-ID: <1452144920.36.0.0587260148246.issue25940@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- assignee: -> martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 01:13:07 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 07 Jan 2016 06:13:07 +0000 Subject: [issue26035] traceback.print_tb() takes `tb`, not `traceback` as a keyword argument In-Reply-To: <1452142055.04.0.968906484949.issue26035@psf.upfronthosting.co.za> Message-ID: <1452147187.52.0.126779238402.issue26035@psf.upfronthosting.co.za> Martin Panter added the comment: According to the history, the parameter was always called ?tb? in the implementation , and the documentation always had it wrong . So I would change the documentation to ?tb?. It looks like other functions in this module have the wrong parameter names also. ---------- nosy: +martin.panter stage: -> needs patch versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 01:46:45 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 07 Jan 2016 06:46:45 +0000 Subject: [issue26030] Use PEP8 in documentation examples In-Reply-To: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> Message-ID: <1452149205.45.0.505007263481.issue26030@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > I found a lot of missing spaces around binary operators Please don't make trivial changes like this. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 02:06:16 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 07 Jan 2016 07:06:16 +0000 Subject: [issue26030] Use PEP8 in documentation examples In-Reply-To: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> Message-ID: <1452150376.46.0.526119132911.issue26030@psf.upfronthosting.co.za> Martin Panter added the comment: If it is fixing stuff like ?lambda x: x +1? (from Issue 23921), I am in favour. But if the code example is self-consistent and uses a reasonable style, it should not be changed. Julien, perhaps you should give an example to clarify. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 02:16:09 2016 From: report at bugs.python.org (INADA Naoki) Date: Thu, 07 Jan 2016 07:16:09 +0000 Subject: [issue26030] Use PEP8 in documentation examples In-Reply-To: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> Message-ID: <1452150969.03.0.744594774887.issue26030@psf.upfronthosting.co.za> INADA Naoki added the comment: No spaces around binary operator is OK in PEP8. See http://bugs.python.org/issue11425 ---------- nosy: +naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 03:02:23 2016 From: report at bugs.python.org (Hristo Venev) Date: Thu, 07 Jan 2016 08:02:23 +0000 Subject: [issue26026] True%2 is True In-Reply-To: <1452105494.05.0.152464370821.issue26026@psf.upfronthosting.co.za> Message-ID: <1452153743.28.0.711400727146.issue26026@psf.upfronthosting.co.za> Hristo Venev added the comment: OK. class A(int): pass a=A(1) b=A(2) print(type(a*b), type(a+b), type(a-b), type(a**b), type(a^b), type(a&b), type(a|b), type(a//b), type(a%b)) ---------- resolution: not a bug -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 03:34:35 2016 From: report at bugs.python.org (SilentGhost) Date: Thu, 07 Jan 2016 08:34:35 +0000 Subject: [issue26026] True%2 is True In-Reply-To: <1452105494.05.0.152464370821.issue26026@psf.upfronthosting.co.za> Message-ID: <1452155675.41.0.154383093284.issue26026@psf.upfronthosting.co.za> SilentGhost added the comment: Hristo, python is a duck typing language. You should not have to care about the type of a variable as long as it does what's intended. Seeking consistency where none is required will just end up being huge waste of everyone's time. If you're so convinced in the rightness of your opinion, please take it to python-ideas mailing list and have it discussed there first before re-opening issue in the future. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 03:45:29 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 07 Jan 2016 08:45:29 +0000 Subject: [issue26035] traceback.print_tb() takes `tb`, not `traceback` as a keyword argument In-Reply-To: <1452142055.04.0.968906484949.issue26035@psf.upfronthosting.co.za> Message-ID: <1452156329.49.0.573203813803.issue26035@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 03:53:40 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 07 Jan 2016 08:53:40 +0000 Subject: [issue26032] Use scandir() to speed up pathlib globbing In-Reply-To: Message-ID: STINNER Victor added the comment: "Another question: for symlinks, there are two different possible stat results: one for stat() and one for lstat(). Are these both cached separately?" Hopefully, both are cached. It's directly the result of stat() and stat(follow_symlinks=False) which are cached (so a os.stat_result object). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 04:13:08 2016 From: report at bugs.python.org (Hristo Venev) Date: Thu, 07 Jan 2016 09:13:08 +0000 Subject: [issue26026] True%2 is True In-Reply-To: <1452105494.05.0.152464370821.issue26026@psf.upfronthosting.co.za> Message-ID: <1452157988.96.0.966903368433.issue26026@psf.upfronthosting.co.za> Hristo Venev added the comment: One last thing: type(a%b) is A, type(b%a) is int. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 04:37:44 2016 From: report at bugs.python.org (Hristo Venev) Date: Thu, 07 Jan 2016 09:37:44 +0000 Subject: [issue26026] True%2 is True In-Reply-To: <1452105494.05.0.152464370821.issue26026@psf.upfronthosting.co.za> Message-ID: <1452159464.48.0.601663623148.issue26026@psf.upfronthosting.co.za> Hristo Venev added the comment: type( A(1) % A(2) ) is A type( A(1) % A(-2) ) is int type( A(-1) % A(-2) ) is A type( A(2) % A(1) ) is int type( A(1) % A(2**30+2) ) is A type( A(2**30+1) % A(2**30+2) ) is int type( A(2**15+1) % A(2**15+2) ) is (A if 64bit else int) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 06:01:17 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 07 Jan 2016 11:01:17 +0000 Subject: [issue22088] base64 module still ignores non-alphabet characters In-Reply-To: <1406414649.83.0.15731376973.issue22088@psf.upfronthosting.co.za> Message-ID: <1452164477.24.0.659258438229.issue22088@psf.upfronthosting.co.za> Martin Panter added the comment: This new patch applies to Python 3. As well as the above changes, I updated the doc strings based on the changes in 92760d2edc9e (Issue 1753718, Issue 20782), mainly clarifying the data types functions accept and return. Further fixes: * In Python 3, b16decode() raises binascii.Error, not TypeError * The base-85 functions? data parameter is called ?b?, not ?s? ---------- Added file: http://bugs.python.org/file41522/base64-discard.py3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 06:43:31 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 07 Jan 2016 11:43:31 +0000 Subject: [issue26012] pathlib.Path().rglob() is fooled by symlink loops In-Reply-To: <1451960031.51.0.813695149526.issue26012@psf.upfronthosting.co.za> Message-ID: <1452167011.19.0.912135142107.issue26012@psf.upfronthosting.co.za> Martin Panter added the comment: This seems to have broken test_pathlib, both on my computer and some Linux and BSD buildbots: ====================================================================== FAIL: test_rglob_symlink_loop (test.test_pathlib.PathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/media/disk/home/proj/python/cpython/Lib/test/test_pathlib.py", line 1455, in test_rglob_symlink_loop self.assertEqual(given, {p / x for x in expect}) AssertionError: Items in the second set but not the first: PosixPath('/media/disk/home/proj/python/cpython/build/test_python_27756/@test_27756_tmp/dirA/linkC') PosixPath('/media/disk/home/proj/python/cpython/build/test_python_27756/@test_27756_tmp/dirB/fileB') PosixPath('/media/disk/home/proj/python/cpython/build/test_python_27756/@test_27756_tmp/dirB/linkD') ====================================================================== FAIL: test_rglob_symlink_loop (test.test_pathlib.PosixPathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/media/disk/home/proj/python/cpython/Lib/test/test_pathlib.py", line 1455, in test_rglob_symlink_loop self.assertEqual(given, {p / x for x in expect}) AssertionError: Items in the second set but not the first: PosixPath('/media/disk/home/proj/python/cpython/build/test_python_27756/@test_27756_tmp/dirA/linkC') PosixPath('/media/disk/home/proj/python/cpython/build/test_python_27756/@test_27756_tmp/dirB/fileB') PosixPath('/media/disk/home/proj/python/cpython/build/test_python_27756/@test_27756_tmp/dirB/linkD') ---------- nosy: +martin.panter status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 07:16:23 2016 From: report at bugs.python.org (Cal Leeming) Date: Thu, 07 Jan 2016 12:16:23 +0000 Subject: [issue26036] Unnecessary arguments on smtpd.SMTPServer Message-ID: <1452168983.71.0.914590889995.issue26036@psf.upfronthosting.co.za> New submission from Cal Leeming: `smtpd.SMTPServer` takes argument `remoteaddr`, however this is only used in subclass `smtpd.DebuggingServer`. Would anyone object to a patch which removes `remoteaddr` from `smtpd.SMTPServer.__init__` and places it into `smtpd.DebuggingServer.__init__` instead? Naturally this would be backwards incompatible ---------- components: Library (Lib) messages: 257684 nosy: sleepycal priority: normal severity: normal status: open title: Unnecessary arguments on smtpd.SMTPServer type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 07:43:44 2016 From: report at bugs.python.org (=?utf-8?b?ZXBoIOKAiw==?=) Date: Thu, 07 Jan 2016 12:43:44 +0000 Subject: [issue26037] Crash when reading sys.stdin.buffer in a daemon thread Message-ID: <1452170624.64.0.0901256170606.issue26037@psf.upfronthosting.co.za> New submission from eph ?: I wrote a script to non-blocking reading binary data from stdin like this: import sys, threading def _thread(): data = sys.stdin.buffer.readline() thread = threading.Thread(target=_thread) thread.daemon = True thread.start() and the output is like this: Fatal Python error: could not acquire lock for <_io.BufferedReader name=''> at interpreter shutdown, possibly due to daemon threads Thread 0x00007faf54ebf700 (most recent call first): File "pipetcpadapter.py", line 8 in func File "/usr/lib/python3.5/threading.py", line 862 in run File "/usr/lib/python3.5/threading.py", line 914 in _bootstrap_inner File "/usr/lib/python3.5/threading.py", line 882 in _bootstrap Current thread 0x00007faf566da700 (most recent call first): Aborted (core dumped) ---------- components: IO messages: 257685 nosy: eph ? priority: normal severity: normal status: open title: Crash when reading sys.stdin.buffer in a daemon thread type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 07:46:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Jan 2016 12:46:07 +0000 Subject: [issue26032] Use scandir() to speed up pathlib globbing In-Reply-To: <1452120927.04.0.31788168865.issue26032@psf.upfronthosting.co.za> Message-ID: <1452170767.2.0.310478209376.issue26032@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Library (Lib) dependencies: +File descriptor leaks in os.scandir(), regular files handled as directories in the glob module versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 08:26:28 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Jan 2016 13:26:28 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1452173188.04.0.935168171801.issue22995@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I can understand why. AFAIK Cython creates a class that stores attributes not in __dict__, but packed in a structure, as for __slots__. This increases the basicstate. But if it doesn't provide nor __dict__, nor __slotnames__, nor any pickle-related method, the default implementation object.__reduce_ex__ returned a value that didn't contain the full state of the object. Therefore the object couldn't be correctly unpickled, copied, or deepcopied. If this is true, there is a bug in Cython. But if deepcopying worked for Cython objects, we need to find how object's state is retrieved and take this into account in our code. If this is Cython bug, may be we have to change an exception to a warning in maintained releases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 08:29:43 2016 From: report at bugs.python.org (Brett Rosen) Date: Thu, 07 Jan 2016 13:29:43 +0000 Subject: [issue26038] zipfile cannot handle zip files where the archive size for a file does not match actual contents Message-ID: <1452173383.07.0.105152287179.issue26038@psf.upfronthosting.co.za> New submission from Brett Rosen: In python 2.7 it was able to handle this. It looks like this was introduced in https://github.com/python/cpython/commit/ae489fa76bb02daa636afe3bebec232e5aa9fac5 . I'm not really sure if this should be considered a regression or not since the zip files that trigger this could be considered bad, even though unzip and older versions of zipfile.py could handle them. I've attached a copy of a local diff I applied that worked around this issue, but I don't think it is a proper fix. ---------- components: Library (Lib) files: changes.diff keywords: patch messages: 257687 nosy: Brett Rosen priority: normal severity: normal status: open title: zipfile cannot handle zip files where the archive size for a file does not match actual contents type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file41523/changes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 08:50:12 2016 From: report at bugs.python.org (INADA Naoki) Date: Thu, 07 Jan 2016 13:50:12 +0000 Subject: [issue24870] Optimize ascii and latin1 decoder with surrogateescape and surrogatepass error handlers In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za> Message-ID: <1452174612.79.0.567859378376.issue24870@psf.upfronthosting.co.za> INADA Naoki added the comment: FYI, I found a workaround. https://github.com/PyMySQL/PyMySQL/pull/409 _table = [chr(i) for i in range(128)] + [chr(i) for i in range(0xdc80, 0xdd00)] def decode_surroundescape(s): return s.decode('latin1').translate(_table) In [15]: data = b'\xff' * 1024 * 1024 In [16]: data.decode('ascii', 'surrogateescape') == decode_surroundescape(data) Out[16]: True In [17]: %timeit data.decode('ascii', 'surrogateescape') 1 loops, best of 3: 394 ms per loop In [18]: %timeit decode_surroundescape(data) 10 loops, best of 3: 40 ms per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 08:51:51 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 07 Jan 2016 13:51:51 +0000 Subject: [issue24870] Optimize ascii and latin1 decoder with surrogateescape and surrogatepass error handlers In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za> Message-ID: <1452174711.67.0.070171737313.issue24870@psf.upfronthosting.co.za> STINNER Victor added the comment: > In [18]: %timeit decode_surroundescape(data) > 10 loops, best of 3: 40 ms per loop Cool! Good job. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 08:54:35 2016 From: report at bugs.python.org (Upendra Kumar) Date: Thu, 07 Jan 2016 13:54:35 +0000 Subject: [issue26029] Broken sentence in extending documentation In-Reply-To: <1452116648.24.0.989848174126.issue26029@psf.upfronthosting.co.za> Message-ID: <1452174875.88.0.92316971675.issue26029@psf.upfronthosting.co.za> Upendra Kumar added the comment: I am submitting the patch with small change suggested by you. Thank you. ---------- keywords: +patch nosy: +upendra-k14 Added file: http://bugs.python.org/file41524/building_additional.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 09:02:39 2016 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 07 Jan 2016 14:02:39 +0000 Subject: [issue26029] Broken sentence in extending documentation In-Reply-To: <1452116648.24.0.989848174126.issue26029@psf.upfronthosting.co.za> Message-ID: <1452175359.13.0.773617602389.issue26029@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> patch review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 09:09:53 2016 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 07 Jan 2016 14:09:53 +0000 Subject: [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452175793.36.0.0820627945414.issue26020@psf.upfronthosting.co.za> Neil Girdhar added the comment: If BUIlD_SET is going to be changed, it would probably be could to keep BUILD_SET_UNPACK consistent. ---------- nosy: +neil.g _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 09:29:28 2016 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 07 Jan 2016 14:29:28 +0000 Subject: [issue26036] Unnecessary arguments on smtpd.SMTPServer In-Reply-To: <1452168983.71.0.914590889995.issue26036@psf.upfronthosting.co.za> Message-ID: <1452176968.72.0.0112161585037.issue26036@psf.upfronthosting.co.za> Eric V. Smith added the comment: We won't make such a backward-incompatible change. Because subclassing is how you extend SMTPServer, it's likely to be used by other derived classes, not in the standard library. I could see some argument for making it optional and default to None, but that's about the extent of what I would support. PS: It's used in PureProxy, not DebuggingServer (at least in 3.6, where I checked). ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 09:47:43 2016 From: report at bugs.python.org (Cal Leeming) Date: Thu, 07 Jan 2016 14:47:43 +0000 Subject: [issue26036] Unnecessary arguments on smtpd.SMTPServer In-Reply-To: <1452168983.71.0.914590889995.issue26036@psf.upfronthosting.co.za> Message-ID: <1452178063.8.0.534525696195.issue26036@psf.upfronthosting.co.za> Cal Leeming added the comment: Apologies for the typo, it is indeed `PureProxy`. Setting a default of `None` sounds like a good plan, since it won't break backwards compatibility. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 10:10:51 2016 From: report at bugs.python.org (Thomas Kluyver) Date: Thu, 07 Jan 2016 15:10:51 +0000 Subject: [issue26039] More flexibility in zipfile interface Message-ID: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za> New submission from Thomas Kluyver: I was working recently on some code writing zip files, and needed a bit more flexibility than the interface of zipfile provides. To do what I wanted, I ended up copying the entirety of ZipFile.write() into my own code with modifications. That's ugly, and to make it worse, the code I copied from the Python 3.4 stdlib didn't work properly with Python 3.5. Specifically, I want to: * Override the timestamp, which write() unconditionally takes from the mtime of the file. * Do extra processing on the data (e.g. calculating a checksum) as it is read. Being able to pass a file-like object in to be read, rather than just a filename, would work for this. I could do both by using ZipFile.writestr(), but then the entire file must be loaded into memory at once, which I would much rather avoid. The patch attached is one proposal which would make it easier to do what I want, but it's intended as a starting point for discussion. I'm not particularly attached to the API. - Should this be a new method, or new functionality for either the write or writestr method? I favour a new method, because the existing methods are already quite long, and I think it's nicer to break write() up into two parts like this. - If a new method, what should it be called? I opted for writefile() - What should its signature be? It's currently writefile(file_obj, zinfo, force_zip64=False), but I can see an argument for aligning it with writestr(zinfo_or_arcname, data, compress_type=None). - What to do about ZIP64: the code has to decide whether to use ZIP64 format before writing, because it affects the header size, but we may not know the length before we have read it all. I've used a force_zip64 boolean parameter, and documented that people should pass it True if a file of unknown size could exceed 2 GiB. - Are there other points where it could be made more flexible while we're thinking about this? I'd quite like to split out the code for writing a directory entry to a separate method ('writedir'?). I'd also like to allow datetime objects to be passed in for timestamps as well as the 6-tuples currently expected. ---------- components: Library (Lib) files: zipfile-flexibility.patch keywords: patch messages: 257694 nosy: takluyver priority: normal severity: normal status: open title: More flexibility in zipfile interface type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file41525/zipfile-flexibility.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 10:41:23 2016 From: report at bugs.python.org (Jeff Allen) Date: Thu, 07 Jan 2016 15:41:23 +0000 Subject: [issue26040] Improve coverage and rigour of test.test_math Message-ID: <1452181282.79.0.203850145541.issue26040@psf.upfronthosting.co.za> New submission from Jeff Allen: In many cases, test_math does not exercise the functions defined by the math module, other than at a few values needing special handling. Where it does test a function with values representative of the domain, the accuracy demanded is often loose in one place and tight in another. By comparison, test_cmath uses more interesting values and a rational approach to accuracy. In most implementations, math simply proxies an expertly built (and tested) platform library or firmware, so it is unlikely we are the victims of mathematical inexactitude. We observed this as a problem in the Jython project, where failures in cmath were traced eventually to the naive (but passing) implementation of some functions in math. For Jython, we now supplement test_math with stronger tests more like those in test_cmath. So this issue is really an offer to fold that work back into the CPython test_math, to strengthen testing for all. Coverage: -------- In the attached program, in the coverge section, I logged the calls to selected functions from test_math to see what range of values they used. It produces results like: sqrt [9.881e-324, 7.905e-323, 1.862e-309, 1e-305, 1e-150, ..., 2, 23, 1e+16, 1e+150, 1e+299] [-1] [-0.0, -inf, 0.0, inf, nan] sin [1.571] [-1.571] [-0.0, -inf, 0.0, inf, nan] exp [] [-745] [-0.0, -inf, 0.0, inf, nan] sinh [] [] [-0.0, -inf, 0.0, inf, nan] The three rows here are positive, negative and "special" arguments, and "..." means I abridged the list. Accuracy: -------- Where functions are tested, results are expected with a maximum error of 1e-5. On sqrt(1e150), this demands bit-perfect accuracy; on sqrt(1e-150) it demands virtually nothing. In the attached program, in the accuracy section, I wrap most of the functions so as to fuzz their results by plus or minus 2e-6, test_math will still pass them. test_cmath uses a relative measure of error (so many ulps of the expected value), which is worth emulating. If people think it better, coverage and accuracy can be tracked as separate issues. ---------- components: Tests files: stat_math.py messages: 257695 nosy: jeff.allen, mark.dickinson priority: normal severity: normal status: open title: Improve coverage and rigour of test.test_math type: behavior versions: Python 2.7, Python 3.6 Added file: http://bugs.python.org/file41526/stat_math.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 10:53:31 2016 From: report at bugs.python.org (Matthias Bussonnier) Date: Thu, 07 Jan 2016 15:53:31 +0000 Subject: [issue26039] More flexibility in zipfile interface In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za> Message-ID: <1452182011.41.0.458008074528.issue26039@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: from the last blog post of [Brett Cannon][1], I would say that he might be interested in Participating to this discussion (Rewrite zipimport from scratch section) Though I'm not sure about the etiquette to ping someone on such an issue. [1]: http://www.snarky.ca/my-new-years-programming-resolutions ---------- nosy: +mbussonn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 11:07:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Jan 2016 16:07:17 +0000 Subject: [issue26039] More flexibility in zipfile interface In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za> Message-ID: <1452182837.76.0.861526869284.issue26039@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: issue11980 has a patch that adds a method for writing a file into the ZIP archive. But more flexible way is to add the support of the "w" mode to ZipFile.open(). This will allow to write a data that doesn't exist in memory at once, nor in disk, but is loaded by chunks from the pipe, or from the socket, or from other archive, or just generated on fly. I'm worked on this, but this feature needed to add support of some other features. For example writing to unseekable file (already implemented) or writing and reading a file without known size (not implemented still). issue18595 has a proposition to add special methods for creating symlinks, directories etc. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 11:18:30 2016 From: report at bugs.python.org (Stefan Pfeil) Date: Thu, 07 Jan 2016 16:18:30 +0000 Subject: [issue25824] 32-bit 2.7.11 installer creates registry keys that are incompatible with the installed python27.dll In-Reply-To: <1449584200.04.0.891595448742.issue25824@psf.upfronthosting.co.za> Message-ID: <1452183510.02.0.515484721368.issue25824@psf.upfronthosting.co.za> Changes by Stefan Pfeil : ---------- nosy: +pfeil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 11:26:16 2016 From: report at bugs.python.org (Stefan Pfeil) Date: Thu, 07 Jan 2016 16:26:16 +0000 Subject: [issue25824] 32-bit 2.7.11 installer creates registry keys that are incompatible with the installed python27.dll In-Reply-To: <1449584200.04.0.891595448742.issue25824@psf.upfronthosting.co.za> Message-ID: <1452183976.35.0.259524341394.issue25824@psf.upfronthosting.co.za> Stefan Pfeil added the comment: Our installations of Python Essentials for SPSS Statistics 21 (64bit, presumeably also 32bit) were also broken by this issue (Python Essentials for SPSS 21 uses the regular Python 2.7 folder/installation). The workaround with renaming the mentioned registry key works here as well (we still decided to hold back the update to Python 2.7.11 for the moment). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 11:44:14 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 07 Jan 2016 16:44:14 +0000 Subject: [issue26012] pathlib.Path().rglob() is fooled by symlink loops In-Reply-To: <1451960031.51.0.813695149526.issue26012@psf.upfronthosting.co.za> Message-ID: <1452185054.79.0.104514250535.issue26012@psf.upfronthosting.co.za> Guido van Rossum added the comment: Oops, sorry about that. I will see if I can figure out how to repro this -- on my own Mac it succeeds. In the mean time if you could have a look yourself (since you can repro it on your own computer) I'd be grateful. Initial hunches: maybe a case-insensitivity crept into the test? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 11:46:00 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Jan 2016 16:46:00 +0000 Subject: [issue5501] Update multiprocessing docs re: freeze_support In-Reply-To: <1237312904.73.0.910184118935.issue5501@psf.upfronthosting.co.za> Message-ID: <20160107164553.30364.52721@psf.io> Roundup Robot added the comment: New changeset f08d4712a055 by Berker Peksag in branch '3.5': Issue #5501: Clarify that invoking freeze_support() on non-Windows platforms has no effect https://hg.python.org/cpython/rev/f08d4712a055 New changeset 2902f32d1ae9 by Berker Peksag in branch 'default': Issue #5501: Clarify that invoking freeze_support() on non-Windows platforms has no effect https://hg.python.org/cpython/rev/2902f32d1ae9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 11:50:04 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Jan 2016 16:50:04 +0000 Subject: [issue5501] Update multiprocessing docs re: freeze_support In-Reply-To: <1237312904.73.0.910184118935.issue5501@psf.upfronthosting.co.za> Message-ID: <20160107164956.69599.91479@psf.io> Roundup Robot added the comment: New changeset 8b20a606ecde by Berker Peksag in branch '2.7': Issue #5501: Clarify that invoking freeze_support() on non-Windows platforms has no effect https://hg.python.org/cpython/rev/8b20a606ecde ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 11:54:59 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 07 Jan 2016 16:54:59 +0000 Subject: [issue5501] Update multiprocessing docs re: freeze_support In-Reply-To: <1237312904.73.0.910184118935.issue5501@psf.upfronthosting.co.za> Message-ID: <1452185699.51.0.623518456984.issue5501@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks Davin and Camilla. ---------- nosy: +berker.peksag resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 11:58:44 2016 From: report at bugs.python.org (Dan Kegel) Date: Thu, 07 Jan 2016 16:58:44 +0000 Subject: [issue1633941] for line in sys.stdin: doesn't notice EOF the first time Message-ID: <1452185924.91.0.190597518372.issue1633941@psf.upfronthosting.co.za> Dan Kegel added the comment: Still present in python 2.7.9, but fixed in python 3.4.3. Also, in python 3.4.3, output is immediate, there seems to be no input buffering. ---------- nosy: +dankegel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 12:18:20 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 07 Jan 2016 17:18:20 +0000 Subject: [issue26041] Update deprecation messages of platform.dist() and platform.linux_distribution() Message-ID: <1452187100.03.0.384540652472.issue26041@psf.upfronthosting.co.za> New submission from Berker Peksag: We need to remove "and will be removed in Python 3.7" from deprecation messages of platform.dist() and platform.linux_distribution() and update the relevant whatsnew entry in Doc/whatsnew/3.5.rst. See msg256111 in issue 1322 for details. ---------- components: Library (Lib) keywords: easy messages: 257704 nosy: berker.peksag priority: normal severity: normal stage: needs patch status: open title: Update deprecation messages of platform.dist() and platform.linux_distribution() type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 12:52:21 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 07 Jan 2016 17:52:21 +0000 Subject: [issue26042] Consider dropping magic number for more detailed .pyc file name Message-ID: <1452189141.27.0.112439951883.issue26042@psf.upfronthosting.co.za> New submission from Brett Cannon: The reason the magic number exists in .pyc files is because back in Python 2 we only had a single .pyc file per module, which meant if you suddenly switched versions of Python you needed a way to know that the .pyc file was wrong for the running version of Python. This is not the case in Python 3. Thanks to __pycache__ directories we have separate .pyc files per release version of Python (we also have .pyc files for each optimization level of Python). If we changed the sys.implementation.cache_tag to include the bugfix version -- and maybe even release level -- then the magic number wouldn't be necessary for users. It does make developing bytecode a little bit more difficult for core developers since they will have to clear out their .pyc files during development, but users wouldn't be affected. Now I don't know if this is really worth the simplification it provides. I don't think it's worth the compatibility break for any code that may be reading .pyc files and I doubt there is any measurable performance benefit. But the realization struck me and I figured I should at least write it down in case anyone else thinks of it. ---------- components: Interpreter Core messages: 257705 nosy: brett.cannon, eric.snow, ncoghlan priority: low severity: normal stage: test needed status: open title: Consider dropping magic number for more detailed .pyc file name type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 12:52:39 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 07 Jan 2016 17:52:39 +0000 Subject: [issue26027] Support Path objects in the posix module In-Reply-To: <1452114329.99.0.617690911804.issue26027@psf.upfronthosting.co.za> Message-ID: <1452189159.06.0.496021945777.issue26027@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 12:53:55 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 07 Jan 2016 17:53:55 +0000 Subject: [issue26031] Add stat caching option to pathlib In-Reply-To: <1452120089.84.0.0792910513701.issue26031@psf.upfronthosting.co.za> Message-ID: <1452189235.53.0.804249490557.issue26031@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 12:55:31 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 07 Jan 2016 17:55:31 +0000 Subject: [issue26032] Use scandir() to speed up pathlib globbing In-Reply-To: <1452120927.04.0.31788168865.issue26032@psf.upfronthosting.co.za> Message-ID: <1452189331.2.0.192782068492.issue26032@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 13:02:29 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 07 Jan 2016 18:02:29 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1452189749.08.0.142066946321.issue22995@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Your explanation still doesn't entirely make sense to me yet because the crash is happening in what seems to be a Cython implementation class, not a generated class based on a .pyx in some other project using Cython. I tried to search the Cython Trac but either my Trac-fu sucks or nobody has yet reported compatibility problems with Python 3.5.1 to upstream. I don't see any other relevant bug reports, and Cython's git head passes its test suite with Python 3.5.1 (other than the asyncio_generators test which is probably unrelated and has already been reported to the Cython mailing list). It's always possible of course that the Python change is triggering a bug not caught by the Cython test suite, but something as fundamental as pickling would be surprising if not tested. Turning the error into a warning does have a lot of appeal for 3.5 maintenance. It could be kept as an error in 3.6. At the least, can the exception text include more information about *why* the pickling failure occurs. (Note that the exact error message can be raised in multiple places, so I had to build a custom 3.5.1 to distinguish between them; I don't have gdb set up in the build environment yet.) It's still worth better understanding why this change is causing the bugs in projects using Cython, and reviewing what happens with Python 3.5.0. For completeness, I also want to verify that there isn't some problem specifically related to Ubuntu's version of Python 3.5.1, although the tests against Cython's git head use the same version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 13:43:57 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 07 Jan 2016 18:43:57 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <1452192236.99.0.729351765838.issue24120@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think this is not fixed yet. The try/except clause is currently around certain loops whereas it should be around specific calls (is_dir, exists, listdir. and is_symlink). As it currently is, the behavior is dependent on the ordering of the names returned by listdir(), which is just wrong. I think this is the root cause of the breakage reported in issue #26012. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 13:44:49 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 07 Jan 2016 18:44:49 +0000 Subject: [issue26012] pathlib.Path().rglob() is fooled by symlink loops In-Reply-To: <1451960031.51.0.813695149526.issue26012@psf.upfronthosting.co.za> Message-ID: <1452192289.95.0.335949953928.issue26012@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks like the root cause of the breakage is actually that issue #24120 isn't quite fixed yet. I'm now able to repro on a Linux VM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 13:57:09 2016 From: report at bugs.python.org (Vitaminus Maximus) Date: Thu, 07 Jan 2016 18:57:09 +0000 Subject: [issue26043] ON DELETE CASCADE does not work when using sqlite3 library Message-ID: <1452193029.87.0.593726838819.issue26043@psf.upfronthosting.co.za> New submission from Vitaminus Maximus: Let me provide a completely reproducible code, which demonstrates the issue: >>> import sqlite3 >>> cnx = sqlite3.connect("mytest.db") >>> cnx.isolation_level = None >>> cursor = cnx.cursor() >>> cnx.execute("BEGIN") >>> cursor.execute("CREATE TABLE test_table (id integer)") >>> cursor.execute("CREATE UNIQUE INDEX id_primary ON test_table(id)") >>> cursor.execute("INSERT INTO test_table (id) VALUES (1),(2),(3)") >>> cursor.execute("CREATE TABLE test_table_2(id_fk integer, txt text, FOREIGN KEY (id_fk) REFERENCES test_table(id) ON DELETE CASCADE)") >>> cursor.execute("INSERT INTO test_table_2 (id_fk, txt) VALUES (1,\"one\"),(2,\"two\"),(3,\"three\")") >>> res = cursor.execute("SELECT * FROM test_table_2") >>> res >>> for r in res: ... print(r) ... (1, 'one') (2, 'two') (3, 'three') >>> cursor.execute("PRAGMA foreign_keys = ON") >>> cursor.execute("DELETE FROM test_table WHERE id = 1") >>> res = cursor.execute("SELECT * FROM test_table_2") >>> for r in res: ... print(r) ... (1, 'one') (2, 'two') (3, 'three') As you can see, even though I explicitly set isolation_level, start transaction and specify PRAGMA foreign_keys = ON, it does not work. The expected behaviour is that when I run the last SELECT command, it should return only two rows (because a "parent" raw with id = 1 was deleted). By the way, if I run these commands in pure sqlite prompt, then I get what I expect to see. ---------- components: Library (Lib) messages: 257709 nosy: Vitaminus Maximus priority: normal severity: normal status: open title: ON DELETE CASCADE does not work when using sqlite3 library type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 13:58:59 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Jan 2016 18:58:59 +0000 Subject: [issue26012] pathlib.Path().rglob() is fooled by symlink loops In-Reply-To: <1451960031.51.0.813695149526.issue26012@psf.upfronthosting.co.za> Message-ID: <20160107185857.9620.76527@psf.io> Roundup Robot added the comment: New changeset 4043e08e6e52 by Guido van Rossum in branch '3.4': Add another try/except PermissionError to avoid depending on listdir order. Fix issues #24120 and #26012. https://hg.python.org/cpython/rev/4043e08e6e52 New changeset 8a3b0c1fb3d3 by Guido van Rossum in branch '3.5': Add another try/except PermissionError to avoid depending on listdir order. Fix issues #24120 and #26012. (Merge 3.4->3.5) https://hg.python.org/cpython/rev/8a3b0c1fb3d3 New changeset 398cb8c183da by Guido van Rossum in branch 'default': Add another try/except PermissionError to avoid depending on listdir order. Fix issues #24120 and #26012. (Merge 3.5->3.6) https://hg.python.org/cpython/rev/398cb8c183da ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 13:58:59 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Jan 2016 18:58:59 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <20160107185857.9620.36350@psf.io> Roundup Robot added the comment: New changeset 4043e08e6e52 by Guido van Rossum in branch '3.4': Add another try/except PermissionError to avoid depending on listdir order. Fix issues #24120 and #26012. https://hg.python.org/cpython/rev/4043e08e6e52 New changeset 8a3b0c1fb3d3 by Guido van Rossum in branch '3.5': Add another try/except PermissionError to avoid depending on listdir order. Fix issues #24120 and #26012. (Merge 3.4->3.5) https://hg.python.org/cpython/rev/8a3b0c1fb3d3 New changeset 398cb8c183da by Guido van Rossum in branch 'default': Add another try/except PermissionError to avoid depending on listdir order. Fix issues #24120 and #26012. (Merge 3.5->3.6) https://hg.python.org/cpython/rev/398cb8c183da ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 13:59:52 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 07 Jan 2016 18:59:52 +0000 Subject: [issue26012] pathlib.Path().rglob() is fooled by symlink loops In-Reply-To: <1451960031.51.0.813695149526.issue26012@psf.upfronthosting.co.za> Message-ID: <1452193192.62.0.126251506819.issue26012@psf.upfronthosting.co.za> Guido van Rossum added the comment: Should be fixed for real now. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 14:00:14 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 07 Jan 2016 19:00:14 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <1452193214.95.0.129622801092.issue24120@psf.upfronthosting.co.za> Guido van Rossum added the comment: Should be fixed for real now. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 14:14:34 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 07 Jan 2016 19:14:34 +0000 Subject: [issue26042] Consider dropping magic number for more detailed .pyc file name In-Reply-To: <1452189141.27.0.112439951883.issue26042@psf.upfronthosting.co.za> Message-ID: <1452194074.17.0.647459053278.issue26042@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 14:28:19 2016 From: report at bugs.python.org (Joseph Fox-Rabinovitz) Date: Thu, 07 Jan 2016 19:28:19 +0000 Subject: [issue26044] Name mangling overrides externally defined names Message-ID: <1452194899.15.0.985986475185.issue26044@psf.upfronthosting.co.za> New submission from Joseph Fox-Rabinovitz: I will begin by including three code snippets that do not work to illustrate the issue. All snippets were run as python modules/scripts from the command line using "python snippet.py": **1** __a = 3 print(locals()) class T: def __init__(self): global __a self.a = __a t1 = T() **2** __a = 3 print(locals()) class T: def __init__(self): self.a = __a t2 = T() **3** __a = 3 print(locals()) class T: def __init__(self): m = sys.modules[__name__] self.a = m.__a t3 = T() All three snippets fail in the line assigning `self.a`. The first two produce `NameError: name '_T__a' is not defined`. The third produces `AttributeError: module '__main__' has no attribute '_T__a'`. The problem in all three cases is that name mangling supercedes any other operation to the point that it mangles elements that are explicitly stated not to belong to the class. This behavior is not intuitive or expected. I am running `Python 3.5.1 :: Continuum Analytics, Inc.` (using the Anaconda platform) on a Red Hat 6.5 machine. I have tried the same thing on Arch Linux (also with Python 3.5.1 and anaconda) with identical results. ---------- components: Interpreter Core messages: 257714 nosy: madphysicist priority: normal severity: normal status: open title: Name mangling overrides externally defined names type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 14:53:06 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 07 Jan 2016 19:53:06 +0000 Subject: [issue26044] Name mangling overrides externally defined names In-Reply-To: <1452194899.15.0.985986475185.issue26044@psf.upfronthosting.co.za> Message-ID: <1452196386.24.0.418807147805.issue26044@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman resolution: -> not a bug stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 14:54:34 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 07 Jan 2016 19:54:34 +0000 Subject: [issue26036] Unnecessary arguments on smtpd.SMTPServer In-Reply-To: <1452168983.71.0.914590889995.issue26036@psf.upfronthosting.co.za> Message-ID: <1452196474.5.0.819489891175.issue26036@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 14:56:17 2016 From: report at bugs.python.org (Ethan Furman) Date: Thu, 07 Jan 2016 19:56:17 +0000 Subject: [issue26044] Name mangling overrides externally defined names In-Reply-To: <1452194899.15.0.985986475185.issue26044@psf.upfronthosting.co.za> Message-ID: <1452196577.95.0.236827365345.issue26044@psf.upfronthosting.co.za> Ethan Furman added the comment: Nice work with the debugging. but what you have proved is that Python is behaving exactly as designed [0]. While true that the current implementation does have the pitfall you have discovered, removing it is not worth the cost in complexity. The proper "fix" is not to have __vars outside of a class. [0] [https://docs.python.org/2/tutorial/classes.html#private-variables-and-class-local-references] ---------- resolution: not a bug -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 15:58:09 2016 From: report at bugs.python.org (Andrew Barnert) Date: Thu, 07 Jan 2016 20:58:09 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1452200289.45.0.338901442528.issue25958@psf.upfronthosting.co.za> Changes by Andrew Barnert : Added file: http://bugs.python.org/file41527/patch4a.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 16:00:15 2016 From: report at bugs.python.org (Eric Snow) Date: Thu, 07 Jan 2016 21:00:15 +0000 Subject: [issue26042] Consider dropping magic number for more detailed .pyc file name In-Reply-To: <1452189141.27.0.112439951883.issue26042@psf.upfronthosting.co.za> Message-ID: <1452200415.67.0.964371739188.issue26042@psf.upfronthosting.co.za> Eric Snow added the comment: That's an interesting thought. My intuition is that it wouldn't be worth doing. It would certainly trade one development overhead for another, so it's a bit of a wash there, I think. Are there other spots in the stdlib that rely on the magic number? Is it used much outside the stdlib? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 16:15:54 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 07 Jan 2016 21:15:54 +0000 Subject: [issue26012] pathlib.Path().rglob() is fooled by symlink loops In-Reply-To: <1451960031.51.0.813695149526.issue26012@psf.upfronthosting.co.za> Message-ID: <1452201354.57.0.766218648395.issue26012@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks, your latest change seems to have fixed it on my Linux computer, and most of the buildbots. However now there is a failure on : ====================================================================== FAIL: test_rglob_common (test.test_pathlib.PathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_pathlib.py", line 1460, in test_rglob_common "linkB/fileB", "dirA/linkC/fileB"]) File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_pathlib.py", line 1451, in _check self.assertEqual(set(glob), { P(BASE, q) for q in expected }) AssertionError: Items in the second set but not the first: WindowsPath('C:/buildbot.python.org/3.x.kloth-win64/build/build/test_python_1700/@test_1700_tmp/linkB/fileB') WindowsPath('C:/buildbot.python.org/3.x.kloth-win64/build/build/test_python_1700/@test_1700_tmp/dirB/linkD/fileB') WindowsPath('C:/buildbot.python.org/3.x.kloth-win64/build/build/test_python_1700/@test_1700_tmp/dirA/linkC/fileB') ====================================================================== FAIL: test_rglob_common (test.test_pathlib.WindowsPathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_pathlib.py", line 1460, in test_rglob_common "linkB/fileB", "dirA/linkC/fileB"]) File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_pathlib.py", line 1451, in _check self.assertEqual(set(glob), { P(BASE, q) for q in expected }) AssertionError: Items in the second set but not the first: WindowsPath('C:/buildbot.python.org/3.x.kloth-win64/build/build/test_python_1700/@test_1700_tmp/linkB/fileB') WindowsPath('C:/buildbot.python.org/3.x.kloth-win64/build/build/test_python_1700/@test_1700_tmp/dirB/linkD/fileB') WindowsPath('C:/buildbot.python.org/3.x.kloth-win64/build/build/test_python_1700/@test_1700_tmp/dirA/linkC/fileB') I don?t have a Windows setup so I can?t really help much with this one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 16:30:15 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 07 Jan 2016 21:30:15 +0000 Subject: [issue26012] pathlib.Path().rglob() is fooled by symlink loops In-Reply-To: <1451960031.51.0.813695149526.issue26012@psf.upfronthosting.co.za> Message-ID: <1452202215.95.0.398909859965.issue26012@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think I understand the Windows failure. I uncommented some tests that were previously broken due to the symlink loop and/or PermissionError, but one of these has a different expected outcome if symlinks don't work. I've pushed a hopeful fix for that (no Windows box here either, but the buildbots are good for this :-). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 17:08:46 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Jan 2016 22:08:46 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1452204526.0.0.573714905342.issue22995@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm not well known with Cython. Can it replace Python class with extension class on fly? There is a declaration of the NameAssignment class in Cython/Compiler/FlowControl.pxd. We need Cython expert. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 17:11:11 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 07 Jan 2016 22:11:11 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1452204671.36.0.184557186184.issue22995@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: You asked what reductor(4) returns in Python 3.5.0: > /usr/lib/python3.5/copy.py(176)deepcopy() -> rv = reductor(4) (Pdb) reductor(4) (, (,), None, None, None) And this is completely reasonable: (Pdb) p rv (, (,), None, None, None) (Pdb) p rv[0](*rv[1]) NameAssignment(entry=None) I'm doing another debug build of Python to get more information about which extra bit of basicsize is getting added to trigger the TypeError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 17:27:17 2016 From: report at bugs.python.org (=?utf-8?q?Emil_Stenstr=C3=B6m?=) Date: Thu, 07 Jan 2016 22:27:17 +0000 Subject: [issue26045] Improve error message for http.client when posting unicode string Message-ID: <1452205637.36.0.0359255361227.issue26045@psf.upfronthosting.co.za> New submission from Emil Stenstr?m: This issue is in response to this thread on python-ideas: https://mail.python.org/pipermail/python-ideas/2016-January/037678.html Note that Cory did a lot of encoding background work here: https://mail.python.org/pipermail/python-ideas/2016-January/037680.html --- Bug description: When posting an unencoded unicode string directly with python-requests you get the following stacktrace: import requests r = requests.post("http://example.com", data="Celebrate ?") ... File "../lib/python3.4/http/client.py", line 1127, in _send_request body = body.encode('iso-8859-1') UnicodeEncodeError: 'latin-1' codec can't encode characters in position 14-15: ordinal not in range(256) This is because requests uses http.client, and http.client assumes the encoding to be latin-1 if given a unicode string. This is a very common source of bugs for beginners who assume sending in unicode would automatically encode it in utf-8, like in the libraries of many other languages. The simplest fix here is to catch the UnicodeEncodeError and improve the error message to something that points beginners in the right direction. Another option would be to: - Keep encoding in latin-1 first, and if that fails try utf-8 Other possible solutions (that would be backwards incompatible) includes: - Changing the default encoding to utf-8 instead of latin-1 - Detect an unencoded unicode string and fail without encoding it with a descriptive error message --- Just to show that this is a problem that exists in the wild, here are a few examples that all crashes on the same line in http.client (not all going through the requests library: - https://github.com/kennethreitz/requests/issues/2838 - https://github.com/kennethreitz/requests/issues/1822 - http://stackoverflow.com/questions/34618149/post-unicode-string-to-web-service-using-python-requests-library - https://www.reddit.com/r/learnpython/comments/3violw/unicodeencodeerror_when_searching_ebay_with/ - https://github.com/codecov/codecov-python/issues/35 - https://github.com/google/google-api-python-client/issues/145 - https://bugs.launchpad.net/ubuntu/+source/lazr.restfulclient/+bug/1414063 ---------- components: Unicode messages: 257721 nosy: Emil Stenstr?m, ezio.melotti, haypo priority: normal severity: normal status: open title: Improve error message for http.client when posting unicode string type: enhancement versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 17:33:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Jan 2016 22:33:20 +0000 Subject: [issue26042] Consider dropping magic number for more detailed .pyc file name In-Reply-To: <1452189141.27.0.112439951883.issue26042@psf.upfronthosting.co.za> Message-ID: <1452206000.03.0.258676749234.issue26042@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What about zipimport? It doesn't use __pycache__ directories, but just try to read *.pyc file, then *.py file. The launcher on Windows also check magic number (it contains a mapping from magic numbers to Python versions). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 17:40:25 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 07 Jan 2016 22:40:25 +0000 Subject: [issue26042] Consider dropping magic number for more detailed .pyc file name In-Reply-To: <1452189141.27.0.112439951883.issue26042@psf.upfronthosting.co.za> Message-ID: <1452206425.49.0.749269429252.issue26042@psf.upfronthosting.co.za> Brett Cannon added the comment: I figured it was a wash. Closing as "won't fix". As for zipimport, it's busted thanks to the fact that it doesn't work with __pycache__ directories. Yet another reason it needs to be rewritten. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 17:47:18 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 07 Jan 2016 22:47:18 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1452206838.04.0.112789884094.issue22995@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I added some debugging to the if(required) clause. This is interesting: basicsize 16 slotnames 0 basicsize 16 tp_basicsize 80 basicsize 16 tp_basicsize comes in at 16 bytes. tp_dictoffset and tp_weaklistoffset must both be 0, and while slotnames is not Py_None, it must be adding 0 to the basicsize. Since sizeof(PyObject *) can't be 0, it must mean that Py_SIZE(slotnames) is 0 (since they are multiplied). But as you can see tp_basicsize is 80. So essentially PyBaseObject_Type.tp_basicsize is 16 but obj->ob_type->tp_basicsize is 80, and that triggers the traceback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 18:10:14 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 07 Jan 2016 23:10:14 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1452208214.5.0.382042341536.issue22995@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: So yeah, I guess Cython is doing something magical to boost the instance's type's basicsize, but I can't tell what from the Python prompt. It also clearly doesn't affect the un/picklability of the instance, so I think the entire check is probably misguided. It should almost definitely not raise a TypeError. Either disable the entire check, or at most make it a warning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 18:11:09 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 07 Jan 2016 23:11:09 +0000 Subject: [issue26012] pathlib.Path().rglob() is fooled by symlink loops In-Reply-To: <1451960031.51.0.813695149526.issue26012@psf.upfronthosting.co.za> Message-ID: <1452208269.24.0.353864008164.issue26012@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks like that Windows buildbot is now green. Of the stable bots only OpenIndiana is red, and it's unrelated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 18:12:04 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 07 Jan 2016 23:12:04 +0000 Subject: [issue26045] Improve error message for http.client when posting unicode string In-Reply-To: <1452205637.36.0.0359255361227.issue26045@psf.upfronthosting.co.za> Message-ID: <1452208324.74.0.40926148605.issue26045@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 19:08:29 2016 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 08 Jan 2016 00:08:29 +0000 Subject: [issue19251] bitwise ops for bytes of equal length In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za> Message-ID: <1452211709.6.0.802537011741.issue19251@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm very skeptical of this. I expect it would cause quite a few surprises for people who aren't used to bitmask operations on integers, let alone on (byte) strings. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 19:19:13 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 08 Jan 2016 00:19:13 +0000 Subject: [issue19251] bitwise ops for bytes of equal length In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za> Message-ID: <1452212353.45.0.425242575285.issue19251@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Two years ago I suggested this: > Then I would prefer a view, using e.g. the buffer API, but without any copies. ... and of course Numpy already provides such an API: >>> a, b = b"123", bytearray(b"abc") >>> p = np.frombuffer(a, dtype=np.int8) >>> q = np.frombuffer(b, dtype=np.int8) >>> p ^ q array([80, 80, 80], dtype=int8) >>> b[0] = 64 >>> p ^ q array([113, 80, 80], dtype=int8) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 19:19:53 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 08 Jan 2016 00:19:53 +0000 Subject: [issue19251] bitwise ops for bytes of equal length In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za> Message-ID: <1452212393.98.0.0712375085545.issue19251@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Another possibility if you don't mind a copy is to use int.from_bytes(): >>> p = int.from_bytes(a, 'little') >>> q = int.from_bytes(b, 'little') >>> (p ^ q).to_bytes(len(a), 'little') b'qPP' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 19:42:11 2016 From: report at bugs.python.org (Andrew Barnert) Date: Fri, 08 Jan 2016 00:42:11 +0000 Subject: [issue19251] bitwise ops for bytes of equal length In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za> Message-ID: <1452213731.3.0.984520347521.issue19251@psf.upfronthosting.co.za> Andrew Barnert added the comment: For what it's worth, I looked at some old code (a clean re-implementation of a crypto algorithm in Python, used as a unit test for production code in C++) and found this: class BytesBits(bytes): # from a quick test, 1.12us in NumPy, 1.39us in C, 2.55us this way, 46.1us with bytes(genexpr), so we don't need numpy def _bitwise(self, other, op): iself = int.from_bytes(self, 'little') iother = int.from_bytes(other, 'little') b = op(iself, iother) return b.to_bytes(len(self), 'little') def __or__(self, other): return self._bitwise(other, int.__or__) __ror__ = __or__ def __and__(self, other): return self._bitwise(other, int.__and__) __rand__ = __and__ def __xor__(self, other): return self._bitwise(other, int.__xor__) __rxor__ = __xor__ It doesn't do as much error checking as you want, but it was good enough for my purposes. At any rate, the fact that it's trivial to wrap this up yourself (and even more so if you just write functions called band/bor/bxor instead of wrapping them up in a subclass) implies to me that, if it's not used all that often, it doesn't need to be on the builtin types. ---------- nosy: +abarnert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 19:46:20 2016 From: report at bugs.python.org (David Sterry) Date: Fri, 08 Jan 2016 00:46:20 +0000 Subject: [issue26046] Typo Message-ID: <1452213980.49.0.122824663371.issue26046@psf.upfronthosting.co.za> New submission from David Sterry: In https://docs.python.org/2/library/unittest.html#basic-example the word "details" should be "detail". ---------- assignee: docs at python components: Documentation messages: 257731 nosy: David Sterry, docs at python priority: normal severity: normal status: open title: Typo type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 19:46:28 2016 From: report at bugs.python.org (Andrew Barnert) Date: Fri, 08 Jan 2016 00:46:28 +0000 Subject: [issue26019] collections.abc documentation incomplete In-Reply-To: <1452045912.74.0.509683701942.issue26019@psf.upfronthosting.co.za> Message-ID: <1452213988.74.0.543296332085.issue26019@psf.upfronthosting.co.za> Andrew Barnert added the comment: Probably better to wait. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 20:15:39 2016 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 08 Jan 2016 01:15:39 +0000 Subject: [issue26046] Typo in documentation of unittest In-Reply-To: <1452213980.49.0.122824663371.issue26046@psf.upfronthosting.co.za> Message-ID: <1452215739.58.0.351633191108.issue26046@psf.upfronthosting.co.za> Emanuel Barry added the comment: Think you can submit a patch? ---------- keywords: +easy nosy: +ebarry stage: -> needs patch title: Typo -> Typo in documentation of unittest _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 20:53:22 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 08 Jan 2016 01:53:22 +0000 Subject: [issue26045] Improve error message for http.client when posting unicode string In-Reply-To: <1452205637.36.0.0359255361227.issue26045@psf.upfronthosting.co.za> Message-ID: <1452218002.02.0.686677523178.issue26045@psf.upfronthosting.co.za> Martin Panter added the comment: For the record, this is what Requests sent when I passed a Latin-1-encodable string: b'POST / HTTP/1.1\r\n' b'Host: example.com\r\n' b'Content-Length: 11\r\n' b'Connection: keep-alive\r\n' b'Accept: */*\r\n' b'Accept-Encoding: gzip, deflate\r\n' b'User-Agent: python-requests/2.9.1\r\n' b'\r\n' b'Celebrate \xa9' There is no Content-Type header field, nor any indication of the encoding used. This is also how the lower-level HTTPConnection.request() method works. The documentation already mentions that a text string gets encoded with ISO-8859-1 (a.k.a. Latin-1): . How do you propose to improve the error message? Encoding with either Latin-1 or UTF-8 depending on the characters sounds like a terrible idea. We may as well send the request without any body and pretend everything is okay. I don?t understand the point of changing to UTF-8 either. If you actually want UTF-8 encoded text, why not explicitly encode it yourself? Failing for any unencoded text string would be a serious backwards compatibility problem. It would break the POST example using urlencode() at for instance. IMO the Latin-1 encoding feature is a bad API design, maybe based on a misunderstanding of HTTP. Perhaps it would be more reasonable to deprecate the automatic Latin-1 encoding, and only allow ASCII characters in a text string. That would still cater for the urlencode() scenario in the POST example. Of the links you posted, they seem to be different problems with separate solutions: Requests bug 2838: Perhaps the user was trying to send URL-encoded form data. If so, textual fields should be UTF-8 encoded and then percent-encoded, resulting in only ASCII codes in the ?data? argument. Python has urllib.parse.urlencode() which does this. Requests bug 1822: It sounds like the user or a library intended to send UTF-8, so they should encode it themselves. Stack Overflow: Custom web service needed fixing, and the user had to encode as UTF-8. This is a custom agreement between the client and server, it is not up to Python. Ebay: I?m not familiar with any Ebay API and it is not clear from the post, but I suspect the user wasn?t encoding their data properly. Maybe similar to the first case. For the rest it is not clear what the problem or solution was. Some of them sound like they were somehow sending text when they really wanted to send arbitrary bytes, in which case UTF-8 is not going to help. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 21:22:45 2016 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 08 Jan 2016 02:22:45 +0000 Subject: [issue26045] Improve error message for http.client when posting unicode string In-Reply-To: <1452205637.36.0.0359255361227.issue26045@psf.upfronthosting.co.za> Message-ID: <1452219765.79.0.31808943056.issue26045@psf.upfronthosting.co.za> Guido van Rossum added the comment: Any solution that encodes Unicode in a way that works for some characters but fails for others has the same problem that Unicode had in Python 3. Unfortunately we're stuck with such a solution (Latin-1) and for backwards compatibility reasons we can't change it. If we were to deprecate it, we should warn for *any* data given as a Unicode string, even if it's plain ASCII (even if it's an empty string :-). But even if we don't deprecate it, we can still change the text of the error message (but not the type of the exception used) to be more clear. Can we please start drafting a suitable error message here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 22:16:10 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 08 Jan 2016 03:16:10 +0000 Subject: [issue26045] Improve error message for http.client when posting unicode string In-Reply-To: <1452205637.36.0.0359255361227.issue26045@psf.upfronthosting.co.za> Message-ID: <1452222970.74.0.537500483634.issue26045@psf.upfronthosting.co.za> Martin Panter added the comment: After reading through the linked thread, there are a few error message proposals: Guido: "use data.encode('utf-8') if you want the data to be encoded in UTF-8". (Then of course the server might not like it.) Andrew Barnert: A UnicodeEncodeError (or subclass of it?) with text like "HTTP body without encoding defaults to 'latin-1', which can't encode character '\u5555' in position 30: ordinal not in range(256)") Paul Moore: Encode as ASCII and catch UnicodeEncodeError and re-raise as a TypeError "Unicode string supplied without an explicit encoding". Emil, do you think any of these would help? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 23:35:17 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 08 Jan 2016 04:35:17 +0000 Subject: [issue19919] SSL: test_connect_ex_error fails with EWOULDBLOCK In-Reply-To: <1386434917.9.0.425282577519.issue19919@psf.upfronthosting.co.za> Message-ID: <1452227717.97.0.903691470212.issue19919@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 00:39:16 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 Jan 2016 05:39:16 +0000 Subject: [issue25672] set SSL_MODE_RELEASE_BUFFERS In-Reply-To: <1447957027.04.0.0951767236546.issue25672@psf.upfronthosting.co.za> Message-ID: <20160108053857.53702.28619@psf.io> Roundup Robot added the comment: New changeset b5b0394ed20b by Benjamin Peterson in branch 'default': merge 3.5 (closes #25672) https://hg.python.org/cpython/rev/b5b0394ed20b ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 00:57:41 2016 From: report at bugs.python.org (Upendra Kumar) Date: Fri, 08 Jan 2016 05:57:41 +0000 Subject: [issue26046] Typo in documentation of unittest In-Reply-To: <1452213980.49.0.122824663371.issue26046@psf.upfronthosting.co.za> Message-ID: <1452232661.65.0.168872217685.issue26046@psf.upfronthosting.co.za> Upendra Kumar added the comment: I have submitted the patch for this small typo. ---------- keywords: +patch nosy: +upendra-k14 Added file: http://bugs.python.org/file41528/typo.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 01:02:30 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 Jan 2016 06:02:30 +0000 Subject: [issue26046] Typo in documentation of unittest In-Reply-To: <1452213980.49.0.122824663371.issue26046@psf.upfronthosting.co.za> Message-ID: <20160108060223.69623.13132@psf.io> Roundup Robot added the comment: New changeset ff3655d6c257 by Benjamin Peterson in branch '2.7': fix typo in unittest docs (closes #26046) https://hg.python.org/cpython/rev/ff3655d6c257 New changeset f24d22b44099 by Benjamin Peterson in branch '3.4': fix typo in unittest docs (closes #26046) https://hg.python.org/cpython/rev/f24d22b44099 New changeset 21567b4493c6 by Benjamin Peterson in branch '3.5': merge 3.4 (#26046) https://hg.python.org/cpython/rev/21567b4493c6 New changeset eeec6c5b5b79 by Benjamin Peterson in branch 'default': merge 3.5 (#26046) https://hg.python.org/cpython/rev/eeec6c5b5b79 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 02:47:30 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 08 Jan 2016 07:47:30 +0000 Subject: [issue26017] Update https://docs.python.org/3/installing/index.html to always quote arguments In-Reply-To: <1452015796.73.0.274069830205.issue26017@psf.upfronthosting.co.za> Message-ID: <1452239250.69.0.954169369909.issue26017@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Here is the patch with the changes suggested by Brett. Having created this patch, I had second thoughts on this change. Folks who use pip often, usually use it without any quotes, like `pip install requests`, `pip install CherryPy`. Pinned down versions are most often required by projects and they mention it in the requirements.txt in an unquoted manner Ref: https://pip.readthedocs.org/en/1.1/requirements.html It works fine as it is not the shell which is parsing this file. Since ">" thing parsed by shell on the command line is a special thing, why not address that scenario with more clarification, instead of quoting all the examples, which seem contrary to the common usage patterns? ---------- keywords: +patch nosy: +orsenthil Added file: http://bugs.python.org/file41529/Issue26017.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 02:57:19 2016 From: report at bugs.python.org (Vitaminus Maximus) Date: Fri, 08 Jan 2016 07:57:19 +0000 Subject: [issue26043] ON DELETE CASCADE does not work when using sqlite3 library In-Reply-To: <1452193029.87.0.593726838819.issue26043@psf.upfronthosting.co.za> Message-ID: <1452239839.92.0.587989483167.issue26043@psf.upfronthosting.co.za> Changes by Vitaminus Maximus : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 03:12:53 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 08 Jan 2016 08:12:53 +0000 Subject: [issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title In-Reply-To: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za> Message-ID: <1452240773.96.0.738629767639.issue23675@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Here is the patch with the suggested wording. ---------- keywords: +patch nosy: +orsenthil Added file: http://bugs.python.org/file41530/Issue23675.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 03:13:08 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 08 Jan 2016 08:13:08 +0000 Subject: [issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title In-Reply-To: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za> Message-ID: <1452240788.0.0.637853738111.issue23675@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 04:03:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 Jan 2016 09:03:24 +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: <20160108090319.30362.95000@psf.io> Roundup Robot added the comment: New changeset 7fe960f1a101 by Senthil Kumaran in branch '3.5': Issue20969 - Set the Epub Author and Epub Publisher in Python docs. https://hg.python.org/cpython/rev/7fe960f1a101 New changeset 4daffae06f64 by Senthil Kumaran in branch 'default': merge from 3.5 https://hg.python.org/cpython/rev/4daffae06f64 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 04:06:05 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 Jan 2016 09:06:05 +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: <20160108090602.8281.67688@psf.io> Roundup Robot added the comment: New changeset 6b72b4b79aef by Senthil Kumaran in branch '2.7': Issue20969 - Set the Epub Author and Epub Publisher in Python docs. https://hg.python.org/cpython/rev/6b72b4b79aef ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 04:06:58 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 08 Jan 2016 09:06:58 +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: <1452244018.36.0.666368540387.issue20969@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Fixed in all branches for which documentation will be published / updated. ---------- assignee: docs at python -> orsenthil nosy: +orsenthil resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 04:18:18 2016 From: report at bugs.python.org (Christof Hanke) Date: Fri, 08 Jan 2016 09:18:18 +0000 Subject: [issue26047] argparse.ArgumentError documentation wrong Message-ID: <1452244698.45.0.106083471244.issue26047@psf.upfronthosting.co.za> New submission from Christof Hanke: On https://docs.python.org/2/library/argparse.html (and on those of the 3.6-Version) it says at the bottom: """ ArgumentParser.error(message) This method prints a usage message including the message to the standard error and terminates the program with a status code of 2. """ In fact, the returned staus code is 1. ---------- assignee: docs at python components: Documentation messages: 257745 nosy: Christof Hanke, docs at python priority: normal severity: normal status: open title: argparse.ArgumentError documentation wrong type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 04:22:31 2016 From: report at bugs.python.org (SilentGhost) Date: Fri, 08 Jan 2016 09:22:31 +0000 Subject: [issue26047] argparse.ArgumentError documentation wrong In-Reply-To: <1452244698.45.0.106083471244.issue26047@psf.upfronthosting.co.za> Message-ID: <1452244951.54.0.780429322584.issue26047@psf.upfronthosting.co.za> SilentGhost added the comment: Christof, you'd have to demonstrate the issue in more than just words. The returned status code is hard-coded to be 2 in the error method and it does end up being 2 when i run, could you post some output that led you to believe that it is 1? ---------- nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 04:40:41 2016 From: report at bugs.python.org (Erik Quaeghebeur) Date: Fri, 08 Jan 2016 09:40:41 +0000 Subject: [issue11245] Implementation of IMAP IDLE in imaplib? In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za> Message-ID: <1452246041.4.0.139541221742.issue11245@psf.upfronthosting.co.za> Changes by Erik Quaeghebeur : ---------- nosy: +equaeghe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 04:58:06 2016 From: report at bugs.python.org (Upendra Kumar) Date: Fri, 08 Jan 2016 09:58:06 +0000 Subject: [issue26035] traceback.print_tb() takes `tb`, not `traceback` as a keyword argument In-Reply-To: <1452142055.04.0.968906484949.issue26035@psf.upfronthosting.co.za> Message-ID: <1452247086.49.0.163978655484.issue26035@psf.upfronthosting.co.za> Upendra Kumar added the comment: I am submitting a patch for this documentation issue. I have changed the function parameters name 'traceback' to 'tb'. Because of this I have also introduced changes in the text of the documentation to maintain coherency. I found some more inconsistent function parameter's name: I have changed them : 'type' to 'etype' in functions print_exception, format_exception_only, format_exception 'list' to 'extracted_list' in function format_list ' ---------- keywords: +patch nosy: +upendra-k14 Added file: http://bugs.python.org/file41531/func_args_name.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 05:24:39 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 08 Jan 2016 10:24:39 +0000 Subject: [issue19251] bitwise ops for bytes of equal length In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za> Message-ID: <1452248679.42.0.0478384314188.issue19251@psf.upfronthosting.co.za> STINNER Victor added the comment: > I'm very skeptical of this. I expect it would cause quite a few surprises for people who aren't used to bitmask operations on integers, let alone on (byte) strings. Maybe it makes more sense to implement such operation on the array.array type? But only for integer types (ex: not for 'd', float)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 05:42:44 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 08 Jan 2016 10:42:44 +0000 Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL certificate In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za> Message-ID: <1452249764.97.0.122877418249.issue25940@psf.upfronthosting.co.za> Martin Panter added the comment: In python-dev I offered to make a patch to switch to https://self-signed.pythontest.net. Here is my patch so far. There is one outstanding problem though: test_get_ca_certs_capath() fails. I think it is because the self-signed certificate does not have a ?CA basic constraints? flag set, and SSLContext.get_ca_certs() no longer lists the certificate. Maybe someone else can help. I suspect this would need to be fixed on the server side (or find another server with a certificate signed with this flag set?), but I could easily be wrong :). ---------- Added file: http://bugs.python.org/file41532/pythontest.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 06:49:23 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 08 Jan 2016 11:49:23 +0000 Subject: [issue26037] Crash when reading sys.stdin.buffer in a daemon thread In-Reply-To: <1452170624.64.0.0901256170606.issue26037@psf.upfronthosting.co.za> Message-ID: <1452253763.24.0.197054863847.issue26037@psf.upfronthosting.co.za> ???? ????????? added the comment: 16.2.4.3. Multi-threading FileIO objects are thread-safe to the extent that the operating system calls (such as read(2) under Unix) they wrap are thread-safe too. Binary buffered objects (instances of BufferedReader, BufferedWriter, BufferedRandom and BufferedRWPair) protect their internal structures using a lock; it is therefore safe to call them from multiple threads at once. >>>> TextIOWrapper objects are not thread-safe. <<<< Maybe problem here? ---------- nosy: +mmarkk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 06:52:34 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 08 Jan 2016 11:52:34 +0000 Subject: [issue26037] Crash when reading sys.stdin.buffer in a daemon thread In-Reply-To: <1452170624.64.0.0901256170606.issue26037@psf.upfronthosting.co.za> Message-ID: <1452253954.97.0.526634334648.issue26037@psf.upfronthosting.co.za> ???? ????????? added the comment: sys.stdin sys.stdout sys.stderr ... These streams are regular text files.... ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 06:58:49 2016 From: report at bugs.python.org (Divyang Patel) Date: Fri, 08 Jan 2016 11:58:49 +0000 Subject: [issue26048] New user in community Message-ID: <1452254329.64.0.275249688938.issue26048@psf.upfronthosting.co.za> New submission from Divyang Patel: Greetings to all! Hi, please Guide me to understand how to contributing python ?? ---------- messages: 257752 nosy: devtechnofreak priority: normal severity: normal status: open title: New user in community type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 07:12:56 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 08 Jan 2016 12:12:56 +0000 Subject: [issue26048] New user in community In-Reply-To: <1452254329.64.0.275249688938.issue26048@psf.upfronthosting.co.za> Message-ID: <1452255176.85.0.649926570627.issue26048@psf.upfronthosting.co.za> Ezio Melotti added the comment: Please check the devguide at https://docs.python.org/devguide/ and the python-mentorship mailing list. ---------- nosy: +ezio.melotti resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 07:15:14 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 08 Jan 2016 12:15:14 +0000 Subject: [issue19251] bitwise ops for bytes of equal length In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za> Message-ID: <1452255314.4.0.176041387593.issue19251@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW a long time ago I wanted fast XORing of 512-byte ?sectors? of Rar files. Initially I think I used array.array with the largest word size available, or numpy if available. Later when I learnt more Python I discovered the int.from_bytes() trick, and used int(hexlify(...), 16) in Python 2. So I guess the array module was a relatively obvious place to look, and the long integer trick was unexpected (I?d never programmed with unlimited size integers before). Serhiy?s bit array idea also seems interesting. I bet somebody has already written a package. Maybe it could also be useful for things like Huffman encoding, where you string various bit strings together into a sequence of bytes. But I do wonder if all these things are too specialized for Python?s standard library. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 07:57:09 2016 From: report at bugs.python.org (Christian Heimes) Date: Fri, 08 Jan 2016 12:57:09 +0000 Subject: [issue19251] bitwise ops for bytes of equal length In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za> Message-ID: <1452257829.01.0.626971219664.issue19251@psf.upfronthosting.co.za> Christian Heimes added the comment: Serhiy?s bitarray idea has another benefit. Bit masking is only haft of the story. Since Python's int type has no length information, it not possible to handle shifting with overflow and rotation. A bit array can provide bit shifting ops like rshift, lshift, rotr and rotl. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 08:36:38 2016 From: report at bugs.python.org (Sergi Almacellas Abellana) Date: Fri, 08 Jan 2016 13:36:38 +0000 Subject: [issue26049] Poor performance when reading large xmlrpc data Message-ID: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za> New submission from Sergi Almacellas Abellana: By default, python xmlrpclib parser reads data by chunks of 1024 bytes [1], which leads to a lot of data concatenations when reading large data, which is very slow in python. Increasing the chuck size from 1024 bytes to a higher value makes improve in performance. On the same machine, we have tested with 20MB of data and we've got the following results: Chucks of 1024: 1min 48.933491sec Chucks of 10 * 1024 * 1024: 0.245282sec We have chosen 10 * 1024 * 1024, as it is the same value used in issue792570 We have done our tests on python2.7, but same code exists for default branch [2] (and 3.x branches also [3][4][5][6]), so I belive all the versions are affected. I can work on a patch if you think this change is acceptable. IMHO it's logical to allow the developer to customize the chunk size instead of using a hard coded one. [1] https://hg.python.org/cpython/file/2.7/Lib/xmlrpclib.py#l1479 [2] https://hg.python.org/cpython/file/default/Lib/xmlrpc/client.py#l1310 [3] https://hg.python.org/cpython/file/3.5/Lib/xmlrpc/client.py#l1310 [4] https://hg.python.org/cpython/file/3.4/Lib/xmlrpc/client.py#l1324 [5] https://hg.python.org/cpython/file/3.3/Lib/xmlrpc/client.py#l1316 [6] https://hg.python.org/cpython/file/3.2/Lib/xmlrpc/client.py#l1301 ---------- components: XML messages: 257756 nosy: pokoli priority: normal severity: normal status: open title: Poor performance when reading large xmlrpc data _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 08:52:28 2016 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Fri, 08 Jan 2016 13:52:28 +0000 Subject: [issue26049] Poor performance when reading large xmlrpc data In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za> Message-ID: <1452261148.12.0.302722600126.issue26049@psf.upfronthosting.co.za> C?dric Krier added the comment: I don't think it is necessary to allow to customize the chunk size. Indeed Python should provide a good value by default that works for all platforms. ---------- nosy: +ced type: -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 08:53:03 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 08 Jan 2016 13:53:03 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1452261183.48.0.717346959967.issue25596@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Adding a doc patch. ---------- Added file: http://bugs.python.org/file41533/glob_scandir_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 09:32:35 2016 From: report at bugs.python.org (Sergi Almacellas Abellana) Date: Fri, 08 Jan 2016 14:32:35 +0000 Subject: [issue26049] Poor performance when reading large xmlrpc data In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za> Message-ID: <1452263555.23.0.847689918483.issue26049@psf.upfronthosting.co.za> Sergi Almacellas Abellana added the comment: I attach a patch to fix on default series ---------- keywords: +patch Added file: http://bugs.python.org/file41534/default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 09:32:54 2016 From: report at bugs.python.org (Sergi Almacellas Abellana) Date: Fri, 08 Jan 2016 14:32:54 +0000 Subject: [issue26049] Poor performance when reading large xmlrpc data In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za> Message-ID: <1452263574.7.0.743927980487.issue26049@psf.upfronthosting.co.za> Sergi Almacellas Abellana added the comment: And Also another patch for 2.7 branches ---------- Added file: http://bugs.python.org/file41535/python27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 09:35:17 2016 From: report at bugs.python.org (Andrew Barnert) Date: Fri, 08 Jan 2016 14:35:17 +0000 Subject: [issue19251] bitwise ops for bytes of equal length In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za> Message-ID: <1452263717.06.0.767405583557.issue19251@psf.upfronthosting.co.za> Andrew Barnert added the comment: There are a number of existing libraries on PyPI for bit arrays and bit sets. There are a lot more API choices than you'd think of in advance, and between them they explore most of the useful space. And I don't think any of them need to be in the stdlib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 09:53:31 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 08 Jan 2016 14:53:31 +0000 Subject: [issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title In-Reply-To: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za> Message-ID: <1452264811.73.0.298102603345.issue23675@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 10:12:46 2016 From: report at bugs.python.org (Vincent Legoll) Date: Fri, 08 Jan 2016 15:12:46 +0000 Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL certificate In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za> Message-ID: <1452265966.56.0.548607328775.issue25940@psf.upfronthosting.co.za> Vincent Legoll added the comment: Maybe if the server change is not approved you can still push the part of the patch that un-hardwire that server name everywhere... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 11:04:13 2016 From: report at bugs.python.org (=?utf-8?q?Emil_Stenstr=C3=B6m?=) Date: Fri, 08 Jan 2016 16:04:13 +0000 Subject: [issue26045] Improve error message for http.client when posting unicode string In-Reply-To: <1452205637.36.0.0359255361227.issue26045@psf.upfronthosting.co.za> Message-ID: <1452269053.12.0.536534452904.issue26045@psf.upfronthosting.co.za> Emil Stenstr?m added the comment: I think changing the error message is enough for the short term, and deprecation of automatic encoding is the correct way in the long term. A text that mention "utf-8" which will likely be the correct solution definitely gets my vote, so Guidos suggestion sounds good to me: UnicodeEncodeError("Use data.encode('utf-8') if you want the data to be encoded in UTF-8") Andrew's and Pauls suggestions doesn't point to a solution to the problem, which I think is a great think for something this basic. Also, the error message only gets shown when latin-1 fails, so we can't use text that speaks about "no encoding" in general. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 11:05:39 2016 From: report at bugs.python.org (Sergi Almacellas Abellana) Date: Fri, 08 Jan 2016 16:05:39 +0000 Subject: [issue26049] Poor performance when reading large xmlrpc data In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za> Message-ID: <1452269139.91.0.821344064621.issue26049@psf.upfronthosting.co.za> Sergi Almacellas Abellana added the comment: I added a new patch which fixed comments ---------- Added file: http://bugs.python.org/file41536/default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 11:05:49 2016 From: report at bugs.python.org (Sergi Almacellas Abellana) Date: Fri, 08 Jan 2016 16:05:49 +0000 Subject: [issue26049] Poor performance when reading large xmlrpc data In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za> Message-ID: <1452269149.64.0.655329925173.issue26049@psf.upfronthosting.co.za> Changes by Sergi Almacellas Abellana : Removed file: http://bugs.python.org/file41534/default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 11:39:06 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 08 Jan 2016 16:39:06 +0000 Subject: [issue19251] bitwise ops for bytes of equal length In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za> Message-ID: <1452271146.86.0.152952152585.issue19251@psf.upfronthosting.co.za> ???? ????????? added the comment: Just mention it here :) https://github.com/KeepSafe/aiohttp/issues/686 ---------- nosy: +mmarkk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 11:43:24 2016 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 08 Jan 2016 16:43:24 +0000 Subject: [issue26045] Improve error message for http.client when posting unicode string In-Reply-To: <1452205637.36.0.0359255361227.issue26045@psf.upfronthosting.co.za> Message-ID: <1452271404.85.0.42455937199.issue26045@psf.upfronthosting.co.za> Guido van Rossum added the comment: Here's a patch. I noticed there are lots of other places where a similar encoding() call exists -- I wrapped them all using a helper function. Please review carefully. ---------- keywords: +patch Added file: http://bugs.python.org/file41537/utfpatch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 11:45:10 2016 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 08 Jan 2016 16:45:10 +0000 Subject: [issue26045] Improve error message for http.client when posting unicode string In-Reply-To: <1452205637.36.0.0359255361227.issue26045@psf.upfronthosting.co.za> Message-ID: <1452271510.56.0.590174120995.issue26045@psf.upfronthosting.co.za> Guido van Rossum added the comment: BTW the error and traceback will look something like this: Traceback (most recent call last): File "", line 1, in File "/Users/guido/src/cpython/Lib/http/client.py", line 1138, in _send_request self.putheader(hdr, value) File "/Users/guido/src/cpython/Lib/http/client.py", line 1062, in putheader header = _encode(header, 'ascii', 'header') File "/Users/guido/src/cpython/Lib/http/client.py", line 161, in _encode (name.title(), data[err.start:err.end], name)) from None UnicodeEncodeError: 'ascii' codec can't encode character '\u1234' in position 3: Header ('?') is not valid Latin-1. Use header.encode('utf-8') if you want to send it encoded in UTF-8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 12:16:46 2016 From: report at bugs.python.org (Kartikaya Gupta) Date: Fri, 08 Jan 2016 17:16:46 +0000 Subject: [issue24712] Docs page's sidebar vibrates on mouse wheel scroll on Chrome. In-Reply-To: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za> Message-ID: <1452273406.9.0.786226593727.issue24712@psf.upfronthosting.co.za> Kartikaya Gupta added the comment: Please note that this issue will affect Firefox 46 and up as well; we have enabled asynchronous scrolling as of Firefox 46. Bugzilla bug for this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=997269 Announcement for asynchronous scrolling: https://groups.google.com/d/msg/mozilla.dev.platform/X2BwGm348jI/Tl26C_1JBAAJ Also, in Firefox 46 and up, if you open the browser's web console and scroll these documentation pages, you should see a warning about scroll-linked effects with pointers to additional info on why this is happening. ---------- nosy: +kats _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 12:18:44 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 08 Jan 2016 17:18:44 +0000 Subject: [issue24712] Docs page's sidebar vibrates on mouse wheel scroll on Chrome. In-Reply-To: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za> Message-ID: <1452273524.49.0.508754123495.issue24712@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 12:30:49 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 08 Jan 2016 17:30:49 +0000 Subject: [issue26041] Update deprecation messages of platform.dist() and platform.linux_distribution() In-Reply-To: <1452187100.03.0.384540652472.issue26041@psf.upfronthosting.co.za> Message-ID: <1452274249.65.0.882924585332.issue26041@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 12:34:27 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 08 Jan 2016 17:34:27 +0000 Subject: [issue26030] Use PEP8 in documentation examples In-Reply-To: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> Message-ID: <1452274467.77.0.359603623961.issue26030@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 12:35:36 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 08 Jan 2016 17:35:36 +0000 Subject: [issue26025] Document pathlib.Path.__truediv__() In-Reply-To: <1452101974.47.0.473485918535.issue26025@psf.upfronthosting.co.za> Message-ID: <1452274536.53.0.0436390215448.issue26025@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti type: -> enhancement versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 12:41:36 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 08 Jan 2016 17:41:36 +0000 Subject: [issue26017] Update https://docs.python.org/3/installing/index.html to always quote arguments In-Reply-To: <1452015796.73.0.274069830205.issue26017@psf.upfronthosting.co.za> Message-ID: <1452274896.35.0.624453005773.issue26017@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think it's enough to add a note that says that if the argument contains > (and possibly other) special characters, then it needs to be quoted. Examples that use > should also be quoted, but not the others one. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 12:46:11 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 08 Jan 2016 17:46:11 +0000 Subject: [issue26009] HTMLParser lacking a few features to reconstruct input exactly In-Reply-To: <1451928938.48.0.712719588041.issue26009@psf.upfronthosting.co.za> Message-ID: <1452275171.65.0.596309124997.issue26009@psf.upfronthosting.co.za> Ezio Melotti added the comment: What is your use case? Also note that new features can only go on 3.6. ---------- nosy: +ezio.melotti versions: +Python 3.6 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 12:48:34 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 08 Jan 2016 17:48:34 +0000 Subject: [issue26001] Tutorial: write() does not expect string in binary mode In-Reply-To: <1451829375.45.0.0188699168911.issue26001@psf.upfronthosting.co.za> Message-ID: <1452275314.41.0.18809008215.issue26001@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> patch review type: -> enhancement versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 12:50:19 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 08 Jan 2016 17:50:19 +0000 Subject: [issue25991] readline example eventually consumes all memory In-Reply-To: <1451708933.83.0.797303528676.issue25991@psf.upfronthosting.co.za> Message-ID: <1452275419.3.0.893984153181.issue25991@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti stage: -> needs patch type: resource usage -> enhancement versions: +Python 2.7, Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 12:54:44 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Jan 2016 17:54:44 +0000 Subject: [issue25992] test_gdb fails on OSX In-Reply-To: <1451713806.34.0.803842118103.issue25992@psf.upfronthosting.co.za> Message-ID: <1452275684.05.0.681977407596.issue25992@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: test_gdb fails -> test_gdb fails on OSX _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 13:11:10 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Jan 2016 18:11:10 +0000 Subject: [issue26001] Tutorial: write() does not expect string in binary mode In-Reply-To: <1451829375.45.0.0188699168911.issue26001@psf.upfronthosting.co.za> Message-ID: <1452276670.45.0.840672819312.issue26001@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Lines should be kept to about 80 chars. Both chunks needs a newline added. I think it okay to create short lines rather than re-wrapping the whole paragraph. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 13:17:54 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Jan 2016 18:17:54 +0000 Subject: [issue26004] pip install lifetimes - throwing error and unable to install packages In-Reply-To: <1451897106.72.0.251427221401.issue26004@psf.upfronthosting.co.za> Message-ID: <1452277074.94.0.117445058864.issue26004@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Debashish: questions on using pip should be directed to python-list, also accessible as newsgroup gmane.comp.python.general at news.gmane.org. pip is otherwise maintained separately from CPython and has its own bug-reporting system. ---------- nosy: +terry.reedy resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 13:24:00 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Jan 2016 18:24:00 +0000 Subject: [issue26007] Support embedding the standard library in an executable In-Reply-To: <1451923993.52.0.708853061063.issue26007@psf.upfronthosting.co.za> Message-ID: <1452277440.27.0.211856616791.issue26007@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> test needed title: Request for Support for Embedding the Standard Library in an Executable -> Support embedding the standard library in an executable versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 13:26:03 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Jan 2016 18:26:03 +0000 Subject: [issue26009] HTMLParser lacking a few features to reconstruct input exactly In-Reply-To: <1451928938.48.0.712719588041.issue26009@psf.upfronthosting.co.za> Message-ID: <1452277563.7.0.341085221884.issue26009@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> test needed type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 13:35:13 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Jan 2016 18:35:13 +0000 Subject: [issue26024] Non-ascii Windows locale names In-Reply-To: <1452090490.23.0.240691672935.issue26024@psf.upfronthosting.co.za> Message-ID: <1452278113.38.0.826878553598.issue26024@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 13:40:30 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Jan 2016 18:40:30 +0000 Subject: [issue26036] Unnecessary arguments on smtpd.SMTPServer In-Reply-To: <1452168983.71.0.914590889995.issue26036@psf.upfronthosting.co.za> Message-ID: <1452278430.02.0.906167710482.issue26036@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 13:48:00 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Jan 2016 18:48:00 +0000 Subject: [issue26045] Improve error message for http.client when posting unicode string In-Reply-To: <1452205637.36.0.0359255361227.issue26045@psf.upfronthosting.co.za> Message-ID: <1452278880.55.0.0927177486563.issue26045@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: -Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 13:58:18 2016 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 08 Jan 2016 18:58:18 +0000 Subject: [issue26045] Improve error message for http.client when posting unicode string In-Reply-To: <1452205637.36.0.0359255361227.issue26045@psf.upfronthosting.co.za> Message-ID: <1452279498.84.0.60306483758.issue26045@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think this would be okay for 3.5.2 as well. ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 14:14:55 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Jan 2016 19:14:55 +0000 Subject: [issue26049] Poor performance when reading large xmlrpc data In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za> Message-ID: <1452280495.93.0.0905029336217.issue26049@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I believe performance enhancements are, by default, limited to 'default', but this one might be a good candidate for backport. ---------- nosy: +loewis, terry.reedy versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 15:11:17 2016 From: report at bugs.python.org (Chris Hogan) Date: Fri, 08 Jan 2016 20:11:17 +0000 Subject: [issue25589] test_ascii_formatd fails on Mac when built with Intel compiler In-Reply-To: <1447093853.5.0.154282338345.issue25589@psf.upfronthosting.co.za> Message-ID: <1452283877.34.0.519221958092.issue25589@psf.upfronthosting.co.za> Chris Hogan added the comment: The Intel compiler team is looking into this issue. I'll keep everyone updated here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 15:37:56 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 08 Jan 2016 20:37:56 +0000 Subject: [issue26050] Add new StreamReader.readuntil() method Message-ID: <1452285476.14.0.419432816204.issue26050@psf.upfronthosting.co.za> New submission from ???? ?????????: See code discussion here: https://github.com/python/asyncio/pull/297 ---------- components: asyncio messages: 257776 nosy: gvanrossum, haypo, mmarkk, yselivanov priority: normal severity: normal status: open title: Add new StreamReader.readuntil() method type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 15:46:06 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 08 Jan 2016 20:46:06 +0000 Subject: [issue26037] Crash when reading sys.stdin.buffer in a daemon thread In-Reply-To: <1452170624.64.0.0901256170606.issue26037@psf.upfronthosting.co.za> Message-ID: <1452285966.12.0.589744802911.issue26037@psf.upfronthosting.co.za> Martin Panter added the comment: But sys.stdin.buffer would be a BufferedReader ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 16:03:51 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 08 Jan 2016 21:03:51 +0000 Subject: [issue25991] readline example eventually consumes all memory In-Reply-To: <1451708933.83.0.797303528676.issue25991@psf.upfronthosting.co.za> Message-ID: <1452287031.83.0.377386654602.issue25991@psf.upfronthosting.co.za> Martin Panter added the comment: What version of Readline are you using? Is it perhaps Editline (libedit)? When I experimented with Editline on Linux once, I think I saw the history file doubling in size every time I ran Python. Maybe that is what you are seeing. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 16:12:49 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 08 Jan 2016 21:12:49 +0000 Subject: [issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title In-Reply-To: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za> Message-ID: <1452287569.08.0.893780322147.issue23675@psf.upfronthosting.co.za> Martin Panter added the comment: The wording looks good in spirit. I just have a couple nits to pick with the grammar: * Why change from ?See? to ?Refer?? ?Refer to? would work better I think; but ?See? was fine too IMO. * I think it is better without ?document?. Just ?See / Refer to <2.3 MRO> for details?. * I would insert ?the? in ?since the 2.3 release?. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 17:33:18 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 Jan 2016 22:33:18 +0000 Subject: [issue25802] Finish deprecating load_module() In-Reply-To: <1449274063.93.0.451300544059.issue25802@psf.upfronthosting.co.za> Message-ID: <20160108223314.30350.16216@psf.io> Roundup Robot added the comment: New changeset d733b6275e17 by Brett Cannon in branch 'default': Issue #25802: Add an examples section to importlib. https://hg.python.org/cpython/rev/d733b6275e17 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 17:33:48 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 08 Jan 2016 22:33:48 +0000 Subject: [issue25802] Finish deprecating load_module() In-Reply-To: <1449274063.93.0.451300544059.issue25802@psf.upfronthosting.co.za> Message-ID: <1452292428.35.0.936097522014.issue25802@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the review, Berker! I managed to figure out how to get the Examples links to work so that made it into the final version. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 18:21:49 2016 From: report at bugs.python.org (Antony Lee) Date: Fri, 08 Jan 2016 23:21:49 +0000 Subject: [issue26051] Non-data descriptors in pydoc Message-ID: <1452295309.05.0.476253695659.issue26051@psf.upfronthosting.co.za> New submission from Antony Lee: Consider the following minimal example: class readonlyprop: __init__ = lambda self, func: None __get__ = lambda self, inst, cls=None: None class C: def bar(self): pass @readonlyprop def foo(self): pass def quux(self): pass the output of `pydoc modname.C` is <... cropped ...> modname.C = class C(builtins.object) | Methods defined here: | | bar(self) | | foo = None | quux(self) | | ---------------------------------------------------------------------- | Data descriptors defined here: <... cropped ...> It would be nice if 1. a newline was added after `foo = None`, and 2. foo was *also* marked as being a non-data-descriptor of class readonlyprop (basically what you'd get without invoking the __get__). ---------- assignee: docs at python components: Documentation messages: 257782 nosy: Antony.Lee, docs at python priority: normal severity: normal status: open title: Non-data descriptors in pydoc versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 18:24:46 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 08 Jan 2016 23:24:46 +0000 Subject: [issue26025] Document pathlib.Path.__truediv__() In-Reply-To: <1452101974.47.0.473485918535.issue26025@psf.upfronthosting.co.za> Message-ID: <1452295486.05.0.58271342022.issue26025@psf.upfronthosting.co.za> Brett Cannon added the comment: Turns out it is if you read the PurePath docs: https://docs.python.org/3/library/pathlib.html#operators ---------- resolution: -> not a bug stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 18:30:08 2016 From: report at bugs.python.org (Antony Lee) Date: Fri, 08 Jan 2016 23:30:08 +0000 Subject: [issue26052] pydoc for __init__ with not docstring Message-ID: <1452295807.98.0.613500169742.issue26052@psf.upfronthosting.co.za> New submission from Antony Lee: For a class whose __init__ has no docstring, e.g. class C: def __init__(self, arg): pass pydoc outputs <... cropped ...> class C(builtins.object) | Methods defined here: | | __init__(self, arg) | Initialize self. See help(type(self)) for accurate signature. <... cropped ...> The last part "See help(type(self)) for accurate signature." could arguably be cropped as the correct signature is already displayed (I see that this is the docstring of object.__init__, it's not clear to me why it needs this sentence.). ---------- assignee: docs at python components: Documentation messages: 257784 nosy: Antony.Lee, docs at python priority: normal severity: normal status: open title: pydoc for __init__ with not docstring versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 18:43:41 2016 From: report at bugs.python.org (Doug Hellmann) Date: Fri, 08 Jan 2016 23:43:41 +0000 Subject: [issue26053] regression in pdb output between 2.7 and 3.5 Message-ID: <1452296621.32.0.373600761217.issue26053@psf.upfronthosting.co.za> New submission from Doug Hellmann: Under python 2.7 using the "run" command within pdb and passing it arguments causes those arguments to be printed out. Under 3.5, this is no longer true. $ python2.7 -m pdb pdb_run.py > /Users/dhellmann/Dropbox/PyMOTW/Python3/pymotw-3/source/pdb/pdb_run.py(7)() -> import sys (Pdb) c ('Command-line args:', ['pdb_run.py']) The program finished and will be restarted > /Users/dhellmann/Dropbox/PyMOTW/Python3/pymotw-3/source/pdb/pdb_run.py(7)() -> import sys (Pdb) run a b c "this is a long argument" Restarting pdb_run.py with arguments: a b c this is a long argument > /Users/dhellmann/Dropbox/PyMOTW/Python3/pymotw-3/source/pdb/pdb_run.py(7)() -> import sys $ python3.5 -m pdb pdb_run.py > /Users/dhellmann/Dropbox/PyMOTW/Python3/pymotw-3/source/pdb/pdb_run.py(7)() -> import sys (Pdb) c Command-line args: ['pdb_run.py'] The program finished and will be restarted > /Users/dhellmann/Dropbox/PyMOTW/Python3/pymotw-3/source/pdb/pdb_run.py(7)() -> import sys (Pdb) run a b c "this is a long argument" Restarting pdb_run.py with arguments: pdb_run.py > /Users/dhellmann/Dropbox/PyMOTW/Python3/pymotw-3/source/pdb/pdb_run.py(7)() -> import sys It looks like the issue is in the pdb main loop. Under 2.7 the restart logic has: except Restart: print "Restarting", mainpyfile, "with arguments:" print "\t" + " ".join(sys.argv[1:]) but under 3.5 that was changed to: except Restart: print("Restarting", mainpyfile, "with arguments:") print("\t" + " ".join(args)) The do_run() method has already reset sys.argv before throwing Restart, so to print the correct arguments sys.argv[1:] should be used. ---------- files: pdb_run.py keywords: 3.5regression messages: 257785 nosy: doughellmann priority: normal severity: normal status: open title: regression in pdb output between 2.7 and 3.5 type: behavior versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41538/pdb_run.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 18:44:27 2016 From: report at bugs.python.org (Doug Hellmann) Date: Fri, 08 Jan 2016 23:44:27 +0000 Subject: [issue26053] regression in pdb output between 2.7 and 3.5 In-Reply-To: <1452296621.32.0.373600761217.issue26053@psf.upfronthosting.co.za> Message-ID: <1452296667.42.0.990167156957.issue26053@psf.upfronthosting.co.za> Doug Hellmann added the comment: I should also mention that I haven't tested early versions of 3.x to see where exactly the regression was introduced. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 19:02:27 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 09 Jan 2016 00:02:27 +0000 Subject: [issue26045] Improve error message for http.client when posting unicode string In-Reply-To: <1452205637.36.0.0359255361227.issue26045@psf.upfronthosting.co.za> Message-ID: <1452297747.11.0.0403234805295.issue26045@psf.upfronthosting.co.za> Martin Panter added the comment: Personally I am skeptical if suggesting UTF-8 for the body data is a good idea, but I can go along with it, since other people want it. But I do strongly question whether it is right to suggest UTF-8 for header fields. The RFC only mentions ASCII and Latin-1. Newer protocols based on HTTP (RTSP comes to mind) do specify UTF-8 for the header, but that is probably out of scope of both the HTTP module and beginner-targetted errors. If I were redoing this patch, I would drop all the changes except at the body.encode() line in Emil?s original post. ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 19:08:28 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 09 Jan 2016 00:08:28 +0000 Subject: [issue26045] Improve error message for http.client when posting unicode string In-Reply-To: <1452205637.36.0.0359255361227.issue26045@psf.upfronthosting.co.za> Message-ID: <1452298108.08.0.430916341277.issue26045@psf.upfronthosting.co.za> Guido van Rossum added the comment: Martin, please make a patch along those lines! The only reason I generalized this to headers is that one of the three Requests issues referenced in the original post seemed to be about a header value (https://github.com/kennethreitz/requests/issues/1926). But that one seems different than the other two anyways, and it's about Python 3.7 so it wouldn't be helped by anything we're doing here anyways. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 19:17:09 2016 From: report at bugs.python.org (Michael Layzell) Date: Sat, 09 Jan 2016 00:17:09 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1452298629.3.0.815468034471.issue25677@psf.upfronthosting.co.za> Michael Layzell added the comment: Sorry for missing the review comments earlier, I didn't notice them (I've not used this bug tracker before - sorry). I've attached an updated patch which should not have the variable problem, and also takes some of the other review comments into account. Berker: I agree that the current positioning of the caret is undesirable, and that ideally we would report the error at the site of the operator rather than the first character of the expression. I think that changing this behavior is a different bug though. P.S: Sorry for disappearing for a month, I don't seem to get emails when there are changes made to the bug, and thus forgot to check up on the bug... ---------- Added file: http://bugs.python.org/file41539/cpython25677.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 20:39:57 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 09 Jan 2016 01:39:57 +0000 Subject: [issue25958] Implicit ABCs have no means of "anti-registration" In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za> Message-ID: <1452303597.6.0.370937885027.issue25958@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t have strong opinions about the Reversible class because I don?t imagine needing it. My instinct was __reverse__() is independent of __iter__(), so it should not be a subclass. But I don?t really mind either way. I did actually mean a version changed notice for the data model change. I see this as a small expansion of the Python object API. Previously, __reversed__() had to be a function, now you are also allowed to set it to None. The collections ABCs are just catching up with the API change. Imagine someone using an Orderable virtual base class that tested for __gt__() etc. If you need, you can write repetitive tests without copying and pasting or generated code: for [param, result1, result2] in parameters: with self.subTest(param=param): ... Maybe it is okay to add a test to ABCTestCase.validate_isinstance() to check that None cancels isinstance(). I also added some Reitveld comments for patch4a. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 21:06:10 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 09 Jan 2016 02:06:10 +0000 Subject: [issue26052] pydoc for __init__ with not docstring In-Reply-To: <1452295807.98.0.613500169742.issue26052@psf.upfronthosting.co.za> Message-ID: <1452305170.24.0.447655213894.issue26052@psf.upfronthosting.co.za> Martin Panter added the comment: I suspect this the same side effect of 3.5?s doc string inheritance that I mentioned in Issue 15582. The solution proposed was basically ?write a custom doc string?, though I?m not sure that is always appropriate. ---------- keywords: +3.5regression nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 21:10:57 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 09 Jan 2016 02:10:57 +0000 Subject: [issue26053] regression in pdb output between 2.7 and 3.5 In-Reply-To: <1452296621.32.0.373600761217.issue26053@psf.upfronthosting.co.za> Message-ID: <1452305457.03.0.455931027315.issue26053@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 21:44:40 2016 From: report at bugs.python.org (David Jackson) Date: Sat, 09 Jan 2016 02:44:40 +0000 Subject: [issue26054] Unable to run scripts: idle3 -r script.py Message-ID: <1452307480.34.0.944770933211.issue26054@psf.upfronthosting.co.za> New submission from David Jackson: [Raspberry Jessie] Idle3(4.2] If I open a idle3 shell (from menu) and enter >>import pandas as pd it accepts the command, but if I trying and run it from the shell>> idle3 -r script.py I get the following errors: Traceback (most recent call last): File "test.py", line 1, in import pandas as pd File "/home/pi/python/pandas.py", line 3, in from pandas_datareader import data, wb File "/usr/local/lib/python3.4/dist-packages/pandas_datareader-0.2.1-py3.4.egg/pandas_datareader/__init__.py", line 3, in from .data import (get_components_yahoo, get_data_famafrench, get_data_google, get_data_yahoo, File "/usr/local/lib/python3.4/dist-packages/pandas_datareader-0.2.1-py3.4.egg/pandas_datareader/data.py", line 7, in from pandas_datareader.google.daily import GoogleDailyReader File "/usr/local/lib/python3.4/dist-packages/pandas_datareader-0.2.1-py3.4.egg/pandas_datareader/google/daily.py", line 1, in from pandas_datareader.base import _DailyBaseReader File "/usr/local/lib/python3.4/dist-packages/pandas_datareader-0.2.1-py3.4.egg/pandas_datareader/base.py", line 9, in from pandas import to_datetime ImportError: cannot import name 'to_datetime' ---------- components: IDLE messages: 257792 nosy: davidjackson1955 priority: normal severity: normal status: open title: Unable to run scripts: idle3 -r script.py versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 22:07:11 2016 From: report at bugs.python.org (David Jackson) Date: Sat, 09 Jan 2016 03:07:11 +0000 Subject: [issue26054] Unable to run scripts: idle3 -r script.py In-Reply-To: <1452307480.34.0.944770933211.issue26054@psf.upfronthosting.co.za> Message-ID: <1452308830.96.0.511298335936.issue26054@psf.upfronthosting.co.za> David Jackson added the comment: The problem was I had a pandas.py and a pandas.pyc in my home directory. after deleting them everything seems to be working. ---------- resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 22:46:29 2016 From: report at bugs.python.org (Zachary Ware) Date: Sat, 09 Jan 2016 03:46:29 +0000 Subject: [issue26054] Unable to run scripts: idle3 -r script.py In-Reply-To: <1452307480.34.0.944770933211.issue26054@psf.upfronthosting.co.za> Message-ID: <1452311189.18.0.600243452619.issue26054@psf.upfronthosting.co.za> Zachary Ware added the comment: Glad you got it figured out. It's a situation that can be tricky to debug, as your eyes tend to gloss over the paths given in the traceback. It's much easier to figure out after you've been bitten the first time, though! ---------- nosy: +zach.ware stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 23:38:16 2016 From: report at bugs.python.org (YoungBoy) Date: Sat, 09 Jan 2016 04:38:16 +0000 Subject: [issue26055] sys.argv[0] is the python file, not "" Message-ID: <1452314296.6.0.563314730517.issue26055@psf.upfronthosting.co.za> New submission from YoungBoy: python tutorial 2.1.1 You can access this list by executing import sys. The length of the list is at least one; when no script and no arguments are given, sys.argv[0] is an empty string. but, when i try it, the sys.argv[0]is the filename,not empty string. ---------- assignee: docs at python components: Documentation messages: 257795 nosy: Wei, docs at python priority: normal severity: normal status: open title: sys.argv[0] is the python file, not "" versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 23:46:58 2016 From: report at bugs.python.org (random832) Date: Sat, 09 Jan 2016 04:46:58 +0000 Subject: [issue26055] sys.argv[0] is the python file, not "" In-Reply-To: <1452314296.6.0.563314730517.issue26055@psf.upfronthosting.co.za> Message-ID: <1452314818.81.0.906674360563.issue26055@psf.upfronthosting.co.za> random832 added the comment: By "when no script [is] given", it is referring to the use in the interactive interpreter, not in a python file. ---------- nosy: +random832 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 23:53:00 2016 From: report at bugs.python.org (YoungBoy) Date: Sat, 09 Jan 2016 04:53:00 +0000 Subject: [issue26055] sys.argv[0] is the python file, not "" In-Reply-To: <1452314296.6.0.563314730517.issue26055@psf.upfronthosting.co.za> Message-ID: <1452315180.0.0.470949065364.issue26055@psf.upfronthosting.co.za> Changes by YoungBoy : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 00:39:12 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 09 Jan 2016 05:39:12 +0000 Subject: [issue15430] Improve filecmp documentation In-Reply-To: <1343011170.68.0.66414126493.issue15430@psf.upfronthosting.co.za> Message-ID: <1452317952.06.0.341997021621.issue15430@psf.upfronthosting.co.za> Senthil Kumaran added the comment: This bug report can be closed as the patch, written by me is no longer valid. The only useful addition it can bring is, exposing the BUFSIZE, but that is used transparently by the module and I think, it need not be exposed via documentation. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 02:37:20 2016 From: report at bugs.python.org (koobs) Date: Sat, 09 Jan 2016 07:37:20 +0000 Subject: [issue20397] distutils --record option does not validate existence of byte-compiled files In-Reply-To: <1390746014.88.0.900467086198.issue20397@psf.upfronthosting.co.za> Message-ID: <1452325040.42.0.513357035643.issue20397@psf.upfronthosting.co.za> koobs added the comment: This needs review, commit, merge. We've back-ported and committed these patches against all of our FreeBSD Python ports (27,32,33,34,35) https://svnweb.freebsd.org/ports?view=revision&revision=405569 ---------- stage: needs patch -> patch review versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 02:42:56 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 09 Jan 2016 07:42:56 +0000 Subject: [issue26053] regression in pdb output between 2.7 and 3.5 In-Reply-To: <1452296621.32.0.373600761217.issue26053@psf.upfronthosting.co.za> Message-ID: <1452325376.96.0.494614924014.issue26053@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 02:44:20 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 Jan 2016 07:44:20 +0000 Subject: [issue22138] patch.object doesn't restore function defaults In-Reply-To: <1407212040.69.0.583222239779.issue22138@psf.upfronthosting.co.za> Message-ID: <20160109074417.21235.1827@psf.io> Roundup Robot added the comment: New changeset b67ed559a7d3 by Senthil Kumaran in branch '3.5': Issue #22138: Fix mock.patch behavior when patching descriptors. Restore https://hg.python.org/cpython/rev/b67ed559a7d3 New changeset 9b21dfd71561 by Senthil Kumaran in branch 'default': merge from 3.5 https://hg.python.org/cpython/rev/9b21dfd71561 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 02:45:37 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 09 Jan 2016 07:45:37 +0000 Subject: [issue22138] patch.object doesn't restore function defaults In-Reply-To: <1407212040.69.0.583222239779.issue22138@psf.upfronthosting.co.za> Message-ID: <1452325537.65.0.486264280119.issue22138@psf.upfronthosting.co.za> Senthil Kumaran added the comment: This was an interesting issue. Thanks for the patch, Sean to fix this bug. I have committed it in 3.5 and 3.6. ---------- assignee: -> orsenthil nosy: +orsenthil resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 03:19:23 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Jan 2016 08:19:23 +0000 Subject: [issue26029] Broken sentence in extending documentation In-Reply-To: <1452116648.24.0.989848174126.issue26029@psf.upfronthosting.co.za> Message-ID: <1452327563.83.0.743473327912.issue26029@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: docs at python -> terry.reedy nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 03:22:39 2016 From: report at bugs.python.org (Amandeep Singh Sohal) Date: Sat, 09 Jan 2016 08:22:39 +0000 Subject: [issue26056] installation failure Message-ID: <1452327759.39.0.705157588806.issue26056@psf.upfronthosting.co.za> New submission from Amandeep Singh Sohal: when i trying to install the python 3.5.1. It gives a error "window 7 service pack 1 and all applicable updates are required to install python 3.5.1". here i am also uploading the log file of installation. ---------- components: Installation files: Python 3.5.1 (32-bit)_20160109133257.log messages: 257801 nosy: Amandeep Singh Sohal priority: normal severity: normal status: open title: installation failure type: compile error versions: Python 3.5 Added file: http://bugs.python.org/file41540/Python 3.5.1 (32-bit)_20160109133257.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 03:28:19 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 Jan 2016 08:28:19 +0000 Subject: [issue26029] Broken sentence in extending documentation In-Reply-To: <1452116648.24.0.989848174126.issue26029@psf.upfronthosting.co.za> Message-ID: <20160109082816.69155.27647@psf.io> Roundup Robot added the comment: New changeset 3b860ce5bb51 by Terry Jan Reedy in branch '3.5': Issue #26029: Remove extraneous word. Patch by Upendra Kumar. https://hg.python.org/cpython/rev/3b860ce5bb51 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 03:28:57 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Jan 2016 08:28:57 +0000 Subject: [issue26029] Broken sentence in extending documentation In-Reply-To: <1452116648.24.0.989848174126.issue26029@psf.upfronthosting.co.za> Message-ID: <1452328137.1.0.423829367638.issue26029@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thanks for reporting. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 03:34:29 2016 From: report at bugs.python.org (Zachary Ware) Date: Sat, 09 Jan 2016 08:34:29 +0000 Subject: [issue26056] installation failure In-Reply-To: <1452327759.39.0.705157588806.issue26056@psf.upfronthosting.co.za> Message-ID: <1452328469.65.0.402907675841.issue26056@psf.upfronthosting.co.za> Zachary Ware added the comment: Just like it says, you need Service Pack 1 for Python 3.5. If for some reason that's not possible, you'll have to revert back to Python 3.4. ---------- nosy: +zach.ware resolution: -> not a bug stage: -> resolved status: open -> closed type: compile error -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 03:37:49 2016 From: report at bugs.python.org (Zachary Ware) Date: Sat, 09 Jan 2016 08:37:49 +0000 Subject: [issue26029] Broken sentence in extending documentation In-Reply-To: <1452116648.24.0.989848174126.issue26029@psf.upfronthosting.co.za> Message-ID: <1452328669.92.0.223222013108.issue26029@psf.upfronthosting.co.za> Zachary Ware added the comment: Terry, it doesn't look like you used Upendra's patch. What you committed just removes the "of", but doesn't change "addition" to "additional", which is also required to make that sentence make sense. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 03:41:42 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 09 Jan 2016 08:41:42 +0000 Subject: [issue26057] Avoid nonneeded use of PyUnicode_FromObject() Message-ID: <1452328901.15.0.65828251852.issue26057@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: In Python 2 PyUnicode_FromObject() was used for coercing 8-bit strings to unicode by decoding them with the default encoding. But in Python 3 there is no such coercing. The effect of PyUnicode_FromObject() in Python 3 is ensuring that the argument is a string and convert an instance of str subtype to exact str. The latter often is just a waste of memory and time, since resulted string is used only for retrieving UTF-8 representation or raw data. Proposed patch makes following things: 1. Avoids unneeded copying of string's content. 2. Avoids raising some unneeded exceptions. 3. Gets rid of unneeded incref/decref. 4. Makes some error messages more correct or informative. 5. Converts runtime checks PyBytes_Check() for results of string encoding to asserts. Example of performance gain: Unpatched: $ ./python -m timeit -s "a = 'a'*100; b = 'b'*1000" -- "a in b" 1000000 loops, best of 3: 0.404 usec per loop $ ./python -m timeit -s "class S(str): pass" -s "a = S('a'*100); b = S('b'*1000)" -- "a in b" 1000000 loops, best of 3: 0.723 usec per loop Patched: $ ./python -m timeit -s "a = 'a'*100; b = 'b'*1000" -- "a in b" 1000000 loops, best of 3: 0.383 usec per loop $ ./python -m timeit -s "class S(str): pass" -s "a = S('a'*100); b = S('b'*1000)" -- "a in b" 1000000 loops, best of 3: 0.387 usec per loop ---------- components: Interpreter Core files: no_unicode_copy.patch keywords: patch messages: 257806 nosy: haypo, ncoghlan, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Avoid nonneeded use of PyUnicode_FromObject() type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file41541/no_unicode_copy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 04:02:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 09 Jan 2016 09:02:23 +0000 Subject: [issue26057] Avoid nonneeded use of PyUnicode_FromObject() In-Reply-To: <1452328901.15.0.65828251852.issue26057@psf.upfronthosting.co.za> Message-ID: <1452330143.82.0.164450019893.issue26057@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue15984 about correcting the documentation of PyUnicode_FromObject(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 04:20:05 2016 From: report at bugs.python.org (Eryk Sun) Date: Sat, 09 Jan 2016 09:20:05 +0000 Subject: [issue26024] Non-ascii Windows locale names In-Reply-To: <1452090490.23.0.240691672935.issue26024@psf.upfronthosting.co.za> Message-ID: <1452331205.77.0.181792411864.issue26024@psf.upfronthosting.co.za> Eryk Sun added the comment: The issue isn't quite the same for 3.5+. The new CRT uses Windows Vista locale APIs. In this case it uses LOCALE_SENGLISHLANGUAGENAME instead of the old LOCALE_SENGLANGUAGE. This maps "Norwegian" to simply "Norwegian" instead of "Norwegian Bokm?l": >>> locale.setlocale(locale.LC_TIME, 'norwegian') 'Norwegian_Norway.1252' The "Norwegian Bokm?l" language name has to be requested explicitly to see the same problem: >>> try: locale.setlocale(locale.LC_TIME, 'Norwegian Bokm?l') ... except Exception as e: print(e) ... unsupported locale setting The fix for 3.4 would be to encode the locale string using PyUnicode_AsMBCSString (ANSI). It's too late, however, since 3.4 is no longer getting bug fixes. For 3.5+, setlocale could either switch to using _wsetlocale on Windows or call setlocale with the string encoded via Py_EncodeLocale (wcstombs). Encoding the string via wcstombs is required because the new CRT roundtrips the conversion via mbstowcs before forwarding the call to _wsetlocale. This means that success depends on the current LC_CTYPE, unless Python switches to calling _wsetlocale directly. As a workaround for 3.5+, the new CRT also supports RFC 4646 language-tag locales when running on Vista or later. For example, "Norwegian Bokm?l" is simply "nb". Language-tag locales differ from POSIX locales. Superficially, they use "-" instead of "_" as the delimiter. More importantly, they don't allow explicitly setting the codeset. Instead of a .codeset, they use ISO 15924 script codes. Specifying a script may select a different ANSI codepage. It depends on whether there's an NLS definition for the language-script combination. For example, Bosnian can be written using either Latin or Cyrillic. Thus the "bs-BA" and "bs-Latn-BA" locales use the Central Europe codepage 1250, but "bs-Cyrl-BA" uses the Cyrillic codepage 1251. On the other hand, "en-Cyrl-US" still uses the Latin codepage 1252. As a separate issue, language-tag locales break the parsing in locale.getlocale: >>> locale.setlocale(locale.LC_TIME, 'nb-NO') 'nb-NO' >>> try: locale.getlocale(locale.LC_TIME) ... except Exception as e: print(e) ... unknown locale: nb-NO >>> locale.setlocale(locale.LC_CTYPE, 'bs-Cyrl-BA') 'bs-Cyrl-BA' >>> try: locale.getlocale(locale.LC_CTYPE) ... except Exception as e: print(e) ... unknown locale: bs-Cyrl-BA ---------- resolution: -> third party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 04:30:48 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 09 Jan 2016 09:30:48 +0000 Subject: [issue26058] Add dict.__version__ read-only property Message-ID: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch implements the following PEP currently discussed on python-ideas: https://faster-cpython.readthedocs.org/pep_dict_version.html#pep-dict-version ---------- files: dict_version.patch keywords: patch messages: 257809 nosy: haypo priority: normal severity: normal status: open title: Add dict.__version__ read-only property type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file41542/dict_version.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 04:34:12 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 09 Jan 2016 09:34:12 +0000 Subject: [issue26058] Add dict.__version__ read-only property In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za> Message-ID: <1452332052.18.0.384050047213.issue26058@psf.upfronthosting.co.za> STINNER Victor added the comment: Result of pybench on Dict microbenchmarks: DictCreation: 44ms 49ms -10.5% 44ms 49ms -10.7% DictWithFloatKeys: 35ms 35ms -0.5% 35ms 35ms -1.0% DictWithIntegerKeys: 28ms 28ms -1.2% 28ms 29ms -2.3% DictWithStringKeys: 26ms 27ms -3.2% 26ms 28ms -4.8% SimpleDictManipulation: 52ms 53ms -0.7% 53ms 53ms -0.4% Hum, as usuall, pybench doesn't seem reliable at all: I expect worse performance with the patch since it adds "version++" in dict.__setimte__(). I don't really trust pybench, results seem to have a lot of noise :-/ Maybe I'm not using pybench correctly? I used: $ make distclean; ./configure && make $ ./python Tools/pybench/pybench.py -f pybench.default $ patch -p1 < dict_version.patch $ ./python Tools/pybench/pybench.py -f pybench.dictversion $ ./python Tools/pybench/pybench.py -s pybench.dictversion -c pybench.default Full output: ------------------------------------------------------------------------------- PYBENCH 2.1 ------------------------------------------------------------------------------- * using CPython 3.6.0a0 (default:53271aa4d84c+, Jan 9 2016, 10:27:40) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] * disabled garbage collection * system check interval set to maximum: 2147483647 * using timer: time.perf_counter * timer: resolution=1e-09, implementation=clock_gettime(CLOCK_MONOTONIC) ------------------------------------------------------------------------------- Benchmark: pybench.dictversion ------------------------------------------------------------------------------- Rounds: 10 Warp: 10 Timer: time.perf_counter Machine Details: Platform ID: Linux-4.2.5-300.fc23.x86_64-x86_64-with-fedora-23-Twenty_Three Processor: x86_64 Python: Implementation: CPython Executable: /home/haypo/prog/python/default/python Version: 3.6.0a0 Compiler: GCC 5.1.1 20150618 (Red Hat 5.1.1-4) Bits: 64bit Build: Jan 9 2016 10:27:40 (#default:53271aa4d84c+) Unicode: UCS4 ------------------------------------------------------------------------------- Comparing with: pybench.default ------------------------------------------------------------------------------- Rounds: 10 Warp: 10 Timer: time.perf_counter Machine Details: Platform ID: Linux-4.2.5-300.fc23.x86_64-x86_64-with-fedora-23-Twenty_Three Processor: x86_64 Python: Implementation: CPython Executable: /home/haypo/prog/python/default/python Version: 3.6.0a0 Compiler: GCC 5.1.1 20150618 (Red Hat 5.1.1-4) Bits: 64bit Build: Jan 9 2016 10:21:57 (#default:53271aa4d84c) Unicode: UCS4 Test minimum run-time average run-time this other diff this other diff ------------------------------------------------------------------------------- BuiltinFunctionCalls: 42ms 42ms +0.1% 43ms 43ms -0.9% BuiltinMethodLookup: 26ms 25ms +5.7% 26ms 25ms +5.1% CompareFloats: 27ms 27ms -0.9% 27ms 28ms -4.2% CompareFloatsIntegers: 60ms 63ms -3.3% 61ms 65ms -6.8% CompareIntegers: 41ms 38ms +7.9% 41ms 38ms +7.2% CompareInternedStrings: 30ms 28ms +5.7% 30ms 28ms +5.0% CompareLongs: 24ms 22ms +8.6% 24ms 22ms +8.5% CompareStrings: 22ms 22ms +0.3% 23ms 24ms -6.6% ComplexPythonFunctionCalls: 43ms 42ms +1.2% 43ms 45ms -5.2% ConcatStrings: 29ms 32ms -11.0% 29ms 33ms -13.6% CreateInstances: 45ms 45ms +0.3% 46ms 46ms -0.4% CreateNewInstances: 34ms 34ms +0.6% 35ms 34ms +0.7% CreateStringsWithConcat: 58ms 58ms +0.1% 58ms 58ms -0.1% DictCreation: 44ms 49ms -10.5% 44ms 49ms -10.7% DictWithFloatKeys: 35ms 35ms -0.5% 35ms 35ms -1.0% DictWithIntegerKeys: 28ms 28ms -1.2% 28ms 29ms -2.3% DictWithStringKeys: 26ms 27ms -3.2% 26ms 28ms -4.8% ForLoops: 22ms 22ms +0.4% 22ms 22ms +0.6% IfThenElse: 34ms 34ms +0.9% 34ms 34ms +0.8% ListSlicing: 34ms 34ms -0.2% 34ms 34ms -0.1% NestedForLoops: 37ms 36ms +2.1% 37ms 36ms +2.1% NestedListComprehensions: 36ms 35ms +1.4% 36ms 36ms +1.8% NormalClassAttribute: 75ms 77ms -2.5% 75ms 77ms -2.3% NormalInstanceAttribute: 37ms 37ms +2.2% 38ms 37ms +2.5% PythonFunctionCalls: 37ms 36ms +1.8% 37ms 37ms +1.6% PythonMethodCalls: 50ms 47ms +5.5% 50ms 48ms +4.5% Recursion: 61ms 61ms -0.2% 61ms 62ms -0.2% SecondImport: 35ms 36ms -2.9% 35ms 37ms -3.3% SecondPackageImport: 37ms 37ms -0.3% 37ms 37ms -0.4% SecondSubmoduleImport: 89ms 87ms +2.1% 90ms 88ms +1.6% SimpleComplexArithmetic: 23ms 23ms +0.0% 24ms 24ms -0.1% SimpleDictManipulation: 52ms 53ms -0.7% 53ms 53ms -0.4% SimpleFloatArithmetic: 25ms 25ms -1.2% 25ms 25ms -1.0% SimpleIntFloatArithmetic: 32ms 32ms -0.3% 32ms 32ms -1.1% SimpleIntegerArithmetic: 32ms 32ms -0.6% 32ms 32ms -0.3% SimpleListComprehensions: 29ms 28ms +2.3% 30ms 29ms +3.2% SimpleListManipulation: 27ms 28ms -1.3% 28ms 28ms -1.4% SimpleLongArithmetic: 22ms 22ms +3.6% 23ms 22ms +4.4% SmallLists: 38ms 38ms -1.9% 38ms 41ms -7.0% SmallTuples: 47ms 44ms +7.8% 47ms 44ms +7.5% SpecialClassAttribute: 75ms 73ms +2.3% 75ms 73ms +2.2% SpecialInstanceAttribute: 38ms 39ms -1.8% 38ms 39ms -2.1% StringMappings: 84ms 83ms +0.8% 84ms 84ms +0.5% StringPredicates: 49ms 49ms -0.6% 49ms 49ms -1.0% StringSlicing: 42ms 42ms +0.8% 42ms 42ms +0.7% TryExcept: 25ms 25ms -0.4% 25ms 25ms -0.8% TryFinally: 31ms 31ms +1.1% 32ms 31ms +1.4% TryRaiseExcept: 12ms 12ms -0.8% 12ms 12ms -1.4% TupleSlicing: 43ms 43ms +0.1% 43ms 43ms -0.6% WithFinally: 49ms 50ms -0.9% 49ms 50ms -0.9% WithRaiseExcept: 39ms 39ms -0.6% 39ms 40ms -1.6% ------------------------------------------------------------------------------- Totals: 2011ms 2006ms +0.2% 2025ms 2035ms -0.5% (this=pybench.dictversion, other=pybench.default) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 04:38:04 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 09 Jan 2016 09:38:04 +0000 Subject: [issue26049] Poor performance when reading large xmlrpc data In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za> Message-ID: <1452332284.83.0.298573129202.issue26049@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Reading with 10 MB limit allocates 10 MB buffer. It may be better to start with 1024 bytes limit, and increase it by 2 times on every iteration. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 04:43:43 2016 From: report at bugs.python.org (Ramin Farajpour Cami) Date: Sat, 09 Jan 2016 09:43:43 +0000 Subject: [issue26059] Integer Overflow Message-ID: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za> New submission from Ramin Farajpour Cami: this work on python 2.7.10 and 2.7.11 crash, C:\Users\RaminFP>cdb -g python C:\Users\RaminFP\Desktop\1.py Microsoft (R) Windows Debugger Version 6.11.0001.404 X86 Copyright (c) Microsoft Corporation. All rights reserved. CommandLine: python C:\Users\RaminFP\Desktop\1.py Symbol search path is: srv*c:\pubsymbols*http://msdl.microsoft.com/download/symbols Executable search path is: ModLoad: 1d000000 1d00a000 python.exe ModLoad: 76fe0000 77159000 ntdll.dll ModLoad: 76ac0000 76bb0000 C:\Windows\SysWOW64\KERNEL32.DLL ModLoad: 74e30000 74fa6000 C:\Windows\SysWOW64\KERNELBASE.dll ModLoad: 1e000000 1e264000 C:\Windows\SysWOW64\python27.dll ModLoad: 71a10000 71ab3000 C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.9158_none_5091b51ebcb97cdc\MSVCR90.dll ModLoad: 748f0000 74a30000 C:\Windows\SysWOW64\USER32.dll ModLoad: 747a0000 748ed000 C:\Windows\SysWOW64\GDI32.dll ModLoad: 763e0000 7645b000 C:\Windows\SysWOW64\ADVAPI32.dll ModLoad: 74bd0000 74c8e000 C:\Windows\SysWOW64\msvcrt.dll ModLoad: 76bd0000 76c13000 C:\Windows\SysWOW64\sechost.dll ModLoad: 76c30000 76cdc000 C:\Windows\SysWOW64\RPCRT4.dll ModLoad: 740f0000 7410e000 C:\Windows\SysWOW64\SspiCli.dll ModLoad: 740e0000 740ea000 C:\Windows\SysWOW64\CRYPTBASE.dll ModLoad: 74080000 740d9000 C:\Windows\SysWOW64\bcryptPrimitives.dll ModLoad: 74fb0000 7636f000 C:\Windows\SysWOW64\SHELL32.dll ModLoad: 742c0000 7479d000 C:\Windows\SysWOW64\windows.storage.dll ModLoad: 76900000 76aba000 C:\Windows\SysWOW64\combase.dll ModLoad: 74de0000 74e24000 C:\Windows\SysWOW64\shlwapi.dll ModLoad: 767c0000 767cc000 C:\Windows\SysWOW64\kernel.appcore.dll ModLoad: 76d40000 76dcd000 C:\Windows\SysWOW64\shcore.dll ModLoad: 767d0000 76814000 C:\Windows\SysWOW64\powrprof.dll ModLoad: 76bc0000 76bcf000 C:\Windows\SysWOW64\profapi.dll ModLoad: 76670000 7669b000 C:\Windows\SysWOW64\IMM32.DLL ModLoad: 766a0000 767c0000 C:\Windows\SysWOW64\MSCTF.dll (13a4.1030): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=02555630 ebx=5708ac94 ecx=00003c7a edx=00000000 esi=02546448 edi=57091000 eip=71a4ae7a esp=0028fc98 ebp=0028fca0 iopl=0 nv up ei pl nz ac pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010216 MSVCR90!memcpy+0x5a: 71a4ae7a f3a5 rep movs dword ptr es:[edi],dword ptr [esi] 0:000> r eax=02555630 ebx=5708ac94 ecx=00003c7a edx=00000000 esi=02546448 edi=57091000 eip=71a4ae7a esp=0028fc98 ebp=0028fca0 iopl=0 nv up ei pl nz ac pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010216 MSVCR90!memcpy+0x5a: 71a4ae7a f3a5 rep movs dword ptr es:[edi],dword ptr [esi] 0:000> db esi *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\SysWOW64\python27.dll - 02546448 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 02546458 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 02546468 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 02546478 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 02546488 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 02546498 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 025464a8 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 025464b8 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0:000> db edi 57091000 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 57091010 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 57091020 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 57091030 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 57091040 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 57091050 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 57091060 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 57091070 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 0:000> ---------- components: ctypes files: 1.py messages: 257812 nosy: Ramin Farajpour Cami priority: normal severity: normal status: open title: Integer Overflow type: crash versions: Python 2.7 Added file: http://bugs.python.org/file41543/1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 04:47:48 2016 From: report at bugs.python.org (Daniel Dye) Date: Sat, 09 Jan 2016 09:47:48 +0000 Subject: [issue25991] readline example eventually consumes all memory In-Reply-To: <1451708933.83.0.797303528676.issue25991@psf.upfronthosting.co.za> Message-ID: <1452332868.16.0.385849971521.issue25991@psf.upfronthosting.co.za> Daniel Dye added the comment: Add a history length of 1000 lines Default is -1 (infinite), which may grow unruly ---------- keywords: +patch nosy: +Daniel Dye Added file: http://bugs.python.org/file41544/doc_library_readline.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 04:53:06 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 09 Jan 2016 09:53:06 +0000 Subject: [issue26058] Add dict.__version__ read-only property In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za> Message-ID: <1452333186.64.0.00860839584486.issue26058@psf.upfronthosting.co.za> STINNER Victor added the comment: Using timeit to microbenchmark dict operations (constructor, __setitem__, __delitem__, clear), I get exactly the same performance or even better performance (???) with the patch. ./python -m timeit 'd={1: 0}; d[2]=0; d[3]=0; d[4]=0; del d[1]; del d[2]; d.clear()' Original: 318 ns Patched: 318 ns ./python -m timeit 'd={i:i for i in range(2**16)}' 'for i in range(2**16): d[i]=i-1' 'for i in range(2**16): d[i]=i+1' 'for i in range(2**15): del d[i]' 'd.clear()' Original: 19.9 ms Patched: 18.9 ms (5% faster) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 05:00:35 2016 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Sat, 09 Jan 2016 10:00:35 +0000 Subject: [issue26049] Poor performance when reading large xmlrpc data In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za> Message-ID: <1452333635.17.0.795821225955.issue26049@psf.upfronthosting.co.za> C?dric Krier added the comment: Will it not be better indeed to just stream.read() without any argument? Because HTTPResponse will call _safe_read with just the length of the header. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 05:26:45 2016 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Sat, 09 Jan 2016 10:26:45 +0000 Subject: [issue26049] Poor performance when reading large xmlrpc data In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za> Message-ID: <1452335205.72.0.333206441459.issue26049@psf.upfronthosting.co.za> C?dric Krier added the comment: Answering to myself, it is better to read by chunk to feed the parser also by chunk. So here is a version of the patch which increases by 2 on every loop. ---------- Added file: http://bugs.python.org/file41545/default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 05:42:39 2016 From: report at bugs.python.org (Kumaripaba Miyurusara Athukorala) Date: Sat, 09 Jan 2016 10:42:39 +0000 Subject: [issue26041] Update deprecation messages of platform.dist() and platform.linux_distribution() In-Reply-To: <1452187100.03.0.384540652472.issue26041@psf.upfronthosting.co.za> Message-ID: <1452336159.62.0.552136242309.issue26041@psf.upfronthosting.co.za> Kumaripaba Miyurusara Athukorala added the comment: Attached the patch that fixed the issue26041. Changed the deprecation message. ---------- keywords: +patch nosy: +Kumaripaba Miyurusara Athukorala Added file: http://bugs.python.org/file41546/issue26041.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 06:00:03 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 09 Jan 2016 11:00:03 +0000 Subject: [issue26058] Add dict.__version__ read-only property In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za> Message-ID: <1452337203.66.0.0223802390369.issue26058@psf.upfronthosting.co.za> STINNER Victor added the comment: Updated patch, I forgot to include unit tests. I added a test on integer overflow on the version. The patch adds _testcapi.dict_setversion(dict, version) and _testcapi.PY_SIZE_MAX. ---------- Added file: http://bugs.python.org/file41547/dict_version-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 06:05:46 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 09 Jan 2016 11:05:46 +0000 Subject: [issue26058] Add dict.__version__ read-only property In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za> Message-ID: <1452337546.46.0.959707604366.issue26058@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't understand this: > The version 0 is reserved for "missing key" ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 06:09:25 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 09 Jan 2016 11:09:25 +0000 Subject: [issue26058] Add dict.__version__ read-only property In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za> Message-ID: <1452337765.39.0.629169818327.issue26058@psf.upfronthosting.co.za> STINNER Victor added the comment: > I don't understand this: >> The version 0 is reserved for "missing key" Oh, ignore it, it's an outdated comment :-) Dictionary version is initialized to 0, it's not more "reserved". FYI I added the comment in my first implementation which also added a version to dictionary *entries*. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 07:29:18 2016 From: report at bugs.python.org (Manvi B) Date: Sat, 09 Jan 2016 12:29:18 +0000 Subject: [issue24918] Docs layout bug In-Reply-To: <1440361207.71.0.0873906255469.issue24918@psf.upfronthosting.co.za> Message-ID: <1452342558.2.0.21397885143.issue24918@psf.upfronthosting.co.za> Manvi B added the comment: Fixed by using "display:inline" in ".highlight" class. ---------- keywords: +patch nosy: +Manvi B Added file: http://bugs.python.org/file41548/issue24918.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 07:37:03 2016 From: report at bugs.python.org (Manvi B) Date: Sat, 09 Jan 2016 12:37:03 +0000 Subject: [issue24918] Docs layout bug In-Reply-To: <1440361207.71.0.0873906255469.issue24918@psf.upfronthosting.co.za> Message-ID: <1452343023.57.0.57229526947.issue24918@psf.upfronthosting.co.za> Manvi B added the comment: Fixed by using "background: none" in ".highlight" class. ---------- Added file: http://bugs.python.org/file41549/issue24918.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 07:46:38 2016 From: report at bugs.python.org (Manvi B) Date: Sat, 09 Jan 2016 12:46:38 +0000 Subject: [issue24918] Docs layout bug In-Reply-To: <1440361207.71.0.0873906255469.issue24918@psf.upfronthosting.co.za> Message-ID: <1452343598.16.0.547727794277.issue24918@psf.upfronthosting.co.za> Manvi B added the comment: Both solutions msg257821, msg257822 seems to fix the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 07:56:11 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 09 Jan 2016 12:56:11 +0000 Subject: [issue26060] Class __dict__ iteration order changing due to type instance key-sharing Message-ID: <1452344171.87.0.895462140972.issue26060@psf.upfronthosting.co.za> New submission from Nick Coghlan: Dave Beazley found some odd behaviour in Python 3.4.1+, where the order of the keys in a class dictionary can be changed by assigning a new value to an existing key: https://gist.github.com/dabeaz/617a5b0542d57e003433 Dave's original reproducer showed a case where iterating over class attributes replacing some of them with new values worked correctly as a class decorator on a normal instance of type, but was unreliable when the same operation was called from a metaclass __new__ or __init__ method. Further investigation showed that it wasn't the timing of the assignment that mattered, but rather the use of a subclass of type rather than type itself as the metaclass. Checking between 3.4.0 and 3.4.1 with hg bisect using the simpler attached script as the reproducer identified the enabling of key sharing with subclass instances in #20637 as the apparent culprit. My current theory is that from 3.3.0 to 3.4.0, keys weren't being shared between instances of type and instances of type subclasses at all, and changing that in 3.4.1 broke a subtle assumption somewhere in type_new. ---------- files: ns_reordering_bug.py messages: 257824 nosy: ncoghlan priority: normal severity: normal status: open title: Class __dict__ iteration order changing due to type instance key-sharing Added file: http://bugs.python.org/file41550/ns_reordering_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 08:01:40 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 09 Jan 2016 13:01:40 +0000 Subject: [issue26060] Class __dict__ iteration order changing due to type instance key-sharing In-Reply-To: <1452344171.87.0.895462140972.issue26060@psf.upfronthosting.co.za> Message-ID: <1452344500.86.0.887107475081.issue26060@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +Mark.Shannon, benjamin.peterson, pingebretson, rhettinger, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 08:03:03 2016 From: report at bugs.python.org (Kumaripaba Miyurusara Athukorala) Date: Sat, 09 Jan 2016 13:03:03 +0000 Subject: [issue26041] Update deprecation messages of platform.dist() and platform.linux_distribution() In-Reply-To: <1452187100.03.0.384540652472.issue26041@psf.upfronthosting.co.za> Message-ID: <1452344583.19.0.752976056256.issue26041@psf.upfronthosting.co.za> Kumaripaba Miyurusara Athukorala added the comment: Fixed the remaining errors. ---------- Added file: http://bugs.python.org/file41551/issue26041.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 08:15:01 2016 From: report at bugs.python.org (Elena Oat) Date: Sat, 09 Jan 2016 13:15:01 +0000 Subject: [issue25574] 2.7 incorrectly documents objects hash as equal to id In-Reply-To: <1446849305.52.0.678156368856.issue25574@psf.upfronthosting.co.za> Message-ID: <1452345301.36.0.0583331016045.issue25574@psf.upfronthosting.co.za> Elena Oat added the comment: Updated the documentation. Now it says that the hash is derived from id, as it says already in Python 3 docs. ---------- nosy: +Elena.Oat Added file: http://bugs.python.org/file41552/issue25574.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 08:29:56 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 09 Jan 2016 13:29:56 +0000 Subject: [issue18911] minidom does not encode correctly when calling Document.writexml In-Reply-To: <1378186619.58.0.930376227557.issue18911@psf.upfronthosting.co.za> Message-ID: <1452346196.03.0.730217622485.issue18911@psf.upfronthosting.co.za> Ezio Melotti added the comment: > On Python 3 you should not only open file in text mode with specified > encoding, but also specify the "xmlcharrefreplace" error handler. Isn't this only required in case there are non encodable characters? If the encoding is utf-8, this shouldn't be necessary (unless there are lone surrogates). Specifying xmlcharrefreplace might be useful while using ascii or latin1 though. The docs of writexml don't seem to specify if the file should be opened in text or binary mode but istm that only text mode is supported. The advice of using xmlcharrefreplace could be added in a note. ---------- nosy: +ezio.melotti versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 08:50:38 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 09 Jan 2016 13:50:38 +0000 Subject: [issue25730] invisible sidebar content with code snippets In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za> Message-ID: <1452347438.08.0.35452844508.issue25730@psf.upfronthosting.co.za> Ezio Melotti added the comment: This is a duplicate of #24918, which also has a couple of patches that seem to fix the problem. ---------- superseder: -> Docs layout bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 08:51:22 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 09 Jan 2016 13:51:22 +0000 Subject: [issue25730] invisible sidebar content with code snippets In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za> Message-ID: <1452347482.72.0.79155567382.issue25730@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- resolution: -> duplicate stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 09:09:38 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 Jan 2016 14:09:38 +0000 Subject: [issue24789] ctypes doc string In-Reply-To: <1438719738.53.0.780685651956.issue24789@psf.upfronthosting.co.za> Message-ID: <20160109140935.21392.52876@psf.io> Roundup Robot added the comment: New changeset 1753a28acad4 by Ezio Melotti in branch '3.5': #24789: fix docstring of ctypes.create_string_buffer. Patch by Matheus Vieira Portela. https://hg.python.org/cpython/rev/1753a28acad4 New changeset 57964ca3ce0f by Ezio Melotti in branch 'default': #24789: merge with 3.5. https://hg.python.org/cpython/rev/57964ca3ce0f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 09:11:29 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 09 Jan 2016 14:11:29 +0000 Subject: [issue24789] ctypes doc string In-Reply-To: <1438719738.53.0.780685651956.issue24789@psf.upfronthosting.co.za> Message-ID: <1452348689.19.0.0779829950388.issue24789@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- nosy: +ezio.melotti resolution: -> fixed stage: needs patch -> resolved status: open -> closed versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 09:12:01 2016 From: report at bugs.python.org (Aviv Palivoda) Date: Sat, 09 Jan 2016 14:12:01 +0000 Subject: [issue26061] logging LogRecordFactory allow kwargs Message-ID: <1452348721.62.0.0659441609169.issue26061@psf.upfronthosting.co.za> New submission from Aviv Palivoda: The logging LogRecord factory receives kwargs. However because _log and makeRecord functions in the Logger class don't support kwargs we can't actually pass additional positional arguments to LogRecord. A use case for this is attached. I had made a patch to fix this by changing _log and makeRecord to accept kwargs and pass them. ---------- components: Library (Lib) files: usecase.py messages: 257831 nosy: palaviv, vinay.sajip priority: normal severity: normal status: open title: logging LogRecordFactory allow kwargs type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file41553/usecase.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 09:12:41 2016 From: report at bugs.python.org (SilentGhost) Date: Sat, 09 Jan 2016 14:12:41 +0000 Subject: [issue11440] fix_callable should be dropped from lib2to3 / changed In-Reply-To: <1299600488.07.0.0466070744973.issue11440@psf.upfronthosting.co.za> Message-ID: <1452348761.2.0.460761116779.issue11440@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 09:14:43 2016 From: report at bugs.python.org (Aviv Palivoda) Date: Sat, 09 Jan 2016 14:14:43 +0000 Subject: [issue26061] logging LogRecordFactory allow kwargs In-Reply-To: <1452348721.62.0.0659441609169.issue26061@psf.upfronthosting.co.za> Message-ID: <1452348883.53.0.749557802521.issue26061@psf.upfronthosting.co.za> Aviv Palivoda added the comment: adding the patch :) ---------- keywords: +patch Added file: http://bugs.python.org/file41554/LogRecordFactoryKwargs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 09:25:36 2016 From: report at bugs.python.org (=?utf-8?q?Christoph_B=C3=B6ddeker?=) Date: Sat, 09 Jan 2016 14:25:36 +0000 Subject: [issue26062] IPython4 bash magic ! with {} does not work with Python 3.5.1 Message-ID: <1452349536.45.0.55048690622.issue26062@psf.upfronthosting.co.za> New submission from Christoph B?ddeker: Hello, I found a wrong behavior with IPython 4 in combination with Python 3.5.1. Normally in a command like "In [2]: !echo {a}" everything inside {} is interpreted with python and inserted to executed the line with bash. After I done a upgrade tp Python 3.5.1 this wasn't working. After a downgrade (3.5.0) it was working. In the bottom is an example, where "In [2]: !echo {a}" are the important lines. In [2]: !echo {a} * Python 3.5.0 -> 3 * Python 3.5.1 -> {a} Best regards Christoph ----------------------------------------------------------------------- $ ipython Python 3.5.1 |Anaconda 2.4.0 (64-bit)| (default, Dec 7 2015, 11:16:01) Type "copyright", "credits" or "license" for more information. IPython 4.0.0 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object', use 'object??' for extra details. In [1]: a = 3 In [2]: !echo {a} {a} In [3]: ----------------------------------------------------------------------- conda install python=3.5.0 Fetching package metadata: .... Solving package specifications: ................ Package plan for installation in environment /opt/anaconda3: The following packages will be DOWNGRADED: python: 3.5.1-0 --> 3.5.0-1 Proceed ([y]/n)? y Unlinking packages ... [ COMPLETE ]|###################################################| 100% Linking packages ... [ COMPLETE ]|###################################################| 100% ----------------------------------------------------------------------- $ ipython Python 3.5.0 |Anaconda 2.4.0 (64-bit)| (default, Oct 19 2015, 21:57:25) Type "copyright", "credits" or "license" for more information. IPython 4.0.0 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object', use 'object??' for extra details. In [1]: a = 3 In [2]: !echo {a} 3 In [3]: ---------- messages: 257833 nosy: Christoph B?ddeker priority: normal severity: normal status: open title: IPython4 bash magic ! with {} does not work with Python 3.5.1 type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 09:30:37 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 09 Jan 2016 14:30:37 +0000 Subject: [issue26063] Update copyright in the devguide Message-ID: <1452349837.88.0.575893993486.issue26063@psf.upfronthosting.co.za> New submission from Ezio Melotti: The copyright in the devguide needs to be updated for 2016. ---------- components: Devguide messages: 257834 nosy: ezio.melotti, willingc priority: normal severity: normal stage: needs patch status: open title: Update copyright in the devguide type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 09:31:15 2016 From: report at bugs.python.org (Chris Gonzalez) Date: Sat, 09 Jan 2016 14:31:15 +0000 Subject: [issue26063] Update copyright in the devguide In-Reply-To: <1452349837.88.0.575893993486.issue26063@psf.upfronthosting.co.za> Message-ID: <1452349875.06.0.0816241875681.issue26063@psf.upfronthosting.co.za> Changes by Chris Gonzalez : ---------- keywords: +patch Added file: http://bugs.python.org/file41555/copyright.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 09:31:56 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 09 Jan 2016 14:31:56 +0000 Subject: [issue24786] Changes in the devguide repository are not published online in HTML In-Reply-To: <1438640887.59.0.275627512221.issue24786@psf.upfronthosting.co.za> Message-ID: <1452349916.66.0.0750568417836.issue24786@psf.upfronthosting.co.za> Ezio Melotti added the comment: This seem to be already fixed, however the copyright needs to be updated again (see #26063). ---------- nosy: +ezio.melotti resolution: -> out of date stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 09:35:23 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 Jan 2016 14:35:23 +0000 Subject: [issue26063] Update copyright in the devguide In-Reply-To: <1452349837.88.0.575893993486.issue26063@psf.upfronthosting.co.za> Message-ID: <20160109143520.21384.23698@psf.io> Roundup Robot added the comment: New changeset ac2b3bafd41c by Ezio Melotti in branch 'default': #26063: update copyright. Patch by Chris Gonzalez. https://hg.python.org/devguide/rev/ac2b3bafd41c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 09:35:52 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 09 Jan 2016 14:35:52 +0000 Subject: [issue26063] Update copyright in the devguide In-Reply-To: <1452349837.88.0.575893993486.issue26063@psf.upfronthosting.co.za> Message-ID: <1452350152.06.0.24438800289.issue26063@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 09:38:20 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 09 Jan 2016 14:38:20 +0000 Subject: [issue26030] Use PEP8 in documentation examples In-Reply-To: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> Message-ID: <1452350300.55.0.416472909076.issue26030@psf.upfronthosting.co.za> Ezio Melotti added the comment: Without a list of places that don't follow the PEP8, I'm going to close this. ---------- resolution: -> not a bug status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 09:52:45 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 09 Jan 2016 14:52:45 +0000 Subject: [issue25170] 3.5.0 documentation archives missing In-Reply-To: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za> Message-ID: <1452351165.29.0.674231579609.issue25170@psf.upfronthosting.co.za> Ezio Melotti added the comment: https://www.python.org/ftp/python/doc/3.5.0/ now contains some files, but they seem to be for the ones for alpha 1 and 3. The dir for 3.5.1 is still missing. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 09:58:56 2016 From: report at bugs.python.org (Elena Oat) Date: Sat, 09 Jan 2016 14:58:56 +0000 Subject: [issue26001] Tutorial: write() does not expect string in binary mode In-Reply-To: <1451829375.45.0.0188699168911.issue26001@psf.upfronthosting.co.za> Message-ID: <1452351536.98.0.587783669489.issue26001@psf.upfronthosting.co.za> Elena Oat added the comment: Wrapped the lines to 80 chars. ---------- nosy: +Elena.Oat Added file: http://bugs.python.org/file41556/issue26001.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 11:02:58 2016 From: report at bugs.python.org (Julien) Date: Sat, 09 Jan 2016 16:02:58 +0000 Subject: [issue26030] Use PEP8 in documentation examples In-Reply-To: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> Message-ID: <1452355378.62.0.746354031634.issue26030@psf.upfronthosting.co.za> Julien added the comment: I opened this ticket mainly to know the opinions on those modifications, I'll slowly review what I see, and provide little patches from time to time, only when the PEP8 infringement look obvious. I think the most obvious PEP8 infringement ARE to be fixed, typically in the tutorial: The documentation is where people learn, let's teach them the right thing to do :-) Thanks to naoki I just learnt that no spaces around binary operators are OK when it enhance the readability (https://www.python.org/dev/peps/pep-0008/#other-recommendations) like 2*2 + 3*2. I close this ticket, I'll just mention if I propose a patch in a new one. Bests. ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 11:39:19 2016 From: report at bugs.python.org (Stefan Krah) Date: Sat, 09 Jan 2016 16:39:19 +0000 Subject: [issue25486] Resurrect inspect.getargspec() in 3.6 In-Reply-To: <1445891623.91.0.591196153919.issue25486@psf.upfronthosting.co.za> Message-ID: <1452357559.69.0.291233501518.issue25486@psf.upfronthosting.co.za> Stefan Krah added the comment: Could this be done soon? I ran into this just now: Traceback (most recent call last): File "", line 1, in File "/home/stefan/usr/lib/python3.6/site-packages/datashape-0.4.7-py3.6.egg/datashape/__init__.py", line 7, in from .user import * File "/home/stefan/usr/lib/python3.6/site-packages/datashape-0.4.7-py3.6.egg/datashape/user.py", line 16, in @dispatch(np.dtype, basetypes) File "/home/stefan/usr/lib/python3.6/site-packages/multipledispatch-0.4.8-py3.6.egg/multipledispatch/core.py", line 60, in _ if ismethod(func): File "/home/stefan/usr/lib/python3.6/site-packages/multipledispatch-0.4.8-py3.6.egg/multipledispatch/core.py", line 79, in ismethod spec = inspect.getargspec(func) AttributeError: module 'inspect' has no attribute 'getargspec' ---------- nosy: +rhettinger, skrah priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 11:44:27 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 09 Jan 2016 16:44:27 +0000 Subject: [issue25486] Resurrect inspect.getargspec() in 3.6 In-Reply-To: <1445891623.91.0.591196153919.issue25486@psf.upfronthosting.co.za> Message-ID: <1452357867.39.0.527776606388.issue25486@psf.upfronthosting.co.za> Berker Peksag added the comment: Perhaps we can also add it back in 3.5.2 since 3.5 is in early stages of its maintenance period? ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 11:45:30 2016 From: report at bugs.python.org (Stefan Krah) Date: Sat, 09 Jan 2016 16:45:30 +0000 Subject: [issue25486] Resurrect inspect.getargspec() in 3.6 In-Reply-To: <1445891623.91.0.591196153919.issue25486@psf.upfronthosting.co.za> Message-ID: <1452357930.15.0.0606078341909.issue25486@psf.upfronthosting.co.za> Stefan Krah added the comment: +1 for adding it to 3.5.2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 11:54:04 2016 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 09 Jan 2016 16:54:04 +0000 Subject: [issue25486] Resurrect inspect.getargspec() in 3.6 In-Reply-To: <1445891623.91.0.591196153919.issue25486@psf.upfronthosting.co.za> Message-ID: <1452358444.6.0.179176636617.issue25486@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Perhaps we can also add it back in 3.5.2 since 3.5 is in early stages of its maintenance period? > +1 for adding it to 3.5.2. I was never removed from 3.5 Python 3.5.1 (default, Dec 13 2015, 16:05:52) [GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import inspect >>> inspect.getargspec _______________________________________ From report at bugs.python.org Sat Jan 9 12:22:30 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 Jan 2016 17:22:30 +0000 Subject: [issue26029] Broken sentence in extending documentation In-Reply-To: <1452116648.24.0.989848174126.issue26029@psf.upfronthosting.co.za> Message-ID: <20160109172228.21382.67606@psf.io> Roundup Robot added the comment: New changeset 3f9b9244488d by Terry Jan Reedy in branch '3.5': Issue #26029: Finish correction. https://hg.python.org/cpython/rev/3f9b9244488d ---------- _______________________________________ Python tracker _______________________________________ From random832 at fastmail.com Fri Jan 8 23:09:08 2016 From: random832 at fastmail.com (Random832) Date: Fri, 08 Jan 2016 23:09:08 -0500 Subject: [issue26045] Improve error message for http.client when posting unicode string References: <1452205637.36.0.0359255361227.issue26045@psf.upfronthosting.co.za> <1452271510.56.0.590174120995.issue26045@psf.upfronthosting.co.za> Message-ID: <874mencs2j.fsf@fastmail.com> Guido van Rossum writes: > UnicodeEncodeError: 'ascii' codec can't encode character '\u1234' in ^ ^^^^^ > position 3: Header ('?') is not valid Latin-1. Use ^ ^^^^^^^ > header.encode('utf-8') if you want to send it encoded in UTF-8. Er... From report at bugs.python.org Sat Jan 9 12:58:15 2016 From: report at bugs.python.org (Brett Cannon) Date: Sat, 09 Jan 2016 17:58:15 +0000 Subject: [issue26062] IPython4 bash magic ! with {} does not work with Python 3.5.1 In-Reply-To: <1452349536.45.0.55048690622.issue26062@psf.upfronthosting.co.za> Message-ID: <1452362295.66.0.498993550841.issue26062@psf.upfronthosting.co.za> Brett Cannon added the comment: Python itself has nothing to do with IPython's shell commands (i.e., !). It would be best to report this bug to IPython to have them fix it on their end. ---------- nosy: +brett.cannon resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 13:03:02 2016 From: report at bugs.python.org (Brett Cannon) Date: Sat, 09 Jan 2016 18:03:02 +0000 Subject: [issue26058] Add dict.__version__ read-only property In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za> Message-ID: <1452362582.69.0.716285120568.issue26058@psf.upfronthosting.co.za> Brett Cannon added the comment: A better way to benchmark this is to run hg.python.org/benchmarks with a patched interpreter and see if that shows any performance impact. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 13:03:36 2016 From: report at bugs.python.org (Brett Cannon) Date: Sat, 09 Jan 2016 18:03:36 +0000 Subject: [issue26060] Class __dict__ iteration order changing due to type instance key-sharing In-Reply-To: <1452344171.87.0.895462140972.issue26060@psf.upfronthosting.co.za> Message-ID: <1452362616.13.0.043727638671.issue26060@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 13:04:25 2016 From: report at bugs.python.org (Brett Cannon) Date: Sat, 09 Jan 2016 18:04:25 +0000 Subject: [issue26060] Class __dict__ iteration order changing due to type instance key-sharing In-Reply-To: <1452344171.87.0.895462140972.issue26060@psf.upfronthosting.co.za> Message-ID: <1452362665.67.0.0523619615855.issue26060@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +beazley _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 13:25:26 2016 From: report at bugs.python.org (Sagar Kar) Date: Sat, 09 Jan 2016 18:25:26 +0000 Subject: [issue26064] directory is getting separated Message-ID: <1452363926.86.0.702790160127.issue26064@psf.upfronthosting.co.za> New submission from Sagar Kar: In [108]: os.mkdir('newdir') # make new dir In [140]: p = os.path.abspath('newdir') In [141]: p Out[141]: '/media/sagarkar10/sdrive/programing/python/SciPy/scipy-notebook/newdir' ## here 'newdir' is also a directory with a file inside In [143]: os.path.dirname(p) Out[143]: '/media/sagarkar10/sdrive/programing/python/SciPy/scipy-notebook' ## but os.path.dirname() dont show it under directory it treats as if its a file and till the last '/' is the directory and also In [145]: os.path.basename(p) Out[145]: 'newdir' ## basename shows it ---------- components: Extension Modules messages: 257849 nosy: sagarkar10 priority: normal severity: normal status: open title: directory is getting separated type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 13:30:53 2016 From: report at bugs.python.org (SilentGhost) Date: Sat, 09 Jan 2016 18:30:53 +0000 Subject: [issue26064] directory is getting separated In-Reply-To: <1452363926.86.0.702790160127.issue26064@psf.upfronthosting.co.za> Message-ID: <1452364253.44.0.667047218555.issue26064@psf.upfronthosting.co.za> SilentGhost added the comment: It behaves exactly as described in documentation, the only thing I could suggest is to re-read the following for details: https://docs.python.org/3/library/os.path.html#os.path.split ---------- nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 13:36:26 2016 From: report at bugs.python.org (=?utf-8?q?Christoph_B=C3=B6ddeker?=) Date: Sat, 09 Jan 2016 18:36:26 +0000 Subject: [issue26062] IPython4 bash magic ! with {} does not work with Python 3.5.1 In-Reply-To: <1452349536.45.0.55048690622.issue26062@psf.upfronthosting.co.za> Message-ID: <1452364586.31.0.567684163497.issue26062@psf.upfronthosting.co.za> Christoph B?ddeker added the comment: That's true. Now I have finde the reason. Someone has changed a function in lib/python3.5/string.py : _vformat. This function returns now a tuple (befor it was only one return value). IPython inherits from this object in lib/python3.5/site-packages/IPython/utils/text.py Because of this change the IPython code is not working. It seems to me, that this change in python is not nessesary. I don't, know how to find the commit, message who has changed this and why. Python 3.5.0: def _vformat( ..., auto_arg_index=0): ... format_spec = self._vformat( ..., auto_arg_index=auto_arg_index) ... return ''.join(result) Python 3.5.1: def _vformat( ..., auto_arg_index=0): ... format_spec, auto_arg_index = self._vformat( ..., auto_arg_index=auto_arg_index) ... return ''.join(result), auto_arg_index ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 13:44:48 2016 From: report at bugs.python.org (SilentGhost) Date: Sat, 09 Jan 2016 18:44:48 +0000 Subject: [issue26062] IPython4 bash magic ! with {} does not work with Python 3.5.1 In-Reply-To: <1452349536.45.0.55048690622.issue26062@psf.upfronthosting.co.za> Message-ID: <1452365088.04.0.172501250734.issue26062@psf.upfronthosting.co.za> SilentGhost added the comment: > It seems to me, that this change in python is not nessesary. > I don't, know how to find the commit, message who has changed this and why. It was done in issue 13598. It's a bit puzzling that IPython decided to depend on behaviour of a private method. I'd suggest you take it up with them. ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 13:54:49 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 09 Jan 2016 18:54:49 +0000 Subject: [issue26062] IPython4 bash magic ! with {} does not work with Python 3.5.1 In-Reply-To: <1452349536.45.0.55048690622.issue26062@psf.upfronthosting.co.za> Message-ID: <1452365689.71.0.839492937808.issue26062@psf.upfronthosting.co.za> Emanuel Barry added the comment: The choice of IPython to depend on a private, undocumented method means that they are subject to such bugs. A quick Google search tells me you should probably report the issue here: https://github.com/ipython/ipython/issues ---------- nosy: +ebarry status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 14:03:09 2016 From: report at bugs.python.org (=?utf-8?q?Christoph_B=C3=B6ddeker?=) Date: Sat, 09 Jan 2016 19:03:09 +0000 Subject: [issue26062] IPython4 bash magic ! with {} does not work with Python 3.5.1 In-Reply-To: <1452349536.45.0.55048690622.issue26062@psf.upfronthosting.co.za> Message-ID: <1452366189.73.0.875642428423.issue26062@psf.upfronthosting.co.za> Christoph B?ddeker added the comment: ok, thanks, I have opend there an issue https://github.com/ipython/ipython/issues/9120 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 14:15:02 2016 From: report at bugs.python.org (Laurent Dufrechou) Date: Sat, 09 Jan 2016 19:15:02 +0000 Subject: [issue26065] python embedded 3.5 amd64 crash when using venv Message-ID: <1452366902.23.0.484622853391.issue26065@psf.upfronthosting.co.za> New submission from Laurent Dufrechou: Install python-3.5.1-embed-amd64 to c:\dev\python-3.5.1-embed-amd64 Open terminal window: cd c:\dev\python-3.5.1-embed-amd64 python -m venv c:\dev\myenv -> crash Error: Command '['C:\\dev\\myenv\\Scripts\\python.exe', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 3221226505 Using debugger (VS2015) shows error: Exception non g?r?e ? 0x00007FFDA1D05A4E (ucrtbase.dll) dans python.exe? And stopping debugger leave this log: C:\dev\python-3.5.1-embed-amd64>python -m venv C:\dev\python35_x64_rtquickreport Traceback (most recent call last): File "runpy.py", line 170, in _run_module_as_main File "runpy.py", line 85, in _run_code File "venv\__main__.py", line 6, in File "venv\__init__.py", line 442, in main File "venv\__init__.py", line 85, in create File "venv\__init__.py", line 257, in _setup_pip File "subprocess.py", line 629, in check_output File "subprocess.py", line 698, in run File "subprocess.py", line 1055, in communicate KeyboardInterrupt ---------- components: Windows messages: 257855 nosy: Laurent Dufrechou, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: python embedded 3.5 amd64 crash when using venv type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 15:06:02 2016 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Sat, 09 Jan 2016 20:06:02 +0000 Subject: [issue26060] Class __dict__ iteration order changing due to type instance key-sharing In-Reply-To: <1452344171.87.0.895462140972.issue26060@psf.upfronthosting.co.za> Message-ID: <1452369962.12.0.78577219959.issue26060@psf.upfronthosting.co.za> Changes by Ionel Cristian M?rie? : ---------- nosy: +ionelmc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 15:06:27 2016 From: report at bugs.python.org (Mike Romberg) Date: Sat, 09 Jan 2016 20:06:27 +0000 Subject: [issue17633] zipimport's handling of namespace packages is incorrect In-Reply-To: <1365070223.85.0.365511954484.issue17633@psf.upfronthosting.co.za> Message-ID: <1452369987.15.0.419330175179.issue17633@psf.upfronthosting.co.za> Mike Romberg added the comment: This patch modifies issue17633-hg.diff by adding changes suggested by the reviewers. Note. I did cleanup the use of __import__ outside of the area involved with issue17633 as it seemed low risk. The tests for issue17633 (and the refactored doTest/makeZip now use addCleanup(). However there are still tests in the module that use the old try/finally way of cleanup. I did not modify these in order to keep this from being a rewrite of test_zipimport. But if more changes are desired, I'll add them. ---------- Added file: http://bugs.python.org/file41557/issue17633-hg-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 15:18:41 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 09 Jan 2016 20:18:41 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1452370721.71.0.876710015786.issue25677@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 15:19:22 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 09 Jan 2016 20:19:22 +0000 Subject: [issue18911] minidom does not encode correctly when calling Document.writexml In-Reply-To: <1378186619.58.0.930376227557.issue18911@psf.upfronthosting.co.za> Message-ID: <1452370762.39.0.818615297564.issue18911@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 15:20:05 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 09 Jan 2016 20:20:05 +0000 Subject: [issue25730] invisible sidebar content with code snippets In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za> Message-ID: <1452370805.04.0.9824084441.issue25730@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 15:21:18 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 09 Jan 2016 20:21:18 +0000 Subject: [issue25170] 3.5.0 documentation archives missing In-Reply-To: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za> Message-ID: <1452370878.67.0.438138355365.issue25170@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 15:41:56 2016 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 09 Jan 2016 20:41:56 +0000 Subject: [issue26066] Language on the "Cryptographic Services" is out of date Message-ID: <1452372116.19.0.623367169611.issue26066@psf.upfronthosting.co.za> New submission from Alex Gaynor: https://docs.python.org/2/library/crypto.html https://docs.python.org/3/library/crypto.html This language has a number of issues: - Crypto isn't just for "Hardcore cypherpunks" anymore, it's a necessary component of a great many software projects - PyCrypto isn't maintained by A.M. Kuchling any longer - (IMO) it's no longer the recommended library for cryptography in Python - The page should probably also point people towards the ssl module. ---------- assignee: docs at python components: Documentation messages: 257857 nosy: alex, docs at python priority: normal severity: normal status: open title: Language on the "Cryptographic Services" is out of date versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 15:42:04 2016 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 09 Jan 2016 20:42:04 +0000 Subject: [issue26066] Language on the "Cryptographic Services" documentation page is out of date In-Reply-To: <1452372116.19.0.623367169611.issue26066@psf.upfronthosting.co.za> Message-ID: <1452372124.01.0.453164948902.issue26066@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- title: Language on the "Cryptographic Services" is out of date -> Language on the "Cryptographic Services" documentation page is out of date _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 16:10:35 2016 From: report at bugs.python.org (Dinesh Wijekoon) Date: Sat, 09 Jan 2016 21:10:35 +0000 Subject: [issue26067] test_shutil fails when gid name is missing Message-ID: <1452373835.73.0.278108988814.issue26067@psf.upfronthosting.co.za> New submission from Dinesh Wijekoon: ./python.exe -m test -j3 -v test_shutil The above test fails when id name is missing. The fail message is group = grp.getgrgid(gid)[0] KeyError: 'getgrgid(): gid not found: 203135016' Following is the results from console "id" command, when the failure happens. uid=1336551206(athukora) gid=203135016 groups=203135016,402(com.apple.sharepoint.group.2),12(everyone),62(netaccounts),80(admin),401(com.apple.sharepoint.group.1),33(_appstore),98(_lpadmin),100(_lpoperator),204(_developer),398(com.apple.access_screensharing),399(com.apple.access_ssh) And again when I change user to sudo the "id" command returns the following and test get passed. uid=0(root) gid=0(wheel) groups=0(wheel),1(daemon),2(kmem),3(sys),4(tty),5(operator),8(procview),9(procmod),12(everyone),20(staff),29(certusers),61(localaccounts),80(admin),401(com.apple.sharepoint.group.1),402(com.apple.sharepoint.group.2),33(_appstore),98(_lpadmin),100(_lpoperator),204(_developer),398(com.apple.access_screensharing),399(com.apple.access_ssh) PS: We tried to debug this a bit and found the bug is possibly in Modules/grpmodule.c, may be at method grp_getgrall_impl. Adding "PyString_AsString(v);" before if command " PyList_Append(d, v) != 0" will fix the issue in test. But we have no idea how its working with this change. ---------- components: Extension Modules messages: 257858 nosy: Dinesh Wijekoon, ezio.melotti priority: normal severity: normal status: open title: test_shutil fails when gid name is missing versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 16:13:46 2016 From: report at bugs.python.org (Dinesh Wijekoon) Date: Sat, 09 Jan 2016 21:13:46 +0000 Subject: [issue26067] test_shutil fails when gid name is missing In-Reply-To: <1452373835.73.0.278108988814.issue26067@psf.upfronthosting.co.za> Message-ID: <1452374026.35.0.123711009191.issue26067@psf.upfronthosting.co.za> Dinesh Wijekoon added the comment: This reported bug occurred in Mac OS. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 16:18:18 2016 From: report at bugs.python.org (ThiefMaster) Date: Sat, 09 Jan 2016 21:18:18 +0000 Subject: [issue26068] re.compile() repr end quote truncated Message-ID: <1452374298.65.0.166509982693.issue26068@psf.upfronthosting.co.za> New submission from ThiefMaster: ``` Python 3.4.3 (default, Jan 5 2016, 23:13:10) [GCC 4.7.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> for n in range(198, 201): ... print(re.compile('x' * n)) ... re.compile('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx') re.compile('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) re.compile('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) ``` The closing quote in the repr goes away once the regex exceeds a certain length. This smells like an off-by-one somewhere that results in the last character to be lost. In any case, it's pretty ugly since the repr clearly pretends to be executable Python code, which is not the case anymore with this quote missing. ---------- components: Regular Expressions messages: 257860 nosy: ThiefMaster, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: re.compile() repr end quote truncated versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 16:27:36 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 09 Jan 2016 21:27:36 +0000 Subject: [issue26068] re.compile() repr end quote truncated In-Reply-To: <1452374298.65.0.166509982693.issue26068@psf.upfronthosting.co.za> Message-ID: <1452374856.38.0.945595721823.issue26068@psf.upfronthosting.co.za> Guido van Rossum added the comment: It's simply the effect of the "%.200R" format here: https://hg.python.org/cpython/file/default/Modules/_sre.c#l1417 I recommend not bothering to fix this: it would just be more code, and to what end? ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 16:28:30 2016 From: report at bugs.python.org (Krista Paasonen) Date: Sat, 09 Jan 2016 21:28:30 +0000 Subject: [issue24823] ctypes.create_string_buffer does not add NUL if len(init) == size In-Reply-To: <1438942688.18.0.266077254276.issue24823@psf.upfronthosting.co.za> Message-ID: <1452374910.28.0.234707091134.issue24823@psf.upfronthosting.co.za> Krista Paasonen added the comment: Patch containing checking for buffer size, so that NULL value is the last byte as C standard specifies. Raises ValueError exception if initial value does not fit into to the buffer with NULL char. This should decrease the possibility of creating security issues. ---------- keywords: +patch nosy: +krista Added file: http://bugs.python.org/file41558/create_string_buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 16:30:12 2016 From: report at bugs.python.org (ThiefMaster) Date: Sat, 09 Jan 2016 21:30:12 +0000 Subject: [issue26068] re.compile() repr end quote truncated In-Reply-To: <1452374298.65.0.166509982693.issue26068@psf.upfronthosting.co.za> Message-ID: <1452375012.36.0.405319089903.issue26068@psf.upfronthosting.co.za> ThiefMaster added the comment: I think it's pretty ugly to have a repr that is valid python code in most cases and suddenly stops being so. The repr of a string is not truncated, so why truncate it in a pattern object? With the truncation, why not use a repr style that's clearly not executable to recreate the original object, e.g. `` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 16:39:21 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 09 Jan 2016 21:39:21 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1452375561.82.0.444558441918.issue25677@psf.upfronthosting.co.za> Martin Panter added the comment: +script = textwrap.dedent("1 + 1 = 2\n") You don?t need that first textwrap.dedent() call. It is only useful if the string has extra indentation at the start, as in the second multiline one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 16:39:30 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sat, 09 Jan 2016 21:39:30 +0000 Subject: [issue26068] re.compile() repr end quote truncated In-Reply-To: <1452374298.65.0.166509982693.issue26068@psf.upfronthosting.co.za> Message-ID: <1452375570.99.0.855885499651.issue26068@psf.upfronthosting.co.za> Emanuel Barry added the comment: Truncating at 200 characters is actually a common occurrence in the C code, just barely anyone notice this, as it's not common to need more than 200 characters for most expressions. I don't think this needs to be changed at all; the rare case should not affect the common ones. If eval()'ing your repr fails, you can always access the full regex from `exp.pattern` - which doesn't truncate at 200 characters :) ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 16:40:42 2016 From: report at bugs.python.org (ThiefMaster) Date: Sat, 09 Jan 2016 21:40:42 +0000 Subject: [issue26068] re.compile() repr end quote truncated In-Reply-To: <1452374298.65.0.166509982693.issue26068@psf.upfronthosting.co.za> Message-ID: <1452375642.91.0.690040946231.issue26068@psf.upfronthosting.co.za> ThiefMaster added the comment: Not eval'ing it, just wondered why the repr looks so weird when printing an object containing a compiled regex ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 16:42:04 2016 From: report at bugs.python.org (Matthew Barnett) Date: Sat, 09 Jan 2016 21:42:04 +0000 Subject: [issue26068] re.compile() repr end quote truncated In-Reply-To: <1452374298.65.0.166509982693.issue26068@psf.upfronthosting.co.za> Message-ID: <1452375724.79.0.146242379309.issue26068@psf.upfronthosting.co.za> Matthew Barnett added the comment: I'm going to have to agree with ThiefMaster. String literals don't truncate like that, nor do lists, nor tuples. Are there any similar cases of truncation elsewhere in the standard library? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 16:44:43 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 09 Jan 2016 21:44:43 +0000 Subject: [issue26068] re.compile() repr end quote truncated In-Reply-To: <1452375724.79.0.146242379309.issue26068@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Yes, the C code pretty much always uses %., in order to protect itself from buffer overflows. Pulling off an unabbreviated str() here would be a major piece of work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 16:46:07 2016 From: report at bugs.python.org (ThiefMaster) Date: Sat, 09 Jan 2016 21:46:07 +0000 Subject: [issue26068] re.compile() repr end quote truncated In-Reply-To: <1452374298.65.0.166509982693.issue26068@psf.upfronthosting.co.za> Message-ID: <1452375967.03.0.142490103305.issue26068@psf.upfronthosting.co.za> ThiefMaster added the comment: Would it be possible to preserve the quotes even in case of truncation? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 16:47:02 2016 From: report at bugs.python.org (Michael Layzell) Date: Sat, 09 Jan 2016 21:47:02 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1452376022.51.0.303942764781.issue25677@psf.upfronthosting.co.za> Michael Layzell added the comment: Oops. Should be fixed now. ---------- Added file: http://bugs.python.org/file41559/cpython25677.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 16:51:10 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 09 Jan 2016 21:51:10 +0000 Subject: [issue26068] re.compile() repr end quote truncated In-Reply-To: <1452375967.03.0.142490103305.issue26068@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: That would be an interesting exercise. You'd have to patch PyUnicode_FromFormat(). It would be nice to have this. It should probably also insert some dots (the universal sign to indicate that something was truncated). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 17:05:09 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 09 Jan 2016 22:05:09 +0000 Subject: [issue26030] Use PEP8 in documentation examples In-Reply-To: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> Message-ID: <1452377109.95.0.661260296661.issue26030@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 17:11:52 2016 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 09 Jan 2016 22:11:52 +0000 Subject: [issue26060] Class __dict__ iteration order changing due to type instance key-sharing In-Reply-To: <1452344171.87.0.895462140972.issue26060@psf.upfronthosting.co.za> Message-ID: <1452377512.07.0.303859031178.issue26060@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 17:12:15 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 09 Jan 2016 22:12:15 +0000 Subject: [issue26063] Update copyright in the devguide In-Reply-To: <1452349837.88.0.575893993486.issue26063@psf.upfronthosting.co.za> Message-ID: <1452377535.93.0.562104203112.issue26063@psf.upfronthosting.co.za> Berker Peksag added the comment: I'd prefer a more general solution similar to the one has been used in Doc/conf.py copyright = u'1990-%s, Python Software Foundation' % time.strftime('%Y') ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 17:33:24 2016 From: report at bugs.python.org (Steve Dower) Date: Sat, 09 Jan 2016 22:33:24 +0000 Subject: [issue26065] python embedded 3.5 amd64 crash when using venv In-Reply-To: <1452366902.23.0.484622853391.issue26065@psf.upfronthosting.co.za> Message-ID: <1452378804.95.0.12381535997.issue26065@psf.upfronthosting.co.za> Steve Dower added the comment: I can't read those error messages, but I suspect this is because some of the bundled files are omitted from the embeddable package. Using it to run venv isn't really part of the intended use cases - it's expected you'll manually install packages alongside it with your own installer. If that doesn't sound suitable for what you're trying to do, you should use the installers to install Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 17:40:15 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sat, 09 Jan 2016 22:40:15 +0000 Subject: [issue26063] Update copyright in the devguide In-Reply-To: <1452377535.93.0.562104203112.issue26063@psf.upfronthosting.co.za> Message-ID: <20160109224012.GA5852@sg1> St?phane Wirtel added the comment: +1 ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 17:42:34 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 09 Jan 2016 22:42:34 +0000 Subject: [issue26058] Add dict.__version__ read-only property In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za> Message-ID: <1452379354.54.0.737099858163.issue26058@psf.upfronthosting.co.za> STINNER Victor added the comment: Brett: > A better way to benchmark this is to run hg.python.org/benchmarks with a patched interpreter and see if that shows any performance impact. Ok. Here is the output. Can you please explain me the result? :-) Especially the "significant" value. $ ./python.orig ../benchmarks/perf.py ./python.orig ./python.patched INFO:root:Automatically selected timer: perf_counter INFO:root:Running `./python.patched ../benchmarks/lib3/2to3/2to3 -f all ../benchmarks/lib/2to3` INFO:root:Running `./python.patched ../benchmarks/lib3/2to3/2to3 -f all ../benchmarks/lib/2to3` 1 time INFO:root:Running `./python.orig ../benchmarks/lib3/2to3/2to3 -f all ../benchmarks/lib/2to3` INFO:root:Running `./python.orig ../benchmarks/lib3/2to3/2to3 -f all ../benchmarks/lib/2to3` 1 time INFO:root:Running `./python.patched ../benchmarks/performance/bm_chameleon_v2.py -n 50 --timer perf_counter` INFO:root:Running `./python.orig ../benchmarks/performance/bm_chameleon_v2.py -n 50 --timer perf_counter` INFO:root:Running `./python.patched ../benchmarks/performance/bm_django_v3.py -n 50 --timer perf_counter` INFO:root:Running `./python.orig ../benchmarks/performance/bm_django_v3.py -n 50 --timer perf_counter` INFO:root:Running `./python.patched ../benchmarks/performance/bm_pickle.py -n 50 --timer perf_counter --use_cpickle pickle` INFO:root:Running `./python.orig ../benchmarks/performance/bm_pickle.py -n 50 --timer perf_counter --use_cpickle pickle` INFO:root:Running `./python.patched ../benchmarks/performance/bm_pickle.py -n 50 --timer perf_counter --use_cpickle unpickle` INFO:root:Running `./python.orig ../benchmarks/performance/bm_pickle.py -n 50 --timer perf_counter --use_cpickle unpickle` INFO:root:Running `./python.patched ../benchmarks/performance/bm_json_v2.py -n 50 --timer perf_counter` INFO:root:Running `./python.orig ../benchmarks/performance/bm_json_v2.py -n 50 --timer perf_counter` INFO:root:Running `./python.patched ../benchmarks/performance/bm_json.py -n 50 --timer perf_counter json_load` INFO:root:Running `./python.orig ../benchmarks/performance/bm_json.py -n 50 --timer perf_counter json_load` INFO:root:Running `./python.patched ../benchmarks/performance/bm_nbody.py -n 50 --timer perf_counter` INFO:root:Running `./python.orig ../benchmarks/performance/bm_nbody.py -n 50 --timer perf_counter` INFO:root:Running `./python.patched ../benchmarks/performance/bm_regex_v8.py -n 50 --timer perf_counter` INFO:root:Running `./python.orig ../benchmarks/performance/bm_regex_v8.py -n 50 --timer perf_counter` INFO:root:Running `./python.patched ../benchmarks/performance/bm_tornado_http.py -n 100 --timer perf_counter` INFO:root:Running `./python.orig ../benchmarks/performance/bm_tornado_http.py -n 100 --timer perf_counter` [ 1/10] 2to3... [ 2/10] chameleon_v2... [ 3/10] django_v3... [ 4/10] fastpickle... [ 5/10] fastunpickle... [ 6/10] json_dump_v2... [ 7/10] json_load... [ 8/10] nbody... [ 9/10] regex_v8... [10/10] tornado_http... Report on Linux smithers 4.2.8-300.fc23.x86_64 #1 SMP Tue Dec 15 16:49:06 UTC 2015 x86_64 x86_64 Total CPU cores: 8 ### 2to3 ### 6.825440 -> 6.996616: 1.03x slower ### fastpickle ### Min: 0.449710 -> 0.458054: 1.02x slower Avg: 0.451589 -> 0.583100: 1.29x slower Significant (t=-8.04) Stddev: 0.00076 -> 0.11568: 152.3886x larger ### fastunpickle ### Min: 0.549672 -> 0.545734: 1.01x faster Avg: 0.551284 -> 0.696920: 1.26x slower Significant (t=-6.65) Stddev: 0.00118 -> 0.15493: 130.9694x larger ### json_load ### Min: 0.432500 -> 0.466602: 1.08x slower Avg: 0.433771 -> 0.471205: 1.09x slower Significant (t=-10.63) Stddev: 0.00495 -> 0.02440: 4.9303x larger ### nbody ### Min: 0.230055 -> 0.234925: 1.02x slower Avg: 0.230985 -> 0.236441: 1.02x slower Significant (t=-7.56) Stddev: 0.00048 -> 0.00508: 10.5095x larger The following not significant results are hidden, use -v to show them: chameleon_v2, django_v3, json_dump_v2, regex_v8, tornado_http. ---------- versions: +Python 2.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 18:55:18 2016 From: report at bugs.python.org (Eryk Sun) Date: Sat, 09 Jan 2016 23:55:18 +0000 Subject: [issue24823] ctypes.create_string_buffer does not add NUL if len(init) == size In-Reply-To: <1438942688.18.0.266077254276.issue24823@psf.upfronthosting.co.za> Message-ID: <1452383718.53.0.00963215008562.issue24823@psf.upfronthosting.co.za> Eryk Sun added the comment: I didn't want to change the function in lieu of breaking someone's code. If this change is accepted, then it at least needs a documentation note to indicate the new behavior. ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 18:56:47 2016 From: report at bugs.python.org (Eryk Sun) Date: Sat, 09 Jan 2016 23:56:47 +0000 Subject: [issue24823] ctypes.create_string_buffer does not add NUL if len(init) == size In-Reply-To: <1438942688.18.0.266077254276.issue24823@psf.upfronthosting.co.za> Message-ID: <1452383807.32.0.408333932263.issue24823@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- components: +Documentation, Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 19:16:44 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sun, 10 Jan 2016 00:16:44 +0000 Subject: [issue26060] Class __dict__ iteration order changing due to type instance key-sharing In-Reply-To: <1452344171.87.0.895462140972.issue26060@psf.upfronthosting.co.za> Message-ID: <1452385004.12.0.00572553940656.issue26060@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 19:20:26 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 10 Jan 2016 00:20:26 +0000 Subject: [issue26069] Remove the Deprecated API in trace module Message-ID: <1452385226.89.0.6584761467.issue26069@psf.upfronthosting.co.za> New submission from Senthil Kumaran: A number of old methods in trace module were deprecated in issue10371. They should be removed in 3.6 release. ---------- components: Library (Lib) messages: 257877 nosy: belopolsky, orsenthil priority: normal severity: normal stage: needs patch status: open title: Remove the Deprecated API in trace module type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 19:59:35 2016 From: report at bugs.python.org (Mark Hammond) Date: Sun, 10 Jan 2016 00:59:35 +0000 Subject: [issue26070] Launcher fails to find in-place built binaries from earlier Python versions Message-ID: <1452387575.38.0.184373942558.issue26070@psf.upfronthosting.co.za> New submission from Mark Hammond: The launcher was recently updated to look in PCBuild/win32 to support the win32 binaries being built in this directory instead of the top-level PCBuild directory. However, when this new launcher tries to find a binary for, say, Python 2.7, it doesn't find an executable because it's directly in PCBuild, not one of the win32 or amd64 sub-directories. Note this only impacts Python when it is built in the directory - it doesn't impact installed versions. The fix I came up with is to continue looking in PCBuild if it isn't found in one of those dirs. Vinay, what do you think? ---------- components: Windows files: launcher.patch keywords: patch messages: 257878 nosy: mhammond, paul.moore, steve.dower, tim.golden, vinay.sajip, zach.ware priority: normal severity: normal status: open title: Launcher fails to find in-place built binaries from earlier Python versions type: behavior versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41560/launcher.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 20:06:48 2016 From: report at bugs.python.org (Mark Hammond) Date: Sun, 10 Jan 2016 01:06:48 +0000 Subject: [issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons Message-ID: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za> New submission from Mark Hammond: Binaries created by bdist_wininst fail on 3.5+ for 2 reasons: * The built binary links against the DLL version of the CRT. This means the binary will typically fail to start as the CRT DLL isn't found. * When looking for 32bit Python versions, it fails to take the recent "-32" change for the registry key, so it tells you no Python is installed. This patch: * Uses the static CRT, which IIRC, was the case in previous Python versions. * Changes directory to the directory with pythonxx.dll before attempting to loadlibrary it - this allows the loadlibrary to succeed as the CRT DLL in that directory is found. * Appends "-32" to registry keys on 32bit builds. With these patches I can successfully get a pywin32 build working and installing. Steve (or anyone), what do you think? (Note that the attached patch does *not* include a newly built wininst-14.exe, but that would obviously need to be updated before checking in.) ---------- components: Windows files: bdist.patch keywords: patch messages: 257879 nosy: mhammond, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: bdist_wininst created binaries fail to start and find 32bit Pythons type: behavior versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41561/bdist.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 20:07:19 2016 From: report at bugs.python.org (Brett Cannon) Date: Sun, 10 Jan 2016 01:07:19 +0000 Subject: [issue26058] Add dict.__version__ read-only property In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za> Message-ID: <1452388039.55.0.280642550006.issue26058@psf.upfronthosting.co.za> Brett Cannon added the comment: So min is the fastest time in a benchmark execution, average is the average across all benchmark executions, and the t-value is some statistics thing. Anything marked insignificant had such a small average difference it isn't worth reporting. If you want to smooth out the numbers you should do a rigorous run that uses more loops per benchmark to help smooth out outliers. And if you are doing this on Linux there is a flag to measure memory usage as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 21:33:06 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 10 Jan 2016 02:33:06 +0000 Subject: [issue26069] Remove the Deprecated API in trace module In-Reply-To: <1452385226.89.0.6584761467.issue26069@psf.upfronthosting.co.za> Message-ID: <1452393186.97.0.818613678823.issue26069@psf.upfronthosting.co.za> Senthil Kumaran added the comment: This patch removes the deprecated apis from 3.6. After getting a review from one another core dev, I will commit this. * No doc changes are required as the deprecated apis were not documented. * README will be added during commit. ---------- assignee: -> orsenthil stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 22:06:13 2016 From: report at bugs.python.org (Eryk Sun) Date: Sun, 10 Jan 2016 03:06:13 +0000 Subject: [issue26065] python embedded 3.5 amd64 crash when using venv In-Reply-To: <1452366902.23.0.484622853391.issue26065@psf.upfronthosting.co.za> Message-ID: <1452395173.9.0.51200090429.issue26065@psf.upfronthosting.co.za> Eryk Sun added the comment: 0xC0000409 (3221226505) is STATUS_STACK_BUFFER_OVERRUN due to the CRT calling __fastfail(FAST_FAIL_FATAL_APP_EXIT) in abort(). This is expected behavior in Windows 8+ [1]. Initially I couldn't reproduce this error because Python found the standard library from the system Python via the registry. After archiving (as .reg) and removing the key "HKLM\SOFTWARE\Python\PythonCore\3.5", I reproduced the problem as follows: C:\Temp>myenv\Scripts\python.exe -Im ensurepip --upgrade --default-pip Fatal Python error: Py_Initialize: unable to load the file system codec ImportError: No module named 'encodings' Current thread 0x00000b9c (most recent call first): venv didn't copy over python35.zip to the Scripts directory. I don't know whether there's ever a legitimate reason to look for and copy a zipped standard library, or whether venv is only supported for use with a standard Python installation. I don't recommend doing this, but if you create the environment --without-pip, the command 'succeeds'. Then you'll have to manually copy python35.zip to Scripts and obtain activate.bat (edit this) and deactivate.bat from another install or the web. You still won't have ensurepip. If you want pip and setuptools, use get-pip.py from the web. This is all probably more trouble than you want. However, the embedding distribution is not intended to be a full Python installation that's suitable for development. [1]: https://msdn.microsoft.com/en-us/library/dn774154 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 22:09:16 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sun, 10 Jan 2016 03:09:16 +0000 Subject: [issue26069] Remove the Deprecated API in trace module In-Reply-To: <1452385226.89.0.6584761467.issue26069@psf.upfronthosting.co.za> Message-ID: <1452395356.61.0.424379989495.issue26069@psf.upfronthosting.co.za> Emanuel Barry added the comment: You seem to have forgotten to include a patch. ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 23:16:37 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 10 Jan 2016 04:16:37 +0000 Subject: [issue26069] Remove the Deprecated API in trace module In-Reply-To: <1452385226.89.0.6584761467.issue26069@psf.upfronthosting.co.za> Message-ID: <1452399397.91.0.233759999527.issue26069@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Sorry for that. Here is the patch. ---------- keywords: +patch Added file: http://bugs.python.org/file41562/issue26069.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 23:18:01 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 10 Jan 2016 04:18:01 +0000 Subject: [issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za> Message-ID: <1452399481.07.0.755950253655.issue26071@psf.upfronthosting.co.za> Steve Dower added the comment: Looks good to me. Feel free to check it in, Mark, or one of us will get to it if you're not set up for committing right now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 23:21:18 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 10 Jan 2016 04:21:18 +0000 Subject: [issue26070] Launcher fails to find in-place built binaries from earlier Python versions In-Reply-To: <1452387575.38.0.184373942558.issue26070@psf.upfronthosting.co.za> Message-ID: <1452399678.94.0.632132681718.issue26070@psf.upfronthosting.co.za> Steve Dower added the comment: I don't think Vinay does much wrt the launcher in core anymore, it's mostly been me recently. I don't see any harm in this change, though I'll admit I also don't see the point. When is the launcher ever going to find Python built in-place? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 23:37:47 2016 From: report at bugs.python.org (Eryk Sun) Date: Sun, 10 Jan 2016 04:37:47 +0000 Subject: [issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za> Message-ID: <1452400667.92.0.951259086827.issue26071@psf.upfronthosting.co.za> Eryk Sun added the comment: I would call SetDllDirectory instead of changing the current directory. This replaces the current directory in the DLL search. Then call SetDllDirectory(NULL) to restore the default before returning. When you say "the CRT assembly", you're talking about vcruntime140.dll, right? This module implements exceptions, setjmp/longjmp, and other functions that are closely coupled with the VC++ version, but most of the universal CRT is implemented in the system DLL ucrtbase.dll. vcruntime was initially linked statically everywhere, but that was a problem for extension modules, since each instance was taking a fiber locale storage slot. However, it really should be static for the bdist_wininst installer. I believe Steve had the link configuration customized as a partially static build that linked dynamically with ucrtbase.dll. This benefits from continuous CRT bug fixes and security updates. To configure this he added ucrt[d].lib as a dependency and ignored the default library libucrt[d].lib. See the following diff for the changes that were made to revert this: https://hg.python.org/cpython/diff/8374472c6a6e/PCbuild/pyproject.props ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 00:16:24 2016 From: report at bugs.python.org (Antony Lee) Date: Sun, 10 Jan 2016 05:16:24 +0000 Subject: [issue26072] pdb fails to access variables closed over Message-ID: <1452402984.12.0.000738362264887.issue26072@psf.upfronthosting.co.za> New submission from Antony Lee: Consider the following example: def f(x=1): def g(): y = 2 raise Exception g() f() $ python -mpdb -ccontinue example.py <... traceback ...> > /tmp/example.py(4)g() -> raise Exception (Pdb) p x ##### this can be worked around using "up" *** NameError: name 'x' is not defined (Pdb) p y 2 (Pdb) p (lambda: y)() ##### this is more awkward to work around, e.g. (lambda *, y=y: y)() *** NameError: name 'y' is not defined Use case: I wan to pass a lambda to a numerical optimizer, but the optimizer fails using the default starting point. Within pdb, I'd like to pass a different starting point but the same lambda, to see whether this helps. ---------- components: Library (Lib) messages: 257888 nosy: Antony.Lee priority: normal severity: normal status: open title: pdb fails to access variables closed over versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 01:10:45 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 10 Jan 2016 06:10:45 +0000 Subject: [issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za> Message-ID: <1452406245.23.0.139810263119.issue26071@psf.upfronthosting.co.za> Steve Dower added the comment: In this case, it needs to load vcruntime for the python##.dll, so linking isn't going to make any difference. We need to statically link the loader, since it will be run independently and can't have any dependencies, but when it finds a Python install and loads the DLL directly it's not finding the vcruntime adjacent to the DLL. We'd have to statically link python##.dll. SetDllDirectory would also work, though it's a little more complicated to get right. It's probably worth it here though to set the search path around the load in this case, as we know that nobody else is expecting the value to not change. However, it may break other loads if python##.dll calls it or makes assumptions about the search path (which it almost certainly does). Setting the working directory is likely to lead to a more reliable initial state. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 01:30:56 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 10 Jan 2016 06:30:56 +0000 Subject: [issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title In-Reply-To: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za> Message-ID: <1452407456.59.0.405577221599.issue23675@psf.upfronthosting.co.za> Senthil Kumaran added the comment: @Martin, thanks for the review comments. I've addressed this is version 2 of the patch. I am submitting this change. ---------- versions: +Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41563/Issue23675-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 01:34:55 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jan 2016 06:34:55 +0000 Subject: [issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title In-Reply-To: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za> Message-ID: <20160110063451.47395.13108@psf.io> Roundup Robot added the comment: New changeset 9ba001cb107b by Senthil Kumaran in branch '3.5': Issue23675 - A tiny clarification in the MRO glossary term. https://hg.python.org/cpython/rev/9ba001cb107b New changeset 60d4c3a29201 by Senthil Kumaran in branch 'default': merge from 3.5 https://hg.python.org/cpython/rev/60d4c3a29201 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 01:36:20 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jan 2016 06:36:20 +0000 Subject: [issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title In-Reply-To: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za> Message-ID: <20160110063618.27386.59050@psf.io> Roundup Robot added the comment: New changeset 99f5276e4197 by Senthil Kumaran in branch '2.7': Issue23675 - A tiny clarification in the MRO glossary term. https://hg.python.org/cpython/rev/99f5276e4197 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 01:37:15 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 10 Jan 2016 06:37:15 +0000 Subject: [issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title In-Reply-To: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za> Message-ID: <1452407835.22.0.162749708433.issue23675@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Fixed in the active documentation branches 2.7,3.5 and 3.6. ---------- assignee: docs at python -> orsenthil resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 02:23:12 2016 From: report at bugs.python.org (Eryk Sun) Date: Sun, 10 Jan 2016 07:23:12 +0000 Subject: [issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za> Message-ID: <1452410592.32.0.529671510233.issue26071@psf.upfronthosting.co.za> Eryk Sun added the comment: > We'd have to statically link python##.dll. I was talking about the partially static build that you used for wininst-14.0-amd64.exe in rc3, in which vcruntime is linked statically but ucrt is linked dynamically (actually to the api-ms-win-crt-* API sets). But is there a bad assumption there? I was only thinking about installing to systems with Python 3.5+, on which ucrtbase.dll is guaranteed to be in System32, but this installer should work for older systems that don't have the universal CRT update, right? > However, it may break other loads if python##.dll calls it or > makes assumptions about the search path I don't understand. It would be pretty broken if python##.dll depends on the current directory. All SetDllDirectory does is swap in the target directory in place of the current directory in the DLL search path. I made the suggestion because it's cleaner to surgically change only what the system loader sees, rather than changing the current directory, which affects everything. The LoadLibrary docs recommend using SetDllDirectory instead of changing the current directory. Using AddDllDirectory would be better, but that's only available on updated Vista/7 systems (KB2533623). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 02:43:26 2016 From: report at bugs.python.org (Eryk Sun) Date: Sun, 10 Jan 2016 07:43:26 +0000 Subject: [issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za> Message-ID: <1452411806.56.0.462678015676.issue26071@psf.upfronthosting.co.za> Eryk Sun added the comment: Steve, I think I understand the linking problem now -- in terms of the bad assumption I mentioned in the previous message. Mark said the "built binary links against the DLL version of the CRT", but I just checked in 3.5.1 that you actually didn't switch that one to link against vcruntime140.dll like you did with everything else, so he's only referring to the api-set-ms-win-crt dependencies. This would only fail on systems that don't have the universal CRT update. I thought he meant the executable was typically failing on all systems that don't have Visual Studio, which installs vcruntime140.dll in System32. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 02:49:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Jan 2016 07:49:54 +0000 Subject: [issue26073] Update the list of magic numbers in launcher Message-ID: <1452412193.99.0.751958856998.issue26073@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: There is a list of magic numbers in PC/launcher.c for mapping magic number to Python version. But it ends on 3.3 (and even only on 3.3a0). Proposed patch updates the list (by values taken from Lib/importlib/_bootstrap_external.py). ---------- components: Windows files: launcher_magic_numbers.patch keywords: patch messages: 257896 nosy: brett.cannon, eric.snow, ncoghlan, paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: patch review status: open title: Update the list of magic numbers in launcher type: behavior versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41564/launcher_magic_numbers.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 02:55:57 2016 From: report at bugs.python.org (Mark Hammond) Date: Sun, 10 Jan 2016 07:55:57 +0000 Subject: [issue26070] Launcher fails to find in-place built binaries from earlier Python versions In-Reply-To: <1452387575.38.0.184373942558.issue26070@psf.upfronthosting.co.za> Message-ID: <1452412557.83.0.452691007947.issue26070@psf.upfronthosting.co.za> Mark Hammond added the comment: > When is the launcher ever going to find Python built in-place? On the machine that built Python in-place :) I have a dev environment where all Python versions and pywin32 are built and that's the environment where py.exe is failing. My build scripts use py.exe to build for a specific Python version. It sounds like you are fine with it, so I'll try and work out how to get a new key up and push it unless I hear otherwise, thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 02:56:52 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jan 2016 07:56:52 +0000 Subject: [issue26066] Language on the "Cryptographic Services" documentation page is out of date In-Reply-To: <1452372116.19.0.623367169611.issue26066@psf.upfronthosting.co.za> Message-ID: <20160110075649.1023.68472@psf.io> Roundup Robot added the comment: New changeset 84fdbdd483a3 by Benjamin Peterson in branch '2.7': delete old crypto prose (closes #26066) https://hg.python.org/cpython/rev/84fdbdd483a3 New changeset d8944e059c7f by Benjamin Peterson in branch '3.4': delete old crypto prose (closes #26066) https://hg.python.org/cpython/rev/d8944e059c7f New changeset cc9ffb4829e7 by Benjamin Peterson in branch '3.5': merge 3.4 (#26066) https://hg.python.org/cpython/rev/cc9ffb4829e7 New changeset 8ee02ec9b634 by Benjamin Peterson in branch 'default': merge 3.5 (#26066) https://hg.python.org/cpython/rev/8ee02ec9b634 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 03:05:08 2016 From: report at bugs.python.org (Mark Hammond) Date: Sun, 10 Jan 2016 08:05:08 +0000 Subject: [issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za> Message-ID: <1452413108.02.0.472945608241.issue26071@psf.upfronthosting.co.za> Mark Hammond added the comment: > Mark said the "built binary links against the DLL version of the CRT > but I just checked in 3.5.1 that you actually didn't switch that > one to link against vcruntime140.dll like you did with everything else Yeah, I didn't dig too much further here, but I'm fairly sure that "static crt" has been a thing for quite a while now for that stub (there are comments about that around the SetStdHandle calls in that file). I suspect it was accidentally lost in one of the build system fixups that happened (which seem great and a vast improvement!) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 03:48:49 2016 From: report at bugs.python.org (Elena Oat) Date: Sun, 10 Jan 2016 08:48:49 +0000 Subject: [issue25986] Collections.deque maxlen: added in 2.6 or 2.7? In-Reply-To: <1451681300.68.0.792062287695.issue25986@psf.upfronthosting.co.za> Message-ID: <1452415729.36.0.13122310154.issue25986@psf.upfronthosting.co.za> Elena Oat added the comment: I checked and 2.6 python has maxlen as a parameter, but not a maxlen attribute. The maxlen attribute was added in 2.7. ---------- nosy: +Elena.Oat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 03:51:26 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 10 Jan 2016 08:51:26 +0000 Subject: [issue25986] Collections.deque maxlen: added in 2.6 or 2.7? In-Reply-To: <1451681300.68.0.792062287695.issue25986@psf.upfronthosting.co.za> Message-ID: <1452415886.15.0.287358843697.issue25986@psf.upfronthosting.co.za> Ezio Melotti added the comment: Thanks for checking. Closing. ---------- nosy: +ezio.melotti resolution: -> not a bug stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 05:03:28 2016 From: report at bugs.python.org (Vinay Sajip) Date: Sun, 10 Jan 2016 10:03:28 +0000 Subject: [issue26070] Launcher fails to find in-place built binaries from earlier Python versions In-Reply-To: <1452387575.38.0.184373942558.issue26070@psf.upfronthosting.co.za> Message-ID: <1452420208.31.0.473227557702.issue26070@psf.upfronthosting.co.za> Vinay Sajip added the comment: Hey, Steve, don't shut me out, I'm still here ;-) I've had a heavy consulting load for the past year or so which means I can't always deal with issues as quickly as before. If someone else fixes issues before I get to them, it's fine by me :-) IMO the proposed change by Mark seems reasonable. It's really only for us devs anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 05:52:00 2016 From: report at bugs.python.org (Blaize Rhodes) Date: Sun, 10 Jan 2016 10:52:00 +0000 Subject: [issue26074] Add a method to pip.. pip.require("package_name") Message-ID: <1452423120.4.0.471254538905.issue26074@psf.upfronthosting.co.za> New submission from Blaize Rhodes: The idea is to add a method to pip that tries to import a package and if the import fails then try to download and install the package handling the UI. Yes, you can put the package as a dependency in your pip config for your code. This is intended for the case when you have a bunch of python tools/libs in some shared repository in your organization. People check the code out and expect it to run but it has third party dependencies. There is no install step for your code, per se. Furthermore the people using your code don't know enough about python to install things themselves. Proposed syntax is: import pip pip.require("foo") If you search online for pip.main you'll see a whole bunch of hall-baked brittle solutions to this problem that look like this: try: import foo except ImportError: pip.main("install", "foo") ---------- files: require.py messages: 257903 nosy: Blaize Rhodes priority: normal severity: normal status: open title: Add a method to pip.. pip.require("package_name") type: enhancement Added file: http://bugs.python.org/file41565/require.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 05:55:37 2016 From: report at bugs.python.org (Blaize Rhodes) Date: Sun, 10 Jan 2016 10:55:37 +0000 Subject: [issue26074] Add a method to pip.. pip.require("package_name") In-Reply-To: <1452423120.4.0.471254538905.issue26074@psf.upfronthosting.co.za> Message-ID: <1452423337.98.0.36037433844.issue26074@psf.upfronthosting.co.za> Blaize Rhodes added the comment: I'm more than happy to fill in the contributor agreement.. but it seems like a hassle if, what I'm assuming will happen, someone points out a good reason why this hasn't been done already. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 06:56:13 2016 From: report at bugs.python.org (lilydjwg) Date: Sun, 10 Jan 2016 11:56:13 +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: <1452426973.1.0.562959006083.issue21047@psf.upfronthosting.co.za> lilydjwg added the comment: FYI, this breaks one of my programs. I find it now because it only threw errors in rare cases, and I've never seen the deprecated warning because I don't check the logs unless something goes wrong. ---------- nosy: +lilydjwg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 07:09:29 2016 From: report at bugs.python.org (Elena Oat) Date: Sun, 10 Jan 2016 12:09:29 +0000 Subject: [issue25517] regex howto example in "Lookahead Assertions" In-Reply-To: <1446199646.71.0.249231376897.issue25517@psf.upfronthosting.co.za> Message-ID: <1452427769.21.0.670722674932.issue25517@psf.upfronthosting.co.za> Elena Oat added the comment: Corrected the regular expression and documented why [^.]* is used. ---------- keywords: +patch nosy: +Elena.Oat Added file: http://bugs.python.org/file41566/issue25517.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 07:26:36 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sun, 10 Jan 2016 12:26:36 +0000 Subject: [issue26074] Add a method to pip.. pip.require("package_name") In-Reply-To: <1452423337.98.0.36037433844.issue26074@psf.upfronthosting.co.za> Message-ID: <20160110122633.GA21490@sg1> St?phane Wirtel added the comment: But in fact, Pip is an external project to CPython. Could you explain why you post this issue in the CPython Bug Tracker? Thank you ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 07:47:53 2016 From: report at bugs.python.org (Chris Thomas) Date: Sun, 10 Jan 2016 12:47:53 +0000 Subject: [issue25967] Devguide: add 2to3 to the "Changing CPython's Grammar" checklist In-Reply-To: <1451340554.37.0.242024647268.issue25967@psf.upfronthosting.co.za> Message-ID: <1452430073.18.0.884949472956.issue25967@psf.upfronthosting.co.za> Chris Thomas added the comment: Added a note to the check list as needed. ---------- keywords: +patch nosy: +Aegil Added file: http://bugs.python.org/file41567/issue25967.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 07:54:18 2016 From: report at bugs.python.org (Elena Oat) Date: Sun, 10 Jan 2016 12:54:18 +0000 Subject: [issue19316] devguide: compiler - wording In-Reply-To: <1382272126.03.0.859419260116.issue19316@psf.upfronthosting.co.za> Message-ID: <1452430458.82.0.149784800498.issue19316@psf.upfronthosting.co.za> Elena Oat added the comment: Here's the patch regenerated for the latest devguide. ---------- nosy: +Elena.Oat Added file: http://bugs.python.org/file41568/issue19316.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 07:57:34 2016 From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=) Date: Sun, 10 Jan 2016 12:57:34 +0000 Subject: [issue26075] typing.Union unifies types too broadly Message-ID: <1452430654.78.0.244173734721.issue26075@psf.upfronthosting.co.za> New submission from Alex Gr?nholm: >>> from typing import Union, Iterable >>> Union[str, Iterable[int]] typing.Iterable[int] The union loses the "str" parameter because issubclass(str, collections.abc.Iterable) returns True and the check completely disregards generics. Guido mentioned that issubclass() support for generic types should be going away. In the mean time, maybe the subclass check in typing.GenericMeta should be modified not to do it with types from Typing, but how can we accurately identify them? ---------- components: Extension Modules messages: 257910 nosy: alex.gronholm, gvanrossum, lukasz.langa priority: normal severity: normal status: open title: typing.Union unifies types too broadly type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 08:41:14 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 10 Jan 2016 13:41:14 +0000 Subject: [issue26075] typing.Union unifies types too broadly In-Reply-To: <1452430654.78.0.244173734721.issue26075@psf.upfronthosting.co.za> Message-ID: <1452433274.39.0.18077395836.issue26075@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 09:48:47 2016 From: report at bugs.python.org (cowlicks) Date: Sun, 10 Jan 2016 14:48:47 +0000 Subject: [issue19251] bitwise ops for bytes of equal length In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za> Message-ID: <1452437327.25.0.380801929125.issue19251@psf.upfronthosting.co.za> cowlicks added the comment: I've attached a diff that adds ^, |, and & to bytes and bytearray object on the master branch (err the analogous hg thing). It also includes a test file which definitely is in the wrong place, but demonstrates what is working. Personally this came up while I was playing with toy crypto problems. I expected to already be part of the language, but it wasn't. I think this is a natural expectation. I don't think it is obvious to newer python users that they need to cast bytes to ints to do bitwise operations on them. And I do not understand how bitwise operations work on arbitrary precision integers. So perhaps it is not as simple of a concept as "bytes xor bytes". Some folks have suggested using NumPy, but that is a very heavy dependency, and not useful outside of cpython. I searched for code this would clean up in the wild. It was easy to find. This would also catch bugs when bytes objects are different lengths, but there is no check. Like this code I found # XOR each byte of the roundKey with the state table def addRoundKey(state, roundKey): for i in range(len(state)): state[i] = state[i] ^ roundKey[i] p.s. this is my first cpython issue/patch please let me know if I'm doing something wrong. ---------- keywords: +patch nosy: +cowlicks Added file: http://bugs.python.org/file41569/bitwise_bytes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 09:53:35 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 10 Jan 2016 14:53:35 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1452437615.1.0.340857236849.issue25596@psf.upfronthosting.co.za> Xavier de Gaye added the comment: FWIW I have followed the idea of having _iterdir() yielding the DirEntry entry instead of the name in Serhiy's patch. There is a slight performance gain. Now _glob0() and _glob1() do return a list of directories when dironly is true but there is now another place where OSError must be tracked, so it is not clear if this is worth it. glob_scandir_2_diff.patch is the differential patch between glob_scandir_2.patch and glob_scandir_3.patch. Here are the performance tests run with both patches. $ ./python -m timeit -s "from glob import glob" -- "glob('**/*', recursive=True)" glob_scandir_2.patch: 33.1 msec per loop glob_scandir_3.patch: 33.8 msec per loop $ ./python -m timeit -s "from glob import glob" -- "glob('/usr/lib*/**/*', recursive=True)" glob_scandir_2.patch: 927 msec per loop glob_scandir_3.patch: 850 msec per loop $ ./python -m timeit -s "from glob import glob" -- "glob('/usr/lib*/**/', recursive=True)" glob_scandir_2.patch: 423 msec per loop glob_scandir_3.patch: 337 msec per loop ---------- Added file: http://bugs.python.org/file41570/glob_scandir_2_diff.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 09:53:47 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 10 Jan 2016 14:53:47 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1452437627.41.0.977441793575.issue25596@psf.upfronthosting.co.za> Changes by Xavier de Gaye : Added file: http://bugs.python.org/file41571/glob_scandir_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 10:09:35 2016 From: report at bugs.python.org (Ram Rachum) Date: Sun, 10 Jan 2016 15:09:35 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <1452438575.1.0.0322840740513.issue22570@psf.upfronthosting.co.za> Ram Rachum added the comment: Here's an alternate idea I thought of now. Maybe `path.path` should be a pointer to the same `Path` object, so every function will do this: str(arg.path) if hasattr(arg, 'path') else arg What I like about this is that it avoids having the path argument be a string. I don't like misnomers :) I'd understand though if people won't like this suggestion since it introduces another step, of turning the path back into a string. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 10:20:41 2016 From: report at bugs.python.org (Andrew Barnert) Date: Sun, 10 Jan 2016 15:20:41 +0000 Subject: [issue19251] bitwise ops for bytes of equal length In-Reply-To: <1452437327.25.0.380801929125.issue19251@psf.upfronthosting.co.za> Message-ID: Andrew Barnert added the comment: On Jan 10, 2016, at 06:48, cowlicks wrote: > > > Personally this came up while I was playing with toy crypto problems. I expected to already be part of the language, but it wasn't. I think this is a natural expectation. Maybe if you're coming to Python from APL or R or something, but C, C#, Scala, Ruby, Haskell--almost any other language you pick, there's no bitwise operations on (byte) strings. (And if you _are_ coming to Python from something like R, you definitely should be using NumPy.) > > And I do not understand how bitwise operations work on arbitrary precision integers. It's obvious once you think of them as infinite-sized fixed-size ints: 0x27 is the same number as 0x0027, so 0x27 & 0x0134 is 0x0024. (Of course not and negation aren't quite as obvious, but once you think about it, there's only one sensible thing 2's complement could do, and only two sensible things 1's complement could do, and Python is sensible, so it's not surprising once you try it out.) > Some folks have suggested using NumPy, but that is a very heavy dependency, and not useful outside of cpython. It's useful outside of CPython. While NumPyPy isn't 100% yet, it's usable enough for many projects. More to the point, if you're looking for arrays that have really fast and highly readable elementwise operations, that's exactly what NumPy is all about. Sure, you can get bits and pieces of similar functionality without it, but if you're thinking about your code in NumPy's terms (elementwise operations), you really do want to think about NumPy. Meanwhile, have you looked around PyPI at the various bitarray, bitstring, etc. libraries? Are they too slow, too heavyweight, or too inconveniently-API'd? I know whenever I want to play with things like Huffman coding or the underlying bit representation of IEEE floats or anything else bitwise besides basic C integer stuff, I reach for one of those libraries, rather than trying to hack things up around bytes strings. (Except for that example I posted above--clearly for some reason I _did_ hack things up around bytes strings that time--but it only took me that simple class to make things convenient and efficient.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 10:42:34 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 10 Jan 2016 15:42:34 +0000 Subject: [issue13963] dev guide has no mention of mechanics of patch review In-Reply-To: <1328631878.8.0.85188160352.issue13963@psf.upfronthosting.co.za> Message-ID: <1452440554.0.0.17557610004.issue13963@psf.upfronthosting.co.za> Ezio Melotti added the comment: Since we are moving away from rietveld, I'm going to close this as out of date. ---------- resolution: -> out of date stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 10:48:29 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 10 Jan 2016 15:48:29 +0000 Subject: [issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za> Message-ID: <1452440909.95.0.0900965857461.issue26071@psf.upfronthosting.co.za> Steve Dower added the comment: Ultimately, launching python.exe is better than loading python##.dll here because it avoids DLL planting vulnerabilities, but I'm honestly a little surprised still that LoadLibrary won't resolve vcruntime in this case. Been a while since I looked, and I haven't had a chance to check for this yet, but why isn't the directory containing the loaded DLL searched for dependencies? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 10:50:05 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 10 Jan 2016 15:50:05 +0000 Subject: [issue26070] Launcher fails to find in-place built binaries from earlier Python versions In-Reply-To: <1452387575.38.0.184373942558.issue26070@psf.upfronthosting.co.za> Message-ID: <1452441005.16.0.0983539532326.issue26070@psf.upfronthosting.co.za> Steve Dower added the comment: > I've had a heavy consulting load for the past year or so which means I can't always deal with issues as quickly as before. That explains it :) With so little visibility into what we're doing outside of Python it's hard to know. Glad you're still about. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 10:59:00 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 10 Jan 2016 15:59:00 +0000 Subject: [issue26030] Use PEP8 in documentation examples In-Reply-To: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> Message-ID: <1452441540.39.0.063115032176.issue26030@psf.upfronthosting.co.za> Ezio Melotti added the comment: > I'll slowly review what I see, and provide little patches from > time to time, only when the PEP8 infringement look obvious. Sounds good to me. If you are not sure you can ask on IRC (#python-dev on freenode) or the core-mentorship mailing list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 11:44:03 2016 From: report at bugs.python.org (Eryk Sun) Date: Sun, 10 Jan 2016 16:44:03 +0000 Subject: [issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za> Message-ID: <1452444243.28.0.519872357668.issue26071@psf.upfronthosting.co.za> Eryk Sun added the comment: > why isn't the directory containing the loaded DLL searched > for dependencies? That's possible. The loader provides several ways to go about solving this problem. The directory of the DLL can be added to the search path if you use LoadLibraryEx with the flag LOAD_WITH_ALTERED_SEARCH_PATH and use an absolute path. Python already does this for loading extension modules. If we didn't have to worry about older systems, in Windows 8/10 (and Vista/7 with KB2533623), the loader supports a set of flags that give detailed control of the DLL path, including LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR. Individual directories can be added via AddDllDirectory and enabled via the flag LOAD_LIBRARY_SEARCH_USER_DIRS. Default flags can be set via SetDefaultDllDirectories, which affects LoadLibrary as well as LoadLibraryEx. On a related note, it would be nice to modify ctypes to call LoadLibraryEx instead of LoadLibrary. If the flags value is 0 the two calls are identical, so it wouldn't be a disruptive change. The existing dlopen "mode" parameter can be used for the flags, since it isn't used on Windows currently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 12:21:42 2016 From: report at bugs.python.org (Brett Cannon) Date: Sun, 10 Jan 2016 17:21:42 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <1452446502.63.0.303584639467.issue22570@psf.upfronthosting.co.za> Brett Cannon added the comment: I appreciate the thought, Ram, but I'm not a fan. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 12:29:48 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 10 Jan 2016 17:29:48 +0000 Subject: [issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za> Message-ID: <1452446988.09.0.553187045309.issue26071@psf.upfronthosting.co.za> Steve Dower added the comment: > The directory of the DLL can be added to the search path if you use LoadLibraryEx with the flag LOAD_WITH_ALTERED_SEARCH_PATH and use an absolute path. That sounds like the better fix then. I thought there was something along those lines available. We already use the full path to load it - can someone test this change? If not I'll give it a go later today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 12:40:00 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 10 Jan 2016 17:40:00 +0000 Subject: [issue26074] Add a method to pip.. pip.require("package_name") In-Reply-To: <1452423120.4.0.471254538905.issue26074@psf.upfronthosting.co.za> Message-ID: <1452447600.94.0.983510199044.issue26074@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report, but this should be discussed either at https://groups.google.com/forum/#!forum/pypa-dev or https://github.com/pypa/pip/issues ---------- nosy: +berker.peksag resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 13:23:01 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 10 Jan 2016 18:23:01 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <1452450181.83.0.768360780935.issue22570@psf.upfronthosting.co.za> Guido van Rossum added the comment: Using 'path' for this field is not a misnomer (example: DictEntry uses 'path' for the same field). See issue #26027 for a follow-up idea. ---------- dependencies: -Support Path objects in the posix module resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 13:25:26 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 10 Jan 2016 18:25:26 +0000 Subject: [issue26075] typing.Union unifies types too broadly In-Reply-To: <1452430654.78.0.244173734721.issue26075@psf.upfronthosting.co.za> Message-ID: <1452450326.25.0.631531349036.issue26075@psf.upfronthosting.co.za> Guido van Rossum added the comment: Oh, this is yet another reason to finally rip out the issubclass() support... We're tracking that at https://github.com/ambv/typehinting/issues/136 In the meantime, just don't do this! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 13:31:27 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Jan 2016 18:31:27 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za> Message-ID: <1452450687.17.0.706568993884.issue22570@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > str(arg.path) if hasattr(arg, 'path') else arg DirEntry.path can be bytes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 14:00:01 2016 From: report at bugs.python.org (Oren Milman) Date: Sun, 10 Jan 2016 19:00:01 +0000 Subject: [issue26076] redundant checks in tok_get in Parser\tokenizer.c Message-ID: <1452452400.02.0.853203557937.issue26076@psf.upfronthosting.co.za> New submission from Oren Milman: In Parser\tokenizer.c, in tok_get, in the identification of a potential NUMBER token, in case the token starts with a '0', the next char of the token is retrieved, followed by two redundant checks: if (c == '.') goto fraction; if (c == 'j' || c == 'J') goto imaginary; These two are redundant, because they check for the case of a token starting with '0.' or '0j', but even without them, the flow in either of these would reach the code after the /* maybe old-style octal; c is first char of it */ comment. This code (after consuming all zeros and all decimal digits) would again perform those exact two checks, and handle them exactly the same. My proposal is simply to remove the first two checks. I have attached the patched tokenizer.c (the redundant checks are just commented out). ---------- components: Interpreter Core files: tokenizer.c.withoutRedundantChecks.c messages: 257927 nosy: Oren Milman priority: normal severity: normal status: open title: redundant checks in tok_get in Parser\tokenizer.c type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41572/tokenizer.c.withoutRedundantChecks.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 14:14:14 2016 From: report at bugs.python.org (SilentGhost) Date: Sun, 10 Jan 2016 19:14:14 +0000 Subject: [issue26076] redundant checks in tok_get in Parser\tokenizer.c In-Reply-To: <1452452400.02.0.853203557937.issue26076@psf.upfronthosting.co.za> Message-ID: <1452453254.77.0.945361001307.issue26076@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- keywords: +patch nosy: +benjamin.peterson stage: -> patch review versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 14:18:08 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 10 Jan 2016 19:18:08 +0000 Subject: [issue22570] Better stdlib support for Path objects In-Reply-To: <1452450687.17.0.706568993884.issue22570@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: You can't win 'em all... :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 14:32:46 2016 From: report at bugs.python.org (Wiktor Niesiobedzki) Date: Sun, 10 Jan 2016 19:32:46 +0000 Subject: [issue25919] http.client PUT method ignores error responses sent immediatly after headers In-Reply-To: <1450729223.96.0.301570875049.issue25919@psf.upfronthosting.co.za> Message-ID: <1452454366.73.0.453385166278.issue25919@psf.upfronthosting.co.za> Wiktor Niesiobedzki added the comment: Here are the test cases that I've come up with. test_response_after_headers - tests for the case that I'm missing test_ssl_renegotiation - tests for the case that Martin point out As in stock ssl library there is no way to force renegotiation, I've just separated the receiving of standard HTTP status message into few parts and checking, if the http.client is still sending the contents. So - without my patch, first case is failing, with my patch - the second case is failing. I'll try to find some better solution here, which will cover both cases. ---------- Added file: http://bugs.python.org/file41573/early_http_response_tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 15:04:58 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 10 Jan 2016 20:04:58 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1452456298.38.0.0507280250313.issue25596@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Oops, the list comprehension in _glob1() of glob_scandir_3.patch should be instead: names = [x.name for x in _iterdir(dirname, dironly)] This does not change the tests results except it improves glob('/usr/lib*/**/*', True) that gives now 820 msec instead of 927 msec with glob_scandir_2.patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 15:16:27 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sun, 10 Jan 2016 20:16:27 +0000 Subject: [issue19316] devguide: compiler - wording In-Reply-To: <1451615477.48.0.422599685836.issue19316@psf.upfronthosting.co.za> Message-ID: <20160110201624.GA28497@sg1> St?phane Wirtel added the comment: maybe :/ I have reinstalled my laptop, will try to find the patch asap ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 15:27:43 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sun, 10 Jan 2016 20:27:43 +0000 Subject: [issue26076] redundant checks in tok_get in Parser\tokenizer.c In-Reply-To: <1452453254.77.0.945361001307.issue26076@psf.upfronthosting.co.za> Message-ID: <20160110202740.GA28792@sg1> St?phane Wirtel added the comment: Hi SilentGhost and Oren, There is a problem with this patch. This is not a patch, but the complete file. 1. Could you provide a real patch, with the real diff. Use hg diff > /tmp/issue26076.diff 2. Please, could you provide a small test to be sure that everything goes well. Thank you, Stephane ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 15:29:44 2016 From: report at bugs.python.org (SilentGhost) Date: Sun, 10 Jan 2016 20:29:44 +0000 Subject: [issue26076] redundant checks in tok_get in Parser\tokenizer.c In-Reply-To: <1452452400.02.0.853203557937.issue26076@psf.upfronthosting.co.za> Message-ID: <1452457784.08.0.0918937892603.issue26076@psf.upfronthosting.co.za> SilentGhost added the comment: The patch indeed would be more useful, though I'd suggest to actually delete the lines you think should be deleted, rather than just leave the commented out. ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 15:32:10 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sun, 10 Jan 2016 20:32:10 +0000 Subject: [issue26076] redundant checks in tok_get in Parser\tokenizer.c In-Reply-To: <1452457784.08.0.0918937892603.issue26076@psf.upfronthosting.co.za> Message-ID: <20160110203208.GB28792@sg1> St?phane Wirtel added the comment: Totally agree with you, 1. Create a patch 2. Remove the commented lines in the patch ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 15:32:54 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 10 Jan 2016 20:32:54 +0000 Subject: [issue8810] TZ offset description is unclear in docs In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za> Message-ID: <1452457974.08.0.80360037037.issue8810@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 15:33:05 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 10 Jan 2016 20:33:05 +0000 Subject: [issue9305] Don't use east/west of UTC in date/time documentation In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za> Message-ID: <1452457985.47.0.417936568436.issue9305@psf.upfronthosting.co.za> Martin Panter added the comment: Assuming you meant Issue 8810, yes these patches would collide with each other. I am yet to look at the patches, but I gess they should be merged. ---------- dependencies: +TZ offset description is unclear in docs -Don't use east/west of UTC in date/time documentation nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 15:35:58 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sun, 10 Jan 2016 20:35:58 +0000 Subject: [issue8810] TZ offset description is unclear in docs In-Reply-To: <1452457974.08.0.80360037037.issue8810@psf.upfronthosting.co.za> Message-ID: <20160110203556.GC28792@sg1> St?phane Wirtel added the comment: Hi Martin, Which patch? Thanks -- St?phane Wirtel - http://wirtel.be - @matrixise ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 15:45:56 2016 From: report at bugs.python.org (Filip Haglund) Date: Sun, 10 Jan 2016 20:45:56 +0000 Subject: [issue26077] Make slicing of immutable structures return a view instead of a copy Message-ID: <1452458756.3.0.749991798075.issue26077@psf.upfronthosting.co.za> New submission from Filip Haglund: Slicing tuples returns a copy, which is O(n) time. This could be O(1) since tuples are immutable, by just pointing to the same data. This probably applies to other immutable structures as well, such as strings. ---------- components: Interpreter Core messages: 257937 nosy: Filip Haglund priority: normal severity: normal status: open title: Make slicing of immutable structures return a view instead of a copy type: performance versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 16:09:31 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 10 Jan 2016 21:09:31 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1452460171.75.0.639316101491.issue25596@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Actually the microbenchmarks comparison between glob_scandir_2.patch and glob_scandir_3.patch must be made by removing the call to entry.is_symlink() also in glob_scandir_2.patch. In that case the microbenchmarks give about the same results for each patch. Sorry for the noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 16:22:29 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sun, 10 Jan 2016 21:22:29 +0000 Subject: [issue26077] Make slicing of immutable structures return a view instead of a copy In-Reply-To: <1452458756.3.0.749991798075.issue26077@psf.upfronthosting.co.za> Message-ID: <1452460949.86.0.454616322607.issue26077@psf.upfronthosting.co.za> Emanuel Barry added the comment: This is an interesting idea, +1 from me. Do you want to submit a patch? ---------- nosy: +ebarry stage: -> needs patch versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 16:24:42 2016 From: report at bugs.python.org (Edward) Date: Sun, 10 Jan 2016 21:24:42 +0000 Subject: [issue26078] Python launcher options enhancement Message-ID: <1452461082.93.0.268338836984.issue26078@psf.upfronthosting.co.za> New submission from Edward: The Python launcher in Windows is a neat tool for running multiple versions of Python 2 and Python 3 at different times. It allows as options the ability to specify the latest version of either Python 2 or Python 3 defaulting to the 64-bit version if both exist, or a specific 32-bit or 64-bit version of Python 2 or Python 3. What is missing is the ability to specify the latest 32-bit version of Python 2 or Python 3. The equivalent syntax would be '-2-32' or '-3-32'. Is there some reason why this option has been disallowed ? If not I would like to see this logical enhancement to the Python launcher in Windows added to its functionality. ---------- components: Windows messages: 257940 nosy: edienerlee, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python launcher options enhancement type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 16:31:03 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 10 Jan 2016 21:31:03 +0000 Subject: [issue1753718] base64 "legacy" functions violate RFC 3548 Message-ID: <1452461463.14.0.856811174016.issue1753718@psf.upfronthosting.co.za> Martin Panter added the comment: Uploaded a Python 3 patch to Issue 22088 which includes the doc string changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 17:04:57 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 10 Jan 2016 22:04:57 +0000 Subject: [issue26077] Make slicing of immutable structures return a view instead of a copy In-Reply-To: <1452458756.3.0.749991798075.issue26077@psf.upfronthosting.co.za> Message-ID: <1452463497.42.0.480730644255.issue26077@psf.upfronthosting.co.za> Martin Panter added the comment: I think which technique (copy or view) is better depends on the situation. If you are making a large temporary slice, a view may be more efficient. But if you are making a long-term slice and don?t need the original any more, a copy would allow the original memory to be freed early. Do you have any use cases? You can already get a kind of slice view into bytes etc by using memoryview(). ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 17:16:44 2016 From: report at bugs.python.org (Oren Milman) Date: Sun, 10 Jan 2016 22:16:44 +0000 Subject: [issue26076] redundant checks in tok_get in Parser\tokenizer.c In-Reply-To: <1452452400.02.0.853203557937.issue26076@psf.upfronthosting.co.za> Message-ID: <1452464204.19.0.0306303696352.issue26076@psf.upfronthosting.co.za> Oren Milman added the comment: Sorry for being so clueless. The diff is attached. I manually did some checks to verify that relevant stuff work correctly (the imaginary number 0j, and fractions starting with '0.'). I run 'python -m test', and got the following output: 352 tests OK. 1 test altered the execution environment: test_subprocess 45 tests skipped: test_bz2 test_crypt test_curses test_dbm_gnu test_dbm_ndbm test_devpoll test_epoll test_fcntl test_fork1 test_gdb test_grp test_idle test_ioctl test_kqueue test_lzma test_nis test_openpty test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd test_readline test_resource test_smtpnet test_socketserver test_spwd test_sqlite test_ssl test_syslog test_tcl test_threadsignals test_timeout test_tix test_tk test_ttk_guionly test_ttk_textonly test_urllib2net test_urllibnet test_wait3 test_wait4 test_winsound test_xmlrpc_net test_zipfile64 Then, I removed my patch (and made sure hg diff output nothing), rebuilt CPython, run 'python -m test', and got exactly the same output. ---------- versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file41574/issue26076.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 17:25:23 2016 From: report at bugs.python.org (SilentGhost) Date: Sun, 10 Jan 2016 22:25:23 +0000 Subject: [issue26076] redundant checks in tok_get in Parser\tokenizer.c In-Reply-To: <1452452400.02.0.853203557937.issue26076@psf.upfronthosting.co.za> Message-ID: <1452464723.47.0.740749017982.issue26076@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 17:43:09 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 10 Jan 2016 22:43:09 +0000 Subject: [issue25170] 3.5.0 documentation archives missing In-Reply-To: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za> Message-ID: <1452465789.48.0.667280090278.issue25170@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps related is that the list at only goes up to 3.4.3. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 18:07:48 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 10 Jan 2016 23:07:48 +0000 Subject: [issue25919] http.client PUT method ignores error responses sent immediatly after headers In-Reply-To: <1450729223.96.0.301570875049.issue25919@psf.upfronthosting.co.za> Message-ID: <1452467268.03.0.797432098365.issue25919@psf.upfronthosting.co.za> Martin Panter added the comment: Sorry for making a seemingly easy problem harder :) Your version of test_ssl_renegotiation() would actually be harder to fix IMO, since that would require the client to receive response data (the ?H?) and continue to transmit request data concurrently. It would probably require sending and receiving in separate coroutines or threads, like asyncio. There may still be a way to avoid that if we don?t need to send and receive HTTP data at the same time. We only need the low-level SSL messages to work properly. The following might work: self.sock.setblocking(False) try: ... # Get chunks of request body to send while datablock: select((self._reader,), (self.sock,), (), self._timeout) if self._reader.peek(): ... # Early response received try: amount = self.sock.send(datablock) except (BlockingIOError, SSLWantRead, SSLWantWrite): continue datablock = datablock[amount:] finally: self.sock.settimeout(self.timeout) This might require the following problems investigated and fixed first: * Need to maintain the buffered socket reader of self.sock.makefile(), before the response is actually read. Could use my patch for Issue 23377. * Allow a buffered socket reader to be non-blocking without upsetting its buffer. The documentation disallows non-blocking mode, but I suspect that is just a Python 2 relic and there is no restriction in the Python 3 implementation. I thought there was a bug open for this but I can only find mentions in other bugs. * Allow using BufferedReader.peek() to see if data is ready to be read. The current documentation does not guarantee it will return any bytes (Issue 5811), but I understand the implementation normally does return ? 1 byte. * Clarify what peek() should do if no non-blocking data is available. Currently I think it returns b"", but that is inconsistent with other APIs, and does not differentiate from EOF. I proposed to change peek() to return None in Issue 13322. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 18:43:55 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jan 2016 23:43:55 +0000 Subject: [issue19332] Guard against changing dict during iteration In-Reply-To: <1382364174.9.0.836332683158.issue19332@psf.upfronthosting.co.za> Message-ID: <20160110234351.70885.56690@psf.io> Roundup Robot added the comment: New changeset a576199a5350 by Victor Stinner in branch 'default': PEP 509 https://hg.python.org/peps/rev/a576199a5350 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 22:14:18 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 11 Jan 2016 03:14:18 +0000 Subject: [issue25596] regular files handled as directories in the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1452482058.2.0.192663689667.issue25596@psf.upfronthosting.co.za> Guido van Rossum added the comment: @serhiy, I assume this is in your capable hands? Personally I'd like to have seen the refactoring in a separate diff from the switch to scandir(), just to ensure that the refactoring does not change anything and to make it easier to read the changes for the scandir() switch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 22:27:19 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 11 Jan 2016 03:27:19 +0000 Subject: [issue26076] redundant checks in tok_get in Parser\tokenizer.c In-Reply-To: <1452452400.02.0.853203557937.issue26076@psf.upfronthosting.co.za> Message-ID: <1452482839.42.0.560149957408.issue26076@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 22:29:07 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Mon, 11 Jan 2016 03:29:07 +0000 Subject: [issue26076] redundant checks in tok_get in Parser\tokenizer.c In-Reply-To: <1452464204.19.0.0306303696352.issue26076@psf.upfronthosting.co.za> Message-ID: <20160111032903.GB29527@sg1> St?phane Wirtel added the comment: Thank you for your patch, it's easier for the review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 22:54:13 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jan 2016 03:54:13 +0000 Subject: [issue26070] Launcher fails to find in-place built binaries from earlier Python versions In-Reply-To: <1452387575.38.0.184373942558.issue26070@psf.upfronthosting.co.za> Message-ID: <20160111035409.59590.81051@psf.io> Roundup Robot added the comment: New changeset 51cc7adac78d by Mark Hammond in branch '3.5': Issue #26070: py.exe launcher fails to find in-place built binaries from earlier Python versions. https://hg.python.org/cpython/rev/51cc7adac78d New changeset bfb4a09149b1 by Mark Hammond in branch 'default': Issue #26070: py.exe launcher fails to find in-place built binaries from earlier Python versions. https://hg.python.org/cpython/rev/bfb4a09149b1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 01:19:31 2016 From: report at bugs.python.org (Mark Hammond) Date: Mon, 11 Jan 2016 06:19:31 +0000 Subject: [issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za> Message-ID: <1452493171.11.0.149632180394.issue26071@psf.upfronthosting.co.za> Mark Hammond added the comment: > > The directory of the DLL can be added to the search path if you > > use LoadLibraryEx with the flag LOAD_WITH_ALTERED_SEARCH_PATH and use an absolute path. > That sounds like the better fix then. I thought there was something along those lines available. That does work. I didn't do it that way initially as I felt your earlier comment: > Setting the working directory is likely to lead to a more reliable initial state. Was an additional nice outcome of just changing the cwd. This patch does the LoadLibraryEx() and works (but obviously leaves the CWD being the downloaded directory, probably %temp%) I'll check this in once I get the green-light, thanks. ---------- Added file: http://bugs.python.org/file41575/bdist.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 02:10:47 2016 From: report at bugs.python.org (Eryk Sun) Date: Mon, 11 Jan 2016 07:10:47 +0000 Subject: [issue26078] Python launcher options enhancement In-Reply-To: <1452461082.93.0.268338836984.issue26078@psf.upfronthosting.co.za> Message-ID: <1452496247.48.0.00944461424447.issue26078@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Let launcher autoselect best 32-bit Python on 64-bit system _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 02:12:29 2016 From: report at bugs.python.org (Eryk Sun) Date: Mon, 11 Jan 2016 07:12:29 +0000 Subject: [issue25636] Let launcher autoselect best 32-bit Python on 64-bit system In-Reply-To: <1447699025.13.0.574177201603.issue25636@psf.upfronthosting.co.za> Message-ID: <1452496349.38.0.335227489673.issue25636@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 03:01:46 2016 From: report at bugs.python.org (Mark Hammond) Date: Mon, 11 Jan 2016 08:01:46 +0000 Subject: [issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za> Message-ID: <1452499306.34.0.465893632907.issue26071@psf.upfronthosting.co.za> Mark Hammond added the comment: welp, I hadn't actually tested the patch on x64 yet ;) > #ifdef WIN_64 should read: > #ifdef _WIN64 WIN_64 is a Python invented name and this stub doesn't Python pull the headers in... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 03:31:30 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 11 Jan 2016 08:31:30 +0000 Subject: [issue26077] Make slicing of immutable structures return a view instead of a copy In-Reply-To: <1452458756.3.0.749991798075.issue26077@psf.upfronthosting.co.za> Message-ID: <1452501090.74.0.0581119983616.issue26077@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: While it's theoretically possible, there's a reason why we haven't done this in the past: we don't want to keep the possibly large original object alive when using a slice. For buffer interface types, you can already use memoryview to get a view in case you need this. In most other cases, it's better to work with indexes into the original object rather than views on the data. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 03:33:02 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Jan 2016 08:33:02 +0000 Subject: [issue25596] Use scandir() to speed the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1452501182.44.0.152396396257.issue25596@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Xavier for correcting the documentation. Here is minimal patch that switches the glob module to scandir(). ---------- title: regular files handled as directories in the glob module -> Use scandir() to speed the glob module Added file: http://bugs.python.org/file41576/glob_scandir_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 07:18:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Jan 2016 12:18:20 +0000 Subject: [issue25596] Use scandir() to speed the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1452514700.18.0.245298478722.issue25596@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Results of microbenchmarks for glob_scandir_4.patch: $ ./python -m timeit -s "from glob import glob" -- "glob('**/*', recursive=True)" Unpatched: 275 msec per loop Patched: 79.4 msec per loop $ ./python -m timeit -s "from glob import glob" -- "glob('/usr/lib*/**/*', recursive=True)" Unpatched: 2.11 sec per loop Patched: 624 msec per loop $ ./python -m timeit -s "from glob import glob" -- "glob('/usr/lib*/**/', recursive=True)" Unpatched: 1.79 sec per loop Patched: 281 msec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 07:20:21 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Jan 2016 12:20:21 +0000 Subject: [issue26032] Use scandir() to speed up pathlib globbing In-Reply-To: <1452120927.04.0.31788168865.issue26032@psf.upfronthosting.co.za> Message-ID: <1452514821.4.0.115798593828.issue26032@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed minimal patch implements globbing in pathlib using os.scandir(). Here are results of microbenchmarks: $ ./python -m timeit -s "from pathlib import Path; p = Path()" -- "list(p.glob('**/*'))" Unpatched: 598 msec per loop Patched: 372 msec per loop $ ./python -m timeit -s "from pathlib import Path; p = Path('/usr/')" -- "list(p.glob('lib*/**/*'))" Unpatched: 1.33 sec per loop Patched: 804 msec per loop $ ./python -m timeit -s "from pathlib import Path; p = Path('/usr/')" -- "list(p.glob('lib*/**/'))" Unpatched: 750 msec per loop Patched: 180 msec per loop See msg257954 in issue25596 for comparison with the glob module. ---------- assignee: -> serhiy.storchaka keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file41577/pathlib_glob_scandir.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 07:22:00 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Jan 2016 12:22:00 +0000 Subject: [issue25596] Use scandir() to speed up the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1452514920.27.0.75574790432.issue25596@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- title: Use scandir() to speed the glob module -> Use scandir() to speed up the glob module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 08:34:40 2016 From: report at bugs.python.org (Bjoern Thiel) Date: Mon, 11 Jan 2016 13:34:40 +0000 Subject: [issue26079] Build with Visual Studio 2015 using PlatformToolset=v120 Message-ID: <1452519280.93.0.432725713668.issue26079@psf.upfronthosting.co.za> New submission from Bjoern Thiel: Fixing the build output folder for tix-8.4.3.6. ---------- components: Build files: build.patch keywords: patch messages: 257956 nosy: bjoernthiel priority: normal severity: normal status: open title: Build with Visual Studio 2015 using PlatformToolset=v120 type: crash versions: Python 3.5 Added file: http://bugs.python.org/file41578/build.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 08:45:10 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 11 Jan 2016 13:45:10 +0000 Subject: [issue26079] Build with Visual Studio 2015 using PlatformToolset=v120 In-Reply-To: <1452519280.93.0.432725713668.issue26079@psf.upfronthosting.co.za> Message-ID: <1452519910.68.0.506080996824.issue26079@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware type: crash -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 09:14:14 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 11 Jan 2016 14:14:14 +0000 Subject: [issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za> Message-ID: <1452521654.57.0.80647505839.issue26071@psf.upfronthosting.co.za> Steve Dower added the comment: The downside of the preprocessor - no errors when you spell an ifdef wrong ;) It looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 09:25:58 2016 From: report at bugs.python.org (Ben Hoyt) Date: Mon, 11 Jan 2016 14:25:58 +0000 Subject: [issue25596] Use scandir() to speed up the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1452522358.29.0.116605661741.issue25596@psf.upfronthosting.co.za> Ben Hoyt added the comment: Nice! Good to see scandir() getting used to speed up other functions, functions that folks are using a ton already, like glob(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 09:28:07 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 11 Jan 2016 14:28:07 +0000 Subject: [issue22642] trace module: unclear error message In-Reply-To: <1413377180.82.0.707385230262.issue22642@psf.upfronthosting.co.za> Message-ID: <1452522486.99.0.879844550661.issue22642@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I reviewed the patch. It looks like the problem is not just with list functions but with other options too. Like. $ ./python.exe -m trace -t $ ./python.exe -m trace -c $ ./python.exe -m trace -T Will throw the same error. So, any changes should address all these cases instead of a single listfunctions (-l) case only. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 09:41:05 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 11 Jan 2016 14:41:05 +0000 Subject: [issue22642] trace module: unclear error message In-Reply-To: <1413377180.82.0.707385230262.issue22642@psf.upfronthosting.co.za> Message-ID: <1452523265.25.0.272016644706.issue22642@psf.upfronthosting.co.za> SilentGhost added the comment: I could submit a patch, but I'd switch over from getopt to argparse. I think this exactly the case when such a change is warranted. ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 09:47:57 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Jan 2016 14:47:57 +0000 Subject: [issue26058] PEP 509: Add ma_version to PyDictObject In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za> Message-ID: <1452523677.61.0.263309264915.issue26058@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Add dict.__version__ read-only property -> PEP 509: Add ma_version to PyDictObject _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 09:48:17 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Jan 2016 14:48:17 +0000 Subject: [issue26058] PEP 509: Add ma_version to PyDictObject In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za> Message-ID: <1452523697.37.0.275399319707.issue26058@psf.upfronthosting.co.za> STINNER Victor added the comment: The PEP is now at python.org: PEP 509. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 09:52:30 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 11 Jan 2016 14:52:30 +0000 Subject: [issue24955] webbrowser broken on Mac OS X when using the BROWSER variable In-Reply-To: <1440842500.82.0.168118984503.issue24955@psf.upfronthosting.co.za> Message-ID: <1452523950.62.0.162398886296.issue24955@psf.upfronthosting.co.za> Senthil Kumaran added the comment: The patch is correct and will fix the issue. It will require test coverage to be complete so that we don't land upon similar issues in future. ---------- nosy: +orsenthil stage: -> test needed versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 09:57:05 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 11 Jan 2016 14:57:05 +0000 Subject: [issue22642] trace module: unclear error message In-Reply-To: <1413377180.82.0.707385230262.issue22642@psf.upfronthosting.co.za> Message-ID: <1452524225.23.0.415436809786.issue22642@psf.upfronthosting.co.za> Senthil Kumaran added the comment: @SilentGhost, I agree with you. I am making the change to use argparse as part of this issue24649. And this bug could be covered as part of the change to argparse. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 09:58:49 2016 From: report at bugs.python.org (cowlicks) Date: Mon, 11 Jan 2016 14:58:49 +0000 Subject: [issue19251] bitwise ops for bytes of equal length In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za> Message-ID: <1452524329.84.0.606485647705.issue19251@psf.upfronthosting.co.za> cowlicks added the comment: @Andrew Barnert > Maybe if you're coming to Python from... I'm not sure if your trying argue that my expectations are unusual? Python is my first programming language. To reiterate: I expected cpython to support bitwise operations on binary data. I don't think that is so strange. No I have not looked at PyPi. What I did was have an idea to do this, and there happened to be an open bug on it that needed a patch. So I wrote one. And yes, I realize NumPy can do this, but it is still a very large dependency. Anyway, here are some random projects which would look a lot nicer with this: An implementation of the blake2 hash function in pure python. Consider this line: https://github.com/buggywhip/blake2_py/blob/master/blake2.py#L234 self.h = [self.h[i] ^ v[i] ^ v[i+8] for i in range(8)] Which would become something like: self.h ^= v[:8] ^ v[8:] Which is much easier to read and much faster. Or consider this function from this aes implementation: https://github.com/bozhu/AES-Python/blob/master/aes.py#L194-L201 def __mix_single_column(self, a): # please see Sec 4.1.2 in The Design of Rijndael t = a[0] ^ a[1] ^ a[2] ^ a[3] u = a[0] a[0] ^= t ^ xtime(a[0] ^ a[1]) a[1] ^= t ^ xtime(a[1] ^ a[2]) a[2] ^= t ^ xtime(a[2] ^ a[3]) a[3] ^= t ^ xtime(a[3] ^ u) This would become something like: def __mix_single_column(self, a): a ^= a ^ xtime(a ^ (a[1:] + a[0:1])) Clearer and faster. Another piece of code this would improve: https://github.com/mgoffin/keccak-python/blob/master/Keccak.py#L196-L209 These were easy to find so I'm sure there are more. I think these demonstrate that despite what people *should* be doing, they are doing things in a way that could be substantially improved with this patch. This does resemble NumPy's vectorized functions, but it is much more limited in scope since there is no broadcasting involved. Here is a quick benchmark: $ ./python -m timeit -n 100000 -s "a=b'a'*64; b=b'b'*64" "(int.from_bytes(a, 'little') ^ int.from_bytes(b, 'little')).to_bytes(64, 'little')" 100000 loops, best of 3: 0.942 usec per loop $ ./python -m timeit -n 100000 -s "a=b'a'*64; b=b'b'*64" "a ^ b" 100000 loops, best of 3: 0.041 usec per loop NumPy is the slowest but I'm probably doing something wrong, and its in ipython so I'm not timing the import: In [13]: %timeit bytes(np.frombuffer(b'b'*64, dtype=np.int8) ^ np.frombuffer(b'a'*64, dtype=np.int8)) 100000 loops, best of 3: 3.69 ?s per loop About 20 times faster, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 10:09:50 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jan 2016 15:09:50 +0000 Subject: [issue26069] Remove the Deprecated API in trace module In-Reply-To: <1452385226.89.0.6584761467.issue26069@psf.upfronthosting.co.za> Message-ID: <20160111150947.1005.77253@psf.io> Roundup Robot added the comment: New changeset 6f05bdc18661 by Senthil Kumaran in branch 'default': Issue #26069: Remove the deprecated apis in the trace module. https://hg.python.org/cpython/rev/6f05bdc18661 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 10:11:47 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 11 Jan 2016 15:11:47 +0000 Subject: [issue26069] Remove the Deprecated API in trace module In-Reply-To: <1452385226.89.0.6584761467.issue26069@psf.upfronthosting.co.za> Message-ID: <1452525107.93.0.0424274273371.issue26069@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks for the review, matrixise. I've submitted this change. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 10:18:53 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 11 Jan 2016 15:18:53 +0000 Subject: [issue26069] Remove the Deprecated API in trace module In-Reply-To: <1452385226.89.0.6584761467.issue26069@psf.upfronthosting.co.za> Message-ID: <1452525533.2.0.5978789038.issue26069@psf.upfronthosting.co.za> Berker Peksag added the comment: I couldn't find exact references, but I think we've reached an agreement that we want to keep old APIs in the stdlib to make porting from Python 2 easier. So you might want to revert this :) ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 10:27:28 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 11 Jan 2016 15:27:28 +0000 Subject: [issue26069] Remove the Deprecated API in trace module In-Reply-To: <1452385226.89.0.6584761467.issue26069@psf.upfronthosting.co.za> Message-ID: <1452526048.13.0.767538354342.issue26069@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Hi Berker, could you find the reference for it? It will be helpful to analyze. IMO, the non-removal of 2.x-> 3.x APIs could be done on a case to case basis. In this case, issue10371 made the change in (2010) of making the undocumented public methods to private internal and deprecated those old undocumented internal (but public) methods. It was a correct thing to do. Removal of the deprecated should have been done sooner. Otherwise, we are left with redundant methods (public and _private) in the same module serving no useful purpose. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 11:31:50 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 11 Jan 2016 16:31:50 +0000 Subject: [issue26059] Integer Overflow In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za> Message-ID: <1452529910.69.0.875305694857.issue26059@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks for the report. This module has been deprecated for a long time, but we should still fix this. Do you have any idea how to fix it? ---------- components: +Extension Modules -ctypes nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 11:32:53 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Jan 2016 16:32:53 +0000 Subject: [issue26059] Integer Overflow in strop.replace() In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za> Message-ID: <1452529973.05.0.960808312402.issue26059@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Integer Overflow -> Integer Overflow in strop.replace() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 11:39:59 2016 From: report at bugs.python.org (Matej Cepl) Date: Mon, 11 Jan 2016 16:39:59 +0000 Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za> Message-ID: <1452530399.0.0.8857122301.issue7559@psf.upfronthosting.co.za> Changes by Matej Cepl : ---------- nosy: +mcepl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 11:41:23 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 11 Jan 2016 16:41:23 +0000 Subject: [issue26079] Build with Visual Studio 2015 using PlatformToolset=v120 In-Reply-To: <1452519280.93.0.432725713668.issue26079@psf.upfronthosting.co.za> Message-ID: <1452530483.03.0.478135616964.issue26079@psf.upfronthosting.co.za> Steve Dower added the comment: Good catch! Once I'm at a PC I'll merge this in unless someone else gets there first. (I believe it also applies to 2.7 since the project files were updated.) ---------- versions: +Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 11:45:14 2016 From: report at bugs.python.org (Zachary Ware) Date: Mon, 11 Jan 2016 16:45:14 +0000 Subject: [issue26079] Build with Visual Studio 2015 using PlatformToolset=v120 In-Reply-To: <1452519280.93.0.432725713668.issue26079@psf.upfronthosting.co.za> Message-ID: <1452530714.6.0.534438749596.issue26079@psf.upfronthosting.co.za> Zachary Ware added the comment: I'm on the fence about this one. MSVC 12.0 is not officially supported for any Python release. Also, using PlatformToolset makes things difficult for ICC builds (which set PlatformToolset to e.g. "Intel C++ Compiler 16.0"). On the other hand, this is a very simple change, and building tkinter with ICC is pretty well completely broken anyway (it only works if you first build Tcl/Tk with MSVC). Call me +0; +1 if you can get around using PlatformToolset directly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 11:58:24 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 11 Jan 2016 16:58:24 +0000 Subject: [issue25348] Update pgo_build.bat to use --pgo flag for regrtest In-Reply-To: <1444346245.0.0.569960292546.issue25348@psf.upfronthosting.co.za> Message-ID: <1452531504.81.0.83960724928.issue25348@psf.upfronthosting.co.za> Steve Dower added the comment: LGTM ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:07:27 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 11 Jan 2016 17:07:27 +0000 Subject: [issue26059] Integer Overflow in strop.replace() In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za> Message-ID: <1452532047.97.0.630688599244.issue26059@psf.upfronthosting.co.za> Guido van Rossum added the comment: I cannot reproduce this on Mac (the code form 1.py just gives a very long answer). I don't have a Windows machine to try it on. Do you have a patch or fix? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:09:29 2016 From: report at bugs.python.org (W. Trevor King) Date: Mon, 11 Jan 2016 17:09:29 +0000 Subject: [issue26080] "abandonned" -> "abandoned" in PEP 510's https://hg.python.org/peps/rev/b463c740990c Message-ID: <1452532169.85.0.59348007279.issue26080@psf.upfronthosting.co.za> New submission from W. Trevor King: In the recently-landed [1], There was also the Unladen Swallow project, but it was abandonned in 2011. Should have used ?abandoned? instead of ?abandonned?. [1]: https://hg.python.org/peps/rev/b463c740990c changeset: 6155:b463c740990c user: Victor Stinner gmail.com> date: Sun Jan 10 14:58:17 2016 +0100 summary: PEP 510: rationale for static optimize vs JIT compiler http://permalink.gmane.org/gmane.comp.python.cvs/114604 ---------- assignee: docs at python components: Documentation messages: 257974 nosy: docs at python, labrat priority: normal severity: normal status: open title: "abandonned" -> "abandoned" in PEP 510's https://hg.python.org/peps/rev/b463c740990c type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:11:03 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jan 2016 17:11:03 +0000 Subject: [issue26080] "abandonned" -> "abandoned" in PEP 510's https://hg.python.org/peps/rev/b463c740990c In-Reply-To: <1452532169.85.0.59348007279.issue26080@psf.upfronthosting.co.za> Message-ID: <20160111171057.70893.82579@psf.io> Roundup Robot added the comment: New changeset 63151533cebf by Victor Stinner in branch 'default': PEP 510: abandonned => abandoned https://hg.python.org/peps/rev/63151533cebf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:11:33 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Jan 2016 17:11:33 +0000 Subject: [issue26080] "abandonned" -> "abandoned" in PEP 510's https://hg.python.org/peps/rev/b463c740990c In-Reply-To: <1452532169.85.0.59348007279.issue26080@psf.upfronthosting.co.za> Message-ID: <1452532293.56.0.882109419313.issue26080@psf.upfronthosting.co.za> STINNER Victor added the comment: Fixed, thanks for the report. ---------- nosy: +haypo resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:14:38 2016 From: report at bugs.python.org (Ramin Farajpour Cami) Date: Mon, 11 Jan 2016 17:14:38 +0000 Subject: [issue26059] Integer Overflow in strop.replace() In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za> Message-ID: <1452532478.13.0.192940570708.issue26059@psf.upfronthosting.co.za> Ramin Farajpour Cami added the comment: static char * mymemreplace(const char *str, Py_ssize_t len, const char *pat, Py_ssize_t pat_len, pattern string to find */ const char *sub, Py_ssize_t sub_len, substitution string */ Py_ssize_t count, number of replacements */ Py_ssize_t *out_len) { [...] new_len = len + nfound*(sub_len - pat_len); <<<< Unchecked arithmetic can overflow here. if (new_len == 0) { /* Have to allocate something for the caller to free(). */ out_s = (char *)PyMem_MALLOC(1); if (out_s == NULL) return NULL; out_s[0] = '\0'; } else { assert(new_len > 0); new_s = (char *)PyMem_MALLOC(new_len); <<<< An allocation is performed using overflowed value. if (new_s == NULL) return NULL; out_s = new_s; for (; count > 0 && len > 0; --count) { <<<< Memory is copied to new_s using len, which can be greater than the overflowed new_len value. /* find index of next instance of pattern */ offset = mymemfind(str, len, pat, pat_len); if (offset == -1) break; /* copy non matching part of input string */ memcpy(new_s, str, offset); str += offset + pat_len; len -= offset + pat_len; /* copy substitute into the output string */ new_s += offset; memcpy(new_s, sub, sub_len); new_s += sub_len; } /* copy any remaining values into output string */ if (len > 0) memcpy(new_s, str, len); } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:16:15 2016 From: report at bugs.python.org (Ramin Farajpour Cami) Date: Mon, 11 Jan 2016 17:16:15 +0000 Subject: [issue26059] Integer Overflow in strop.replace() In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za> Message-ID: <1452532575.35.0.132768364999.issue26059@psf.upfronthosting.co.za> Ramin Farajpour Cami added the comment: The issue can be triggered by performing a large substitution that overflows the arithmetic used in mymemreplace() to calculate the size of the new string: ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:17:27 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 11 Jan 2016 17:17:27 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1452532647.33.0.839659693022.issue22995@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I've verified that backing out the typeobject.c change allows kivy and pysam to build. s3ql still fails but for other reasons, though its build does get past the cython failure. This clinches it for me. I am going to remove the typeobject.c clause from 2.7, 3.5, and 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:17:46 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Jan 2016 17:17:46 +0000 Subject: [issue26059] Integer Overflow in strop.replace() In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za> Message-ID: <1452532666.98.0.693516200941.issue26059@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I thought this was fixed in issue24708. At least I get MemoryError on 32-bit Linux as expected, and the code around looks correct. May be PyMem_MALLOC on 64-bit Windows works only with 32-bit size? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:18:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Jan 2016 17:18:37 +0000 Subject: [issue26059] Integer Overflow in strop.replace() In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za> Message-ID: <1452532717.12.0.778875152495.issue26059@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:18:44 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 11 Jan 2016 17:18:44 +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: <1452532724.36.0.834125179247.issue21047@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:19:28 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 11 Jan 2016 17:19:28 +0000 Subject: [issue25919] http.client PUT method ignores error responses sent immediatly after headers In-Reply-To: <1450729223.96.0.301570875049.issue25919@psf.upfronthosting.co.za> Message-ID: <1452532768.84.0.934121847126.issue25919@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:19:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Jan 2016 17:19:35 +0000 Subject: [issue26059] Integer Overflow in strop.replace() In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za> Message-ID: <1452532775.66.0.704749966001.issue26059@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The code in msg257977 doesn't match current sources. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:22:47 2016 From: report at bugs.python.org (Ramin Farajpour Cami) Date: Mon, 11 Jan 2016 17:22:47 +0000 Subject: [issue26059] Integer Overflow in strop.replace() In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za> Message-ID: <1452532967.86.0.625385839651.issue26059@psf.upfronthosting.co.za> Ramin Farajpour Cami added the comment: python 2.7.10 32bit and python 2.7.11 64bit crash on windows 10 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:23:28 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Jan 2016 17:23:28 +0000 Subject: [issue26050] Add new StreamReader.readuntil() method In-Reply-To: <1452285476.14.0.419432816204.issue26050@psf.upfronthosting.co.za> Message-ID: <1452533008.31.0.364970011788.issue26050@psf.upfronthosting.co.za> Yury Selivanov added the comment: Some info on this: https://github.com/python/asyncio/issues/282#issuecomment-155957235 Long story short, Future implemented in C can speedup some asyncio code up to 25%. I'm attaching a patch with a WIP implementation. There are some failing assertions deep in GC, which I need to track down. 'Future.remove_done_callback' still needs to be properly implemented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:23:44 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Jan 2016 17:23:44 +0000 Subject: [issue26081] Implement asyncio Future in C to improve performance Message-ID: <1452533022.97.0.443242974791.issue26081@psf.upfronthosting.co.za> New submission from Yury Selivanov: Some info on this: https://github.com/python/asyncio/issues/282#issuecomment-155957235 Long story short, Future implemented in C can speedup some asyncio code up to 25%. I'm attaching a patch with a WIP implementation. There are some failing assertions deep in GC, which I need to track down. 'Future.remove_done_callback' still needs to be properly implemented. ---------- assignee: yselivanov components: asyncio files: futures.patch keywords: patch messages: 257984 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal stage: needs patch status: open title: Implement asyncio Future in C to improve performance type: performance versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41579/futures.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:24:01 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Jan 2016 17:24:01 +0000 Subject: [issue26050] Add new StreamReader.readuntil() method In-Reply-To: <1452285476.14.0.419432816204.issue26050@psf.upfronthosting.co.za> Message-ID: <1452533041.59.0.0338749110269.issue26050@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- Removed message: http://bugs.python.org/msg257983 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:24:49 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Jan 2016 17:24:49 +0000 Subject: [issue26050] Add new StreamReader.readuntil() method In-Reply-To: <1452285476.14.0.419432816204.issue26050@psf.upfronthosting.co.za> Message-ID: <1452533089.49.0.829752795818.issue26050@psf.upfronthosting.co.za> Yury Selivanov added the comment: Sorry, posted my previous message here by mistake (it was for issue #26081). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:26:16 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 11 Jan 2016 17:26:16 +0000 Subject: [issue26079] Build with Visual Studio 2015 using PlatformToolset=v120 In-Reply-To: <1452519280.93.0.432725713668.issue26079@psf.upfronthosting.co.za> Message-ID: <1452533176.84.0.326228606011.issue26079@psf.upfronthosting.co.za> Steve Dower added the comment: It's better than using the Visual Studio version, which isn't necessarily tied to any VC version. To support another compiler will require more code like this anyway. An alternative may be to patch Tcl et al. to not put the VC version into the output path? That's likely to lead to different problems for people though... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:30:03 2016 From: report at bugs.python.org (Ramin Farajpour Cami) Date: Mon, 11 Jan 2016 17:30:03 +0000 Subject: [issue26059] Integer Overflow in strop.replace() In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za> Message-ID: <1452533403.93.0.643695592299.issue26059@psf.upfronthosting.co.za> Ramin Farajpour Cami added the comment: Do you have any idea how to fix it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:32:47 2016 From: report at bugs.python.org (Zachary Ware) Date: Mon, 11 Jan 2016 17:32:47 +0000 Subject: [issue26079] Build with Visual Studio 2015 using PlatformToolset=v120 In-Reply-To: <1452533176.84.0.326228606011.issue26079@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: The fewer patches we carry against Tcl/Tk the better. This can be revisited if necessary when other ICC issues with our Tcl/Tk build are fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:33:04 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jan 2016 17:33:04 +0000 Subject: [issue26050] Add new StreamReader.readuntil() method In-Reply-To: <1452285476.14.0.419432816204.issue26050@psf.upfronthosting.co.za> Message-ID: <20160111173259.70895.27607@psf.io> Roundup Robot added the comment: New changeset db11d0db1598 by Yury Selivanov in branch '3.4': Issue #26050: Add asyncio.StreamReader.readuntil() method. https://hg.python.org/cpython/rev/db11d0db1598 New changeset a6288fe5420f by Yury Selivanov in branch '3.5': Merge 3.4 (Issue #26050) https://hg.python.org/cpython/rev/a6288fe5420f New changeset c2cd3b435afe by Yury Selivanov in branch 'default': Merge 3.5 (issue #26050) https://hg.python.org/cpython/rev/c2cd3b435afe ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:33:33 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Jan 2016 17:33:33 +0000 Subject: [issue26050] Add new StreamReader.readuntil() method In-Reply-To: <1452285476.14.0.419432816204.issue26050@psf.upfronthosting.co.za> Message-ID: <1452533613.46.0.971184196786.issue26050@psf.upfronthosting.co.za> Yury Selivanov added the comment: Leaving this issue open until we have the docs committed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:35:00 2016 From: report at bugs.python.org (Ramin Farajpour Cami) Date: Mon, 11 Jan 2016 17:35:00 +0000 Subject: [issue26059] Integer Overflow in strop.replace() In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za> Message-ID: <1452533700.36.0.584377088783.issue26059@psf.upfronthosting.co.za> Ramin Farajpour Cami added the comment: please look image : Thanks, ---------- Added file: http://bugs.python.org/file41580/123.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:37:56 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Jan 2016 17:37:56 +0000 Subject: [issue26058] PEP 509: Add ma_version to PyDictObject In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za> Message-ID: <1452533876.89.0.00290414377983.issue26058@psf.upfronthosting.co.za> STINNER Victor added the comment: Patch version 3 updated for the second version of the PEP 509. Main changes: * ma_version now has the type PY_UINT64_T * remove dict.__version__ property: replace with _testcapi.dict_get_version() for tests ---------- versions: +Python 3.6 -Python 2.7 Added file: http://bugs.python.org/file41581/dict_version-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:50:03 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Jan 2016 17:50:03 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1452534603.32.0.642259323532.issue22995@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Therefore my guess was true. There is a bug in Cython. It creates classes that can't be correctly unpickled or copied. The question is wherever we should replace TypeError with a warning in maintained releases, or remove this check at all? Here is a patch against 3.5 that replaces TypeError with a warning. ---------- stage: resolved -> patch review versions: -Python 3.6 Added file: http://bugs.python.org/file41582/pickle_restrictions_warning-3.5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:52:59 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Jan 2016 17:52:59 +0000 Subject: [issue26059] Integer Overflow in strop.replace() In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za> Message-ID: <1452534779.74.0.0896374525406.issue26059@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't have a Windows machine too. ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 13:00:12 2016 From: report at bugs.python.org (Ramin Farajpour Cami) Date: Mon, 11 Jan 2016 18:00:12 +0000 Subject: [issue26059] Integer Overflow in strop.replace() In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za> Message-ID: <1452535212.36.0.702089841238.issue26059@psf.upfronthosting.co.za> Ramin Farajpour Cami added the comment: also linux Ubuntu version Python 2.7.6 ---------- Added file: http://bugs.python.org/file41583/12.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 13:10:27 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Jan 2016 18:10:27 +0000 Subject: [issue26059] Integer Overflow in strop.replace() In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za> Message-ID: <1452535827.07.0.952822780467.issue26059@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 2.7.6 and 2.7.10 are outdated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 13:16:36 2016 From: report at bugs.python.org (Ramin Farajpour Cami) Date: Mon, 11 Jan 2016 18:16:36 +0000 Subject: [issue26059] Integer Overflow in strop.replace() In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za> Message-ID: <1452536196.64.0.600318561329.issue26059@psf.upfronthosting.co.za> Ramin Farajpour Cami added the comment: I say work this problem on version 2.7.11 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 13:36:55 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 11 Jan 2016 18:36:55 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1452534603.32.0.642259323532.issue22995@psf.upfronthosting.co.za> Message-ID: <20160111133650.6d640e88@anarchist.wooz.org> Barry A. Warsaw added the comment: On Jan 11, 2016, at 05:50 PM, Serhiy Storchaka wrote: > >Therefore my guess was true. There is a bug in Cython. It creates classes >that can't be correctly unpickled or copied. I don't think that's necessarily true. Clearly the classes *can* be copied and unpickled because they *are*, otherwise Cython builds would be failing for a long time now, and I can find no evidence of that either in Debian/Ubuntu packages which use Cython nor in upstream bug reports for Cython or the affected packages. It's just as likely that the assumptions of the typeobject.c code are incorrect. >The question is wherever we should replace TypeError with a warning in >maintained releases, or remove this check at all? Here is a patch against 3.5 >that replaces TypeError with a warning. I am final testing a patch to typeobject.c that ifdefs that test out in 2.7, 3.5 and 3.6. I think given the observed regressions, this is the right way to go for now. If you can figure out more detail about what's going on and can adjust the change to avoid the regressions, then this code can be unifdef'd away and fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 13:49:49 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jan 2016 18:49:49 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <20160111184946.4242.279@psf.io> Roundup Robot added the comment: New changeset e79eddcdff63 by Barry Warsaw in branch '3.5': Issue #22995: [UPDATE] Comment out the one of the pickleability tests in https://hg.python.org/cpython/rev/e79eddcdff63 New changeset 927fd0e14d49 by Barry Warsaw in branch 'default': Issue #22995: [UPDATE] Comment out the one of the pickleability tests in https://hg.python.org/cpython/rev/927fd0e14d49 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 14:20:49 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Jan 2016 19:20:49 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1452540049.79.0.0210008431407.issue22995@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The classes can't be *correctly* copied and unpickled because the pickle data doesn't contain object's state. "Copied" and "unpickled" objects are not equal to original objects, they are non-initialized instances. You can test attributes of copied NameAssignment instance to ensure that they are not restored. May be copied values are not used in Cython building, except rare exclusive cases when using them fails. Example in the stdlib is csv.Dialect objects: >>> import csv, pickle >>> d = csv.get_dialect('excel-tab') >>> d2 = pickle.loads(pickle.dumps(d)) >>> d.delimiter, d.doublequote, d.escapechar, d.lineterminator, d.quotechar, d.quoting, d.skipinitialspace, d.strict ('\t', 1, None, '\r\n', '"', 0, 0, 0) >>> d2.delimiter, d2.doublequote, d2.escapechar, d2.lineterminator, d2.quotechar, d2.quoting, d2.skipinitialspace, d2.strict (',', 1, None, '\r\n', '"', 0, 0, 0) You just silently get wrong result. Since it by accident matches the instance of most used 'excel' dialect, this error is left unnoticed. I think we have to left this restriction in 3.6 (and Cython should fix its bug by providing either __getnewargs__/ __getnewargs_ex__, __getstate__ or __reduce__/__reduce_ex__). But in 2.7 and 3.5 we should allow current Cython to work (even obtaining wrong result) by removing the check at all or by making it emit only a warning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 14:23:57 2016 From: report at bugs.python.org (Chiu-Hsiang Hsu) Date: Mon, 11 Jan 2016 19:23:57 +0000 Subject: [issue26082] functools.lru_cache user specified cachedict support Message-ID: <1452540237.19.0.595360503064.issue26082@psf.upfronthosting.co.za> New submission from Chiu-Hsiang Hsu: Currently, lru_cache will automatically construct a Python dictionary in the function as cachedict. IMHO, it will be much more flexible to let users specified their cachedict, so they can use any kind of dict-like calss as their cachedict. Thus, users can use any dictionary implementation and save result in any form they want. for example : use OrderedDict .. code-block:: python from functools import lru_cache from collections import OrderedDict @lru_cache(maxsize=None, cache=OrderedDict()) def func(*args, **kwargs): pass save by pickle .. code-block:: python import os import pickle from functools import lru_cache filename = "cache.pickle" cache = {} def load_cache(): global cache if os.path.isfile(filename): with open(filename, "rb") as f: cache = pickle.load(f) def store_cache(): with open(filename, "wb") as f: pickle.dump(cache, f) load_cache() @lru_cache(maxsize=None, cache=cache) def func(*args, **kwargs): pass ---------- components: Library (Lib) files: functools.lru_cache-user-specified-cachedict.patch keywords: patch messages: 258001 nosy: wdv4758h priority: normal severity: normal status: open title: functools.lru_cache user specified cachedict support type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file41584/functools.lru_cache-user-specified-cachedict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 14:24:18 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 11 Jan 2016 19:24:18 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1452540049.79.0.0210008431407.issue22995@psf.upfronthosting.co.za> Message-ID: <20160111142414.4e14e886@anarchist.wooz.org> Barry A. Warsaw added the comment: On Jan 11, 2016, at 07:20 PM, Serhiy Storchaka wrote: >I think we have to left this restriction in 3.6 (and Cython should fix its >bug by providing either __getnewargs__/ __getnewargs_ex__, __getstate__ or >__reduce__/__reduce_ex__). But in 2.7 and 3.5 we should allow current Cython >to work (even obtaining wrong result) by removing the check at all or by >making it emit only a warning. I'm okay with reverting the change in 2.7 and 3.5 since those are clearly regressions (whether or not Cython unpickles/copies correctly build failures are regressions). I'm also okay with leaving the restriction in 3.6, at least for now. We can let Cython upstream complain if they disagree with the location of the bug. I will update the various branches. Thanks for the good discussion! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 14:28:12 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 11 Jan 2016 19:28:12 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1452540492.08.0.349918410129.issue22995@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: BTW Serhiy, can you please file a bug with upstream Cython? I think you're the right person to do it since you added this restriction. With reverting this in 2.7 and 3.5 it's not urgent, but we don't want to have to reopen this when 3.6 is out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 14:36:44 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Jan 2016 19:36:44 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1452541004.56.0.706204635609.issue22995@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 14:45:07 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jan 2016 19:45:07 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <20160111194504.31073.23744@psf.io> Roundup Robot added the comment: New changeset 9d3ac16b78dc by Barry Warsaw in branch '2.7': Issue #22995: [UPDATE] Comment out the one of the pickleability tests in https://hg.python.org/cpython/rev/9d3ac16b78dc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 15:05:43 2016 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 11 Jan 2016 20:05:43 +0000 Subject: [issue26061] logging LogRecordFactory allow kwargs In-Reply-To: <1452348721.62.0.0659441609169.issue26061@psf.upfronthosting.co.za> Message-ID: <1452542743.5.0.581494352627.issue26061@psf.upfronthosting.co.za> Vinay Sajip added the comment: That the LogRecord receives kwargs is an internal implementation detail - note that it is not mentioned in the documentation, and not even currently used there. If you want to pass additional information to be stored in the record, use the documented approach - which is to pass a dictionary in the "extra" keyword argument containing the additional fields to add. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 15:16:16 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jan 2016 20:16:16 +0000 Subject: [issue25486] Resurrect inspect.getargspec() in 3.6 In-Reply-To: <1445891623.91.0.591196153919.issue25486@psf.upfronthosting.co.za> Message-ID: <20160111201601.70897.27018@psf.io> Roundup Robot added the comment: New changeset 32c8bdcd66cc by Yury Selivanov in branch 'default': Issue #25486: Resurrect inspect.getargspec in 3.6. Backout a565aad5d6e1. https://hg.python.org/cpython/rev/32c8bdcd66cc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 15:17:11 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Jan 2016 20:17:11 +0000 Subject: [issue25486] Resurrect inspect.getargspec() in 3.6 In-Reply-To: <1445891623.91.0.591196153919.issue25486@psf.upfronthosting.co.za> Message-ID: <1452543431.6.0.126150718065.issue25486@psf.upfronthosting.co.za> Yury Selivanov added the comment: inspect.getargspec is back to Python 3.6 (it was never removed from <= 3.5, fwiw) ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 15:25:43 2016 From: report at bugs.python.org (Stefan Krah) Date: Mon, 11 Jan 2016 20:25:43 +0000 Subject: [issue25486] Resurrect inspect.getargspec() in 3.6 In-Reply-To: <1452543431.6.0.126150718065.issue25486@psf.upfronthosting.co.za> Message-ID: <20160111202533.GA3444@bytereef.org> Stefan Krah added the comment: On Mon, Jan 11, 2016 at 08:17:11PM +0000, Yury Selivanov wrote: > inspect.getargspec is back to Python 3.6 (it was never removed from <= 3.5, fwiw) Yay! Thank you very much! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 15:41:10 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 11 Jan 2016 20:41:10 +0000 Subject: [issue25596] Use scandir() to speed up the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1452544870.14.0.0133933418026.issue25596@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks like switching to scandir will also resolve http://bugs.python.org/issue22167 without further action. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 15:41:40 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 11 Jan 2016 20:41:40 +0000 Subject: [issue22167] iglob() has misleading documentation (does indeed store names internally) In-Reply-To: <1407460141.27.0.298063472331.issue22167@psf.upfronthosting.co.za> Message-ID: <1452544900.13.0.322440135756.issue22167@psf.upfronthosting.co.za> Guido van Rossum added the comment: Once http://bugs.python.org/issue25596 (switching glob to use scandir) is solved this issue can be closed IMO. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 15:43:15 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Mon, 11 Jan 2016 20:43:15 +0000 Subject: [issue26083] ValueError: insecure string pickle in subprocess.Popen on Python 2 Message-ID: <1452544995.42.0.684031601483.issue26083@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: Originally reported at [1] and [2]. On Mac OS X, read() on pipes may return only the first 512 bytes. The remaining bytes are not read into `data` in _execute_child(). There's a patch proposal at [3]. I didn't test it myself because I can't reproduce the broken situation. [1] https://github.com/rg3/youtube-dl/issues/6840 [2] https://github.com/matplotlib/matplotlib/issues/5386 [3] https://github.com/matplotlib/matplotlib/issues/5386#issuecomment-161111817 ---------- components: Library (Lib), Macintosh messages: 258011 nosy: Chi Hsuan Yen, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: ValueError: insecure string pickle in subprocess.Popen on Python 2 type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 15:43:37 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jan 2016 20:43:37 +0000 Subject: [issue24705] sysconfig._parse_makefile doesn't expand ${} vars appearing before $() vars In-Reply-To: <1437739980.61.0.17161588188.issue24705@psf.upfronthosting.co.za> Message-ID: <20160111204334.4252.91789@psf.io> Roundup Robot added the comment: New changeset ef84d21f5292 by doko in branch '3.5': - Issue #24705: Fix sysconfig._parse_makefile not expanding ${} vars https://hg.python.org/cpython/rev/ef84d21f5292 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 15:48:45 2016 From: report at bugs.python.org (Tom Anderl) Date: Mon, 11 Jan 2016 20:48:45 +0000 Subject: [issue26084] HTMLParser mishandles last attribute in self-closing tag Message-ID: <1452545325.06.0.546064798317.issue26084@psf.upfronthosting.co.za> New submission from Tom Anderl: When the HTMLParser encounters a start tag element that includes: 1. an unquoted attribute as the final attribute 2. an optional '/' character marking the start tag as self-closing 3. no space between the final attribute and the '/' character the '/' character gets attached to the attribute value and the element is interpreted as not self-closing. This can be illustrated with the following: =============================================================================== import HTMLParser # Begin Monkeypatch #import re #HTMLParser.attrfind = re.compile( # r'((?<=[\'"\s/])[^\s/>][^\s/=>]*)(\s*=+\s*' # r'(\'[^\']*\'|"[^"]*"|(?![\'"])[^/>\s]*))?(?:\s|/(?!>))*') # End Monkeypatch class MyHTMLParser(HTMLParser.HTMLParser): def handle_starttag(self, tag, attrs): print('got starttag: {0} with attributes {1}'.format(tag, attrs)) def handle_endtag(self, tag): print('got endtag: {0}'.format(tag)) MyHTMLParser().feed('') ============================================================================== Running the above code yields the output: got starttag: img with attributes [('height', '1.0'), ('width', '2.0/')] Note the trailing '/' on the 'width' attribute. If I uncomment the monkey patch, the script then yields: got starttag: img with attributes [('height', '1.0'), ('width', '2.0')] got endtag: img Note that the trailing '/' is gone, and an endtag event was generated. ---------- components: Library (Lib) messages: 258013 nosy: Tom Anderl priority: normal severity: normal status: open title: HTMLParser mishandles last attribute in self-closing tag type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 15:50:26 2016 From: report at bugs.python.org (Maciej Szulik) Date: Mon, 11 Jan 2016 20:50:26 +0000 Subject: [issue23942] Explain naming of the patch files in the bug tracker In-Reply-To: <1428966137.48.0.790822523429.issue23942@psf.upfronthosting.co.za> Message-ID: <1452545426.63.0.537065831283.issue23942@psf.upfronthosting.co.za> Maciej Szulik added the comment: Ezio, I've meant we should provide some guidelines with information the system will pick whatever they choose based on submission date. More informational than as a requirement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 15:53:33 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 11 Jan 2016 20:53:33 +0000 Subject: [issue26084] HTMLParser mishandles last attribute in self-closing tag In-Reply-To: <1452545325.06.0.546064798317.issue26084@psf.upfronthosting.co.za> Message-ID: <1452545613.6.0.905735951473.issue26084@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti nosy: +ezio.melotti stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 15:56:44 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Jan 2016 20:56:44 +0000 Subject: [issue25596] Use scandir() to speed up the glob module In-Reply-To: <1447154287.89.0.207791672282.issue25596@psf.upfronthosting.co.za> Message-ID: <1452545804.5.0.768231489335.issue25596@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Not this version of the path. It accumulates all scandir results in a list before yielding values. Otherwise globbing will consume a lot of open file descriptors and could leak them (see issue25994, issue25995). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 15:57:06 2016 From: report at bugs.python.org (Maciej Szulik) Date: Mon, 11 Jan 2016 20:57:06 +0000 Subject: [issue11245] Implementation of IMAP IDLE in imaplib? In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za> Message-ID: <1452545826.1.0.720292996955.issue11245@psf.upfronthosting.co.za> Changes by Maciej Szulik : ---------- nosy: +maciej.szulik _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 15:57:29 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 11 Jan 2016 20:57:29 +0000 Subject: [issue23942] Explain naming of the patch files in the bug tracker In-Reply-To: <1428966137.48.0.790822523429.issue23942@psf.upfronthosting.co.za> Message-ID: <1452545849.37.0.258180056037.issue23942@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 15:58:48 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 11 Jan 2016 20:58:48 +0000 Subject: [issue25596] Use scandir() to speed up the glob module In-Reply-To: <1452545804.5.0.768231489335.issue25596@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Oh well. Too bad. Never mind then. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 16:08:07 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 11 Jan 2016 21:08:07 +0000 Subject: [issue25994] File descriptor leaks in os.scandir() In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za> Message-ID: <1452546487.15.0.536345791142.issue25994@psf.upfronthosting.co.za> Guido van Rossum added the comment: Note there's also a nasty corner case related to generators and GC. If a generator contains a with-block or finally-clause, and the generator is not run until its end because the caller hit an exception on one of the items returned, and the generator object is somehow kept alive (either because it's stored in some longer-living state or because the Python implementation doesn't use reference counting) then the close() call in the finally-clause or in the __exit__ method doesn't run until the generator object is garbage-collected. IOW even making it a context manager doesn't completely solve this issue (though it can certainly help). ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 16:10:38 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 11 Jan 2016 21:10:38 +0000 Subject: [issue25995] os.walk() consumes a lot of file descriptors In-Reply-To: <1451757425.39.0.0524932176307.issue25995@psf.upfronthosting.co.za> Message-ID: <1452546638.83.0.379676976312.issue25995@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't like the first solution (it just collects all scandir() results in a list, which defeats one of the purposes of using scandir()), but I don't understand the second solution. Ideally the number of FDs used should be limited by the depth of the tree being walked, right? ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 16:12:36 2016 From: report at bugs.python.org (fresh_nick) Date: Mon, 11 Jan 2016 21:12:36 +0000 Subject: [issue26085] Tkinter spoils the input text Message-ID: <1452546756.92.0.853539899898.issue26085@psf.upfronthosting.co.za> New submission from fresh_nick: Hello, I have Python 3.4.3 and Tk/Tcl 8.5 (built in Python; reported by tk.TclVersion and tk.TkVersion). When I assign printing 'This works' to a hotkey, the program prints 'This worsk'. After pressing the hotkey again, 'worsk' is replaced with 'works', but when the hotkey is pressed repeatedly, we can see 'worsk' sometimes (see the attachment). Have a nice day. ---------- components: Tkinter files: 2016-01-11--1452545267_1920x1080_scrot.png messages: 258019 nosy: fresh_nick priority: normal severity: normal status: open title: Tkinter spoils the input text type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file41585/2016-01-11--1452545267_1920x1080_scrot.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 16:14:09 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 11 Jan 2016 21:14:09 +0000 Subject: [issue26083] ValueError: insecure string pickle in subprocess.Popen on Python 2 In-Reply-To: <1452544995.42.0.684031601483.issue26083@psf.upfronthosting.co.za> Message-ID: <1452546849.21.0.756347255308.issue26083@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 16:31:51 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jan 2016 21:31:51 +0000 Subject: [issue25991] readline example eventually consumes all memory In-Reply-To: <1451708933.83.0.797303528676.issue25991@psf.upfronthosting.co.za> Message-ID: <20160111213148.31083.81616@psf.io> Roundup Robot added the comment: New changeset 9a2c891a4333 by Ezio Melotti in branch '2.7': #25991: fix readline example to limit history size. Patch by Daniel Dye. https://hg.python.org/cpython/rev/9a2c891a4333 New changeset 416db1a2fb81 by Ezio Melotti in branch '3.5': #25991: fix readline example to limit history size. Patch by Daniel Dye. https://hg.python.org/cpython/rev/416db1a2fb81 New changeset cb08e5271cc0 by Ezio Melotti in branch 'default': #25991: merge with 3.5. https://hg.python.org/cpython/rev/cb08e5271cc0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 16:32:45 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 11 Jan 2016 21:32:45 +0000 Subject: [issue25991] readline example eventually consumes all memory In-Reply-To: <1451708933.83.0.797303528676.issue25991@psf.upfronthosting.co.za> Message-ID: <1452547965.68.0.627583498228.issue25991@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 16:35:22 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Jan 2016 21:35:22 +0000 Subject: [issue25995] os.walk() consumes a lot of file descriptors In-Reply-To: <1451757425.39.0.0524932176307.issue25995@psf.upfronthosting.co.za> Message-ID: <1452548122.1.0.103553265034.issue25995@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Both patches are basically equivalent. The first one collects all scandir() results in a list, the second one collects only directory names in a list. The purpose of using os.scandir() in os.walk() was a speed up (issue23605), and both patches preserve it. Yes, the number of FDs used is equivalent to the depth of the tree which can be very deep (I just created a tree depth of 1000 levels). And what is worse, all these FDs can be effectively leaked if the walking was not finished. This is unwanted behavior change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 16:35:26 2016 From: report at bugs.python.org (Hana Larsen) Date: Mon, 11 Jan 2016 21:35:26 +0000 Subject: [issue26086] Bug in standardmodule os Message-ID: <1452548126.01.0.956593686661.issue26086@psf.upfronthosting.co.za> New submission from Hana Larsen: I get a error in the stardard module "os" (I use Python 3.5.1 64bit for Windows 10!) What is wrong and have someone a patch See the "os-bug.PNG"-file. ---------- files: os-bug.PNG messages: 258023 nosy: Johano priority: normal severity: normal status: open title: Bug in standardmodule os type: crash versions: Python 3.5 Added file: http://bugs.python.org/file41586/os-bug.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 16:36:37 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 11 Jan 2016 21:36:37 +0000 Subject: [issue24918] Docs layout bug In-Reply-To: <1440361207.71.0.0873906255469.issue24918@psf.upfronthosting.co.za> Message-ID: <1452548197.34.0.0711503045168.issue24918@psf.upfronthosting.co.za> Ezio Melotti added the comment: Georg, do you have any opinion on this? AFAIK all the div.highlight contain a 
 with the actual code and it's own background color, so using background: none; should be fine.

----------
nosy: +georg.brandl
stage: needs patch -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 16:37:41 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 11 Jan 2016 21:37:41 +0000
Subject: [issue26041] Update deprecation messages of platform.dist() and
 platform.linux_distribution()
In-Reply-To: <1452187100.03.0.384540652472.issue26041@psf.upfronthosting.co.za>
Message-ID: <1452548261.66.0.910514426619.issue26041@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
stage: needs patch -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 16:42:12 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 11 Jan 2016 21:42:12 +0000
Subject: [issue25995] os.walk() consumes a lot of file descriptors
In-Reply-To: <1452548122.1.0.103553265034.issue25995@psf.upfronthosting.co.za>
Message-ID: 


Guido van Rossum added the comment:

I am all for preventing the leaks. But using FDs proportional to the tree
depth seems reasonable to me. (If you are worried about some kind of DoS
attack on the algorithm by someone who can build a tree with depth 1000,
well, if they can do that they can also create a flat folder with a million
files in it.)

Is there a potential hybrid strategy, where for small directories we close
the FD but for large directories we keep it open?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 16:49:23 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 11 Jan 2016 21:49:23 +0000
Subject: [issue26067] test_shutil fails when gid name is missing
In-Reply-To: <1452373835.73.0.278108988814.issue26067@psf.upfronthosting.co.za>
Message-ID: <1452548963.68.0.522171606313.issue26067@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

We looked at this at the PyLadies Sprint in Helsinki.
When the group has an id but not a name (see "gid=203135016" in the "id" output -- the name is missing), its entry is missing from the list returned by grp.getgrall().

If this behaviour is expected and desired, then the test should be fixed to handle cases where the name is missing and the KeyError is raised.
Otherwise, the entry could still be included with "None" as name.

----------
nosy: +serhiy.storchaka
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 16:50:17 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 11 Jan 2016 21:50:17 +0000
Subject: [issue26083] ValueError: insecure string pickle in subprocess.Popen
 on Python 2
In-Reply-To: <1452544995.42.0.684031601483.issue26083@psf.upfronthosting.co.za>
Message-ID: <1452549017.61.0.882376279843.issue26083@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I strongly recommend people use https://pypi.python.org/pypi/subprocess32/ instead of Python 2.7's subprocess module whenever possible.

That said, the fix is pretty easy.

----------
assignee:  -> gregory.p.smith

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 16:55:05 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 11 Jan 2016 21:55:05 +0000
Subject: [issue26068] re.compile() repr end quote truncated
In-Reply-To: <1452374298.65.0.166509982693.issue26068@psf.upfronthosting.co.za>
Message-ID: <1452549305.22.0.250063764872.issue26068@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

FTR the repr was added in #13592.

----------
nosy: +serhiy.storchaka
type:  -> behavior
versions: +Python 3.5, Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 16:57:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Jan 2016 21:57:05 +0000
Subject: [issue26083] ValueError: insecure string pickle in subprocess.Popen
 on Python 2
In-Reply-To: <1452544995.42.0.684031601483.issue26083@psf.upfronthosting.co.za>
Message-ID: <20160111215658.69143.92785@psf.io>


Roundup Robot added the comment:

New changeset 268d13c7e939 by Gregory P. Smith in branch '2.7':
Fixes issue #26083: Workaround a subprocess bug that raised an incorrect
https://hg.python.org/cpython/rev/268d13c7e939

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 16:58:32 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 11 Jan 2016 21:58:32 +0000
Subject: [issue26083] ValueError: insecure string pickle in subprocess.Popen
 on Python 2
In-Reply-To: <1452544995.42.0.684031601483.issue26083@psf.upfronthosting.co.za>
Message-ID: <1452549512.69.0.380131667208.issue26083@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

note: this was not a security issue nor was it a crash.  an exception was being raised anyways from the forked child prior to the exec(), this bug just caused that to be swallowed and this ValueError raised instead.

----------
resolution:  -> fixed
stage:  -> commit review
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 17:00:51 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Jan 2016 22:00:51 +0000
Subject: [issue26063] Update copyright in the devguide
In-Reply-To: <1452349837.88.0.575893993486.issue26063@psf.upfronthosting.co.za>
Message-ID: <20160111220048.27366.4338@psf.io>


Roundup Robot added the comment:

New changeset a4c18139d9b0 by Ezio Melotti in branch 'default':
#26063: future-proof copyright updating.
https://hg.python.org/devguide/rev/a4c18139d9b0

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 17:11:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Jan 2016 22:11:41 +0000
Subject: [issue25517] regex howto example in "Lookahead Assertions"
In-Reply-To: <1446199646.71.0.249231376897.issue25517@psf.upfronthosting.co.za>
Message-ID: <20160111221138.27362.76081@psf.io>


Roundup Robot added the comment:

New changeset c6b5c03183e3 by Ezio Melotti in branch '2.7':
#25517: fix regex in the regex howto.  Patch by Elena Oat.
https://hg.python.org/cpython/rev/c6b5c03183e3

New changeset 6bd4a4907f66 by Ezio Melotti in branch '3.5':
#25517: fix regex in the regex howto.  Patch by Elena Oat.
https://hg.python.org/cpython/rev/6bd4a4907f66

New changeset 48e2f5915d49 by Ezio Melotti in branch 'default':
#25517: merge with 3.5.
https://hg.python.org/cpython/rev/48e2f5915d49

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 17:12:26 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 11 Jan 2016 22:12:26 +0000
Subject: [issue25517] regex howto example in "Lookahead Assertions"
In-Reply-To: <1446199646.71.0.249231376897.issue25517@psf.upfronthosting.co.za>
Message-ID: <1452550346.24.0.0713983984687.issue25517@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 17:15:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Jan 2016 22:15:28 +0000
Subject: [issue25967] Devguide: add 2to3 to the "Changing CPython's Grammar"
 checklist
In-Reply-To: <1451340554.37.0.242024647268.issue25967@psf.upfronthosting.co.za>
Message-ID: <20160111221520.47405.14163@psf.io>


Roundup Robot added the comment:

New changeset 367486fbab84 by Ezio Melotti in branch 'default':
#25967: add note about updating lib2to3 when the grammar is updated.  Patch by Chris Thomas.
https://hg.python.org/devguide/rev/367486fbab84

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 17:15:38 2016
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 11 Jan 2016 22:15:38 +0000
Subject: [issue26083] ValueError: insecure string pickle in subprocess.Popen
 on Python 2
In-Reply-To: <1452544995.42.0.684031601483.issue26083@psf.upfronthosting.co.za>
Message-ID: <1452550538.43.0.0247360287633.issue26083@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> I strongly recommend people use https://pypi.python.org/pypi/subprocess32/

I think this warrants a note that draws more attention to itself than the "see also" text.

----------
nosy: +eryksun

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 17:15:47 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 11 Jan 2016 22:15:47 +0000
Subject: [issue25967] Devguide: add 2to3 to the "Changing CPython's Grammar"
 checklist
In-Reply-To: <1451340554.37.0.242024647268.issue25967@psf.upfronthosting.co.za>
Message-ID: <1452550547.63.0.511895800661.issue25967@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 17:25:53 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 11 Jan 2016 22:25:53 +0000
Subject: [issue19251] bitwise ops for bytes of equal length
In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za>
Message-ID: <1452551153.77.0.364915399004.issue19251@psf.upfronthosting.co.za>


Changes by Gregory P. Smith :


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 17:57:44 2016
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 11 Jan 2016 22:57:44 +0000
Subject: [issue26086] Bug in standardmodule os
In-Reply-To: <1452548126.01.0.956593686661.issue26086@psf.upfronthosting.co.za>
Message-ID: <1452553064.74.0.230830068722.issue26086@psf.upfronthosting.co.za>


Eryk Sun added the comment:

The "yield from" syntax was added in Python 3.3, so somehow you're using the 3.5 standard library with either an old 3.x or 2.x version. The older version shouldn't use 3.5's standard library, unless you have either PYTHONHOME or PYTHONPATH defined. Generally neither of these variables should be defined, especially not PYTHONHOME. In the command prompt run "set PYTHON" to list all environment variables that start with "PYTHON".

You also appear to be running with the 3.5 site-packages as the working directory. Even without the other problems, I recommend against this since the current directory has precedence in sys.path. You're moving site-packages to the head of the list, in front of the standard library. For example:

    C:\Program Files\Python35\Lib\site-packages>type subprocess.py
    print("This isn't the subprocess you're looking for.")

    C:\Program Files\Python35\Lib\site-packages>py -3 -c "import subprocess"
    This isn't the subprocess you're looking for.

Save your scripts in the top-level Scripts directory or a directory in your user profile. Generally leave everything under Lib alone, to be managed by pip and other installers.

----------
nosy: +eryksun

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 17:58:08 2016
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 11 Jan 2016 22:58:08 +0000
Subject: [issue26086] Bug in standardmodule os
In-Reply-To: <1452548126.01.0.956593686661.issue26086@psf.upfronthosting.co.za>
Message-ID: <1452553088.57.0.538926519717.issue26086@psf.upfronthosting.co.za>


Changes by Eryk Sun :


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 18:17:10 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 11 Jan 2016 23:17:10 +0000
Subject: [issue23942] Explain naming of the patch files in the bug tracker
In-Reply-To: <1428966137.48.0.790822523429.issue23942@psf.upfronthosting.co.za>
Message-ID: <1452554230.3.0.0508834376526.issue23942@psf.upfronthosting.co.za>


Martin Panter added the comment:

I guess if people wonder about this, you could at least say the naming doesn?t matter very much for the review system.

If I am generating my own patches, I try to name them with one or two concise words describing the particular solution, and then insert ?.v2?, ?.v3? etc for the revised patches. If I just gave them an issue number, it would get lost my Mercurial patch queue among a sea of other numbers. If I did not add the ?.v2? revision number, people would have to refer to the patches by upload date rather than name or version.

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 18:52:33 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 11 Jan 2016 23:52:33 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1452556353.86.0.472448919885.issue25887@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Attaching another patch.  Please review (I plan to commit it tomorrow in 3.5 and 3.6 branches).

The patch affects generators machinery in the following way:

1. Generators behaviour isn't touched, the patch is only for 'async def' coroutines.

2. Calling 'send()' or 'throw()' on a coroutine object after it is exhausted or closed triggers a `RuntimeError("coroutine was already awaited")`

3. Calling 'close()' method on an exhausted or closed coroutines is a no-op.  'close()' can be called multiple times -- same as for generators.

----------
Added file: http://bugs.python.org/file41587/Issue25887_3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 18:52:45 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 11 Jan 2016 23:52:45 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1452556365.52.0.536568542679.issue25994@psf.upfronthosting.co.za>


Martin Panter added the comment:

Guido are you saying in the following code, the ?finally? message is not guaranteed to be printed out? Or just that you cannot limit a ResourceWarning to garbage collection?

def g():
    try:
        yield "item"
    finally:
        # Run at exhaustion, close(), and garbage collection
        print("finally")

gi = g()
try:
    item = next(gi)
    print(item / 2)  # Oops, TypeError
finally:
    # Should be run as the exception passes through. GeneratorExit is raised inside the generator, causing the other ?finally? block to execute. All before the original exception is caught and a traceback is printed.
    gi.close()

But as I understand it, os.scandir() is not a generator, so none of these problems would apply.

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 18:58:31 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 11 Jan 2016 23:58:31 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1452556711.77.0.0728685716786.issue25887@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I don't like "coroutine was already awaited". I feel like either "on" should be appended to that or another sentence like "coroutine had 'await' called on it" or something.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 19:00:47 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 12 Jan 2016 00:00:47 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1452556847.85.0.562319998193.issue25887@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> I don't like "coroutine was already awaited". I feel like either "on" should be appended to that or another sentence like "coroutine had 'await' called on it" or something.

Fine with me to have "coroutine was already awaited on".

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 19:07:49 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 12 Jan 2016 00:07:49 +0000
Subject: [issue25888] awaiting on coroutine that is being awaited should be an
 error
In-Reply-To: <1450302672.61.0.939075659371.issue25888@psf.upfronthosting.co.za>
Message-ID: <1452557269.55.0.521073820946.issue25888@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Will commit this patch tomorrow to 3.5 and 3.6.

It only affects coroutines (async defs): if an await expression is used on a coroutine object while it's being already awaited by another coroutine, a `RuntimeError("coroutine is being awaited already")` will be triggered.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 19:35:00 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 12 Jan 2016 00:35:00 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1452558900.84.0.195247609489.issue25887@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The patch looks good to me, but I'd like to see the error message convey two points:
- the coroutine has already terminated (regardless of how that happened)
- the calling code attempted to resume it anyway

That is, something like "Cannot resume terminated coroutine", rather than specifically referring to "await".

After all, waiting for the result with "await" is only one way to terminate a coroutine - you can also get there with direct calls to next(), send(), throw() and close().

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 19:40:11 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 12 Jan 2016 00:40:11 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1452559211.7.0.783884488227.issue25994@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

It was a bit more subtle. I think like this:

def f():
    with some_lock:
        yield 0
        yield 1

def g():
    with another_lock:
        it = f()
        for i in it:
            raise

We determined that another_lock was freed *before* some_lock.  This is because the local variable 'it' keeps the generator object returned by f() alive until after the with-block in g() has released another_lock.

I think this does not strictly require f to be a generator -- it's any kind of closable resource that only gets closed by its destructor.

The solution is to add a try/finally that calls it.close() before leaving the with-block in g().

Hope this helps.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 20:07:28 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Jan 2016 01:07:28 +0000
Subject: [issue25888] awaiting on coroutine that is being awaited should be an
 error
In-Reply-To: <1450302672.61.0.939075659371.issue25888@psf.upfronthosting.co.za>
Message-ID: <1452560848.78.0.040908693977.issue25888@psf.upfronthosting.co.za>


Martin Panter added the comment:

Missing word in a comment on the review

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 20:30:53 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Jan 2016 01:30:53 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1452562253.96.0.0167989204565.issue25994@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay I understand. You have to explicitly call the close() method if you want a generator to be cleaned up properly, which parallels how Serhiy?s proposal would be used.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 20:37:47 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Jan 2016 01:37:47 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1452562667.53.0.431941854267.issue25887@psf.upfronthosting.co.za>


Martin Panter added the comment:

The patch looks like it adds checks for the special generator-like send() etc methods, but I was expecting __await__() to also (or instead) do this check. That way you wouldn?t have to break the iterator protocol by the iterator not raising StopIteration a second time.

Also left some other review comments.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 20:37:50 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 12 Jan 2016 01:37:50 +0000
Subject: [issue26082] functools.lru_cache user specified cachedict support
In-Reply-To: <1452540237.19.0.595360503064.issue26082@psf.upfronthosting.co.za>
Message-ID: <1452562669.99.0.108106355715.issue26082@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Given that lru_cache uses the cache dict in very specific ways, supporting arbitrary mapping types would be extremely hard. Among other things:

1. The C code uses the concrete dict APIs (including private APIs) that would not work on arbitrary mappings that don't directly inherit from dict (and often wouldn't work properly even if they do inherit from dict). Changing to use the abstract mapping APIs would slow all use cases for an extremely uncommon use case.

2. The C code is operating under the assumption that specific operations cannot release the GIL (e.g. dict insertion and deletion is done after precomputing the hash of the key, so it's impossible for Python byte code to be executed), so it can safely ignore thread safety issues. If a non-dict mapping was provided, implemented in Python rather than C, these assumptions could easily be violated.

3. This is basically a superset of the request from #23030, which rhettinger has rejected (you can read the rationale there)

----------
nosy: +josh.r, rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 20:43:43 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 12 Jan 2016 01:43:43 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1452563023.39.0.668331723407.issue25887@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Nick,

> After all, waiting for the result with "await" is only one way to terminate a coroutine - you can also get there with direct calls to next(), send(), throw() and close().

Yes, but I expect that almost nobody will use 'send', 'throw' etc on coroutines, it's too low level.  In asyncio there is only one place where this magic happens.  Regular user will only understand the 'await' part -- that's why I wanted to mention it in the error message.

  async def something():
      await coro
      ^ RuntimeError('Cannot resume terminated coroutine')

The above use case might be a bit hard for users to actually understand, as opposed to

  async def something():
      await coro
      ^ RuntimeError('coroutine was already awaited on')

What do you think?

Martin, thanks for the review!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 20:44:08 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Jan 2016 01:44:08 +0000
Subject: [issue25486] Resurrect inspect.getargspec() in 3.6
In-Reply-To: <1445891623.91.0.591196153919.issue25486@psf.upfronthosting.co.za>
Message-ID: <1452563048.43.0.317544664265.issue25486@psf.upfronthosting.co.za>


Martin Panter added the comment:

Now the documentation says it will be removed in 3.6. I guess the 3.5 documentation also needs updating.

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 20:54:47 2016
From: report at bugs.python.org (Mike Taylor)
Date: Tue, 12 Jan 2016 01:54:47 +0000
Subject: [issue24712] Docs page's sidebar vibrates on mouse wheel scroll on
 Chrome.
In-Reply-To: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za>
Message-ID: <1452563687.0.0.500185844243.issue24712@psf.upfronthosting.co.za>


Mike Taylor added the comment:

I can reproduce on Chrome and Firefox Nightly --

Carol, if I'd like to write a patch where would I do that? I see https://github.com/python/pythondotorg, but am not sure that's the right repo. Thanks!

----------
nosy: +Mike Taylor

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 21:02:18 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Jan 2016 02:02:18 +0000
Subject: [issue25991] readline example eventually consumes all memory
In-Reply-To: <1451708933.83.0.797303528676.issue25991@psf.upfronthosting.co.za>
Message-ID: <1452564138.02.0.513565147849.issue25991@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks Ezio for handling this. Ignore my previous comment; I missed the key word ?example? :)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 21:02:24 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 12 Jan 2016 02:02:24 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1452564144.85.0.421121955841.issue25887@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Attaching an updated patch.  The RuntimeError says 'coroutine was already awaited on' for now.

----------
Added file: http://bugs.python.org/file41588/Issue25887_4.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 21:05:24 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Jan 2016 02:05:24 +0000
Subject: [issue25486] Resurrect inspect.getargspec() in 3.6
In-Reply-To: <1445891623.91.0.591196153919.issue25486@psf.upfronthosting.co.za>
Message-ID: <20160112020520.31073.51454@psf.io>


Roundup Robot added the comment:

New changeset 36a54e30bcbd by Yury Selivanov in branch '3.5':
Issue #25486: Drop "removed in 3.6" wording from inspect.getargspec docs.
https://hg.python.org/cpython/rev/36a54e30bcbd

New changeset 4f1a0e5deca6 by Yury Selivanov in branch 'default':
Merge 3.5 (issue #25486)
https://hg.python.org/cpython/rev/4f1a0e5deca6

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 21:05:33 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 12 Jan 2016 02:05:33 +0000
Subject: [issue25486] Resurrect inspect.getargspec() in 3.6
In-Reply-To: <1445891623.91.0.591196153919.issue25486@psf.upfronthosting.co.za>
Message-ID: <1452564333.92.0.432984070813.issue25486@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Now the documentation says it will be removed in 3.6. I guess the 3.5 documentation also needs updating.

Good catch!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 21:10:11 2016
From: report at bugs.python.org (Zach Byrne)
Date: Tue, 12 Jan 2016 02:10:11 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1452564611.16.0.921565822082.issue21955@psf.upfronthosting.co.za>


Zach Byrne added the comment:

Anybody still looking at this? I can take another stab at it if it's still in scope.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 21:25:47 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Jan 2016 02:25:47 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1452565547.47.0.250186620087.issue25887@psf.upfronthosting.co.za>


Martin Panter added the comment:

If the coroutine-iterator is going to raise RuntimeError rather than StopIteration, do you think the __await__() documentation  should be clarified?

IMO ?yield from coroutine_iterator? might be plausable for some strange combination of 3.4 code and a 3.5 coroutine, but I think it would be rare. And if you added a check in __await__() then the using ?await? wouldn?t need to rely on next() raising the RuntimeError.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 21:34:49 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 12 Jan 2016 02:34:49 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1452566089.77.0.131371591519.issue25887@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> IMO ?yield from coroutine_iterator? might be plausable for some strange combination of 3.4 code and a 3.5 coroutine, but I think it would be rare. And if you added a check in __await__() then the using ?await? wouldn?t need to rely on next() raising the RuntimeError.

Adding the check *only* to __await__ will allow you to wrap an exhausted coroutine in an 'asyncio.Task' and await on it (the await will do nothing, which this patch fixes).

I think it's important to fix all coroutines' APIs to throw an error if they're manipulated in any way after being exhausted/closed, that's why I decided to fix the lower level.

To be honest, I don't care too much about 'yield from coro.__await__()' raising a RuntimeError (if the coro is an 'async def' coroutine that *is* closed/exhausted).  To me it's a clear behaviour.  Again, coroutine-iterators (objects returned by native coroutines from their __await__() method) aren't classical iterators meant to produce a fibonacci sequence in a for..in loop.  They are a low level interface to their coroutine objects.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 21:42:00 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 12 Jan 2016 02:42:00 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1452566520.21.0.58685074999.issue21955@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Anybody still looking at this? I can take another stab at it if it's still in scope.

There were some visible speedups from your patch -- I think we should merge this optimization.  Can you figure why unpack_sequence and other benchmarks were slower?

----------
nosy: +yselivanov

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 22:31:15 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 12 Jan 2016 03:31:15 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1452569475.6.0.91882007819.issue25887@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Good point about having "await" in the error message to make it more obvious what it's referring to in the "awaiting twice" case.

I'll tender "Cannot await previously awaited coroutine" as one final alternative, but if you don't like that, I can cope with "Coroutine already awaited on" :)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 22:37:31 2016
From: report at bugs.python.org (Zach Byrne)
Date: Tue, 12 Jan 2016 03:37:31 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1452569851.78.0.951467016225.issue21955@psf.upfronthosting.co.za>


Zach Byrne added the comment:

> Can you figure why unpack_sequence and other benchmarks were slower?
I didn't look really closely, A few of the slower ones were floating point heavy, which would incur the slow path penalty, but I can dig into unpack_sequence.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 23:14:32 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Tue, 12 Jan 2016 04:14:32 +0000
Subject: [issue26087] PEP 0373 should be updated
Message-ID: <1452572071.97.0.659652590609.issue26087@psf.upfronthosting.co.za>


New submission from Chi Hsuan Yen:

Current PEP 0373 lists Python 2.7.11 as a future release, and there's no information about Python 2.7.12. Please update it, thanks!

----------
assignee: docs at python
components: Documentation
messages: 258063
nosy: Chi Hsuan Yen, docs at python
priority: normal
severity: normal
status: open
title: PEP 0373 should be updated
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 23:16:35 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 12 Jan 2016 04:16:35 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1452572195.21.0.0961502446158.issue25887@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

"Cannot await previously awaited coroutine" might be confusing if raised on "coro.send(..)"-like code...

So far "coroutine was already awaited on" (do you want to drop "was", btw?) is less of all evil IMHO.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 00:39:36 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 12 Jan 2016 05:39:36 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1452577176.18.0.446696366009.issue25887@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Sorry, dropping the "was" was a typo (I should have copied & pasted it instead of rewriting).

>From the point of view of the error message, the reason I changed my suggestion was because I liked your idea of optimising it for the "only using await" case and trusting that the folks delving into the lower level plumbing of calling methods manually can figure it out. Anything that mentions await *at all* will be wrong in some cases, since what we're actually reporting is an attempt to resume (by some means) a coroutine that was previously terminated (by some means).

That is, "Cannot resume terminated coroutine" is always accurate, but relies on the reader knowing that "await" both resumes a coroutine and waits for it to terminate.

"Coroutine was previously awaited on" may be wrong about how the coroutine was originally terminated, but at least hints that the error may be related to awaiting the coroutine.

"Cannot resume previously awaited coroutine" would be inaccurate under the same circumstances.

"Cannot await previously awaited coroutine" would only be entirely accurate for "double await" errors, but doesn't rely on the reader making any assumptions at all in that case.

(The bulk of the problem here is that my brain is happy to accept "awaited" as a novel adjective modifying "coroutine", but balks at "awaited" as a verb or "awaited on" as a verb phrase. I'm extrapolating from that to guess that other folks would find the verb form similarly jarring)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 01:05:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Jan 2016 06:05:35 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1452578735.47.0.752981169125.issue25887@psf.upfronthosting.co.za>


Martin Panter added the comment:

Isn?t the combined point of this issue and Issue 25888 to make it only legal to ?await? a coroutine instance that has not yet been started? Perhaps ?Cannot [re]start terminated coroutine? would be better.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 01:21:20 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 12 Jan 2016 06:21:20 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1452579680.51.0.241949996721.issue25887@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Oh, choosing a good error message is hard :(

I've a few comments.  Sorry, this thread is growing rather rapidly, but please help me to pick one of them:


> From the point of view of the error message, the reason I changed my suggestion was because I liked your idea of optimising it for the "only using await" case and trusting that the folks delving into the lower level plumbing of calling methods manually can figure it out. [...]

We either have to use a sub-optimal error message tailored for 'await' expression users, or we can choose a longer error message.  I'm not very fond of this option, but maybe it's because I can't come up with something long and concise at the same time.  Maybe something along the lines of: "cannot resume terminated coroutine (was it awaited on before?)"


> That is, "Cannot resume terminated coroutine" is always accurate, but relies on the reader knowing that "await" both resumes a coroutine and waits for it to terminate.

Not sure I like the "terminated" word here.  The coroutine was either awaited before, which means that the coroutine object is now exhausted, or it was manually closed at some point.  To me "terminated" is closer to the latter.


> "Coroutine was previously awaited on" may be wrong about how the coroutine was originally terminated, but at least hints that the error may be related to awaiting the coroutine.

Agree.


> "Cannot resume previously awaited coroutine" would be inaccurate under the same circumstances.

Thinking about "resume"...  If a user sees this message pointing to an "await" expression, it might confuse them, since "await coro" does not just resume "coro".  It inits and consumes "coro" until it raises a StopIteration.


"Cannot await previously awaited coroutine" would only be entirely accurate for "double await" errors, but doesn't rely on the reader making any assumptions at all in that case.

Agree.  But I don't like that we have two "await" words in one short message.


> (The bulk of the problem here is that my brain is happy to accept "awaited" as a novel adjective modifying "coroutine", but balks at "awaited" as a verb or "awaited on" as a verb phrase. I'm extrapolating from that to guess that other folks would find the verb form similarly jarring)

I trust your brain here, you're a native speaker ;)  If you think that "Cannot await previously awaited coroutine" is the best option here, let's stick to it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 02:11:03 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 12 Jan 2016 07:11:03 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1452582663.25.0.234783824856.issue25887@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I expect whatever message we use will become a Stack Overflow question in fairly short order, so "good enough" is almost certainly good enough here, and I'm massively overthinking the problem :)

However, combining my last suggestion with a variant of Martin's would give us:

    "Cannot reuse already awaited coroutine"

The generic "reuse" both eliminated the repetition of "await", and also gets us away from worrying about exactly what the caller was doing.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 02:13:41 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 12 Jan 2016 07:13:41 +0000
Subject: [issue25887] awaiting on coroutine more than once should be an error
In-Reply-To: <1450302417.78.0.492418197951.issue25887@psf.upfronthosting.co.za>
Message-ID: <1452582821.2.0.982419493643.issue25887@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

>    "Cannot reuse already awaited coroutine"

Great, I like it!  Thanks Martin and Nick.

Please check out issue #25888 just in case.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 02:32:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Jan 2016 07:32:04 +0000
Subject: [issue25348] Update pgo_build.bat to use --pgo flag for regrtest
In-Reply-To: <1444346245.0.0.569960292546.issue25348@psf.upfronthosting.co.za>
Message-ID: <20160112073200.31091.16737@psf.io>


Roundup Robot added the comment:

New changeset 113c524aed93 by Zachary Ware in branch '2.7':
Issue #25348: Add --pgo and --pgo-job flags to PCbuild\build.bat
https://hg.python.org/cpython/rev/113c524aed93

New changeset 01ab138f4133 by Zachary Ware in branch '3.5':
Issue #25348: Add --pgo and --pgo-job flags to PCbuild\build.bat
https://hg.python.org/cpython/rev/01ab138f4133

New changeset 9442b4a60379 by Zachary Ware in branch 'default':
Closes #25348: Merge with 3.5
https://hg.python.org/cpython/rev/9442b4a60379

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 02:32:40 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 12 Jan 2016 07:32:40 +0000
Subject: [issue25348] Update pgo_build.bat to use --pgo flag for regrtest
In-Reply-To: <1444346245.0.0.569960292546.issue25348@psf.upfronthosting.co.za>
Message-ID: <1452583960.32.0.212991526148.issue25348@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the review, Steve.

----------
assignee: brett.cannon -> zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 02:47:17 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Jan 2016 07:47:17 +0000
Subject: [issue25788] fileinput.hook_encoded has no way to pass arguments to
 codecs
In-Reply-To: <1449160890.79.0.711012524776.issue25788@psf.upfronthosting.co.za>
Message-ID: <1452584837.61.0.000779852827639.issue25788@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

fileinput is in Python, hence the source is in Lib.  Online version is
https://hg.python.org/cpython/file/tip/Lib/fileinput.py
https://hg.python.org/cpython/file/tip/Lib/test/test_fileinput.py

Patching openhook itself looks trivial.  A test is the hard part. Laura, can you provide a test case? -- a short (one line?) file that fails with errors=strict and passes with something else?  A new test_errors method should be added to class Test_hook_encoded (the last testCase in the file).  I think the 'test' method would need revision.

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 03:14:44 2016
From: report at bugs.python.org (Hana Larsen)
Date: Tue, 12 Jan 2016 08:14:44 +0000
Subject: [issue26088] re
Message-ID: <5694B5F2.5000806@mail.dk>


New submission from Hana Larsen:

-- 
Hans Larsen Galgebakken S?nder 4-11A 2620 Albertslund Danmark/Danio

----------
messages: 258073
nosy: Johano
priority: normal
severity: normal
status: open
title: re

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 03:17:32 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2016 08:17:32 +0000
Subject: [issue26088] re
In-Reply-To: <5694B5F2.5000806@mail.dk>
Message-ID: <1452586652.81.0.785355188429.issue26088@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 03:33:50 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Jan 2016 08:33:50 +0000
Subject: [issue19316] devguide: compiler - wording
In-Reply-To: <1382272126.03.0.859419260116.issue19316@psf.upfronthosting.co.za>
Message-ID: <20160112083342.70879.36121@psf.io>


Roundup Robot added the comment:

New changeset 43d842419188 by Ezio Melotti in branch 'default':
#19316: fix wording in the compiler.rst page.
https://hg.python.org/devguide/rev/43d842419188

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 03:35:26 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2016 08:35:26 +0000
Subject: [issue19316] devguide: compiler - wording
In-Reply-To: <1382272126.03.0.859419260116.issue19316@psf.upfronthosting.co.za>
Message-ID: <1452587726.92.0.908809183117.issue19316@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks everyone for the patches and the reviews!

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 03:36:52 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Jan 2016 08:36:52 +0000
Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL
 certificate
In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za>
Message-ID: <1452587812.85.0.988687861962.issue25940@psf.upfronthosting.co.za>


Martin Panter added the comment:

This is a patch against the pythontestdotnet repository to change the certificate to have the CA flag set. It should be applied in conjunction with an (upcoming) update to the test suite, otherwise test_httplib will fail with certificate verification errors.

If I push this patch to the pythontest repository, will the server immediately update itself, or are other steps required?

----------
Added file: http://bugs.python.org/file41589/pythontest-set-ca.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 03:38:54 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2016 08:38:54 +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: <1452587934.01.0.158548091012.issue21047@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

DeprecationWarnings are silenced by default.  You can enable them by using the -W Python flag.
They are also enabled while running tests with unittest, so you should have seen them there.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 03:44:03 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Jan 2016 08:44:03 +0000
Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL
 certificate
In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za>
Message-ID: <1452588243.55.0.744502209395.issue25940@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is the corresponding patch for the test suite. This version should fix all the SSL tests as long as the server is updated.

----------
Added file: http://bugs.python.org/file41590/use-pythontest.v2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 03:47:34 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2016 08:47:34 +0000
Subject: [issue24712] Docs page's sidebar vibrates on mouse wheel scroll on
 Chrome.
In-Reply-To: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za>
Message-ID: <1452588454.51.0.447460140289.issue24712@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

CSS: Doc/tools/pydoctheme/static/pydoctheme.css
JS: Doc/tools/static/sidebar.js

The repo is https://hg.python.org/cpython/, but there should be a github mirror too.  See also the devguide for more info.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 03:50:27 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Jan 2016 08:50:27 +0000
Subject: [issue25913] base64.a85decode adobe flag incorrectly utilizes <~ as a
 marker causing error
In-Reply-To: <1450567913.0.0.974183293511.issue25913@psf.upfronthosting.co.za>
Message-ID: <1452588627.08.0.676647424425.issue25913@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Soren, for me, the page you link to is impossible to read as it blinks every second or so, something I have never seen before.  Perhaps it is trying to forward to the actual reference. As near as I can tell, it just lists about 3 other documents and is not a reference in itself, and for me has no sections.  Can you provide a better link, perhaps one that is more direct?

----------
nosy: +terry.reedy
stage:  -> test needed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 03:55:43 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 12 Jan 2016 08:55:43 +0000
Subject: [issue26087] PEP 0373 should be updated
In-Reply-To: <1452572071.97.0.659652590609.issue26087@psf.upfronthosting.co.za>
Message-ID: <1452588943.3.0.544136146922.issue26087@psf.upfronthosting.co.za>


Changes by Georg Brandl :


----------
assignee: docs at python -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 03:56:15 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 12 Jan 2016 08:56:15 +0000
Subject: [issue24918] Docs layout bug
In-Reply-To: <1440361207.71.0.0873906255469.issue24918@psf.upfronthosting.co.za>
Message-ID: <1452588975.24.0.0546698263574.issue24918@psf.upfronthosting.co.za>


Georg Brandl added the comment:

If it works...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 03:56:30 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2016 08:56:30 +0000
Subject: [issue23942] Explain naming of the patch files in the bug tracker
In-Reply-To: <1428966137.48.0.790822523429.issue23942@psf.upfronthosting.co.za>
Message-ID: <1452588990.23.0.11203042138.issue23942@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I think this is not worth fixing, for two reasons:
1) we are moving away from Rietveld;
2) even if we document it, most people won't go looking for naming conventions and just use reasonable names (and most of the times they will just work);
I'm therefore going to close this -- thanks anyway for the report.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 03:57:38 2016
From: report at bugs.python.org (Hana Larsen)
Date: Tue, 12 Jan 2016 08:57:38 +0000
Subject: [issue26086] Bug in standardmodule os
In-Reply-To: <1452553064.74.0.230830068722.issue26086@psf.upfronthosting.co.za>
Message-ID: <5694C001.4020402@mail.dk>


Hana Larsen added the comment:

I thank you much for thisse answer!
I Python is in "C:\Python35\" in the root of C-Drive (OS)
=-O
Den 11-01-2016 kl. 23:57 skrev Eryk Sun:
> Eryk Sun added the comment:
>
> The "yield from" syntax was added in Python 3.3, so somehow you're using the 3.5 standard library with either an old 3.x or 2.x version. The older version shouldn't use 3.5's standard library, unless you have either PYTHONHOME or PYTHONPATH defined. Generally neither of these variables should be defined, especially not PYTHONHOME. In the command prompt run "set PYTHON" to list all environment variables that start with "PYTHON".
>
> You also appear to be running with the 3.5 site-packages as the working directory. Even without the other problems, I recommend against this since the current directory has precedence in sys.path. You're moving site-packages to the head of the list, in front of the standard library. For example:
>
>      C:\Program Files\Python35\Lib\site-packages>type subprocess.py
>      print("This isn't the subprocess you're looking for.")
>
>      C:\Program Files\Python35\Lib\site-packages>py -3 -c "import subprocess"
>      This isn't the subprocess you're looking for.
>
> Save your scripts in the top-level Scripts directory or a directory in your user profile. Generally leave everything under Lib alone, to be managed by pip and other installers.
>
> ----------
> nosy: +eryksun
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 04:04:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Jan 2016 09:04:05 +0000
Subject: [issue19006] UnitTest docs should have a single list of assertions
In-Reply-To: <1378914335.13.0.0543263347661.issue19006@psf.upfronthosting.co.za>
Message-ID: <20160112090402.59566.77271@psf.io>


Roundup Robot added the comment:

New changeset ddb8fa84a119 by Ezio Melotti in branch '2.7':
#19006: fix wording in unittest docs.
https://hg.python.org/cpython/rev/ddb8fa84a119

New changeset 84f34e8685de by Ezio Melotti in branch '3.5':
#19006: fix wording in unittest docs.
https://hg.python.org/cpython/rev/84f34e8685de

New changeset 86c8d65d188f by Ezio Melotti in branch 'default':
#19006: merge with 3.5.
https://hg.python.org/cpython/rev/86c8d65d188f

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 04:04:50 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2016 09:04:50 +0000
Subject: [issue19006] UnitTest docs should have a single list of assertions
In-Reply-To: <1378914335.13.0.0543263347661.issue19006@psf.upfronthosting.co.za>
Message-ID: <1452589490.46.0.896937437007.issue19006@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the review!

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 04:20:37 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 12 Jan 2016 09:20:37 +0000
Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL
 certificate
In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za>
Message-ID: <1452590437.85.0.651203824892.issue25940@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

The patch looks good. I only have one question:

Why are you removing this part ? ...

@@ -1684,13 +1688,8 @@
             try:
                 ret = func(*args)
             except ssl.SSLError as e:
-                # Note that we get a spurious -1/SSL_ERROR_SYSCALL for
-                # non-blocking IO. The SSL_shutdown manpage hints at this.
-                # It *should* be safe to just ignore SYS_ERROR_SYSCALL because
-                # with a Memory BIO there's no syscalls (for IO at least).
                 if e.errno not in (ssl.SSL_ERROR_WANT_READ,
-                                   ssl.SSL_ERROR_WANT_WRITE,
-                                   ssl.SSL_ERROR_SYSCALL):
+                                   ssl.SSL_ERROR_WANT_WRITE):
                     raise
                 errno = e.errno
             # Get any data from the outgoing BIO irrespective of any error, and

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 04:28:11 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Jan 2016 09:28:11 +0000
Subject: [issue26001] Tutorial: write() does not expect string in binary mode
In-Reply-To: <1451829375.45.0.0188699168911.issue26001@psf.upfronthosting.co.za>
Message-ID: <20160112092807.59576.42280@psf.io>


Roundup Robot added the comment:

New changeset 5a2692911a43 by Ezio Melotti in branch '3.5':
#26001: mention in the tutorial that files in binary mode expect bytes, not str.
https://hg.python.org/cpython/rev/5a2692911a43

New changeset 4b434a4770a9 by Ezio Melotti in branch 'default':
#26001: merge with 3.5.
https://hg.python.org/cpython/rev/4b434a4770a9

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 04:30:02 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2016 09:30:02 +0000
Subject: [issue26001] Tutorial: write() does not expect string in binary mode
In-Reply-To: <1451829375.45.0.0188699168911.issue26001@psf.upfronthosting.co.za>
Message-ID: <1452591002.08.0.639918634848.issue26001@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks Dimistri for the report, Upendra for the patch, Terry for the review, and Elena for the rewrapping!
I also rephrased the last sentence a bit to make it more readable.

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 04:36:46 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Jan 2016 09:36:46 +0000
Subject: [issue25574] 2.7 incorrectly documents objects hash as equal to id
In-Reply-To: <1446849305.52.0.678156368856.issue25574@psf.upfronthosting.co.za>
Message-ID: <20160112093634.11393.18562@psf.io>


Roundup Robot added the comment:

New changeset 499ee454eecc by Ezio Melotti in branch '2.7':
#25574: backport glossary doc fix about hash and id of user-defined classes.
https://hg.python.org/cpython/rev/499ee454eecc

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 04:37:14 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2016 09:37:14 +0000
Subject: [issue25574] 2.7 incorrectly documents objects hash as equal to id
In-Reply-To: <1446849305.52.0.678156368856.issue25574@psf.upfronthosting.co.za>
Message-ID: <1452591434.6.0.634411931495.issue25574@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 04:44:50 2016
From: report at bugs.python.org (Augustin Laville)
Date: Tue, 12 Jan 2016 09:44:50 +0000
Subject: [issue26089] Duplicated keyword in distutils metadata
Message-ID: <1452591890.07.0.0660802423296.issue26089@psf.upfronthosting.co.za>


New submission from Augustin Laville:

The line https://hg.python.org/cpython/file/tip/Lib/distutils/dist.py#l1016 contains the word "licence" twice.

Check only on Python, 3.5 and 3.6, may be in others versions.

----------
components: Distutils
messages: 258091
nosy: Augustin Laville, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Duplicated keyword in distutils metadata
type: resource usage
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 04:54:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Jan 2016 09:54:14 +0000
Subject: [issue26090] More correct string truncating in PyUnicode_FromFormat()
Message-ID: <1452592454.92.0.0368970992087.issue26090@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The C code often uses %. in PyUnicode_FromFormat(). %.200s protects from unlimited output when broken pointer points on random non-null-terminated data. %.200R is used to limit the size of human-readable messages.

In all these case formatted string can look well-formed with short data, but mis-formed (not closed quote, truncated backslash escaping or ? decoded from truncated UTF-8 sequence) with long data.

I propose to make truncating in PyUnicode_FromFormat() more smart.

1. Truncated %R should keep at least one end character (the quote or ">").
2. Truncated output should include "..." or "[...]" as truncating sign.
3. \c, \OOO, \xXX, \uXXXX, and \UXXXXXXXX should not be truncated. It is better to omit these sequences at all (cut the string before them) that output them truncated.
4. Doesn't truncate UTF-8 sequence inside a character for %s.

----------
components: Interpreter Core
messages: 258092
nosy: gvanrossum, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: More correct string truncating in PyUnicode_FromFormat()
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 04:55:38 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2016 09:55:38 +0000
Subject: [issue26089] Duplicated keyword in distutils metadata
In-Reply-To: <1452591890.07.0.0660802423296.issue26089@psf.upfronthosting.co.za>
Message-ID: <1452592538.08.0.413187136611.issue26089@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

This seems to be because the alternative spelling "licence" was also included in the list, and got changed in #693470/178d19cff163.
Because of that change, the method get_licence() is not supported anymore, but at this point removing the duplicate "license" should be safe.
Attached a patch.
(Note that there seem to be no tests for the "licence" alias in Lib/distutils/tests)

----------
keywords: +patch
nosy: +ezio.melotti
stage:  -> commit review
type: resource usage -> enhancement
versions:  -Python 3.5
Added file: http://bugs.python.org/file41591/issue26089.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 04:56:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Jan 2016 09:56:19 +0000
Subject: [issue26068] re.compile() repr end quote truncated
In-Reply-To: <1452374298.65.0.166509982693.issue26068@psf.upfronthosting.co.za>
Message-ID: <1452592579.23.0.83711893069.issue26068@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

More smart truncating with closing quote and dots was the idea that I want to propose since introducing %R, but I didn't have time to formulate this. Opened issue26090 for this.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 04:56:27 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2016 09:56:27 +0000
Subject: [issue26090] More correct string truncating in PyUnicode_FromFormat()
In-Reply-To: <1452592454.92.0.0368970992087.issue26090@psf.upfronthosting.co.za>
Message-ID: <1452592587.3.0.490594995952.issue26090@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 05:01:46 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Jan 2016 10:01:46 +0000
Subject: [issue26090] More correct string truncating in PyUnicode_FromFormat()
In-Reply-To: <1452592587.33.0.980596747121.issue26090@psf.upfronthosting.co.za>
Message-ID: 


STINNER Victor added the comment:

See my old issue #10833 which proposed to *remove* the arbitrary limit
on strings. It was rejected.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 05:06:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Jan 2016 10:06:48 +0000
Subject: [issue25995] os.walk() consumes a lot of file descriptors
In-Reply-To: <1451757425.39.0.0524932176307.issue25995@psf.upfronthosting.co.za>
Message-ID: <1452593208.93.0.070333152048.issue25995@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> But using FDs proportional to the tree depth seems reasonable to me.

This was the main reason for rejecting issue15200. May be we can allow this for globbing, but only explicitly enabled with special parameter or separate functions. The benefit for globbing is starting to yield results without internal caching. The benefit for os.walk() is smaller, because in any case it yields files and directories not one-by-one, but collected into lists.

> Is there a potential hybrid strategy, where for small directories we close
> the FD but for large directories we keep it open?

May be with more complicated code. I think this needs explicit close() method, so it can go only in 3.6. For now I think we have to commit one of my patches (the difference only stylistic).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 05:13:41 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 12 Jan 2016 10:13:41 +0000
Subject: [issue22642] trace module: convert to argparse
In-Reply-To: <1413377180.82.0.707385230262.issue22642@psf.upfronthosting.co.za>
Message-ID: <1452593621.18.0.534200769861.issue22642@psf.upfronthosting.co.za>


SilentGhost added the comment:

Here is the patch that incorporates earlier changes from Vajrasky's patch as well as wording from Evan's patch in issue24649. I've extended the test of failures, but I'm not sure if much can be done about the test of successful executions. I'm going to mark this issue as a superseder of the issue24649.

----------
title: trace module: unclear error message -> trace module: convert to argparse
versions: +Python 3.6 -Python 2.7, Python 3.4
Added file: http://bugs.python.org/file41592/issue22642.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 05:17:07 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 12 Jan 2016 10:17:07 +0000
Subject: [issue24649] python -mtrace --help is wrong
In-Reply-To: <1437086585.22.0.878051480873.issue24649@psf.upfronthosting.co.za>
Message-ID: <1452593827.1.0.735149871692.issue24649@psf.upfronthosting.co.za>


SilentGhost added the comment:

A re-write using argparse is submitted in the issue22642, that's why I'm closing this issue. Changes from Evan's patch were incorporated in the submitted patch there.

----------
nosy: +SilentGhost
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed
superseder:  -> trace module: convert to argparse
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 06:23:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Jan 2016 11:23:59 +0000
Subject: [issue22995] Restrict default pickleability
In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za>
Message-ID: <1452597839.76.0.467946228519.issue22995@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for reverting the change in 2.7 and 3.5 Barry.

> can you please file a bug with upstream Cython?

It is not so easy. Cython bugtracker doesn't allow free registration or anonymous reporting. I have submitted a report to Cython core developer mailing list, but it still waits for moderating. AFAIK Stefan is active Cython core developer, may be his could raise this issue for Cython core team.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 06:45:29 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Jan 2016 11:45:29 +0000
Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL
 certificate
In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za>
Message-ID: <1452599129.02.0.32128828503.issue25940@psf.upfronthosting.co.za>


Martin Panter added the comment:

Marc-Andre: This is a fix or workaround for the problem I first described in . It looks like the code was written by Geert Jansen in Issue 21965. I suspect it is not right, but I am not familiar enough with the Open SSL API to be certain.

Geert: can you shed any light on why ssl_io_loop() in /Lib/test/test_ssl.py catches SSL_ERROR_SYSCALL and immediately retries the call? I found that when the call is unwrap(), and the remote end has shut down the TCP connection without a secure SSL-level shutdown, this calls unwrap() over and over in an infinite loop.

Geert?s comment, that my latest patch removes, mentions a spurious SSL_ERROR_SYSCALL for non-blocking IO, especially for SSL_shutdown(), which is what the Python-level unwrap() method calls. Even though the OS-level socket is blocking, I guess from Open SSL?s point of view it is doing non-blocking IO through the BIO interface.

The manual page  does mention a quirk with SSL_ERROR_SYSCALL, but only for a return value of zero, indicating the operation is half done. Python?s SSL module does not seem to pay any attention to any error codes if SSL_shutdown() returns zero; see . It just retries once, and then either returns the socket or None, never raising an exception. When the infinite loop problem occurs, the SSL_shutdown() return value is negative, indicating failure.

----------
nosy: +geertj

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 08:04:56 2016
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 12 Jan 2016 13:04:56 +0000
Subject: [issue22995] Restrict default pickleability
In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za>
Message-ID: <1452603896.33.0.941163332517.issue22995@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Thanks for calling me in. I can confirm that the stack trace in https://paste.debian.net/361351/ points at a bug in Cython's own implementation (not the code it generates). It's deep-copying objects that don't support it (which doesn't normally have an impact because they aren't actually used). I'll try to fix that.

Given this specific case, i.e. deep-copying objects to death "by accident", however shows that this change is clearly a) helpful and b) harmful. It's going to help people write safer code, but it will also break existing working code that can't normally fail as it is and that people might not really want to (or even cannot) touch any more. Not really something for a backport, IMHO.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 08:42:43 2016
From: report at bugs.python.org (akaihola)
Date: Tue, 12 Jan 2016 13:42:43 +0000
Subject: [issue20337] bdist_rpm should support %config(noreplace)
In-Reply-To: <1390343812.97.0.521102464448.issue20337@psf.upfronthosting.co.za>
Message-ID: <1452606163.74.0.655859165284.issue20337@psf.upfronthosting.co.za>


Changes by akaihola :


----------
nosy: +akaihola

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 09:08:14 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 12 Jan 2016 14:08:14 +0000
Subject: [issue25347] assert_has_calls output is formatted inconsistently
In-Reply-To: <1444342123.9.0.512399656595.issue25347@psf.upfronthosting.co.za>
Message-ID: <1452607694.77.0.993670923608.issue25347@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

The patch looks good to me. The change is in the error message of the AssertionError and don't test the error messages of Exceptions in our unittest. This change is a good usability improvement and I will commit this patch.

----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 09:18:53 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Jan 2016 14:18:53 +0000
Subject: [issue25347] assert_has_calls output is formatted inconsistently
In-Reply-To: <1444342123.9.0.512399656595.issue25347@psf.upfronthosting.co.za>
Message-ID: <20160112141844.51232.42667@psf.io>


Roundup Robot added the comment:

New changeset 77d24f51effc by Senthil Kumaran in branch 'default':
Issue25347 - Format the error message output of mock's assert_has_calls method.
https://hg.python.org/cpython/rev/77d24f51effc

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 09:20:04 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 12 Jan 2016 14:20:04 +0000
Subject: [issue25347] assert_has_calls output is formatted inconsistently
In-Reply-To: <1444342123.9.0.512399656595.issue25347@psf.upfronthosting.co.za>
Message-ID: <1452608404.94.0.98562679151.issue25347@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Verified the change and committed.

The new output behavior will be like this.

```
>>> from unittest.mock import Mock
>>> mock = Mock(return_value=None)
>>> for i in range(1, 10):
...     mock(i)
...
>>> from unittest.mock import call
>>> calls = [call(i) for i in range(2, 10)]
>>> mock.assert_has_calls(calls)
>>> calls.append(call(100))
>>> mock.assert_has_calls(calls)
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/senthilkumaran/python/cpython/Lib/unittest/mock.py", line 824, in assert_has_calls
    ) from cause
AssertionError: Calls not found.
Expected: [call(2),
 call(3),
 call(4),
 call(5),
 call(6),
 call(7),
 call(8),
 call(9),
 call(100)]
Actual: [call(1),
 call(2),
 call(3),
 call(4),
 call(5),
 call(6),
 call(7),
 call(8),
 call(9)]
```

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 09:25:27 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 12 Jan 2016 14:25:27 +0000
Subject: [issue22995] Restrict default pickleability
In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za>
Message-ID: <1452608727.11.0.95573962178.issue22995@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Thanks Stefan and Serhiy!  I think this issue is now resolved.

----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 10:57:22 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 12 Jan 2016 15:57:22 +0000
Subject: [issue22642] trace module: convert to argparse
In-Reply-To: <1413377180.82.0.707385230262.issue22642@psf.upfronthosting.co.za>
Message-ID: <1452614242.43.0.109657664967.issue22642@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

@SilentGhost,

Thanks a lot for the quick turn around of a patch. I have left some review comments in reitveld. Please address them.

Since this is underlying implementation change in option processing/parsing, it should only in feature release (3.6). 

Thank you!

----------
assignee:  -> orsenthil
versions:  -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 11:09:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Jan 2016 16:09:10 +0000
Subject: [issue22995] Restrict default pickleability
In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za>
Message-ID: <1452614950.07.0.568135053756.issue22995@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
stage: patch review -> resolved

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 11:28:45 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 12 Jan 2016 16:28:45 +0000
Subject: [issue26060] Class __dict__ iteration order changing due to type
 instance key-sharing
In-Reply-To: <1452344171.87.0.895462140972.issue26060@psf.upfronthosting.co.za>
Message-ID: <1452616125.71.0.70614382414.issue26060@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Is this a bug though?  No guarantees of dict order exists, regardless of whether the dict changes or not, right?  Even if the implementation used to, or in some circumstances still does, appear to preserve iteration order, you shouldn't count on it.

----------
nosy: +barry

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 11:29:08 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 12 Jan 2016 16:29:08 +0000
Subject: [issue26090] More correct string truncating in PyUnicode_FromFormat()
In-Reply-To: 
Message-ID: 


Guido van Rossum added the comment:

Could we make this feature available at the Python level too? It sounds
really useful.

--Guido (mobile)
On Jan 12, 2016 2:01 AM, "STINNER Victor"  wrote:

>
> STINNER Victor added the comment:
>
> See my old issue #10833 which proposed to *remove* the arbitrary limit
> on strings. It was rejected.
>
> ----------
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 11:44:04 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 12 Jan 2016 16:44:04 +0000
Subject: [issue26036] Unnecessary arguments on smtpd.SMTPServer
In-Reply-To: <1452168983.71.0.914590889995.issue26036@psf.upfronthosting.co.za>
Message-ID: <1452617044.3.0.953856483279.issue26036@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Tangentially, I'm kind of hoping we can get this into 3.6 as an asyncio replacement for smtpd: https://gitlab.com/python-smtpd-hackers/aiosmtpd

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 12:07:40 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 12 Jan 2016 17:07:40 +0000
Subject: [issue26036] Unnecessary arguments on smtpd.SMTPServer
In-Reply-To: <1452617044.3.0.953856483279.issue26036@psf.upfronthosting.co.za>
Message-ID: <0018DE39-2F8B-4AAC-8D0A-1E76C0B6DF74@trueblade.com>


Eric V. Smith added the comment:

I'd forgotten that issue 25008 is about deprecating SMTPServer (or not, there are multiple opinions on it).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 12:49:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Jan 2016 17:49:09 +0000
Subject: [issue26090] More correct string truncating in PyUnicode_FromFormat()
In-Reply-To: <1452592454.92.0.0368970992087.issue26090@psf.upfronthosting.co.za>
Message-ID: <1452620949.0.0.971349873919.issue26090@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think we can make this feature available with classic formatting '%.100r', but with new formatting '{0:.100!r}' (especially with f-strings) this can be not so easy.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 12:59:25 2016
From: report at bugs.python.org (Joseph Pyott)
Date: Tue, 12 Jan 2016 17:59:25 +0000
Subject: [issue26091] decimal.Decimal(0)**0 throws decimal.InvalidOperation
Message-ID: <1452621565.71.0.961155486004.issue26091@psf.upfronthosting.co.za>


Changes by Joseph Pyott :


----------
components: Extension Modules
files: decimal pow error.py
nosy: Pyottamus
priority: normal
severity: normal
status: open
title: decimal.Decimal(0)**0 throws decimal.InvalidOperation
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file41593/decimal pow error.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 13:01:05 2016
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Tue, 12 Jan 2016 18:01:05 +0000
Subject: [issue26060] Class __dict__ iteration order changing due to type
 instance key-sharing
In-Reply-To: <1452344171.87.0.895462140972.issue26060@psf.upfronthosting.co.za>
Message-ID: <1452621665.87.0.767054595791.issue26060@psf.upfronthosting.co.za>


Ionel Cristian M?rie? added the comment:

As I understood it the issue is not with the order but with the iteration being "unstable" (eg: same key appears multiple times). Yes, the dict is mutated while it's being iterated on, but no keys are added or removed, only values are changed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 13:02:50 2016
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 12 Jan 2016 18:02:50 +0000
Subject: [issue26060] Class __dict__ iteration order changing due to type
 instance key-sharing
In-Reply-To: <1452344171.87.0.895462140972.issue26060@psf.upfronthosting.co.za>
Message-ID: <1452621770.55.0.630690129696.issue26060@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Indeed. Here is another version of the script, it crashes when I set PYTHONHASHSEED=1 and passes with PYTHONHASHSEED=3::

class Meta(type):
    def __new__(meta, clsname, bases, methods):
        cls = super(Meta, meta).__new__(meta, clsname, bases, methods)
        count = 0
        for name in vars(cls):
            if name.startswith('f_'):
                print('decorate', name)
                count += 1
                setattr(cls, name, getattr(cls, name))
        assert count == 8
        return cls

class Spam2(metaclass=Meta):
    def f_1(self): pass
    def f_2(self): pass
    def f_3(self): pass
    def f_4(self): pass
    def f_5(self): pass
    def f_6(self): pass
    def f_7(self): pass
    def f_8(self): pass

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 13:03:59 2016
From: report at bugs.python.org (Joseph Pyott)
Date: Tue, 12 Jan 2016 18:03:59 +0000
Subject: [issue26091] decimal.Decimal(0)**0 throws decimal.InvalidOperation
Message-ID: <1452621839.79.0.503427473074.issue26091@psf.upfronthosting.co.za>


Changes by Joseph Pyott :


----------
components: +Library (Lib) -Extension Modules

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 13:17:34 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 12 Jan 2016 18:17:34 +0000
Subject: [issue26091] decimal.Decimal(0)**0 throws decimal.InvalidOperation
Message-ID: <1452622654.43.0.84872040379.issue26091@psf.upfronthosting.co.za>


New submission from Stefan Krah:

http://speleotrove.com/decimal/daops.html#refpower

----------
nosy: +skrah
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 13:20:57 2016
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Tue, 12 Jan 2016 18:20:57 +0000
Subject: [issue26092] doctest should allow custom sys.displayhook
Message-ID: <1452622857.37.0.137754453324.issue26092@psf.upfronthosting.co.za>


New submission from Sergey B Kirpichev:

The purpose of doctest's - verify interactive examples.  But if
your users will use custom displayhook all the time (consider, as
examples CAS like SymPy or https://github.com/skirpichev/omg/) - why
you must show them examples with the builtin's displayhook?

After https://bugs.python.org/issue8048, sys.displayhook can't be
customized for doctest.  I think, that decision was wrong and we
should have a better solution.

PS: In fact, right now this issue can be workarrounded if you instead
override sys.__displayhook__ before doctest call.  But I believe
this "solution" has own problems.

----------
components: Library (Lib)
messages: 258115
nosy: Sergey.Kirpichev
priority: normal
severity: normal
status: open
title: doctest should allow custom sys.displayhook
type: behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 13:36:17 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 12 Jan 2016 18:36:17 +0000
Subject: [issue25995] os.walk() consumes a lot of file descriptors
In-Reply-To: <1451757425.39.0.0524932176307.issue25995@psf.upfronthosting.co.za>
Message-ID: <1452623777.81.0.642442440041.issue25995@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I like them both, if I had to choose I'd pick patch 2.

But yes, we need to add a close() method to the scandir iterator object.

In the meantime, I am still worried about what would happen if somehow the loop got interrupted and the frame got kept alive and the iterator wasn't closed by its dealloc until much later.  This kind of thing was common in asyncio and we had to resort to similar tricks to break some cycles. Maybe you can add a try/finally that *deletes* scandir_it to force it to close itself (at least in CPython)? That can go into 3.5.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 13:44:39 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 12 Jan 2016 18:44:39 +0000
Subject: [issue22642] trace module: convert to argparse
In-Reply-To: <1413377180.82.0.707385230262.issue22642@psf.upfronthosting.co.za>
Message-ID: <1452624279.67.0.414538599546.issue22642@psf.upfronthosting.co.za>


SilentGhost added the comment:

Here is the updated version of the patch that addresses Senthil's comments. Besides re-flowing code, I've also added enforcement of --summary switch and re-factored and expanded the test_failures. It probably would be good if someone could test this on a real-life code.

----------
Added file: http://bugs.python.org/file41594/issue22642_2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 14:08:39 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 12 Jan 2016 19:08:39 +0000
Subject: [issue26090] More correct string truncating in PyUnicode_FromFormat()
In-Reply-To: <1452620949.0.0.971349873919.issue26090@psf.upfronthosting.co.za>
Message-ID: 


Guido van Rossum added the comment:

Well it seems a little odd to spend effort on a corner case of the C-level
error messages if we can't even replicate it in pure Python.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 16:04:24 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 12 Jan 2016 21:04:24 +0000
Subject: [issue25913] base64.a85decode adobe flag incorrectly utilizes <~ as a
 marker causing error
In-Reply-To: <1450567913.0.0.974183293511.issue25913@psf.upfronthosting.co.za>
Message-ID: <1452632664.3.0.795022887332.issue25913@psf.upfronthosting.co.za>


Changes by Zachary Ware :


----------
nosy: +curioswati

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 17:33:48 2016
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 12 Jan 2016 22:33:48 +0000
Subject: [issue26093] __qualname__ different when calling generator object w/
 functions.partial
Message-ID: <1452638028.1.0.595104762218.issue26093@psf.upfronthosting.co.za>


New submission from Dino Viehland:

import functools
def f():
    def g():
        yield 1
    return g

functools.partial(f())().__qualname__ != f()().__qualname__

The qualified name gets passed in via the interpreter loop with _PyEval_EvalCodeWithName calling PyGen_NewWithQualName.  If a generator object gets called from C then the qualified name gets lost.

It seems like _PyEval_EvalCodeWithName shouldn't exist and the generator code object should be able to get back to its qualified name so subtle differences like this don't happen.

----------
components: Interpreter Core
messages: 258119
nosy: dino.viehland
priority: normal
severity: normal
status: open
title: __qualname__ different when calling generator object w/ functions.partial
type: behavior
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 17:43:04 2016
From: report at bugs.python.org (Simon Conseil)
Date: Tue, 12 Jan 2016 22:43:04 +0000
Subject: [issue24955] webbrowser broken on Mac OS X when using the BROWSER
 variable
In-Reply-To: <1440842500.82.0.168118984503.issue24955@psf.upfronthosting.co.za>
Message-ID: <1452638584.69.0.767582743359.issue24955@psf.upfronthosting.co.za>


Simon Conseil added the comment:

I have looked at the webbrowser tests and it seems not so easy: currently the MacOS browser classes are not tested, and they don't the GenericBrowser base class. Instead they use custom code with os.popen, so it would require some work either replace os.popen with subprocess.Popen, or to mock the os.popen calls. I'm not sure I will the time to dig into this.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 18:40:01 2016
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Tue, 12 Jan 2016 23:40:01 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <1452642001.64.0.70165211359.issue25924@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

Related to #1288833, when FreeBSD 5.3's getaddrinfo was declared thread-safe.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 18:43:27 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 12 Jan 2016 23:43:27 +0000
Subject: [issue24955] webbrowser broken on Mac OS X when using the BROWSER
 variable
In-Reply-To: <1440842500.82.0.168118984503.issue24955@psf.upfronthosting.co.za>
Message-ID: <1452642207.59.0.879736277114.issue24955@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Simon, sure. It is just for someone, either commiters or other interested folks to add the tests on top of your patch. Agree with you that more change is required to add the required tests.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 18:48:48 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 12 Jan 2016 23:48:48 +0000
Subject: [issue26050] Add new StreamReader.readuntil() method
In-Reply-To: <1452285476.14.0.419432816204.issue26050@psf.upfronthosting.co.za>
Message-ID: <1452642528.07.0.295003575575.issue26050@psf.upfronthosting.co.za>


Changes by ???? ????????? :


----------
keywords: +patch
Added file: http://bugs.python.org/file41595/asyncio-stream-doc-preliminary.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 18:50:15 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 12 Jan 2016 23:50:15 +0000
Subject: [issue26050] Add new StreamReader.readuntil() method
In-Reply-To: <1452285476.14.0.419432816204.issue26050@psf.upfronthosting.co.za>
Message-ID: <1452642615.57.0.77375317957.issue26050@psf.upfronthosting.co.za>


???? ????????? added the comment:

Attached patch, but did not compile documentation until text is validated.

These descriptions are just copies of docstrings of corresponding functions.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 19:39:59 2016
From: report at bugs.python.org (khyox)
Date: Wed, 13 Jan 2016 00:39:59 +0000
Subject: [issue26094] ConfigParser.get() doc to be updated according to the
 configparser.py header doc
Message-ID: <1452645599.68.0.959713633048.issue26094@psf.upfronthosting.co.za>


New submission from khyox:

For the sake of clarity, in https://docs.python.org/3.5/library/configparser.html#configparser.ConfigParser the ConfigParser.get() method doc could be properly updated with merging the information written in the header doc of the source file, as found in https://hg.python.org/cpython/file/3.5/Lib/configparser.py

Concretely, this sentence there, "Return a string value for the named option." could be considered quite relevant to be added to the doc of the method, as some packages are (incorrectly) expecting boolean values returned by the ConfigParser.get() method. The reality is that a "True" in the configuration file is returning the string "True" and not the boolean constant True.

To sum up, the suggested update would be:

    def get(self, section, option, *, raw=False, vars=None, fallback=_UNSET):
        """Returns a string value for the named option for a given section.

        If `vars' is provided, it must be a dictionary. The option is looked up
        in `vars' (if provided), `section', and in `DEFAULTSECT' in that order.
        If the key is not found and `fallback' is provided, it is used as
        a fallback value. `None' can be provided as a `fallback' value.

        If interpolation is enabled and the optional argument `raw' is False,
        all interpolations are expanded in the return values.

        Arguments `raw', `vars', and `fallback' are keyword only.

        The section DEFAULT is special.
        """
        (...)

----------
assignee: docs at python
components: Documentation
messages: 258124
nosy: docs at python, khyox
priority: normal
severity: normal
status: open
title: ConfigParser.get() doc to be updated according to the configparser.py header doc
type: enhancement
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 20:48:11 2016
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Wed, 13 Jan 2016 01:48:11 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <1452649691.1.0.997251414259.issue25924@psf.upfronthosting.co.za>


Changes by A. Jesse Jiryu Davis :


Added file: http://bugs.python.org/file41596/h_resolv.c

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 20:48:35 2016
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Wed, 13 Jan 2016 01:48:35 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <1452649715.57.0.62648471105.issue25924@psf.upfronthosting.co.za>


Changes by A. Jesse Jiryu Davis :


Added file: http://bugs.python.org/file41597/d_mach

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 20:51:28 2016
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Wed, 13 Jan 2016 01:51:28 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <1452649888.4.0.148094104569.issue25924@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

NetBSD has a concurrency test for getaddrinfo, so I tried it on Mac to see if getaddrinfo is thread-safe here, too. It appears that it is thread-safe.

I copied NetBSD's getaddrinfo concurrency test "h_resolv.c" and the test's data file "d_mach" from src/tests/lib/libpthread in the NetBSD 7 source:

http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/lib/libpthread/

I've also attached these files to this ticket.*

The test program h_resolv.c compiles fine on Mac OS X 10.10 with clang 7, and the test passes using the same parameters that the NetBSD test uses, resolving five host names on five threads:

./h_resolv -d -n 5 -h 5 d_mach

There's even evidence that getaddrinfo is actually concurrent on my Mac: resolving 100 hostnames on 1 thread takes about 6 seconds, but using 100 threads take only 3 seconds. To test concurrency I ran this:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
time h_resolv -d -h 100 -n 1 d_mach

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
time h_resolv -d -h 1 -n 100 d_mach

Those sudo commands flush the Mac's DNS cache between runs.

* I removed one unresolvable domain, "cnftp.bjpu.edu.cn", from the test file d_mach. That domain took 15 seconds to time out and made the rest of the timing irrelevant.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 21:16:37 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Jan 2016 02:16:37 +0000
Subject: [issue26095] Update porting HOWTO to special-case Python 2 code,
 not Python 3
Message-ID: <1452651397.71.0.110404454924.issue26095@psf.upfronthosting.co.za>


New submission from Brett Cannon:

As pointed out by http://astrofrog.github.io/blog/2016/01/12/stop-writing-python-4-incompatible-code/, special-casing Python 3 code instead of Python 2 code when writing Python 2/3 code will lead to breakage when Python 3 comes out. There should probably be a note in the porting HOWTO mentioning that you should always special-case Python 2 code and not Python 3 code.

----------
assignee: docs at python
components: Documentation
messages: 258126
nosy: brett.cannon, docs at python
priority: normal
severity: normal
status: open
title: Update porting HOWTO to special-case Python 2 code, not Python 3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 21:17:07 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Jan 2016 02:17:07 +0000
Subject: [issue26095] Update porting HOWTO to special-case Python 2 code,
 not Python 3
In-Reply-To: <1452651397.71.0.110404454924.issue26095@psf.upfronthosting.co.za>
Message-ID: <1452651427.31.0.337955516485.issue26095@psf.upfronthosting.co.za>


Brett Cannon added the comment:

And suggesting feature detection is even better than version detection.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 21:17:53 2016
From: report at bugs.python.org (JitterMan)
Date: Wed, 13 Jan 2016 02:17:53 +0000
Subject: [issue26096] '*' glob string matches dot files in pathlib
Message-ID: <1452651473.17.0.586447787765.issue26096@psf.upfronthosting.co.za>


New submission from JitterMan:

Path('.').glob('*') generates all files and directories in '.' including hidden files (those that begin with '.'). This behavior is inconsistent with the shell and with the old glob module, which only generate hidden files if the glob pattern starts with a '.'.

----------
messages: 258128
nosy: jitterman
priority: normal
severity: normal
status: open
title: '*' glob string matches dot files in pathlib
type: behavior
versions: Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 22:45:42 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 13 Jan 2016 03:45:42 +0000
Subject: [issue25752] asyncio.readline - add customizable line separator
In-Reply-To: <1448659598.46.0.288346349625.issue25752@psf.upfronthosting.co.za>
Message-ID: <1452656742.98.0.601690252701.issue25752@psf.upfronthosting.co.za>


Martin Panter added the comment:

The same Git Hub pull request is mentioned in Issue 26050, so I am guessing this is now a duplicate.

----------
nosy: +martin.panter
resolution: wont fix -> duplicate
status: open -> closed
superseder:  -> Add new StreamReader.readuntil() method

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 23:33:36 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 13 Jan 2016 04:33:36 +0000
Subject: [issue26095] Update porting HOWTO to special-case Python 2 code,
 not Python 3
In-Reply-To: <1452651397.71.0.110404454924.issue26095@psf.upfronthosting.co.za>
Message-ID: <1452659616.97.0.365873987787.issue26095@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The feature detection approach is especially important for anything covered by the security backports in PEP 466 and 476, but can also apply for things like installing the importlib2 meta_path hooks into Python 2.7.

----------
nosy: +ncoghlan

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 00:00:20 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Jan 2016 05:00:20 +0000
Subject: [issue26087] PEP 0373 should be updated
In-Reply-To: <1452572071.97.0.659652590609.issue26087@psf.upfronthosting.co.za>
Message-ID: <20160113050017.4226.14045@psf.io>


Roundup Robot added the comment:

New changeset 1046a40e086f by Benjamin Peterson in branch 'default':
update 2.7 schedule (closes #26087)
https://hg.python.org/peps/rev/1046a40e086f

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 01:04:19 2016
From: report at bugs.python.org (anchal agarwal)
Date: Wed, 13 Jan 2016 06:04:19 +0000
Subject: [issue24780] unittest assertEqual difference output foiled by newlines
In-Reply-To: <1438534169.3.0.814109265012.issue24780@psf.upfronthosting.co.za>
Message-ID: <1452665059.48.0.421900341342.issue24780@psf.upfronthosting.co.za>


anchal agarwal added the comment:

There is another case where the error message displayed by self.assertEqual() is weird. 

======================================================================
FAIL: test_newline_1 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 9, in test_newline_1
    self.assertEqual("\n abc", "\n abd")
AssertionError: '\n abc' != '\n abd'
  
-  abc?    ^
+  abd?    ^


======================================================================
FAIL: test_newline_2 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 12, in test_newline_2
    self.assertEqual("\nabc", "\nabd")
AssertionError: '\nabc' != '\nabd'
  
- abc+ abd


----------------------------------------------------------------------

There is a difference in between "\nabc" and "\n abc" and hence the difference between output

----------
nosy: +pynewbie

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 02:50:46 2016
From: report at bugs.python.org (=?utf-8?q?Dani=C3=ABl_van_Eeden?=)
Date: Wed, 13 Jan 2016 07:50:46 +0000
Subject: [issue15071] TLS get keys and randoms
In-Reply-To: <1339706412.94.0.740645043785.issue15071@psf.upfronthosting.co.za>
Message-ID: <1452671446.63.0.219356996033.issue15071@psf.upfronthosting.co.za>


Changes by Dani?l van Eeden :


----------
nosy: +dveeden

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 03:34:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Jan 2016 08:34:56 +0000
Subject: [issue25911] Regression: os.walk now using os.scandir() breaks bytes
 filenames on windows
In-Reply-To: <1450539578.39.0.976654454489.issue25911@psf.upfronthosting.co.za>
Message-ID: <1452674096.62.0.0938274111495.issue25911@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fixed a typo found by Eryk Sun.

----------
Added file: http://bugs.python.org/file41598/walk_bytes_2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 03:39:08 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Jan 2016 08:39:08 +0000
Subject: [issue25911] Regression: os.walk now using os.scandir() breaks bytes
 filenames on windows
In-Reply-To: <1450539578.39.0.976654454489.issue25911@psf.upfronthosting.co.za>
Message-ID: <1452674348.53.0.653180776005.issue25911@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Did we want a deprecation warning too?

I didn't tested on Windows. If bytes paths considered deprecated on Windows, os.listdir() should emit a warning. Otherwise I don't think we should special case os.walk().

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 04:01:52 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 13 Jan 2016 09:01:52 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1452675712.9.0.403345139225.issue23551@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

On python-list, Chris Angelico reported 2 other problems when running something like "import pip; pip.main(['install','psycopg2'])" from IDLE.  Both can be worked around in a pipgui program.

1. pip displays a progress bar by sending to stdout a sequence of strings something like '#', '\r##', '\r###', ..., '\r###...###'.  When IDLE sends these on to the tk text widget, they are displayed as above.  '\r' displays as '\r' and does not cause a 'return'.

pipgui would already be monitoring and parsing pip output to display information in appropriate widgets, so it could look for and interpret whatever pip actually does send.

2. pip has a bug.  When installing a non-wheel, it may unconditionally execute "s.decode(sys.__stdout__.encoding)".  sys.__stdin__, etcetera, are documented as sometimes being None, https://docs.python.org/3/library/sys.html#sys.__stdin__, and None does not have an 'encoding' attribute.  The workaround, until this is fixed, is for pipgui to rebind sys.__stdout__ to an object that at least has a sensible .encoding.  I would grep the entire pip source other '__std.*__' uses to see if more is needed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 04:17:42 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 13 Jan 2016 09:17:42 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1452676662.84.0.724518799026.issue23551@psf.upfronthosting.co.za>


Changes by Mark Lawrence :


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 04:26:18 2016
From: report at bugs.python.org (Ismail Donmez)
Date: Wed, 13 Jan 2016 09:26:18 +0000
Subject: [issue25720] Fix curses module compilation with ncurses6
In-Reply-To: <1448365148.0.0.732837314732.issue25720@psf.upfronthosting.co.za>
Message-ID: <1452677178.03.0.761629825701.issue25720@psf.upfronthosting.co.za>


Ismail Donmez added the comment:

Any patch review/comment ?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 04:53:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Jan 2016 09:53:13 +0000
Subject: [issue25720] Fix curses module compilation with ncurses6
In-Reply-To: <1448365148.0.0.732837314732.issue25720@psf.upfronthosting.co.za>
Message-ID: <1452678793.36.0.476868164495.issue25720@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

configure.ac directly uses w->_flags in a check. It looks that this check always fails with ncurses6.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 05:10:46 2016
From: report at bugs.python.org (Graham Dumpleton)
Date: Wed, 13 Jan 2016 10:10:46 +0000
Subject: [issue23990] Callable builtin doesn't respect descriptors
In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za>
Message-ID: <1452679846.45.0.847675601023.issue23990@psf.upfronthosting.co.za>


Changes by Graham Dumpleton :


----------
nosy: +grahamd

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 05:38:30 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 10:38:30 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>
Message-ID: <1452681510.41.0.523326154855.issue26058@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 4: I forgot to include my patch to update test_sys. Now the full Python test suite pass.

----------
Added file: http://bugs.python.org/file41599/dict_version-4.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 05:38:41 2016
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Wed, 13 Jan 2016 10:38:41 +0000
Subject: [issue19072] classmethod doesn't honour descriptor protocol of
 wrapped callable
In-Reply-To: <1379856164.11.0.6368818134.issue19072@psf.upfronthosting.co.za>
Message-ID: <1452681521.95.0.785952525522.issue19072@psf.upfronthosting.co.za>


Changes by Ionel Cristian M?rie? :


----------
nosy: +ionelmc

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 05:41:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 10:41:19 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>
Message-ID: <1452681679.42.0.29379285411.issue26058@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm not a big fan of pybench (it looks unstable and so not reliable), but here are results with dict_version-4.patch.

I used more loops and a lower warp factor to get more reliable tests (I hope):

./python Tools/pybench/pybench.py -f pybench.orig -w 2 -C 100 -n 25
./python.patched Tools/pybench/pybench.py -f pybench.dictver -w 2 -C 100 -n 25
./python Tools/pybench/pybench.py -s pybench.dictver -c pybench.orig

-------------------------------------------------------------------------------
PYBENCH 2.1
-------------------------------------------------------------------------------
* using CPython 3.6.0a0 (default:77d24f51effc+, Jan 13 2016, 11:27:53) [GCC 5.3.1 20151207 (Red Hat 5.3.1-2)]
* disabled garbage collection
* system check interval set to maximum: 2147483647
* using timer: time.perf_counter
* timer: resolution=1e-09, implementation=clock_gettime(CLOCK_MONOTONIC)

-------------------------------------------------------------------------------
Benchmark: pybench.dictver
-------------------------------------------------------------------------------

    Rounds: 25
    Warp:   2
    Timer:  time.perf_counter

    Machine Details:
       Platform ID:    Linux-4.2.8-300.fc23.x86_64-x86_64-with-fedora-23-Twenty_Three
       Processor:      x86_64
    
    Python:
       Implementation: CPython
       Executable:     /home/haypo/prog/python/default/python
       Version:        3.6.0a0
       Compiler:       GCC 5.3.1 20151207 (Red Hat 5.3.1-2)
       Bits:           64bit
       Build:          Jan 13 2016 11:27:53 (#default:77d24f51effc+)
       Unicode:        UCS4


-------------------------------------------------------------------------------
Comparing with: pybench.orig
-------------------------------------------------------------------------------

    Rounds: 25
    Warp:   2
    Timer:  time.perf_counter

    Machine Details:
       Platform ID:    Linux-4.2.8-300.fc23.x86_64-x86_64-with-fedora-23-Twenty_Three
       Processor:      x86_64
    
    Python:
       Implementation: CPython
       Executable:     /home/haypo/prog/python/default/python
       Version:        3.6.0a0
       Compiler:       GCC 5.3.1 20151207 (Red Hat 5.3.1-2)
       Bits:           64bit
       Build:          Jan 13 2016 11:14:50 (#default:77d24f51effc)
       Unicode:        UCS4


Test                             minimum run-time        average  run-time
                                 this    other   diff    this    other   diff
-------------------------------------------------------------------------------
          BuiltinFunctionCalls:   230ms   229ms   +0.4%   241ms   230ms   +5.1%
           BuiltinMethodLookup:   130ms   132ms   -1.2%   135ms   134ms   +0.4%
                 CompareFloats:   147ms   149ms   -1.4%   151ms   149ms   +1.2%
         CompareFloatsIntegers:   330ms   333ms   -0.8%   347ms   335ms   +3.6%
               CompareIntegers:   214ms   209ms   +2.5%   223ms   209ms   +6.5%
        CompareInternedStrings:   160ms   145ms  +10.8%   170ms   145ms  +16.9%
                  CompareLongs:   121ms   120ms   +0.2%   124ms   120ms   +3.4%
                CompareStrings:   132ms   131ms   +0.7%   138ms   132ms   +4.8%
    ComplexPythonFunctionCalls:   233ms   235ms   -0.7%   241ms   238ms   +1.1%
                 ConcatStrings:   166ms   165ms   +0.3%   177ms   167ms   +6.0%
               CreateInstances:   240ms   247ms   -3.1%   253ms   249ms   +1.5%
            CreateNewInstances:   178ms   186ms   -4.2%   188ms   188ms   +0.1%
       CreateStringsWithConcat:   315ms   316ms   -0.5%   331ms   318ms   +4.3%
                  DictCreation:   254ms   236ms   +7.8%   262ms   237ms  +10.5%
             DictWithFloatKeys:   211ms   199ms   +6.1%   219ms   201ms   +8.9%
           DictWithIntegerKeys:   171ms   163ms   +5.4%   180ms   166ms   +9.0%
            DictWithStringKeys:   163ms   142ms  +14.5%   170ms   144ms  +17.7%
                      ForLoops:   121ms   121ms   -0.3%   125ms   124ms   +0.9%
                    IfThenElse:   179ms   178ms   +0.7%   185ms   178ms   +3.6%
                   ListSlicing:   194ms   193ms   +0.4%   198ms   194ms   +2.2%
                NestedForLoops:   212ms   210ms   +1.2%   220ms   210ms   +4.6%
      NestedListComprehensions:   205ms   212ms   -3.3%   218ms   215ms   +1.5%
          NormalClassAttribute:   429ms   407ms   +5.5%   446ms   408ms   +9.3%
       NormalInstanceAttribute:   212ms   206ms   +2.8%   226ms   209ms   +8.0%
           PythonFunctionCalls:   208ms   210ms   -1.4%   215ms   212ms   +1.2%
             PythonMethodCalls:   275ms   253ms   +8.7%   293ms   255ms  +14.9%
                     Recursion:   333ms   328ms   +1.4%   366ms   329ms  +11.0%
                  SecondImport:   190ms   188ms   +0.8%   201ms   188ms   +6.7%
           SecondPackageImport:   195ms   192ms   +1.8%   214ms   192ms  +11.7%
         SecondSubmoduleImport:   472ms   447ms   +5.7%   502ms   455ms  +10.3%
       SimpleComplexArithmetic:   141ms   138ms   +2.1%   146ms   139ms   +5.2%
        SimpleDictManipulation:   287ms   288ms   -0.3%   313ms   290ms   +8.0%
         SimpleFloatArithmetic:   138ms   137ms   +0.7%   151ms   140ms   +7.9%
      SimpleIntFloatArithmetic:   172ms   180ms   -4.3%   182ms   181ms   +0.4%
       SimpleIntegerArithmetic:   172ms   169ms   +1.9%   184ms   170ms   +8.1%
      SimpleListComprehensions:   166ms   167ms   -0.7%   179ms   173ms   +3.3%
        SimpleListManipulation:   159ms   153ms   +3.9%   166ms   155ms   +7.6%
          SimpleLongArithmetic:   118ms   117ms   +1.2%   123ms   118ms   +4.3%
                    SmallLists:   210ms   204ms   +2.8%   221ms   205ms   +7.3%
                   SmallTuples:   244ms   252ms   -3.1%   255ms   256ms   -0.2%
         SpecialClassAttribute:   424ms   416ms   +1.8%   442ms   419ms   +5.5%
      SpecialInstanceAttribute:   214ms   211ms   +1.3%   223ms   214ms   +4.5%
                StringMappings:   442ms   446ms   -0.8%   460ms   447ms   +2.9%
              StringPredicates:   259ms   258ms   +0.2%   281ms   260ms   +8.2%
                 StringSlicing:   218ms   220ms   -1.2%   228ms   221ms   +3.3%
                     TryExcept:   130ms   135ms   -3.9%   134ms   136ms   -1.4%
                    TryFinally:   173ms   171ms   +0.9%   180ms   172ms   +4.4%
                TryRaiseExcept:    62ms    63ms   -1.2%    63ms    63ms   +0.9%
                  TupleSlicing:   223ms   224ms   -0.3%   251ms   232ms   +8.0%
                   WithFinally:   263ms   264ms   -0.4%   280ms   265ms   +5.4%
               WithRaiseExcept:   205ms   203ms   +0.7%   215ms   204ms   +5.5%
-------------------------------------------------------------------------------
Totals:                         11040ms 10900ms   +1.3% 11635ms 10991ms   +5.9%

(this=pybench.dictver, other=pybench.orig)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 06:07:08 2016
From: report at bugs.python.org (=?utf-8?q?Nicolas_=C3=89vrard?=)
Date: Wed, 13 Jan 2016 11:07:08 +0000
Subject: [issue26097] 2.7 documentation about TextTestRunner do not specify
 all the arguments
Message-ID: <1452683228.39.0.232346799389.issue26097@psf.upfronthosting.co.za>


New submission from Nicolas ?vrard:

Some of the arguments although specified further in the documentation do not appear in the signature of TextTestRunner.

Here's a simple patch to include them.

----------
assignee: docs at python
components: Documentation
files: unittest_doc_bug.diff
keywords: patch
messages: 258140
nosy: docs at python, nicoe
priority: normal
severity: normal
status: open
title: 2.7 documentation about TextTestRunner do not specify all the arguments
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file41600/unittest_doc_bug.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 07:52:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 12:52:49 +0000
Subject: [issue26098] PEP 510: Specialize functions with guards
Message-ID: <1452689568.12.0.253530674137.issue26098@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch implements the PEP 510 "Specialize functions with guards".

Changes on the C API are described in the PEP:
https://www.python.org/dev/peps/pep-0510/#changes

Additions of the patch:

* Add func_specialize() and func_get_specialized() to _testcapi
* Add _testcapi.PyGuard: Python wrapper to the Guard C API
* Add Lib/test/test_pep510.py

----------
files: specialize.patch
keywords: patch
messages: 258141
nosy: haypo
priority: normal
severity: normal
status: open
title: PEP 510: Specialize functions with guards
versions: Python 3.6
Added file: http://bugs.python.org/file41601/specialize.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 08:53:39 2016
From: report at bugs.python.org (Ismail Donmez)
Date: Wed, 13 Jan 2016 13:53:39 +0000
Subject: [issue25720] Fix curses module compilation with ncurses6
In-Reply-To: <1448365148.0.0.732837314732.issue25720@psf.upfronthosting.co.za>
Message-ID: <1452693219.36.0.704649618765.issue25720@psf.upfronthosting.co.za>


Ismail Donmez added the comment:

Thats not an issue for ncurses because Include/py_curses.h does:

  #ifdef HAVE_NCURSES_H
  /* configure was checking , but we will
     use , which has all these features. */
  #ifndef WINDOW_HAS_FLAGS
  #define WINDOW_HAS_FLAGS 1
  #endif
  #ifndef MVWDELCH_IS_EXPRESSION
  #define MVWDELCH_IS_EXPRESSION 1
  #endif
  #endif

So it overrides WINDOW_HAS_FLAGS for ncurses case.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 09:12:39 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 14:12:39 +0000
Subject: [issue26098] PEP 510: Specialize functions with guards
In-Reply-To: <1452689568.12.0.253530674137.issue26098@psf.upfronthosting.co.za>
Message-ID: <1452694359.9.0.138018664432.issue26098@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 2 fixes some bugs and add more tests.

More notes about the patch:

* RuntimeError is raised if guard check() result is greater than 2
* RuntimeError is raised if guard init() result is greater than 1
* (hum, maybe 'res < 0' check must be replaced with 'res == -1', but I'm not sure that that it's worth it.)
* If PyFunction_Specialize() is called with a code object or a Python code, it creates a new code object and copies the code name and first line number in the new code object to ease debugging

TODO: keywords are currently not supported in PyGuard.__call__().

----------
Added file: http://bugs.python.org/file41602/specialize-2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 09:46:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 14:46:44 +0000
Subject: [issue26099] site ignores ImportError when running sitecustomize and
 usercustomize
Message-ID: <1452696404.05.0.367833198211.issue26099@psf.upfronthosting.co.za>


New submission from STINNER Victor:

If the code of sitecustomize raises an ImportError because the requested module doesn't exist, sitecustomize exception is silently ignored because site.py uses "try: import sitecustomize except ImportError: pass".

It's possible to log a warning since ImportError now has a name attribute since Python 3.3.

There is a similar issue on usercustomize.

Attached patch fixes the issue.

----------
files: site.patch
keywords: patch
messages: 258144
nosy: haypo
priority: normal
severity: normal
status: open
title: site ignores ImportError when running sitecustomize and usercustomize
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41603/site.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 09:46:56 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 14:46:56 +0000
Subject: [issue26099] site ignores ImportError when running sitecustomize and
 usercustomize
In-Reply-To: <1452696404.05.0.367833198211.issue26099@psf.upfronthosting.co.za>
Message-ID: <1452696416.38.0.809690542128.issue26099@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 09:59:54 2016
From: report at bugs.python.org (Florent Viard)
Date: Wed, 13 Jan 2016 14:59:54 +0000
Subject: [issue25668] Deadlock in logging caused by a possible race condition
 with "format"
In-Reply-To: <1447942973.46.0.788007678714.issue25668@psf.upfronthosting.co.za>
Message-ID: <1452697194.86.0.972646075269.issue25668@psf.upfronthosting.co.za>


Florent Viard added the comment:

Sorry to reply after a so long time.

Please don't close this issue too fast, there is really a big issue that is not related to my specific case.
(Note that the attached test case is not the real case, but a small piece of code that is able to reproduce the issue consistently)

Also, I don't pretend that my fix proposal is the solution, but the issue definitively exists.

To reply to your comment:
<<<
handle() and emit() are high level methods of a handler, and format() is at a lower level. Not all emit() methods will call format(). For example, socket-based and queue-based handlers don't. So it is not in general possible to separate format() out - you will need to have a customised handler to deal with your somewhat unusual use case, and do whatever you need in there.
>>>
That is not true even if it is a little hidden in the code:
- SocketHandler: emit first calls makePickle that almost starts with "record.getMessages()" that does the interesting thing.
(self.format mainly does getMessages(), that is the function that gets the messages arguments, eventually from properties)
- QueueHandler: emit first calls "prepare(record)", that starts by calling self.format(record).

But after having looked deeper at the code, maybe my fix proposal could be modified to be something like:
new function in "LogRecord" class:
 def stringifyMessage(self):
     # CODE THAT WAS IN getMessages()
     self.processed_msg = str(self.msg)
     if self.args:
         self.processed_msg = self.processed_msg % self.args

modify the getMessages function to:
 def getMessages(self):
     if not self.processed_msg:
         self.stringifyMessage()
     return self.processed_msg

Then, in the "__init__.py" handle function, add the following before "self.acquire()":
record.stringifyMessage()

Thus, no need to change anything, any handler, but the "message" arguments will be processed before getting the lock of "logging".

Regarding the second part of your comment, just saying that "generally" threading locks are a complex topic, doesn't remove the fact that in this specific logging case, there is a real bug regarding how python works. Here, you assume that an user of "logging" is supposed to know how the inside thread locking of "logging" works because the section under locking of logging leaks into "user space code". I'm pretty sure that almost everyone using logging today would not think that such an issue could arise.

I could agree with your point if the problem that was solvable, but i'm pretty sure that there is at least a solution that is working with backward compatibility and at worst minor disturbance to some very specific users of some specific handlers.

----------
resolution: not a bug -> 
status: closed -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 10:04:36 2016
From: report at bugs.python.org (Florent Viard)
Date: Wed, 13 Jan 2016 15:04:36 +0000
Subject: [issue25668] Deadlock in logging caused by a possible race condition
 with "format"
In-Reply-To: <1447942973.46.0.788007678714.issue25668@psf.upfronthosting.co.za>
Message-ID: <1452697476.55.0.140947296172.issue25668@psf.upfronthosting.co.za>


Florent Viard added the comment:

Sorry, typo in my last sentence:
"I would have agreed with your point if the problem was NOT solvable,..."

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 10:24:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 15:24:09 +0000
Subject: [issue26098] PEP 510: Specialize functions with guards
In-Reply-To: <1452689568.12.0.253530674137.issue26098@psf.upfronthosting.co.za>
Message-ID: <1452698649.0.0.00890554852758.issue26098@psf.upfronthosting.co.za>


STINNER Victor added the comment:

An unit test is needed on pickle serialization to ensure that the specialize code and guards are ignored.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 10:47:06 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Jan 2016 15:47:06 +0000
Subject: [issue22642] trace module: convert to argparse
In-Reply-To: <1413377180.82.0.707385230262.issue22642@psf.upfronthosting.co.za>
Message-ID: <20160113154701.106535.10947@psf.io>


Roundup Robot added the comment:

New changeset 0aa46b9ffba3 by Senthil Kumaran in branch 'default':
Issue22642 - Convert trace module's option handling mechanism from getopt to argparse.
https://hg.python.org/cpython/rev/0aa46b9ffba3

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 10:49:03 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Jan 2016 15:49:03 +0000
Subject: [issue22642] trace module: convert to argparse
In-Reply-To: <1413377180.82.0.707385230262.issue22642@psf.upfronthosting.co.za>
Message-ID: <20160113154901.31087.72223@psf.io>


Roundup Robot added the comment:

New changeset 69aa17b1f894 by Senthil Kumaran in branch 'default':
Add a NEWS entry for Issue #22642.
https://hg.python.org/cpython/rev/69aa17b1f894

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 10:51:23 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 13 Jan 2016 15:51:23 +0000
Subject: [issue22642] trace module: convert to argparse
In-Reply-To: <1413377180.82.0.707385230262.issue22642@psf.upfronthosting.co.za>
Message-ID: <1452700283.74.0.684832761074.issue22642@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the contribution. The option handling of trace module is modernized now.

As berker suggested in one of the review comments, this module could see an increase in test coverage and we could deal with this as separate ticket.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 11:12:34 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 16:12:34 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>
Message-ID: <1452701554.57.0.0524257395403.issue26058@psf.upfronthosting.co.za>


STINNER Victor added the comment:

guard_benchmark.patch: patch adding a _testcapi.guard_benchmark(), a microbenchmark on dictionary guard. The benchmark measures the cost of checking if a dictionary key was modified.

Run the benchmark with attached guard_benchmark.py. Result on my PC:

* PyObject_GetItem(): 10.2 ns
* PyDict_GetItem(): 9.1 ns
* guard->check(): 2.9 ns

python3 -m platform:
Linux-4.2.8-300.fc23.x86_64-x86_64-with-fedora-23-Twenty_Three

You have to modify manually _testcapi.c to choose between the 3 implementations.

guard_benchmark.patch requires the issue #26098 patch and the fat module which implements fat.GuardDict. The fat module can be found at:
https://github.com/haypo/fat

----------
Added file: http://bugs.python.org/file41604/guard_benchmark.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 11:12:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 16:12:52 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>
Message-ID: <1452701572.83.0.442617753029.issue26058@psf.upfronthosting.co.za>


Changes by STINNER Victor :


Added file: http://bugs.python.org/file41605/guard_benchmark.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 11:32:31 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 16:32:31 +0000
Subject: [issue26100] Add test.support.optim_args_from_interpreter_flags()
Message-ID: <1452702751.92.0.809582535795.issue26100@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch adds a new optim_args_from_interpreter_flags() function to the test.support module, similar to the existing args_from_interpreter_flags() function. The function creates command line arguments related to optimization. The function is required by test_compileall.py and test_inspect.py.

The patch enables test_details() test of test_inspect when -O or -OO command line options are used.

----------
files: optim_args.patch
keywords: patch
messages: 258152
nosy: haypo
priority: normal
severity: normal
status: open
title: Add test.support.optim_args_from_interpreter_flags()
versions: Python 3.6
Added file: http://bugs.python.org/file41606/optim_args.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 11:32:36 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 16:32:36 +0000
Subject: [issue26100] Add test.support.optim_args_from_interpreter_flags()
In-Reply-To: <1452702751.92.0.809582535795.issue26100@psf.upfronthosting.co.za>
Message-ID: <1452702756.62.0.566581903426.issue26100@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
components: +Tests

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 11:34:06 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 16:34:06 +0000
Subject: [issue26100] Add test.support.optim_args_from_interpreter_flags()
In-Reply-To: <1452702751.92.0.809582535795.issue26100@psf.upfronthosting.co.za>
Message-ID: <1452702846.57.0.362409249369.issue26100@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Do you want that the change should be applied to Python 3.5 too?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 11:40:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 16:40:57 +0000
Subject: [issue26101] Lib/test/test_compileall.py fails when run directly
Message-ID: <1452703257.16.0.0951114007651.issue26101@psf.upfronthosting.co.za>


New submission from STINNER Victor:

"./python Lib/test/test_compileall.py" fails on test_compile_path() because the Lib/test/ directory is in sys.path and this directory contains invalid Python scripts like Lib/test/badsyntax_pep3120.py

Attached patch fixes the issue by removing temporarely Lib/test/ from sys.path.

Note: Python 3.5 doesn't test compileall.compile_path() which fails. The new test was added by the changeset 71f071f2e074 of the issue #25768.

----------
files: test_compileall.patch
keywords: patch
messages: 258154
nosy: brett.cannon, haypo
priority: normal
severity: normal
status: open
title: Lib/test/test_compileall.py fails when run directly
versions: Python 3.6
Added file: http://bugs.python.org/file41607/test_compileall.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 11:41:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 16:41:43 +0000
Subject: [issue26100] Add test.support.optim_args_from_interpreter_flags()
In-Reply-To: <1452702751.92.0.809582535795.issue26100@psf.upfronthosting.co.za>
Message-ID: <1452703303.37.0.254751104394.issue26100@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Note: running directly "./python Lib/test/test_compileall.py" fails because of the issue #26101.

----------
nosy: +brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 11:44:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 16:44:33 +0000
Subject: [issue26100] Add test.support.optim_args_from_interpreter_flags()
In-Reply-To: <1452702751.92.0.809582535795.issue26100@psf.upfronthosting.co.za>
Message-ID: <1452703473.82.0.695999589075.issue26100@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 2: I forgot Lib/test/test_cmd_line_script.py.

----------
Added file: http://bugs.python.org/file41608/optim_args-2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 11:52:12 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 13 Jan 2016 16:52:12 +0000
Subject: [issue25752] asyncio.readline - add customizable line separator
In-Reply-To: <1448659598.46.0.288346349625.issue25752@psf.upfronthosting.co.za>
Message-ID: <1452703932.76.0.60210905339.issue25752@psf.upfronthosting.co.za>


???? ????????? added the comment:

During development, we decide not to change readline() function. So, yes, this issue is closed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 12:01:32 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 17:01:32 +0000
Subject: [issue25752] asyncio.readline - add customizable line separator
In-Reply-To: <1448659598.46.0.288346349625.issue25752@psf.upfronthosting.co.za>
Message-ID: <1452704492.3.0.181811918462.issue25752@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy:  -haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 12:26:19 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Jan 2016 17:26:19 +0000
Subject: [issue26101] Lib/test/test_compileall.py fails when run directly
In-Reply-To: <1452703257.16.0.0951114007651.issue26101@psf.upfronthosting.co.za>
Message-ID: <1452705979.28.0.598399365493.issue26101@psf.upfronthosting.co.za>


Brett Cannon added the comment:

A cleaner way to do what you're after is to use test_importlib.util.import_state() where you can pass in an explicit value for sys.path to be temporarily set.

Otherwise I'm fine with the idea of the proposed change.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 12:29:53 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 17:29:53 +0000
Subject: [issue26101] Lib/test/test_compileall.py fails when run directly
In-Reply-To: <1452703257.16.0.0951114007651.issue26101@psf.upfronthosting.co.za>
Message-ID: <1452706193.02.0.458925518144.issue26101@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> A cleaner way to do what you're after is to use test_importlib.util.import_state() where you can pass in an explicit value for sys.path to be temporarily set.

I would prefer to not couple test_importlib and test_compileall to keep tests independent. If you consider that it's worth, import_state() must be moved to test.support.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 12:39:53 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jan 2016 17:39:53 +0000
Subject: [issue3824] test_tarfile fails on cygwin (unicode decode error)
In-Reply-To: <1220992929.24.0.0835677599554.issue3824@psf.upfronthosting.co.za>
Message-ID: <1452706793.63.0.502720474543.issue3824@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
resolution:  -> out of date
stage:  -> resolved
status: pending -> closed
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 12:42:51 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Jan 2016 17:42:51 +0000
Subject: [issue26093] __qualname__ different when calling generator object w/
 functions.partial
In-Reply-To: <1452638028.1.0.595104762218.issue26093@psf.upfronthosting.co.za>
Message-ID: <1452706971.42.0.852185913322.issue26093@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
nosy: +brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 12:44:42 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Jan 2016 17:44:42 +0000
Subject: [issue26099] site ignores ImportError when running sitecustomize and
 usercustomize
In-Reply-To: <1452696404.05.0.367833198211.issue26099@psf.upfronthosting.co.za>
Message-ID: <1452707082.42.0.365065880827.issue26099@psf.upfronthosting.co.za>


Brett Cannon added the comment:

This is a change in semantics. It might be better to log an ImportWarning when the import fails and keep the current semantics (and be careful about importing warnings).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 12:47:59 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Jan 2016 17:47:59 +0000
Subject: [issue26101] Lib/test/test_compileall.py fails when run directly
In-Reply-To: <1452703257.16.0.0951114007651.issue26101@psf.upfronthosting.co.za>
Message-ID: <1452707279.51.0.917888946519.issue26101@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Don't care enough to do the work to separate it out, so if you don't want to bother either then LGTM.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 12:48:15 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Jan 2016 17:48:15 +0000
Subject: [issue26101] Lib/test/test_compileall.py fails when run directly
In-Reply-To: <1452703257.16.0.0951114007651.issue26101@psf.upfronthosting.co.za>
Message-ID: <1452707295.12.0.465013868361.issue26101@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
assignee:  -> haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 14:20:24 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Jan 2016 19:20:24 +0000
Subject: [issue25668] Deadlock in logging caused by a possible race condition
 with "format"
In-Reply-To: <1447942973.46.0.788007678714.issue25668@psf.upfronthosting.co.za>
Message-ID: <1452712824.16.0.864122690437.issue25668@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
nosy:  -r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 14:41:38 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 13 Jan 2016 19:41:38 +0000
Subject: [issue22642] trace module: convert to argparse
In-Reply-To: <1413377180.82.0.707385230262.issue22642@psf.upfronthosting.co.za>
Message-ID: <1452714098.74.0.679553155582.issue22642@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks, Senthil. My comment was for Vajrasky's patch, not for the whole argparse switch. We need to add tests for the old getopt code first to avoid regressions. After 0aa46b9ffba3, if we add tests we won't be able to test the old interface.

My other comments:

* SilentGhost needs to fill the contributor's agreement form. We generally accept trivial patches without asking CA, but I think we can't accept 0aa46b9ffba3 without one since the patch is huge.
* I don't think we add reST formatted docstring to stdlib. The javadoc style one in Trace.__init__() is 13 years old so we can ignore it.
* I also have some minor comments, but I don't think they are important at this point :)

----------
nosy: +berker.peksag

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 14:43:42 2016
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Wed, 13 Jan 2016 19:43:42 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <1452714222.69.0.0686091737364.issue25924@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

An Apple Developer Relations engineer tells me it's "reasonable to assume that getaddrinfo() is thread safe" on OS X 10.5 and later. (He mentioned that iOS inherited the OS X 10.5 DNS architecture, so Apple phones, watches, TVs, hairdryers, etc. can all do concurrent DNS too.)

Before OS X 10.5 the DNS system was a mix of new Mac OS X features, mDNSResponder and Open Directory, along with historical lookupd from NeXT and libresolv from an old BSD. In 10.5 the system was cleaned up to depend on OS X's mDNSResponder consistently; in the process getaddrinfo became thread-safe.

He cites as further evidence of its thread safety:

* The "bugs" section of getaddrinfo's man page was removed in 10.5
* 10.5 is the first OS X to be UNIX '03 certified, which includes the requirement that getaddrinfo be thread-safe
* The system itself uses getaddrinfo extensively as if it's thread-safe
* He hasn't seen reports of thread-safety problems with getaddrinfo

He explained how the code works. In the latest version:

http://www.opensource.apple.com/source/Libinfo/Libinfo-476/lookup.subproj/libinfo.c

getaddrinfo calls down to libinfo?s "mdns" module:

http://www.opensource.apple.com/source/Libinfo/Libinfo-476/lookup.subproj/mdns_module.c

"mdns" uses the DNS-SD API declared in dns_sd.h, which he says is "well known to be thread safe." The DNS-SD API is part of the mDNSResponder project:

http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-576.30.4/

The key function is DNSServiceQueryRecord:

http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-576.30.4/mDNSShared/dnssd_clientstub.c

My contact concludes, "As you can see, it does an IPC over to the mDNSResponder process, at which point thread safety is assured."

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 14:47:51 2016
From: report at bugs.python.org (Christian Berger)
Date: Wed, 13 Jan 2016 19:47:51 +0000
Subject: [issue26102] access violation in PyErrFetch if tcur==null in
 PyGILState_Release
Message-ID: <1452714471.66.0.669763876009.issue26102@psf.upfronthosting.co.za>


New submission from Christian Berger:

I've been messing with PyGILState_... handling for my embedded python interpreter and came across this issue:

code in PyGILState_Release:

    PyThreadState *tcur = (PyThreadState *)PyThread_get_key_value(
                                                            autoTLSkey);
    if (tcur == NULL)
        Py_FatalError("auto-releasing thread-state, "
                      "but no thread-state for this thread");

The Py_FatalError() call will then invoke PyErr_Fetch() which won't check if PyThreadState_GET() returns a valid ptr (!= NULL):

PyErr_Fetch(PyObject **p_type, PyObject **p_value, PyObject **p_traceback)
{
    PyThreadState *tstate = PyThreadState_GET();
    *p_type = tstate->curexc_type;

----------
components: Interpreter Core
messages: 258164
nosy: cberger
priority: normal
severity: normal
status: open
title: access violation in PyErrFetch if tcur==null in PyGILState_Release
type: crash
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 15:08:46 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 13 Jan 2016 20:08:46 +0000
Subject: [issue23762] python.org page on new-style classes should be updated
In-Reply-To: <1427207285.84.0.436806674049.issue23762@psf.upfronthosting.co.za>
Message-ID: <1452715726.22.0.233763831689.issue23762@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I've now added a warning to the document.

----------
stage: needs patch -> resolved
status: pending -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 15:21:30 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Jan 2016 20:21:30 +0000
Subject: [issue7944] Use the 'with' statement in conjunction with 'open'
 throughout test modules
In-Reply-To: <1266342231.42.0.692171370087.issue7944@psf.upfronthosting.co.za>
Message-ID: <20160113202127.121140.8412@psf.io>


Roundup Robot added the comment:

New changeset e3763d98c46e by Ezio Melotti in branch '2.7':
#7944: close files explicitly in test_tarfile (backport d560eece0857).
https://hg.python.org/cpython/rev/e3763d98c46e

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 15:23:00 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jan 2016 20:23:00 +0000
Subject: [issue7944] Use the 'with' statement in conjunction with 'open'
 throughout test modules
In-Reply-To: <1266342231.42.0.692171370087.issue7944@psf.upfronthosting.co.za>
Message-ID: <1452716580.76.0.905522853128.issue7944@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Thanks for the patch, however I got several errors while trying to apply it, so I ended up backporting d560eece0857 instead.
This can be closed now.

----------
assignee:  -> ezio.melotti
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 15:56:52 2016
From: report at bugs.python.org (Aaron Hall)
Date: Wed, 13 Jan 2016 20:56:52 +0000
Subject: [issue26103] Contradiction in definition of "data descriptor" between
 (dotted lookup behavior/datamodel documentation) and (inspect
 lib/descriptor how-to)
Message-ID: <1452718612.1.0.925403449689.issue26103@psf.upfronthosting.co.za>


New submission from Aaron Hall:

Based on the data-model documentation (https://docs.python.org/2/reference/datamodel.html#invoking-descriptors) and the dotted lookup behavior, the follow definitions are correct:

"If the descriptor defines __set__() and/or __delete__(), it is a data descriptor; if it defines neither, it is a non-data descriptor."

def has_data_descriptor_attrs(obj):
    return set(['__set__', '__delete__']) & set(dir(obj))

def is_data_descriptor(obj):
    return bool(has_data_descriptor_attrs(obj))


However, the inspect module has the following, which is also reflected in the descriptor how-to (https://docs.python.org/2/howto/descriptor.html#descriptor-protocol):

"If an object defines both __get__() and __set__(), it is considered a data descriptor."

def isdatadescriptor(object):
    """Return true if the object is a data descriptor.

    Data descriptors have both a __get__ and a __set__ attribute..."""
    if isclass(object) or ismethod(object) or isfunction(object):
        # mutual exclusion
        return False
    tp = type(object)
    return hasattr(tp, "__set__") and hasattr(tp, "__get__")


I'm willing to sign a contributor release and fix myself.

----------
messages: 258168
nosy: Aaron Hall
priority: normal
severity: normal
status: open
title: Contradiction in definition of "data descriptor" between (dotted lookup behavior/datamodel documentation) and (inspect lib/descriptor how-to)
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 16:16:40 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 13 Jan 2016 21:16:40 +0000
Subject: [issue25668] Deadlock in logging caused by a possible race condition
 with "format"
In-Reply-To: <1447942973.46.0.788007678714.issue25668@psf.upfronthosting.co.za>
Message-ID: <1452719800.26.0.882570062838.issue25668@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Logging has been in the Python stdlib for over a dozen years, and in all that time, no one else has had a problem with the way handler locks and formatting work in logging. Your problem arises because your use case is very unusual, and this is why I don't propose to make changes to the stdlib to cater for it. You can, as I've suggested earlier, subclass the handlers you need and implement their emit methods as per your needs. Any changes to the stdlib code along the lines you've proposed could well break existing code for other people, so making these changes is not warranted.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 16:18:27 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 13 Jan 2016 21:18:27 +0000
Subject: [issue24203] Deprecate threading.Thread.isDaemon etc
In-Reply-To: <1431707934.14.0.173246279453.issue24203@psf.upfronthosting.co.za>
Message-ID: <1452719907.94.0.0186335299971.issue24203@psf.upfronthosting.co.za>


Berker Peksag added the comment:

The docs for old API already say:

    Old getter/setter API for name; use it directly as a property instead.

https://docs.python.org/3.5/library/threading.html#threading.Thread.getName

Users don't read the documentation every six or fifteen months so it would be nice to document old APIs properly as deprecated. And I don't think documentation-only deprecation would work. See issue 25964 for a real world example. Users still don't know that optparse is deprecated.

> We don't have to deprecate this for any reason other than to satisfy a personal sense of neatness and compactness.

The original request came from a Python user, not from a new generation perfectionist core developer.

> For the sake of developers who rely on the standard library being "standard" and for the mountains of existing code on PyPI, we need to have a strong aversion to unnecessary deprecations.

That doesn't mean we shouldn't tell users "Hey, there is a new API which was added back in 2008. Use it if you want to."

> [...] and they increase the likelihood that package distributors will monkey-patch or duplicate the code to restore prior behavior (for example, the Hypothesis project will likely have to duplicate the code that was recently taken out of the inspect module in favor of signature objects).

I'm not sure we are on the same page here. I already said that I don't want to remove the old API, but document it properly as deprecated. The inspect case you've mentioned has already been solved in issue 25486. See issue 26069 (old trace API) and issue 26041 (platform.dist() and platform.linux_distribution() deprecation) for my views on deprecation policy.

> We should put more focus on proposed new APIs and making sure that they are something we want to live with for a very long time.

Agreed, but we need to advertise new APIs better. Otherwise no one is going to notice and use them. I think deprecating old APIs (with a clear upgrade path) would be a good way to promote new ones.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 16:32:36 2016
From: report at bugs.python.org (Rose Ames)
Date: Wed, 13 Jan 2016 21:32:36 +0000
Subject: [issue25791] Raise an ImportWarning when __spec__.parent/__package__
 isn't defined for a relative import
In-Reply-To: <1449175692.43.0.67090220632.issue25791@psf.upfronthosting.co.za>
Message-ID: <1452720756.17.0.656966821817.issue25791@psf.upfronthosting.co.za>


Changes by Rose Ames :


----------
keywords: +patch
Added file: http://bugs.python.org/file41609/issue25791.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 16:34:49 2016
From: report at bugs.python.org (Rose Ames)
Date: Wed, 13 Jan 2016 21:34:49 +0000
Subject: [issue25791] Raise an ImportWarning when __spec__.parent/__package__
 isn't defined for a relative import
In-Reply-To: <1449175692.43.0.67090220632.issue25791@psf.upfronthosting.co.za>
Message-ID: <1452720889.51.0.546471616711.issue25791@psf.upfronthosting.co.za>


Rose Ames added the comment:

Patch with tests.  Not sure if importlib.h should be included?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 16:36:08 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Jan 2016 21:36:08 +0000
Subject: [issue25791] Raise an ImportWarning when __spec__.parent/__package__
 isn't defined for a relative import
In-Reply-To: <1449175692.43.0.67090220632.issue25791@psf.upfronthosting.co.za>
Message-ID: <1452720968.3.0.788157086179.issue25791@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Including importlib.h doesn't hurt.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 16:39:28 2016
From: report at bugs.python.org (Rose Ames)
Date: Wed, 13 Jan 2016 21:39:28 +0000
Subject: [issue25791] Raise an ImportWarning when __spec__.parent/__package__
 isn't defined for a relative import
In-Reply-To: <1449175692.43.0.67090220632.issue25791@psf.upfronthosting.co.za>
Message-ID: <1452721168.68.0.606776916475.issue25791@psf.upfronthosting.co.za>


Rose Ames added the comment:

that's what I figured.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 16:51:20 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 13 Jan 2016 21:51:20 +0000
Subject: [issue26069] Remove the Deprecated API in trace module
In-Reply-To: <1452385226.89.0.6584761467.issue26069@psf.upfronthosting.co.za>
Message-ID: <1452721880.45.0.419708005059.issue26069@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Sorry, I don't have much time investigate this further, but here is a few references from my bookmarks:

* http://bugs.python.org/msg253473 (from issue 20438)
* https://hg.python.org/peps/rev/570913685f49 (this doesn't mention old APIs, but I think we can safely follow it for old APIs)

Another discussions about deprecation policy: issue 24203 (old threading API), issue 25486 (inspect.getargspec()) and issue 26041 (platform.dist() and platform.linux_distribution())

If you want to keep the old API removed, it would be great to add a note in Doc/whatsnew/3.6.rst in addtion to the Misc/NEWS entry.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 17:13:12 2016
From: report at bugs.python.org (Maciej Szulik)
Date: Wed, 13 Jan 2016 22:13:12 +0000
Subject: [issue25591] refactor imaplib tests
In-Reply-To: <1447107407.81.0.130095933409.issue25591@psf.upfronthosting.co.za>
Message-ID: <1452723192.84.0.478936784763.issue25591@psf.upfronthosting.co.za>


Maciej Szulik added the comment:

David can you please take a look once more, I've applied all the changes you've asked for. I'm currently working on adding the existing tests rewritten to use the new framework so it's easy to compare. It's still in progress but the general idea should maintain.

----------
keywords: +patch
Added file: http://bugs.python.org/file41610/new_imap_tests_v2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 17:24:30 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 13 Jan 2016 22:24:30 +0000
Subject: [issue26104] Reference leak in functools.partial constructor in
 failure case
Message-ID: <1452723870.39.0.274687476417.issue26104@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

Minor bug introduced while implementing the fix for #7830:

In the case where functools.partial is wrapping another functools.partial instance, both of them providing positional arguments, the value nargs is not freed when the tuple concatenation fails and the constructor raises an Exception/returns NULL. Only nargs has the problem (it's a slice of the args passed to the function); pargs is a borrowed reference so there is no leak there. Admittedly, the odds of failure is incredibly low, but best to fix it on principle.

Code link: https://hg.python.org/cpython/file/5a2692911a43/Modules/_functoolsmodule.c#l77

The simplest fix is to add the explicit DECREF in the error path:

        pto->args = PySequence_Concat(pargs, nargs);
        if (pto->args == NULL) {
            pto->kw = NULL;
            Py_DECREF(nargs);  // <-- New
            Py_DECREF(pto);
            return NULL;
        }

All other code paths hit a DECREF later on, no other fixes required. I'd submit a proper patch, but I'm on a new machine and I've got a lot of work to get the repos set up again.

----------
components: Extension Modules
messages: 258176
nosy: belopolsky, josh.r
priority: normal
severity: normal
status: open
title: Reference leak in functools.partial constructor in failure case
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 17:46:43 2016
From: report at bugs.python.org (Florent Viard)
Date: Wed, 13 Jan 2016 22:46:43 +0000
Subject: [issue25668] Deadlock in logging caused by a possible race condition
 with "format"
In-Reply-To: <1447942973.46.0.788007678714.issue25668@psf.upfronthosting.co.za>
Message-ID: <1452725202.99.0.17898175741.issue25668@psf.upfronthosting.co.za>


Florent Viard added the comment:

Come on, please stop trying to close the issue so fast without deeply thinking about it.

A lot of years without a "detailed" bug report indicating the root cause is not a "proof" that there is no bug. Otherwise, you can say that there is no more bug in python, because people used it for 15 years...

The issue looks easy with the explanation and the test case, but it took me a lot of hours of investigation to figure out the origin of the freeze of python that I was lucky to be able to reproduce because of good specific conditions. And so I was able to try to have stack traces to find the origin of the issue. But race conditions like that are hard to catch, and to investigate but can bit anyone.

Please tell me what is unusual for you with this testcase? The sleeps are here to put you in the "good"/bad condition, but you can remove it and try to run the testcase 1 million times to be in the standard race condition situation...

----------
resolution: not a bug -> 
status: closed -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 18:00:29 2016
From: report at bugs.python.org (Rose Ames)
Date: Wed, 13 Jan 2016 23:00:29 +0000
Subject: [issue25791] Raise an ImportWarning when __spec__.parent/__package__
 isn't defined for a relative import
In-Reply-To: <1449175692.43.0.67090220632.issue25791@psf.upfronthosting.co.za>
Message-ID: <1452726029.23.0.219372734555.issue25791@psf.upfronthosting.co.za>


Rose Ames added the comment:

Thanks for the quick review, new patch uploaded.

----------
Added file: http://bugs.python.org/file41611/issue25791_2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 18:15:13 2016
From: report at bugs.python.org (Connor Wolf)
Date: Wed, 13 Jan 2016 23:15:13 +0000
Subject: [issue26105] Python JSON module doesn't actually produce JSON
Message-ID: <1452726913.68.0.934947942911.issue26105@psf.upfronthosting.co.za>


New submission from Connor Wolf:

The Python library JSON library doesn't emit JSON by default.

Basically, `json.dumps(float('nan'))` produces something that kind of looks like json, but isn't (specifically, `'NaN'`). Valid JSON must be `null`.

JSON *does not allow `NaN`, `infinity`, or `-infinity`. 

`json.dump[s]` has the parameter `allow_nan`, but it's `False` by default, so basically it's not actually JSON by default.

The default for emitting JSON should actually emit JSON. `allow_nan` must be `True` by default.

----------
components: Library (Lib)
messages: 258179
nosy: Connor.Wolf
priority: normal
severity: normal
status: open
title: Python JSON module doesn't actually produce JSON
versions: Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 18:16:28 2016
From: report at bugs.python.org (Julien)
Date: Wed, 13 Jan 2016 23:16:28 +0000
Subject: [issue26106] Move licences to literal blocks
Message-ID: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>


New submission from Julien:

In the context of translating the documentation:

I'd like to move the licence texts in https://docs.python.org/3.5/license.html to literal blocks, so they won't pollute the po files with legal (untranslatable) stuff, and it's visually more appealing (as far as it's possible for a licence text).

Here is what it gives graphically when applying the patch (it's the translation, don't mind the french text): http://www.afpy.org/doc/python/3.5/license.html

I also took the liberty to drop a dangling "ACCEPT", while reformating centered "titles" to real titles and building paragraphs from licence text, hope it wasn't legal stuff / part of the licence (a line before the licence mention an "accept" button ...).

----------
assignee: docs at python
components: Documentation
files: literal-licence.patch
keywords: patch
messages: 258180
nosy: docs at python, sizeof
priority: normal
severity: normal
status: open
title: Move licences to literal blocks
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41612/literal-licence.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 18:19:58 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jan 2016 23:19:58 +0000
Subject: [issue26105] Python JSON module doesn't actually produce JSON
In-Reply-To: <1452726913.68.0.934947942911.issue26105@psf.upfronthosting.co.za>
Message-ID: <1452727198.75.0.265058795252.issue26105@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

This is documented at https://docs.python.org/3/library/json.html#standard-compliance-and-interoperability and https://docs.python.org/3/library/json.html#infinite-and-nan-number-values
The default could be changed if we go through a deprecation process, but I'm not sure it's worth it.

----------
nosy: +ezio.melotti
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
versions: +Python 3.5, Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 18:28:27 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jan 2016 23:28:27 +0000
Subject: [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <1452727707.82.0.111128451781.issue26106@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Sounds like a reasonable request to me.
Given the content of document, special care should be taken in reviewing the patch and making sure that nothing has gone missing.

----------
nosy: +ezio.melotti
stage:  -> patch review
type:  -> enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 18:40:34 2016
From: report at bugs.python.org (Connor Wolf)
Date: Wed, 13 Jan 2016 23:40:34 +0000
Subject: [issue26105] Python JSON module doesn't actually produce JSON
In-Reply-To: <1452726913.68.0.934947942911.issue26105@psf.upfronthosting.co.za>
Message-ID: <1452728434.25.0.353545465405.issue26105@psf.upfronthosting.co.za>


Connor Wolf added the comment:

The problem here is that JSON is *everywhere*, and I only ran into this particular issue after a whole bunch of digging as to why my "JSON" messages were disappearing in some javascript. 

Basically, with the default the way it is, you have interoperability bombs in every project that uses it to interface with other languages. In my case, I'm using Flask-SocketIO ( https://github.com/miguelgrinberg/Flask-SocketIO ), which uses JSON as it's transport, and it works fine until you have a NaN or infinity in your data, at which point the socket.io in the browser starts *silently* eating messages.

Basically, if I call json.dumps, the principle of least astonishment dictated that you actually get, you know, JSON.

If you have a module called something like `pyson`, and it's partially JSON compatible, that makes sense. For the JSON module to fail at the very thing it's named after is kind of ludicrous.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 19:20:29 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Jan 2016 00:20:29 +0000
Subject: [issue25791] Raise an ImportWarning when __spec__.parent/__package__
 isn't defined for a relative import
In-Reply-To: <1449175692.43.0.67090220632.issue25791@psf.upfronthosting.co.za>
Message-ID: <1452730829.2.0.0495144226886.issue25791@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 21:34:55 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2016 02:34:55 +0000
Subject: [issue26059] Integer Overflow in strop.replace()
In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za>
Message-ID: <1452738895.19.0.44305161825.issue26059@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Do you have any idea how to fix it?

strop is a deprecated module, you can write ("\x100"  *0xEAAA).replace("\x100", "AA"*0xAAAA). Does this instruction also crash?

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 23:42:22 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 14 Jan 2016 04:42:22 +0000
Subject: [issue25822] Add docstrings to fields of urllib.parse results
In-Reply-To: <1449566140.42.0.349073725206.issue25822@psf.upfronthosting.co.za>
Message-ID: <1452746542.34.0.0456479676197.issue25822@psf.upfronthosting.co.za>


Changes by Senthil Kumaran :


----------
assignee:  -> orsenthil

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 02:27:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Jan 2016 07:27:01 +0000
Subject: [issue26104] Reference leak in functools.partial constructor in
 failure case
In-Reply-To: <1452723870.39.0.274687476417.issue26104@psf.upfronthosting.co.za>
Message-ID: <1452756421.59.0.80305067413.issue26104@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This bug is fixed by more comprehensive patch for issue25945.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Type confusion in partial_setstate and partial_call leads to memory corruption

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 03:02:57 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Jan 2016 08:02:57 +0000
Subject: [issue25945] Type confusion in partial_setstate and partial_call
 leads to memory corruption
In-Reply-To: <1451017001.94.0.489150526382.issue25945@psf.upfronthosting.co.za>
Message-ID: <1452758577.48.0.756135008621.issue25945@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
assignee: serhiy.storchaka -> rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 03:03:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Jan 2016 08:03:14 +0000
Subject: [issue25455] Some repr implementations don't check for
 self-referential structures
In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za>
Message-ID: <1452758594.82.0.206205803973.issue25455@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
assignee:  -> rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 03:11:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Jan 2016 08:11:49 +0000
Subject: [issue25822] Add docstrings to fields of urllib.parse results
In-Reply-To: <1449566140.42.0.349073725206.issue25822@psf.upfronthosting.co.za>
Message-ID: <20160114081146.14796.62273@psf.io>


Roundup Robot added the comment:

New changeset 7bfcb8b75ad9 by Senthil Kumaran in branch 'default':
Issue #25822: Add docstrings to the fields of urllib.parse results.
https://hg.python.org/cpython/rev/7bfcb8b75ad9

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 03:17:37 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 14 Jan 2016 08:17:37 +0000
Subject: [issue25822] Add docstrings to fields of urllib.parse results
In-Reply-To: <1449566140.42.0.349073725206.issue25822@psf.upfronthosting.co.za>
Message-ID: <1452759457.58.0.679912062149.issue25822@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thank you, Swati. 

I reviewed and committed your patch. I had to make some minor formatting changes while keeping an eye for the maintainability of the module and doc strings.

* Moved all the doc strings up to a single place just below the namespaces are declared.
* Followed pep-0257 conventions for doc strings.
* Tried DRY for parse result's sub-components.

Thanks for addressing the review comments from other developers.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 03:48:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Jan 2016 08:48:15 +0000
Subject: [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <1452761295.04.0.246639419147.issue26106@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Does the |release| substitution work in literal blocks?

----------
nosy: +brett.cannon, georg.brandl, ned.deily, serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 04:12:46 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2016 09:12:46 +0000
Subject: [issue26107] code.co_lnotab: use signed line number delta to support
 moving instructions in an optimizer
Message-ID: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Python doesn't store the original line number in the .pyc file in the bytecode. Instead, an efficient table is used to find the line number from the current in the bytecode: code.co_lnotab.

Basically, it's a list of (offset_delta, line_number_delta) pairs where offset_delta and line_number_delta are unsigned 8 bits numbers. If an offset delta is larger than 255, (offset_delta % 255, line_number_delta) and (offset_delta // 255, 0) pairs are emited. Same for line_number_delta. (In fact, more than two pairs can be created.)

The format is described in Objects/lnotab_notes.txt.

I implemented an optimizer which can generate *negative* line number. For example, the loop:

   for i in range(2):   # line 1
      print(i)          # line 2

is replaced with:

   i = 0      # line 1
   print(i)   # line 2
   i = 1      # line 1
   print(i)   # line 2

The third instruction has a negative line number delta.

I'm not the first one hitting the issue, but it's just that no one proposed a patch before. Previous projects bitten by this issue:

* issue #10399: "AST Optimization: inlining of function calls"
* issue #11549: "Build-out an AST optimizer, moving some functionality out of the peephole optimizer"

Attached patch changes the type of line number delta from unsigned 8-bit integer to *signed* 8-bit integer. If a line number delta is smaller than -128 or larger than 127, multiple pairs are created (as before).

My code in Lib/dis.py is inefficient. Maybe unpack the full lnotab than *then* skip half of the bytes? (instead of calling struct.unpack times for each byte).

The patch adds also "assert(Py_REFCNT(lnotab_obj) == 1);" to PyCode_Optimize(). The assertion never fails, but it's just to be extra safe.

The patch renames variables in PyCode_Optimize() because I was confused between "offset" and "line numbers". IMHO variables were badly named.

I changed the MAGIC_NUMBER of importlib, but it was already changed for f-string:

#     Python 3.6a0  3360 (add FORMAT_VALUE opcode #25483)

Is it worth to modify it again?

You may have to recompile Python/importlib_external.h if it's not recompiled automatically (just touch the file before running make).

Note: this issue is related to the PEP 511 (the PEP is not ready for a review, but it gives a better overview of the use cases.)

----------
files: lnotab.patch
keywords: patch
messages: 258189
nosy: brett.cannon, haypo, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: code.co_lnotab: use signed line number delta to support moving instructions in an optimizer
versions: Python 3.6
Added file: http://bugs.python.org/file41613/lnotab.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 04:15:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Jan 2016 09:15:43 +0000
Subject: [issue26107] code.co_lnotab: use signed line number delta to support
 moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <20160114091540.19312.90409@psf.io>


Roundup Robot added the comment:

New changeset c4a826184937 by Victor Stinner in branch 'default':
PEP 511: add link to issue #26107
https://hg.python.org/peps/rev/c4a826184937

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 04:16:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2016 09:16:09 +0000
Subject: [issue26107] code.co_lnotab: use signed line number delta to support
 moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1452762969.44.0.405204582947.issue26107@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
components: +Interpreter Core
type:  -> enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 04:20:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2016 09:20:10 +0000
Subject: [issue26107] code.co_lnotab: use signed line number delta to support
 moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1452763210.47.0.312620833485.issue26107@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Attached patch changes the type of line number delta from unsigned 8-bit integer to *signed* 8-bit integer. If a line number delta is smaller than -128 or larger than 127, multiple pairs are created (as before).

The main visible change is that .pyc files can be a little bit larger and so use more disk space. Well... in fact only .pyc of files using line number delta larger than 127.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 04:36:41 2016
From: report at bugs.python.org (Julien)
Date: Thu, 14 Jan 2016 09:36:41 +0000
Subject: [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <1452764201.44.0.186926468245.issue26106@psf.upfronthosting.co.za>


Julien added the comment:

@Serhiy Well spotted, it does not work (as we can see here http://www.afpy.org/doc/python/3.5/license.html).

Anyone having a better background than me in ReStructuredText have an idea ?

About the review of the patch, as a human review may be fastidious, here a script to check that I did NOT modified the content of the licences themselves (still need to trust the command, but it's faster to review than the whole licence text itself):

    diff -w <(grep '^-' literal-licence.patch | cut -b2-) <(grep '^+' literal-licence.patch | cut -b2- | sed 's/\(^ *\)[0-8]\./\1#./g')

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 04:45:03 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 14 Jan 2016 09:45:03 +0000
Subject: [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <1452764703.0.0.54571839281.issue26106@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Since the text does need no highlighting, a parsed-literal block should work.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 04:53:50 2016
From: report at bugs.python.org (David Heffernan)
Date: Thu, 14 Jan 2016 09:53:50 +0000
Subject: [issue26108] Calling PyInitialize with 2.7.11 on Windows x64
 terminates process
Message-ID: <1452765230.72.0.612722422255.issue26108@psf.upfronthosting.co.za>


New submission from David Heffernan:

Environment: 
 - Python 2.7.11 from python.org, x64.
 - Windows 10 or Windows 8.1
 - MSVC 2015

I compiled the most basic embedding example, taken from the Python docs:

#include 

int
main(int argc, char *argv[])
{
  Py_SetProgramName(argv[0]);  /* optional but recommended */
  Py_Initialize();
  PyRun_SimpleString("from time import time,ctime\n"
                     "print 'Today is',ctime(time())\n");
  Py_Finalize();
  return 0;
}

When run the call to Py_Initialize does not return and the process is terminated.

----------
components: Windows
messages: 258194
nosy: David Heffernan, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Calling PyInitialize with 2.7.11 on Windows x64 terminates process
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 04:55:30 2016
From: report at bugs.python.org (David Heffernan)
Date: Thu, 14 Jan 2016 09:55:30 +0000
Subject: [issue26108] Calling PyInitialize with 2.7.11 on Windows x64
 terminates process
In-Reply-To: <1452765230.72.0.612722422255.issue26108@psf.upfronthosting.co.za>
Message-ID: <1452765330.74.0.971724244853.issue26108@psf.upfronthosting.co.za>


David Heffernan added the comment:

Note that I've just listed the Windows versions on which I have tested this. I have not tested on Windows 7 or Vista so do not know whether or not the issue exists there.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 05:38:08 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 14 Jan 2016 10:38:08 +0000
Subject: [issue25945] Type confusion in partial_setstate and partial_call
 leads to memory corruption
In-Reply-To: <1451017001.94.0.489150526382.issue25945@psf.upfronthosting.co.za>
Message-ID: <1452767888.46.0.770104014672.issue25945@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I didn't do a full review of the C code changes, but the new test cases look good to me, and the changes specifically to partial_setstate also look good.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 07:32:42 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Jan 2016 12:32:42 +0000
Subject: [issue26107] code.co_lnotab: use signed line number delta to support
 moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1452774762.13.0.955385765455.issue26107@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

A patch was proposed in issue16956. And issue17611 is related.

----------
nosy: +gvanrossum

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 07:52:23 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 14 Jan 2016 12:52:23 +0000
Subject: [issue26108] Calling PyInitialize with 2.7.11 on Windows x64
 terminates process
In-Reply-To: <1452765230.72.0.612722422255.issue26108@psf.upfronthosting.co.za>
Message-ID: <1452775943.08.0.202076881758.issue26108@psf.upfronthosting.co.za>


Eryk Sun added the comment:

Probably this is related to issue 25824. When built as a console application and run from the command prompt, you should see an the error

    ImportError: No module named site

If that's the case, the problem is that even the 64-bit build is incorrectly setting the DLL version string to "2.7-32":

    0:000> da poi(python27!PyWin_DLLVersionString)
    00000000`50b878c0  "2.7-32"

So the interpreter is looking at the wrong registry key to get the default sys.path:

    python27!getpythonregpath+0x110:
    00000000`509a3d90 ff15b2d20500    call    qword ptr
                [python27!_imp_RegOpenKeyExA (00000000`50a01048)]
                ds:00000000`50a01048=
                    {ADVAPI32!RegOpenKeyExAStub (00007ffb`56f87d70)}
    0:000> da @rdx
    00000037`e4fd9940  "Software\Python\PythonCore\2.7-3"
    00000037`e4fd9960  "2\PythonPath"

As a workaround, before calling Py_Initialize, add Py_SetPythonHome("C:\\Python27"), or wherever you installed Python. Or create a symbolic link to Python's Lib directory in the directory that has your executable:

    mklink /d Lib "C:\Python27\Lib"

Or 'fix' the "SOFTWARE\Python\PythonCore\2.7" registry key by renaming it to "2.7-32". Or downgrade to 2.7.10 until 2.7.12 is released. 

That said, probably you'll use a zipped library if distributing an application, in which case this shouldn't be a problem.

----------
nosy: +eryksun

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 08:10:34 2016
From: report at bugs.python.org (John Malmberg)
Date: Thu, 14 Jan 2016 13:10:34 +0000
Subject: [issue26109] _Py_DumpTraceback should be PyAPI_FUNC
Message-ID: <1452777034.65.0.00477411953399.issue26109@psf.upfronthosting.co.za>


New submission from John Malmberg:

The _PyDumpTraceback and _Py_DumpTracebackThreads routines in traceback.h are tagged with PyAPI_DATA attributes when they should be tagged with PyAPI_FUNC.

For platforms that use those attributes, this can cause run-time issues if those methods are called.

----------
components: Interpreter Core
messages: 258199
nosy: John.Malmberg
priority: normal
severity: normal
status: open
title: _Py_DumpTraceback should be PyAPI_FUNC
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 08:39:18 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Jan 2016 13:39:18 +0000
Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL
 certificate
In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za>
Message-ID: <20160114133914.24740.54343@psf.io>


Roundup Robot added the comment:

New changeset 81b3beea7e99 by Georg Brandl in branch '3.2':
Issue #25940: Backport self-signed.pythontest.net testing for test_httplib
https://hg.python.org/cpython/rev/81b3beea7e99

New changeset adf750b1252d by Martin Panter in branch '3.2':
Issue #25940: Use self-signed.pythontest.net in SSL tests
https://hg.python.org/cpython/rev/adf750b1252d

New changeset e167a9296947 by Martin Panter  in branch '3.3':
Issue #25940: Merge self-signed.pythontest.net testing from 3.2 into 3.3
https://hg.python.org/cpython/rev/e167a9296947

New changeset 32bcb9aa286e by Martin Panter  in branch '3.4':
Issue #25940: Merge self-signed.pythontest.net testing from 3.3 into 3.4
https://hg.python.org/cpython/rev/32bcb9aa286e

New changeset 0585c0089466 by Martin Panter  in branch '3.4':
Issue #25940: Update new SSL tests for self-signed.pythontest.net
https://hg.python.org/cpython/rev/0585c0089466

New changeset c3aa4b48b905 by Martin Panter  in branch '3.5':
Issue #25940: Merge self-signed.pythontest.net testing from 3.4 into 3.5
https://hg.python.org/cpython/rev/c3aa4b48b905

New changeset f5f14d65297e by Martin Panter  in branch '3.5':
Issue #25940: Update new SSL tests for self-signed.pythontest.net
https://hg.python.org/cpython/rev/f5f14d65297e

New changeset 2f2b42a8b34d by Martin Panter  in branch 'default':
Issue #25940: Merge self-signed.pythontest.net testing from 3.5
https://hg.python.org/cpython/rev/2f2b42a8b34d

New changeset ac94418299bd by Martin Panter  in branch 'default':
Issue #25940: test_ssl is working again
https://hg.python.org/cpython/rev/ac94418299bd

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 09:21:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Jan 2016 14:21:17 +0000
Subject: [issue26109] _Py_DumpTraceback should be PyAPI_FUNC
In-Reply-To: <1452777034.65.0.00477411953399.issue26109@psf.upfronthosting.co.za>
Message-ID: <1452781277.14.0.147486250624.issue26109@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Correction for searching: _Py_DumpTraceback and _Py_DumpTracebackThreads. They were added with the faulthandler module in issue11393.

----------
nosy: +haypo, serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 10:20:30 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2016 15:20:30 +0000
Subject: [issue26107] code.co_lnotab: use signed line number delta to support
 moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1452784830.96.0.618403270041.issue26107@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +Mark.Shannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 11:01:55 2016
From: report at bugs.python.org (Ramin Farajpour Cami)
Date: Thu, 14 Jan 2016 16:01:55 +0000
Subject: [issue26059] Integer Overflow in strop.replace()
In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za>
Message-ID: <1452787315.96.0.591688554464.issue26059@psf.upfronthosting.co.za>


Ramin Farajpour Cami added the comment:

Not work ,i think should check sizeof of memory avoid overflow 
assert(new_len > 0 && new_len <= PY_SSIZE_T_MAX);

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 11:30:15 2016
From: report at bugs.python.org (koobs)
Date: Thu, 14 Jan 2016 16:30:15 +0000
Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL
 certificate
In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za>
Message-ID: <1452789015.68.0.814369997587.issue25940@psf.upfronthosting.co.za>


koobs added the comment:

Wow. *thank you* Georg and Martin :)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 12:09:10 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 14 Jan 2016 17:09:10 +0000
Subject: [issue26110] Speedup method calls 1.2x
Message-ID: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

This issue supersedes issue #6033.  I decided to open a new one, since the patch is about Python 3.6 (not 2.7) and is written from scratch.

The idea is to add new opcodes to avoid instantiation of BoundMethods.  The patch only affects method calls of Python functions with positional arguments.

I'm working on the attached patch in this repo: https://github.com/1st1/cpython/tree/call_meth2

If the patch gets accepted, I'll update it with the docs etc.


Performance Improvements
------------------------

Method calls in micro-benchmarks are 1.2x faster:

### call_method ###
Avg: 0.330371 -> 0.281452: 1.17x faster

### call_method_slots ###
Avg: 0.333489 -> 0.280612: 1.19x faster

### call_method_unknown ###
Avg: 0.304949 -> 0.251623: 1.21x faster

Improvements in mini-benchmarks, such as Richards are less impressive, I'd say it's 3-7% improvement.  The full output of benchmarks/perf.py is here: https://gist.github.com/1st1/e00f11586329f68fd490

When the full benchmarks suite is run, some of them report that they were slow.  When I ran them separately several times, they all show no real slowdowns.  It's just some of them (such as nbody) are highly unstable.

It's actually possible to improve the performance another 1-3% if we fuse __PyObject_GetMethod with ceval/LOAD_METHOD code.  I've tried this here: https://github.com/1st1/cpython/tree/call_meth4, however I don't like to have so many details of object.c into ceval.c.


Changes in the Core
-------------------

Two new opcodes are added -- LOAD_METHOD and CALL_METHOD.  Whenever compiler sees a method call "obj.method(..)" with positional arguments it compiles it as follows:

  LOAD_FAST(obj)
  LOAD_METHOD(method)
  {call arguments}
  CALL_METHOD

LOAD_METHOD implementation in ceval looks up "method" on obj's type, and checks that it wasn't overridden in obj.__dict__.  Apparently, even with the __dict__ check this is still faster then creating a BoundMethod instance etc.  

If the method is found and not overridden, LOAD_METHOD pushes the resolved method object, and 'obj'.  If the method was overridden, the resolved method object and NULL are pushed to the stack.

CALL_METHOD then looks at the two stack values after call arguments.  If the first one isn't NULL, it means that we have a method call.


Why CALL_METHOD?
----------------

It's actually possible to hack CALL_FUNCTION to support LOAD_METHOD.  I've tried this approach in https://github.com/1st1/cpython/tree/call_meth3.  It looks like that adding extra checks in CALL_FUNCTION have negative impact on many benchmarks.  It's really easier to add another opcode.


Why only pure-Python methods?
-----------------------------

LOAD_METHOD atm works only with methods defined in pure Python.  C methods, such as `list.append` are still wrapped into a descriptor, that creates a PyCFunction object on each attribute access.  I've tried to do that in https://github.com/1st1/cpython/tree/call_cmeth.  It does impact C method calls in a positive way, although my implementation is very hacky.  It still uses LOAD_METHOD and CALL_METHOD opcodes, so my idea is to consider merging this patch first, and then introduce the necessary refactoring of PyCFunction and MethodDesctiptors in a separate issue.


Why only calls with positional arguments?
-----------------------------------------

As showed in "Why CALL_METHOD?", making CALL_FUNCTION to work with LOAD_METHOD slows it down.  For keyword and var-arg calls we have three more opcodes -- CALL_FUNCTION_VAR, CALL_FUNCTION_KW, and CALL_FUNCTION_VAR_KW.  I suspect that making them work with LOAD_METHOD would slow them down too, which will probably require us to add three (!) more opcodes for LOAD_METHOD.

And these kind of calls require much more overhead anyways, I don't expect them to be as optimizable as positional arg calls.

----------
assignee: yselivanov
components: Interpreter Core
files: call_method_1.patch
keywords: patch
messages: 258204
nosy: benjamin.peterson, brett.cannon, gvanrossum, haypo, ncoghlan, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Speedup method calls 1.2x
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file41614/call_method_1.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 12:44:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2016 17:44:01 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1452793441.57.0.711689033458.issue26110@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> For keyword and var-arg calls we have three more opcodes -- CALL_FUNCTION_VAR, CALL_FUNCTION_KW, and CALL_FUNCTION_VAR_KW.  I suspect that making them work with LOAD_METHOD would slow them down too, which will probably require us to add three (!) more opcodes for LOAD_METHOD.

I don't think that it's an issue to add 3 more opcodes for performance. If you prefer to limit the number of opcodes, you can pass a flag in arguments. For example, use 2 bytes for 2 arguments instead of only 1?

See also the (now old) WPython project which proposed kind of CISC instructions:
https://code.google.com/p/wpython/

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 12:51:33 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 14 Jan 2016 17:51:33 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1452793893.16.0.702583695864.issue26110@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> If you prefer to limit the number of opcodes, you can pass a flag in arguments. For example, use 2 bytes for 2 arguments instead of only 1?

I tried two approaches:

1. Push one more leading NULL to the stack in LOAD_METHOD (which makes it push 3 vals).  Then, in CALL_FUNCTION, detect when the callable is NULL and to the stuff that CALL_METHOD does.

2. Use a bitflag on oparg for CALL_FUNCTION and CALL_* opcodes.  This adds EXTENDED_ARG opcode overhead.

Long story short, the only option would be to add dedicated opcodes to work with LOAD_METHOD.  However, I'd prefer to first merge this patch, as it's relatively small and easy to review, and then focus on improving other things (keyword/*arg calls, C methods, etc).  This is just a first step.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 12:54:35 2016
From: report at bugs.python.org (David Heffernan)
Date: Thu, 14 Jan 2016 17:54:35 +0000
Subject: [issue26108] Calling PyInitialize with 2.7.11 on Windows x64
 terminates process
In-Reply-To: <1452765230.72.0.612722422255.issue26108@psf.upfronthosting.co.za>
Message-ID: <1452794075.25.0.393290920854.issue26108@psf.upfronthosting.co.za>


David Heffernan added the comment:

Thanks Eryk, everything you described happens exactly as you describe it. Much appreciated.

As it happens, I'm not distributing Python because I want to give my users the flexibility to use whatever version they please, and with whatever third party modules they want. So I'll just advise them to avoid 2.7.11.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 12:55:24 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 14 Jan 2016 17:55:24 +0000
Subject: [issue6033] LOOKUP_METHOD and CALL_METHOD optimization
In-Reply-To: <1242438240.35.0.944379800728.issue6033@psf.upfronthosting.co.za>
Message-ID: <1452794124.39.0.526268310259.issue6033@psf.upfronthosting.co.za>


Changes by Yury Selivanov :


----------
superseder:  -> Speedup method calls 1.2x

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 13:09:16 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Jan 2016 18:09:16 +0000
Subject: [issue26103] Contradiction in definition of "data descriptor" between
 (dotted lookup behavior/datamodel documentation) and (inspect
 lib/descriptor how-to)
In-Reply-To: <1452718612.1.0.925403449689.issue26103@psf.upfronthosting.co.za>
Message-ID: <1452794956.57.0.417888421457.issue26103@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
assignee:  -> docs at python
components: +Documentation, Library (Lib)
nosy: +docs at python, yselivanov
stage:  -> needs patch
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 13:19:07 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Jan 2016 18:19:07 +0000
Subject: [issue26096] '*' glob string matches dot files in pathlib
In-Reply-To: <1452651473.17.0.586447787765.issue26096@psf.upfronthosting.co.za>
Message-ID: <1452795547.81.0.48714269749.issue26096@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
components: +Library (Lib)
nosy: +gvanrossum, pitrou
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 13:20:55 2016
From: report at bugs.python.org (Jakub Klama)
Date: Thu, 14 Jan 2016 18:20:55 +0000
Subject: [issue25602] Add support for EVFILT_USER kqueue filter
In-Reply-To: <1447242368.46.0.687277732517.issue25602@psf.upfronthosting.co.za>
Message-ID: <1452795655.95.0.703134923968.issue25602@psf.upfronthosting.co.za>


Jakub Klama added the comment:

Hey, any news on this? I've created that issue over 2 months ago and it didn't get even commented since then.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 13:23:53 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Jan 2016 18:23:53 +0000
Subject: [issue26096] '*' glob string matches dot files in pathlib
In-Reply-To: <1452651473.17.0.586447787765.issue26096@psf.upfronthosting.co.za>
Message-ID: <1452795833.45.0.63242793241.issue26096@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'm frankly not sure that's a bug. If you want to filter out dotfiles, it is quite easy to do yourself. On the other hand, if pathlib always filtered them out, it would be more cumbersome to get a unified set of results with both dotfiles and non-dotfiles.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 13:29:20 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Jan 2016 18:29:20 +0000
Subject: [issue25957] sockaddr_l2 lacks CID,
 address type (AF_BLUETOOTH sockets)
In-Reply-To: <1451158541.36.0.577449474291.issue25957@psf.upfronthosting.co.za>
Message-ID: <1452796160.85.0.203370012316.issue25957@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
components: +Library (Lib)
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 13:32:44 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 14 Jan 2016 18:32:44 +0000
Subject: [issue26096] '*' glob string matches dot files in pathlib
In-Reply-To: <1452651473.17.0.586447787765.issue26096@psf.upfronthosting.co.za>
Message-ID: <1452796364.51.0.607670719811.issue26096@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I've thought about this too, and I've decided it's a feature. As Antoine says, it's easy enough to filter the dot files out if you don't want them; it's slightly complicated to include them if the default is to skip them.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 13:33:32 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Jan 2016 18:33:32 +0000
Subject: [issue25602] Add support for EVFILT_USER kqueue filter
In-Reply-To: <1447242368.46.0.687277732517.issue25602@psf.upfronthosting.co.za>
Message-ID: <1452796412.04.0.15740349155.issue25602@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +haypo
stage:  -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 13:36:39 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Jan 2016 18:36:39 +0000
Subject: [issue26038] zipfile cannot handle zip files where the archive size
 for a file does not match actual contents
In-Reply-To: <1452173383.07.0.105152287179.issue26038@psf.upfronthosting.co.za>
Message-ID: <1452796599.55.0.754701119673.issue26038@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +alanmcintyre, serhiy.storchaka, twouters
versions: +Python 3.5, Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 13:37:54 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 14 Jan 2016 18:37:54 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1452796674.63.0.0881505853766.issue26110@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I like this idea! I like the limitations to positional-only calls. I do think that it would be nice if we could speed up C calls too -- today, s.startswith('abc') is slower than s[:3] == 'abc' precisely because of the lookup. But I'm all for doing this one step at a time, so we can be sure it is solid before taking the next step(s).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 13:39:24 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Jan 2016 18:39:24 +0000
Subject: [issue25491] ftplib.sendcmd only accepts string
In-Reply-To: <1445956788.1.0.428769013447.issue25491@psf.upfronthosting.co.za>
Message-ID: <1452796764.12.0.160591419914.issue25491@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +giampaolo.rodola
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 13:41:41 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Jan 2016 18:41:41 +0000
Subject: [issue24945] Expose Py_TPFLAGS_ values from Python
In-Reply-To: <1440683454.06.0.831934129277.issue24945@psf.upfronthosting.co.za>
Message-ID: <1452796901.84.0.497948630055.issue24945@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +benjamin.peterson
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 13:43:07 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Jan 2016 18:43:07 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1452796987.86.0.146278327012.issue26110@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
nosy: +twouters

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 13:45:10 2016
From: report at bugs.python.org (Remy Roy)
Date: Thu, 14 Jan 2016 18:45:10 +0000
Subject: [issue26111] On Windows,
 os.scandir will keep a handle on the directory until the iterator is
 exhausted
Message-ID: <1452797110.0.0.310492336724.issue26111@psf.upfronthosting.co.za>


New submission from Remy Roy:

On Windows, os.scandir will keep a handle on the directory being scanned until the iterator is exhausted. This behavior can cause various problems if try to use some filesystem calls like os.chmod or os.remove on the directory while the handle is still being kept.

There are some use cases where the iterator is not going to be exhausted like looking for a specific entry in a directory and breaking from the loop prematurely.

This behavior should at least be documented.  Alternatively, it might be interesting to provide a way prematurely end the scan without having to exhaust it and close the handle.

As a workaround, you can force the exhaustion after you are done with the iterator with something like:

for entry in iterator:
    pass

This is going to affect os.walk as well since it uses os.scandir .

The original github issue can be found on https://github.com/benhoyt/scandir/issues/58 .

----------
components: Windows
messages: 258212
nosy: paul.moore, remyroy, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: On Windows, os.scandir will keep a handle on the directory until the iterator is exhausted
type: behavior
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 13:45:17 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Jan 2016 18:45:17 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1452797117.02.0.239350234641.issue26110@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
nosy: +dino.viehland

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 13:51:44 2016
From: report at bugs.python.org (Ben Hoyt)
Date: Thu, 14 Jan 2016 18:51:44 +0000
Subject: [issue26111] On Windows,
 os.scandir will keep a handle on the directory until the iterator is
 exhausted
In-Reply-To: <1452797110.0.0.310492336724.issue26111@psf.upfronthosting.co.za>
Message-ID: <1452797504.86.0.670724641017.issue26111@psf.upfronthosting.co.za>


Changes by Ben Hoyt :


----------
nosy: +benhoyt

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 14:26:18 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Jan 2016 19:26:18 +0000
Subject: [issue25753] Reference leaks in test_smtplib
In-Reply-To: <1448660464.47.0.968238224363.issue25753@psf.upfronthosting.co.za>
Message-ID: <1452799578.01.0.0646541625904.issue25753@psf.upfronthosting.co.za>


SilentGhost added the comment:

Serhiy, I cannot reproduce these leaks on recent checkout. Is this something that's still happens for you?

----------
nosy: +SilentGhost

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 14:29:52 2016
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Thu, 14 Jan 2016 19:29:52 +0000
Subject: [issue26112] Error on example using "dialect" parameter. have to be:
 "dialect=dialect"
Message-ID: <1452799792.3.0.65685555924.issue26112@psf.upfronthosting.co.za>


New submission from ?????? ?????????:

with open('example.csv') as csvfile:
    dialect = csv.Sniffer().sniff(csvfile.read(1024))
    csvfile.seek(0)
    reader = csv.reader(csvfile, dialect)
    # ... process CSV file contents here ...
--

have to be:
    ...
    reader = csv.reader(csvfile, dialect=dialect)
     # ... process CSV file contents here ...

It's here:
https://docs.python.org/3.4/library/csv.html

----------
assignee: docs at python
components: Documentation
messages: 258214
nosy: docs at python, ?????? ?????????
priority: normal
severity: normal
status: open
title: Error on example using "dialect" parameter. have to be: "dialect=dialect"
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 14:34:16 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Jan 2016 19:34:16 +0000
Subject: [issue26112] Error on example using "dialect" parameter. have to be:
 "dialect=dialect"
In-Reply-To: <1452799792.3.0.65685555924.issue26112@psf.upfronthosting.co.za>
Message-ID: <1452800056.42.0.315379772531.issue26112@psf.upfronthosting.co.za>


SilentGhost added the comment:

No, the shown code works just fine.

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 15:13:00 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 14 Jan 2016 20:13:00 +0000
Subject: [issue25668] Deadlock in logging caused by a possible race condition
 with "format"
In-Reply-To: <1447942973.46.0.788007678714.issue25668@psf.upfronthosting.co.za>
Message-ID: <1452802380.73.0.568278465266.issue25668@psf.upfronthosting.co.za>


Changes by Yury Selivanov :


----------
nosy: +yselivanov

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 15:16:18 2016
From: report at bugs.python.org (JitterMan)
Date: Thu, 14 Jan 2016 20:16:18 +0000
Subject: [issue26113] pathlib p.match('') should return False rather than
 raising exception
Message-ID: <1452802578.55.0.628676824088.issue26113@psf.upfronthosting.co.za>


New submission from JitterMan:

One can use '*' as an 'accept all' pattern to match(). It would be nice to also use '' as a 'reject all' pattern. These 'accept all' and 'reject all' rules are useful as defaults. Currently passing '' to match() causes an exception. While it is easy enough to catch the exception, the need to constrains the way match() must be called and makes the calling code needlessly complicated and fussy.

----------
files: example.py
messages: 258216
nosy: jitterman
priority: normal
severity: normal
status: open
title: pathlib p.match('') should return False rather than raising exception
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file41615/example.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 15:19:04 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Jan 2016 20:19:04 +0000
Subject: [issue26113] pathlib p.match('') should return False rather than
 raising exception
In-Reply-To: <1452802578.55.0.628676824088.issue26113@psf.upfronthosting.co.za>
Message-ID: <1452802744.8.0.219211856538.issue26113@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
components: +Library (Lib)
nosy: +gvanrossum, pitrou
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 15:24:25 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 14 Jan 2016 20:24:25 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>
Message-ID: <1452803065.62.0.344437153686.issue26058@psf.upfronthosting.co.za>


Changes by Yury Selivanov :


----------
nosy: +yselivanov

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 15:34:12 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 14 Jan 2016 20:34:12 +0000
Subject: [issue26113] pathlib p.match('') should return False rather than
 raising exception
In-Reply-To: <1452802578.55.0.628676824088.issue26113@psf.upfronthosting.co.za>
Message-ID: <1452803652.01.0.930977212942.issue26113@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

What's the use case for a "reject all" pattern? Why do you want to call glob with an argument that causes it do do a bunch of pointless work but then return an empty result set?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 15:35:41 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Jan 2016 20:35:41 +0000
Subject: [issue26114] Rewrite math.erf() and math.erfc() from scratch
Message-ID: <1452803741.39.0.631242355329.issue26114@psf.upfronthosting.co.za>


New submission from Brett Cannon:

If you look Modules/mathmodule.c you will notice there is a comment that goes with erf() and erfc() stating that the algorithms were taken from a book entitled 'Numerical Recipes'. Unfortunately that book has a license dictating that any information from the book is only allowed for non-commercial use; commercial use requires negotiating a license (http://numerical.recipes/aboutNR3license.html). That's bad for anyone who has a commercial distribution of Python as that's a special requirement they have to follow.

It would be best to do a clean room implementation of both math.erf() and math.erfc() that does not use information from 'Numerical Recipes' in order to not be violating that license. That way Python can be sold commercially without having to negotiate a separate license just for those two functions.

Unfortunately this code exists since at least Python 2.7, so I have flagged all Python releases as needing the eventual clean room implementation applied to it (although Python 3.2 goes out of security maintenance next month so I don't know how critical it is to fix that far back).

----------
components: Library (Lib)
messages: 258218
nosy: benjamin.peterson, brett.cannon, eric.smith, georg.brandl, larry, lemburg, mark.dickinson, stutzbach
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Rewrite math.erf() and math.erfc() from scratch
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 15:38:01 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Jan 2016 20:38:01 +0000
Subject: [issue26114] Rewrite math.erf() and math.erfc() from scratch
In-Reply-To: <1452803741.39.0.631242355329.issue26114@psf.upfronthosting.co.za>
Message-ID: <1452803881.61.0.300290375927.issue26114@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
nosy: +peter, teoliphant

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 15:38:20 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Jan 2016 20:38:20 +0000
Subject: [issue26114] Rewrite math.erf() and math.erfc() from scratch
In-Reply-To: <1452803741.39.0.631242355329.issue26114@psf.upfronthosting.co.za>
Message-ID: <1452803900.73.0.811503138117.issue26114@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
nosy:  -peter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 15:50:33 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 14 Jan 2016 20:50:33 +0000
Subject: [issue26111] On Windows,
 os.scandir will keep a handle on the directory until the iterator is
 exhausted
In-Reply-To: <1452797110.0.0.310492336724.issue26111@psf.upfronthosting.co.za>
Message-ID: <1452804633.03.0.680626508955.issue26111@psf.upfronthosting.co.za>


Eryk Sun added the comment:

If you own the only reference you can also delete the reference, which deallocates the iterator and closes the handle.

Can you provide concrete examples where os.remove and os.chmod fail? At least in Windows 7 and 10 the directory handle is opened with the normal read and write sharing, but also with delete sharing. This sharing mode is fairly close to POSIX behavior (an important distinction is noted below). I get the following results in Windows 10:

    >>> import os, stat
    >>> os.mkdir('test')
    >>> f = open('test/file1', 'w'); f.close()
    >>> f = open('test/file2', 'w'); f.close()
    >>> it = os.scandir('test')
    >>> next(it)
    

rename, chmod, and rmdir operations succeed:

    >>> os.rename('test', 'spam')
    >>> os.chmod('spam', stat.S_IREAD)
    >>> os.chmod('spam', stat.S_IWRITE)
    >>> os.remove('spam/file1')
    >>> os.remove('spam/file2')
    >>> os.rmdir('spam')

Apparently cached entries can be an issue, but this caching is up to WinAPI FindNextFile and the system call NtQueryDirectoryFile:

    >>> next(it)
    

An important distinction is that a deleted file in Windows doesn't actually get unlinked until all handles and kernel pointer references are closed. Also, once the delete disposition is set, no *new* handles can be created for the existing file or directory (all access is denied), and a new file or directory with same name cannot be created.

    >>> os.listdir('spam')
    Traceback (most recent call last):
      File "", line 1, in 
    PermissionError: [WinError 5] Access is denied: 'spam'

    >>> f = open('spam', 'w')
    Traceback (most recent call last):
      File "", line 1, in 
    PermissionError: [Errno 13] Permission denied: 'spam'

If we had another handle we could use that to rename "spam" to get it out of the way, at least. Without that, AFAIK, all we can do is deallocate the iterator or wait for it to be exhausted, which closes the handle and thus allows Windows to finally unlink "spam":

    >>> next(it)
    Traceback (most recent call last):
      File "", line 1, in 
    StopIteration

Creating a new file named "spam" is allowed now:

    >>> f = open('spam', 'w')
    >>> f.close()

----------
nosy: +eryksun

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 15:57:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2016 20:57:33 +0000
Subject: [issue26114] Rewrite math.erf() and math.erfc() from scratch
In-Reply-To: <1452803741.39.0.631242355329.issue26114@psf.upfronthosting.co.za>
Message-ID: <1452805053.57.0.546402425629.issue26114@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 16:12:39 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 14 Jan 2016 21:12:39 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1452805959.47.0.122048008582.issue26110@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> I like this idea! I like the limitations to positional-only calls. I do think that it would be nice if we could speed up C calls too -- today, s.startswith('abc') is slower than s[:3] == 'abc' precisely because of the lookup. But I'm all for doing this one step at a time, so we can be sure it is solid before taking the next step(s).

Yes, I think we can make `.method(..)` calls much faster with LOAD_METHOD.  Since those types lack `__dict__` and their `__class__` is read-only, we can use a far better optimized code path without extra lookups and creation of BoundMethod/PyCFunction objects.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 16:16:05 2016
From: report at bugs.python.org (JitterMan)
Date: Thu, 14 Jan 2016 21:16:05 +0000
Subject: [issue26096] '*' glob string matches dot files in pathlib
In-Reply-To: <1452651473.17.0.586447787765.issue26096@psf.upfronthosting.co.za>
Message-ID: <1452806165.47.0.10397845973.issue26096@psf.upfronthosting.co.za>


JitterMan added the comment:

The same issues applies with '**', where it is harder to work around. The shell version of '**' prunes out hidden files and directories at all levels, whereas the pathlib.glob() includes all hidden directories.

Major surgery would be required to filter out hidden files and directories from the output of pathlib.glob(), which would be expensive and complicated. Perhaps an option is called for that would allow pathlib.glob() to prune its search to only non-hidden directories if requested. And if that seems like a good idea, perhaps there could also be options that specify that only files or only directories should be returned.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 16:16:21 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2016 21:16:21 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1452806181.45.0.364290170007.issue26110@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm happy to see people working on optimizing CPython ;-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 16:20:32 2016
From: report at bugs.python.org (JitterMan)
Date: Thu, 14 Jan 2016 21:20:32 +0000
Subject: [issue26115] pathlib.glob('**') returns only directories
Message-ID: <1452806432.12.0.827592335617.issue26115@psf.upfronthosting.co.za>


New submission from JitterMan:

The title says it all.

The shell version of '*' and '**' return both directories and files.
Path('.').glob('*') returns both directories and files, but Path('.').glob('**') returns only directories. That seems wrong to me.

----------
messages: 258223
nosy: jitterman
priority: normal
severity: normal
status: open
title: pathlib.glob('**') returns only directories
type: behavior
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 16:22:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Jan 2016 21:22:10 +0000
Subject: [issue25753] Reference leaks in test_smtplib
In-Reply-To: <1448660464.47.0.968238224363.issue25753@psf.upfronthosting.co.za>
Message-ID: <1452806530.16.0.254512651788.issue25753@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The result of searching leaks is not stable. I ran the test 10 times and got failures 3 times.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 16:35:09 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 14 Jan 2016 21:35:09 +0000
Subject: [issue26111] On Windows,
 os.scandir will keep a handle on the directory until the iterator is
 exhausted
In-Reply-To: <1452797110.0.0.310492336724.issue26111@psf.upfronthosting.co.za>
Message-ID: <1452807309.67.0.259691217819.issue26111@psf.upfronthosting.co.za>


Martin Panter added the comment:

Remy, is this the same problem described in Issue 25994? There a close() method (like on generators) and/or context manager support is proposed for the scandir() iterator. Perhaps we can keep this issue open for adding a warning to the documentation, and the other issue can be for improving the API in 3.6.

----------
assignee:  -> docs at python
components: +Documentation
dependencies: +File descriptor leaks in os.scandir()
nosy: +docs at python, martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 16:46:39 2016
From: report at bugs.python.org (Remy Roy)
Date: Thu, 14 Jan 2016 21:46:39 +0000
Subject: [issue26111] On Windows,
 os.scandir will keep a handle on the directory until the iterator is
 exhausted
In-Reply-To: <1452797110.0.0.310492336724.issue26111@psf.upfronthosting.co.za>
Message-ID: <1452807999.16.0.763152178857.issue26111@psf.upfronthosting.co.za>


Remy Roy added the comment:

I believe Eryk's explanation on how a file in Windows doesn't actually get unlinked until all handles and kernel pointer references are closed is spot on about the problem I had.

I had a complex example that could probably have been simplified to what Eryk posted.

That behavior on Windows is quite counterintuitive. I'm not sure about what can be done to help it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 16:50:32 2016
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Thu, 14 Jan 2016 21:50:32 +0000
Subject: [issue26116] CSV-module. The example code don't work. Have to be:
 reader = csv.reader(csvfile, dialect=dialect)
Message-ID: <1452808232.54.0.345665768771.issue26116@psf.upfronthosting.co.za>


New submission from ?????? ?????????:

with open('example.csv') as csvfile:
    dialect = csv.Sniffer().sniff(csvfile.read(1024))
    csvfile.seek(0)
    reader = csv.reader(csvfile, dialect)
    # ... process CSV file contents here ...
--

have to be:
    ...
    reader = csv.reader(csvfile, dialect=dialect)
     # ... process CSV file contents here ...

It's here:
https://docs.python.org/3.4/library/csv.html

----------
assignee: docs at python
components: Documentation
messages: 258227
nosy: Vasyl Kolomiets, docs at python
priority: normal
severity: normal
status: open
title: CSV-module. The example code don't work.    Have to be: reader = csv.reader(csvfile, dialect=dialect)
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 16:54:30 2016
From: report at bugs.python.org (Remy Roy)
Date: Thu, 14 Jan 2016 21:54:30 +0000
Subject: [issue26111] On Windows,
 os.scandir will keep a handle on the directory until the iterator is
 exhausted
In-Reply-To: <1452797110.0.0.310492336724.issue26111@psf.upfronthosting.co.za>
Message-ID: <1452808470.22.0.542554465177.issue26111@psf.upfronthosting.co.za>


Remy Roy added the comment:

This issue is not same as Issue 25994 but it is quite related. Some kind of close() method and/or context manager support could help here as well.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 16:54:33 2016
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Thu, 14 Jan 2016 21:54:33 +0000
Subject: [issue26116] CSV-module. The example code don't work. Have to be:
 reader = csv.reader(csvfile, dialect=dialect)
In-Reply-To: <1452808232.54.0.345665768771.issue26116@psf.upfronthosting.co.za>
Message-ID: <1452808473.64.0.980121841696.issue26116@psf.upfronthosting.co.za>


?????? ????????? added the comment:

Traceback (most recent call last):
  File "F:\Program Files (x86)\Pyton3_4\=Py\NovaPoshta\View#1-check-Trojan.py", line 11, in 
    for row in readed:
  File "F:\Program Files (x86)\Pyton3_4\lib\csv.py", line 118, in __next__
    d = dict(zip(self.fieldnames, row))
TypeError: zip argument #1 must support iteration

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 16:55:11 2016
From: report at bugs.python.org (Chris Angelico)
Date: Thu, 14 Jan 2016 21:55:11 +0000
Subject: [issue18018] SystemError: Parent module '' not loaded,
 cannot perform relative import
In-Reply-To: <1369011708.43.0.213176616662.issue18018@psf.upfronthosting.co.za>
Message-ID: <1452808511.84.0.919651604686.issue18018@psf.upfronthosting.co.za>


Chris Angelico added the comment:

This still happens in current CPython, and doesn't even require a package:

rosuav at sikorsky:~$ echo 'from . import x' >syserr.py
rosuav at sikorsky:~$ python3 syserr.py
Traceback (most recent call last):
  File "syserr.py", line 1, in 
    from . import x
SystemError: Parent module '' not loaded, cannot perform relative import


This just caused some confusion for a student of mine who had migrated from Python 2. Converting intra-package imports from "import spam" to "from . import spam" made them work; converting a non-package import the same way caused this problem. ImportError would be massively preferable.

But I'm not understanding something here. If I set __package__ inside the module, the behaviour changes accordingly:

rosuav at sikorsky:~$ cat syserr.py 
__package__ = 'sys'
from . import version
print(version)
rosuav at sikorsky:~$ python3 syserr.py 
3.6.0a0 (default:ac94418299bd+, Jan 15 2016, 08:44:02) 
[GCC 4.9.2]


Leaving __package__ unset has it implicitly be None. Whether it's None or '', the package checks should simply not be made - see three lines above the line Brett linked to (in today's code, that's https://hg.python.org/cpython/file/ac94418299b/Lib/importlib/_bootstrap.py#l925 - hasn't changed). So I'm not sure why the checks are even happening. However, that probably means more about my exploration and testing than it does about the code; editing the text of the message doesn't result in a change, so I'm obviously not updating the frozen version.

----------
nosy: +Rosuav
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:01:00 2016
From: report at bugs.python.org (Chris Angelico)
Date: Thu, 14 Jan 2016 22:01:00 +0000
Subject: [issue24752] SystemError when importing from a non-package directory
In-Reply-To: <1438238767.05.0.118820684187.issue24752@psf.upfronthosting.co.za>
Message-ID: <1452808860.26.0.487459226794.issue24752@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Linking this issue with #18018 - same problem, same situation.

----------
nosy: +Rosuav

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:05:30 2016
From: report at bugs.python.org (Wil D'Amato)
Date: Thu, 14 Jan 2016 22:05:30 +0000
Subject: [issue18018] SystemError: Parent module '' not loaded,
 cannot perform relative import
In-Reply-To: <1369011708.43.0.213176616662.issue18018@psf.upfronthosting.co.za>
Message-ID: <1452809130.1.0.315135276461.issue18018@psf.upfronthosting.co.za>


Changes by Wil D'Amato :


----------
nosy: +auslander1970

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:10:00 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Jan 2016 22:10:00 +0000
Subject: [issue24752] SystemError when importing from a non-package directory
In-Reply-To: <1438238767.05.0.118820684187.issue24752@psf.upfronthosting.co.za>
Message-ID: <1452809400.98.0.795670929257.issue24752@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
superseder:  -> SystemError: Parent module '' not loaded, cannot perform relative import

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:10:15 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Jan 2016 22:10:15 +0000
Subject: [issue24752] SystemError when importing from a non-package directory
In-Reply-To: <1438238767.05.0.118820684187.issue24752@psf.upfronthosting.co.za>
Message-ID: <1452809415.68.0.920716191845.issue24752@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:10:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Jan 2016 22:10:22 +0000
Subject: [issue26117] Close directory descriptor in scandir iterator on error
Message-ID: <1452809422.76.0.117373240485.issue26117@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Since scandir iterator has no close method, the most safe way to avoid file descriptors leaks when use os.scandir() is accumulating yielded results into a list before processing them:

    entries = list(os.scandir(path))

But this doesn't save us from all leaks. If an error happened during yielding next entry, opened file descriptor left open.

Proposed patch makes scandir to close the file descriptor not only when an iteration is exhausted, but when any error (expected OSError or MemoryError) is raised.

This is needed to fix possible leaks in os.walk() in 3.5 (see also issue25995).

----------
components: Extension Modules
files: scandir_closedir_on_error.patch
keywords: patch
messages: 258232
nosy: benhoyt, gvanrossum, haypo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Close directory descriptor in scandir iterator on error
type: resource usage
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41616/scandir_closedir_on_error.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:11:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Jan 2016 22:11:40 +0000
Subject: [issue26111] On Windows,
 os.scandir will keep a handle on the directory until the iterator is
 exhausted
In-Reply-To: <1452797110.0.0.310492336724.issue26111@psf.upfronthosting.co.za>
Message-ID: <1452809500.74.0.24476963718.issue26111@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:12:57 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Jan 2016 22:12:57 +0000
Subject: [issue18018] SystemError: Parent module '' not loaded,
 cannot perform relative import
In-Reply-To: <1369011708.43.0.213176616662.issue18018@psf.upfronthosting.co.za>
Message-ID: <1452809577.39.0.572712393413.issue18018@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
assignee: flox -> brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:14:16 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 14 Jan 2016 22:14:16 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1452809656.09.0.116484964328.issue25994@psf.upfronthosting.co.za>


Martin Panter added the comment:

I definitely support adding a close() method, and a ResourceWarning if the iterator is not exhausted when it is deallocated. Adding context manager support is probably worthwhile as well, though there is one disadvantage: it would be hard to implement scandir() as a plain generator, because generators don?t support the context manager protocol. But C Python?s implementation is in C, and even in native Python you could implement it as a custom iterator class.

I suggest using this issue for adding the new API(s), presumably to 3.6 only, and Issue 26111 for adding a warning to the existing 3.5 documentation.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:18:30 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Jan 2016 22:18:30 +0000
Subject: [issue26116] CSV-module. The example code don't work. Have to be:
 reader = csv.reader(csvfile, dialect=dialect)
In-Reply-To: <1452808232.54.0.345665768771.issue26116@psf.upfronthosting.co.za>
Message-ID: <1452809910.32.0.279646626793.issue26116@psf.upfronthosting.co.za>


SilentGhost added the comment:

Vasyl, this line in your code is causing the problem:

    for row in readed:

The error reasonably clear states that it's due to your `fieldnames' parameter being non-iterable. Again, this has nothing whatsoever to do with `dialect' argument and documentation of Sniffer. 

Please, do not open new issues about this. This is not a issue with csv library or its documentation. Try to use use stackoverflow or python-tutor list to get help on this.
https://mail.python.org/pipermail/tutor/

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:22:09 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 14 Jan 2016 22:22:09 +0000
Subject: [issue26111] On Windows,
 os.scandir will keep a handle on the directory until the iterator is
 exhausted
In-Reply-To: <1452797110.0.0.310492336724.issue26111@psf.upfronthosting.co.za>
Message-ID: <1452810129.47.0.352333548735.issue26111@psf.upfronthosting.co.za>


Martin Panter added the comment:

Can you explain how it is different? The way I see it, both problems are about the scandir() iterator holding an open reference (file descriptor or handle) to a directory/folder, when the iterator was not exhausted, but the caller no longer needs it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:24:53 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 14 Jan 2016 22:24:53 +0000
Subject: [issue26111] On Windows,
 os.scandir will keep a handle on the directory until the iterator is
 exhausted
In-Reply-To: <1452797110.0.0.310492336724.issue26111@psf.upfronthosting.co.za>
Message-ID: <1452810293.01.0.140228530702.issue26111@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> That behavior on Windows is quite counterintuitive.

It's counter-intuitive from a POSIX point of view, in which anonymous files are allowed. In contrast, Windows allows any existing reference to unset the delete disposition, so the name cannot be unlinked until all references are closed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:26:27 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Jan 2016 22:26:27 +0000
Subject: [issue26115] pathlib.glob('**') returns only directories
In-Reply-To: <1452806432.12.0.827592335617.issue26115@psf.upfronthosting.co.za>
Message-ID: <1452810387.62.0.266085950228.issue26115@psf.upfronthosting.co.za>


SilentGhost added the comment:

It is, however, exactly what documentation says it should do:

> The ?**? pattern means ?this directory and all subdirectories, recursively?.

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:26:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Jan 2016 22:26:51 +0000
Subject: [issue25995] os.walk() consumes a lot of file descriptors
In-Reply-To: <1451757425.39.0.0524932176307.issue25995@psf.upfronthosting.co.za>
Message-ID: <1452810411.67.0.49151511301.issue25995@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, OSError, MemoryError and KeyboardInterrupt can be raised during iterating scandir object or calling is_dir() or is_symlink() methods of the result. They stop iterating and left file descriptor open. If close file descriptor on error during iteration (issue26117), patch 1 becomes more safe, because it minimizes the lifetime of opened descriptor.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:28:36 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Jan 2016 22:28:36 +0000
Subject: [issue26102] access violation in PyErrFetch if tcur==null in
 PyGILState_Release
In-Reply-To: <1452714471.66.0.669763876009.issue26102@psf.upfronthosting.co.za>
Message-ID: <1452810516.33.0.654967891009.issue26102@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:34:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Jan 2016 22:34:59 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1452810899.49.0.721343351307.issue25994@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If scandir() is implemented as native Python generator (see for example issue25911), it could easily be converted to context manager:

def scandir(path):
    return contextlib.closing(native_scandir(path))

def native_scandir(path):
    ...
    yield ...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:36:24 2016
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Thu, 14 Jan 2016 22:36:24 +0000
Subject: [issue26116] CSV-module. The example code don't work. Have to be:
 reader = csv.reader(csvfile, dialect=dialect)
In-Reply-To: <1452809910.32.0.279646626793.issue26116@psf.upfronthosting.co.za>
Message-ID: 


?????? ????????? added the comment:

Thanx a lot.
And sorry.
But with ..., dialect=dialect, .... the same code is working.
.
Ok. i'll try to understand.
With best wishes - VK.

? ?????????,
??????? ????????
+38050 45 22 559

2016-01-15 0:18 GMT+02:00 SilentGhost :

>
> SilentGhost added the comment:
>
> Vasyl, this line in your code is causing the problem:
>
>     for row in readed:
>
> The error reasonably clear states that it's due to your `fieldnames'
> parameter being non-iterable. Again, this has nothing whatsoever to do with
> `dialect' argument and documentation of Sniffer.
>
> Please, do not open new issues about this. This is not a issue with csv
> library or its documentation. Try to use use stackoverflow or python-tutor
> list to get help on this.
> https://mail.python.org/pipermail/tutor/
>
> ----------
> nosy: +SilentGhost
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------
title: CSV-module. The example code don't work.    Have to be: reader = csv.reader(csvfile, dialect=dialect) -> CSV-module. The example code don't work. Have to be: reader = csv.reader(csvfile, dialect=dialect)

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:38:04 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 14 Jan 2016 22:38:04 +0000
Subject: [issue26116] CSV-module. The example code don't work. Have to be:
 reader = csv.reader(csvfile, dialect=dialect)
In-Reply-To: <1452808232.54.0.345665768771.issue26116@psf.upfronthosting.co.za>
Message-ID: <1452811084.35.0.302467945014.issue26116@psf.upfronthosting.co.za>


Georg Brandl added the comment:

We'll need at least the two full examples (one not working, one working) to make a call here.

----------
nosy: +georg.brandl

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:39:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Jan 2016 22:39:37 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1452811177.86.0.346300496428.issue25994@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Since the close() method can be added only in 3.6, but we have leaks in 3.5 too, I suggest to closed file descriptor if error happened during iteration (issue26117). This will allow to write safe code even in 3.5.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:47:44 2016
From: report at bugs.python.org (poostenr)
Date: Thu, 14 Jan 2016 22:47:44 +0000
Subject: [issue26118] String performance issue using single quotes
Message-ID: <1452811664.45.0.761474192648.issue26118@psf.upfronthosting.co.za>


New submission from poostenr:

There appears to be a significant performance issue between the following two statements. Unable to explain performance impact.

s = "{0},".format(columnvalue)   # fast
s = "'{0}',".format(columnvalue) # ~30x slower

So far, no luck trying to find other statements to improve performance, such as:
s = "\'{0}\',".format(columnvalue)
s = "'" + "%s" %(columnvalue) + "'"+","
s = "{0}{1}{2},".format("'",columnvalue,"'")

----------
components: Windows
messages: 258243
nosy: paul.moore, poostenr, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: String performance issue using single quotes
type: performance
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:49:22 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 14 Jan 2016 22:49:22 +0000
Subject: [issue25994] File descriptor leaks in os.scandir()
In-Reply-To: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>
Message-ID: <1452811762.96.0.813033749502.issue25994@psf.upfronthosting.co.za>


Martin Panter added the comment:

Contextlib.closing() cannot be used in general, because it doesn?t inherit the iterator protocol from the wrapped generator. So I think you really need a class that implements __exit__(), __iter__(), etc at the same time.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:49:31 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Jan 2016 22:49:31 +0000
Subject: [issue24950] FAIL: test_expanduser when $HOME=/
In-Reply-To: <1440732506.26.0.0296213798936.issue24950@psf.upfronthosting.co.za>
Message-ID: <1452811771.65.0.224045685107.issue24950@psf.upfronthosting.co.za>


SilentGhost added the comment:

For posixpath the fix is straightforward: just skip that assert if the home ends up being '/' (the '/' is tested above).

For pathlib, I'm not entirely sure what the fix should be.

----------
nosy: +SilentGhost, pitrou
versions: +Python 3.6 -Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:50:40 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 14 Jan 2016 22:50:40 +0000
Subject: [issue26096] '*' glob string matches dot files in pathlib
In-Reply-To: <1452651473.17.0.586447787765.issue26096@psf.upfronthosting.co.za>
Message-ID: <1452811840.02.0.602168786745.issue26096@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

If you have that use case you're probably better of using os.walk() so you are not limited to a prune strategy that can be expressed using a single glob pattern (e.g. maybe I want to ignore .git, .hg and __pycache__ but descend into everything else).

I think we would also welcome adding a walk() method to pathlib. But let's please leave glob() alone.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:56:23 2016
From: report at bugs.python.org (ubehera)
Date: Thu, 14 Jan 2016 22:56:23 +0000
Subject: [issue26118] String performance issue using single quotes
In-Reply-To: <1452811664.45.0.761474192648.issue26118@psf.upfronthosting.co.za>
Message-ID: <1452812183.92.0.97944117535.issue26118@psf.upfronthosting.co.za>


Changes by ubehera :


----------
nosy: +ubehera

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:58:23 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 14 Jan 2016 22:58:23 +0000
Subject: [issue26118] String performance issue using single quotes
In-Reply-To: <1452811664.45.0.761474192648.issue26118@psf.upfronthosting.co.za>
Message-ID: <1452812303.73.0.719621084015.issue26118@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Please show us how you're measuring the performance. Also, please show the output of "python -V".

----------
components: +Interpreter Core -Windows
nosy: +eric.smith -paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 18:01:15 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Jan 2016 23:01:15 +0000
Subject: [issue25682] __package__ not set to None under pdb in Python 3
In-Reply-To: <1448035339.32.0.969832659097.issue25682@psf.upfronthosting.co.za>
Message-ID: <1452812475.57.0.26540667014.issue25682@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +brett.cannon, eric.snow, ncoghlan

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 18:13:07 2016
From: report at bugs.python.org (Remy Roy)
Date: Thu, 14 Jan 2016 23:13:07 +0000
Subject: [issue26111] On Windows,
 os.scandir will keep a handle on the directory until the iterator is
 exhausted
In-Reply-To: <1452797110.0.0.310492336724.issue26111@psf.upfronthosting.co.za>
Message-ID: <1452813187.11.0.34527379907.issue26111@psf.upfronthosting.co.za>


Remy Roy added the comment:

>From my point of view, Issue 25994 is about the potential file descriptor/handle leaks and this issue is about being unable to perform some filesystem calls because of a hidden unclosed file descriptor/handle.

I am not going to protest if you want to treat them as the same issue.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 18:20:31 2016
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Thu, 14 Jan 2016 23:20:31 +0000
Subject: [issue26116] CSV-module. The example code don't work. Have to be:
 reader = csv.reader(csvfile, dialect=dialect)
In-Reply-To: <1452811084.35.0.302467945014.issue26116@psf.upfronthosting.co.za>
Message-ID: 


?????? ????????? added the comment:

I am very happy!
Thx for attention to my opinion.
Sorry for my english.

so - in attachment two codes and source csv-file.

With best wishes,
Vasyl Kolomiets.
+38050 45 22 559

2016-01-15 0:38 GMT+02:00 Georg Brandl :

>
> Georg Brandl added the comment:
>
> We'll need at least the two full examples (one not working, one working)
> to make a call here.
>
> ----------
> nosy: +georg.brandl
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------
Added file: http://bugs.python.org/file41617/may_be-error_csv_exmpl.py
Added file: http://bugs.python.org/file41618/from_to_proportions.csv
Added file: http://bugs.python.org/file41619/may_be-good_csv_exmpl.py

_______________________________________
Python tracker 

_______________________________________
-------------- next part --------------
from tkinter import *
from PIL import Image
import csv

filename = "from_to_proportions.csv"
with open(filename) as csvfile:
    dialect=csv.Sniffer().sniff(csvfile.read(1024))
    csvfile.seek(0)
    print(dialect)
    readed = csv.DictReader(csvfile, dialect)
    for row in readed:
        print(row)
        print (row["from_id"],row["from_name"],row['to_id'],row['to_name'],
               row['barcodes_percentage'],row['rows_to_be'])
        
-------------- next part --------------
A non-text attachment was scrubbed...
Name: from_to_proportions.csv
Type: text/csv
Size: 764 bytes
Desc: not available
URL: 
-------------- next part --------------
from tkinter import *
from PIL import Image
import csv

filename = "from_to_proportions.csv"
with open(filename) as csvfile:
    dialect=csv.Sniffer().sniff(csvfile.read(1024))
    csvfile.seek(0)
    print(dialect)
    readed = csv.DictReader(csvfile, dialect=dialect)
    for row in readed:
        print(row)
        print (row["from_id"],row["from_name"],row['to_id'],row['to_name'],
               row['barcodes_percentage'],row['rows_to_be'])
        

From report at bugs.python.org  Thu Jan 14 18:55:04 2016
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Thu, 14 Jan 2016 23:55:04 +0000
Subject: [issue26116] CSV-module. The example code don't work. Have to be:
 reader = csv.reader(csvfile, dialect=dialect)
In-Reply-To: <1452808232.54.0.345665768771.issue26116@psf.upfronthosting.co.za>
Message-ID: <1452815704.51.0.587915414674.issue26116@psf.upfronthosting.co.za>


Changes by ?????? ????????? :


Added file: http://bugs.python.org/file41620/CSV-ex.png

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 18:55:40 2016
From: report at bugs.python.org (poostenr)
Date: Thu, 14 Jan 2016 23:55:40 +0000
Subject: [issue26118] String performance issue using single quotes
In-Reply-To: <1452811664.45.0.761474192648.issue26118@psf.upfronthosting.co.za>
Message-ID: <1452815740.73.0.365081021544.issue26118@psf.upfronthosting.co.za>


poostenr added the comment:

My initial observations with my Python script using:

s = "{0},".format(columnvalue)   # fast
Processed ~360MB of data from 2:16PM - 2:51PM (35 minutes, ~10MB/min)
One particular file 6.5MB took ~1 minute.

When I changed this line of code to:
s = "'{0}',".format(columnvalue) # ~30x slower (1 min. vs 30 min.)
Same particular file of 6.5MB took ~30 minutes (228KB/min).

My Python environment is:
C:\Data>python -V
Python 3.5.1 :: Anaconda 2.4.1 (32-bit)

I did some more testing with a very simplified piece of code, but is not conclusive. But there is a significant jump when I introduce the single quotes where I see a jump from 0m2.410s to 0m3.875s.

$ python -V
Python 3.5.1

// 
// s='test'
// for x in range(10000000):
//     y = "{0}".format(s)

$ time python test.py

real	0m2.410s
user	0m2.356s
sys	0m0.048s

// s='test'
// for x in range(10000000):
//     y = "'%s'" % (s)

$ time python test2.py 

real	0m2.510s
user	0m2.453s
sys	0m0.051s

// s='test'
// for x in range(10000000):
//     y = "'{0}'".format(s)

$ time python test3.py 

real	0m3.875s
user	0m3.819s
sys	0m0.048s

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 19:05:39 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 15 Jan 2016 00:05:39 +0000
Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL
 certificate
In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za>
Message-ID: <1452816339.0.0.920575644049.issue25940@psf.upfronthosting.co.za>


Martin Panter added the comment:

In the 3.3 branch, I got a failure in test_ssl.ThreadedTests.test_dh_params(): ?SSLError: [SSL] dh key too small (_ssl.c:548)?. But the failure also happens in the revision before my merge, so I think it must be a separate problem.

Also, I am seeing Windows 7+ buildbots are failing the new version of test_connect_ex_error(). On Linux, connecting to self-signed.pythontest.net:444 gives EHOSTUNREACH, but it seems we get ETIMEDOUT on Windows:

AssertionError: 10060 not found in (10061, 10065, 10035)

I will update the test to check for that error code as well, since all it really needs to test is that _some_ sensible error code is returned.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 19:11:07 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jan 2016 00:11:07 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <1452816667.95.0.533579787179.issue23606@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Does it mean `cdll.msvcrt` is not the standard way to access the C symbols anymore? Could you update the docs to reflect the current guidelines?
(https://docs.python.org/3/library/ctypes.html)

----------
nosy: +pitrou

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 19:27:25 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 15 Jan 2016 00:27:25 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <1452817645.27.0.453229262068.issue23606@psf.upfronthosting.co.za>


Steve Dower added the comment:

Strictly there's nothing incorrect about the docs, and `cdll.msvcrt` is no more incorrect than it has been since Python 2.4 or so (whenever we  stopped using VC6). It will find the DLL and you can call the functions, but it isn't the same DLL as the exports in the `msvcrt` module will call.

Might be worth a note pointing this out, but it's probably better off with a different example. I'll try and think of something, but I'm fairly distracted at the moment and would appreciate suggestions. Otherwise I'll get there eventually.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 19:29:00 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 15 Jan 2016 00:29:00 +0000
Subject: [issue26118] String performance issue using single quotes
In-Reply-To: <1452811664.45.0.761474192648.issue26118@psf.upfronthosting.co.za>
Message-ID: <1452817740.24.0.00169044463301.issue26118@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I see a small difference, but I think it's related to the fact that in the first example you're concatenating 2 strings (',' and the result of {0}), and in the 2nd example it's 3 strings ("'", {0}, "',"):

$ echo '",{0}".format(x)'
",{0}".format(x)
$ python -m timeit -s 'x=4' '",{0}".format(x)'
1000000 loops, best of 3: 0.182 usec per loop

$ echo '"'\''{0}'\'',".format(x)'
"'{0}',".format(x)
$ python -m timeit -s 'x=4' '"'\''{0}'\'',".format(x)'
1000000 loops, best of 3: 0.205 usec per loop

If you see a factor of 30x difference in your code, I suspect it's not related to str.format(), but some other processing in your code.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 19:42:36 2016
From: report at bugs.python.org (JitterMan)
Date: Fri, 15 Jan 2016 00:42:36 +0000
Subject: [issue26113] pathlib p.match('') should return False rather than
 raising exception
In-Reply-To: <1452802578.55.0.628676824088.issue26113@psf.upfronthosting.co.za>
Message-ID: <1452818556.39.0.786674399512.issue26113@psf.upfronthosting.co.za>


JitterMan added the comment:

I don't know that passing '' as a pattern to glob() makes much sense, but it is useful when passed to match(). Doing so allows me to build a filter that can easily and naturally be disabled. For example, the following allows me to get all the items in a directory that both match a select pattern and do not match a reject pattern:

def ls(dir, select='*', reject='.*'):
    return (p for p in dir.glob(select) if not p.match(reject))

By default this function does not return hidden files or directories. It would seem like this restriction could be removed by passing reject='', but that generates an exception. Working around the exception makes the code noticeably more complicated.

Perhaps the question should really be 'what is the benefit of raising an exception when an empty glob string is encountered?'. I cannot think of any.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 19:56:51 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 15 Jan 2016 00:56:51 +0000
Subject: [issue26113] pathlib p.match('') should return False rather than
 raising exception
In-Reply-To: <1452802578.55.0.628676824088.issue26113@psf.upfronthosting.co.za>
Message-ID: <1452819411.79.0.161510573605.issue26113@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

A benefit is that it catches certain bugs early. It's not really worth a fight, so status quo wins.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 20:09:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Jan 2016 01:09:43 +0000
Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL
 certificate
In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za>
Message-ID: <20160115010940.18407.14615@psf.io>


Roundup Robot added the comment:

New changeset fb7131939508 by Martin Panter in branch '2.7':
Issue #25940: Use self-signed.pythontest.net in SSL tests
https://hg.python.org/cpython/rev/fb7131939508

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 20:40:52 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 15 Jan 2016 01:40:52 +0000
Subject: [issue26118] String performance issue using single quotes
In-Reply-To: <1452811664.45.0.761474192648.issue26118@psf.upfronthosting.co.za>
Message-ID: <1452822052.48.0.209817977246.issue26118@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

I cannot replicate that performance difference under Linux. There's a small difference (about 0.1 second per million iterations, or a tenth of a microsecond) on my computer, but I don't think that's meaningful:

    py> from timeit import Timer
    py> t1 = Timer('"{0},".format(999)')
    py> t2 = Timer('"\'{0}\',".format(999)')
    py> min(t1.repeat())
    4.671058462932706
    py> min(t2.repeat())
    4.774653751403093


Please re-run your tests using the timeit module, and see if you can still see a consistent difference with and without single quotes. Perhaps this is specific to Windows?

Otherwise, I can only suggest that the timing difference is unrelated to the difference in quotes in the script. Are you sure that this is absolutely the only change between the run that took one minute and the run that took 30 minutes? No other changes to the script, running on the same data file, on the same disk, no difference in what other processes are running? (E.g. if one run is fighting for disk access with, say, a memory-hungry anti-virus scan, that would easily explain the difference.)

----------
nosy: +steven.daprano

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 20:56:49 2016
From: report at bugs.python.org (Yongzhi Pan)
Date: Fri, 15 Jan 2016 01:56:49 +0000
Subject: [issue18018] SystemError: Parent module '' not loaded,
 cannot perform relative import
In-Reply-To: <1369011708.43.0.213176616662.issue18018@psf.upfronthosting.co.za>
Message-ID: <1452823009.08.0.210830658755.issue18018@psf.upfronthosting.co.za>


Changes by Yongzhi Pan :


----------
nosy: +fossilet

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 21:27:20 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Jan 2016 02:27:20 +0000
Subject: [issue18018] SystemError: Parent module '' not loaded,
 cannot perform relative import
In-Reply-To: <1369011708.43.0.213176616662.issue18018@psf.upfronthosting.co.za>
Message-ID: <1452824840.53.0.468364284808.issue18018@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The problem is in Python/import.c: https://hg.python.org/cpython/file/default/Python/import.c#l1453 . While the Python code has a check that `package` is a truthy value, the accelerated C code doesn't. Adding a check that the string isn't empty or truthy should do the trick as there seems to already be a check for None earlier.

The other question is whether this should change back to ValueError for Python 2 compatibility or turn into ImportError as Chris and Eric Snow have independently suggested?

Either way I'm only going to change this in Python 3.6 since the current semantics have been this way since Python 3.3, so it's beyond the realm of regression and into fixing a design mistake.

----------
stage:  -> test needed
versions:  -Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 21:46:50 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Jan 2016 02:46:50 +0000
Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL
 certificate
In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za>
Message-ID: <20160115024647.96348.10050@psf.io>


Roundup Robot added the comment:

New changeset b2036b717028 by Martin Panter in branch '3.2':
Issue #25940: On Windows, connecting to port 444 returns ETIMEDOUT
https://hg.python.org/cpython/rev/b2036b717028

New changeset c5cae7366835 by Martin Panter in branch '3.3':
Issue #25940: Merge ETIMEDOUT fix from 3.2 into 3.3
https://hg.python.org/cpython/rev/c5cae7366835

New changeset a806ed21bd82 by Martin Panter in branch '3.4':
Issue #25940: Merge ETIMEDOUT fix from 3.3 into 3.4
https://hg.python.org/cpython/rev/a806ed21bd82

New changeset bd9d5bc8bc95 by Martin Panter in branch '3.5':
Issue #25940: Merge ETIMEDOUT fix from 3.4 into 3.5
https://hg.python.org/cpython/rev/bd9d5bc8bc95

New changeset 32a4e7b337c9 by Martin Panter in branch 'default':
Issue #25940: Merge ETIMEDOUT fix from 3.5
https://hg.python.org/cpython/rev/32a4e7b337c9

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 21:53:25 2016
From: report at bugs.python.org (Chris Angelico)
Date: Fri, 15 Jan 2016 02:53:25 +0000
Subject: [issue18018] SystemError: Parent module '' not loaded,
 cannot perform relative import
In-Reply-To: <1369011708.43.0.213176616662.issue18018@psf.upfronthosting.co.za>
Message-ID: <1452826405.65.0.159687172335.issue18018@psf.upfronthosting.co.za>


Chris Angelico added the comment:

If someone made a new way of importing and had it raise ValueError on some issue or other, I think there'd be complete consensus that that's the wrong exception. Yes, this is incompatible with Python 2 - but there are a lot of corner cases in the 3.3+ import code that differ from 2.7. What we have is a code error ("relative imports outside of packages don't make sense, dummy!") and the only difference is which exception is being raised (ValueError, SystemError, ImportError). It's not like working code has different semantics.

But even if ValueError is chosen, I would still greatly prefer that to SystemError. When my student told me he was getting SystemError, I started trying to diagnose a corrupted venv, not a buggy script.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 22:29:53 2016
From: report at bugs.python.org (poostenr)
Date: Fri, 15 Jan 2016 03:29:53 +0000
Subject: [issue26118] String performance issue using single quotes
In-Reply-To: <1452811664.45.0.761474192648.issue26118@psf.upfronthosting.co.za>
Message-ID: <1452828593.65.0.0816975415113.issue26118@psf.upfronthosting.co.za>


poostenr added the comment:

Eric, Steven, thank you for your feedback so far.

I am using Windows7, Intel i7.
That one particular file of 6.5MB took ~1 minute on my machine.
When I ran that same test on Linux with Python 3.5.1, it took about 3 seconds. I was amazed to see a 20x difference.

Steven suggested the idea that this phenomenon might be specific to Windows. And I agree, that is what it is looking like. Or is Python doing something in the background?

The Python script is straight forward with a loop that reads a line from a CSV file, split the column values and saves each value as '' to another file. Basically building an SQL statement.
I have had no issues until I added the encapsulating single quotes around the value.

Because I can reproduce this performance difference at will by alternating which line I comment out, leads me to believe it cannot be HDD, AV or something outside the python script interfering.

I repeated the simplified test, that I ran earlier on a Linux system, but this time on my Windows system.
I don't see anything spectacular.
I am just puzzled that using one statement or the other causes such a huge performance impact somehow.

I will try some more tests and copy your examples.

import time
loopcount = 10000000

# Using string value
s="test 1"
v="test 1"
start_ms = int(round(time.time() * 1000))
for x in range (loopcount):
    y = "{0}".format(v)
end_ms = int(round(time.time() * 1000))
print("Start {0}: {1}".format(s,start_ms))
print("End   {0}: {1}".format(s,end_ms))
print("Diff  {0}: {1} ms\n\n".format(s,end_ms-start_ms))
# Start test 1: 1452828394523
# End   test 1: 1452828397957
# Diff  test 1: 3434 ms


s="test 2"
v="test 2"
start_ms = int(round(time.time() * 1000))
for x in range (loopcount):
    y = "'%s'" % (v)
end_ms = int(round(time.time() * 1000))
print("Start {0}: {1}".format(s,start_ms))
print("End   {0}: {1}".format(s,end_ms))
print("Diff  {0}: {1} ms\n\n".format(s,end_ms-start_ms))
# Start test 2: 1452828397957
# End   test 2: 1452828401233
# Diff  test 2: 3276 ms


s="test 3"
v="test 3"
start_ms = int(round(time.time() * 1000))
for x in range (loopcount):
    y = "'{0}'".format(v)
end_ms = int(round(time.time() * 1000))
print("Start {0}: {1}".format(s,start_ms))
print("End   {0}: {1}".format(s,end_ms))
print("Diff  {0}: {1} ms\n\n".format(s,end_ms-start_ms))
# Start test 3: 1452828401233
# End   test 3: 1452828406320
# Diff  test 3: 5087 ms

# Using integer value
s="test 4"
v=123456
start_ms = int(round(time.time() * 1000))
for x in range (loopcount):
    y = "{0}".format(v)
end_ms = int(round(time.time() * 1000))
print("Start {0}: {1}".format(s,start_ms))
print("End   {0}: {1}".format(s,end_ms))
print("Diff  {0}: {1} ms\n\n".format(s,end_ms-start_ms))
# Start test 4: 1452828406320
# End   test 4: 1452828411378
# Diff  test 4: 5058 ms


s="test 5"
v=123456
start_ms = int(round(time.time() * 1000))
for x in range (loopcount):
    y = "'%s'" % (v)
end_ms = int(round(time.time() * 1000))
print("Start {0}: {1}".format(s,start_ms))
print("End   {0}: {1}".format(s,end_ms))
print("Diff  {0}: {1} ms\n\n".format(s,end_ms-start_ms))
# Start test 5: 1452828411378
# End   test 5: 1452828415264
# Diff  test 5: 3886 ms

s="test 6"
v=123456
start_ms = int(round(time.time() * 1000))
for x in range (loopcount):
    y = "'{0}'".format(v)
end_ms = int(round(time.time() * 1000))
print("Start {0}: {1}".format(s,start_ms))
print("End   {0}: {1}".format(s,end_ms))
print("Diff  {0}: {1} ms\n\n".format(s,end_ms-start_ms))
# Start test 6: 1452828415264
# End   test 6: 1452828421292
# Diff  test 6: 6028 ms

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 22:43:00 2016
From: report at bugs.python.org (poostenr)
Date: Fri, 15 Jan 2016 03:43:00 +0000
Subject: [issue26118] String performance issue using single quotes
In-Reply-To: <1452811664.45.0.761474192648.issue26118@psf.upfronthosting.co.za>
Message-ID: <1452829380.94.0.825794012763.issue26118@psf.upfronthosting.co.za>


poostenr added the comment:

Eric,

I just tried your examples. 
The loop count is 100x more, but the results are about a factor 10 off.

Test1:
My results:
C:\Data>python -m timeit -s 'x=4' '",{0}".format(x)'
100000000 loops, best of 3: 0.0116 usec per loop 

Eric's results:
$ python -m timeit -s 'x=4' '",{0}".format(x)'
1000000 loops, best of 3: 0.182 usec per loop

Test2:
My results:
C:\Data>python -m timeit -s 'x=4' '"\'{0}\',".format(x)'
100000000 loops, best of 3: 0.0122 usec per loop 

Eric's results:
$ python -m timeit -s 'x=4' '"'\''{0}'\'',".format(x)'
1000000 loops, best of 3: 0.205 usec per loop

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 22:54:11 2016
From: report at bugs.python.org (Paul Hammant)
Date: Fri, 15 Jan 2016 03:54:11 +0000
Subject: [issue26119] Windows Installer can sometimes silently fail pip stage
Message-ID: <1452830051.37.0.928414799264.issue26119@psf.upfronthosting.co.za>


New submission from Paul Hammant:

It NEEDS to communicate more as to why it is rolling back the pip install (progress bar goes backwards, install fails).

Reasons can be:

1. older/wrong versions of Python listed in the PATH - eg c:\Python27 encountered when c:\Python34 is being installed. User should redo PATH env-var.

2. PYTHONPATH similarly set to the wrong thing. User should delete PYTHONPATH env-vars.

3. Incompatible Python installed. User should uninstall other Python's first.

The windows install does not have to silently fail on the pip piece. It can do more to inform them end-user, and not drive them off to stackoverflow.

----------
components: Windows
messages: 258266
nosy: Paul Hammant, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows Installer can sometimes silently fail pip stage
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 00:29:35 2016
From: report at bugs.python.org (Swati Jaiswal)
Date: Fri, 15 Jan 2016 05:29:35 +0000
Subject: [issue25822] Add docstrings to fields of urllib.parse results
In-Reply-To: <1449566140.42.0.349073725206.issue25822@psf.upfronthosting.co.za>
Message-ID: <1452835775.9.0.796830700247.issue25822@psf.upfronthosting.co.za>


Swati Jaiswal added the comment:

Thank you Senthil for the improvements, I'll try to make it better next time :)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 00:48:09 2016
From: report at bugs.python.org (Swati Jaiswal)
Date: Fri, 15 Jan 2016 05:48:09 +0000
Subject: [issue25913] base64.a85decode adobe flag incorrectly utilizes <~ as a
 marker causing error
In-Reply-To: <1450567913.0.0.974183293511.issue25913@psf.upfronthosting.co.za>
Message-ID: <1452836889.61.0.404077488961.issue25913@psf.upfronthosting.co.za>


Swati Jaiswal added the comment:

Modified according to Serhiy's last comment.

----------
Added file: http://bugs.python.org/file41621/iss_25913_3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 00:58:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Jan 2016 05:58:05 +0000
Subject: [issue26097] 2.7 documentation about TextTestRunner do not specify
 all the arguments
In-Reply-To: <1452683228.39.0.232346799389.issue26097@psf.upfronthosting.co.za>
Message-ID: <20160115055802.25928.10231@psf.io>


Roundup Robot added the comment:

New changeset 687f0d4bc188 by Senthil Kumaran in branch '2.7':
Issue26097 - Fix the TextTestRunner documentation, mention all the arguments of the class.
https://hg.python.org/cpython/rev/687f0d4bc188

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 00:58:28 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 15 Jan 2016 05:58:28 +0000
Subject: [issue26097] 2.7 documentation about TextTestRunner do not specify
 all the arguments
In-Reply-To: <1452683228.39.0.232346799389.issue26097@psf.upfronthosting.co.za>
Message-ID: <1452837508.43.0.50663006355.issue26097@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the report. Fixed.

----------
nosy: +orsenthil
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 01:26:10 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 15 Jan 2016 06:26:10 +0000
Subject: [issue26119] Windows Installer can sometimes silently fail pip stage
In-Reply-To: <1452830051.37.0.928414799264.issue26119@psf.upfronthosting.co.za>
Message-ID: <1452839170.31.0.56472762372.issue26119@psf.upfronthosting.co.za>


Steve Dower added the comment:

Do you have any evidence of it failing for those reasons? The command used is specifically crafted to prevent those issues.

I'm not saying there aren't potentially other issues that would be nice to surface (though fairly difficult without modifying a complex piece of third party software), but I don't know that those are the reasons.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 01:31:40 2016
From: report at bugs.python.org (Antony Lee)
Date: Fri, 15 Jan 2016 06:31:40 +0000
Subject: [issue26120] pydoc: move __future__ imports out of the DATA block
Message-ID: <1452839500.03.0.307183465285.issue26120@psf.upfronthosting.co.za>


New submission from Antony Lee:

Currently, for a module that uses __future__ imports, the DATA section of `pydoc foo` contains these imports interspersed with the "real" data from the module.

Even though it is fully-featured _Feature objects that are imported, it probably makes sense to move them out of this section.

----------
assignee: docs at python
components: Documentation
messages: 258272
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: pydoc: move __future__ imports out of the DATA block
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 02:25:15 2016
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Jan 2016 07:25:15 +0000
Subject: [issue26116] CSV-module. The example code don't work. Have to be:
 reader = csv.reader(csvfile, dialect=dialect)
In-Reply-To: <1452808232.54.0.345665768771.issue26116@psf.upfronthosting.co.za>
Message-ID: <1452842715.96.0.620611150743.issue26116@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Thanks!  Now the reason is clear: You use csv.DictReader instead of csv.reader. csv.DictReader has a different argument list - for DictReader the second argument is `fieldnames`.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 02:43:28 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 15 Jan 2016 07:43:28 +0000
Subject: [issue23857] Make default HTTPS certificate verification setting
 configurable
In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za>
Message-ID: <1452843808.12.0.675756911323.issue23857@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Since PEP 493 is now a standards track PEP, the attached patch provides the reference implementation for the current PEP text.

----------
Added file: http://bugs.python.org/file41622/pep493_py27_ssl_config.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 02:56:39 2016
From: report at bugs.python.org (poostenr)
Date: Fri, 15 Jan 2016 07:56:39 +0000
Subject: [issue26118] String performance issue using single quotes
In-Reply-To: <1452811664.45.0.761474192648.issue26118@psf.upfronthosting.co.za>
Message-ID: <1452844599.03.0.391742164413.issue26118@psf.upfronthosting.co.za>


poostenr added the comment:

Eric, Steven,

During further testing I was not able to find any real evidence that the statement I was focused on had a real performance issue.

As I did more testing I noticed that appending data to the file slowed down. The file grew initially with ~30-50KB increments and around 500KB it had slowed down to ~3-5KB/s, until around 1MB the file grew at ~1KB/s. I found this to be odd and because Steven had mentioned other processes, I started looking at some other statements.

After quite a lot of trial and error, I was able to use single quotes and increase my performance to acceptable levels.
Example 3 below is how I resolved it.

Can you explain to me why there was a performance penalty in example 2 ?
Python did something under the hood that I am overlooking.

Did conv.escape_string() change something about columnvalue, so that adding a single quote before and after it introduced some add behavior with writing to file ? I am not an expert on Python and remember reading something about Dynamic typing. 

Example 1: Fast performance, variable s is not encapsulated with single quotes
6.5MB parsed in ~1 minute.
for key in listkeys:
    keyvalue = self.recordstats[key]
    fieldtype   = keyvalue[0]
    columnvalue = record[key]
    columnvalue = conv.escape_string(columnvalue)
    if (count > 1):
        s = "{0},".format(columnvalue)  # No single quotes
    else
        s = "{0},".format(columnvalue)  # No single quotes
    count -= 1
    Append s to file.

Example 2: Slow performance, pre- and post-fixed variable s with single quotes
6.5MB parsed in 35 minutes.
for key in listkeys:
    keyvalue = self.recordstats[key]
    fieldtype   = keyvalue[0]
    columnvalue = record[key]
    columnvalue = conv.escape_string(columnvalue)
    if (count > 1):
        s = "'{0}',".format(columnvalue) # Added single quotes
    else
        s = "'{0}',".format(columnvalue) # Added single quotes
    count -= 1
    Append s to file.

Example 3: Fast performance, variable columnvalue is pre- and post-fixed with single quotes
6.5MB parsed in !45 seconds.
for key in listkeys:
    keyvalue = self.recordstats[key]
    fieldtype   = keyvalue[0]
    columnvalue = record[key]
    columnvalue = conv.escape_string("'" + columnvalue + "'") # Moved single quotes to this statement.
    if (count > 1):
        s = "{0},".format(columnvalue)
    else
        s = "{0},".format(columnvalue)
    count -= 1
    Append s to file.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 03:15:26 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jan 2016 08:15:26 +0000
Subject: [issue26118] String performance issue using single quotes
In-Reply-To: <1452811664.45.0.761474192648.issue26118@psf.upfronthosting.co.za>
Message-ID: <1452845726.72.0.186564910152.issue26118@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I implemented overkill optimization in _PyUnicodeWriter API used by str.format() and str%args. If the result is the input, the string is not copied by value, but by reference.

>>> x="hello"
>>> ("%s" % x) is x
True
>>> ("{}".format(x)) is x
True

If the format string adds something before/after, the string is duplicated:

>>> ("x=%s" % x) is x
False
>>> ("x={}".format(x)) is x
False

The optimization is implemented in _PyUnicodeWriter_WriteStr():

https://hg.python.org/cpython/file/32a4e7b337c9/Objects/unicodeobject.c#l13604

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 03:24:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jan 2016 08:24:01 +0000
Subject: [issue26118] String performance issue using single quotes
In-Reply-To: <1452811664.45.0.761474192648.issue26118@psf.upfronthosting.co.za>
Message-ID: <1452846241.63.0.898753865665.issue26118@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> If you see a factor of 30x difference in your code, I suspect it's not related to str.format(), but some other processing in your code.

The performance of instructions like ("x=%s" % x) or ("x={}".format(x)) depend on the length of the string. Maybe poostenr has some very long strings?

--

Closed issues related to _PyUnicodeWriter API:

* issue #14716: Use unicode_writer API for str.format()
* issue #14687: Optimize str%tuple for the PEP 393
* issue #14744: Use _PyUnicodeWriter API in str.format() internals
* issue #16147: Rewrite PyUnicode_FromFormatV() to use the _PyUnicodeWriter API
* issue #17694: Enhance _PyUnicodeWriter API to control minimum buffer length without overallocation
* issue #19513: Use PyUnicodeWriter instead of PyAccu in repr(tuple) and repr(list)
* issue #19646: Use PyUnicodeWriter in repr(dict)

I'm listing these issues because they contain microbenchmarks script if you would like to play with them.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 03:41:13 2016
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Fri, 15 Jan 2016 08:41:13 +0000
Subject: [issue26116] CSV-module. The example code don't work. Have to be:
 reader = csv.reader(csvfile, dialect=dialect)
In-Reply-To: <1452808232.54.0.345665768771.issue26116@psf.upfronthosting.co.za>
Message-ID: <1452847273.1.0.344412840987.issue26116@psf.upfronthosting.co.za>


?????? ????????? added the comment:

))
Thanks!
Be happy!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 03:47:59 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 15 Jan 2016 08:47:59 +0000
Subject: [issue26114] Rewrite math.erf() and math.erfc() from scratch
In-Reply-To: <1452803741.39.0.631242355329.issue26114@psf.upfronthosting.co.za>
Message-ID: <1452847679.74.0.710663765088.issue26114@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

The comment is unfortunate. The code in Modules/mathmodule.c *was* written from scratch (by me). All I took from Numerical Recipes was the idea of using continued fractions from one part of the domain and a power-series expansion for another part. If you compare the code with the NR code, there's really no similarity beyond that part.

Perhaps just deleting the NR reference is the way to go.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 04:05:44 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 15 Jan 2016 09:05:44 +0000
Subject: [issue26114] Rewrite math.erf() and math.erfc() from scratch
In-Reply-To: <1452803741.39.0.631242355329.issue26114@psf.upfronthosting.co.za>
Message-ID: <1452848744.03.0.681854981023.issue26114@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

... and the way I read it, the NR licence applies specifically to their code, not to the basic numerical ideas set out in the text (which is all we're using). We're not using the actual code from NR at all.

IOW, IANAL but I really don't think there's an issue here.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 04:06:34 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Jan 2016 09:06:34 +0000
Subject: [issue26114] Rewrite math.erf() and math.erfc() from scratch
In-Reply-To: <1452803741.39.0.631242355329.issue26114@psf.upfronthosting.co.za>
Message-ID: <1452848794.92.0.170267730098.issue26114@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

erf() is a part of C99. May be move hand-writen implementation to Modules/_math.c and use libc erf() if available?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 04:10:35 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jan 2016 09:10:35 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <1452849035.02.0.604097218298.issue23606@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Strictly there's nothing incorrect about the docs, and `cdll.msvcrt` is no more incorrect than it has been since Python 2.4 or so (whenever we  stopped using VC6). It will find the DLL and you can call the functions, but it isn't the same DLL as the exports in the `msvcrt` module will call.

Is there a documentation of what functions are exposed through it?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 04:20:01 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 15 Jan 2016 09:20:01 +0000
Subject: [issue26114] Rewrite math.erf() and math.erfc() from scratch
In-Reply-To: <1452848744.03.0.681854981023.issue26114@psf.upfronthosting.co.za>
Message-ID: <5698B9BC.1020405@egenix.com>


Marc-Andre Lemburg added the comment:

On 15.01.2016 10:05, Mark Dickinson wrote:
> 
> Mark Dickinson added the comment:
> 
> ... and the way I read it, the NR licence applies specifically to their code, not to the basic numerical ideas set out in the text (which is all we're using). We're not using the actual code from NR at all.
> 
> IOW, IANAL but I really don't think there's an issue here.

The license is a copyright license, so it only applies to the
actual code from the book. The ideas would have to be patented
to be protected. Copyright in some code or text is not enough
to (potentially) prevent someone else from reusing the ideas.

If someone is aware of a patent on the algorithm, we may have
an issue. Otherwise, there's no issue if we're using Mark's
implementation.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 04:20:46 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 15 Jan 2016 09:20:46 +0000
Subject: [issue26114] Rewrite math.erf() and math.erfc() from scratch
In-Reply-To: <1452803741.39.0.631242355329.issue26114@psf.upfronthosting.co.za>
Message-ID: <1452849646.6.0.177224577308.issue26114@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

@Serhiy: Sure, that would work (the same way that we do for log1p). I *think* I tried this at the time, but it turns out that some libm implementations of erf and erfc are pretty bad, so our tests failed. (But I may be misremembering.)

In any case, the proposal to use the libm erf/erfc should be a separate issue, I think.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 04:25:08 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 15 Jan 2016 09:25:08 +0000
Subject: [issue26092] doctest should allow custom sys.displayhook
In-Reply-To: <1452622857.37.0.137754453324.issue26092@psf.upfronthosting.co.za>
Message-ID: <1452849908.75.0.11042943668.issue26092@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +georg.brandl
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 04:46:03 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 15 Jan 2016 09:46:03 +0000
Subject: [issue26084] HTMLParser mishandles last attribute in self-closing tag
In-Reply-To: <1452545325.06.0.546064798317.issue26084@psf.upfronthosting.co.za>
Message-ID: <1452851163.37.0.409055041186.issue26084@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I don't think this is a bug. The HTML5 syntax spec tells:

    If an attribute using the unquoted attribute syntax is to be followed by another attribute or by the optional "/" (U+002F) character allowed in step 6 of the start tag syntax above, then there must be a space character separating the two.

So I think HTMLParser's behaviour is right.

The link is https://www.w3.org/TR/html5/syntax.html#attributes-0.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 04:51:42 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 15 Jan 2016 09:51:42 +0000
Subject: [issue26084] HTMLParser mishandles last attribute in self-closing tag
In-Reply-To: <1452545325.06.0.546064798317.issue26084@psf.upfronthosting.co.za>
Message-ID: <1452851502.26.0.882372425587.issue26084@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Hmm, can not say the behaviour is right. But since the HTML doesn't follows the official rule, HTMLParser's behaviour is understandable and can not be identified as incorrect.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 05:43:29 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 15 Jan 2016 10:43:29 +0000
Subject: [issue26118] String performance issue using single quotes
In-Reply-To: <1452844599.03.0.391742164413.issue26118@psf.upfronthosting.co.za>
Message-ID: <20160115104312.GM10854@ando.pearwood.info>


Steven D'Aprano added the comment:

On Fri, Jan 15, 2016 at 07:56:39AM +0000, poostenr wrote:
> As I did more testing I noticed that appending data to the file slowed 
> down. The file grew initially with ~30-50KB increments and around 
> 500KB it had slowed down to ~3-5KB/s, until around 1MB the file grew 
> at ~1KB/s.

How are you appending to the file? In the code snippets below you merely 
say "append s to file", which is not Python code and could hide a 
multitude of sins. You're asking us to diagnose slow performance in code 
we can't see.

Or perhaps your disk is just badly fragmented, and as the file gets 
bigger, performance gets worse.

> Did conv.escape_string() change something about columnvalue

I don't know. What's conv.escape_string? Where does it come from, and 
what does it do? Again, you're asking us to diagnose code we can't see.

Perhaps you should run the profiler and see where your code is spending 
most of its time.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 06:42:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Jan 2016 11:42:15 +0000
Subject: [issue26121] Use C99 functions in math if available
Message-ID: <1452858135.55.0.233335376493.issue26121@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently the math module uses own implementation of some mathematical functions that are in C99 standard, but not in C89 standard: tgamma, lgamma, erf, erfc. Proposed patch makes it to use functions from standard C library if they are available. They are faster and presumably more accurate.

Here are microbenchmark results (time in microseconds):

                  0.1     1      3     10     30
erf unpatched:   0.506  0.655  0.509  0.548  0.239
erf patched:     0.129  0.252  0.357  0.253  0.253

erfc unpatched:  0.508  0.646  0.532  0.522  0.251
erfc patched:    0.129  0.239  0.373  0.371  0.307

                    0.1    1.5     3     10     10.5
gamma unpatched:   0.369  0.279  0.273  0.274  0.457
gamma patched:     0.24   0.23   0.412  0.741  0.682

lgamma unpatched:  0.351  0.338  0.478  0.627  0.52
lgamma patched:    0.217  0.155  0.37   0.372  0.247

If some libm implementations are pretty bad, they can be disabled by undefining corresponding HAVE_XXX macros.

----------
components: Extension Modules
files: math_libc_funcs.patch
keywords: patch
messages: 258288
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use C99 functions in math if available
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41623/math_libc_funcs.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 07:18:09 2016
From: report at bugs.python.org (Alessandro Cucci)
Date: Fri, 15 Jan 2016 12:18:09 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1452860289.17.0.545118381879.issue19475@psf.upfronthosting.co.za>


Alessandro Cucci added the comment:

I there anything else I can do for this?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 07:44:07 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 15 Jan 2016 12:44:07 +0000
Subject: [issue26072] pdb fails to access variables closed over
In-Reply-To: <1452402984.12.0.000738362264887.issue26072@psf.upfronthosting.co.za>
Message-ID: <1452861847.91.0.386801943108.issue26072@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +georg.brandl
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 07:48:14 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 15 Jan 2016 12:48:14 +0000
Subject: [issue26122] Isolated mode doesn't ignore PYTHONHASHSEED
Message-ID: <1452862094.75.0.964095204421.issue26122@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

While working on the draft PEP 432 implementation, I noticed that -I isn't special cased for early processing the same way that -E is: https://hg.python.org/cpython/file/tip/Modules/main.c#l265

This means that when isolated mode is used to turn off environment variable access, PYTHONHASHSEED may still be read while configuring hash randomisation.

----------
assignee: christian.heimes
messages: 258290
nosy: christian.heimes, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Isolated mode doesn't ignore PYTHONHASHSEED
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 08:10:03 2016
From: report at bugs.python.org (Sebastian Rittau)
Date: Fri, 15 Jan 2016 13:10:03 +0000
Subject: [issue26123] http.client status code constants incompatible with
 Python 3.4
Message-ID: <1452863403.25.0.433090378442.issue26123@psf.upfronthosting.co.za>


New submission from Sebastian Rittau:

The HTTP status code constants in Python 3.5 http.client are not compatible with the constants in Python 3.4, since the str() behaviour is different. This breaks code: 

srittau at moby:~$ python3.5
Python 3.5.1+ (default, Jan 13 2016, 15:09:18) 
[GCC 5.3.1 20160101] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import http.client
>>> str(http.client.OK)
'HTTPStatus.OK'

vs:

rittau at moby:~$ python3.4
Python 3.4.4 (default, Jan  5 2016, 15:35:18) 
[GCC 5.3.1 20160101] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import http.client
>>> str(http.client.OK)
'200'

----------
components: Library (Lib)
messages: 258291
nosy: srittau
priority: normal
severity: normal
status: open
title: http.client status code constants incompatible with Python 3.4
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 08:14:41 2016
From: report at bugs.python.org (Charles Daffern)
Date: Fri, 15 Jan 2016 13:14:41 +0000
Subject: [issue26124] shlex.quote and pipes.quote do not quote shell keywords
Message-ID: <1452863681.04.0.149848593597.issue26124@psf.upfronthosting.co.za>


New submission from Charles Daffern:

The shlex.quote and pipes.quote functions do not quote shell keywords.

Example shell keywords: done, time, coproc, while

Presumably the intent of the quote functions is to prevent the resulting string from altering the syntax of the script it is inserted into, which is why I think these need to be quoted.

We can't possibly know every shell keyword, so the only sensible thing to do here is to quote everything.

----------
components: Extension Modules
messages: 258292
nosy: Charles Daffern
priority: normal
severity: normal
status: open
title: shlex.quote and pipes.quote do not quote shell keywords
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 08:28:42 2016
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Jan 2016 13:28:42 +0000
Subject: [issue26121] Use C99 functions in math if available
In-Reply-To: <1452858135.55.0.233335376493.issue26121@psf.upfronthosting.co.za>
Message-ID: <1452864522.79.0.997854276.issue26121@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Faster: maybe. More accurate ... Mark can tell you some funny stories. :)

----------
nosy: +christian.heimes

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 08:52:59 2016
From: report at bugs.python.org (Carlo Beccarini)
Date: Fri, 15 Jan 2016 13:52:59 +0000
Subject: [issue26125] Incorrect error message in the module
 asyncio.selector_events.
Message-ID: <1452865979.87.0.840611229209.issue26125@psf.upfronthosting.co.za>


New submission from Carlo Beccarini:

Incorrect error message in the module asyncio.selector_events for the methods:
_SelectorSocketTransport.write
_SelectorSslTransport.write
_SelectorDatagramTransport.sendto.

The previous error was raising a Tuple:
TypeError: ('data argument must be byte-ish (%r)', )

Patched:
TypeError: data argument must be a bytes-like object, not 'str'

----------
components: asyncio
files: patch.diff
keywords: patch
messages: 258294
nosy: Paradisee, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Incorrect error message in the module asyncio.selector_events.
versions: Python 3.4
Added file: http://bugs.python.org/file41624/patch.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 09:02:06 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 15 Jan 2016 14:02:06 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <1452866526.41.0.55108591281.issue23606@psf.upfronthosting.co.za>


Steve Dower added the comment:

The msvcrt module? I don't think so.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 09:03:21 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Jan 2016 14:03:21 +0000
Subject: [issue26125] Incorrect error message in the module
 asyncio.selector_events.
In-Reply-To: <1452865979.87.0.840611229209.issue26125@psf.upfronthosting.co.za>
Message-ID: <1452866601.66.0.3087661927.issue26125@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

LGTM unless you think we should also add a test that checks that the name of the incorrect type is included in the error message.

----------
nosy: +ezio.melotti
stage:  -> commit review
type:  -> behavior
versions: +Python 3.5, Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 09:28:42 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 15 Jan 2016 14:28:42 +0000
Subject: [issue26124] shlex.quote and pipes.quote do not quote shell keywords
In-Reply-To: <1452863681.04.0.149848593597.issue26124@psf.upfronthosting.co.za>
Message-ID: <1452868122.74.0.152878010272.issue26124@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
components: +Library (Lib) -Extension Modules
nosy: +eric.araujo
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 09:34:54 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 15 Jan 2016 14:34:54 +0000
Subject: [issue26123] http.client status code constants incompatible with
 Python 3.4
In-Reply-To: <1452863403.25.0.433090378442.issue26123@psf.upfronthosting.co.za>
Message-ID: <1452868494.23.0.342695677027.issue26123@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
keywords: +3.5regression
nosy: +serhiy.storchaka
type:  -> behavior
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 09:40:19 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Jan 2016 14:40:19 +0000
Subject: [issue26084] HTMLParser mishandles last attribute in self-closing tag
In-Reply-To: <1452545325.06.0.546064798317.issue26084@psf.upfronthosting.co.za>
Message-ID: <1452868819.47.0.234642027658.issue26084@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

This is not a bug, as described in the HTML5 standard[0], if an unquoted attribute value is followed by a /, the / is included (the "anything else" branch of that list).
This is also what browsers do: try to create an HTML document that includes  and open it in a browser, then use the inspector to examine the result -- you will see  (at least on firefox).
HTMLParser follows the HTML5 standard, so I'm closing this as "not a bug".
Thanks anyway for the report and to Xiang for pointing out that it's not a bug.

[0]: https://www.w3.org/TR/html5/syntax.html#attribute-value-%28unquoted%29-state

----------
resolution:  -> not a bug
stage: test needed -> resolved
status: open -> closed
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 10:09:21 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Jan 2016 15:09:21 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1452870561.45.0.275403814726.issue19475@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
nosy:  -r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 10:13:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Jan 2016 15:13:26 +0000
Subject: [issue26124] shlex.quote and pipes.quote do not quote shell keywords
In-Reply-To: <1452863681.04.0.149848593597.issue26124@psf.upfronthosting.co.za>
Message-ID: <1452870806.33.0.383861890521.issue26124@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please provide an example?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 10:20:56 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Fri, 15 Jan 2016 15:20:56 +0000
Subject: [issue18595] zipfile: symlinks etc.
In-Reply-To: <1375170318.76.0.496081120587.issue18595@psf.upfronthosting.co.za>
Message-ID: <1452871256.61.0.86434035874.issue18595@psf.upfronthosting.co.za>


Changes by Thomas Kluyver :


----------
nosy: +takluyver

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 10:37:27 2016
From: report at bugs.python.org (Charles Daffern)
Date: Fri, 15 Jan 2016 15:37:27 +0000
Subject: [issue26124] shlex.quote and pipes.quote do not quote shell keywords
In-Reply-To: <1452863681.04.0.149848593597.issue26124@psf.upfronthosting.co.za>
Message-ID: <1452872247.53.0.754301676504.issue26124@psf.upfronthosting.co.za>


Charles Daffern added the comment:

It's definitely a corner case (in argv[0] position + is keyword), but here's an example:

>>> import subprocess
>>> import shlex
>>> subprocess.call(shlex.quote("done"), shell=True)
/bin/sh: 1: Syntax error: "done" unexpected
2

The expected output of this would be:

/bin/sh: 1: done: not found
127

This would be the output if shlex.quote("done") returned "'done'" or r'\done' or any other combination of escaped/quoted characters where the keyword would otherwise be.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 10:58:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Jan 2016 15:58:13 +0000
Subject: [issue26124] shlex.quote and pipes.quote do not quote shell keywords
In-Reply-To: <1452863681.04.0.149848593597.issue26124@psf.upfronthosting.co.za>
Message-ID: <1452873493.51.0.679034162214.issue26124@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This does not seem to be a serious problem. In any case the command is failed. And usually argv[0] is predefined command name, not arbitrary user input. To be sure that it is existing program, you can use shutil.which().

I would close this issue as "won't fix".

----------
resolution:  -> wont fix

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 11:01:58 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 15 Jan 2016 16:01:58 +0000
Subject: [issue26125] Incorrect error message in the module
 asyncio.selector_events.
In-Reply-To: <1452866601.66.0.3087661927.issue26125@psf.upfronthosting.co.za>
Message-ID: 


Guido van Rossum added the comment:

Remember also to apply to asyncio's own GitHub repo.

--Guido (mobile)
On Jan 15, 2016 6:03 AM, "Ezio Melotti"  wrote:

>
> Ezio Melotti added the comment:
>
> LGTM unless you think we should also add a test that checks that the name
> of the incorrect type is included in the error message.
>
> ----------
> nosy: +ezio.melotti
> stage:  -> commit review
> type:  -> behavior
> versions: +Python 3.5, Python 3.6 -Python 3.4
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 11:09:59 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 15 Jan 2016 16:09:59 +0000
Subject: [issue26123] http.client status code constants incompatible with
 Python 3.4
In-Reply-To: <1452863403.25.0.433090378442.issue26123@psf.upfronthosting.co.za>
Message-ID: <1452874199.5.0.209299337491.issue26123@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy: +ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 11:15:32 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 15 Jan 2016 16:15:32 +0000
Subject: [issue26123] http.client status code constants incompatible with
 Python 3.4
In-Reply-To: <1452863403.25.0.433090378442.issue26123@psf.upfronthosting.co.za>
Message-ID: <1452874532.92.0.692351471541.issue26123@psf.upfronthosting.co.za>


Ethan Furman added the comment:

These changes were made in issue21793.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 11:15:51 2016
From: report at bugs.python.org (Charles Daffern)
Date: Fri, 15 Jan 2016 16:15:51 +0000
Subject: [issue26124] shlex.quote and pipes.quote do not quote shell keywords
In-Reply-To: <1452863681.04.0.149848593597.issue26124@psf.upfronthosting.co.za>
Message-ID: <1452874551.17.0.643438351847.issue26124@psf.upfronthosting.co.za>


Charles Daffern added the comment:

In that case, should the documentation specify that shlex.quote is unsuitable for quoting command names?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 11:21:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Jan 2016 16:21:40 +0000
Subject: [issue26124] shlex.quote and pipes.quote do not quote shell keywords
In-Reply-To: <1452863681.04.0.149848593597.issue26124@psf.upfronthosting.co.za>
Message-ID: <1452874900.0.0.672729664402.issue26124@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be. But only if this doesn't make the documentation too verbose.

----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy
nosy: +docs at python
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 11:25:30 2016
From: report at bugs.python.org (Carlo Beccarini)
Date: Fri, 15 Jan 2016 16:25:30 +0000
Subject: [issue26125] Incorrect error message in the module
 asyncio.selector_events.
In-Reply-To: <1452865979.87.0.840611229209.issue26125@psf.upfronthosting.co.za>
Message-ID: <1452875130.98.0.587400466812.issue26125@psf.upfronthosting.co.za>


Changes by Carlo Beccarini :


----------
type: behavior -> 
versions: +Python 3.4 -Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41625/patch.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 11:28:13 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Jan 2016 16:28:13 +0000
Subject: [issue26114] Rewrite math.erf() and math.erfc() from scratch
In-Reply-To: <1452803741.39.0.631242355329.issue26114@psf.upfronthosting.co.za>
Message-ID: <1452875293.82.0.644256397699.issue26114@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the historical information, Mark! I'll either update the comment or flat-out delete it so it doesn't trip anyone else up.

I'll also scale back the scope of the update since it's just a cleanup and not an IP issue.

----------
assignee:  -> brett.cannon
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 11:28:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Jan 2016 16:28:22 +0000
Subject: [issue26123] http.client status code constants incompatible with
 Python 3.4
In-Reply-To: <1452863403.25.0.433090378442.issue26123@psf.upfronthosting.co.za>
Message-ID: <1452875302.37.0.948277117571.issue26123@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, this a side effect of using more human-friendly enums. This is not a problem if string representation is used in formatting human-readable messages, but if you need numerical representation, you could use str(int(code)), '%d' % code or '{:d}'.format(code).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 11:45:28 2016
From: report at bugs.python.org (Carlo Beccarini)
Date: Fri, 15 Jan 2016 16:45:28 +0000
Subject: [issue26125] Incorrect error message in the module
 asyncio.selector_events.
In-Reply-To: <1452865979.87.0.840611229209.issue26125@psf.upfronthosting.co.za>
Message-ID: <1452876328.84.0.514391218178.issue26125@psf.upfronthosting.co.za>


Carlo Beccarini added the comment:

https://github.com/python/asyncio/pull/313

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 11:56:02 2016
From: report at bugs.python.org (poostenr)
Date: Fri, 15 Jan 2016 16:56:02 +0000
Subject: [issue26118] String performance issue using single quotes
In-Reply-To: <1452811664.45.0.761474192648.issue26118@psf.upfronthosting.co.za>
Message-ID: <1452876962.1.0.761703082009.issue26118@psf.upfronthosting.co.za>


poostenr added the comment:

Thank you for your feedback Victor and Steven.

I just copied my scripts and 360MB of CSV files over to Linux.
The entire process finished in 4 minutes exactly, using the original python scripts.
So there is something different between my environments.
If it was a fragmentation issue, then I would expect to always have a slow performance on the Windows system. But I can influence the performance by alternating between the two original statements:
s = "{0},".format(columnvalue)   # fast
s = "'{0}',".format(columnvalue) # ~30x slower

I apologize for not being able to provide the entire code.
There is too much code to post at this time.

I am opening a file like this:
#logger = open(filename, rw, buffering, encoding)
logger = open('output.sql', 'a', 1, 'iso-8859-1')

I write to file:
logger.write(text+'\n')

I'm using a library to escape the string before saving to file.
import pymysql.converters as conv
<...>
for key in listkeys:
    keyvalue = self.recordstats[key]
    fieldtype   = keyvalue[0]
    columnvalue = record[key]
    columnvalue = conv.escape_string(columnvalue)
    if (count > 1):
        s = "{0},".format(columnvalue)  # No single quotes
    else
        s = "{0},".format(columnvalue)  # No single quotes
    count -= 1
    logger.write(s+'\n')

I appreciate the feedback and ideas so far.
Trying the profiler is on my list to see if it provides more insight.
I am not using Anaconda3 on Linux. Perhaps that has an impact somehow?

I never suspected inserting the two single quotes to cause such a problem in performance. I noticed it when I parsed ~40GB of data and it took almost a week to complete instead of my expected 6-7 hrs.
Just the other day I decided to remove the single quotes because it was the only thing left that I'd changed. I had discarded that change the past two weeks because that couldn't be causing the performance problem.

Today, I wasn't expecting such a big difference between running my script on Linux or Windows.

If I discover anything else, I will post an update.
When I get the chance I can remove redundant code and post the source.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 11:59:20 2016
From: report at bugs.python.org (Sebastian Rittau)
Date: Fri, 15 Jan 2016 16:59:20 +0000
Subject: [issue26123] http.client status code constants incompatible with
 Python 3.4
In-Reply-To: <1452863403.25.0.433090378442.issue26123@psf.upfronthosting.co.za>
Message-ID: <1452877160.38.0.715490142301.issue26123@psf.upfronthosting.co.za>


Sebastian Rittau added the comment:

It is no doubt that is easy to work around. Once I found the problem it took about five minutes to fix it and roll a new release. And of course for Python 3.5+ code it is better to use the enum http.HTTPStatus directly (I actually like that enum a lot). But this breaks existing code that should not break. It might be too late to change now, though.

As a side note, I would also have preferred str(HTTPStatus.OK) to return "OK" or "200" - the latter would mirror default format behaviour - instead of "HTTPStatus.OK", but this may be too late as well.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 12:01:30 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 15 Jan 2016 17:01:30 +0000
Subject: [issue26118] String performance issue using single quotes
In-Reply-To: <1452811664.45.0.761474192648.issue26118@psf.upfronthosting.co.za>
Message-ID: <1452877290.16.0.193925559917.issue26118@psf.upfronthosting.co.za>


SilentGhost added the comment:

poostenr, this is demonstrably not a problem with the CPython, which this bug tracker is about. There are few options available on the internet if you need help with your code: mailing lists and irc are among them.

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 12:04:01 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 15 Jan 2016 17:04:01 +0000
Subject: [issue26121] Use C99 functions in math if available
In-Reply-To: <1452858135.55.0.233335376493.issue26121@psf.upfronthosting.co.za>
Message-ID: <1452877441.66.0.373551389643.issue26121@psf.upfronthosting.co.za>


Changes by Yury Selivanov :


----------
nosy: +brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 12:39:16 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Jan 2016 17:39:16 +0000
Subject: [issue26114] Rewrite math.erf() and math.erfc() from scratch
In-Reply-To: <1452803741.39.0.631242355329.issue26114@psf.upfronthosting.co.za>
Message-ID: <20160115173911.41318.21711@psf.io>


Roundup Robot added the comment:

New changeset 76eb752e5447 by Brett Cannon in branch '3.5':
Issue #26114: Remove a reference to 'Numerical Recipes'.
https://hg.python.org/cpython/rev/76eb752e5447

New changeset 8ad701463cd7 by Brett Cannon in branch 'default':
Merge for issue #26114
https://hg.python.org/cpython/rev/8ad701463cd7

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 12:41:59 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Jan 2016 17:41:59 +0000
Subject: [issue26114] Rewrite math.erf() and math.erfc() from scratch
In-Reply-To: <1452803741.39.0.631242355329.issue26114@psf.upfronthosting.co.za>
Message-ID: <20160115174155.121312.84921@psf.io>


Roundup Robot added the comment:

New changeset faac8f09020d by Brett Cannon in branch '2.7':
Issue #26114: Remove mention of 'Numerical Recipes'.
https://hg.python.org/cpython/rev/faac8f09020d

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 12:42:13 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Jan 2016 17:42:13 +0000
Subject: [issue26114] Rewrite math.erf() and math.erfc() from scratch
In-Reply-To: <1452803741.39.0.631242355329.issue26114@psf.upfronthosting.co.za>
Message-ID: <1452879733.53.0.496759341958.issue26114@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 12:54:06 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Fri, 15 Jan 2016 17:54:06 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1452880446.6.0.37739738606.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Attached is a first go at a patch enabling zipfile.open(blah, mode='w')

Files must be written sequentially, so you have to close one writing handle before opening another. If you try to open a second one before closing the first, it will raise RuntimeError. I considered doing something where it would write to temporary files and add them to the zip file when they were closed, but it seemed like a bad idea.

You can almost certainly break this by reading from a zip file while there's an open writing handle. Resolving this is tricky because there's a disconnect in the requirements for reading and writing: writing allows for a non-seekable output stream, but reading assumes that you can seek freely. The simplest fix is to block reading while there is an open file handle. I don't think many people will need to read one file from a zip while writing another, anyway.

I have used the lock, but I haven't thought carefully about thread safety, so that should still be checked carefully.

----------
Added file: http://bugs.python.org/file41626/zipfile-open-w.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 13:04:50 2016
From: report at bugs.python.org (Mark Summerfield)
Date: Fri, 15 Jan 2016 18:04:50 +0000
Subject: [issue26126] Possible subtle bug when normalizing and
 str.translate()ing
Message-ID: <1452881090.74.0.501338365474.issue26126@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

I am using Python 3.4.3 on Xubuntu 14.04 LTS 64-bit.

I have a program that when run repeatedly sometimes what I expect, and sometimes does not:

$ ~/tmp/normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')
$ ~/tmp/normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')
$ ~/tmp/normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')
$ ~/tmp/normbug.py 
BUG ('The aenid oevre', '!=', 'The AEnid oevre')
$ ~/tmp/normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')
$ ~/tmp/normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')
$ ~/tmp/normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')
$ ~/tmp/normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')
$ ~/tmp/normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')
$ ~/tmp/normbug.py 
BUG ('The aenid oevre', '!=', 'The AEnid oevre')
$ ~/tmp/normbug.py 
BUG ('The aenid oevre', '!=', 'The AEnid oevre')
$ ~/tmp/normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')

As you can see, sometimes the left (actual) is case-folded, and sometimes it isn't which is surprising given the code (which is attached).

Of course this could be a mistake on my part; maybe I've misunderstood how the unicode normalizing works.

----------
files: normbug.py
messages: 258314
nosy: mark
priority: normal
severity: normal
status: open
title: Possible subtle bug when normalizing and str.translate()ing
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file41627/normbug.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 13:17:49 2016
From: report at bugs.python.org (Peter Otten)
Date: Fri, 15 Jan 2016 18:17:49 +0000
Subject: [issue26126] Possible subtle bug when normalizing and
 str.translate()ing
In-Reply-To: <1452881090.74.0.501338365474.issue26126@psf.upfronthosting.co.za>
Message-ID: <1452881869.3.0.200686471693.issue26126@psf.upfronthosting.co.za>


Peter Otten added the comment:

There seems to be a connection to hash randomization. I consistently get

$ PYTHONHASHSEED=1 python3.6 ./normbug.py 
BUG ('The aenid oevre', '!=', 'The AEnid oevre')
$ PYTHONHASHSEED=0 python3.6 ./normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')

----------
nosy: +peter.otten

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 13:34:14 2016
From: report at bugs.python.org (Peter Otten)
Date: Fri, 15 Jan 2016 18:34:14 +0000
Subject: [issue26126] Possible subtle bug when normalizing and
 str.translate()ing
In-Reply-To: <1452881090.74.0.501338365474.issue26126@psf.upfronthosting.co.za>
Message-ID: <1452882854.38.0.496483572161.issue26126@psf.upfronthosting.co.za>


Peter Otten added the comment:

Not a bug. In your XFORMS dict you have

>>> ord("?") == 0xC6
True

Whether the value of "?" or 0xC6 is used by str.maketrans() depends on the order of the dict entries which in turn is determined by the keys' hash. Remove one and you should see consistent results.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 13:37:04 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 15 Jan 2016 18:37:04 +0000
Subject: [issue26126] Possible subtle bug when normalizing and
 str.translate()ing
In-Reply-To: <1452881090.74.0.501338365474.issue26126@psf.upfronthosting.co.za>
Message-ID: <1452883024.03.0.869952823928.issue26126@psf.upfronthosting.co.za>


SilentGhost added the comment:

Mark, your XFORMS dictionary contains this entry: 0x00C6: "ae"
It should be 'AE'. The same applies to 0x0152: "oe" which should be 'OE'.

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 13:37:19 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 15 Jan 2016 18:37:19 +0000
Subject: [issue26126] Possible subtle bug when normalizing and
 str.translate()ing
In-Reply-To: <1452881090.74.0.501338365474.issue26126@psf.upfronthosting.co.za>
Message-ID: <1452883039.49.0.737390376375.issue26126@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 13:44:29 2016
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 15 Jan 2016 18:44:29 +0000
Subject: [issue26124] shlex.quote and pipes.quote do not quote shell keywords
In-Reply-To: <1452863681.04.0.149848593597.issue26124@psf.upfronthosting.co.za>
Message-ID: <1452883469.2.0.883998300717.issue26124@psf.upfronthosting.co.za>


Fred L. Drake, Jr. added the comment:

It's not at all obvious that the intention is to ensure such an argument should be treated only as a command external to the shell.

If an application really wants to ensure the command is not handled as a shell built-in, it should use shell=False.

Making this clear in the documentation is reasonable.

----------
nosy: +fdrake

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 13:48:20 2016
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 15 Jan 2016 18:48:20 +0000
Subject: [issue26094] ConfigParser.get() doc to be updated according to the
 configparser.py header doc
In-Reply-To: <1452645599.68.0.959713633048.issue26094@psf.upfronthosting.co.za>
Message-ID: <1452883700.62.0.0177769394482.issue26094@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. :


----------
nosy: +fdrake

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 13:56:51 2016
From: report at bugs.python.org (Antony Lee)
Date: Fri, 15 Jan 2016 18:56:51 +0000
Subject: [issue26127] Broken link in docs for tokenize
Message-ID: <1452884211.95.0.164669159709.issue26127@psf.upfronthosting.co.za>


New submission from Antony Lee:

The docs for `tokenize.detect_encoding` state `Use open() to open Python source files: it uses detect_encoding() to detect the file encoding.`

Unfortunately, clicking on `open` redirects to the builtin `open` function, not to `tokenize.open` as it should.

----------
assignee: docs at python
components: Documentation
messages: 258319
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Broken link in docs for tokenize
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 14:12:45 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 15 Jan 2016 19:12:45 +0000
Subject: [issue26127] Broken link in docs for tokenize
In-Reply-To: <1452884211.95.0.164669159709.issue26127@psf.upfronthosting.co.za>
Message-ID: <1452885165.24.0.126881385288.issue26127@psf.upfronthosting.co.za>


SilentGhost added the comment:

Here is the patch. Most of the fixes are however for the tokenize function that was for whatever reason linked to the module.

----------
keywords: +patch
nosy: +SilentGhost
stage:  -> patch review
type:  -> behavior
Added file: http://bugs.python.org/file41628/issue26127.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 14:26:30 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Jan 2016 19:26:30 +0000
Subject: [issue17633] zipimport's handling of namespace packages is incorrect
In-Reply-To: <1365070223.85.0.365511954484.issue17633@psf.upfronthosting.co.za>
Message-ID: <1452885990.41.0.873584283009.issue17633@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The fix for 3.5 is in https://hg.python.org/cpython/rev/07a615a8f9ad and 3.6 in https://hg.python.org/cpython/rev/87f87673af7b.

Thanks to Phil and Mike for tackling this problem!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 14:29:50 2016
From: report at bugs.python.org (Charles Daffern)
Date: Fri, 15 Jan 2016 19:29:50 +0000
Subject: [issue26124] shlex.quote and pipes.quote do not quote shell keywords
In-Reply-To: <1452863681.04.0.149848593597.issue26124@psf.upfronthosting.co.za>
Message-ID: <1452886190.18.0.454729273231.issue26124@psf.upfronthosting.co.za>


Charles Daffern added the comment:

>To be sure that it is existing program, you can use shutil.which()

I'd like to clear this up a little because this is worded as if shutil.which()'s success implies that the shell will not fail.

Here is the setup to demonstrate:

>>> import os, shlex, shutil, subprocess
>>> open("do", "w").write("#!/bin/sh\necho Something is being done...")
__main__:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='do' mode='w' encoding='UTF-8'>
41
>>> os.chmod("do", 0o700)


Here is the behaviour using shlex.quote:

>>> subprocess.call(shlex.quote("do"), shell=True, env={'PATH': '.'})
/bin/sh: 1: Syntax error: "do" unexpected
2


Here is the behaviour when quoting properly:

>>> subprocess.call("'do'", shell=True, env={'PATH': '.'})
Something is being done...
0


Here is the output of shutil.which:

>>> shutil.which("do", path=".")
'./do'


So checking shutil.which()'s success or failure will not guard against this case (though using its output would work around the problem).

>It's not at all obvious that the intention is to ensure such an argument should be treated only as a command external to the shell.
>
>If an application really wants to ensure the command is not handled as a shell built-in, it should use shell=False.

The shell will still search builtins if the argument is quoted, it just won't search for keywords. So, a quoted "bind", "shopt" or "jobs" will still work, but a quoted "case", "fi" or "done" will cause the shell to search for a command of that name rather than treating it as syntax.

Looking at the source, shlex.quote's refusal to quote certain arguments appears to be intentional. I would rather it quote slightly more carefully than necessary, than quote something incorrectly.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 14:40:19 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Jan 2016 19:40:19 +0000
Subject: [issue17633] zipimport's handling of namespace packages is incorrect
In-Reply-To: <1365070223.85.0.365511954484.issue17633@psf.upfronthosting.co.za>
Message-ID: <20160115194013.111036.47896@psf.io>


Roundup Robot added the comment:

New changeset 07a615a8f9ad by Brett Cannon in branch '3.5':
Issue #17633: Improve support for namespace packages with zipimport.
https://hg.python.org/cpython/rev/07a615a8f9ad

New changeset 87f87673af7b by Brett Cannon in branch 'default':
Merge for issue #17633
https://hg.python.org/cpython/rev/87f87673af7b

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 14:45:19 2016
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 15 Jan 2016 19:45:19 +0000
Subject: [issue26128] Let the subprocess.STARTUPINFO constructor take arguments
Message-ID: <1452887119.07.0.716350004713.issue26128@psf.upfronthosting.co.za>


New submission from Ram Rachum:

Right now when you want to use `subprocess.STARTUPINFO`, you need to do something like this: 

    si = subprocess.STARTUPINFO()
    si.dwFlags = subprocess.STARTF_USESTDHANDLES
    subprocess.Popen(['whatever'], startupinfo=si)

It would be much nicer to do this: 

    subprocess.Popen(
        ['whatever'],
        startupinfo=subprocess.STARTUPINFO(
            subprocess.STARTF_USESTDHANDLES
        )
    )

So I suggest that the `STARTUPINFO` constructor take an optional argument that sets the flags on it.

----------
components: Library (Lib), Windows
messages: 258324
nosy: cool-RR, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Let the subprocess.STARTUPINFO constructor take arguments
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 14:48:25 2016
From: report at bugs.python.org (Simon Fraser)
Date: Fri, 15 Jan 2016 19:48:25 +0000
Subject: [issue26129] Difference in behaviour with grp.getgrgid and
 pwd.getpwuid
Message-ID: <1452887305.34.0.0492943983639.issue26129@psf.upfronthosting.co.za>


New submission from Simon Fraser:

grp.getgrgid is capable of accepting a string:

from grp import getgrgid
print(getgrgid('0'))

However, pwd.getpwuid can't do the same:

from pwd import getpwuid
print(getpwuid('0'))

Traceback (most recent call last):
  File "getpwuid_test.py", line 2, in 
    print(getpwuid('0'))
TypeError: an integer is required

This seems to be because inside Modules/pwdmodule.c, getpwuid uses PyNumber_ParseTuple with a converter that uses PyNumber_Index to get a Python integer, and that raises an exception on failure.

However, in Modules/grpmodule.c, grp_getgrgid uses PyNumber_Long (Or PyNumber_Int for an old enough Python) as a conversion first, and as the documentation says at https://docs.python.org/3/c-api/number.html, this is the equivalent of running int(o), which can convert a string to an integer. Only then is it given to PyNumber_Index, by way of a helper function _Py_Gid_Converter

Should these have different behaviours? Is there a reason for the difference?

The behaviour of getgrgid seems more helpful, and it's odd that it doesn't apply to both functions. Is this undesirable behaviour in getgrgid or getpwuid?

----------
components: Library (Lib)
messages: 258325
nosy: SimonFr
priority: normal
severity: normal
status: open
title: Difference in behaviour with grp.getgrgid and pwd.getpwuid
type: behavior
versions: Python 2.7, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 15:36:48 2016
From: report at bugs.python.org (Oren Milman)
Date: Fri, 15 Jan 2016 20:36:48 +0000
Subject: [issue26130] redundant local copy of a char pointer in classify in
 Parser\parser.c
Message-ID: <1452890208.24.0.32779562482.issue26130@psf.upfronthosting.co.za>


New submission from Oren Milman:

In Parser\parser.c in classify, the 'str' parameter is assigned into the local variable 's'. However, 'str' is not used anywhere else in the function, which makes 's' redundant.

My proposal is to simply remove 's', and just use 'str' instead.

The diff is attached.

I played a little with the interpreter, and everything worked as usual.
In addition, I run 'python -m test' (on my 64-bit Windows 10) before and after applying the patch, and got the same output:
354 tests OK.
1 test altered the execution environment:
    test_subprocess
45 tests skipped:
    test_bz2 test_crypt test_curses test_dbm_gnu test_dbm_ndbm
    test_devpoll test_epoll test_fcntl test_fork1 test_gdb test_grp
    test_idle test_ioctl test_kqueue test_lzma test_nis test_openpty
    test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd
    test_readline test_resource test_smtpnet test_socketserver
    test_spwd test_sqlite test_ssl test_syslog test_tcl
    test_threadsignals test_timeout test_tix test_tk test_ttk_guionly
    test_ttk_textonly test_urllib2net test_urllibnet test_wait3
    test_wait4 test_winsound test_xmlrpc_net test_zipfile64

----------
components: Interpreter Core
files: patchDiff.txt
messages: 258326
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: redundant local copy of a char pointer in classify in Parser\parser.c
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41629/patchDiff.txt

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 15:47:24 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 15 Jan 2016 20:47:24 +0000
Subject: [issue26130] redundant local copy of a char pointer in classify in
 Parser\parser.c
In-Reply-To: <1452890208.24.0.32779562482.issue26130@psf.upfronthosting.co.za>
Message-ID: <1452890844.57.0.600561903469.issue26130@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan, yselivanov

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 16:01:41 2016
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Jan 2016 21:01:41 +0000
Subject: [issue26130] redundant local copy of a char pointer in classify in
 Parser\parser.c
In-Reply-To: <1452890208.24.0.32779562482.issue26130@psf.upfronthosting.co.za>
Message-ID: <1452891701.28.0.528122064882.issue26130@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Looks good to me. s was probably left over after a rewrite of the function.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 16:17:27 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 15 Jan 2016 21:17:27 +0000
Subject: [issue24840] implement bool conversion for enums to prevent odd edge
 case
In-Reply-To: <1439251772.85.0.609570031312.issue24840@psf.upfronthosting.co.za>
Message-ID: <1452892647.7.0.867639533631.issue24840@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Mike, my apologies.  In the future I'll make sure and read the docs before I go through with changes.

In the docs (https://www.python.org/dev/peps/pep-0435/#id35):

    The reason for defaulting to 1 as the starting number and
    not 0 is that 0 is False in a boolean sense, but enum members
    all evaluate to True.

>From a newer discussion on Python Ideas and Python Dev:

Barry Warsaw:
    I think in general enums are primarily a symbolic value and don't
    have truthiness.  It's also so easy to override when you define
    the enum that it's not worth changing the current behavior.

Guido van Rossum:
    Honestly I think it's too late to change. The proposal to change
    plain Enums to False when their value is zero (or falsey) would
    be a huge backward incompatibility. I don't think there's a reasonable
    path forward, and also don't think there's a big reason to regret
    the current semantics.

Thank you, Gregory, for catching that.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 16:29:12 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 15 Jan 2016 21:29:12 +0000
Subject: [issue26003] Issues with PyEval_InitThreads and PyGILState_Ensure
In-Reply-To: <1451847866.91.0.926666566382.issue26003@psf.upfronthosting.co.za>
Message-ID: <1452893352.29.0.780257268637.issue26003@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 16:33:11 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Jan 2016 21:33:11 +0000
Subject: [issue25791] Raise an ImportWarning when __spec__.parent/__package__
 isn't defined for a relative import
In-Reply-To: <1449175692.43.0.67090220632.issue25791@psf.upfronthosting.co.za>
Message-ID: <20160115213308.96360.63660@psf.io>


Roundup Robot added the comment:

New changeset 6908b2c9a404 by Brett Cannon in branch 'default':
Issue #25791: Raise an ImportWarning when __spec__ or __package__ are
https://hg.python.org/cpython/rev/6908b2c9a404

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 16:33:44 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Jan 2016 21:33:44 +0000
Subject: [issue25791] Raise an ImportWarning when __spec__.parent/__package__
 isn't defined for a relative import
In-Reply-To: <1449175692.43.0.67090220632.issue25791@psf.upfronthosting.co.za>
Message-ID: <1452893624.67.0.352071686898.issue25791@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the patch, Rose! I did notice your review comments about the missing goto and the stacklevel and I simply added them myself.

----------
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 16:35:04 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Jan 2016 21:35: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: <1452893704.32.0.261920667255.issue21235@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Due to lack of response, I'm assuming all issues are now addressed.

----------
status: pending -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 16:41:08 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Jan 2016 21:41:08 +0000
Subject: [issue21762] update the import machinery to only use __spec__
In-Reply-To: <1402781631.86.0.838758150876.issue21762@psf.upfronthosting.co.za>
Message-ID: <1452894068.54.0.428958762946.issue21762@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So I am going to disagree with Nick about the module attributes and their usefulness (partially because I just made __spec__.parent take precedence over __package__ in issue #25791). While I get the idea of wanting a history of what did (not) change since import, keeping the duplicate information around is annoying. And I don't know how truly useful it is to know what things were compared to what they became.

If we shift to preferring specs compared to module attributes we can then begin to clean up __import__ itself by no longer grabbing the globals() and locals() and instead simply pass in the module's __spec__ object. It also simplifies the documentation such that we don't have to explain everything twice. If people really want to track what a value was relating to import before mutation they can simply store it themselves instead of making us do the bookkeeping for them. It would also make things such as module_from_spec() or loader.create_module() simpler since they only have to worry about setting __spec__ instead of that attribute plus a bunch of other ones.

----------
priority: normal -> low
versions: +Python 3.6 -Python 3.4, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 16:44:04 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Jan 2016 21:44:04 +0000
Subject: [issue26131] Raise ImportWarning when loader.load_module() is used
Message-ID: <1452894244.92.0.478987355259.issue26131@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Since loader.load_module() is documented as deprecated, we should consider raising an ImportWarning when it is used. That way when Python 2.7 support ends we can either remove it or have one more release where the various ImportWarnings turn into DeprecationWarnings and we finally clean up the import semantics to only be spec-based.

----------
components: Interpreter Core
messages: 258333
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Raise ImportWarning when loader.load_module() is used
type: behavior
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 17:24:06 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 15 Jan 2016 22:24:06 +0000
Subject: [issue26123] http.client status code constants incompatible with
 Python 3.4
In-Reply-To: <1452863403.25.0.433090378442.issue26123@psf.upfronthosting.co.za>
Message-ID: <1452896646.49.0.857345647857.issue26123@psf.upfronthosting.co.za>


Martin Panter added the comment:

This affected the HTTP server log messages, discussed from  onwards. The first three patches proposed changed the HTTPStatus.__str__() implementation, which would have avoided the problem in general. But Demian?s final patch made a special case of checking for HTTPStatus objects in the logging code instead.

IMO it may have been better to change HTTPStatus.__str__() to use int.__str__() at the time.

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 17:37:11 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 15 Jan 2016 22:37:11 +0000
Subject: [issue26123] http.client status code constants incompatible with
 Python 3.4
In-Reply-To: <1452863403.25.0.433090378442.issue26123@psf.upfronthosting.co.za>
Message-ID: <1452897431.48.0.595394761075.issue26123@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Not using Enum's __str__ was discussed (I think during the initial Enum threads when PEP435 was being debated) and IIRC Guido was strongly against it as it took away half the purpose of using an Enum.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 17:43:53 2016
From: report at bugs.python.org (Rose Ames)
Date: Fri, 15 Jan 2016 22:43:53 +0000
Subject: [issue18287] PyType_Ready() should sanity-check the tp_name field
In-Reply-To: <1372000372.42.0.425313116494.issue18287@psf.upfronthosting.co.za>
Message-ID: <1452897833.17.0.199232086353.issue18287@psf.upfronthosting.co.za>


Rose Ames added the comment:

There's still no check on tp_name.  The patch looks reasonable, applies cleanly, compiles, and doesn't break any tests - suggest it be merged.

----------
nosy: +superluser

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 17:49:23 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 15 Jan 2016 22:49:23 +0000
Subject: [issue26094] ConfigParser.get() doc to be updated according to the
 configparser.py header doc
In-Reply-To: <1452645599.68.0.959713633048.issue26094@psf.upfronthosting.co.za>
Message-ID: <1452898163.06.0.737650473001.issue26094@psf.upfronthosting.co.za>


Martin Panter added the comment:

Perhaps the doc string of the module should be condensed into a much shorter summary of the class and its methods, and the details should be moved to individual doc strings and the main documentation.

----------
nosy: +martin.panter
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 18:03:03 2016
From: report at bugs.python.org (Bernie Hackett)
Date: Fri, 15 Jan 2016 23:03:03 +0000
Subject: [issue24832] Issue building viewable docs with newer sphinx (default
 theme -> classic)
In-Reply-To: <1439052495.87.0.415280083267.issue24832@psf.upfronthosting.co.za>
Message-ID: <1452898983.66.0.324524000933.issue24832@psf.upfronthosting.co.za>


Bernie Hackett added the comment:

We had the same problem with PyMongo's docs. The issue happens with Sphinx 1.3.0 and 1.3.1. It appears to be resolved in 1.3.2. The changelog includes this line (no issue number is mentioned):

Add a ?default.css? stylesheet (which imports ?classic.css?) for compatibility.

http://www.sphinx-doc.org/en/stable/changes.html#release-1-3-2-released-nov-29-2015

----------
nosy: +behackett

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 18:05:47 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 15 Jan 2016 23:05:47 +0000
Subject: [issue24840] implement bool conversion for enums to prevent odd edge
 case
In-Reply-To: <1439251772.85.0.609570031312.issue24840@psf.upfronthosting.co.za>
Message-ID: <1452899147.68.0.794952157608.issue24840@psf.upfronthosting.co.za>


Ethan Furman added the comment:

New changeset: 52dc28ee3c88

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 18:18:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Jan 2016 23:18:00 +0000
Subject: [issue24840] implement bool conversion for enums to prevent odd edge
 case
In-Reply-To: <1439251772.85.0.609570031312.issue24840@psf.upfronthosting.co.za>
Message-ID: <1452899880.26.0.0150921305921.issue24840@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think it is better to use "value" instead of "_value_" in the documentation.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 18:51:24 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Jan 2016 23:51:24 +0000
Subject: [issue25668] Deadlock in logging caused by a possible race condition
 with "format"
In-Reply-To: <1447942973.46.0.788007678714.issue25668@psf.upfronthosting.co.za>
Message-ID: <1452901884.27.0.446581469174.issue25668@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 19:13:57 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 00:13:57 +0000
Subject: [issue13743] xml.dom.minidom.Document class is not documented
In-Reply-To: <1326114378.06.0.424770823698.issue13743@psf.upfronthosting.co.za>
Message-ID: <1452903237.62.0.150085089632.issue13743@psf.upfronthosting.co.za>


Martin Panter added the comment:

In xml.dom, the documentation suggests that there are classes called Document and others, and I was surprised to find that they don?t exist. Apparently they are more like pseudo-code names of abstract interfaces instead. However in xml.dom.minidom there is a real Python class called Document. The documentation should be clearer about this.

I don?t think we need to duplicate the descriptions already given in xml.dom. But it would be good to explicitly say what the public minidom classes are, and point out (or link) what APIs they support.

----------
components: +XML
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 19:22:42 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 00:22:42 +0000
Subject: [issue9371] pulldom doesn't provide END_DOCUMENT or COMMENT nodes.
In-Reply-To: <1279976512.14.0.00983593867016.issue9371@psf.upfronthosting.co.za>
Message-ID: <1452903762.8.0.567224309438.issue9371@psf.upfronthosting.co.za>


Changes by Martin Panter :


----------
stage:  -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 19:30:52 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 00:30:52 +0000
Subject: [issue9372] pulldom.DOMEventStream.__getitem__ is broken
In-Reply-To: <1279976693.98.0.219854761696.issue9372@psf.upfronthosting.co.za>
Message-ID: <1452904252.76.0.757366394035.issue9372@psf.upfronthosting.co.za>


Martin Panter added the comment:

Left a review

----------
nosy: +martin.panter
stage: test needed -> patch review
versions: +Python 3.6 -Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 19:44:53 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 00:44:53 +0000
Subject: [issue5166] ElementTree and minidom don't prevent creation of not
 well-formed XML
In-Reply-To: <1233918825.25.0.360851750395.issue5166@psf.upfronthosting.co.za>
Message-ID: <1452905093.95.0.127923544607.issue5166@psf.upfronthosting.co.za>


Martin Panter added the comment:

Issue 12129 is open about this sort of problem with xml.dom (which would also apply to minidom I think).

If someone wants to suggest a clarification for the Element Tree documentation, that might work. But I tend to agree about not bogging down the implementation.

----------
dependencies: +Document Object Model API - validation

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 19:57:27 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 00:57:27 +0000
Subject: [issue12129] Document Object Model API - validation
In-Reply-To: <1305928931.2.0.716148568641.issue12129@psf.upfronthosting.co.za>
Message-ID: <1452905847.8.0.528910497436.issue12129@psf.upfronthosting.co.za>


Martin Panter added the comment:

My limited understanding is that xml.dom and minidom are supposed to implement particular interfaces. So do these DOM interfaces specify if this validation should be done? If so, this would be a bug. Or is it just a question of whether Python should do extra validation not specified by the underlying DOM API?

----------
components: +XML -Library (Lib)
nosy: +martin.panter
stage: test needed -> 
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 20:06:25 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 01:06:25 +0000
Subject: [issue13551] pulldom.PullDOM doesn't populate DOM tree
In-Reply-To: <1323304899.35.0.878509919082.issue13551@psf.upfronthosting.co.za>
Message-ID: <1452906385.11.0.790926834118.issue13551@psf.upfronthosting.co.za>


Martin Panter added the comment:

Achim: where did you see your quote about the purpose of PullDOM? Neither  nor  even mention the word ?selected?.

In Issue 9453 it was suggested to deprecate SAX2DOM due to being undocumented and quirky. Do you think we could do the same for PullDOM, or do you think it is useful?

----------
nosy: +martin.panter
title: pulldom doesn't populate DOM tree -> pulldom.PullDOM doesn't populate DOM tree

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 20:37:37 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 01:37:37 +0000
Subject: [issue26130] redundant local copy of a char pointer in classify in
 Parser\parser.c
In-Reply-To: <1452890208.24.0.32779562482.issue26130@psf.upfronthosting.co.za>
Message-ID: <1452908257.36.0.445312258276.issue26130@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes it looks like this is code left over from removing the ?register? keyword in revision 0530aadff696, Issue 18722. I quickly looked over the changes in that revision. I couldn?t find any more clear redundancies.

I guess this patch is also applicable to 3.5.

Maybe the following comments and copies are not needed either. But these cases look like heavily optimized code, so I would be careful with them:

https://hg.python.org/cpython/file/4b1bca0b560f/Objects/stringlib/codecs.h#l40
https://hg.python.org/cpython/file/4b1bca0b560f/Objects/stringlib/codecs.h#l519
https://hg.python.org/cpython/file/4b1bca0b560f/Objects/stringlib/find_max_char.h#l26
https://hg.python.org/cpython/file/4b1bca0b560f/Objects/unicodeobject.c#l4794
https://hg.python.org/cpython/file/4b1bca0b560f/Objects/unicodeobject.c#l4819

The last two have mangled comments /* Help allocation */, which previously read /* Help register allocation */.

----------
nosy: +martin.panter
stage:  -> patch review
versions: +Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 20:50:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 01:50:54 +0000
Subject: [issue24832] Issue building viewable docs with newer sphinx (default
 theme -> classic)
In-Reply-To: <1439052495.87.0.415280083267.issue24832@psf.upfronthosting.co.za>
Message-ID: <1452909054.95.0.49492303585.issue24832@psf.upfronthosting.co.za>


Martin Panter added the comment:

After upgrading from 1.3.1 to 1.3.4, I no longer get the warning. Perhaps we can close this now?

----------
nosy: +martin.panter
resolution:  -> third party

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 20:51:24 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 01:51:24 +0000
Subject: [issue26130] redundant local copy of a char pointer in classify in
 Parser\parser.c
In-Reply-To: <1452890208.24.0.32779562482.issue26130@psf.upfronthosting.co.za>
Message-ID: <1452909084.8.0.406130144952.issue26130@psf.upfronthosting.co.za>


Martin Panter added the comment:

Sorry, the revision removing ?register? is e7f6cef7a4cc. Not sure what happened there.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 21:00:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 02:00:35 +0000
Subject: [issue24421] Race condition compiling Modules/_math.c
In-Reply-To: <1433923600.68.0.73894537311.issue24421@psf.upfronthosting.co.za>
Message-ID: <1452909635.61.0.954385128584.issue24421@psf.upfronthosting.co.za>


Martin Panter added the comment:

I am inclined to try committing my second patch to 3.6, as the race condition keeps bugging me every now and again.

My biggest worry is that it may not work on Windows. I assume Windows does not use the Makefile, but does use setup.py. In the worst case, perhaps I could add conditional code to restore the original setup.py parameters for Windows.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 22:36:27 2016
From: report at bugs.python.org (Paul Hammant)
Date: Sat, 16 Jan 2016 03:36:27 +0000
Subject: [issue26119] Windows Installer can sometimes silently fail pip stage
In-Reply-To: <1452830051.37.0.928414799264.issue26119@psf.upfronthosting.co.za>
Message-ID: <1452915387.36.0.738447414682.issue26119@psf.upfronthosting.co.za>


Paul Hammant added the comment:

Steve, if you want I can attempt to reproduce this. Maybe I'll take a video of the reproduction.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 23:09:45 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 04:09:45 +0000
Subject: [issue25234] test_eintr.test_os_open hangs under Xcode 7
In-Reply-To: <1443210079.4.0.780575467942.issue25234@psf.upfronthosting.co.za>
Message-ID: <1452917385.7.0.642241914391.issue25234@psf.upfronthosting.co.za>


Martin Panter added the comment:

Brett, do you think you should also skip test_open()? The same buildbot recently failed again in that method.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 23:27:32 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 04:27:32 +0000
Subject: [issue25940] SSL tests failed due to expired svn.python.org SSL
 certificate
In-Reply-To: <1450990066.48.0.77725045299.issue25940@psf.upfronthosting.co.za>
Message-ID: <1452918452.12.0.719292948828.issue25940@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is an updated version of my local server patch. I merged it with the committed changes, and fixed a couple of mistakes. This patch does not need to be applied to the older branches.

----------
priority: release blocker -> normal
Added file: http://bugs.python.org/file41630/local-server.v3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 23:40:57 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 04:40:57 +0000
Subject: [issue26119] Windows Installer can sometimes silently fail pip stage
In-Reply-To: <1452830051.37.0.928414799264.issue26119@psf.upfronthosting.co.za>
Message-ID: <1452919257.2.0.660813107808.issue26119@psf.upfronthosting.co.za>


Steve Dower added the comment:

The log files will be sufficient. You'll find them in your %TEMP% directory - there'll be around 20 text files, so put them in a zip and upload them here.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 23:43:41 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 16 Jan 2016 04:43:41 +0000
Subject: [issue25791] Raise an ImportWarning when __spec__.parent/__package__
 isn't defined for a relative import
In-Reply-To: <1449175692.43.0.67090220632.issue25791@psf.upfronthosting.co.za>
Message-ID: <1452919421.83.0.618841041572.issue25791@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Favouring __spec__.parent over __package__ will break the documented workaround in PEP 366 for enabling explicit relative imports from __main__ even when a module is run directly instead of via -m:

    if __name__ == "__main__" and __package__ is None:
        __package__ = "expected.package.name"

It may be that workaround is something we *want* to break (as per http://bugs.python.org/issue21762#msg258332 ), but if so, it's at least worthy of a porting note in the What's New document.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 23:48:37 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jan 2016 04:48:37 +0000
Subject: [issue26127] Broken link in docs for tokenize
In-Reply-To: <1452884211.95.0.164669159709.issue26127@psf.upfronthosting.co.za>
Message-ID: <20160116044834.121286.48099@psf.io>


Roundup Robot added the comment:

New changeset 4b4dbc90c6a0 by Martin Panter in branch '3.5':
Issue #26127: Fix links in tokenize documentation; patch by Silent Ghost
https://hg.python.org/cpython/rev/4b4dbc90c6a0

New changeset fe360700d1ae by Martin Panter in branch 'default':
Issue #26127: Merge tokenize documentation
https://hg.python.org/cpython/rev/fe360700d1ae

New changeset 8b09d71fbb6b by Martin Panter in branch '2.7':
Issue #26127: Fix links in tokenize documentation
https://hg.python.org/cpython/rev/8b09d71fbb6b

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 23:50:14 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 04:50:14 +0000
Subject: [issue26127] Broken link in docs for tokenize
In-Reply-To: <1452884211.95.0.164669159709.issue26127@psf.upfronthosting.co.za>
Message-ID: <1452919814.03.0.721511544894.issue26127@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the report and patch. There were similar (but different) problems in the Python 2 documentation too.

----------
nosy: +martin.panter
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 23:52:12 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 16 Jan 2016 04:52:12 +0000
Subject: [issue21762] update the import machinery to only use __spec__
In-Reply-To: <1402781631.86.0.838758150876.issue21762@psf.upfronthosting.co.za>
Message-ID: <1452919932.74.0.634140737566.issue21762@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

My concern is more about backwards compatibility - at the moment, you can alter the behaviour of import, pickle, and other subsystems by modifying the module level attributes, and if we switch to preferring the __spec__ attributes, then that kind of code will break (I added an import specific example related to __main__ module relative imports to the linked issue).

That's not to say it shouldn't be done - as you say, it would be nice to eventually get to a point where the import system only needs access to the module spec and not to the runtime state, and there are also cases where the __spec__ information will be more correct (e.g. pickling objects in __main__).

However, it needs to be in such a way that there are appropriate porting notes that explain to people why their state mutations stopped having the desired effect, and what (if anything) they can do instead.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 00:21:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jan 2016 05:21:42 +0000
Subject: [issue26127] Broken link in docs for tokenize
In-Reply-To: <1452884211.95.0.164669159709.issue26127@psf.upfronthosting.co.za>
Message-ID: <20160116052139.94208.5626@psf.io>


Roundup Robot added the comment:

New changeset 620a37dbc686 by Martin Panter in branch 'default':
Issue #26127: Merge test_gdb fix from 3.5
https://hg.python.org/cpython/rev/620a37dbc686

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 00:21:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jan 2016 05:21:43 +0000
Subject: [issue14771] Occasional failure in test_ioctl when run parallel with
 test_gdb
In-Reply-To: <1336673953.31.0.37144571556.issue14771@psf.upfronthosting.co.za>
Message-ID: <20160116052139.94208.83754@psf.io>


Roundup Robot added the comment:

New changeset 8b8ac7adbf49 by Martin Panter in branch '2.7':
Issue #14771: Redirect GDB's stdin to avoid messing the terminal settings
https://hg.python.org/cpython/rev/8b8ac7adbf49

New changeset c87cc05af8e7 by Martin Panter in branch '3.5':
Issue #14771: Redirect GDB's stdin to avoid messing the terminal settings
https://hg.python.org/cpython/rev/c87cc05af8e7

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 00:23:21 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 05:23:21 +0000
Subject: [issue26127] Broken link in docs for tokenize
In-Reply-To: <1452884211.95.0.164669159709.issue26127@psf.upfronthosting.co.za>
Message-ID: <1452921801.96.0.685939050093.issue26127@psf.upfronthosting.co.za>


Martin Panter added the comment:

Oops that last commit was for Issue #14771

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 00:24:04 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 05:24:04 +0000
Subject: [issue14771] Occasional failure in test_ioctl when run parallel with
 test_gdb
In-Reply-To: <1336673953.31.0.37144571556.issue14771@psf.upfronthosting.co.za>
Message-ID: <1452921844.51.0.273148142751.issue14771@psf.upfronthosting.co.za>


Changes by Martin Panter :


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 00:41:10 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Jan 2016 05:41:10 +0000
Subject: [issue24832] Issue building viewable docs with newer sphinx (default
 theme -> classic)
In-Reply-To: <1439052495.87.0.415280083267.issue24832@psf.upfronthosting.co.za>
Message-ID: <1452922870.72.0.587412030803.issue24832@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

We build happily with 1.3.3 on docs.python.org, so looks like everything is okay.

----------
resolution: third party -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 00:46:17 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jan 2016 05:46:17 +0000
Subject: [issue26035] traceback.print_tb() takes `tb`,
 not `traceback` as a keyword argument
In-Reply-To: <1452142055.04.0.968906484949.issue26035@psf.upfronthosting.co.za>
Message-ID: <20160116054614.96372.58022@psf.io>


Roundup Robot added the comment:

New changeset e40f6c3dc114 by Senthil Kumaran in branch '3.5':
Issue26035 - Correct the argument names used in the docs of the traceback module. Make it consistent with module args.
https://hg.python.org/cpython/rev/e40f6c3dc114

New changeset e96c1491896d by Senthil Kumaran in branch 'default':
Merge from 3.5
https://hg.python.org/cpython/rev/e96c1491896d

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 01:07:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Jan 2016 06:07:19 +0000
Subject: [issue9372] pulldom.DOMEventStream.__getitem__ is broken
In-Reply-To: <1279976693.98.0.219854761696.issue9372@psf.upfronthosting.co.za>
Message-ID: <1452924439.38.0.714367030102.issue9372@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Similar outdated __getitem__ left in wsgiref.util.FileWrapper and fileinput.FileInput.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 01:13:24 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jan 2016 06:13:24 +0000
Subject: [issue26035] traceback.print_tb() takes `tb`,
 not `traceback` as a keyword argument
In-Reply-To: <1452142055.04.0.968906484949.issue26035@psf.upfronthosting.co.za>
Message-ID: <20160116061321.94196.36841@psf.io>


Roundup Robot added the comment:

New changeset daff4ced1b32 by Senthil Kumaran in branch '2.7':
Issue26035 - Correct the argument names used in the docs of the traceback module. Make it consistent with module args.
https://hg.python.org/cpython/rev/daff4ced1b32

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 01:14:51 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 16 Jan 2016 06:14:51 +0000
Subject: [issue26035] traceback.print_tb() takes `tb`,
 not `traceback` as a keyword argument
In-Reply-To: <1452142055.04.0.968906484949.issue26035@psf.upfronthosting.co.za>
Message-ID: <1452924891.63.0.946944989159.issue26035@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the patch, Upendra Kumar. It's fixed now. Appreciate your taking care of other args and making the change meaningful.

----------
assignee: docs at python -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 02:33:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 07:33:00 +0000
Subject: [issue23883] __all__ lists are incomplete
In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za>
Message-ID: <1452929580.33.0.170757505821.issue23883@psf.upfronthosting.co.za>


Martin Panter added the comment:

I committed the last three patches to 3.6:

571632315c36: fileinput
a2ffa9eedb1b: calendar
48090e08e367: tarfile
a5d3ebb6ad2a: Update news

Please let me know if there are some outstanding patches here that I missed. Otherwise, I think we are up to step 6 in .

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 02:39:25 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jan 2016 07:39:25 +0000
Subject: [issue23883] __all__ lists are incomplete
In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za>
Message-ID: <20160116073922.94224.17394@psf.io>


Roundup Robot added the comment:

New changeset 571632315c36 by Martin Panter in branch 'default':
Issue #23883: Missing fileinput.__all__ APIs; patch by Mauro SM Rodrigues
https://hg.python.org/cpython/rev/571632315c36

New changeset a2ffa9eedb1b by Martin Panter in branch 'default':
Issue #23883: Add missing APIs to calendar.__all__
https://hg.python.org/cpython/rev/a2ffa9eedb1b

New changeset 48090e08e367 by Martin Panter in branch 'default':
Issue #23883: Add missing APIs to tarfile.__all__
https://hg.python.org/cpython/rev/48090e08e367

New changeset a5d3ebb6ad2a by Martin Panter in branch 'default':
Issue #23883: Update news
https://hg.python.org/cpython/rev/a5d3ebb6ad2a

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 02:57:21 2016
From: report at bugs.python.org (Mark Summerfield)
Date: Sat, 16 Jan 2016 07:57:21 +0000
Subject: [issue26126] Possible subtle bug when normalizing and
 str.translate()ing
In-Reply-To: <1452881090.74.0.501338365474.issue26126@psf.upfronthosting.co.za>
Message-ID: <1452931041.75.0.463900828417.issue26126@psf.upfronthosting.co.za>


Mark Summerfield added the comment:

Thanks for looking at this. In my full translation dict I had some other mistakes of case, now all fixed:-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 03:18:48 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 16 Jan 2016 08:18:48 +0000
Subject: [issue25458] ftplib: command response shift - mismatch
In-Reply-To: <1445510152.74.0.829316001802.issue25458@psf.upfronthosting.co.za>
Message-ID: <1452932328.57.0.846654245494.issue25458@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +giampaolo.rodola
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 03:28:31 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 16 Jan 2016 08:28:31 +0000
Subject: [issue24905] Allow incremental I/O to blobs in sqlite3
In-Reply-To: <1440144321.97.0.0781853247945.issue24905@psf.upfronthosting.co.za>
Message-ID: <1452932911.96.0.154790413849.issue24905@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
components: +Extension Modules
nosy: +ghaering

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 04:05:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jan 2016 09:05:48 +0000
Subject: [issue23883] __all__ lists are incomplete
In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za>
Message-ID: <20160116090544.94224.52641@psf.io>


Roundup Robot added the comment:

New changeset 62e925be0aff by Serhiy Storchaka in branch 'default':
Issue #23883: Removed redundant names from blacklists.
https://hg.python.org/cpython/rev/62e925be0aff

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 04:13:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Jan 2016 09:13:13 +0000
Subject: [issue23883] __all__ lists are incomplete
In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za>
Message-ID: <1452935593.94.0.938079109587.issue23883@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks for caring for this Martin.

> Should we add anything into What's New, maybe warning of new symbols from "import *"?

I think yes.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 04:25:03 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Jan 2016 09:25:03 +0000
Subject: [issue26059] Integer Overflow in strop.replace()
In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za>
Message-ID: <1452936303.57.0.741244403263.issue26059@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Win 10, 2.7.11, from IDLE editor: 1.py take several seconds, nothing printed.  Add 'print' in front of call and 
Traceback (most recent call last):
  File "F:\Python\mypy\tem.py", line 3, in 
    print strop.replace("\x100"*0xEAAA,"\x100","AA"*0xAAAA)
  File "C:\Programs\Python27\lib\idlelib\PyShell.py", line 1356, in write
    return self.shell.write(s, self.tags)
MemoryError

strop gone in 3.5.

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 04:37:58 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Jan 2016 09:37:58 +0000
Subject: [issue26077] Make slicing of immutable structures return a view
 instead of a copy
In-Reply-To: <1452458756.3.0.749991798075.issue26077@psf.upfronthosting.co.za>
Message-ID: <1452937078.91.0.0608387991274.issue26077@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Proposals for strings views have be rejected precisely because of the keep-alive effect.

I do not remember if tuples were explicitly part of earlier discussions. One could make the argument that million-item tuples, and especially slicing thereof is rarer than the same for strings.  On the other hand, copying short slices of short to medium tuples is not a big deal.

Because of previous discussions, I think this issue should be either closed or suspended for python-ideas discussion.

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 04:42:26 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Jan 2016 09:42:26 +0000
Subject: [issue13743] xml.dom.minidom.Document class is not documented
In-Reply-To: <1326114378.06.0.424770823698.issue13743@psf.upfronthosting.co.za>
Message-ID: <1452937346.63.0.914009939192.issue13743@psf.upfronthosting.co.za>


Changes by Mark Lawrence :


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 04:48:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Jan 2016 09:48:53 +0000
Subject: [issue26077] Make slicing of immutable structures return a view
 instead of a copy
In-Reply-To: <1452458756.3.0.749991798075.issue26077@psf.upfronthosting.co.za>
Message-ID: <1452937733.4.0.592681726716.issue26077@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The support of sharing a content between different tuples requires changing the structure of the tuple object, allocating additional block for every tuple, adding a level of indirection and reference counting. This will increase memory consumption, creating and access time for all tuples. All this is critically important for Python interpreter. I think this idea has no a chance.

----------
nosy: +serhiy.storchaka
resolution:  -> rejected
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 04:52:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Jan 2016 09:52:27 +0000
Subject: [issue26059] Integer Overflow in strop.replace()
In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za>
Message-ID: <1452937947.84.0.710353470571.issue26059@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Are you sure that you use 2.7.11 Ramin?

Can anyone else confirm the issue?

----------
status: open -> pending

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 05:08:51 2016
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 16 Jan 2016 10:08:51 +0000
Subject: [issue22995] Restrict default pickleability
In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za>
Message-ID: <1452938931.92.0.726900717396.issue22995@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

For reference, the bug in Cython is fixed here:

https://github.com/cython/cython/commit/ececb3e9473f6aaa65f29467921594c316ec2f06

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 05:13:37 2016
From: report at bugs.python.org (Campbell Barton)
Date: Sat, 16 Jan 2016 10:13:37 +0000
Subject: [issue25911] Regression: os.walk now using os.scandir() breaks bytes
 filenames on windows
In-Reply-To: <1450539578.39.0.976654454489.issue25911@psf.upfronthosting.co.za>
Message-ID: <1452939217.93.0.506697785174.issue25911@psf.upfronthosting.co.za>


Campbell Barton added the comment:

A related question, (realize this isn't a support forum), but what is the equivalent API calls in Python3.5 so we can update scripts.

Should we be doing: os.walk(os.fsdecode(path)) ?

>From Python's documentation, os.fsdecode is using 'strict' handler which may raise exceptions.
I'm mainly concerned that changes here will introduce bugs where bytes previously resolved the paths (albeit working in an imperfect way).

If this is not the best place to ask about this, then can post elsewhere.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 05:24:57 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 16 Jan 2016 10:24:57 +0000
Subject: [issue26053] regression in pdb output between 2.7 and 3.5
In-Reply-To: <1452296621.32.0.373600761217.issue26053@psf.upfronthosting.co.za>
Message-ID: <1452939897.91.0.701220342824.issue26053@psf.upfronthosting.co.za>


Changes by Xavier de Gaye :


----------
nosy: +xdegaye

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 05:28:31 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 16 Jan 2016 10:28:31 +0000
Subject: [issue26072] pdb fails to access variables closed over
In-Reply-To: <1452402984.12.0.000738362264887.issue26072@psf.upfronthosting.co.za>
Message-ID: <1452940111.42.0.89696855901.issue26072@psf.upfronthosting.co.za>


Changes by Xavier de Gaye :


----------
nosy: +xdegaye

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 05:29:48 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Jan 2016 10:29:48 +0000
Subject: [issue26085] Tkinter spoils the input text
In-Reply-To: <1452546756.92.0.853539899898.issue26085@psf.upfronthosting.co.za>
Message-ID: <1452940188.87.0.197978315503.issue26085@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

You should have uploaded your .py file.  Mine is attached, with fix added.  Anyway, confirmed with 3.5.1, Win10.  Slightly more bizarre than described, in that misspelling disappears on even insertion and reappears in odd insertion.

this worsk
this worksthis works
this worksthis worksthis worsk

Even stranger, printing the txt to Shell after the insertion shows the opposite parity.

this works
this worksthis worsk
this worksthis worksthis works

Binding to another key removes the problem.  By experiment, ^t in Text means 'transpose chars to left and right of cursor and move cursor right' or equivalently, 'move char to right before the one on left'.  So 'abc|def' becomes 'abdc|ef' (where '|' here represents the cursor, not a character.  The exception is that at the end of the text, the two chars to the left are transposed, so that 'abc|' becomes 'acb|'.

Tk.bind has an 'add' parameter that defaults to None, which should mean 'replace previous bindings'.  But I suspect that this only applies to user-added bindings, so not replacing a default Text binding is not considered a bug.

Serhiy, am I correct here or is this a tk or tkinter bug?

In fact, it seems that this default binding cannot be unbound.  Adding 'txt.unbind('') did not work.  Adding "return 'break'" at the end of the callback does work.

Bottom line: make sure that you bind to an unused sequence or add the return to disable any unused binding you do not know about.

Our doc is deficient, but correcting that is beyond the scope of this issue.  Unless I have missed something, this should be closed as 'not a bug'.

----------
nosy: +serhiy.storchaka, terry.reedy
versions: +Python 3.5 -Python 3.4
Added file: http://bugs.python.org/file41631/tem.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 05:37:06 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Jan 2016 10:37:06 +0000
Subject: [issue26086] Bug in os module
In-Reply-To: <1452548126.01.0.956593686661.issue26086@psf.upfronthosting.co.za>
Message-ID: <1452940626.15.0.934940503547.issue26086@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Hana, when responding, please delete the quoted previous message.  On the web page, your response directly follows that messages, so the quotation is redundant and annoying.

Please write and either copy into a message or upload a **minimum** program that shows the error -- one that we can quickly read and test.  Also copy the first line that appears in an interactive shell, the one that looks like "Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 bit (AMD64)] on win32"

----------
nosy: +terry.reedy
title: Bug in standardmodule os -> Bug in os module
type: crash -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 06:02:51 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jan 2016 11:02:51 +0000
Subject: [issue23883] __all__ lists are incomplete
In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za>
Message-ID: <20160116110248.25961.82284@psf.io>


Roundup Robot added the comment:

New changeset bd6127a6354f by Martin Panter in branch 'default':
Issue #23883: grp and pwd are None on Windows
https://hg.python.org/cpython/rev/bd6127a6354f

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 06:08:44 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 11:08:44 +0000
Subject: [issue23883] __all__ lists are incomplete
In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za>
Message-ID: <1452942524.79.0.820232184898.issue23883@psf.upfronthosting.co.za>


Martin Panter added the comment:

Serhiy: I already added a bullet point at .

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 06:23:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Jan 2016 11:23:56 +0000
Subject: [issue26085] Tkinter spoils the input text
In-Reply-To: <1452546756.92.0.853539899898.issue26085@psf.upfronthosting.co.za>
Message-ID: <1452943436.51.0.308554053621.issue26085@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I can't reproduce the result with tem.py. If change binding to  and comment out the line "return 'break'" in the callback I can reproduce it.

This is expected and documented (but only in bind() docstring) behavior. If the callback returns 'break', no other functions (including standard handlers) will be invoked for the event. Otherwise the standard handler for  is invoked and it swaps two characters as Terry said.

If doesn't consider this issue as the documentation issue, it should be closed as not a bug.

Here is Terry's example translated to pure Tcl.

----------
Added file: http://bugs.python.org/file41632/tem.tcl

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 06:46:27 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Jan 2016 11:46:27 +0000
Subject: [issue26114] Rewrite math.erf() and math.erfc() from scratch
In-Reply-To: <1452803741.39.0.631242355329.issue26114@psf.upfronthosting.co.za>
Message-ID: <1452944787.9.0.291803625611.issue26114@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Some additional history: the original 1986 book has separate copyright notices for text (Cambridge U Press), and computer programs (Numerical Recipes Software).  It also has an offer to sell diskettes (Fortran or Pascal), 15 pounds each.  There is no additional license statements that I can see, even for the disks.  I vaguely remember that there was some upset or controversy when a 'license' was added to the 2nd edition.

The copyrighted but license-free erf and erfc functions on p. 164) use the incomplete gamma functions, which use continued fractions and series for different subdomains.  Applied Statistics algorithm AS 66 (about 1973), for normal integrals, appears to directly use series and continued fractions for different subdomains.  It is based on a similar algorithm from 1969.  Both series and continued fraction expansions for erf/normal-integral were known well before that.

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 07:02:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Jan 2016 12:02:30 +0000
Subject: [issue22995] Restrict default pickleability
In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za>
Message-ID: <1452945750.98.0.365066893369.issue22995@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Nice.

Did you considered the possibility to implement the pickling compatible with non-accelerated Python classes with __dict__ for every Cython class? I.e. __getstate__ that returns a dict that maps field names to values and __setstate__ that unpacks such dict?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 07:44:45 2016
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 16 Jan 2016 12:44:45 +0000
Subject: [issue22995] Restrict default pickleability
In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za>
Message-ID: <1452948285.86.0.0341368085875.issue22995@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

In fact, I did consider it and I'd love to, but it's not something to do lightly because the semantics would be a bit fuzzy and unsafe. Basically, extension types that have only Python object compatible attributes could automatically pickle, but as soon as you add, say, a C pointer attribute, it would fail to pickle at runtime, maybe even without an error (as in the case at hand). And what do you think, how many users write unit tests for pickling all of their extension types?

Imagine the case that Cython adds automatic pickling support for a base class and a user tries to implement pickling in a subclass, but using a different set of pickle support methods. It might then happen that the user implementation is silently ignored by the pickle implementation because it prefers the methods in the base class. The user might not even notice this because it (mostly) seems to work. And now think of the case where this user code exists already and Cython starts to enable the base class pickle support with a new release and overrides the user implementation. That might lead to seriously difficult to find bugs.

It would be great to make this support the default rather than requiring user interaction (say, a class decorator or compiler directive), but the subtle code breakage cases above sadly suggest otherwise...

Anyway, this needs more thinking and this ticket isn't the right place to do that.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 09:12:42 2016
From: report at bugs.python.org (David Rader)
Date: Sat, 16 Jan 2016 14:12:42 +0000
Subject: [issue26132] 2.7.11 Windows Installer issues on Win2008R2
Message-ID: <1452953562.0.0.729045756058.issue26132@psf.upfronthosting.co.za>


New submission from David Rader:

Problem 1:
The .manifest information for the VC runtime dll's has been changed in the recent versions of the 2.7.x 64-bit installers for Windows. Python fails to run on a clean Win2008R2 install after running the Python installer to install "Just for me". The installation succeeds if "Install for all users" is selected.

After install completes, trying to run python results in:
The application has failed to start because it's side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

The event viewer log shows:
Activation context generation failed for "C:\Python27\python.exe".Error in manifest or policy file "C:\Python27\Microsoft.VC90.CRT.MANIFEST" on line 4. Component identity found in manifest does not match the identity of the component requested. Reference is Microsoft.VC90.CRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8". Definition is Microsoft.VC90.CRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.30729.1". Please use sxstrace.exe for detailed diagnosis.

This means that that VC2008 SP1 dll and manifest are included in the installer, but the Python.exe is compiled against VC2008 (_not_ SP1).
Replacing the installed manifest and VC90 with one pulled from an older distribution with the correct 9.0.21022.8 version enables python to run.

Problem 2:
The compiled DLLs in the DLLs folder incorrectly have the VC manifest included in them as well. This breaks the side-by-side look up, since the VC90 dll is not in the DLLs folder. So if you try to import socket, you get an error message like:
Traceback (most recent call last):
  File "hub\scripts\pgc.py", line 9, in 
    import socket
  File "C:\Python27\lib\socket.py", line 47, in 
    import _socket
ImportError: DLL load failed: The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

Previous versions of Python for windows have had this problem but it was corrected. It looks like it has crept back in.

----------
components: Installation
messages: 258387
nosy: David Rader, benjamin.peterson, loewis
priority: normal
severity: normal
status: open
title: 2.7.11 Windows Installer issues on Win2008R2
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 09:19:15 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 16 Jan 2016 14:19:15 +0000
Subject: [issue26132] 2.7.11 Windows Installer issues on Win2008R2
In-Reply-To: <1452953562.0.0.729045756058.issue26132@psf.upfronthosting.co.za>
Message-ID: <1452953955.99.0.809669254322.issue26132@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 09:45:43 2016
From: report at bugs.python.org (David Rader)
Date: Sat, 16 Jan 2016 14:45:43 +0000
Subject: [issue26132] 2.7.11 Windows Installer issues on Win2008R2
In-Reply-To: <1452953562.0.0.729045756058.issue26132@psf.upfronthosting.co.za>
Message-ID: <1452955543.35.0.827562833565.issue26132@psf.upfronthosting.co.za>


David Rader added the comment:

FYI - as a work around problem 1, after the install I replaced the .manifest file and the VCRT.dll with the older non-SP1 versions and python ran.

Then, to work around problem 2, I used resource hacker to manually delete the manifest from each file in the DLLs directory. these modified versions (without the embedded manifest for VC RT) now work successfully in the side-by-side execution on Win2008R2.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 10:04:48 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 15:04:48 +0000
Subject: [issue26132] 2.7.11 Windows Installer issues on Win2008R2
In-Reply-To: <1452953562.0.0.729045756058.issue26132@psf.upfronthosting.co.za>
Message-ID: <1452956688.55.0.515173597366.issue26132@psf.upfronthosting.co.za>


Steve Dower added the comment:

I'm a little surprised this is the first we've heard of this issue, but the analysis seems sound.

It's probably a misconfiguration on my build machine, or possibly something to do with the project file backport. I'll look into it.

----------
assignee:  -> steve.dower

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 10:15:57 2016
From: report at bugs.python.org (Ramin Farajpour Cami)
Date: Sat, 16 Jan 2016 15:15:57 +0000
Subject: [issue26059] Integer Overflow in strop.replace()
In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za>
Message-ID: <1452957357.91.0.841797929593.issue26059@psf.upfronthosting.co.za>


Ramin Farajpour Cami added the comment:

Yes!I use python version 2.7.11 and my Windows machine stop and crashed, on cmd Windows,

----------
status: pending -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 10:34:25 2016
From: report at bugs.python.org (Ramin Farajpour Cami)
Date: Sat, 16 Jan 2016 15:34:25 +0000
Subject: [issue26059] Integer Overflow in strop.replace()
In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za>
Message-ID: <1452958465.32.0.0952778300585.issue26059@psf.upfronthosting.co.za>


Ramin Farajpour Cami added the comment:

i trust me ,i don't undrestand :( , work for me this print strop.replace("\x100"*0xEAAA,"\x100","AA"*0xAAAA) .

now test again my system machine crash and i restart windows,


my info system :


Host Name:                 DESKTOP-84QSQQ8
OS Name:                   Microsoft Windows 10 Enterprise
OS Version:                10.0.10240 N/A Build 10240
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation
OS Build Type:             Multiprocessor Free
Registered Owner:          RaminFP
Registered Organization:
Product ID:                00329-00000-00003-AA066
Original Install Date:     11/6/2015, 6:12:53 AM
System Boot Time:          1/16/2016, 6:57:16 PM
System Manufacturer:       ASUSTeK Computer Inc.
System Model:              K52DY
System Type:               x64-based PC
Processor(s):              1 Processor(s) Installed.
                           [01]: AMD64 Family 16 Model 5 Stepping 3 AuthenticAMD ~1800 Mhz
BIOS Version:              American Megatrends Inc. K52DY.207, 1/27/2011
Windows Directory:         C:\Windows
System Directory:          C:\Windows\system32
Boot Device:               \Device\HarddiskVolume2
System Locale:             en-us;English (United States)
Input Locale:              en-us;English (United States)
Time Zone:                 (UTC+03:30) Tehran
Total Physical Memory:     4,094 MB
Available Physical Memory: 1,967 MB
Virtual Memory: Max Size:  6,270 MB
Virtual Memory: Available: 4,152 MB
Virtual Memory: In Use:    2,118 MB
Page File Location(s):     C:\pagefile.sys
Domain:                    WORKGROUP
Logon Server:              \\DESKTOP-84QSQQ8
Hotfix(s):                 5 Hotfix(s) Installed.
                           [01]: KB3087040
                           [02]: KB3106932
                           [03]: KB3116869
                           [04]: KB3124266
                           [05]: KB3133431
Network Card(s):           6 NIC(s) Installed.
                           [01]: Qualcomm Atheros AR9002WB-1NG Wireless Network Adapter
                                 Connection Name: Wi-Fi
                                 DHCP Enabled:    Yes
                                 DHCP Server:     192.168.1.1
                                 IP address(es)
                                 [01]: 192.168.1.101
                                 [02]: fe80::1d3d:b7fa:e576:7111
                           [02]: JMicron PCI Express Gigabit Ethernet Adapter
                                 Connection Name: Ethernet
                                 Status:          Hardware not present
                           [03]: Kerio Virtual Network Adapter
                                 Connection Name: Ethernet 5
                                 Status:          Media disconnected
                           [04]: VMware Virtual Ethernet Adapter for VMnet1
                                 Connection Name: Ethernet 2
                                 Status:          Hardware not present
                           [05]: Cisco AnyConnect Secure Mobility Client Virtual Miniport Adapter for Windows x64
                                 Connection Name: Ethernet 6
                                 Status:          Hardware not present
                           [06]: VMware Virtual Ethernet Adapter for VMnet8
                                 Connection Name: Ethernet 3
                                 Status:          Hardware not present
Hyper-V Requirements:      VM Monitor Mode Extensions: Yes
                           Virtualization Enabled In Firmware: Yes
                           Second Level Address Translation: Yes
                           Data Execution Prevention Available: Yes

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 10:48:21 2016
From: report at bugs.python.org (Ramin Farajpour Cami)
Date: Sat, 16 Jan 2016 15:48:21 +0000
Subject: [issue26059] Integer Overflow in strop.replace()
In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za>
Message-ID: <1452959301.79.0.570502702253.issue26059@psf.upfronthosting.co.za>


Ramin Farajpour Cami added the comment:

i test python version 2.7.11 32 bit i get your error , but 64 bit no crashed,


CommandLine: python.exe
Symbol search path is: srv*c:\pubsymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 1c3c0000 1c3cb000   python.exe
ModLoad: 77020000 77199000   ntdll.dll
ModLoad: 76d00000 76df0000   C:\Windows\SysWOW64\KERNEL32.DLL
ModLoad: 76ea0000 77016000   C:\Windows\SysWOW64\KERNELBASE.dll
ModLoad: 5fd70000 5fffe000   C:\Windows\SysWOW64\python27.dll
ModLoad: 71de0000 71e83000   C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.9158_none_5091b51ebcb97cdc\MSVCR90.dll
ModLoad: 76970000 76ab0000   C:\Windows\SysWOW64\USER32.dll
ModLoad: 76140000 7628d000   C:\Windows\SysWOW64\GDI32.dll
ModLoad: 76b10000 76b8b000   C:\Windows\SysWOW64\ADVAPI32.dll
ModLoad: 76c40000 76cfe000   C:\Windows\SysWOW64\msvcrt.dll
ModLoad: 75c20000 75c63000   C:\Windows\SysWOW64\sechost.dll
ModLoad: 76df0000 76e9c000   C:\Windows\SysWOW64\RPCRT4.dll
ModLoad: 74130000 7414e000   C:\Windows\SysWOW64\SspiCli.dll
ModLoad: 74120000 7412a000   C:\Windows\SysWOW64\CRYPTBASE.dll
ModLoad: 740c0000 74119000   C:\Windows\SysWOW64\bcryptPrimitives.dll
ModLoad: 74150000 7550e000   C:\Windows\SysWOW64\SHELL32.dll
ModLoad: 75510000 759ec000   C:\Windows\SysWOW64\windows.storage.dll
ModLoad: 75c80000 75e3a000   C:\Windows\SysWOW64\combase.dll
ModLoad: 76bf0000 76c34000   C:\Windows\SysWOW64\shlwapi.dll
ModLoad: 76290000 7629c000   C:\Windows\SysWOW64\kernel.appcore.dll
ModLoad: 768e0000 7696d000   C:\Windows\SysWOW64\shcore.dll
ModLoad: 76ac0000 76b04000   C:\Windows\SysWOW64\powrprof.dll
ModLoad: 76ab0000 76abf000   C:\Windows\SysWOW64\profapi.dll
ModLoad: 768b0000 768db000   C:\Windows\SysWOW64\IMM32.DLL
ModLoad: 75fb0000 760d0000   C:\Windows\SysWOW64\MSCTF.dll
Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 20:32:19) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import strop
>>> strop.replace("\x100"*0xEAAA,"\x100","AA"*0xAAAA)
Traceback (most recent call last):
  File "", line 1, in 
MemoryError

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 10:51:03 2016
From: report at bugs.python.org (Ramin Farajpour Cami)
Date: Sat, 16 Jan 2016 15:51:03 +0000
Subject: [issue26059] Integer Overflow in strop.replace()
In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za>
Message-ID: <1452959463.84.0.987776875799.issue26059@psf.upfronthosting.co.za>


Ramin Farajpour Cami added the comment:

here version :

C:\python2711>python.exe
Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 20:40:30) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import strop
>>> strop.replace("\x100"*0xEAAA,"\x100","AA"*0xAAAA)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 10:53:18 2016
From: report at bugs.python.org (Ramin Farajpour Cami)
Date: Sat, 16 Jan 2016 15:53:18 +0000
Subject: [issue26059] Integer Overflow in strop.replace()
In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za>
Message-ID: <1452959598.41.0.968599153214.issue26059@psf.upfronthosting.co.za>


Ramin Farajpour Cami added the comment:

i try install windows on VMWare and get video for you, in primary OS i my system crash i can't save video or image for you ,

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 11:20:10 2016
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 16 Jan 2016 16:20:10 +0000
Subject: [issue26132] 2.7.11 Windows Installer issues on Win2008R2
In-Reply-To: <1452953562.0.0.729045756058.issue26132@psf.upfronthosting.co.za>
Message-ID: <1452961210.09.0.182956699557.issue26132@psf.upfronthosting.co.za>


Eryk Sun added the comment:

Steve, is this something that can only be reproduced on Windows 7/2008 for some reason? My "just for me" installation on Windows 10 seems to work fine. I installed from "python-2.7.11.amd64.msi" with the MD5 sum 25acca42662d4b02682eee0df3f3446d, which matches the MD5 sum posted on python.org. 

The resource #1 manifest embedded in python.exe uses the following assembly:

    
    

The resource #2 manifest embedded in python27.dll uses the same assembly. 

However, I can confirm the second problem. The extension modules in DLLs incorrectly have a resource #2 manifest. They should be relying on the activation context from the #2 manifest in python27.dll.

----------
nosy: +eryksun

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 12:17:22 2016
From: report at bugs.python.org (Ramin Farajpour Cami)
Date: Sat, 16 Jan 2016 17:17:22 +0000
Subject: [issue26059] Integer Overflow in strop.replace()
In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za>
Message-ID: <1452964642.45.0.614029789155.issue26059@psf.upfronthosting.co.za>


Ramin Farajpour Cami added the comment:

also work it , windows 7 OS 64bit with python 2.7.11 64bit,

this is a vulnerability in python 2.7.11 64bit version,

please look video,

https://drive.google.com/file/d/0B0zktfkIvV-LajlIQ0p0eWZjd0U/view

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 12:51:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Jan 2016 17:51:07 +0000
Subject: [issue9006] xml-rpc Server object does not propagate the encoding to
 Unmarshaller
In-Reply-To: <1276680036.39.0.0895862907842.issue9006@psf.upfronthosting.co.za>
Message-ID: <1452966667.81.0.179850764888.issue9006@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

xmlrpc uses XML. This format includes information about the encoding and doesn't need external specification.

The server in the example is not correct. It generates XML with default XML declaration that implies the UTF-8 encoding, but the body is encoded with non-UTF-8 encoding. If add the argument encoding='UTF-8' the example works.

But this feature is not covered by tests. Proposed patch adds tests for non-default client and server encodings. No changes for the xmlrpc module itself is needed.

----------
assignee:  -> serhiy.storchaka
components: +Tests
keywords: +patch
nosy: +serhiy.storchaka
stage:  -> patch review
type: behavior -> enhancement
versions: +Python 3.5, Python 3.6 -Python 3.1, Python 3.2
Added file: http://bugs.python.org/file41633/test_xmlrpc_encoding-2.7.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 12:51:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Jan 2016 17:51:24 +0000
Subject: [issue9006] xml-rpc Server object does not propagate the encoding to
 Unmarshaller
In-Reply-To: <1276680036.39.0.0895862907842.issue9006@psf.upfronthosting.co.za>
Message-ID: <1452966684.71.0.340635500966.issue9006@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file41634/test_xmlrpc_encoding-3.5.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 13:14:14 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 16 Jan 2016 18:14:14 +0000
Subject: [issue21762] update the import machinery to only use __spec__
In-Reply-To: <1402781631.86.0.838758150876.issue21762@psf.upfronthosting.co.za>
Message-ID: <1452968054.75.0.447296761841.issue21762@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I totally agree proper notes in the What's New doc need to be in place to explain that people need to update.

How about I tweak the __package__ change to continue to prefer __package__ over __spec__.parent, but raise an ImportWarning when they differ? It can also fall back to __spec__.parent if __package__ isn't defined and simply not worry about the lack of __package__? Then we can do an ImportWarning for all of the other attributes when we discover a difference so people have time to migrate to updating both locations, and then eventually we can invert the priority and then after that drop the module attributes.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 13:15:34 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 16 Jan 2016 18:15:34 +0000
Subject: [issue25234] test_eintr.test_os_open hangs under Xcode 7
In-Reply-To: <1443210079.4.0.780575467942.issue25234@psf.upfronthosting.co.za>
Message-ID: <1452968134.94.0.602767615794.issue25234@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Sure, that test can be skipped as well if it is hanging.

----------
status: closed -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 13:18:45 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 16 Jan 2016 18:18:45 +0000
Subject: [issue25791] Raise an ImportWarning when __spec__.parent/__package__
 isn't defined for a relative import
In-Reply-To: <1449175692.43.0.67090220632.issue25791@psf.upfronthosting.co.za>
Message-ID: <1452968325.94.0.0534199112134.issue25791@psf.upfronthosting.co.za>


Brett Cannon added the comment:

As I commented on another issue, I think I'm going to tweak the change to continue to prefer __package__, but raise ImportWarning when it doesn't match __spec__.parent. Once we do that for all attributes we can wait until Python 2.7 is done and then swap priority to __spec__ and raise a DeprecationWarning if __spec__ is missing. That way post-Python 2.7 we can move entirely to a spec-based import system.

----------
status: closed -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 13:46:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Jan 2016 18:46:38 +0000
Subject: [issue26049] Poor performance when reading large xmlrpc data
In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za>
Message-ID: <1452969998.22.0.00525193051696.issue26049@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
stage:  -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 14:06:06 2016
From: report at bugs.python.org (Alex Brandt)
Date: Sat, 16 Jan 2016 19:06:06 +0000
Subject: [issue26133] TypeError: signal handler must be signal.SIG_IGN,
 signal.SIG_DFL,
 or a callable object in >
Message-ID: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za>


New submission from Alex Brandt:

When using the suggested practice of setting a stop loop signal handler with:

loop.add_signal_handler(signal.SIGTERM, loop.stop)

The following stack trace is given when the signal runs:

ligament_1 | Exception ignored in: >
ligament_1 | Traceback (most recent call last):
ligament_1 |   File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in __del__
ligament_1 |   File "/usr/lib/python3.5/asyncio/unix_events.py", line 58, in close
ligament_1 |   File "/usr/lib/python3.5/asyncio/unix_events.py", line 139, in remove_signal_handler
ligament_1 |   File "/usr/lib/python3.5/signal.py", line 47, in signal
ligament_1 | TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, or a callable object

Since this happens during shutdown of the application I wouldn't consider this a high priority bug but it is quite annoying.  I've also not investigated if this interrupts the loop stopping procedure yet.

----------
components: asyncio
messages: 258401
nosy: Alex Brandt, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, or a callable object in >
type: crash
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 14:44:28 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 16 Jan 2016 19:44:28 +0000
Subject: [issue26133] TypeError: signal handler must be signal.SIG_IGN,
 signal.SIG_DFL,
 or a callable object in >
In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za>
Message-ID: <1452973468.37.0.985449682779.issue26133@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Heh, this is weird. If the signal being removed is SIGTERM, the logic looks like it is definitely going to call signal.signal(signal.SIGTERM, signal.SIG_DFL). And it doesn't look like the signal module's globals have been eradicated yet (or you'd have gotten something like "TypeError: 'NoneType' object is not callable" instead).

You seem to be using Python 3.5.0.  Can you repro this with 3.5.1 or with the asyncio from github? Do you have a small self-contained program that repos it?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 14:59:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jan 2016 19:59:41 +0000
Subject: [issue25089] Can't run Python Launcher on Windows
In-Reply-To: <1442184297.36.0.379341480925.issue25089@psf.upfronthosting.co.za>
Message-ID: <20160116195938.96358.78784@psf.io>


Roundup Robot added the comment:

New changeset 5fc9bd33a712 by Steve Dower in branch '3.5':
Issue #25089: Adds short documentation section for modifying an install.
https://hg.python.org/cpython/rev/5fc9bd33a712

New changeset 4b06490cca47 by Steve Dower in branch 'default':
Issue #25089: Adds short documentation section for modifying an install.
https://hg.python.org/cpython/rev/4b06490cca47

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 15:01:31 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 20:01:31 +0000
Subject: [issue25089] Can't run Python Launcher on Windows
In-Reply-To: <1442184297.36.0.379341480925.issue25089@psf.upfronthosting.co.za>
Message-ID: <1452974491.08.0.668370750335.issue25089@psf.upfronthosting.co.za>


Steve Dower added the comment:

I've added a brief doc section on modifying and removing the install, so hopefully that suffices for this issue. If the original issue occurs again, feel free to reopen, but I think it'll be okay.

I have a few ideas about changing the installer to be more intuitive, but those would be separate.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 15:05:22 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 20:05:22 +0000
Subject: [issue25799] 2.7.11rc1 not added to Win10 app list (start menu)
In-Reply-To: <1449262006.23.0.517910182008.issue25799@psf.upfronthosting.co.za>
Message-ID: <1452974722.65.0.907620084961.issue25799@psf.upfronthosting.co.za>


Steve Dower added the comment:

Terry, have you had a chance to try this with 2.7.11 final? (We didn't change anything, so I have no reason to expect anything difference.)

Without broader confirmation that this is an issue, I don't see how we can keep it as a release blocker. I also have no idea how to investigate or resolve it without a machine that regularly repros.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 15:09:32 2016
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Sat, 16 Jan 2016 20:09:32 +0000
Subject: [issue25287] test_crypt fails on OpenBSD
In-Reply-To: <1443682191.0.0.229033947807.issue25287@psf.upfronthosting.co.za>
Message-ID: <1452974972.6.0.875215826424.issue25287@psf.upfronthosting.co.za>


Changes by C?dric Krier :


----------
nosy: +ced

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 15:41:20 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jan 2016 20:41:20 +0000
Subject: [issue25850] Building extensions with MSVC 2015 Express fails
In-Reply-To: <1449955225.5.0.401578921369.issue25850@psf.upfronthosting.co.za>
Message-ID: <20160116204117.14181.89296@psf.io>


Roundup Robot added the comment:

New changeset fc117df27143 by Steve Dower in branch '3.5':
Issue #25850: Use cross-compilation by default for 64-bit Windows.
https://hg.python.org/cpython/rev/fc117df27143

New changeset 37dc870175be by Steve Dower in branch 'default':
Issue #25850: Use cross-compilation by default for 64-bit Windows.
https://hg.python.org/cpython/rev/37dc870175be

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 15:41:49 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 20:41:49 +0000
Subject: [issue25850] Building extensions with MSVC 2015 Express fails
In-Reply-To: <1449955225.5.0.401578921369.issue25850@psf.upfronthosting.co.za>
Message-ID: <1452976909.01.0.0027904608989.issue25850@psf.upfronthosting.co.za>


Changes by Steve Dower :


----------
assignee:  -> steve.dower
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 15:42:03 2016
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 16 Jan 2016 20:42:03 +0000
Subject: [issue24840] implement bool conversion for enums to prevent odd edge
 case
In-Reply-To: <1439251772.85.0.609570031312.issue24840@psf.upfronthosting.co.za>
Message-ID: <1452976923.11.0.45785187389.issue24840@psf.upfronthosting.co.za>


Ethan Furman added the comment:

New changeset e4c22eadc25c:

use public 'value'

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 15:43:14 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 20:43:14 +0000
Subject: [issue25850] Building extensions with MSVC 2015 Express fails
In-Reply-To: <1449955225.5.0.401578921369.issue25850@psf.upfronthosting.co.za>
Message-ID: <1452976994.01.0.0700867199259.issue25850@psf.upfronthosting.co.za>


Steve Dower added the comment:

For anyone interested, there's no issue with using the cross compilers even on a 64-bit system. The same code will be generated, the only difference is that the native 64-bit compilers can keep more in memory than the 32-bit cross compilers. For most Python extensions this won't matter (it matters for building huge projects like an operating system).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 15:49:07 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 20:49:07 +0000
Subject: [issue26059] Integer Overflow in strop.replace()
In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za>
Message-ID: <1452977347.35.0.0285563027176.issue26059@psf.upfronthosting.co.za>


Martin Panter added the comment:

Looking at the 2.7.11 code, I think it should fail properly at this line , which checks if the change in size of all the replacements overflows. Is there a way to get a stack trace or similar on Windows?

Your video only shows the operation taking a long time or hanging as far as I can tell, not the Python program crashing. I would expect the call to raise MemoryError fairly quickly, after it has counted all 0xEAAA bytes to replace (but not actually replaced them).

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 15:56:27 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 20:56:27 +0000
Subject: [issue25878] CPython on Windows builds with /W3, not /W4
In-Reply-To: <1450224755.83.0.682115702996.issue25878@psf.upfronthosting.co.za>
Message-ID: <1452977787.93.0.614415869172.issue25878@psf.upfronthosting.co.za>


Steve Dower added the comment:

I made a new patch to replace all of the existing ones here with the two-line version of the change.

I also suppressed warning 4232 about dllimport addresses (essentially, you may get different values when taking the address of an imported function because of the way thunks are generated at compile time - this doesn't matter when you are calling them, only when comparing them), mainly because there's no other way to suppress them.

All warnings about conversions should be suppressed when you make the conversion explicit, and that's the preferable way to fix those.

----------
Added file: http://bugs.python.org/file41635/25878_1.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:02:10 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 21:02:10 +0000
Subject: [issue25153] PCbuild/*.vcxproj* should use CRLF line endings
In-Reply-To: <1442504775.33.0.605516301888.issue25153@psf.upfronthosting.co.za>
Message-ID: <1452978130.5.0.0284981457088.issue25153@psf.upfronthosting.co.za>


Steve Dower added the comment:

IMHO enabling the eol extension is the right way to deal with this. Especially once the GitHub migration happens - it really doesn't handle CRLF endings (or anything Windows) as well as Mercurial does.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:15:41 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 21:15:41 +0000
Subject: [issue25954] Python 3.5.1 installer fails on Windows 7
In-Reply-To: <1451100442.78.0.216176327365.issue25954@psf.upfronthosting.co.za>
Message-ID: <1452978941.84.0.738339704878.issue25954@psf.upfronthosting.co.za>


Steve Dower added the comment:

Sorry for letting this slide for a while...

Can you check (in Programs and Features, View Installed Updates) whether you have KB2999226 installed? If not, you can get it from https://support.microsoft.com/en-us/kb/2999226

In the first install, this component failed (hence the missing DLL error), and then in subsequent installs it wasn't re-run. I'm not sure exactly what happened here, but it's possible that the installation was deferred until the next reboot automatically. Being a Windows Update, we don't have much control over how these are managed and the operating system can basically do what it likes.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:31:49 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 21:31:49 +0000
Subject: [issue24505] shutil.which wrong result on Windows
In-Reply-To: <1435183779.2.0.13075721906.issue24505@psf.upfronthosting.co.za>
Message-ID: <1452979909.37.0.288939943302.issue24505@psf.upfronthosting.co.za>


Steve Dower added the comment:

I'm good with the patch, except we can't use ctypes in the standard library. NeedCurrentDirectoryForExePathW will need to be wrapped in Modules/_winapi.c.

Should be fairly simple to do, though it probably requires learning argument clinic (which admittedly I haven't done enough to write the function without copying from elsewhere). I may get back to it eventually, but if someone posts the implementation separately I'm happy to merge two patches to get this in.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:36:05 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 21:36:05 +0000
Subject: [issue25778] winreg.EnumValue does not truncate strings correctly
In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za>
Message-ID: <1452980165.09.0.557607996182.issue25778@psf.upfronthosting.co.za>


Steve Dower added the comment:

Zach - you still got this or do you want me to commit it?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:36:26 2016
From: report at bugs.python.org (Toby Tobkin)
Date: Sat, 16 Jan 2016 21:36:26 +0000
Subject: [issue24505] shutil.which wrong result on Windows
In-Reply-To: <1435183779.2.0.13075721906.issue24505@psf.upfronthosting.co.za>
Message-ID: <1452980186.49.0.78661452614.issue24505@psf.upfronthosting.co.za>


Toby Tobkin added the comment:

Steve, yeah I saw that and started playing with Clinic last night. I'll have the updated patch out soon--I've just been slow because I've been flying around to interviews trying to get my first job out of college and it's been eating all my free time.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:39:07 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 21:39:07 +0000
Subject: [issue25993] Crashed when call time.time() after using _mm_xor_si64
In-Reply-To: <1451724578.62.0.704000687465.issue25993@psf.upfronthosting.co.za>
Message-ID: <1452980347.72.0.963733398457.issue25993@psf.upfronthosting.co.za>


Steve Dower added the comment:

This is something that you need to fix in the code using MMX. I don't recall the details, but there is an instruction that needs to be executed between using MMX and using the FPU.

Python can't make this judgement every time it calls into native code, so the external code has to do it.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:42:06 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jan 2016 21:42:06 +0000
Subject: [issue25824] 32-bit 2.7.11 installer creates registry keys that are
 incompatible with the installed python27.dll
In-Reply-To: <1449584200.04.0.891595448742.issue25824@psf.upfronthosting.co.za>
Message-ID: <20160116214203.94226.3414@psf.io>


Roundup Robot added the comment:

New changeset b91c323a605e by Steve Dower in branch '2.7':
Issue #25824: Fixes sys.winver to not include any architecture suffix.
https://hg.python.org/cpython/rev/b91c323a605e

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:42:40 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 21:42:40 +0000
Subject: [issue25824] 32-bit 2.7.11 installer creates registry keys that are
 incompatible with the installed python27.dll
In-Reply-To: <1449584200.04.0.891595448742.issue25824@psf.upfronthosting.co.za>
Message-ID: <1452980560.53.0.289629323375.issue25824@psf.upfronthosting.co.za>


Changes by Steve Dower :


----------
assignee:  -> steve.dower
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:45:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jan 2016 21:45:49 +0000
Subject: [issue26065] python embedded 3.5 amd64 crash when using venv
In-Reply-To: <1452366902.23.0.484622853391.issue26065@psf.upfronthosting.co.za>
Message-ID: <20160116214546.14187.93512@psf.io>


Roundup Robot added the comment:

New changeset 84101e587f47 by Steve Dower in branch '3.5':
Issue #26065: Excludes venv from library when generating embeddable distro.
https://hg.python.org/cpython/rev/84101e587f47

New changeset d3422b0e0cee by Steve Dower in branch 'default':
Issue #26065: Excludes venv from library when generating embeddable distro.
https://hg.python.org/cpython/rev/d3422b0e0cee

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:46:40 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 21:46:40 +0000
Subject: [issue26065] python embedded 3.5 amd64 crash when using venv
In-Reply-To: <1452366902.23.0.484622853391.issue26065@psf.upfronthosting.co.za>
Message-ID: <1452980800.99.0.1685750824.issue26065@psf.upfronthosting.co.za>


Steve Dower added the comment:

I'm declaring using venv from the embeddable distro as unsupported, and it will be removed completely from the next release.

To create virtual environments, use a regular install of Python.

----------
assignee:  -> steve.dower
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:47:03 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 16 Jan 2016 21:47:03 +0000
Subject: [issue25878] CPython on Windows builds with /W3, not /W4
In-Reply-To: <1450224755.83.0.682115702996.issue25878@psf.upfronthosting.co.za>
Message-ID: <1452980823.22.0.759121540314.issue25878@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Could you explain warning #4232 in the case of libmpdec? I thought
all files are compiled and linked together. Why is the function
imported?

----------
nosy: +skrah

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:48:52 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jan 2016 21:48:52 +0000
Subject: [issue26073] Update the list of magic numbers in launcher
In-Reply-To: <1452412193.99.0.751958856998.issue26073@psf.upfronthosting.co.za>
Message-ID: <20160116214849.111048.11339@psf.io>


Roundup Robot added the comment:

New changeset 1a2cfa52f749 by Steve Dower in branch '3.5':
Issue #26073: Update the list of magic numbers in launcher
https://hg.python.org/cpython/rev/1a2cfa52f749

New changeset cf868f77b400 by Steve Dower in branch 'default':
Issue #26073: Update the list of magic numbers in launcher
https://hg.python.org/cpython/rev/cf868f77b400

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:50:02 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 21:50:02 +0000
Subject: [issue26073] Update the list of magic numbers in launcher
In-Reply-To: <1452412193.99.0.751958856998.issue26073@psf.upfronthosting.co.za>
Message-ID: <1452981002.97.0.349226563256.issue26073@psf.upfronthosting.co.za>


Steve Dower added the comment:

Thanks!

----------
assignee:  -> steve.dower
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:50:37 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 21:50:37 +0000
Subject: [issue26070] Launcher fails to find in-place built binaries from
 earlier Python versions
In-Reply-To: <1452387575.38.0.184373942558.issue26070@psf.upfronthosting.co.za>
Message-ID: <1452981037.31.0.00137299057262.issue26070@psf.upfronthosting.co.za>


Changes by Steve Dower :


----------
assignee:  -> mhammond
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:55:30 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jan 2016 21:55:30 +0000
Subject: [issue26071] bdist_wininst created binaries fail to start and find
 32bit Pythons
In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za>
Message-ID: <20160116215527.18411.90548@psf.io>


Roundup Robot added the comment:

New changeset daa6fdaf9835 by Steve Dower in branch '3.5':
Issue #26071: bdist_wininst created binaries fail to start and find 32bit Python
https://hg.python.org/cpython/rev/daa6fdaf9835

New changeset db74f3a4cbeb by Steve Dower in branch 'default':
Issue #26071: bdist_wininst created binaries fail to start and find 32bit Python
https://hg.python.org/cpython/rev/db74f3a4cbeb

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:55:59 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 21:55:59 +0000
Subject: [issue26071] bdist_wininst created binaries fail to start and find
 32bit Pythons
In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za>
Message-ID: <1452981359.55.0.878598308127.issue26071@psf.upfronthosting.co.za>


Steve Dower added the comment:

Applied the patch and rebuilt the stubs, so this will show up in 3.5.2 and 3.6.

----------
assignee:  -> steve.dower
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:56:55 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 21:56:55 +0000
Subject: [issue26108] Calling PyInitialize with 2.7.11 on Windows x64
 terminates process
In-Reply-To: <1452765230.72.0.612722422255.issue26108@psf.upfronthosting.co.za>
Message-ID: <1452981415.74.0.877220812747.issue26108@psf.upfronthosting.co.za>


Changes by Steve Dower :


----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:58:15 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 21:58:15 +0000
Subject: [issue25644] Unable to open IDLE on Windows 10 with Python 2.7.10
In-Reply-To: <1447732580.69.0.0826869384289.issue25644@psf.upfronthosting.co.za>
Message-ID: <1452981495.06.0.961178667202.issue25644@psf.upfronthosting.co.za>


Steve Dower added the comment:

Closing as norepro, but happy to reopen if it's still an issue with the official release.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 16:59:24 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 21:59:24 +0000
Subject: [issue25694] test.libregrtest not installed
In-Reply-To: <1448182149.01.0.175316940428.issue25694@psf.upfronthosting.co.za>
Message-ID: <1452981564.06.0.99694176923.issue25694@psf.upfronthosting.co.za>


Steve Dower added the comment:

@Victor - is there anything else to be done for this issue or can we close it?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 17:01:44 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 22:01:44 +0000
Subject: [issue25759] Python 2.7.11rc1 not building with Visual Studio 2015
In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za>
Message-ID: <1452981704.26.0.629963737645.issue25759@psf.upfronthosting.co.za>


Steve Dower added the comment:

Checked PCBuild/readme.txt and it's pretty clear that you can only use VS 2010+ with the SDK and the old compiler. So I'm closing this as wontfix as we will not be merging support to build Python 2 with VC10 or later.

----------
resolution:  -> wont fix
stage: needs patch -> 
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 17:03:28 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 22:03:28 +0000
Subject: [issue25765] Installation error
In-Reply-To: <1448827814.4.0.634101535086.issue25765@psf.upfronthosting.co.za>
Message-ID: <1452981808.28.0.521216443017.issue25765@psf.upfronthosting.co.za>


Steve Dower added the comment:

Closing as third-party, but happy to reopen if this turns out to be something specific to our installer and not the configuration of the target system.

----------
resolution:  -> third party
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 17:06:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Jan 2016 22:06:12 +0000
Subject: [issue26133] TypeError: signal handler must be signal.SIG_IGN,
 signal.SIG_DFL,
 or a callable object in >
In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za>
Message-ID: 


STINNER Victor added the comment:

The problem is that the signal module has been cleared when the destruction
has been called. You must not rely on destructors but call explicitly close
methods. Please run your app in asyncio debug mode and enable logs. See
asyncio doc.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 17:06:15 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 22:06:15 +0000
Subject: [issue25878] CPython on Windows builds with /W3, not /W4
In-Reply-To: <1450224755.83.0.682115702996.issue25878@psf.upfronthosting.co.za>
Message-ID: <1452981975.33.0.331696566706.issue25878@psf.upfronthosting.co.za>


Steve Dower added the comment:

libmpdec/memory.c keeps pointers to customisable memory functions (malloc/free) and initialises them to &malloc and &free. These functions are dllimport'd from the CRT, and so they trigger a warning letting you know that "&malloc == &malloc" may not always be true.

(That trivial comparison should always be true, but if you indirect one of the values through a few other modules it may be an address of a different stub function that calls the real malloc, and hence the addresses may not match.)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 17:07:59 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Jan 2016 22:07:59 +0000
Subject: [issue25694] test.libregrtest not installed
In-Reply-To: <1452981564.06.0.99694176923.issue25694@psf.upfronthosting.co.za>
Message-ID: 


STINNER Victor added the comment:

Please close the issue.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 17:10:49 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 16 Jan 2016 22:10:49 +0000
Subject: [issue26133] TypeError: signal handler must be signal.SIG_IGN,
 signal.SIG_DFL,
 or a callable object in >
In-Reply-To: 
Message-ID: 


Guido van Rossum added the comment:

Victor, if the signal module has been cleared, how could it emit that error
message? signal.signal itself would no longer exist.

(I do agree with the solution you suggest -- though note that it may be
tricky to close the loop from inside the signal callback for SIGTERM, which
is presumably what is going on here.)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 17:36:04 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 22:36:04 +0000
Subject: [issue25694] test.libregrtest not installed
In-Reply-To: <1448182149.01.0.175316940428.issue25694@psf.upfronthosting.co.za>
Message-ID: <1452983764.8.0.392164389988.issue25694@psf.upfronthosting.co.za>


Changes by Steve Dower :


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 17:37:06 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Jan 2016 22:37:06 +0000
Subject: [issue25799] 2.7.11rc1 not added to Win10 app list (start menu)
In-Reply-To: <1449262006.23.0.517910182008.issue25799@psf.upfronthosting.co.za>
Message-ID: <1452983826.2.0.643155390625.issue25799@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

'Python 2.7.11' appeared in the 'All apps' list.  The .exe also appears in the local search, as just 'Python'.  So this was fixed by either you in one of the patches between rc1 and final, Microsoft in a Win 10 update, or randon happenstance.

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 17:39:59 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 16 Jan 2016 22:39:59 +0000
Subject: [issue25878] CPython on Windows builds with /W3, not /W4
In-Reply-To: <1450224755.83.0.682115702996.issue25878@psf.upfronthosting.co.za>
Message-ID: <1452983999.73.0.958589052444.issue25878@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Ah, thanks!  I guess this Visual Studio behavior is not compatible
with the C-standard, but indeed there are no function pointer
comparisons in libmpdec.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 18:39:30 2016
From: report at bugs.python.org (guesommer)
Date: Sat, 16 Jan 2016 23:39:30 +0000
Subject: [issue26134] urllib2.HTTPBasicPriorAuthHandler does not work with
 DigestAuthentication
Message-ID: <1452987570.59.0.951573135537.issue26134@psf.upfronthosting.co.za>


New submission from guesommer:

My first bug reported here, so might not be perfectly following the rules :)

Similar to issue 19494 ("Add urllib2.HTTPBasicPriorAuthHandler for use with APIs that don't return 401 errors") - but related to digest authentication. 

The sending of the auth header at all times works when using basic authentication, but not with digest authentication (verified with wireshark).

IMHO it should be the same behaviour with digest authentication - I think the change needs to applied there as well.

example code to check:
password_mgr = urllib.request.HTTPPasswordMgrWithPriorAuth()
password_mgr.add_password(None , 'http://www.example.org", "supercow","blablabla",is_authenticated=True)
auth_handler = urllib.request.HTTPDigestAuthHandler(password_mgr)
opener = urllib.request.build_opener(auth_handler)
urllib.request.install_opener(opener)

----------
components: Library (Lib)
messages: 258435
nosy: guesommer
priority: normal
severity: normal
status: open
title: urllib2.HTTPBasicPriorAuthHandler does not work with DigestAuthentication
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 18:55:40 2016
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 16 Jan 2016 23:55:40 +0000
Subject: [issue25778] winreg.EnumValue does not truncate strings correctly
In-Reply-To: <1452980165.09.0.557607996182.issue25778@psf.upfronthosting.co.za>
Message-ID: 


Zachary Ware added the comment:

Go for it :)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 20:02:57 2016
From: report at bugs.python.org (Marcelo Duarte)
Date: Sun, 17 Jan 2016 01:02:57 +0000
Subject: [issue25251] Unknown MS Compiler version 1900
In-Reply-To: <1443392264.43.0.443478210283.issue25251@psf.upfronthosting.co.za>
Message-ID: <1452992577.28.0.747593074052.issue25251@psf.upfronthosting.co.za>


Marcelo Duarte added the comment:

I hava a problem with others packages, like cchardet and aiohttp.
Aplying the patch changed the error message, then I generate a lib for vcruntime140, and finally, it is installed:

#go to python installation dir
cd M:\Applications\Python35-32
pexports vcruntime140.dll >libs\vcruntime140.def
dlltool -dllname vcruntime140.dll --def libs\vcruntime140.def --output-lib libs\libvcruntime140.a

----------
nosy: +marcelotduarte

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 20:08:48 2016
From: report at bugs.python.org (Cameron Conn)
Date: Sun, 17 Jan 2016 01:08:48 +0000
Subject: [issue26135] Documentation Recommends Deprecated `imp` Module
Message-ID: <1452992928.86.0.18217536546.issue26135@psf.upfronthosting.co.za>


New submission from Cameron Conn:

The documentation detailing modules recommends using the deprecated `imp` module in section 6.1. Instead, it should recommend `importlib`, which `imp` was deprecated in favor of in Python 3.4.

The portion of the documentation that says this is in the gray aside box at the bottom of Section 6.1 immediately before Section 6.1.1.

These are the pages that have this issue:
Python 3.4: https://docs.python.org/3.4/tutorial/modules.html#more-on-modules
Python 3.5: https://docs.python.org/3.5/tutorial/modules.html#more-on-modules
Python 3.6: https://docs.python.org/3.6/tutorial/modules.html#more-on-modules

----------
assignee: docs at python
components: Documentation
messages: 258438
nosy: camconn, docs at python
priority: normal
severity: normal
status: open
title: Documentation Recommends Deprecated `imp` Module
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 20:22:51 2016
From: report at bugs.python.org (anchal agarwal)
Date: Sun, 17 Jan 2016 01:22:51 +0000
Subject: [issue24780] unittest assertEqual difference output foiled by newlines
In-Reply-To: <1438534169.3.0.814109265012.issue24780@psf.upfronthosting.co.za>
Message-ID: <1452993771.5.0.946668065482.issue24780@psf.upfronthosting.co.za>


Changes by anchal agarwal :


Added file: http://bugs.python.org/file41636/test.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 20:31:21 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 17 Jan 2016 01:31:21 +0000
Subject: [issue24780] unittest assertEqual difference output foiled by newlines
In-Reply-To: <1438534169.3.0.814109265012.issue24780@psf.upfronthosting.co.za>
Message-ID: <1452994281.11.0.336959098547.issue24780@psf.upfronthosting.co.za>


Changes by Emanuel Barry :


----------
components: +Tests
stage: test needed -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 21:21:37 2016
From: report at bugs.python.org (Steve Dower)
Date: Sun, 17 Jan 2016 02:21:37 +0000
Subject: [issue25878] CPython on Windows builds with /W3, not /W4
In-Reply-To: <1450224755.83.0.682115702996.issue25878@psf.upfronthosting.co.za>
Message-ID: <1452997297.25.0.137432291229.issue25878@psf.upfronthosting.co.za>


Steve Dower added the comment:

I don't think the C standard necessarily applies or defines what happens when you call/link a __declspec'd function, but it's certainly not going to be the same as static linking.

That said, maybe the subtle nature of this means we should suppress the warning locally with a comment, rather than suppressing it globally.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 21:24:11 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 17 Jan 2016 02:24:11 +0000
Subject: [issue21762] update the import machinery to only use __spec__
In-Reply-To: <1402781631.86.0.838758150876.issue21762@psf.upfronthosting.co.za>
Message-ID: <1452997451.95.0.445766275955.issue21762@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

That approach sounds good to me.

The main problem cases I'm aware of are:

__name__:

* reliably wrong in __main__
* the attribute you mess with if you want __qualname__ on functions and classes to be different so that pickle will import them from somewhere else (e.g. a parent package)

__path__:

* used for dynamic package definitions (including namespace package emulation)

__package__:

* AFAIK, mainly useful as a workaround for other people doing "bad things" (TM), like running package submodules directly as __main__ rather than using the -m switch

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 21:29:37 2016
From: report at bugs.python.org (Ramin Farajpour Cami)
Date: Sun, 17 Jan 2016 02:29:37 +0000
Subject: [issue26059] Integer Overflow in strop.replace()
In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za>
Message-ID: <1452997777.88.0.991725808379.issue26059@psf.upfronthosting.co.za>


Ramin Farajpour Cami added the comment:

"Your video only shows the operation taking a long time or hanging as far as I can tell," what your means?

i say my OS crash with run function strop i should restart manually for work again,

do you have idea for fix it ?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 21:32:32 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 17 Jan 2016 02:32:32 +0000
Subject: [issue26134] HTTPPasswordMgrWithPriorAuth does not work with
 DigestAuthentication
In-Reply-To: <1452987570.59.0.951573135537.issue26134@psf.upfronthosting.co.za>
Message-ID: <1452997952.18.0.00903322484073.issue26134@psf.upfronthosting.co.za>


Martin Panter added the comment:

Despite the title of the other report, it looks like we ended up having a HTTPPasswordMgrWithPriorAuth class instead, and there is no longer a HTTPBasicPriorAuthHandler class. Also, if this proposal could work, it would have to go into a new version of Python; 3.5 has already been released.

With Basic authentication, the client can easily pre-empt an Authorization field, because it sends the username and password in the clear. I have less understanding of Digest authentication, but it is described in . I understand the client first needs a ?nonce? value issued by the server before it can generate the Authorization field.

You gave some demonstration code. Can you explain what the code should be doing at the HTTP level? Do you have any example server, use case, or something that this would work with? What were you looking for with Wireshark? I suspect you would need to include the nonce or some previous session object with the password manager.

The code to generate the Authorization field with Basic authentication is in AbstractBasicAuthHandler.http_request(): . For comparison, the Digest data for the Authorization field is generated in AbstractDigestAuthHandler.get_authorization(). See how it requires the ?chal? parameter, derived from an Authorization response field.

----------
nosy: +martin.panter
stage:  -> test needed
title: urllib2.HTTPBasicPriorAuthHandler does not work with DigestAuthentication -> HTTPPasswordMgrWithPriorAuth does not work with DigestAuthentication
type:  -> enhancement
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 21:34:45 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Jan 2016 02:34:45 +0000
Subject: [issue21762] update the import machinery to only use __spec__
In-Reply-To: <1402781631.86.0.838758150876.issue21762@psf.upfronthosting.co.za>
Message-ID: <1452998085.58.0.148903144883.issue21762@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Yeah, which is why it will take a transition to get people to start mucking with __spec__ instead of the module attributes for their legitimate/questionable needs (although the whole `__name__ == '__main__'` idiom means __name__ will never go away while __path__, __package__, __loader__, __file__, and __cached__ could all slowly go away).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 21:44:06 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Jan 2016 02:44:06 +0000
Subject: [issue26135] Documentation Recommends Deprecated `imp` Module
In-Reply-To: <1452992928.86.0.18217536546.issue26135@psf.upfronthosting.co.za>
Message-ID: <20160117024402.94222.64795@psf.io>


Roundup Robot added the comment:

New changeset 31e6d4d25b8e by Senthil Kumaran in branch '3.5':
Issue26135 - In the tutorial section on modules, reference importlib.reload instead of imp.reload.
https://hg.python.org/cpython/rev/31e6d4d25b8e

New changeset 6636d688bbd3 by Senthil Kumaran in branch 'default':
merge from 3.5
https://hg.python.org/cpython/rev/6636d688bbd3

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 21:46:18 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 17 Jan 2016 02:46:18 +0000
Subject: [issue26135] Documentation Recommends Deprecated `imp` Module
In-Reply-To: <1452992928.86.0.18217536546.issue26135@psf.upfronthosting.co.za>
Message-ID: <1452998778.35.0.533796594414.issue26135@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thank you for the report. Fixed in the active versions of python (3.5 and 3.6). 3.4 was in security fix mode. Although, it can see important documentation bug-fixes, this isn't bug-fix as far as 3.4 version is concerned. So, I didn't make the change in 3.4.

----------
assignee: docs at python -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 21:50:21 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 17 Jan 2016 02:50:21 +0000
Subject: [issue26069] Remove the Deprecated API in trace module
In-Reply-To: <1452385226.89.0.6584761467.issue26069@psf.upfronthosting.co.za>
Message-ID: <1452999021.94.0.486263009282.issue26069@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the pointers, Berker. That was very helpful and I will keep in mind when evaluating other deprecated apis. 

For the trace module, I will add this removal information in Doc/whatsnew/3.6.rst

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 22:12:17 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 17 Jan 2016 03:12:17 +0000
Subject: [issue26059] Integer Overflow in strop.replace()
In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za>
Message-ID: <1453000337.33.0.580476984777.issue26059@psf.upfronthosting.co.za>


Martin Panter added the comment:

My previous comment was assuming 32-bit Python on Windows; now I see it is 64-bit.

At the end of the video, I see that the cursor stops blinking, and you can?t do anything (closing the window seems to do nothing). So maybe the OS has crashed or frozen, or maybe it is just being really slow.

In the video I also see you have about 8 GB of RAM. The Python strop code should try to allocate a temporary buffer of 0xEAAA * 2 * 0xAAAA bytes = 5.2 GB, and then a second 5.2 GB object which is the final string result. It copies the temporary buffer into the string object, so it will temporarily require 10.4 GB allocated. Does Windows use swap memory? I suspect what you see is normal Windows behaviour when it runs low on memory, and it is not Python?s fault.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 22:31:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 17 Jan 2016 03:31:19 +0000
Subject: [issue26136] DeprecationWarning for PEP 479 (generator_stop)
Message-ID: <1453001479.54.0.173509242949.issue26136@psf.upfronthosting.co.za>


New submission from Martin Panter:

PEP 479 says ?Python 3.6: Non-silent deprecation warning? if ?StopIteration bubbles out of a generator not under __future__ import?. Currently I see a PendingDeprecationWarning in this case; I guess this should be changed to DeprecationWarning in the 3.6 branch.

----------
components: Interpreter Core
messages: 258448
nosy: martin.panter
priority: normal
severity: normal
stage: needs patch
status: open
title: DeprecationWarning for PEP 479 (generator_stop)
type: behavior
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 23:44:45 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Jan 2016 04:44:45 +0000
Subject: [issue25905] IDLE fails to display the README file
In-Reply-To: <1450441792.4.0.635729771057.issue25905@psf.upfronthosting.co.za>
Message-ID: <20160117044442.121300.94538@psf.io>


Roundup Robot added the comment:

New changeset 21356a5b8a5e by Terry Jan Reedy in branch '2.7':
Issue #25905: Specify 'ascii' encoding for README.txt and NEWS.txt.
https://hg.python.org/cpython/rev/21356a5b8a5e

New changeset 59852a79b508 by Terry Jan Reedy in branch '3.5':
Issue #25905: Specify 'ascii' encoding for README.txt and NEWS.txt.
https://hg.python.org/cpython/rev/59852a79b508

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 23:52:42 2016
From: report at bugs.python.org (Ramin Farajpour Cami)
Date: Sun, 17 Jan 2016 04:52:42 +0000
Subject: [issue26059] Integer Overflow in strop.replace()
In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za>
Message-ID: <1453006362.96.0.118851464522.issue26059@psf.upfronthosting.co.za>


Ramin Farajpour Cami added the comment:

Yes,

i have any idea,

Thanks,

----------
resolution:  -> wont fix

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 23:54:24 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 17 Jan 2016 04:54:24 +0000
Subject: [issue25905] IDLE fails to display the README file
In-Reply-To: <1450441792.4.0.635729771057.issue25905@psf.upfronthosting.co.za>
Message-ID: <1453006464.41.0.714590443277.issue25905@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I re-encoded CREDITS to utf-8 and specified 'ascii' for the other so *I* will see an error if a non-ascii chars gets in the file again.  Serhiy, I am confident that this will work on all OSes, but feel free to test AboutIDLE again sometime.

(Note to myself) To automate a test that the files will open, change
from idlelib import textView  # to
from idlelib.textView import view_text, view_file
and change display... and show.. methods to module functions so view_file can be replaced and the show functions called without involving tkinter.  This can be part of future refactoring in 3.5+.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 01:11:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 17 Jan 2016 06:11:19 +0000
Subject: [issue23795] argparse -- incorrect usage for mutually exclusive
In-Reply-To: <1427479353.63.0.760069319945.issue23795@psf.upfronthosting.co.za>
Message-ID: <1453011079.8.0.409167584673.issue23795@psf.upfronthosting.co.za>


Martin Panter added the comment:

I just tried the test script on Arch Linux?s python-3.4.3-2-i686.pkg.tar.xz package (reinstalled just to be sure), and I get the correct help output. All I can suggest is make sure you really have the original files and haven?t accidentally edited the argparse.py file for instance.

----------
nosy: +martin.panter
resolution:  -> works for me
status: open -> closed
type: enhancement -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 01:20:12 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 17 Jan 2016 06:20:12 +0000
Subject: [issue14046] argparse: assertion failure if optional argument has
 square/round brackets in metavar
In-Reply-To: <1329542509.5.0.84021889574.issue14046@psf.upfronthosting.co.za>
Message-ID: <1453011612.69.0.126716292214.issue14046@psf.upfronthosting.co.za>


Changes by Martin Panter :


----------
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 01:32:01 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 17 Jan 2016 06:32:01 +0000
Subject: [issue25058] Right square bracket argparse metavar
In-Reply-To: <1441902603.18.0.552996969637.issue25058@psf.upfronthosting.co.za>
Message-ID: <1453012321.31.0.243348903062.issue25058@psf.upfronthosting.co.za>


Changes by Martin Panter :


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> argparse assertion failure with brackets in metavars

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 03:49:17 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 17 Jan 2016 08:49:17 +0000
Subject: [issue26134] HTTPPasswordMgrWithPriorAuth does not work with
 DigestAuthentication
In-Reply-To: <1452987570.59.0.951573135537.issue26134@psf.upfronthosting.co.za>
Message-ID: <1453020557.22.0.19286880784.issue26134@psf.upfronthosting.co.za>


Martin Panter added the comment:

Perhaps this is similar to Issue 7752, about reusing the nonce.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 04:36:56 2016
From: report at bugs.python.org (Alexander Riccio)
Date: Sun, 17 Jan 2016 09:36:56 +0000
Subject: [issue25878] CPython on Windows builds with /W3, not /W4
In-Reply-To: <1450224755.83.0.682115702996.issue25878@psf.upfronthosting.co.za>
Message-ID: <1453023416.27.0.931627791263.issue25878@psf.upfronthosting.co.za>


Alexander Riccio added the comment:

If there are few enough instances, then using a #pragma warning(suppress:4232) is probably the best idea.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 04:44:12 2016
From: report at bugs.python.org (Alexander Riccio)
Date: Sun, 17 Jan 2016 09:44:12 +0000
Subject: [issue26137] [idea] use the Microsoft Antimalware Scan Interface
Message-ID: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za>


New submission from Alexander Riccio:

I'm really not sure what it'd look like, or how it'd work, but CPython should take advantage of Microsoft's Antimalware Scan Interface, which is new to Windows 10. It's designed for applications like interpreters, which can execute u trusted code that may not be visible to antimalware.

----------
components: Interpreter Core, Windows
messages: 258455
nosy: Alexander Riccio, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: [idea] use the Microsoft Antimalware Scan Interface
type: enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 04:49:03 2016
From: report at bugs.python.org (Alexander Riccio)
Date: Sun, 17 Jan 2016 09:49:03 +0000
Subject: [issue26137] [idea] use the Microsoft Antimalware Scan Interface
In-Reply-To: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za>
Message-ID: <1453024143.12.0.549641327939.issue26137@psf.upfronthosting.co.za>


Alexander Riccio added the comment:

See "Windows 10 to offer application developers new malware defenses" https://blogs.technet.microsoft.com/mmpc/2015/06/09/windows-10-to-offer-application-developers-new-malware-defenses/ for an example of how AMSI works with PowerShell.

I think the applicability to CPython is self-evident.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 04:50:46 2016
From: report at bugs.python.org (Alexander Riccio)
Date: Sun, 17 Jan 2016 09:50:46 +0000
Subject: [issue26137] [idea] use the Microsoft Antimalware Scan Interface
In-Reply-To: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za>
Message-ID: <1453024246.88.0.153905637372.issue26137@psf.upfronthosting.co.za>


Alexander Riccio added the comment:

See also: "Security Focus: Defending PowerShell with the Anti-Malware Scan Interface (AMSI)" http://blogs.technet.com/b/poshchap/archive/2015/10/16/security-focus-defending-powershell-with-windows-defender.aspx

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 05:07:07 2016
From: report at bugs.python.org (Alexander Riccio)
Date: Sun, 17 Jan 2016 10:07:07 +0000
Subject: [issue26137] [idea] use the Microsoft Antimalware Scan Interface
In-Reply-To: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za>
Message-ID: <1453025227.24.0.844480386092.issue26137@psf.upfronthosting.co.za>


Alexander Riccio added the comment:

When I say "I'm really not sure what it'd look like, or how it'd work" I mean at the C level. At a higher level, there are many places that I imagine are good places to use AMSI: Perhaps expressions passed in from the command line (-c) should be scanned; maybe pip packages should be scanned on installation, and maybe untrusted packages should be scanned right before execution...

Then it's a matter of calling the AMSI APIs in the right places; I don't know where those are.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 05:48:45 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Sun, 17 Jan 2016 10:48:45 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1453027725.11.0.970381737416.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

zipinfo-from-file.patch has an orthogonal but related change: the code in ZipFile.write() to construct a ZipInfo object from a filesystem file is pulled out to a classmethod ZipInfo.from_file().

Together, these changes make it much easier to control how a file is written to a zip file, like this:

zi = ZipInfo.from_file(blah)
# ... manipulate zi...
with open(blah, 'rb') as src, zf.open(zi, 'w') as dest:
    # copy of the read/write loop - maybe this should be
    # pulled out separately as well?

If these changes make it in, I might put a backported copy of the module on PyPI so I can start using it without waiting for Python 3.6.

----------
Added file: http://bugs.python.org/file41637/zipinfo-from-file.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 06:09:32 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 17 Jan 2016 11:09:32 +0000
Subject: [issue25878] CPython on Windows builds with /W3, not /W4
In-Reply-To: <1450224755.83.0.682115702996.issue25878@psf.upfronthosting.co.za>
Message-ID: <1453028972.68.0.783178417543.issue25878@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I would expect linking to behave "as if" the abstract machine defined
by the standard were executing the code.

We already had one function pointer equality issue due to COMDAT folding,
so I agree that we should leave the warning on.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 06:26:01 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 17 Jan 2016 11:26:01 +0000
Subject: [issue26138] Disable /W4 warning (non-standard dllimport behavior)
Message-ID: <1453029961.05.0.06139396524.issue26138@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
nosy: skrah
priority: normal
severity: normal
status: open
title: Disable /W4 warning (non-standard dllimport behavior)

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 06:27:07 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 17 Jan 2016 11:27:07 +0000
Subject: [issue26139] libmpdec: disable /W4 warning (non-standard dllimport
 behavior)
Message-ID: <1453030027.6.0.790177544356.issue26139@psf.upfronthosting.co.za>


New submission from Stefan Krah:

See: #25878

----------
assignee: skrah
components: Extension Modules
messages: 258461
nosy: skrah
priority: normal
severity: normal
status: open
title: libmpdec: disable /W4 warning (non-standard dllimport behavior)
type: compile error
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 06:29:06 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Jan 2016 11:29:06 +0000
Subject: [issue26139] libmpdec: disable /W4 warning (non-standard dllimport
 behavior)
In-Reply-To: <1453030027.6.0.790177544356.issue26139@psf.upfronthosting.co.za>
Message-ID: <20160117112903.111050.24488@psf.io>


Roundup Robot added the comment:

New changeset df78978dacab by Stefan Krah in branch 'default':
Issue #26139: libmpdec: disable /W4 warning (non-standard dllimport behavior).
https://hg.python.org/cpython/rev/df78978dacab

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 06:30:11 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 17 Jan 2016 11:30:11 +0000
Subject: [issue26138] Disable /W4 warning (non-standard dllimport behavior)
Message-ID: <1453030211.66.0.275647131999.issue26138@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
type:  -> compile error

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 06:32:23 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 17 Jan 2016 11:32:23 +0000
Subject: [issue26139] libmpdec: disable /W4 warning (non-standard dllimport
 behavior)
In-Reply-To: <1453030027.6.0.790177544356.issue26139@psf.upfronthosting.co.za>
Message-ID: <1453030343.35.0.176397320837.issue26139@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 06:34:09 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 17 Jan 2016 11:34:09 +0000
Subject: [issue25878] CPython on Windows builds with /W3, not /W4
In-Reply-To: <1450224755.83.0.682115702996.issue25878@psf.upfronthosting.co.za>
Message-ID: <1453030449.76.0.518014197257.issue25878@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Pragma added for libmpdec in #26139.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 06:42:52 2016
From: report at bugs.python.org (Hiroyuki Takagi)
Date: Sun, 17 Jan 2016 11:42:52 +0000
Subject: [issue26140] inspect.iscoroutinefunction raises TypeError when checks
 Mock of function or coroutinefunction
Message-ID: <1453030972.84.0.0646105171888.issue26140@psf.upfronthosting.co.za>


New submission from Hiroyuki Takagi:

inspect.iscoroutinefunction and asyncio.iscoroutinefunction with patch of issue25599 (https://bugs.python.org/issue25599) raise TypeError when used to check Mock object which mocks function or coroutinefunction.

How to reproduce:

- For the mock of function

>>> from unittest.mock import Mock
>>> import inspect
>>> def a():...
... 
>>> inspect.iscoroutinefunction(Mock(a))

Expected: False
Actual: 
    Traceback (most recent call last):
      File "", line 1, in 
      File ".../cpython/Lib/inspect.py", line 187, in iscoroutinefunction
        object.__code__.co_flags & CO_COROUTINE)
    TypeError: unsupported operand type(s) for &: 'Mock' and 'int'


- For the mock of coroutine-function

>>> async def b():...
... 
>>> inspect.iscoroutinefunction(Mock(b))

Expected: True
Actual:
    Traceback (most recent call last):
      File "", line 1, in 
      File ".../cpython/Lib/inspect.py", line 187, in iscoroutinefunction
        object.__code__.co_flags & CO_COROUTINE)
    TypeError: unsupported operand type(s) for &: 'Mock' and 'int'


Without the patch of issue25599, asyncio.iscoroutinefunction does not raise error and returns Mock object. But I don't think it is expected behavior, as discussed in that issue.

I wrote a patch to solve this problem.

----------
components: asyncio
files: mock.patch
keywords: patch
messages: 258464
nosy: gvanrossum, haypo, miyakogi, yselivanov
priority: normal
severity: normal
status: open
title: inspect.iscoroutinefunction raises TypeError when checks Mock of function or coroutinefunction
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file41638/mock.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 07:27:45 2016
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 17 Jan 2016 12:27:45 +0000
Subject: [issue25954] Python 3.5.1 installer fails on Windows 7
In-Reply-To: <1451100442.78.0.216176327365.issue25954@psf.upfronthosting.co.za>
Message-ID: <1453033665.58.0.277036430479.issue25954@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

Steve, I do have that update installed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 08:42:40 2016
From: report at bugs.python.org (Elena Oat)
Date: Sun, 17 Jan 2016 13:42:40 +0000
Subject: [issue24780] unittest assertEqual difference output foiled by newlines
In-Reply-To: <1438534169.3.0.814109265012.issue24780@psf.upfronthosting.co.za>
Message-ID: <1453038160.28.0.658691730904.issue24780@psf.upfronthosting.co.za>


Elena Oat added the comment:

The issue is not related only to the caret. In fact, as seen in the below output, the issue occurs anytime there's a newline character in the beginning or middle of the string to be compared. 

In short, if a newline is present in the string and it's in the beginning or middle, a newline character should be put at the end of the string, too. This will make the output look sensible. If, however, the newline is not present at the end, the output is not really readable (the new line is missing).

As we (me and Manvi B.) understand, the caret appears in the output only when the strings are similar enough, i.e. their similarity ratio is high enough. Otherwise, compare function doesn't show the carets in places of difference. This can also be seen in test case test_trailingnewline_2.

This issue occurs, probably, due to using splitlines method.

FFFFFFFF
======================================================================
FAIL: test_notrailingnewline_0 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 8, in test_notrailingnewline_0
    self.assertEqual("abcDefehiJkl", "abcdefGhijkl")
AssertionError: 'abcDefehiJkl' != 'abcdefGhijkl'
- abcDefehiJkl
?    ^  ^  ^
+ abcdefGhijkl
?    ^  ^  ^


======================================================================
FAIL: test_notrailingnewline_1 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 14, in test_notrailingnewline_1
    self.assertEqual("a\nbcdf", "a\nbddf")
AssertionError: 'a\nbcdf' != 'a\nbddf'
  a
- bcdf?  ^
+ bddf?  ^


======================================================================
FAIL: test_notrailingnewline_2 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 18, in test_notrailingnewline_2
    self.assertEqual("a\nbcdf", "a\nbddg")
AssertionError: 'a\nbcdf' != 'a\nbddg'
  a
- bcdf+ bddg

======================================================================
FAIL: test_starting_and_ending_newline_0 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 12, in test_starting_and_ending_newline_0
    self.assertEqual("\nabcDefehiJkl\n", "\nabcdefGhijkl\n")
AssertionError: '\nabcDefehiJkl\n' != '\nabcdefGhijkl\n'
  
- abcDefehiJkl
?    ^  ^  ^
+ abcdefGhijkl
?    ^  ^  ^


======================================================================
FAIL: test_startingnewline_0 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 10, in test_startingnewline_0
    self.assertEqual("\nabcDefehiJkl", "\nabcdefGhijkl")
AssertionError: '\nabcDefehiJkl' != '\nabcdefGhijkl'
  
- abcDefehiJkl?    ^  ^  ^
+ abcdefGhijkl?    ^  ^  ^


======================================================================
FAIL: test_trailingnewline_0 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 6, in test_trailingnewline_0
    self.assertEqual("abcDefehiJkl\n", "abcdefGhijkl\n")
AssertionError: 'abcDefehiJkl\n' != 'abcdefGhijkl\n'
- abcDefehiJkl
?    ^  ^  ^
+ abcdefGhijkl
?    ^  ^  ^


======================================================================
FAIL: test_trailingnewline_1 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 16, in test_trailingnewline_1
    self.assertEqual("a\nbcdf\n", "a\nbddf\n")
AssertionError: 'a\nbcdf\n' != 'a\nbddf\n'
  a
- bcdf
?  ^
+ bddf
?  ^


======================================================================
FAIL: test_trailingnewline_2 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 20, in test_trailingnewline_2
    self.assertEqual("a\nbcdf\n", "a\nbddg\n")
AssertionError: 'a\nbcdf\n' != 'a\nbddg\n'
  a
- bcdf
+ bddg


----------------------------------------------------------------------
Ran 8 tests in 0.007s

FAILED (failures=8)

----------
nosy: +Elena.Oat
Added file: http://bugs.python.org/file41639/test2.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 08:54:28 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 17 Jan 2016 13:54:28 +0000
Subject: [issue26129] Difference in behaviour with grp.getgrgid and
 pwd.getpwuid
In-Reply-To: <1452887305.34.0.0492943983639.issue26129@psf.upfronthosting.co.za>
Message-ID: <1453038868.28.0.0405214090458.issue26129@psf.upfronthosting.co.za>


SilentGhost added the comment:

I'm adding Larry since it was his implementation of _Py_Uid_Converter in issue15301 that seems to lead to this behaviour.

----------
nosy: +SilentGhost, larry
versions: +Python 3.6 -Python 2.7, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 09:15:36 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 17 Jan 2016 14:15:36 +0000
Subject: [issue26129] Difference in behaviour with grp.getgrgid and
 pwd.getpwuid
In-Reply-To: <1452887305.34.0.0492943983639.issue26129@psf.upfronthosting.co.za>
Message-ID: <1453040136.06.0.410562703234.issue26129@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Nope.  Argument Clinic was merged in 3.4, and in 3.3 pwd.getpwuid wouldn't accept strings.  So this isn't a bug introduced in the Clinic conversion in 3.4, this is historical behavior, and we can't change it now.

If anything, I'd prefer that grp.getgrid *didn't* accept strings, but it's too late to change that too.  "Helpfully" automatically calling int() on an argument is un-pythonic.

(To answer your specific questions: they probably shouldn't have different behaviors, and I assume there's no particular reason for the difference.  It's probably that they had different implementors, and one did a sloppier job than the other.)

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 09:24:07 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 17 Jan 2016 14:24:07 +0000
Subject: [issue25982] multiprocessing docs for Namespace lacks class definition
In-Reply-To: <1451523296.03.0.873921755549.issue25982@psf.upfronthosting.co.za>
Message-ID: <1453040647.54.0.292487770761.issue25982@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
components: +Documentation

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 09:26:12 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 17 Jan 2016 14:26:12 +0000
Subject: [issue24906] asyncore asynchat hanging on ssl
In-Reply-To: <1440149579.35.0.0331898658282.issue24906@psf.upfronthosting.co.za>
Message-ID: <1453040772.48.0.216538358757.issue24906@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +giampaolo.rodola, josiahcarlson, stutzbach

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 09:28:34 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 17 Jan 2016 14:28:34 +0000
Subject: [issue25724] SSLv3 test failure on Ubuntu 16.04 LTS
In-Reply-To: <1448379899.26.0.590688499284.issue25724@psf.upfronthosting.co.za>
Message-ID: <1453040914.69.0.723002249972.issue25724@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
stage:  -> patch review
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 09:30:35 2016
From: report at bugs.python.org (Steve Dower)
Date: Sun, 17 Jan 2016 14:30:35 +0000
Subject: [issue26137] [idea] use the Microsoft Antimalware Scan Interface
In-Reply-To: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za>
Message-ID: <1453041035.55.0.794651006457.issue26137@psf.upfronthosting.co.za>


Steve Dower added the comment:

I actually have a prototype of this already, though I haven't benchmarked the impact yet.

Brett and I were concerned that the applicability wasn't apparent enough given the cost involved, so we've been (slowly) preparing a PEP, mainly to have that record of why it's been added. I'll assign to myself, and keep an eye on python-dev for follow-up.

----------
assignee:  -> steve.dower
nosy: +brett.cannon
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 09:32:24 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Jan 2016 14:32:24 +0000
Subject: [issue25724] SSLv3 test failure on Ubuntu 16.04 LTS
In-Reply-To: <1448379899.26.0.590688499284.issue25724@psf.upfronthosting.co.za>
Message-ID: <1453041144.67.0.879359731569.issue25724@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

>From a procedural point of view, I think it would be reasonable to wait for the 16.04 release (or at least feature freeze), in case there are other breakages pending.

----------
versions: +Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 09:32:46 2016
From: report at bugs.python.org (Steve Dower)
Date: Sun, 17 Jan 2016 14:32:46 +0000
Subject: [issue25954] Python 3.5.1 installer fails on Windows 7
In-Reply-To: <1451100442.78.0.216176327365.issue25954@psf.upfronthosting.co.za>
Message-ID: <1453041166.79.0.588014632625.issue25954@psf.upfronthosting.co.za>


Steve Dower added the comment:

Is your installation working okay then? You seemed to imply that in an earlier message, but I just want to confirm before closing the issue.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 10:00:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Jan 2016 15:00:26 +0000
Subject: [issue26129] Difference in behaviour with grp.getgrgid and
 pwd.getpwuid
In-Reply-To: <1452887305.34.0.0492943983639.issue26129@psf.upfronthosting.co.za>
Message-ID: <1453042826.11.0.306235555275.issue26129@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This looks as unintentional consequences of ab0221811771.

I think the current behavior of grp.getgrgid() is not correct, because it accepts str, float and other types. Python is strong-typed language and shouldn't make unwanted implicit type conversions. I guess the purpose was to support long arguments in Python 2.

There is similar problem with grp.getgrnam() in 2.7. It accepts arguments of any types and convert them to str by calling str(). I guess the purpose was to support unicode arguments. In 3.x only str is accepted.

Proposed patch deprecates accepting non-integer arguments in grp.getgrgid(). May be we can just remove this without starting deprecating process. I don't know.

----------
keywords: +patch
nosy: +brett.cannon, serhiy.storchaka
resolution: wont fix -> 
stage: resolved -> patch review
status: closed -> open
Added file: http://bugs.python.org/file41640/grp_getgrgid_non_integer_gid.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 10:38:07 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 17 Jan 2016 15:38:07 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1453045087.15.0.274720300545.issue19475@psf.upfronthosting.co.za>


SilentGhost added the comment:

> I there anything else I can do for this?
I think you've done all you could, it's just someone needs to commit it.  I don't think they're being rude on purpose - it's just that there are so many committers in the nosy list that no one is feeling like it's their job.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 11:35:45 2016
From: report at bugs.python.org (Julien)
Date: Sun, 17 Jan 2016 16:35:45 +0000
Subject: [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <1453048545.82.0.163333144792.issue26106@psf.upfronthosting.co.za>


Julien added the comment:

@georg.brandl is right, a parsed-literal block should work: Does not appear in pot files, and |release| replaced: nice.

I attached a new patch.

----------
Added file: http://bugs.python.org/file41641/literal-licence.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 11:55:40 2016
From: report at bugs.python.org (Ben Darnell)
Date: Sun, 17 Jan 2016 16:55:40 +0000
Subject: [issue26141] typing module documentation incomplete
Message-ID: <1453049740.68.0.762293537242.issue26141@psf.upfronthosting.co.za>


New submission from Ben Darnell:

The typing module docs at https://docs.python.org/3/library/typing.html do not include everything that is documented in the PEP (https://www.python.org/dev/peps/pep-0484/#the-typing-module). Specifically, `AnyStr` is mentioned but not defined, the `@overload` decorator is missing, and so are the new-to-3.5 types Awaitable, AsyncIterable, AsyncIterator.

----------
assignee: docs at python
components: Documentation
messages: 258475
nosy: Ben.Darnell, docs at python
priority: normal
severity: normal
status: open
title: typing module documentation incomplete
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 12:56:22 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Jan 2016 17:56:22 +0000
Subject: [issue26129] Difference in behaviour with grp.getgrgid and
 pwd.getpwuid
In-Reply-To: <1452887305.34.0.0492943983639.issue26129@psf.upfronthosting.co.za>
Message-ID: <1453053382.29.0.281694908721.issue26129@psf.upfronthosting.co.za>


Brett Cannon added the comment:

A single deprecation cycle should be enough since it obviously shouldn't work with floats and strings might make sense but updating code to not use them is easy enough.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 13:52:20 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 17 Jan 2016 18:52:20 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1453045087.15.0.274720300545.issue19475@psf.upfronthosting.co.za>
Message-ID: 


Guido van Rossum added the comment:

I think Alexander has commit rights, he did most of the review, I trust him
to commit it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 14:34:40 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 17 Jan 2016 19:34:40 +0000
Subject: [issue25627] distutils : file "bdist_rpm.py" does not quote filenames
 when executing the rpm command
In-Reply-To: <1447535612.69.0.122030151224.issue25627@psf.upfronthosting.co.za>
Message-ID: <1453059280.34.0.245695637757.issue25627@psf.upfronthosting.co.za>


SilentGhost added the comment:

Eric, Donald, is any one of you able to test this?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 14:46:33 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 17 Jan 2016 19:46:33 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1453059993.72.0.727713208612.issue19475@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Not seeing any indication that this has been tested on Windows, I applied, compiled (32 bit), and ran test_datetime on Win10 without error.  I did not rebuild the doc.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 15:25:37 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 17 Jan 2016 20:25:37 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1453062337.65.0.82856291536.issue19475@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky :


----------
assignee:  -> belopolsky
stage: patch review -> commit review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 15:33:35 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 17 Jan 2016 20:33:35 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1453062815.41.0.713093845594.issue19475@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Is issue19475_v12.patch the final patch?  I don't see it addressing Guido's suggestion in msg256470 to add milli- and nanoseconds options.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 15:46:12 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 17 Jan 2016 20:46:12 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1453063572.28.0.604473676172.issue19475@psf.upfronthosting.co.za>


SilentGhost added the comment:

Yes, version 12 is the final patch. It doesn't add those options. To copy my opinion from the rietveld (https://bugs.python.org/review/19475/#msg14): 

> I don't really think nanoseconds belong here. If they don't
> exist anywhere else in the module, why should they be suddenly introduced here?
> of all places. It would be fine to use some generic solution that would enable
> or ease their addition in the future, but they shall not be added at this time.

(there are altogether 27 messages there, which everyone's naturally CCed on).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 16:23:54 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 17 Jan 2016 21:23:54 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1453065834.82.0.635915526289.issue19475@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I left some comments on Rietveld.

----------
stage: commit review -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 16:33:15 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 17 Jan 2016 21:33:15 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1453066395.64.0.775404787693.issue19475@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> I don't really think nanoseconds belong here.

What about milliseconds?  I'll leave it for Guido to make a call on nanoseconds.  My vote is +0.5.

> If they don't
> exist anywhere else in the module, why should they be suddenly 
> introduced here?

The timespec feature is modeled after GNU date --iso-8601[=timespec] option which does support nanoseconds.  It is fairly common to support nanoseconds these days and it does not cost much to implement.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 16:38:21 2016
From: report at bugs.python.org (Julien)
Date: Sun, 17 Jan 2016 21:38:21 +0000
Subject: [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <1453066701.03.0.478184236351.issue26106@psf.upfronthosting.co.za>


Julien added the comment:

And uploaded the result: http://www.afpy.org/doc/python/3.5/license.html

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 17:07:12 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 17 Jan 2016 22:07:12 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1453068432.78.0.494378089308.issue19475@psf.upfronthosting.co.za>


SilentGhost added the comment:

> What about milliseconds?  I'll leave it for Guido to make a call on nanoseconds.  My vote is +0.5.
The only reason I didn't mention milliseconds because they exist in timedelta instantiation. And really, being the only place in the whole module they're as confusing there as would be nanoseconds.

> > If they don't
> > exist anywhere else in the module, why should they be suddenly 
> > introduced here?

> The timespec feature is modeled after GNU date --iso-8601[=timespec] option which does support nanoseconds.  It is fairly common to support nanoseconds these days and it does not cost much to implement.

Yes, but the module does not support nanoseconds. And putting any such options would require a huge banner saying that the nanosecond option will just always result in three zeros at the end. My suggestion is not to pretend that we suddenly "support" nanoseconds, but rather to follow the actual implementation of the module and add the support for nanoseconds timespec when the module actually adds support for them.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 18:37:34 2016
From: report at bugs.python.org (Jim Nasby)
Date: Sun, 17 Jan 2016 23:37:34 +0000
Subject: [issue26142] Formatting bug on
 https://docs.python.org/2.7/c-api/intro.html
Message-ID: <1453073854.16.0.698165135506.issue26142@psf.upfronthosting.co.za>


New submission from Jim Nasby:

The code for the set_all() example has a formatting bug:

            return -1;
    }
        Py_DECREF(index);
    }

it should be

            return -1;
        }
        Py_DECREF(index);
    }

----------
assignee: docs at python
components: Documentation
messages: 258486
nosy: Jim Nasby, docs at python
priority: normal
severity: normal
status: open
title: Formatting bug on https://docs.python.org/2.7/c-api/intro.html
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 19:09:01 2016
From: report at bugs.python.org (Alexander Riccio)
Date: Mon, 18 Jan 2016 00:09:01 +0000
Subject: [issue26139] libmpdec: disable /W4 warning (non-standard dllimport
 behavior)
In-Reply-To: <1453030027.6.0.790177544356.issue26139@psf.upfronthosting.co.za>
Message-ID: <1453075741.34.0.0758539255309.issue26139@psf.upfronthosting.co.za>


Alexander Riccio added the comment:

#pragma warning(disable : 4232) is almost always NOT what you want. 

See: http://www.viva64.com/en/k/0048/

----------
nosy: +Alexander Riccio

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 20:05:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jan 2016 01:05:23 +0000
Subject: [issue26142] Formatting bug on
 https://docs.python.org/2.7/c-api/intro.html
In-Reply-To: <1453073854.16.0.698165135506.issue26142@psf.upfronthosting.co.za>
Message-ID: <20160118010519.94202.15575@psf.io>


Roundup Robot added the comment:

New changeset 4f1ed606410b by Senthil Kumaran in branch '2.7':
Issue26142 - Fix a formatting bug in c-api intro doc.
https://hg.python.org/cpython/rev/4f1ed606410b

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 20:05:55 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Jan 2016 01:05:55 +0000
Subject: [issue26142] Formatting bug on
 https://docs.python.org/2.7/c-api/intro.html
In-Reply-To: <1453073854.16.0.698165135506.issue26142@psf.upfronthosting.co.za>
Message-ID: <1453079155.06.0.374061138771.issue26142@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for reporting. Fixed.

----------
nosy: +orsenthil
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 21:43:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jan 2016 02:43:00 +0000
Subject: [issue26017] Update https://docs.python.org/3/installing/index.html
 to always quote arguments
In-Reply-To: <1452015796.73.0.274069830205.issue26017@psf.upfronthosting.co.za>
Message-ID: <20160118024256.25908.98954@psf.io>


Roundup Robot added the comment:

New changeset 31debd0dc0dc by Senthil Kumaran in branch '3.5':
Issue26017 - Suggest enclosing command args in double quotes when using characters which get interpreted by shell.
https://hg.python.org/cpython/rev/31debd0dc0dc

New changeset 18ae23b69e08 by Senthil Kumaran in branch 'default':
Merge from 3.5
https://hg.python.org/cpython/rev/18ae23b69e08

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 21:45:17 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jan 2016 02:45:17 +0000
Subject: [issue26017] Update https://docs.python.org/3/installing/index.html
 to always quote arguments
In-Reply-To: <1452015796.73.0.274069830205.issue26017@psf.upfronthosting.co.za>
Message-ID: <20160118024515.5435.49794@psf.io>


Roundup Robot added the comment:

New changeset 668827be66d6 by Senthil Kumaran in branch '2.7':
Issue26017 - Suggest enclosing command args in double quotes when using characters which get interpreted by shell.
https://hg.python.org/cpython/rev/668827be66d6

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 21:46:31 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Jan 2016 02:46:31 +0000
Subject: [issue26017] Update https://docs.python.org/3/installing/index.html
 to always quote arguments
In-Reply-To: <1452015796.73.0.274069830205.issue26017@psf.upfronthosting.co.za>
Message-ID: <1453085191.83.0.846646415099.issue26017@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the review/comment Ezio. Agree with your suggestion and made the change accordingly.

----------
assignee: docs at python -> orsenthil
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 21:59:56 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 18 Jan 2016 02:59:56 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1453085996.33.0.117948017025.issue19475@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

You can leave out the nanoseconds but please do add the milliseconds. I'm sure they would find more use than the option to show only the hours.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 22:05:31 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 18 Jan 2016 03:05:31 +0000
Subject: [issue26140] inspect.iscoroutinefunction raises TypeError when checks
 Mock of function or coroutinefunction
In-Reply-To: <1453030972.84.0.0646105171888.issue26140@psf.upfronthosting.co.za>
Message-ID: 


Guido van Rossum added the comment:

Why fix this in mock rather than in the iscoroutinefunction functions? (Not
a rhetorical question -- I really am not sure what the better place is to
fix this, or if we should even consider fixing it.)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 22:09:09 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Jan 2016 03:09:09 +0000
Subject: [issue26134] HTTPPasswordMgrWithPriorAuth does not work with
 DigestAuthentication
In-Reply-To: <1452987570.59.0.951573135537.issue26134@psf.upfronthosting.co.za>
Message-ID: <1453086549.87.0.260604835909.issue26134@psf.upfronthosting.co.za>


Changes by Senthil Kumaran :


----------
nosy: +orsenthil

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 22:28:23 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Jan 2016 03:28:23 +0000
Subject: [issue6500] urllib2 maximum recursion depth exceeded
In-Reply-To: <1247819174.12.0.0313325803352.issue6500@psf.upfronthosting.co.za>
Message-ID: <1453087703.56.0.280872628499.issue6500@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

@Serhiy, the patch looks good to me. This change is an excellent idea. Please commit it.

----------
assignee: berker.peksag -> serhiy.storchaka
stage: patch review -> commit review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 23:05:50 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 18 Jan 2016 04:05:50 +0000
Subject: [issue26143] Ensure that IDLE's stdlib imports are from the stdlib
Message-ID: <1453089950.28.0.356846327087.issue26143@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

In the past few months, there has been an increase "IDLE fails to start" reports that are apparently due to shadowing of stdlib modules by user modules in the same directly as as user code.  For instance, a beginner creates turtle.py and then writes "import turtle" in the same file or another in the same directory.

Note that only Python-coded modules can be shadowed. Imports of builtin modules that are not accelerators for a .py module are handled internally and do not involve sys.path.  (If turtle were builtin, turtle.py would not interfere with 'import turtle.) In particular, sys is builtin and 'import sys' is guaranteed to work and give access to sys.path.

CPython avoids shadowing of the stdlib in its own imports.  Perhaps it does not add '', standing for the current working directory, to the front of sys.path until after its imports are done.  A self-contained application can avoid the problem by properly naming its own modules.  An application like IDLE that runs user code needs to protect itself from user files.  It does not now.

IDLE normally runs with two processes. I believe shadowing is more a problem for the user process that executes user code, with the working directory set to that of the user code.  (I believe that this is one reason why user code must be saved, to a particular directory, before it is run.)  Since, with one exception, all imports in run.py are done before running user code, I believe a sufficient fix would be temporarily delete '' while run.py does its own imports.

By default, the IDLE gui process should not have a problem.  The working directory is that of python.exe, which initially has no conflicting files.  To guard against user additions, '' could be permanently removed.  However, for option -n single-process mode, it would have to be restored (a reason for wanting to remove that mode).  I am not sure of the effect of all the other options.  At present, I believe, all imports are done at startup.  So the same idea used for the user process might work, at least for the present.

Automated tests would be nice.  I might want to some day 
limit initial imports to the minimum needed to show the initial window (or windows), so IDLE might start faster.  But they are not trivial.  And there is the time factor. A single cold start of IDLE takes as long (about 4 seconds on my machine) as the average test file in the test suite.

----------
messages: 258496
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Ensure that IDLE's stdlib imports are from the stdlib
type: behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 23:12:25 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jan 2016 04:12:25 +0000
Subject: [issue26069] Remove the Deprecated API in trace module
In-Reply-To: <1452385226.89.0.6584761467.issue26069@psf.upfronthosting.co.za>
Message-ID: <20160118041221.18413.38838@psf.io>


Roundup Robot added the comment:

New changeset 715d8a739f3b by Senthil Kumaran in branch 'default':
Issue26069 - Update whatsnew/3.6.rst on traceback module's api removals.
https://hg.python.org/cpython/rev/715d8a739f3b

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 00:14:05 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 18 Jan 2016 05:14:05 +0000
Subject: [issue25514] Improve IDLE's "subprocess didn't make connection"
 message
In-Reply-To: <1446151640.74.0.583734209916.issue25514@psf.upfronthosting.co.za>
Message-ID: <1453094045.34.0.591891242038.issue25514@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I have seen another report that is likely due to masking.  I don't know why this has suddenly become seemingly much more common, but I have made fixing the problem a priority.  See new issue #26143.

I would like to narrow this issue to the user process, and broaden it to reporting all currently plausible causes of non-connection.  I revised the title to say this.

I am looking  at https://stackoverflow.com/questions/15888186/cant-run-python-via-idle-from-explorer-2013-idles-subprocess-didnt-make-c to see what causes people have found or think they have found.

1. Antivirus/firewall (4 people, linux iptables, Windows firewall, antivisus , so not a myth ;-)
2. Shadow files, as described above, and in the python directory (about as common, tkinter,py, subprocess.py).
3. Registry problem (some people can fix, but most should re-install after complete removal).
4. Zombie pythonw process (kill with Windows Task manager).
5. Permissions (run as admin, though should not be needed with proper install)
?. Multiple installed versions clash due to misconfiguration?

https://stackoverflow.com/questions/874757/python-idle-subprocess-error
Add:
?. example program that reads and writes (test)
6. Running after stopping run with ^C (temporary, I believe Restart Shell will fix)  Call this a timing issue.
<>
7. Modem rebot (rather obsolete answer for most of us).

There are plenty of miscellaneous possibilities to add even if masking, the most common reason, is fixed.

----------
title: better startup error messages in IDLE when stdlib modules shadowed -> Improve IDLE's  "subprocess didn't make connection" message

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 00:22:45 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 18 Jan 2016 05:22:45 +0000
Subject: [issue26143] Ensure that IDLE's stdlib imports are from the stdlib
In-Reply-To: <1453089950.28.0.356846327087.issue26143@psf.upfronthosting.co.za>
Message-ID: <1453094565.58.0.808102952327.issue26143@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Looking at https://stackoverflow.com/questions/15888186/cant-run-python-via-idle-from-explorer-2013-idles-subprocess-didnt-make-c and https://stackoverflow.com/questions/874757/python-idle-subprocess-error it seems that people have put things like tkinter.py, random.py, and subprocess.py in the python directory, along side of python.exe.  So the IDLE process definitely also needs a patch.

----------
assignee:  -> terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 00:27:40 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 18 Jan 2016 05:27:40 +0000
Subject: [issue26144] test_pkg test_4 and/or test_7 sometimes fail
Message-ID: <1453094860.75.0.307197769475.issue26144@psf.upfronthosting.co.za>


New submission from Martin Panter:

It doesn?t always fail, and sometimes only one or the other test fails. Also, it seems to depend on the way the tests are run. I have never seen it fail with ?python -m test -v?. Two commands where it does often fail for me:

./python -m test -w test_pkg
./python -m unittest -v test.test_pkg

Here is the output when both tests fail:

test_1 (test.test_pkg.TestPkg) ... ok
test_2 (test.test_pkg.TestPkg) ... ok
test_3 (test.test_pkg.TestPkg) ... ok
test_4 (test.test_pkg.TestPkg) ... ERROR
test_5 (test.test_pkg.TestPkg) ... ok
test_6 (test.test_pkg.TestPkg) ... ok
test_7 (test.test_pkg.TestPkg) ... FAIL
test_8 (test.test_pkg.TestPkg) ... ok

======================================================================
ERROR: test_4 (test.test_pkg.TestPkg)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/test/test_pkg.py", line 180, in test_4
    self.run_code(s)
  File "/media/disk/home/proj/python/cpython/Lib/test/test_pkg.py", line 69, in run_code
    exec(textwrap.dedent(code), globals(), {"self": self})
  File "", line 2, in 
  File "/tmp/tmprhpx80bw/t4.py", line 1, in 
RuntimeError: Shouldnt load t4.py

======================================================================
FAIL: test_7 (test.test_pkg.TestPkg)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/test/test_pkg.py", line 260, in test_7
    '__name__', '__package__', '__path__', '__spec__'])
AssertionError: Lists differ: ['__c[34 chars]__loader__', '__name__', '__package__', '__spec__'] != ['__c[34 chars]__loader__', '__name__', '__package__', '__path__', '__spec__']

First differing element 6:
__spec__
__path__

Second list contains 1 additional elements.
First extra element 7:
__spec__

  ['__cached__',
   '__doc__',
   '__file__',
   '__loader__',
   '__name__',
   '__package__',
+  '__path__',
   '__spec__']

----------------------------------------------------------------------
Ran 8 tests in 0.038s

FAILED (failures=1, errors=1)

----------
components: Tests
messages: 258500
nosy: martin.panter
priority: normal
severity: normal
status: open
title: test_pkg test_4 and/or test_7 sometimes fail
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 00:36:47 2016
From: report at bugs.python.org (Martin Dengler)
Date: Mon, 18 Jan 2016 05:36:47 +0000
Subject: [issue557704] netrc module can't handle all passwords
Message-ID: <1453095407.69.0.657431581122.issue557704@psf.upfronthosting.co.za>


Martin Dengler added the comment:

Anecdotal ( http://stackoverflow.com/a/12675195/2747741 ) evidence suggests other programs do indeed accept spaces, and a cursory browsing of the Perl source code ( http://perl5.git.perl.org/perl.git/blob/HEAD:/cpan/libnet/lib/Net/Netrc.pm#l120 ) indicates Perl at least supports (escaped) spaces in .netrc passwords.

Is there anything that I could do to make the patch I provided acceptable?

If not, could the bug be reopened as 1) the bug description mentions a valid use case that is not handled by the netrc module; and 2) there is precedent for this use case's implementation in other software.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 01:23:06 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 18 Jan 2016 06:23:06 +0000
Subject: [issue557704] netrc module can't handle all passwords
Message-ID: <1453098186.56.0.536388995309.issue557704@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

(Hi Bram! :-)

So does your patch also accept escaped spaces? I wonder if one of the problems here may not be that the syntax required to escape special characters isn't specified? That might be acceptable in 2003, not so much in 2016.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 01:45:37 2016
From: report at bugs.python.org (Martin Dengler)
Date: Mon, 18 Jan 2016 06:45:37 +0000
Subject: [issue557704] netrc module can't handle all passwords
Message-ID: <1453099537.24.0.465905150982.issue557704@psf.upfronthosting.co.za>


Martin Dengler added the comment:

Bram's patch for "special" characters is in, mine is the one that allows spaces in .netrc by enabling the parsing of a password field's value that's surrounded by lexer.quotes ( https://hg.python.org/cpython/file/2.7/Lib/shlex.py#l45 ).

This is not the same as Perl's approach (parse the file in a quoted-character-aware way, so quoted spaces don't separate tokens), but was much simpler to implement.

So, in effect, there are no general support for quoting introduced by my patch, only a special case for supporting the entire contents of the password field to be surrounded by the shlex.quote characters.

Would you accept a different (longer, more involved) patch to implement the arbitrary quoting of characters, or an update to this patch to document how the password field is treated and which characters can surround it?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 03:40:50 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jan 2016 08:40:50 +0000
Subject: [issue6500] urllib2 maximum recursion depth exceeded
In-Reply-To: <1247819174.12.0.0313325803352.issue6500@psf.upfronthosting.co.za>
Message-ID: <20160118084046.96358.15365@psf.io>


Roundup Robot added the comment:

New changeset d34fdd1736f2 by Serhiy Storchaka in branch '2.7':
Issue #6500: Fixed infinite recursion in urllib2.Request.__getattr__().
https://hg.python.org/cpython/rev/d34fdd1736f2

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 03:55:41 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Jan 2016 08:55:41 +0000
Subject: [issue26121] Use C99 functions in math if available
In-Reply-To: <1452858135.55.0.233335376493.issue26121@psf.upfronthosting.co.za>
Message-ID: <1453107341.95.0.621794625063.issue26121@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

LGTM. What platform are the benchmarks on?

Is there some way that this can be submitted to the buildbots *before* applying to the 3.6 branch, so that we can get a sense of how widespread (if at all) libm problems are?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 03:59:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Jan 2016 08:59:33 +0000
Subject: [issue6500] urllib2 maximum recursion depth exceeded
In-Reply-To: <1247819174.12.0.0313325803352.issue6500@psf.upfronthosting.co.za>
Message-ID: <1453107573.3.0.361966895048.issue6500@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for the review Senthil.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 04:01:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 09:01:24 +0000
Subject: [issue26100] Add test.support.optim_args_from_interpreter_flags()
In-Reply-To: <1452702751.92.0.809582535795.issue26100@psf.upfronthosting.co.za>
Message-ID: <1453107684.29.0.0149718464093.issue26100@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Lib/distutils/util.py must also be modified: see attached distutils.patch.

----------
Added file: http://bugs.python.org/file41642/distutils.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 04:01:31 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 09:01:31 +0000
Subject: [issue26100] PEP 511: Add
 test.support.optim_args_from_interpreter_flags()
In-Reply-To: <1452702751.92.0.809582535795.issue26100@psf.upfronthosting.co.za>
Message-ID: <1453107691.57.0.109267751931.issue26100@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
title: Add test.support.optim_args_from_interpreter_flags() -> PEP 511: Add test.support.optim_args_from_interpreter_flags()

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 04:04:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Jan 2016 09:04:39 +0000
Subject: [issue26121] Use C99 functions in math if available
In-Reply-To: <1452858135.55.0.233335376493.issue26121@psf.upfronthosting.co.za>
Message-ID: <1453107879.79.0.270992641526.issue26121@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The benchmarks were ran on 32-bit Linux with AMD processor.

I'll try to run custom build on buildbots.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 04:10:59 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 09:10:59 +0000
Subject: [issue26145] PEP 511: Add sys.set_code_transformers()
Message-ID: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch implements the largest part of the PEP 511:

* add sys.get_code_transformers() and sys.set_code_transformers()
* add sys.implementation.optim_tag
* add -o command line option setting sys.implementation.optim_tag
* modify importlib to use sys.implementation.optim_tag to build .pyc filenames
* modify importlib to raise an ImportError when the .pyc file is missing, the .py is available, and the optimizer tag created from code transformers is different than the current sys.implementation.optim_tag
* add Lib/test/test_pep511.py: test changes especially bytecode and AST transformers
* add a PeepholeOptimizer object created by default for sys.set_code_transformers()
* skip the peephole optimizer when -o noopt is used
* add sys field to the PyInterpreterState structure: used by _PySys_GetCodeTransformers() to get code transformers
* update unit tests to use the optimizer to create the .pyc filename

An optimizer tag must contain characters: '.', '-', directory separators or NUL character.

Brett Canon proposed to not include the optimizer tag in .pyc filenames if it is "opt" to limit backward incompatible changes.

Note: The PEP 511 is under discussion on python-ideas. The patch implements the first version of the PEP, sent to python-ideas, so it doesn't include proposed changes like changing code_transformer() prototype to "def code_transformer(self, code, context)".

See also the issue #26100: add test.support.optim_args_from_interpreter_flags().

----------
files: transformers.patch
keywords: patch
messages: 258509
nosy: brett.cannon, haypo
priority: normal
severity: normal
status: open
title: PEP 511: Add sys.set_code_transformers()
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41643/transformers.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 04:12:29 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 09:12:29 +0000
Subject: [issue26099] site ignores ImportError when running sitecustomize and
 usercustomize
In-Reply-To: <1452696404.05.0.367833198211.issue26099@psf.upfronthosting.co.za>
Message-ID: <1453108349.45.0.336579389155.issue26099@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Example of the bug:

----
$ cat Lib/sitecustomize.py
print("before")
import xxx
print("after")

haypo at smithers$ ./python -q -c pass
before
----

The line "after" is not executed and *no* error nor warning is raised. With the patch:

----
$ ./python -q -c pass
before
Error in sitecustomize; set PYTHONVERBOSE for traceback:
ImportError: No module named 'xxx'

$ PYTHONVERBOSE=1 ./python -q -c pass
(...)
# /home/haypo/prog/python/3.5/Lib/__pycache__/sitecustomize.cpython-35.pyc matches /home/haypo/prog/python/3.5/Lib/sitecustomize.py
# code object from '/home/haypo/prog/python/3.5/Lib/__pycache__/sitecustomize.cpython-35.pyc'
before
Traceback (most recent call last):
  File "/home/haypo/prog/python/3.5/Lib/site.py", line 508, in execsitecustomize
    import sitecustomize
  File "", line 969, in _find_and_load
  File "", line 958, in _find_and_load_unlocked
  File "", line 673, in _load_unlocked
  File "", line 662, in exec_module
  File "", line 222, in _call_with_frames_removed
  File "/home/haypo/prog/python/3.5/Lib/sitecustomize.py", line 2, in 
    import xxx
  File "", line 969, in _find_and_load
  File "", line 956, in _find_and_load_unlocked
ImportError: No module named 'xxx'
# destroy sitecustomize
(...)
----

Brett Cannon: "This is a change in semantics."

Can you please elaborate? Even if importing sitecustomize changes, Python continue its execution. Only a warning is emited.

Brett Cannon: "It might be better to log an ImportWarning when the import fails and keep the current semantics (and be careful about importing warnings)."

With my patch, a message "Error in sitecustomize; set PYTHONVERBOSE for traceback:" is logged. I used the same behaviour then the code to handle site import.

Note: I found this issue when I worked on the PEP 511 to register a code transformer at startup. The bug is really annoying: the code transformers may or may not be registered depending if required modules can be important, I expect an error (or at least a warning).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 04:15:16 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 09:15:16 +0000
Subject: [issue26145] PEP 511: Add sys.set_code_transformers()
In-Reply-To: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>
Message-ID: <1453108516.5.0.598970697603.issue26145@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Missing patch for test_sys testing the new sys.get/set_code_transformers() functions.

----------
Added file: http://bugs.python.org/file41644/test_sys.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 04:16:38 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 09:16:38 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1453108598.11.0.681107541953.issue26107@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
title: code.co_lnotab: use signed line number delta to support moving instructions in an optimizer -> PEP 511: code.co_lnotab: use signed line number delta to support moving instructions in an optimizer

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 05:26:55 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jan 2016 10:26:55 +0000
Subject: [issue26101] Lib/test/test_compileall.py fails when run directly
In-Reply-To: <1452703257.16.0.0951114007651.issue26101@psf.upfronthosting.co.za>
Message-ID: <20160118102652.25930.10838@psf.io>


Roundup Robot added the comment:

New changeset c6a0f424837a by Victor Stinner in branch 'default':
Fix test_compilepath() of test_compileall
https://hg.python.org/cpython/rev/c6a0f424837a

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 05:53:47 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 10:53:47 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1453114427.68.0.075676182868.issue26107@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 2 to take Serhiy's review in account:

* complete Objects/lnotab_notes.txt update. Replace (300, 300) delta example with (300, 200) delta for better readability (300 is the bytecode offset delta, 200 is the line number delta)
* fix added assertion in peephole: don't check the reference counter for empty byte string (which can be the empty byte string singleton)
* restore addrmap name in peephole
* don't change importlib MAGIC: we only change it between Python minor versions, it was already changed for Python 3.6a0
* assemble_lnotab() divide with positive numbers to avoid undefined behaviour on C
* dis.py: use "if line_incr >= 0x80: line_incr -= 0x100" instead of struct.unpack() to convert unsigned to signed

Note: avoid also useless "if (x != NULL)" checks before calling PyMem_Free(). PyMem_Free(NULL) is well specified: do nothing.

----------
Added file: http://bugs.python.org/file41645/lnotab-2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 06:00:29 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 11:00:29 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1453114829.46.0.15247398221.issue26107@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 3:

* When I reviewed issue #16956 patch, I noticed that I forgot to extract my changes on codeobject.c :-/ (FAT Python became a giant patch, it's hard to browse it!)
* Fix typo in dis.py (regression of patch 2)

----------
Added file: http://bugs.python.org/file41646/lnotab-3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 06:06:32 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 11:06:32 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1453115192.75.0.333822195084.issue26107@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> A patch was proposed in issue16956. And issue17611 is related.

I don't see directly the link between this issue and the issue17611, but cool if it helps to implement new optimizations :-)

I compared my patch with issue16956 patch:

* my patch mentions also the change in Lib/importlib/_bootstrap_external.py
* my patch updates also dis.py
* my patch updates also Objects/lnotab_notes.txt
* issue16956 patch changes compiler_while(), this change is not directly related to making line number delta signed

Additionally, my patch uses better names in the peephole optimizer, but it's not directly related to the issue. By the way, this change should be commited in a separated patch.

I prefer to push my recent. By the way, it's up to date, whereas issue16956 patch requires a rebase.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 06:07:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 11:07:19 +0000
Subject: [issue26101] Lib/test/test_compileall.py fails when run directly
In-Reply-To: <1452703257.16.0.0951114007651.issue26101@psf.upfronthosting.co.za>
Message-ID: <1453115239.04.0.402151069732.issue26101@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
components: +Tests
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 06:16:02 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jan 2016 11:16:02 +0000
Subject: [issue26100] PEP 511: Add
 test.support.optim_args_from_interpreter_flags()
In-Reply-To: <1452702751.92.0.809582535795.issue26100@psf.upfronthosting.co.za>
Message-ID: <20160118111559.94216.82419@psf.io>


Roundup Robot added the comment:

New changeset ac6d33317eda by Victor Stinner in branch 'default':
subprocess._optim_args_from_interpreter_flags()
https://hg.python.org/cpython/rev/ac6d33317eda

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 06:16:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 11:16:14 +0000
Subject: [issue26100] PEP 511: Add
 test.support.optim_args_from_interpreter_flags()
In-Reply-To: <1452702751.92.0.809582535795.issue26100@psf.upfronthosting.co.za>
Message-ID: <1453115774.09.0.486625273393.issue26100@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 06:33:44 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 18 Jan 2016 11:33:44 +0000
Subject: [issue13886] readline-related test_builtin failure
In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za>
Message-ID: <1453116824.73.0.129677936894.issue13886@psf.upfronthosting.co.za>


Martin Panter added the comment:

I don?t think this affects Python 2. The failing tests were added in revision 421c8e291221, Issue 13342, for 3.2+ only. They invole input() doing text decoding. AFAIK Python 2?s equivalent, raw_input(), does not do text decoding.

I suspect we can?t really change how Readline handles text encoding errors, which seems to be what Nadeem was trying to do. I suggest to just fix the tests without changing Readline.

As far as I know there is no way to un-register the Readline module once it has been loaded. A quick and dirty workaround might be to skip the test(s) if the Readline has been loaded ("readline" in sys.modules). But a better fix would probably be to run the test in a subprocess, where we can start a new interpreter from scratch and control whether Readline is loaded.

Looking closer at the tests, they mention invoking Gnu Readline. But the associated bug fix is in the wrapper code around PyOS_Readline(), which may call Gnu Readline if it is loaded, or may call a simpler internal routine otherwise. So ideally the tests should be repeated with Readline unloaded and loaded.

Also, the comment for test_input_tty_non_ascii() implies it is testing UTF-8 encoding. But the data is not valid UTF-8 so it ends up testing the error handling. I think that test should use valid UTF-8 input.

----------
components: +Tests -Extension Modules
nosy: +martin.panter
versions: +Python 3.5, Python 3.6 -Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 06:39:14 2016
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 18 Jan 2016 11:39:14 +0000
Subject: [issue26139] libmpdec: disable /W4 warning (non-standard dllimport
 behavior)
In-Reply-To: <1453030027.6.0.790177544356.issue26139@psf.upfronthosting.co.za>
Message-ID: <1453117154.15.0.540695045956.issue26139@psf.upfronthosting.co.za>


Stefan Krah added the comment:

This is *exactly* what I want.  As the sole author of libmpdec I *know*
that the broken dllimport behavior cannot affect anything in memory.c,
since there are no function pointer comparisons.

Please stop educating us.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 06:43:22 2016
From: report at bugs.python.org (Alexander Riccio)
Date: Mon, 18 Jan 2016 11:43:22 +0000
Subject: [issue26139] libmpdec: disable /W4 warning (non-standard dllimport
 behavior)
In-Reply-To: <1453030027.6.0.790177544356.issue26139@psf.upfronthosting.co.za>
Message-ID: <1453117402.1.0.226604700439.issue26139@psf.upfronthosting.co.za>


Alexander Riccio added the comment:

> Please stop educating us.

Sorry, not what was intended! Tone transmits poorly.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 06:57:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Jan 2016 11:57:53 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1453118273.97.0.244358939623.issue26107@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, you patch supersedes issue16956 patch.

Added new comments on Rietveld for lnotab_notes.txt.

I afraid this patch can cause problems with code tracing where it is assumed that lines are increased monotonically and *instr_lb <= frame->f_lasti < *instr_ub. We should carefully analyze the effect of the patch on the tracing.

Before committing you must ask Guido for approval. AFAIK his had objections against code transformations that make debugging harder.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 07:54:47 2016
From: report at bugs.python.org (Hiroyuki Takagi)
Date: Mon, 18 Jan 2016 12:54:47 +0000
Subject: [issue26140] inspect.iscoroutinefunction raises TypeError when checks
 Mock of function or coroutinefunction
In-Reply-To: <1453030972.84.0.0646105171888.issue26140@psf.upfronthosting.co.za>
Message-ID: <1453121687.01.0.180191013411.issue26140@psf.upfronthosting.co.za>


Hiroyuki Takagi added the comment:

Thank you for review and comment.

Honestly speaking, I couldn't find any other good place to fix it.

One possible solution might be to use isinstance(mock, Mock) in iscoroutinefunction, but I don't think it's good for inspect module to add special check and depend on unittest.mock. Mocks are usually used only in debug/test, but iscoroutinefunction is used in production code. Adding some check to iscoroutinefunction only for test is not good for performance (though, actually its effect will be very small).

The reasons why I think this behavior should be fixed are,

    - Raising error and stopping test is not kind for mock users
    - After the patch (issue25599), no mock object can become `True` to iscoroutinefunction, which will make it impossible to test the block after if-iscoroutinefunction by using mock.


Now, I checked inspect module again, and found one more unexpected behavior (not error).

>>> def a(): yield 1
>>> inspect.isgeneratorfunction(a)
    True

>>> inspect.isgeneratorfunction(Mock(a))
    False

With the patch, inspect.isgeneratorfunction(Mock(a)) returns True.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 08:31:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 13:31:27 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1453123887.2.0.536575185393.issue26107@psf.upfronthosting.co.za>


STINNER Victor added the comment:

We have many unit test in the Python test suite which rely on exact line numbers. Examples:

* test_sys_settrace
* test_pdb
* test_dis

I know them because they were all broken when my fatoptimizer project had bugs related to line numbers :-)

With my patch, the full Python test suite pass whereas my patch doesn't modify any test.


> I afraid this patch can cause problems with code tracing where it is assumed that lines are increased monotonically and *instr_lb <= frame->f_lasti < *instr_ub. We should carefully analyze the effect of the patch on the tracing.

First, my patch has no impact on frame->f_lasti.

The trace module and test_sys_settrace use frame.f_lineno which PyFrame_GetLineNumber(). This function returns f->f_lineno if the frame has a trace function, or PyCode_Addr2Line(). PyCode_Addr2Line() and PyFrame_GetLineNumber() still work with my patch.

When you trace a program, "negative line delta" and "negative instruction offset" are not new in Python: it's a basic requirement to support loop, when you compare two instructions seen by the tracer.

To be clear, my patch does *not* introduce negative line number delta in co_lnotab. It only *adds support* for negative line number delta. If a tool decodes co_lnotab using 8-bit unsigned number for line number delta, the tool still works even with the patch. It only starts to return wrong line numbers if you start debugging a program which has negative line numbers.

If you use fatoptimizer, you get such negative delta. But if you use an optimizer, you should be prepared to some subtle differences. The good practice is to disable all optimizers when you debug code. It's also really hard (or impossible) to debug C code optimized with -O3. I always use gcc -O0 to debug CPython.


> Before committing you must ask Guido for approval. AFAIK his had objections against code transformations that make debugging harder.

Are you aware of tools decoding directly co_lnotab?

Oh, I forgot the old Misc/gdbinit script which *does* decode directly co_lnotab. Does anyone still use it? If yes, it should also be updated.

I failed to reproduce the bug with Misc/gdbinit, beacuse bug only occurs if you debug a program which uses negative line number, and CPython doesn't produce negative line number in co_lnotab by default... So it would be "nice" to also support negative line number in Misc/gdbinit, but maybe it's ok to let this old script dying? :-D

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 08:38:40 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 13:38:40 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1453124320.21.0.801513038189.issue26107@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Are you aware of tools decoding directly co_lnotab?

Ah! I found Ned Batchelder's coverage project which has a _bytes_lines() method "adapted from dis.py in the standard library". The method uses directly co_lnotab to compute line numbers.

Ok, *this project* will have to be updated if it wants to support fatoptimizer and other code transformers producing negative line numbers.

Maybe I can contribute to it with a patch if my change to CPython 3.6 is accepted ;-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 09:36:59 2016
From: report at bugs.python.org (Paul Hammant)
Date: Mon, 18 Jan 2016 14:36:59 +0000
Subject: [issue26119] Windows Installer can sometimes silently fail pip stage
In-Reply-To: <1452830051.37.0.928414799264.issue26119@psf.upfronthosting.co.za>
Message-ID: <1453127819.56.0.55043488454.issue26119@psf.upfronthosting.co.za>


Paul Hammant added the comment:

That's all the files in the %TEMP% dir beginning with Python* - right?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 11:51:21 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jan 2016 16:51:21 +0000
Subject: [issue26129] Difference in behaviour with grp.getgrgid and
 pwd.getpwuid
In-Reply-To: <1452887305.34.0.0492943983639.issue26129@psf.upfronthosting.co.za>
Message-ID: <20160118165117.94218.89406@psf.io>


Roundup Robot added the comment:

New changeset 65e0e06b70b6 by Serhiy Storchaka in branch 'default':
Issue #26129: Deprecated accepting non-integers in grp.getgrgid().
https://hg.python.org/cpython/rev/65e0e06b70b6

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 11:53:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Jan 2016 16:53:45 +0000
Subject: [issue26129] Difference in behaviour with grp.getgrgid and
 pwd.getpwuid
In-Reply-To: <1452887305.34.0.0492943983639.issue26129@psf.upfronthosting.co.za>
Message-ID: <1453136025.44.0.801184103098.issue26129@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Brett.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 12:01:20 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Jan 2016 17:01:20 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1453136480.23.0.380535778841.issue26107@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I just wanted to comment on "don't change importlib MAGIC: we only change it between Python minor versions": that's actually not true. Feel free to up the number whenever you make a change that affects eval.c or bytecode. Otherwise .pyc files won't be regenerated. And that number is cheap anyway and isn't about to run out, so don't worry about updating it multiple times before the code sees a public release.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 12:04:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 17:04:52 +0000
Subject: [issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit
 constants
Message-ID: <1453136691.51.0.69393755181.issue26146@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Currently, the Python parser emits ast.Tuple AST nodes which are compiled to multiple LOAD_xxx instructions followed a final BUILD_TUPLE instruction. The Python peephole optimizer detect LOAD_CONST x n + BUILD_TUPLE instructions to replace it directly with a tuple constant.

IHMO it's better to implement this optimization early at the AST level in an AST optimizer. The PEP 511 proposes to add a new ast.Constant AST node for that.

With this new AST node, the AST optimizer can emit tuple constants, but also any kind of constant like frozenset. For example, it's also possible to optimize "x in {1, 2}" to "x in frozenset({1, 2})" where frozenset({1, 2}) is a constant (don't call frozenset type at runtime). (Again, this optimization is already implemented in the peephole optimizer, it's just an example.)

Attached patch adds the new ast.Constant type but update also code consuming AST to handle this new kind of node:

* add the node: Parser/Python.asdl, Parser/asdl.py, Parser/asdl_c.py
* generated changes: Include/asdl.h, Include/Python-ast.h, Python/Python-ast.c
* accept the node kind: Python/symtable.c, Python/ast.c
* accept Constant instead of Num or Str: Lib/ast.py, Python/future.c, Tools/parser/unparse.py
* emit constants to bytecode: Python/compile.c

I didn't change the compiler to emit directly ast.Constant nodes to reduce the impact on the backward compatibility. This change can be done. An AST optimizer is responsible to convert NameConstant (False, True, None), Num (int, float, complex), Str, Bytes, Tuple to Constant. Example with fatoptimizer:
https://github.com/haypo/fatoptimizer/blob/2d794f511fe23ccde320725c6d12ce5ce8ffbdfe/fatoptimizer/convert_const.py

ast.Constant also simplifies AST optimizers: no need to check each time if a node is constant or not.

Adding a new kind of node was already proposed in the old issue #11549: the patch adds ast.Lit (it was proposed to rename it to ast.Literal).

----------
files: constant.patch
keywords: patch
messages: 258528
nosy: benjamin.peterson, brett.cannon, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: PEP 511: Add ast.Constant to allow AST optimizer to emit constants
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41647/constant.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 12:08:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 17:08:23 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1453136480.23.0.380535778841.issue26107@psf.upfronthosting.co.za>
Message-ID: 


STINNER Victor added the comment:

Brett Cannon added the comment:
> I just wanted to comment on "don't change importlib MAGIC: we only change it between Python minor versions": that's actually not true. Feel free to up the number whenever you make a change that affects eval.c or bytecode. Otherwise .pyc files won't be regenerated. And that number is cheap anyway and isn't about to run out, so don't worry about updating it multiple times before the code sees a public release.

Since my patch may break setup of multiple python developers, it can
be worth to increase this number, ok :-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 12:11:09 2016
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Mon, 18 Jan 2016 17:11:09 +0000
Subject: [issue25731] Assigning and deleting __new__ attr on the class does
 not allow to create instances of this class
In-Reply-To: <1448454590.41.0.350843358205.issue25731@psf.upfronthosting.co.za>
Message-ID: <1453137069.2.0.831872701576.issue25731@psf.upfronthosting.co.za>


Bohuslav "Slavek" Kabrda added the comment:

Hi, I'm maintainer of flexmock [1] and some users of my library have started hitting this bug [2] - when one tries to mock __new__ and then revert this mock at the end of testcase to the original one (either by deleting the mock __new__ or replacing mock __new__ by the old one), then one gets "TypeError: object() takes no parameters".

I think that solution proposed by Eryk is correct, but I don't have that much insight into Python internals to confirm that 100 %. I would appreciate this getting fixed. Thanks!

[1] https://github.com/bkabrda/flexmock
[2] https://github.com/bkabrda/flexmock/issues/13

----------
nosy: +bkabrda

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 12:21:37 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 17:21:37 +0000
Subject: [issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit
 constants
In-Reply-To: <1453136691.51.0.69393755181.issue26146@psf.upfronthosting.co.za>
Message-ID: <1453137697.66.0.887507520474.issue26146@psf.upfronthosting.co.za>


STINNER Victor added the comment:

To support emiting constants from ast.Constant, we will also need the fix for the issue #25843. Currently, the compile merges constants (0, 0) and (0.0, 0.0) because they are equal, but item types are different.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 12:22:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 17:22:14 +0000
Subject: [issue25843] lambdas on the same line may incorrectly share code
 objects
In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za>
Message-ID: <1453137734.34.0.657625636654.issue25843@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FYI this issue is linked to the issue #26146 which allows to emit constants from an AST optimizer (see also the PEP 511).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 12:32:47 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Jan 2016 17:32:47 +0000
Subject: [issue557704] netrc module can't handle all passwords
Message-ID: <1453138367.21.0.433720893708.issue557704@psf.upfronthosting.co.za>


R. David Murray added the comment:

If it is a matter of following "the normal rules" about quoting in a place where we currently don't do that, I think it would be sensible to add it, but IMO it should be the full set of "normal rules".  Presumably shlex provides facilities to do that...I haven't looked at the netrc code in quite a while so I don't remember how it all fits together.

As for reopening the issue...there was something that was fixed here, so what we should do instead is open a new issue with your documentation about current reality, a quick summary of this discussion, and a mention of this issue as part of the backstory.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 12:40:50 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jan 2016 17:40:50 +0000
Subject: [issue21847] Fix xmlrpc in unicodeless build
In-Reply-To: <1403594988.87.0.830257217468.issue21847@psf.upfronthosting.co.za>
Message-ID: <20160118174047.121296.74705@psf.io>


Roundup Robot added the comment:

New changeset f602dfd35cd4 by Serhiy Storchaka in branch '2.7':
Issue #21847: Fixed xmlrpclib and tests on Unicode-disabled builds.
https://hg.python.org/cpython/rev/f602dfd35cd4

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 12:40:50 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jan 2016 17:40:50 +0000
Subject: [issue9006] xml-rpc Server object does not propagate the encoding to
 Unmarshaller
In-Reply-To: <1276680036.39.0.0895862907842.issue9006@psf.upfronthosting.co.za>
Message-ID: <20160118174047.121296.2985@psf.io>


Roundup Robot added the comment:

New changeset 04e95f05aafe by Serhiy Storchaka in branch '2.7':
Issue #9006: Added tests for XML RPC with non-UTF-8 encoding.
https://hg.python.org/cpython/rev/04e95f05aafe

New changeset 59cb8811286a by Serhiy Storchaka in branch '3.5':
Issue #9006: Added tests for XML RPC with non-UTF-8 encoding.
https://hg.python.org/cpython/rev/59cb8811286a

New changeset 96a7603d25ea by Serhiy Storchaka in branch 'default':
Issue #9006: Added tests for XML RPC with non-UTF-8 encoding.
https://hg.python.org/cpython/rev/96a7603d25ea

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 12:41:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Jan 2016 17:41:53 +0000
Subject: [issue21847] Fix xmlrpc in unicodeless build
In-Reply-To: <1403594988.87.0.830257217468.issue21847@psf.upfronthosting.co.za>
Message-ID: <1453138913.52.0.216949091111.issue21847@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
assignee:  -> serhiy.storchaka
dependencies:  -Fix unicodeless build of Python
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 12:43:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Jan 2016 17:43:09 +0000
Subject: [issue9006] xml-rpc Server object does not propagate the encoding to
 Unmarshaller
In-Reply-To: <1276680036.39.0.0895862907842.issue9006@psf.upfronthosting.co.za>
Message-ID: <1453138989.22.0.444756558587.issue9006@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 12:44:22 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Jan 2016 17:44:22 +0000
Subject: [issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit
 constants
In-Reply-To: <1453136691.51.0.69393755181.issue26146@psf.upfronthosting.co.za>
Message-ID: <1453139062.24.0.137616075719.issue26146@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Would it make sense to tag the type of the constant in the node somehow?

We also make no backwards-compatibility guarantees about the AST, so if it simplifies things to switch entirely to Constant from Num, etc. then I said do it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 13:21:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Jan 2016 18:21:49 +0000
Subject: [issue26147] Encoding errors in xmlrpc
Message-ID: <1453141309.77.0.0400539753207.issue26147@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes issue with sending non-encodable string via XML RPC. This issue caused raising an exception or even hanging.

----------
components: Library (Lib), XML
files: xmlrpc_escape_nonencodable-3.x.patch
keywords: patch
messages: 258537
nosy: loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Encoding errors in xmlrpc
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41648/xmlrpc_escape_nonencodable-3.x.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 13:22:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Jan 2016 18:22:03 +0000
Subject: [issue26147] Encoding errors in xmlrpc
In-Reply-To: <1453141309.77.0.0400539753207.issue26147@psf.upfronthosting.co.za>
Message-ID: <1453141323.01.0.458652457505.issue26147@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file41649/xmlrpc_escape_nonencodable-2.7.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 13:26:52 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 18 Jan 2016 18:26:52 +0000
Subject: [issue25843] lambdas on the same line may incorrectly share code
 objects
In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za>
Message-ID: <1453141612.66.0.984897927089.issue25843@psf.upfronthosting.co.za>


Changes by Mark Lawrence :


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 13:54:08 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 18 Jan 2016 18:54:08 +0000
Subject: [issue26140] inspect.iscoroutinefunction raises TypeError when checks
 Mock of function or coroutinefunction
In-Reply-To: <1453030972.84.0.0646105171888.issue26140@psf.upfronthosting.co.za>
Message-ID: <1453143248.06.0.909567514478.issue26140@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

It looks like this should be fixed in the mock module, as special casing it in inspect doesn't look right.  Unfortunately, I can't review this patch, as I don't know the mock module internals and I don't think I understand all consequences of this patch.

Michael, what do you think?

----------
nosy: +michael.foord

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 13:55:22 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 18 Jan 2016 18:55:22 +0000
Subject: [issue26145] PEP 511: Add sys.set_code_transformers()
In-Reply-To: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>
Message-ID: <1453143322.61.0.383106291404.issue26145@psf.upfronthosting.co.za>


Changes by Yury Selivanov :


----------
nosy: +yselivanov

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 14:20:34 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Mon, 18 Jan 2016 19:20:34 +0000
Subject: [issue25958] Implicit ABCs have no means of "anti-registration"
In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za>
Message-ID: <1453144834.95.0.447869990083.issue25958@psf.upfronthosting.co.za>


Andrew Barnert added the comment:

Style changes based on Martin's review

----------
Added file: http://bugs.python.org/file41650/patch5.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 14:21:36 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Mon, 18 Jan 2016 19:21:36 +0000
Subject: [issue25958] Implicit ABCs have no means of "anti-registration"
In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za>
Message-ID: <1453144896.29.0.097778893314.issue25958@psf.upfronthosting.co.za>


Changes by Andrew Barnert :


Removed file: http://bugs.python.org/file41650/patch5.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 14:26:33 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Mon, 18 Jan 2016 19:26:33 +0000
Subject: [issue25958] Implicit ABCs have no means of "anti-registration"
In-Reply-To: <1451168802.83.0.911068284232.issue25958@psf.upfronthosting.co.za>
Message-ID: <1453145193.87.0.729389673589.issue25958@psf.upfronthosting.co.za>


Changes by Andrew Barnert :


Added file: http://bugs.python.org/file41651/patch5.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 14:36:33 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jan 2016 19:36:33 +0000
Subject: [issue26013] Pickle protocol 2.0 not loading in python 3.5
In-Reply-To: <1451979584.96.0.927777070704.issue26013@psf.upfronthosting.co.za>
Message-ID: <20160118193630.25965.25845@psf.io>


Roundup Robot added the comment:

New changeset 270add17f203 by Serhiy Storchaka in branch '3.5':
Issue #26013: Added compatibility with broken protocol 2 pickles created
https://hg.python.org/cpython/rev/270add17f203

New changeset 35ff0976b211 by Serhiy Storchaka in branch 'default':
Issue #26013: Added compatibility with broken protocol 2 pickles created
https://hg.python.org/cpython/rev/35ff0976b211

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 14:41:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Jan 2016 19:41:25 +0000
Subject: [issue26013] Pickle protocol 2.0 not loading in python 3.5
In-Reply-To: <1451979584.96.0.927777070704.issue26013@psf.upfronthosting.co.za>
Message-ID: <1453146085.88.0.80687503185.issue26013@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 14:53:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Jan 2016 19:53:09 +0000
Subject: [issue16620] Avoid using private function glob.glob1() in msi module
 and tools
In-Reply-To: <1354736049.23.0.98660459286.issue16620@psf.upfronthosting.co.za>
Message-ID: <1453146789.57.0.694324043218.issue16620@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It looks to me that the glob() method of msilib.Directory is broken from the born. It uses the function from the glob module, but the glob module is not imported in this source file.

Even if add missed import, returned value is incorrect in Python 3. In Python 2 glob.glob1() always returned a list, but in in Python 3 it can return an empty list or an iterator. After iterating on it msilib.Directory returns an empty list or exhausted iterator.

----------
type: enhancement -> behavior
versions: +Python 2.7, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 15:09:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Jan 2016 20:09:48 +0000
Subject: [issue26148] String literals are not interned if in a tuple
Message-ID: <1453147788.86.0.284579420871.issue26148@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Usually string literals are interned. But not if they are a part of constant tuple.

>>> def abc(): pass
... 
>>> x = 'abc'
>>> x is abc.__name__
True
>>> x = ('abc',)
>>> x[0] is abc.__name__
False

This makes effect on namedtuples (issue25981). May make effect on __slots__ or other uses of constant tuples since searching a value in a tuple when values are not identical is a little slower that when they are identical.

----------
components: Interpreter Core
messages: 258542
nosy: benjamin.peterson, brett.cannon, georg.brandl, haypo, ncoghlan, rhettinger, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: String literals are not interned if in a tuple

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 15:17:40 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Jan 2016 20:17:40 +0000
Subject: [issue26036] Unnecessary arguments on smtpd.SMTPServer
In-Reply-To: <1452168983.71.0.914590889995.issue26036@psf.upfronthosting.co.za>
Message-ID: <1453148260.44.0.745389448433.issue26036@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
nosy: +r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 15:20:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 20:20:45 +0000
Subject: [issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit
 constants
In-Reply-To: <1453136691.51.0.69393755181.issue26146@psf.upfronthosting.co.za>
Message-ID: <1453148445.2.0.101816729143.issue26146@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Brett Cannon: "Would it make sense to tag the type of the constant in the node somehow?"

It's easy to get the type of a constant: type(node.value). I like using isinstance().

Brett Cannon: "We also make no backwards-compatibility guarantees about the AST, so if it simplifies things to switch entirely to Constant from Num, etc. then I said do it."

Oh, I forgot an important point from the PEP: "[ast.Constant] does not contain line number and column offset informations on tuple or frozenset items." I don't know if it's an issue or not.

I prefer to move step by step. As I wrote, we can decide to use directly ast.Constant later, even before the Python 3.6 release.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 15:21:54 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 20:21:54 +0000
Subject: [issue26013] Pickle protocol 2.0 not loading in python 3.5
In-Reply-To: <1451979584.96.0.927777070704.issue26013@psf.upfronthosting.co.za>
Message-ID: <1453148514.31.0.53209765129.issue26013@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Buildbots are unhappy.

http://buildbot.python.org/all/builders/PPC64%20Fedora%203.5/builds/344/steps/test/logs/stdio

======================================================================
FAIL: test_reverse_import_mapping (test.test_pickle.CompatPickleTests) [('cStringIO', 'io')]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.5.edelsohn-fedora-ppc64/build/Lib/test/test_pickle.py", line 353, in test_reverse_import_mapping
    (module3, module2))
AssertionError: No reverse mapping from 'io' to 'cStringIO'

----------
nosy: +haypo
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 15:22:22 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Jan 2016 20:22:22 +0000
Subject: [issue26043] ON DELETE CASCADE does not work when using sqlite3
 library
In-Reply-To: <1452193029.87.0.593726838819.issue26043@psf.upfronthosting.co.za>
Message-ID: <1453148542.26.0.3188526236.issue26043@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
nosy: +r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 15:34:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jan 2016 20:34:43 +0000
Subject: [issue26013] Pickle protocol 2.0 not loading in python 3.5
In-Reply-To: <1451979584.96.0.927777070704.issue26013@psf.upfronthosting.co.za>
Message-ID: <20160118203440.25989.72091@psf.io>


Roundup Robot added the comment:

New changeset 7215d13baa2d by Serhiy Storchaka in branch '3.5':
Added exceptins for testing non-reversible import mapping for Issue #26013.
https://hg.python.org/cpython/rev/7215d13baa2d

New changeset 16cfc1652844 by Serhiy Storchaka in branch 'default':
Added exceptins for testing non-reversible import mapping for Issue #26013.
https://hg.python.org/cpython/rev/16cfc1652844

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 15:46:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Jan 2016 20:46:05 +0000
Subject: [issue26013] Pickle protocol 2.0 not loading in python 3.5
In-Reply-To: <1451979584.96.0.927777070704.issue26013@psf.upfronthosting.co.za>
Message-ID: <1453149965.22.0.420409374868.issue26013@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Victor.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 15:50:01 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Jan 2016 20:50:01 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>
Message-ID: <1453150201.79.0.860213064777.issue26058@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
nosy: +r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 16:09:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Jan 2016 21:09:58 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1453151398.55.0.282726187286.issue26107@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

But there is no need to increase it by 10. I suppose the gap is added to allow updating bytecode in maintained releases, but in process of developing next version we don't need this.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 16:10:04 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Jan 2016 21:10:04 +0000
Subject: [issue26092] doctest should allow custom sys.displayhook
In-Reply-To: <1452622857.37.0.137754453324.issue26092@psf.upfronthosting.co.za>
Message-ID: <1453151404.49.0.457267516024.issue26092@psf.upfronthosting.co.za>


R. David Murray added the comment:

What problem does replacing __displayhook__ provoke?  What solution do you propose instead of 8048, which fixed a bug?

----------
nosy: +r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 16:30:37 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Jan 2016 21:30:37 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1453152637.28.0.601885753918.issue26107@psf.upfronthosting.co.za>


Brett Cannon added the comment:

There's technically no need to worry about ranged values as the magic number is purely an equality check to see if the interpreter matches what the .pyc was created with. I guess there might be third-party code that does a range check, but that's bad as importlib checks the raw bytes only; using a number is mostly a convenience for changing it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 16:48:42 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Jan 2016 21:48:42 +0000
Subject: [issue26124] shlex.quote and pipes.quote do not quote shell keywords
In-Reply-To: <1452863681.04.0.149848593597.issue26124@psf.upfronthosting.co.za>
Message-ID: <1453153722.71.0.706532022296.issue26124@psf.upfronthosting.co.za>


R. David Murray added the comment:

Quote is for quoting shell special characters, not command names.  It would be fairly straightforward to add that to the docs ("Return a version of the string s will with all shell special characters (including whitespace) escaped according to shell escaping rules."  Wordier, but more accurate, and not *too* much longer.

----------
nosy: +r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 16:48:48 2016
From: report at bugs.python.org (John Hagen)
Date: Mon, 18 Jan 2016 21:48:48 +0000
Subject: [issue26149] Suggest PyCharm Community as an editor for Unix platforms
Message-ID: <1453153728.95.0.733172914649.issue26149@psf.upfronthosting.co.za>


New submission from John Hagen:

The Python documentation recommends editors that can be used on Unix:
https://docs.python.org/3.5/using/unix.html#editors

If the intent is to advertise very excellent IDEs (as Geany and Komodo Edit are listed), I suggest that PyCharm Community Edition (https://www.jetbrains.com/pycharm/download/) be added to the list.

It is free, has a very powerful static analyzer, comes with PEP8 checking installed by default, supports type hinting, ... (https://www.jetbrains.com/pycharm/features/)

----------
assignee: docs at python
components: Documentation
messages: 258551
nosy: John Hagen, docs at python
priority: normal
severity: normal
status: open
title: Suggest PyCharm Community as an editor for Unix platforms
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 16:49:57 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Jan 2016 21:49:57 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1453153797.52.0.305562243688.issue26107@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The launcher on Windows does a range check.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 16:59:58 2016
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 18 Jan 2016 21:59:58 +0000
Subject: [issue16907] Distutils fails to build extension in path with spaces
In-Reply-To: <1357734162.78.0.136546351961.issue16907@psf.upfronthosting.co.za>
Message-ID: <1453154398.1.0.16995808514.issue16907@psf.upfronthosting.co.za>


Zachary Ware added the comment:

This isn't obviously a distutils bug, but sounds strikingly similar to #4508.  Closing as a duplicate of #4508.

----------
assignee: eric.araujo -> 
nosy: +zach.ware
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> distutils compiler not handling spaces in path to output/src files

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 17:13:13 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 18 Jan 2016 22:13:13 +0000
Subject: [issue26149] Suggest PyCharm Community as an editor for Unix platforms
In-Reply-To: <1453153728.95.0.733172914649.issue26149@psf.upfronthosting.co.za>
Message-ID: <1453155193.12.0.0515198943312.issue26149@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report. It would be better to refer to https://wiki.python.org/moin/PythonEditors and https://wiki.python.org/moin/IntegratedDevelopmentEnvironments instead of maintaining duplicate and outdated lists.

----------
keywords: +easy
nosy: +berker.peksag
stage:  -> needs patch
versions:  -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 17:19:10 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 18 Jan 2016 22:19:10 +0000
Subject: [issue26119] Windows Installer can sometimes silently fail pip stage
In-Reply-To: <1452830051.37.0.928414799264.issue26119@psf.upfronthosting.co.za>
Message-ID: <1453155550.15.0.753455972985.issue26119@psf.upfronthosting.co.za>


Steve Dower added the comment:

Preferably just one group of them (created around the same time) for a failed installation.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 17:31:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 22:31:05 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1453156265.51.0.221809572741.issue26107@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 4:

* finish to update Objects/lnotab_notes.txt
* update _PyCode_CheckLineNumber() in codeobject.c
* set importlib MAGIC to 3361

I don't expect my patch to be complete nor perfect. IMHO it's fine to adjust the code later if needed.

I would like to integrate FAT Python changes step by step. It looks like the general idea of AST optimizers is well accepted.

----------
Added file: http://bugs.python.org/file41652/lnotab-4.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 17:40:56 2016
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 18 Jan 2016 22:40:56 +0000
Subject: [issue21277] don't try to link _ctypes with a ffi_convenience library
In-Reply-To: <1397688266.23.0.303919517358.issue21277@psf.upfronthosting.co.za>
Message-ID: <1453156856.09.0.257540558933.issue21277@psf.upfronthosting.co.za>


Zachary Ware added the comment:

It's not easy to find anything with a google search for 'ffi_convenience' that's not this issue.  I did find doko's patch to GCC to not install libffi_convenience, which included a comment from the author of libffi saying he didn't recommend that GCC install libffi_convenience in the first place[1].

For the record, #1464444 is the issue that added the line in question in the first place.

[1] https://www.sourceware.org/ml/libffi-discuss/2013/msg00125.html

----------
nosy: +zach.ware
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 17:58:18 2016
From: report at bugs.python.org (Rose Ames)
Date: Mon, 18 Jan 2016 22:58:18 +0000
Subject: [issue24922] assertWarnsRegex doesn't allow multiple warning messages
In-Reply-To: <1440425748.63.0.780438690591.issue24922@psf.upfronthosting.co.za>
Message-ID: <1453157898.99.0.252814661588.issue24922@psf.upfronthosting.co.za>


Rose Ames added the comment:

Would this mean that we expect any one of the warnings to be raised, or all of them?  If it's one, the example you give would be equivalent to:

    self.assertWarnsRegex(UserWarning, "^W100[01]")

Matching all of the warnings seems more interesting, but I'm not sure how to handle the context manager attributes.  For instance, right now you can do:

    with self.assertWarnsRegex(FooWarning, "Bar") as cm:
        blah()
    self.assertEquals(cm.lineno, 1000)

Would lineno and filename become lists?  It seems kind of ugly.  What's the advantage over simply testing for each warning separately?

----------
nosy: +superluser

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 18:18:53 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 18 Jan 2016 23:18:53 +0000
Subject: [issue20556] Use specific asserts in threading tests
In-Reply-To: <1391808878.85.0.661174932104.issue20556@psf.upfronthosting.co.za>
Message-ID: <1453159133.63.0.454681597178.issue20556@psf.upfronthosting.co.za>


Berker Peksag added the comment:

test_threading_asserts_2.patch looks good to me.

----------
nosy: +berker.peksag
stage: patch review -> commit review
versions:  -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 18:40:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 23:40:10 +0000
Subject: [issue26145] PEP 511: Add sys.set_code_transformers()
In-Reply-To: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>
Message-ID: <1453160410.36.0.653989541822.issue26145@psf.upfronthosting.co.za>


STINNER Victor added the comment:

main.c:


+        case 'o':
+            if (wcslen(_PyOS_optarg) == 0
+               || wcschr(_PyOS_optarg, L'.')
+               || wcschr(_PyOS_optarg, L'-')
...

'-' character must be valid for -o argument.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 18:48:29 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 18 Jan 2016 23:48:29 +0000
Subject: [issue24823] ctypes.create_string_buffer does not add NUL if
 len(init) == size
In-Reply-To: <1438942688.18.0.266077254276.issue24823@psf.upfronthosting.co.za>
Message-ID: <1453160909.86.0.140990993356.issue24823@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

(Tracker notes:

I added as nosy the people listed as active 'experts' for ctypes on https://docs.python.org/devguide/experts.html#experts.  This was easily done by going to the end of the nosy list, typing a comma ',', typing 'ctypes', and then clicking the box that appeared.  This can be done for any module and the other topics listed on the page.

The Documentation component is for issues that only change the docs, and not the code.  That is why Documentation issues are auto-assigned to docs at python.  Adding 'Documentation' amounts to rejecting this patch or anything else that changes the code.

asyncio, ctypes, IDLE (idlelib), IO, and (T)tkinter are all parts of the stdlib and AFAIK, issues marked for them do not have to also be marked 'Library'.)
---

I looked at ctypes.py with hg annotate.  Create_string_buffer is part of Thomas Heller's original 2006-03-08 patch that moved ctypes from an external source into the stdlib.  The only changes are in the isinstance class checks and the raise statement; the conditional bodies, including the one in question, are unchanged.

Tom, we disagree on our reading of the current docs.  The default number of NULL bytes added is 1.  Is the second argument required to be large enough to keep the number positive?  You think yes, I think no, though I agree with Eryk that the second quoted sentence could and should be clearer.  I will not assume that T. Heller meant 'yes' when he wrote 'no' in the code.  What do the listed experts think?

If the doc matches the code, there is no implementation bug and this is not a behavior issue. It is still possible to request a design change as an enhancement.  I think this would require agreement of at least two core developers.  A deprecation notice would normally be needed.  A third possibility is to decide that this is a security issue severe enough to possibly break code in 3.6 and possibly sooner.  I think this would require pydev discussion.

One problem with changing ctypes is that it is not used in the stdlib, so we have no local examples to draw on.  In this case, the question would be how often is 'size' used to suppress the default NULL byte and how legitimate are such uses.

----------
components: +Devguide -Documentation, Library (Lib), ctypes
nosy: +amaury.forgeotdarc, belopolsky, ezio.melotti, meador.inge, terry.reedy, willingc

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 19:02:19 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Jan 2016 00:02:19 +0000
Subject: [issue25366] test_venv fails with --without-threads
In-Reply-To: <1444494418.59.0.980856375099.issue25366@psf.upfronthosting.co.za>
Message-ID: <20160119000209.94208.90298@psf.io>


Roundup Robot added the comment:

New changeset 2a201272daed by Berker Peksag in branch '3.5':
Issue #25366: Skip test_with_pip when threading module is not available
https://hg.python.org/cpython/rev/2a201272daed

New changeset 27d4f06c3720 by Berker Peksag in branch 'default':
Issue #25366: Skip test_with_pip when threading module is not available
https://hg.python.org/cpython/rev/27d4f06c3720

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 19:03:51 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 19 Jan 2016 00:03:51 +0000
Subject: [issue25366] test_venv fails with --without-threads
In-Reply-To: <1444494418.59.0.980856375099.issue25366@psf.upfronthosting.co.za>
Message-ID: <1453161831.76.0.296034940382.issue25366@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Fixed. Thanks for the report, Arfrever

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior
versions:  -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 19:50:27 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 19 Jan 2016 00:50:27 +0000
Subject: [issue13886] readline-related test_builtin failure
In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za>
Message-ID: <1453164627.72.0.27967595715.issue13886@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a possible patch which:

* Runs the three test_input_tty() tests in a fresh child Python interpreter, for control over whether Readline is loaded. A pseudoterminal is used for stdin and stdout, and stderr is left untouched to easily see error messages.
* Repeats each test with and without Readline enabled
* Only tests the error handling without Readline
* Fixes the non-error test to use proper UTF-8 input

With my patch applied, there are a couple of prompts mixed up in the test log output via stderr, due to Issue 1927. It is not a major problem, but perhaps we should work on fixing that bug first.

----------
dependencies: +raw_input behavior incorrect if readline not enabled
stage: needs patch -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 20:09:03 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 19 Jan 2016 01:09:03 +0000
Subject: [issue13886] readline-related test_builtin failure
In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za>
Message-ID: <1453165743.7.0.402996694656.issue13886@psf.upfronthosting.co.za>


Changes by Martin Panter :


Added file: http://bugs.python.org/file41653/input-readline.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 20:16:43 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 19 Jan 2016 01:16:43 +0000
Subject: [issue5626] misleading comment in socket.gethostname() documentation
In-Reply-To: <1238515382.33.0.784525971679.issue5626@psf.upfronthosting.co.za>
Message-ID: <1453166203.01.0.846537063491.issue5626@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Given that we have not received any more reports on users tripping up on this message, it seems to me that we could just ignore this report and close it. Thoughts?

----------
nosy: +orsenthil

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 20:38:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Jan 2016 01:38:23 +0000
Subject: [issue25859] EOFError in
 test_nntplib.NetworkedNNTPTests.test_starttls()
In-Reply-To: <1450083626.81.0.0429805941711.issue25859@psf.upfronthosting.co.za>
Message-ID: <20160119013818.14193.16686@psf.io>


Roundup Robot added the comment:

New changeset a9fca95f119a by Martin Panter in branch '3.5':
Issue #25859: Reimplement NNTP test_starttls() using local server
https://hg.python.org/cpython/rev/a9fca95f119a

New changeset c44bfa733526 by Martin Panter in branch 'default':
Issue #25859: Merge NNTP test server from 3.5
https://hg.python.org/cpython/rev/c44bfa733526

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 20:52:09 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 19 Jan 2016 01:52:09 +0000
Subject: [issue5626] misleading comment in socket.gethostname() documentation
In-Reply-To: <1238515382.33.0.784525971679.issue5626@psf.upfronthosting.co.za>
Message-ID: <1453168329.44.0.540874710622.issue5626@psf.upfronthosting.co.za>


Ned Deily added the comment:

The point still stands that speaking of "the current machine's IP address" is misleading at best.  I'd say either apply Berker's suggested patch or expand the description to better reflect the real world of multiple interfaces.  Of course I'm biased.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 21:46:03 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Jan 2016 02:46:03 +0000
Subject: [issue23962] Incorrect TimeoutError referenced in concurrent.futures
 documentation
In-Reply-To: <1429068832.51.0.845639899608.issue23962@psf.upfronthosting.co.za>
Message-ID: <20160119024600.25920.36587@psf.io>


Roundup Robot added the comment:

New changeset 673d1ccea050 by Senthil Kumaran in branch '3.5':
issue23962 - Reference the correct TimeoutError in concurrent.futures documentation.
https://hg.python.org/cpython/rev/673d1ccea050

New changeset 2b0c7b67eca5 by Senthil Kumaran in branch 'default':
merge from 3.5
https://hg.python.org/cpython/rev/2b0c7b67eca5

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 21:47:40 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 19 Jan 2016 02:47:40 +0000
Subject: [issue23962] Incorrect TimeoutError referenced in concurrent.futures
 documentation
In-Reply-To: <1429068832.51.0.845639899608.issue23962@psf.upfronthosting.co.za>
Message-ID: <1453171660.28.0.30457457327.issue23962@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the report and the patch. I have fixed that in 3.5 and 3.6 docs. I found it reasonable to include the full module path for TimeoutError makeing it consist with asyncio and multiprocessing TimeoutError.

Also, Error exception is not exposed via __all__ so, left this out in the documentation.

----------
assignee: docs at python -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 21:50:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 19 Jan 2016 02:50:54 +0000
Subject: [issue12869] PyOS_StdioReadline is printing the prompt on stderr
In-Reply-To: <1314801518.5.0.445361297153.issue12869@psf.upfronthosting.co.za>
Message-ID: <1453171854.17.0.00198620097572.issue12869@psf.upfronthosting.co.za>


Martin Panter added the comment:

Adam: My experiments were assuming that PyOS_Readline() only ever uses the basic implementation or the Readline library, in order to see if there was any consistency with how Python worked in common situations.

There is actually a test that waits for the interpreter prompt on stderr; see test_cmd_line_script.CmdLineTest.interactive_python(). I realized that changing this would have to be considered carefully, because it could easily break other code as well. It certainly should not be done in a bug fix release.

Anyway I am proposing a patch in Issue 1927 to fix PyOS_StdioReadline(), so closing this as a duplicate.

----------
components: +Interpreter Core -Extension Modules
resolution:  -> duplicate
status: open -> closed
superseder:  -> raw_input behavior incorrect if readline not enabled

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 22:13:16 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 19 Jan 2016 03:13:16 +0000
Subject: [issue1927] raw_input behavior incorrect if readline not enabled
In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za>
Message-ID: <1453173196.06.0.315522504507.issue1927@psf.upfronthosting.co.za>


Martin Panter added the comment:

Tal: thanks for testing.

This v3 patch changes the interactive interpreter to pass stderr as the sys_stdout parameter. This means we should maintain compatibility with the interpreter prompt going to stderr, but still fix input().

----------
versions:  -Python 3.4
Added file: http://bugs.python.org/file41654/promptOutputFix3.v3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 22:19:14 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 19 Jan 2016 03:19:14 +0000
Subject: [issue25859] EOFError in
 test_nntplib.NetworkedNNTPTests.test_starttls()
In-Reply-To: <1450083626.81.0.0429805941711.issue25859@psf.upfronthosting.co.za>
Message-ID: <1453173554.33.0.886318290484.issue25859@psf.upfronthosting.co.za>


Changes by Martin Panter :


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 00:04:54 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Jan 2016 05:04:54 +0000
Subject: [issue26059] Integer Overflow in strop.replace()
In-Reply-To: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za>
Message-ID: <1453179894.16.0.711649373944.issue26059@psf.upfronthosting.co.za>


Changes by Benjamin Peterson :


----------
resolution: wont fix -> not a bug
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 00:18:45 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Jan 2016 05:18:45 +0000
Subject: [issue25731] Assigning and deleting __new__ attr on the class does
 not allow to create instances of this class
In-Reply-To: <1448454590.41.0.350843358205.issue25731@psf.upfronthosting.co.za>
Message-ID: <20160119051842.41314.76048@psf.io>


Roundup Robot added the comment:

New changeset 3c9512d8ac0d by Benjamin Peterson in branch '3.5':
set tp_new from the class in the hierarchy that actually owns the descriptor (closes #25731)
https://hg.python.org/cpython/rev/3c9512d8ac0d

New changeset e7062dd9085e by Benjamin Peterson in branch '2.7':
set tp_new from the class in the hierarchy that actually owns the descriptor (closes #25731)
https://hg.python.org/cpython/rev/e7062dd9085e

New changeset a7953ee29f1c by Benjamin Peterson in branch 'default':
merge 3.5 (#25731)
https://hg.python.org/cpython/rev/a7953ee29f1c

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 02:44:34 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 07:44:34 +0000
Subject: [issue26145] PEP 511: Add sys.set_code_transformers()
In-Reply-To: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>
Message-ID: <1453189474.52.0.551532259954.issue26145@psf.upfronthosting.co.za>


STINNER Victor added the comment:

sys_init_code_transformer: Py_DECREF(name); must be Py_XDECREF(name); at exit, it can NULL. An unit test on an invalid transformer (with no name) is missing?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 02:51:22 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Jan 2016 07:51:22 +0000
Subject: [issue11816] Refactor the dis module to provide better building
 blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <20160119075117.121294.74687@psf.io>


Roundup Robot added the comment:

New changeset bf997b22df06 by Victor Stinner in branch '3.5':
Fix BytecodeTestCase.assertNotInBytecode()
https://hg.python.org/cpython/rev/bf997b22df06

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 04:39:28 2016
From: report at bugs.python.org (Michael Foord)
Date: Tue, 19 Jan 2016 09:39:28 +0000
Subject: [issue26140] inspect.iscoroutinefunction raises TypeError when checks
 Mock of function or coroutinefunction
In-Reply-To: <1453030972.84.0.0646105171888.issue26140@psf.upfronthosting.co.za>
Message-ID: <1453196368.14.0.739879034236.issue26140@psf.upfronthosting.co.za>


Michael Foord added the comment:

In inspect checking that __code__ is a code object, or that co_flags is an int, would be better than special casing mock. 

However, the patch to mock looks reasonable to me. It copies the whole code object from the original function to the mock object. The patch needs a test (I'd like to see a test for the Mock(func) case and the create_autospec(func) case.)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 04:43:32 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 19 Jan 2016 09:43:32 +0000
Subject: [issue16620] Avoid using private function glob.glob1() in msi module
 and tools
In-Reply-To: <1354736049.23.0.98660459286.issue16620@psf.upfronthosting.co.za>
Message-ID: <1453196612.45.0.413283798321.issue16620@psf.upfronthosting.co.za>


Changes by Mark Lawrence :


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 04:58:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Jan 2016 09:58:29 +0000
Subject: [issue1927] raw_input behavior incorrect if readline not enabled
In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za>
Message-ID: <1453197509.63.0.0455644088653.issue1927@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Unix shell builtin command "read" outputs prompt to stderr. In bash that uses readline and in dash that doesn't use readline. Looks as this is standard behavior.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 05:02:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Jan 2016 10:02:59 +0000
Subject: [issue26013] Pickle protocol 2.0 not loading in python 3.5
In-Reply-To: <1451979584.96.0.927777070704.issue26013@psf.upfronthosting.co.za>
Message-ID: <1453197779.29.0.916424685856.issue26013@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 05:09:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Jan 2016 10:09:14 +0000
Subject: [issue25718] itertools.accumulate __reduce__/__setstate__ bug
In-Reply-To: <1448352443.54.0.731172452763.issue25718@psf.upfronthosting.co.za>
Message-ID: <1453198154.13.0.782609872389.issue25718@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 05:36:31 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 19 Jan 2016 10:36:31 +0000
Subject: [issue1927] raw_input behavior incorrect if readline not enabled
In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za>
Message-ID: <1453199791.34.0.51921898995.issue1927@psf.upfronthosting.co.za>


Martin Panter added the comment:

The way I see it, input() is mainly geared for prompting to stdout, and it is just one aspect that strangely uses stderr:

* Documentation says stdout
* Stdout is checked if it is a terminal and not redirected
* Gnu Readline is configured for stdout
* The fallback for non-terminals uses stdout

Arguments for using stderr:

* Consistency with Unix shell
* Consistency with the Python interactive interpreter prompt

Maybe it is more ideal to use stderr (I have no idea). But I think that would be a more drastic change.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 05:49:38 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 10:49:38 +0000
Subject: [issue26145] PEP 511: Add sys.set_code_transformers()
In-Reply-To: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>
Message-ID: <1453200578.66.0.610380332251.issue26145@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 2:

* allow "-" character in the argument of the -o command line option
* add an unit test on invalid type for code transformer
* fix a crash in sys.set_code_transformers(): replace Py_DECREF() with Py_XDECREF()

----------
Added file: http://bugs.python.org/file41655/transformers-2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 05:49:56 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 10:49:56 +0000
Subject: [issue26145] PEP 511: Add sys.set_code_transformers()
In-Reply-To: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>
Message-ID: <1453200596.27.0.805782160666.issue26145@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 2:

* allow "-" character in the argument of the -o command line option
* add an unit test on invalid type for code transformer
* fix a crash in sys.set_code_transformers(): replace Py_DECREF() with Py_XDECREF()

----------
Added file: http://bugs.python.org/file41656/transformers-2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 05:50:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 10:50:14 +0000
Subject: [issue26145] PEP 511: Add sys.set_code_transformers()
In-Reply-To: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>
Message-ID: <1453200614.93.0.104265214685.issue26145@psf.upfronthosting.co.za>


Changes by STINNER Victor :


Removed file: http://bugs.python.org/file41655/transformers-2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 05:50:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 10:50:23 +0000
Subject: [issue26145] PEP 511: Add sys.set_code_transformers()
In-Reply-To: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>
Message-ID: <1453200623.59.0.307037038531.issue26145@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
Removed message: http://bugs.python.org/msg258579

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 05:51:20 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 10:51:20 +0000
Subject: [issue26145] PEP 511: Add sys.set_code_transformers()
In-Reply-To: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>
Message-ID: <1453200680.12.0.269847444647.issue26145@psf.upfronthosting.co.za>


STINNER Victor added the comment:

(oops, i posted the same message with patch twice)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 06:06:38 2016
From: report at bugs.python.org (=?utf-8?b?0JLQu9Cw0LTQuNGB0LvQsNCyINCQ0LvQtdC60YHQsNC90LTRgNC+0LLQuNGH?=)
Date: Tue, 19 Jan 2016 11:06:38 +0000
Subject: [issue26150] SequenceMatcher's algorithm is not correct
Message-ID: <1453201598.83.0.994407990741.issue26150@psf.upfronthosting.co.za>


New submission from ????????? ?????????????:

For strings 'aaaaaa', 'aabaaa' SequenceMatcher's algorithm finds only common substring 'aaa', while well-known classic LCS algorithm: http://www.geeksforgeeks.org/printing-longest-common-subsequence/ finds 'aa' and 'aaa'.

Is it the price for "best case time is linear", as mentioned in difflib's documentation? Are there any other reasons not to implement classic LCS algorith (e.g. memory limits?)? If no, maybe it will be usefull to create subclass StrictSequenceMatcher?

----------
messages: 258582
nosy: ????????? ?????????????
priority: normal
severity: normal
status: open
title: SequenceMatcher's algorithm is not correct
type: behavior
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 06:52:04 2016
From: report at bugs.python.org (Johnny Wezel)
Date: Tue, 19 Jan 2016 11:52:04 +0000
Subject: [issue26151] str(bytes) does __repr__() instead of __str__()
Message-ID: <1453204324.06.0.936189522154.issue26151@psf.upfronthosting.co.za>


New submission from Johnny Wezel:

str(b'xxx') returns "b'xxx'" instead of 'xxx'

----------
components: Interpreter Core, Unicode
messages: 258583
nosy: ezio.melotti, haypo, jwezel
priority: normal
severity: normal
status: open
title: str(bytes) does __repr__() instead of __str__()
type: behavior
versions: Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 07:01:37 2016
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Tue, 19 Jan 2016 12:01:37 +0000
Subject: [issue26152] A non-breaking space in a source
Message-ID: <1453204897.88.0.969876573405.issue26152@psf.upfronthosting.co.za>


New submission from Adam Barto?:

Consider the following code:
>>> 1,?2
  File "", line 1
    1,?2
       ^
SyntaxError: invalid character in identifier

The error is due to the fact, that the space before "2" is actually a non-breaking space. The error message and the position of the caret is misleading.

The tokenize module gives an ERRORTOKEN at the position of the space, so shouldn't the massage be more like "invalid syntax" with the correct position or even something more appropriate?

----------
components: Interpreter Core, Unicode
messages: 258584
nosy: Drekin, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: A non-breaking space in a source
type: behavior
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 07:10:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Jan 2016 12:10:42 +0000
Subject: [issue16620] Avoid using private function glob.glob1() in msi module
 and tools
In-Reply-To: <1354736049.23.0.98660459286.issue16620@psf.upfronthosting.co.za>
Message-ID: <20160119121034.96356.41495@psf.io>


Roundup Robot added the comment:

New changeset 652a50208e89 by Serhiy Storchaka in branch '3.5':
Issue #16620: Fixed AttributeError in msilib.Directory.glob().
https://hg.python.org/cpython/rev/652a50208e89

New changeset 158ae15f5809 by Serhiy Storchaka in branch '2.7':
Issue #16620: Fixed AttributeError in msilib.Directory.glob().
https://hg.python.org/cpython/rev/158ae15f5809

New changeset 84a50f14a266 by Serhiy Storchaka in branch 'default':
Issue #16620: Fixed AttributeError in msilib.Directory.glob().
https://hg.python.org/cpython/rev/84a50f14a266

New changeset f2586c381b0b by Serhiy Storchaka in branch 'default':
Issue #16620: Got rid of using undocumented function glob.glob1().
https://hg.python.org/cpython/rev/f2586c381b0b

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 07:11:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Jan 2016 12:11:07 +0000
Subject: [issue16620] Avoid using private function glob.glob1() in msi module
 and tools
In-Reply-To: <1354736049.23.0.98660459286.issue16620@psf.upfronthosting.co.za>
Message-ID: <1453205467.56.0.610331025067.issue16620@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 07:14:30 2016
From: report at bugs.python.org (Min RK)
Date: Tue, 19 Jan 2016 12:14:30 +0000
Subject: [issue26153] PyImport_GetModuleDict: no module dictionary! when
 `__del__` triggers a warning
Message-ID: <1453205670.9.0.210259286868.issue26153@psf.upfronthosting.co.za>


New submission from Min RK:

PyImport_GetModuleDict: no module dictionary! can be raised during interpreter shutdown if a `__del__` method results in a warning. This only happens on Python 3.5.

The prompting case is IPython 4.0.2 and traitlets 4.1.0. An IPython ExtensionManager calls `self.shell.on_trait_change` during its `__del__` to unregister a listener. That `on_trait_change` method is deprecated, and tries to display a DeprecationWarning. The call to `warnings.warn results in:

    Fatal Python error: PyImport_GetModuleDict: no module dictionary!

There appear to be races involved, because the crash happens with inconsistent frequency, sometimes quite rarely.

I've tried to put together a simple minimal test case, but I cannot reproduce the crash outside of IPython. I can, however, reproduce inconsistent behavior where a UserWarning displayed during `__del__` sometimes fails with

    ImportError: import of 'linecache' halted; None in sys.modules

and sometimes the exact same code succeeds, showing the error:

    ~/dev/tmp/del-warn/a.py:9: DeprecationWarning: I don't cleanup anymore
      self.b.cleanup()

and sometimes it shows the warning but not the frame

    ~/dev/tmp/del-warn/a.py:9: DeprecationWarning: I don't cleanup anymore

----------
components: Interpreter Core
messages: 258586
nosy: minrk
priority: normal
severity: normal
status: open
title: PyImport_GetModuleDict: no module dictionary! when `__del__` triggers a warning
type: crash
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 07:14:48 2016
From: report at bugs.python.org (Min RK)
Date: Tue, 19 Jan 2016 12:14:48 +0000
Subject: [issue26153] PyImport_GetModuleDict: no module dictionary! when
 `__del__` triggers a warning
In-Reply-To: <1453205670.9.0.210259286868.issue26153@psf.upfronthosting.co.za>
Message-ID: <1453205688.28.0.280932064966.issue26153@psf.upfronthosting.co.za>


Changes by Min RK :


Added file: http://bugs.python.org/file41657/a.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 07:15:12 2016
From: report at bugs.python.org (Min RK)
Date: Tue, 19 Jan 2016 12:15:12 +0000
Subject: [issue26153] PyImport_GetModuleDict: no module dictionary! when
 `__del__` triggers a warning
In-Reply-To: <1453205670.9.0.210259286868.issue26153@psf.upfronthosting.co.za>
Message-ID: <1453205712.39.0.285704928196.issue26153@psf.upfronthosting.co.za>


Changes by Min RK :


Added file: http://bugs.python.org/file41658/b.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 07:15:21 2016
From: report at bugs.python.org (Min RK)
Date: Tue, 19 Jan 2016 12:15:21 +0000
Subject: [issue26153] PyImport_GetModuleDict: no module dictionary! when
 `__del__` triggers a warning
In-Reply-To: <1453205670.9.0.210259286868.issue26153@psf.upfronthosting.co.za>
Message-ID: <1453205721.46.0.335677779213.issue26153@psf.upfronthosting.co.za>


Changes by Min RK :


Added file: http://bugs.python.org/file41659/main.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 07:30:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 12:30:33 +0000
Subject: [issue26154] Add private _PyThreadState_FastGet() to get the current
 thread state
Message-ID: <1453206633.27.0.0623775421981.issue26154@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The issue #25150 modified pystate.h to hide _PyThreadState_Current. Sadly, this change broke the vmprof project:
https://mail.python.org/pipermail/python-dev/2016-January/142767.html

Attached patches adds a new private _PyThreadState_FastGet() function to get the current thread state but don't call Py_FatalError() if it is NULL.

The patch also uses replace direct access to _PyThreadState_Current with _PyThreadState_FastGet(), except inside ceval.c and pystate.c.

Calling Py_FatalError() to handle errors is not really a great API... Bad that's a different story, I don't want to break anything here.

I want to add the private function to Python 3.5.2 because I consider that the removal of the _PyThreadState_Current symbol is a regression introduced in Python 3.5.1.

We have no rule for the Python private API, it can change *anytime*.

----------
files: pythreadstate_fastget.patch
keywords: patch
messages: 258587
nosy: haypo, larry
priority: normal
severity: normal
status: open
title: Add private _PyThreadState_FastGet() to get the current thread state
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41660/pythreadstate_fastget.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 07:33:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 12:33:43 +0000
Subject: [issue26151] str(bytes) does __repr__() instead of __str__()
In-Reply-To: <1453204324.06.0.936189522154.issue26151@psf.upfronthosting.co.za>
Message-ID: <1453206823.21.0.0862728586127.issue26151@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Yes. It's a feature, not a bug. You muse decode manually bytes to get type: b'xxx'.decode('ascii') or str(b'xxx'.decode('ascii')).

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 07:42:38 2016
From: report at bugs.python.org (Johnny Wezel)
Date: Tue, 19 Jan 2016 12:42:38 +0000
Subject: [issue26151] str(bytes) does __repr__() instead of __str__()
In-Reply-To: <1453204324.06.0.936189522154.issue26151@psf.upfronthosting.co.za>
Message-ID: <1453207358.04.0.0499701876777.issue26151@psf.upfronthosting.co.za>


Johnny Wezel added the comment:

Bad feature, as it is a violation of POLA.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 07:49:09 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Jan 2016 12:49:09 +0000
Subject: [issue25935] OrderedDict prevents garbage collection if a circulary
 referenced class is used as key
In-Reply-To: <1450913999.27.0.791224065959.issue25935@psf.upfronthosting.co.za>
Message-ID: <20160119124901.121286.81276@psf.io>


Roundup Robot added the comment:

New changeset 627575e9a7aa by Serhiy Storchaka in branch '3.5':
Issue #25935: Garbage collector now breaks reference loops with OrderedDict.
https://hg.python.org/cpython/rev/627575e9a7aa

New changeset 5f0a08cfc4f6 by Serhiy Storchaka in branch 'default':
Issue #25935: Garbage collector now breaks reference loops with OrderedDict.
https://hg.python.org/cpython/rev/5f0a08cfc4f6

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 07:51:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 12:51:09 +0000
Subject: [issue26098] PEP 510: Specialize functions with guards
In-Reply-To: <1452689568.12.0.253530674137.issue26098@psf.upfronthosting.co.za>
Message-ID: <1453207869.78.0.562485527119.issue26098@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 3:

* guards are now tracked by the garbage collector. That's a very important requirements to not change the Python semantics at exit, when a guard keeps a strong reference to the global namespace:

https://mail.python.org/pipermail/python-dev/2016-January/142792.html

* add more tests: call specialize() with invalid types, set __code__

----------
Added file: http://bugs.python.org/file41661/specialize-3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 08:41:17 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 13:41:17 +0000
Subject: [issue26148] String literals are not interned if in a tuple
In-Reply-To: <1453147788.86.0.284579420871.issue26148@psf.upfronthosting.co.za>
Message-ID: <1453210877.96.0.502119421379.issue26148@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
type:  -> performance

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 08:41:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 13:41:24 +0000
Subject: [issue26148] String literals are not interned if in a tuple
In-Reply-To: <1453147788.86.0.284579420871.issue26148@psf.upfronthosting.co.za>
Message-ID: <1453210884.39.0.826383562874.issue26148@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 08:49:12 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 19 Jan 2016 13:49:12 +0000
Subject: [issue26153] PyImport_GetModuleDict: no module dictionary! when
 `__del__` triggers a warning
In-Reply-To: <1453205670.9.0.210259286868.issue26153@psf.upfronthosting.co.za>
Message-ID: <1453211352.72.0.587888336588.issue26153@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 08:50:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Jan 2016 13:50:20 +0000
Subject: [issue25935] OrderedDict prevents garbage collection if a circulary
 referenced class is used as key
In-Reply-To: <1450913999.27.0.791224065959.issue25935@psf.upfronthosting.co.za>
Message-ID: <1453211420.84.0.516553781095.issue25935@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In some cases (as in committed test) garbage collector was not able to collect a loop with OrderedDict at all.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 08:56:10 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 19 Jan 2016 13:56:10 +0000
Subject: [issue26150] SequenceMatcher's algorithm is not correct
In-Reply-To: <1453201598.83.0.994407990741.issue26150@psf.upfronthosting.co.za>
Message-ID: <1453211770.91.0.140159188172.issue26150@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
components: +Library (Lib)
nosy: +rhettinger
stage:  -> test needed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 08:56:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Jan 2016 13:56:45 +0000
Subject: [issue25949] Lazy creation of __dict__ in OrderedDict
In-Reply-To: <1451047688.41.0.0988158472157.issue25949@psf.upfronthosting.co.za>
Message-ID: <1453211805.49.0.25619276998.issue25949@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch have no visible effect, except lesser memory consumption. The latter is hard to measure in tests. Additional tests just ensure that the patch doesn't break existing behavior.

----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 08:58:38 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 13:58:38 +0000
Subject: [issue26148] String literals are not interned if in a tuple
In-Reply-To: <1453147788.86.0.284579420871.issue26148@psf.upfronthosting.co.za>
Message-ID: <1453211918.34.0.000132815319516.issue26148@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FYI fatoptimizer has a more efficient algorithm to merge constants:
http://fatoptimizer.readthedocs.org/en/latest/optimizations.html#comparison-with-the-peephole-optimizer

It looks like it interns strings which are part of tuples. To be honest, I don't understand how it works, but it works :-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 09:00:18 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 14:00:18 +0000
Subject: [issue26133] asyncio: ugly error related signal handler at exit if
 the loop is not closed explicitly
In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za>
Message-ID: <1453212018.81.0.995805660178.issue26133@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
title: TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, or a callable object in > -> asyncio: ugly error related signal handler at exit if the loop is not closed explicitly

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 09:00:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 14:00:27 +0000
Subject: [issue26133] asyncio: ugly error related to signal handlers at exit
 if the loop is not closed explicitly
In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za>
Message-ID: <1453212027.33.0.525394059377.issue26133@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
title: asyncio: ugly error related signal handler at exit if the loop is not closed explicitly -> asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 09:26:47 2016
From: report at bugs.python.org (TarotRedhand)
Date: Tue, 19 Jan 2016 14:26:47 +0000
Subject: [issue26155] 3.5.1 installer issue on Win 7 32 bit
Message-ID: <1453213607.65.0.0758375238655.issue26155@psf.upfronthosting.co.za>


New submission from TarotRedhand:

This is not in the Python Core but in the installer for version 3.5.1 on windows 32 bit. It occurs with the custom install option. I gave a verified new location for python to be installed to but it installed in MyDocuments anyway.

----------
components: Installation
messages: 258595
nosy: TarotRedhand
priority: normal
severity: normal
status: open
title: 3.5.1 installer issue on Win 7 32 bit
type: behavior
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 09:32:26 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 19 Jan 2016 14:32:26 +0000
Subject: [issue26155] 3.5.1 installer issue on Win 7 32 bit
In-Reply-To: <1453213607.65.0.0758375238655.issue26155@psf.upfronthosting.co.za>
Message-ID: <1453213946.02.0.652189820704.issue26155@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 09:41:26 2016
From: report at bugs.python.org (=?utf-8?q?Chema_Cort=C3=A9s?=)
Date: Tue, 19 Jan 2016 14:41:26 +0000
Subject: [issue26156] Bad name into power operator syntax
Message-ID: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>


New submission from Chema Cort?s:

The documentation erroneously changes "primary" for "away" in the power operator syntax:

https://docs.python.org/3.6/reference/expressions.html#the-power-operator
https://docs.python.org/3.5/reference/expressions.html#the-power-operator

----------
assignee: docs at python
components: Documentation
messages: 258596
nosy: Chema Cort?s, docs at python
priority: normal
severity: normal
status: open
title: Bad name into power operator syntax
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 09:45:21 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 19 Jan 2016 14:45:21 +0000
Subject: [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1453214721.31.0.140024068225.issue26156@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

The docs are correct. See the definition of the "await" expression: https://docs.python.org/3.6/reference/expressions.html#await-expression

----------
nosy: +yselivanov
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 10:10:03 2016
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 19 Jan 2016 15:10:03 +0000
Subject: [issue26154] Add private _PyThreadState_FastGet() to get the current
 thread state
In-Reply-To: <1453206633.27.0.0623775421981.issue26154@psf.upfronthosting.co.za>
Message-ID: <1453216203.51.0.877187710066.issue26154@psf.upfronthosting.co.za>


Nathaniel Smith added the comment:

Name should be _PyThreadState_UncheckedGet

----------
nosy: +njs

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 10:16:28 2016
From: report at bugs.python.org (Frank Millman)
Date: Tue, 19 Jan 2016 15:16:28 +0000
Subject: [issue26157] Typo in asyncio documentation
Message-ID: <1453216588.95.0.751274480755.issue26157@psf.upfronthosting.co.za>


New submission from Frank Millman:

18.5.1.15. Server

close()

"The sockets that represent existing incoming client connections are leaved open."

I think this should say 'are left open'.

----------
assignee: docs at python
components: Documentation
messages: 258599
nosy: docs at python, frankmillman
priority: normal
severity: normal
status: open
title: Typo in asyncio documentation
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 10:19:45 2016
From: report at bugs.python.org (Fornax)
Date: Tue, 19 Jan 2016 15:19:45 +0000
Subject: [issue26158] File truncate() not defaulting to current position as
 documented
Message-ID: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>


New submission from Fornax:

io.IOBase.truncate() documentation says:
"Resize the stream to the given size in bytes (or the current position if size is not specified). The current stream position isn?t changed. This resizing can extend or reduce the current file size. In case of extension, the contents of the new file area depend on the platform (on most systems, additional bytes are zero-filled). The new file size is returned."

However:
>>> open('temp.txt', 'w').write('ABCDE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\n')
32
>>> f = open('temp.txt', 'r+')
>>> f.readline()
'ABCDE\n'
>>> f.tell()
6                   # As expected, current position is 6 after the readline
>>> f.truncate()
32                  # ?!

Verified that the document does not get truncated to 6 bytes as expected. Adding an explicit f.seek(6) before the truncate causes it to work properly (truncate to 6). It also works as expected using a StringIO rather than a file, or in Python 2 (used 2.7.9).

Tested in 3.4.3/Windows, 3.4.1/Linux, 3.5.1/Linux.

----------
components: IO
messages: 258600
nosy: fornax
priority: normal
severity: normal
status: open
title: File truncate() not defaulting to current position as documented
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 10:23:02 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 19 Jan 2016 15:23:02 +0000
Subject: [issue5626] misleading comment in socket.gethostname() documentation
In-Reply-To: <1238515382.33.0.784525971679.issue5626@psf.upfronthosting.co.za>
Message-ID: <1453216982.7.0.334299931765.issue5626@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I agree with Chris and Ned. I will apply issue5626_v1.diff today.

----------
stage:  -> commit review
type:  -> behavior
versions: +Python 3.5, Python 3.6 -Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 11:02:11 2016
From: report at bugs.python.org (Carlo Beccarini)
Date: Tue, 19 Jan 2016 16:02:11 +0000
Subject: [issue26157] Typo in asyncio documentation
In-Reply-To: <1453216588.95.0.751274480755.issue26157@psf.upfronthosting.co.za>
Message-ID: <1453219331.92.0.156710644925.issue26157@psf.upfronthosting.co.za>


Carlo Beccarini added the comment:

Absolutely.

----------
nosy: +Paradisee

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 11:02:21 2016
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 19 Jan 2016 16:02:21 +0000
Subject: [issue26151] str(bytes) does __repr__() instead of __str__()
In-Reply-To: <1453204324.06.0.936189522154.issue26151@psf.upfronthosting.co.za>
Message-ID: <1453219341.74.0.525627338301.issue26151@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> Bad feature, as it is a violation of POLA.

I would be astonished if the default __str__ conversion returned a Latin-1 decoding, which won't fail, or used the locale encoding or UTF-8, which could fail. The more explicit call x.decode() uses UTF-8 as the default encoding.

----------
nosy: +eryksun

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 11:06:55 2016
From: report at bugs.python.org (Johnny Wezel)
Date: Tue, 19 Jan 2016 16:06:55 +0000
Subject: [issue26151] str(bytes) does __repr__() instead of __str__()
In-Reply-To: <1453204324.06.0.936189522154.issue26151@psf.upfronthosting.co.za>
Message-ID: <1453219615.49.0.866793779661.issue26151@psf.upfronthosting.co.za>


Johnny Wezel added the comment:

Who's talking about latin-1 in Python3? Of course str() needs to return decode('utf-8').

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 11:08:19 2016
From: report at bugs.python.org (Rose Ames)
Date: Tue, 19 Jan 2016 16:08:19 +0000
Subject: [issue26144] test_pkg test_4 and/or test_7 sometimes fail
In-Reply-To: <1453094860.75.0.307197769475.issue26144@psf.upfronthosting.co.za>
Message-ID: <1453219699.39.0.913341226202.issue26144@psf.upfronthosting.co.za>


Rose Ames added the comment:

Reproduced.  In four runs, one errored in test_4, one failed in test_7, and the other two did both.

----------
nosy: +superluser

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 11:12:39 2016
From: report at bugs.python.org (Carlo Beccarini)
Date: Tue, 19 Jan 2016 16:12:39 +0000
Subject: [issue26157] Typo in asyncio documentation
In-Reply-To: <1453216588.95.0.751274480755.issue26157@psf.upfronthosting.co.za>
Message-ID: <1453219959.92.0.419082096058.issue26157@psf.upfronthosting.co.za>


Changes by Carlo Beccarini :


----------
versions: +Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 11:14:00 2016
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Tue, 19 Jan 2016 16:14:00 +0000
Subject: [issue26151] str(bytes) does __repr__() instead of __str__()
In-Reply-To: <1453204324.06.0.936189522154.issue26151@psf.upfronthosting.co.za>
Message-ID: <1453220040.19.0.43078699804.issue26151@psf.upfronthosting.co.za>


Walter D?rwald added the comment:

> Who's talking about latin-1 in Python3? Of course str() needs to return decode('utf-8').

So that would mean that:

   print(b"\xff")

will always fail!

----------
nosy: +doerwalter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 11:14:58 2016
From: report at bugs.python.org (Bradley McLean)
Date: Tue, 19 Jan 2016 16:14:58 +0000
Subject: [issue26159] Unsafe to BaseEventLoop.set_debug(False) when
 PYTHONASYNCIODEBUG=1
Message-ID: <1453220098.77.0.244617474798.issue26159@psf.upfronthosting.co.za>


New submission from Bradley McLean:

Leads to spurious RuntimeWarning: coroutine  was never awaited messages, when @asyncio.coroutine methods call async def methods.  Likely because decorators ran before set_debug set False, and are assuming it won't change.

----------
components: asyncio
messages: 258607
nosy: Bradley McLean, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Unsafe to BaseEventLoop.set_debug(False) when PYTHONASYNCIODEBUG=1
type: behavior
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 11:19:08 2016
From: report at bugs.python.org (Johnny Wezel)
Date: Tue, 19 Jan 2016 16:19:08 +0000
Subject: [issue26151] str(bytes) does __repr__() instead of __str__()
In-Reply-To: <1453204324.06.0.936189522154.issue26151@psf.upfronthosting.co.za>
Message-ID: <1453220348.68.0.676277592629.issue26151@psf.upfronthosting.co.za>


Johnny Wezel added the comment:

The other question is why one would want to run such a statement. This is almost certainly a bug in which case an error one would be better off with an exception.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 11:24:52 2016
From: report at bugs.python.org (Carlo Beccarini)
Date: Tue, 19 Jan 2016 16:24:52 +0000
Subject: [issue26157] Typo in asyncio documentation
In-Reply-To: <1453216588.95.0.751274480755.issue26157@psf.upfronthosting.co.za>
Message-ID: <1453220692.82.0.363568889537.issue26157@psf.upfronthosting.co.za>


Changes by Carlo Beccarini :


----------
keywords: +patch
Added file: http://bugs.python.org/file41662/patch.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 11:35:43 2016
From: report at bugs.python.org (Rose Ames)
Date: Tue, 19 Jan 2016 16:35:43 +0000
Subject: [issue26144] test_pkg test_4 and/or test_7 sometimes fail
In-Reply-To: <1453094860.75.0.307197769475.issue26144@psf.upfronthosting.co.za>
Message-ID: <1453221343.72.0.982115723307.issue26144@psf.upfronthosting.co.za>


Rose Ames added the comment:

redirecting stdout seems to reliably suppress both failures:

$ ./python -m test -w test_pkg >foo
$ cat foo
[1/1] test_pkg
1 test OK.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 11:41:17 2016
From: report at bugs.python.org (Stephen Paul Chappell)
Date: Tue, 19 Jan 2016 16:41:17 +0000
Subject: [issue26158] File truncate() not defaulting to current position as
 documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453221677.4.0.344846022186.issue26158@psf.upfronthosting.co.za>


Changes by Stephen Paul Chappell :


----------
nosy: +Zero

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 12:15:22 2016
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Tue, 19 Jan 2016 17:15:22 +0000
Subject: [issue26151] str(bytes) does __repr__() instead of __str__()
In-Reply-To: <1453204324.06.0.936189522154.issue26151@psf.upfronthosting.co.za>
Message-ID: <1453223722.03.0.481226128583.issue26151@psf.upfronthosting.co.za>


Walter D?rwald added the comment:

But this leads to uninspectable objects.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 12:24:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Jan 2016 17:24:43 +0000
Subject: [issue26158] File truncate() not defaulting to current position as
 documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453224283.82.0.40657108775.issue26158@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is because the file is buffered.

>>> open('temp.txt', 'w').write('ABCDE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\n')
32
>>> f = open('temp.txt', 'r+')
>>> f.readline()
'ABCDE\n'
>>> f.tell()
6
>>> f.buffer.tell()
32
>>> f.buffer.raw.tell()
32

The documentation needs a clarification.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +benjamin.peterson, docs at python, haypo, pitrou, serhiy.storchaka, steve.dower, stutzbach
versions: +Python 2.7, Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 12:46:14 2016
From: report at bugs.python.org (Fornax)
Date: Tue, 19 Jan 2016 17:46:14 +0000
Subject: [issue26158] File truncate() not defaulting to current position as
 documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453225574.49.0.492043886443.issue26158@psf.upfronthosting.co.za>


Fornax added the comment:

To clarify... the intended behavior is for truncate to default to the current position of the buffer, rather than the current position as reported directly from the stream by tell?

That seems... surprising.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 12:46:56 2016
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 19 Jan 2016 17:46:56 +0000
Subject: [issue26158] File truncate() not defaulting to current position as
 documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453225616.37.0.137507915152.issue26158@psf.upfronthosting.co.za>


Eryk Sun added the comment:

Serhiy, why doesn't truncate do a seek(0, SEEK_CUR) to synchronize the buffer's file pointer before calling its truncate method? This also affects writing in "+" modes when the two file pointers are out of sync.

----------
nosy: +eryksun

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 12:50:02 2016
From: report at bugs.python.org (Jake Garver)
Date: Tue, 19 Jan 2016 17:50:02 +0000
Subject: [issue24324] Remove -Wunreachable-code flag
In-Reply-To: <1432907477.51.0.798249204562.issue24324@psf.upfronthosting.co.za>
Message-ID: <1453225802.6.0.264164913687.issue24324@psf.upfronthosting.co.za>


Changes by Jake Garver :


Added file: http://bugs.python.org/file41663/Python351-no-unreachable-check.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 13:04:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Jan 2016 18:04:26 +0000
Subject: [issue26158] File truncate() not defaulting to current position as
 documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453226666.56.0.308728032052.issue26158@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is not always possible. Consider following example:

>>> open('temp.txt', 'wb').write(b'+BDAEMQQyBDMENA-')
16
>>> f = open('temp.txt', 'r+', encoding='utf-7')
>>> f.read(2)
'??'

What should be the result of truncating?

I think it would be better to not implement truncate() for text files at all.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 13:23:00 2016
From: report at bugs.python.org (Fornax)
Date: Tue, 19 Jan 2016 18:23:00 +0000
Subject: [issue26158] File truncate() not defaulting to current position as
 documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453227780.66.0.0257660719865.issue26158@psf.upfronthosting.co.za>


Fornax added the comment:

Heh... building on Serhiy's example:

>>> f.tell()
680564735109527527154978616360239628288

I'm way out of my depth here. The results seem surprising, but I lack the experience to be able to say what they "should" look like. So I guess if it's working as intended and just needs clarification in the documentation, so be it.

Thanks for pointing out what's actually causing the behavior.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 13:53:52 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Tue, 19 Jan 2016 18:53:52 +0000
Subject: [issue26152] A non-breaking space in a source
In-Reply-To: <1453204897.88.0.969876573405.issue26152@psf.upfronthosting.co.za>
Message-ID: <1453229632.22.0.311638428984.issue26152@psf.upfronthosting.co.za>


Andrew Barnert added the comment:

Ultimately, this is because the tokenizer works byte by byte instead of character by character, as far as possible. Since any byte >= 128 must be part of some non-ASCII character, and the only legal use for non-ASCII characters outside of quotes and comments is as part of an identifier, the tokenizer assumes (see the macros at the top of tokenizer.c, and the top of the again block in tok_get) that any byte >= 128 is part of an identifier, and then checks the whole string with PyUnicode_IsIdentifier at the end.

This actually gives a better error for more visible glyphs, especially ones that look letter-like but aren't in XID_Continue, but it is kind of weird for a few, like non-break space.

If this needs to be fixed, I think the simplest thing is to special-case things: if the first non-valid-identifier character is in category Z, set an error about invalid whitespace instead of invalid identifier character. (This would probably require adding a PyUnicode_CheckIdentifier that, instead of just returning 0 for failure as PyUnicode_IsIdentifier, returns -n for non-identifier character with code point n.)

----------
nosy: +abarnert

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 14:24:28 2016
From: report at bugs.python.org (Fornax)
Date: Tue, 19 Jan 2016 19:24:28 +0000
Subject: [issue26158] File truncate() not defaulting to current position as
 documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453231468.23.0.121999934745.issue26158@psf.upfronthosting.co.za>


Fornax added the comment:

After taking a little time to let this sink in, I'm going to play Devil's Advocate just a little more.

It sounds like you're basically saying that any read-write text-based modes (e.g. r+, w+) should be used at your own peril. While I understand your UTF-7 counterexample, and it's a fair point, is it out of line to expect that for encodings that operate on full bytes, file positioning should work a bit more intuitively? (Which is to say, a write/truncate after a read should take place in the position immediately following the end of the read.)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 14:32:44 2016
From: report at bugs.python.org (Matthias Bussonnier)
Date: Tue, 19 Jan 2016 19:32:44 +0000
Subject: [issue26153] PyImport_GetModuleDict: no module dictionary! when
 `__del__` triggers a warning
In-Reply-To: <1453205670.9.0.210259286868.issue26153@psf.upfronthosting.co.za>
Message-ID: <1453231964.35.0.858212090233.issue26153@psf.upfronthosting.co.za>


Changes by Matthias Bussonnier :


----------
nosy: +mbussonn

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 14:38:15 2016
From: report at bugs.python.org (Fornax)
Date: Tue, 19 Jan 2016 19:38:15 +0000
Subject: [issue26158] File truncate() not defaulting to current position as
 documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453232295.89.0.586887454079.issue26158@psf.upfronthosting.co.za>


Fornax added the comment:

Another surprising result:

>>> open('temp.txt', 'w').write('ABCDE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\n')
32
>>> f = open('temp.txt', 'r+')
>>> f.write('test')
4
>>> f.close()
>>> open('temp.txt').read()
'testE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\n'

>>> open('temp.txt', 'w').write('ABCDE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\n')
32
>>> f = open('temp.txt', 'r+')
>>> f.write('test')
4
>>> f.read(1)
'A'
>>> f.close()
>>> open('temp.txt').read()
'ABCDE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\ntest'

The position of the write in the file depends on whether or not there is a subsequent read.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 15:00:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Jan 2016 20:00:14 +0000
Subject: [issue26158] File truncate() not defaulting to current position as
 documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453233614.3.0.663923262079.issue26158@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be. Looking at the code, both Python and C implementations of TextIOWrapper look incorrect.

Python implementation:

    def truncate(self, pos=None):
        self.flush()
        if pos is None:
            pos = self.tell()
        return self.buffer.truncate(pos)

If pos is not specified, self.tell() is used as truncating position for underlying binary file. But self.tell() is not an offset in bytes, as seen from UTF-7 example. This is complex cookie that includes starting position in binary file, a number of bytes that should be read and feed to the decoder, and other decoder flags. Needed at least unpack the cookie returned by self.tell(), and raise an exception if it doesn't ambiguously point to binary file position.

C implementation is equivalent to:

    def truncate(self, pos=None):
        self.flush()
        return self.buffer.truncate(pos)

It just ignores decoder buffer.

----------
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 15:46:56 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 19 Jan 2016 20:46:56 +0000
Subject: [issue26151] str(bytes) does __repr__() instead of __str__()
In-Reply-To: <1453204324.06.0.936189522154.issue26151@psf.upfronthosting.co.za>
Message-ID: <1453236416.18.0.31695536473.issue26151@psf.upfronthosting.co.za>


Martin Panter added the comment:

A warning is already emitted if you enable it with the ?-b? flag, which I recommend. You can even turn the warning into an error with ?-bb?. And you can always use repr() or ascii() to inspect for a more robust inspection.

$ python3 -bb
Python 3.5.0 (default, Sep 20 2015, 11:28:25) 
[GCC 5.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print(b"\xFF")
Traceback (most recent call last):
  File "", line 1, in 
BytesWarning: str() on a bytes instance
>>> print(repr(b"\xFF"))
b'\xff'

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 16:19:25 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 21:19:25 +0000
Subject: [issue26151] str(bytes) does __repr__() instead of __str__()
In-Reply-To: <1453204324.06.0.936189522154.issue26151@psf.upfronthosting.co.za>
Message-ID: <1453238365.02.0.909008787723.issue26151@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy:  -haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 16:30:08 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 21:30:08 +0000
Subject: [issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit
 constants
In-Reply-To: <1453136691.51.0.69393755181.issue26146@psf.upfronthosting.co.za>
Message-ID: <1453239008.58.0.741411026787.issue26146@psf.upfronthosting.co.za>


STINNER Victor added the comment:

First I also wanted to add ast.Literal to literals: list, set, dict, etc. But it doesn't work, we loose the item order: set and dict are unordered. An optimizer must not change the order in which items are created. At least, not by default.

I'm talking about an hypothetical ast.Literal type which would take a Python object (list, set, etc.) Current ast.Set contains an ordered list of items, ast.Dict uses two ordered lists for keys and values.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 16:38:29 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 19 Jan 2016 21:38:29 +0000
Subject: [issue26158] File truncate() not defaulting to current position as
 documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453239509.64.0.993822204527.issue26158@psf.upfronthosting.co.za>


Martin Panter added the comment:

In theory, TextIOWrapper could rewrite the last bit of the file (or the whole file) to have the requested number of characters. But I wonder if it is worth it; maybe deprecation is better. Do you have a use case for any of these bugs, or are you just playing around to see what the methods do?

In Issue 12922, seek() and tell() were (re-)defined for TextIOBase, but the situation with truncate() was apparently not considered.

Perhaps the write()?read() bug is related to Issue 12215.

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 16:50:31 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 19 Jan 2016 21:50:31 +0000
Subject: [issue24923] Append system paths in setup.py instead of prepending
In-Reply-To: <1440428121.6.0.746141080033.issue24923@psf.upfronthosting.co.za>
Message-ID: <1453240231.8.0.502514725073.issue24923@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I've been doing some research on this, the below is pretty much a brain-dump.

Related issues: issue232609, issue420565, issue10520.

This looks to me like the ideal solution is to assign a priority to each entry and sort by that priority before using it; give system locations low priority, /usr/local (sys.prefix) locations slightly higher priority, and user-defined paths highest priority.  That may be far more complex than it's worth, though.

It looks like setup.py doesn't actually look at CFLAGS at all, just CPPFLAGS and LDFLAGS.

Chris, is the behavior of 3.x any better for you?  There are some differences between the 2.7 and 3.x implementations of add_dir_to_list (most obviously, relative paths are always kept at the front of the list; see issue10520).

The naive solution looks to me to be to just move the CPPFLAGS/LDFLAGS checking further down detect_modules(), past all other calls to add_dir_to_list.  A test build with that change seems to work for me, but I'm not familiar enough with setup.py and how it works to call it correct.

----------
nosy: +zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 16:56:22 2016
From: report at bugs.python.org (Fornax)
Date: Tue, 19 Jan 2016 21:56:22 +0000
Subject: [issue26158] File truncate() not defaulting to current position as
 documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453240582.63.0.000511414294997.issue26158@psf.upfronthosting.co.za>


Fornax added the comment:

I don't have a specific use case. This spawned from a tangentially-related StackOverflow question (http://stackoverflow.com/questions/34858088), where in the answers a behavior difference between Python 2 and 3 was noted. I couldn't find any documentation to explain it, so I opened a follow-up question (http://stackoverflow.com/questions/34879318), and based on some feedback I got there, I opened up this issue.

Just to be sure I understand, you're suggesting deprecating truncate on text-mode file objects? And the interleaved read-writes are likely related to an issue that will be dealt with elsewhere?

----------
type: behavior -> 

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 16:58:17 2016
From: report at bugs.python.org (Johnny Wezel)
Date: Tue, 19 Jan 2016 21:58:17 +0000
Subject: [issue26151] str(bytes) does __repr__() instead of __str__()
In-Reply-To: <1453204324.06.0.936189522154.issue26151@psf.upfronthosting.co.za>
Message-ID: <1453240697.96.0.081321538419.issue26151@psf.upfronthosting.co.za>


Johnny Wezel added the comment:

> But this leads to uninspectable objects.

An inspection would be done with repr() which should not cause a problem.

Besides. the official and correct way of handling an ff character is to emit a Unicode replacement code, not to issue an exception. Another flaw in the whole story.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 17:07:34 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 22:07:34 +0000
Subject: [issue26158] File truncate() not defaulting to current position as
 documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453241254.72.0.364327621618.issue26158@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy:  -haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 17:11:11 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 19 Jan 2016 22:11:11 +0000
Subject: [issue26158] File truncate() not defaulting to current position as
 documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453241471.21.0.211715183595.issue26158@psf.upfronthosting.co.za>


???? ????????? added the comment:

text files and seek() offset: issue25849

----------
nosy: +mmarkk

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 17:22:54 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 19 Jan 2016 22:22:54 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1453242174.01.0.973409119304.issue25702@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I'm a bit concerned that the flags are being added unconditionally to CFLAGS and LDFLAGS (when configured --with-lto), which means extensions are forced into it as well.  I think it would be better to use CFLAGS_NODIST and to add LDFLAGS_NODIST.  Unfortunately, 2.7 doesn't have even CFLAGS_NODIST; I suspect it may be time to backport that.

----------
nosy: +zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 17:26:54 2016
From: report at bugs.python.org (Antti Haapala)
Date: Tue, 19 Jan 2016 22:26:54 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1453242414.58.0.508635010084.issue26107@psf.upfronthosting.co.za>


Antti Haapala added the comment:

Nice work, my issue21385 is also related. Basically, transforming non-Python code into Python meant that all line number information, which otherwise would have been useful for debugging, had to be discarded, or debug builds of Python would dump cores.

So, bye "assert(d_lineno >= 0);", you won't be missed.

----------
nosy: +ztane

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 17:37:50 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 19 Jan 2016 22:37:50 +0000
Subject: [issue17781] optimize compilation options
In-Reply-To: <1366224008.41.0.60101315886.issue17781@psf.upfronthosting.co.za>
Message-ID: <1453243070.68.0.78612045157.issue17781@psf.upfronthosting.co.za>


Zachary Ware added the comment:

PGO is available as `make profile-opt`, LTO has a patch in issue25702.  Are there any other interesting options worth investigating?

----------
nosy: +zach.ware
status: open -> pending

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 17:46:28 2016
From: report at bugs.python.org (fireattack)
Date: Tue, 19 Jan 2016 22:46:28 +0000
Subject: [issue15809] 2.7 IDLE  console uses incorrect encoding.
In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za>
Message-ID: <1453243587.99.0.00112855432032.issue15809@psf.upfronthosting.co.za>


fireattack added the comment:

Any update on this?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 17:50:06 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 19 Jan 2016 22:50:06 +0000
Subject: [issue25934] ICC compiler: ICC treats denormal floating point numbers
 as 0.0
In-Reply-To: <1450911743.93.0.393041043786.issue25934@psf.upfronthosting.co.za>
Message-ID: <1453243806.13.0.430625055736.issue25934@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I've looked into this a bit, and tests won't pass with MSVC /fp:strict, so it would need to be ICC specific.  UNIX ICC builds do unconditionally use -fp-model strict now, though, so I think Windows ICC builds should as well.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 17:50:26 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Jan 2016 22:50:26 +0000
Subject: [issue15809] 2.7 IDLE  console uses incorrect encoding.
In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za>
Message-ID: <1453243826.12.0.956261644271.issue15809@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
nosy:  -r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 17:52:56 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Jan 2016 22:52:56 +0000
Subject: [issue17781] optimize compilation options
In-Reply-To: <1366224008.41.0.60101315886.issue17781@psf.upfronthosting.co.za>
Message-ID: <1453243976.69.0.183325259708.issue17781@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
nosy: +r.david.murray
status: pending -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 17:54:42 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Jan 2016 22:54:42 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1453244082.46.0.184162485402.issue25702@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
nosy: +r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 17:56:07 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Jan 2016 22:56:07 +0000
Subject: [issue24923] Append system paths in setup.py instead of prepending
In-Reply-To: <1440428121.6.0.746141080033.issue24923@psf.upfronthosting.co.za>
Message-ID: <1453244167.1.0.0856485956053.issue24923@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
nosy: +r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 18:00:27 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Jan 2016 23:00:27 +0000
Subject: [issue17781] optimize compilation options
In-Reply-To: <1366224008.41.0.60101315886.issue17781@psf.upfronthosting.co.za>
Message-ID: <1453244427.44.0.599226032217.issue17781@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
status: open -> pending

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 18:03:46 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Jan 2016 23:03:46 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1453244626.55.0.129412963426.issue25702@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Unfortunately, 2.7 doesn't have even CFLAGS_NODIST; I suspect it may be time to backport that.

I don't think now is a good time to introduce instability in the 2.7 branch.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 18:09:09 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 19 Jan 2016 23:09:09 +0000
Subject: [issue15809] 2.7 IDLE  console uses incorrect encoding.
In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za>
Message-ID: <1453244949.89.0.966944239911.issue15809@psf.upfronthosting.co.za>


Changes by Ned Deily :


----------
nosy:  -ned.deily

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 18:25:35 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 19 Jan 2016 23:25:35 +0000
Subject: [issue26154] Add private _PyThreadState_FastGet() to get the current
 thread state
In-Reply-To: <1453206633.27.0.0623775421981.issue26154@psf.upfronthosting.co.za>
Message-ID: <1453245935.06.0.871979691941.issue26154@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

Overall +1 to this private API.  I like the UncheckedGet name better than FastGet but don't really care what the name is so long as it keeps this property: It must be non-blocking and safe to call from a signal handler.  Returning NULL in the event the value could not be obtained in such a manner is fine (unlikely to happen from the looks of the 3.5 code).

They are private and this fixes the regression in 3.5.1.  people (ab)using these private APIs should be fine writing conditional compilation code to deal with that.

We've got a similar patch on our CPython 2.7 interpreter at work (more complicated as it must do a non-blocking lock acquire in the old 2.7 code).

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 18:34:46 2016
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 19 Jan 2016 23:34:46 +0000
Subject: [issue26158] File truncate() not defaulting to current position as
 documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453246486.06.0.790685821146.issue26158@psf.upfronthosting.co.za>


Eryk Sun added the comment:

FYI, you can parse the cookie using struct or ctypes. For example:

    class Cookie(ctypes.Structure):
        _fields_ = (('start_pos',     ctypes.c_longlong),
                    ('dec_flags',     ctypes.c_int),
                    ('bytes_to_feed', ctypes.c_int),
                    ('chars_to_skip', ctypes.c_int),
                    ('need_eof',      ctypes.c_byte))

In the simple case only the buffer start_pos is non-zero, and the result of tell() is just the 64-bit file pointer. In Serhiy's UTF-7 example it needs to also convey the bytes_to_feed and chars_to_skip values:

    >>> f.tell()
    680564735109527527154978616360239628288
    >>> cookie_bytes = f.tell().to_bytes(ctypes.sizeof(Cookie), sys.byteorder)
    >>> state = Cookie.from_buffer_copy(cookie_bytes)
    >>> state.start_pos
    0
    >>> state.dec_flags
    0
    >>> state.bytes_to_feed
    16
    >>> state.chars_to_skip
    2
    >>> state.need_eof
    0

So a seek(0, SEEK_CUR) in this case has to seek the buffer to 0, read and decode 16 bytes, and skip 2 characters. 

Isn't this solvable at least for the case of truncating, Martin? It could do a tell(), seek to the start_pos, read and decode the bytes_to_feed, re-encode the chars_to_skip, seek back to the start_pos, write the encoded characters, and then truncate.

    >>> f = open('temp.txt', 'w+', encoding='utf-7')
    >>> f.write(b'+BDAEMQQyBDMENA-'.decode('utf-7'))
    5
    >>> _ = f.seek(0); f.read(2)
    '??'
    >>> cookie_bytes = f.tell().to_bytes(sizeof(Cookie), byteorder)
    >>> state = Cookie.from_buffer_copy(cookie_bytes)
    >>> f.buffer.seek(state.start_pos)
    0
    >>> buf = f.buffer.read(state.bytes_to_feed)
    >>> s = buf.decode(f.encoding)[:state.chars_to_skip]
    >>> f.buffer.seek(state.start_pos)
    0
    >>> f.buffer.write(s.encode(f.encoding))
    8
    >>> f.buffer.truncate()
    8
    >>> f.close()
    >>> open('temp.txt', encoding='utf-7').read()
    '??'

Rewriting the encoded bytes is necessary to properly terminate the UTF-7 sequence, which makes me doubt whether this simple approach will work for all codecs. But something like this is possible, no?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 21:09:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Jan 2016 02:09:55 +0000
Subject: [issue25863] ISO-2022 seeking forgets state
In-Reply-To: <1450147044.33.0.0242462239972.issue25863@psf.upfronthosting.co.za>
Message-ID: <1453255795.53.0.630079966645.issue25863@psf.upfronthosting.co.za>


Martin Panter added the comment:

After thinking about Issue 26158, I realize the seek() magic numbers don?t store any _encoder_ state, only _decoder_ state. That would explain the first bug (write, seek, then read). Though for this codec I suspect the decoder state is not recorded either, hence the bug with tell().

Personally I don?t care much for seeking text files. But if someone wanted to fix the second bug, that might require fixing the incremental decoder?s getstate() implementation.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 21:53:42 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Jan 2016 02:53:42 +0000
Subject: [issue12215] TextIOWrapper: issues with interlaced read-write
In-Reply-To: <1306759084.05.0.928785750761.issue12215@psf.upfronthosting.co.za>
Message-ID: <1453258422.34.0.781972333269.issue12215@psf.upfronthosting.co.za>


Martin Panter added the comment:

Consider codecs that maintain an internal buffer (UTF-7) or other state (ISO-2022). When you call TextIOWrapper.read() and then tell(), the I think the returned number is supposed to hold the _decoder_ state, so you can seek back and read again. But I don?t think the number holds any _encoder_ state, so seek() cannot set up the encoder properly for these more awkward codecs.

I don?t think it is practical to fix this problem using the incremental codec API. You would need to construct the encoder?s state from the decoder. There are a couple of bugs marked as duplicates of this. What are the real-world use cases?

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 22:04:51 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Jan 2016 03:04:51 +0000
Subject: [issue26158] File truncate() not defaulting to current position as
 documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453259091.43.0.179773064756.issue26158@psf.upfronthosting.co.za>


Martin Panter added the comment:

Fornax: Yes, I was suggesting the idea of deprecating truncate() for text files! Although a blanket deprecation of all cases may not be realistic. Quickly reading the Stack Overflow pages, it seems like there is demand for this to work in some cases. Deprecating it in the more awkward situations, such as after after reading, and with specific kinds of codecs, might be an option though.

Now I think Issue 12215 (read then write) is more closely related to the read-then-truncate problem. For the write-then-read bug, it might be a separate problem with an easy fix: call flush() before changing to reader mode.

Eryk: If there is no decoder state, and the file data hasn?t changed, maybe it is solvable. But I realize now it won?t work in general. We would have to construct the encoder state from the decoder state. The same problem as Issue 12215.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 22:46:14 2016
From: report at bugs.python.org (Hiroyuki Takagi)
Date: Wed, 20 Jan 2016 03:46:14 +0000
Subject: [issue26140] inspect.iscoroutinefunction raises TypeError when checks
 Mock of function or coroutinefunction
In-Reply-To: <1453030972.84.0.0646105171888.issue26140@psf.upfronthosting.co.za>
Message-ID: <1453261574.88.0.59851332474.issue26140@psf.upfronthosting.co.za>


Hiroyuki Takagi added the comment:

Thank you for reviewing patch.

I wrote test and updated patch. To pass the test, both this patch and issue25599's patch are required.

Changes of the patch:
- copy __code__ not only functions but also methods
- add autospec (create_autospec) suppoort

I have completely missed about autospec, thank you for a mention about it.
For autospec, simply copying original __code__ to funcopy makes error on existing tests.
That's why I changed the src of exec, but it seems to be quite ad-hoc. It may be better to be improved, but I don't have any good idea, sorry.

On the tests of this patch, I wonder if it's better to use assertIs(.., True/False) instead of assertTrue/False, since it was one of the problem in issue25599.
To apply this change and pass test, need to change asyncio.iscoroutinefunction to return bool. The change would be very easy, just update issue25599's patch like `return_value = bool(getattr(func, ...`.

----------
Added file: http://bugs.python.org/file41664/mock2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 23:31:30 2016
From: report at bugs.python.org (random832)
Date: Wed, 20 Jan 2016 04:31:30 +0000
Subject: [issue26158] File truncate() not defaulting to current position as
 documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453264290.88.0.751417733021.issue26158@psf.upfronthosting.co.za>


random832 added the comment:

In the analogous C operations, ftell (analogous to .tell) actually causes the underlying file descriptor's position (analogous to the raw stream's position) to be reset to be at the same value that ftell has returned. Which means, yes, that you lose the benefits of buffering if you're so foolish as to call ftell after every read. But in this case the sequence "read / tell / truncate" would be analogous to "fread(f) / ftell(f) / ftruncate(fileno(f))

Though, the fact that fread operates on the FILE * whereas truncate operates on a file descriptor serves as a red flag to C programmers... arguably since this is not the case with Python, truncate on a buffered stream should implicitly include this same "reset underlying position" operation before actually performing the truncate.

----------
nosy: +random832

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 00:14:57 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Jan 2016 05:14:57 +0000
Subject: [issue26157] Typo in asyncio documentation
In-Reply-To: <1453216588.95.0.751274480755.issue26157@psf.upfronthosting.co.za>
Message-ID: <20160120051451.121304.84217@psf.io>


Roundup Robot added the comment:

New changeset 7415a9386048 by Berker Peksag in branch '3.5':
Issue #26157: Fix typos in asyncio-eventloop.rst
https://hg.python.org/cpython/rev/7415a9386048

New changeset 67f562cbd87b by Berker Peksag in branch 'default':
Issue #26157: Fix typos in asyncio-eventloop.rst
https://hg.python.org/cpython/rev/67f562cbd87b

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 00:17:36 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 20 Jan 2016 05:17:36 +0000
Subject: [issue26157] Typo in asyncio documentation
In-Reply-To: <1453216588.95.0.751274480755.issue26157@psf.upfronthosting.co.za>
Message-ID: <1453267056.01.0.314423563687.issue26157@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks! I noticed another typo in the same file and fixed it.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 00:28:16 2016
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 20 Jan 2016 05:28:16 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1453267696.64.0.77876460006.issue25702@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Unless I'm just missing something, I don't see how introducing CFLAGS_NODIST and LDFLAGS_NODIST to 2.7 would introduce instability.  It should be a fairly non-invasive change, restricted to configure and the Makefile; both vars should usually be empty and thus builds should be entirely unaffected unless options like --with-lto are chosen.


On a separate note about the patch: as mentioned in msg251305, it's probably better to restrict adding the LTO flags to just the profile-opt targets, even with the --with-lto check.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 01:09:05 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 20 Jan 2016 06:09:05 +0000
Subject: [issue26155] 3.5.1 installer issue on Win 7 32 bit
In-Reply-To: <1453213607.65.0.0758375238655.issue26155@psf.upfronthosting.co.za>
Message-ID: <1453270145.15.0.867392150718.issue26155@psf.upfronthosting.co.za>


Steve Dower added the comment:

You should have some log files in your %TEMP% directory, all starting with "python". Could you post those here? They'll help us see what happened.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 01:12:35 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Jan 2016 06:12:35 +0000
Subject: [issue25925] Coverage support for CPython 2
In-Reply-To: <1450793280.08.0.219488007546.issue25925@psf.upfronthosting.co.za>
Message-ID: <20160120061230.96354.80371@psf.io>


Roundup Robot added the comment:

New changeset ed7b602a7400 by Zachary Ware in branch '2.7':
Issue #25925: Backport C coverage reporting Makefile targets
https://hg.python.org/cpython/rev/ed7b602a7400

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 01:13:25 2016
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 20 Jan 2016 06:13:25 +0000
Subject: [issue25925] Coverage support for CPython 2
In-Reply-To: <1450793280.08.0.219488007546.issue25925@psf.upfronthosting.co.za>
Message-ID: <1453270405.91.0.820510674399.issue25925@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Committed (with a couple minor tweaks), thanks for the patch!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 01:27:46 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 20 Jan 2016 06:27:46 +0000
Subject: [issue10367] "python setup.py sdist upload --show-response" can fail
 with "UnboundLocalError: local variable 'result' referenced before
 assignment"
In-Reply-To: <1289252212.79.0.124730407849.issue10367@psf.upfronthosting.co.za>
Message-ID: <1453271266.4.0.677864237085.issue10367@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This has been fixed in issue 12853. The relevant line is here: https://hg.python.org/cpython/file/2.7/Lib/distutils/command/upload.py#l179

Closing this one as a duplicate.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> global name 'r' is not defined in upload.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 01:39:00 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 20 Jan 2016 06:39:00 +0000
Subject: [issue8519] doc: termios and ioctl reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1453271940.74.0.392971820614.issue8519@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

I followed the previous discussions and reviewed the patch. With respect to the patch, I see few drawbacks in providing links to references like this:

`fcntl `_
`ioctl `_
`the POSIX specification +`_

these URLs can quickly become outdated and it will be an unnecessary detail for us to maintain.

Instead, I suggest we have references like :manpage:`fcntl(2)`, :manpage:`ioctl(2)` and :manpage:`termios(2)`, a supported directive by sphinx, so that users can quickly search for those and land up on relevant and latest documentation.

----------
nosy: +orsenthil

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 01:46:00 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Jan 2016 06:46:00 +0000
Subject: [issue15809] 2.7 IDLE  console uses incorrect encoding.
In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za>
Message-ID: <1453272360.67.0.730497781758.issue15809@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Serhiy, unless you are planning to do something more, please close this.  The extended extended maintenance period for 2.7 is mainly for build and security issues, and I don't expect to do any more 2.7-only patches.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 01:46:01 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Jan 2016 06:46:01 +0000
Subject: [issue5626] misleading comment in socket.gethostname() documentation
In-Reply-To: <1238515382.33.0.784525971679.issue5626@psf.upfronthosting.co.za>
Message-ID: <20160120064558.25973.60550@psf.io>


Roundup Robot added the comment:

New changeset e1a711808cfe by Berker Peksag in branch '3.5':
Issue #5626: Remove misleading comment from socket.gethostname() documentation
https://hg.python.org/cpython/rev/e1a711808cfe

New changeset 689f881dd5d1 by Berker Peksag in branch 'default':
Issue #5626: Remove misleading comment from socket.gethostname() documentation
https://hg.python.org/cpython/rev/689f881dd5d1

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 01:46:38 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 20 Jan 2016 06:46:38 +0000
Subject: [issue5626] misleading comment in socket.gethostname() documentation
In-Reply-To: <1238515382.33.0.784525971679.issue5626@psf.upfronthosting.co.za>
Message-ID: <1453272398.14.0.968854926459.issue5626@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 02:02:32 2016
From: report at bugs.python.org (Kevin Norris)
Date: Wed, 20 Jan 2016 07:02:32 +0000
Subject: [issue26160] Tutorial incorrectly claims that (explicit) relative
 imports don't work in the main module
Message-ID: <1453273352.49.0.425335373136.issue26160@psf.upfronthosting.co.za>


New submission from Kevin Norris:

The tutorial contains this statement:

Note that relative imports are based on the name of the current module. Since the name of the main module is always "__main__", modules intended for use as the main module of a Python application must always use absolute imports.

See .  The wording is slightly different in the 2.7 version of the tutorial to account for the existence of implicit relative imports, but it clearly states that explicit relative imports suffer from this limitation.

As of PEP 366, this is no longer true.  You can do (explicit) relative imports in the main module just fine (though with some minor caveats w.r.t. using the -m flag vs. specifying the .py file directly).  PEP 366 has a Python-Version of 2.6, 3.0, so every sufficiently recent version of the tutorial is wrong.

It's probably not a good idea to get too far into those caveats in the tutorial.  I'd suggest wording like this:

Note that relative imports are based on the name of the current package.  If Python is invoked with the -m switch, it can determine the package name automatically, but if it is invoked directly as ``python file.py``, relative imports will not work because Python doesn't know what package file.py belongs to.

It might be worth mentioning __package__ here, too, but we don't want to get too far down the rabbit hole of trivia (e.g. PEP 366 discusses sys.path manipulation, and for that you probably want to use __file__ instead of hard-coding the path, and then you have to talk about zipimports, and then, and then, and then...!).

(For the record, is the 2.7 tutorial still under active support?  Is it okay to report bugs in it?)

----------
assignee: docs at python
components: Documentation
messages: 258650
nosy: Kevin.Norris, docs at python
priority: normal
severity: normal
status: open
title: Tutorial incorrectly claims that (explicit) relative imports don't work in the main module
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 02:27:02 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 20 Jan 2016 07:27:02 +0000
Subject: [issue19225] lack of PyExc_BufferError doc
In-Reply-To: <1381485777.95.0.364414099437.issue19225@psf.upfronthosting.co.za>
Message-ID: <1453274822.74.0.688789400675.issue19225@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
keywords: +easy
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 03:37:58 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Jan 2016 08:37:58 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1453279078.96.0.621641232897.issue25702@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Any non-bugfix introduction can introduce instability. That has always been our position with respect to adding features to bugfix branches. I don't see how adding a LTO option this late in the 2.7 release cycle can be considered important enough to break that rule.

Let me add that downstream distributors already customize compilation options (Ubuntu's Python is compiled with both PGO and LTO enabled, AFAIR), so this change may only really affect the tiny subset of non-Windows users that compile Python themselves.

But well, perhaps Python development has become boring to the point of deliberately introducing uncertainty and risk to make things a bit more fun? ;-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 03:41:38 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 20 Jan 2016 08:41:38 +0000
Subject: [issue25934] ICC compiler: ICC treats denormal floating point numbers
 as 0.0
In-Reply-To: <1450911743.93.0.393041043786.issue25934@psf.upfronthosting.co.za>
Message-ID: <1453279298.29.0.717735719426.issue25934@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Which tests fail with MSVC /fp:strict? It's surprising that making behaviour stricter causes tests to fail that wouldn't have done otherwise. :-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 03:41:55 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 08:41:55 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1453279078.96.0.621641232897.issue25702@psf.upfronthosting.co.za>
Message-ID: 


STINNER Victor added the comment:

I suggest to only modify the default branch and work with downstream (like
Linux vendors) to compile Python with best compiler options.

I'm talking about the default compilation mode. Maybe we can add a
configure option to 2.7 and 3.5, disabled by default, to use best options.

Sorry I didn't read the whole discussion.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 03:42:37 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 20 Jan 2016 08:42:37 +0000
Subject: [issue25843] lambdas on the same line may incorrectly share code
 objects
In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za>
Message-ID: <1453279357.09.0.871307296726.issue25843@psf.upfronthosting.co.za>


Changes by Mark Dickinson :


----------
nosy: +mark.dickinson

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 03:55:46 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 20 Jan 2016 08:55:46 +0000
Subject: [issue26150] SequenceMatcher's algorithm is not correct
In-Reply-To: <1453201598.83.0.994407990741.issue26150@psf.upfronthosting.co.za>
Message-ID: <1453280146.36.0.764851039068.issue26150@psf.upfronthosting.co.za>


Changes by Senthil Kumaran :


----------
nosy: +orsenthil

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 04:10:06 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Jan 2016 09:10:06 +0000
Subject: [issue26147] Encoding errors in xmlrpc
In-Reply-To: <1453141309.77.0.0400539753207.issue26147@psf.upfronthosting.co.za>
Message-ID: <20160120090959.41340.58476@psf.io>


Roundup Robot added the comment:

New changeset bb2cb184eca9 by Serhiy Storchaka in branch '2.7':
Issue #26147: xmlrpclib now works with unicode not encodable with used
https://hg.python.org/cpython/rev/bb2cb184eca9

New changeset 6c624ba1b61e by Serhiy Storchaka in branch '3.5':
Issue #26147: xmlrpc now works with strings not encodable with used
https://hg.python.org/cpython/rev/6c624ba1b61e

New changeset 72034327022e by Serhiy Storchaka in branch 'default':
Issue #26147: xmlrpc now works with strings not encodable with used
https://hg.python.org/cpython/rev/72034327022e

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 04:27:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Jan 2016 09:27:32 +0000
Subject: [issue26147] Encoding errors in xmlrpc
In-Reply-To: <1453141309.77.0.0400539753207.issue26147@psf.upfronthosting.co.za>
Message-ID: <1453282052.84.0.526301985576.issue26147@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  Wed Jan 20 04:27:49 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Wed, 20 Jan 2016 09:27:49 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1453282069.96.0.199649740678.issue25702@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

Thank you for your feedback, I've updated the patches and now LTO flags are used only when building with PGO (v04). CFLAGS/LDFLAGS remain untouched, as Antoine and Victor suggested is better.

----------
Added file: http://bugs.python.org/file41665/lto-cpython2-v04.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 04:28:00 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Wed, 20 Jan 2016 09:28:00 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1453282080.74.0.636084300156.issue25702@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu :


Added file: http://bugs.python.org/file41666/lto-cpython3-v04.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 04:39:57 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Jan 2016 09:39:57 +0000
Subject: [issue1674555] sys.path in tests contains system directories
Message-ID: <1453282797.43.0.374204524909.issue1674555@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
nosy: +martin.panter, serhiy.storchaka
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 04:57:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Jan 2016 09:57:30 +0000
Subject: [issue1747670] Limiting data copy in xmlrpclib
Message-ID: <1453283850.0.0.536844763617.issue1747670@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
status: open -> pending

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 04:57:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Jan 2016 09:57:45 +0000
Subject: [issue1690840] xmlrpclib methods submit call on __str__, __repr__
Message-ID: <1453283865.87.0.447815957379.issue1690840@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
status: open -> pending

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 05:04:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Jan 2016 10:04:14 +0000
Subject: [issue12912] xmlrpclib.__version__ not bumped with updates
In-Reply-To: <1315316505.08.0.403062949645.issue12912@psf.upfronthosting.co.za>
Message-ID: <1453284254.7.0.776624083482.issue12912@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
status: open -> pending

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 05:20:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Jan 2016 10:20:00 +0000
Subject: [issue10066] xmlrpclib does not handle some non-printable characters
 properly
In-Reply-To: <1286813801.19.0.762560466895.issue10066@psf.upfronthosting.co.za>
Message-ID: <1453285200.08.0.903685647316.issue10066@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> xmlrpc library returns string which contain null ( \x00 )

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 05:20:39 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Jan 2016 10:20:39 +0000
Subject: [issue26154] Add private _PyThreadState_FastGet() to get the current
 thread state
In-Reply-To: <1453206633.27.0.0623775421981.issue26154@psf.upfronthosting.co.za>
Message-ID: <20160120102036.25979.25384@psf.io>


Roundup Robot added the comment:

New changeset f9461f1e0559 by Victor Stinner in branch '3.5':
Add _PyThreadState_UncheckedGet()
https://hg.python.org/cpython/rev/f9461f1e0559

New changeset d4f13c9a2b07 by Victor Stinner in branch 'default':
Merge 3.5
https://hg.python.org/cpython/rev/d4f13c9a2b07

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 05:21:22 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 10:21:22 +0000
Subject: [issue26154] Add private _PyThreadState_UncheckedGet() to get the
 current thread state
In-Reply-To: <1453206633.27.0.0623775421981.issue26154@psf.upfronthosting.co.za>
Message-ID: <1453285282.7.0.425914501761.issue26154@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Function added

@fijal: Sorry for the annoyance of the Python 3.5.1 regression.

----------
resolution:  -> fixed
status: open -> closed
title: Add private _PyThreadState_FastGet() to get the current thread state -> Add private _PyThreadState_UncheckedGet() to get the current thread state

_______________________________________
Python tracker 

_______________________________________

From mal at egenix.com  Wed Jan 20 05:24:07 2016
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 20 Jan 2016 11:24:07 +0100
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1453279078.96.0.621641232897.issue25702@psf.upfronthosting.co.za>
References: <1453279078.96.0.621641232897.issue25702@psf.upfronthosting.co.za>
Message-ID: <569F6047.3050903@egenix.com>

On 20.01.2016 09:37, Antoine Pitrou wrote:
> Let me add that downstream distributors already customize compilation options (Ubuntu's Python is compiled with both PGO and LTO enabled, AFAIR), so this change may only really affect the tiny subset of non-Windows users that compile Python themselves.

Are the Windows installers on python.org compiled with PGO and
LTO enabled ?

If not, then the patch would also effect the not-so-tiny fraction
of Python users on Windows ;-)

BTW: It may make sense to start collecting the various performance
related optional patches to Python 2.7 on a wiki page for interested
parties to use.

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Wed Jan 20 05:24:18 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 20 Jan 2016 10:24:18 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1453279078.96.0.621641232897.issue25702@psf.upfronthosting.co.za>
Message-ID: <569F6047.3050903@egenix.com>


Marc-Andre Lemburg added the comment:

On 20.01.2016 09:37, Antoine Pitrou wrote:
> Let me add that downstream distributors already customize compilation options (Ubuntu's Python is compiled with both PGO and LTO enabled, AFAIR), so this change may only really affect the tiny subset of non-Windows users that compile Python themselves.

Are the Windows installers on python.org compiled with PGO and
LTO enabled ?

If not, then the patch would also effect the not-so-tiny fraction
of Python users on Windows ;-)

BTW: It may make sense to start collecting the various performance
related optional patches to Python 2.7 on a wiki page for interested
parties to use.

----------
nosy: +lemburg

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 05:29:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Jan 2016 10:29:46 +0000
Subject: [issue26160] Tutorial incorrectly claims that (explicit) relative
 imports don't work in the main module
In-Reply-To: <1453273352.49.0.425335373136.issue26160@psf.upfronthosting.co.za>
Message-ID: <1453285786.22.0.428021549097.issue26160@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes 2.7 is open for changes to the documentation like this, as is 3.5+.

It?s been a while since I looked at the tutorial. Does it even mention the ?python -m? mode? I don?t think this is the right place to introduce it.

Perhaps it would be okay to just say relative imports are based on the _full_ name of the current module. It could be misleading saying ?the name of the current package?, because the import could be relative to the a higher level parent package if more than one dot is specified. Then point out that relative imports won?t work with ``python file.py`` or interactive mode, but don?t mention ?-m? (or the other ways to run scripts and modules).

----------
nosy: +martin.panter
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 05:38:15 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Jan 2016 10:38:15 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1453286295.09.0.678350929745.issue25702@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> If not, then the patch would also effect the not-so-tiny fraction
of Python users on Windows ;-)

I don't see how enabling LTO for gcc and clang could ever affect our Windows users ;-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 05:57:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 10:57:13 +0000
Subject: [issue26161] Use Py_uintptr_t instead of void* for atomic pointers
Message-ID: <1453287433.06.0.917991277181.issue26161@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch fixes compiler warnings on atomic pointers.

Python has 4 implementations of atomic types:

* 
* GCC 4.7+ builtin atomic operations
* GCC x86 and x86_64 assembler
* volatile

The type of atomic pointers changes depending on the implementation. Attached patch changes the _Py_atomic_address to use atomic_uintptr_t () or Py_uintptr_t type internally.

The patchs also adds GET_TSTATE(), SET_TSTATE() and GET_INTERP_STATE() macros in pystate.c to make the code more readable.

This issue is a follow up of the issue #22038 which added support for  in Python/pyatomic.h. See also issues #23644 (compilation issue with g++), #25150 (compilation issue with OpenMP) and #26154 (add _PyThreadState_UncheckedGet()).

I would be "nice" to backport this change to Python 3.5.2 to fix the compiler warning, but I'm not 100% confident that my patch works on all compilers and all platforms. Maybe it's better to "experiment" it only in Python 3.6.

Note: I copied the nosy list of the issue #22038 since this one is a follow up.

----------
components: Interpreter Core
files: atomic_pointer.patch
keywords: patch
messages: 258661
nosy: Arfrever, John.Malmberg, Vitor.de.Lima, fijall, gustavotemple, haypo, koobs, lbianc, neologix
priority: normal
severity: normal
status: open
title: Use Py_uintptr_t instead of void* for atomic pointers
versions: Python 3.6
Added file: http://bugs.python.org/file41667/atomic_pointer.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 05:57:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 10:57:33 +0000
Subject: [issue26161] Use Py_uintptr_t instead of void* for atomic pointers
In-Reply-To: <1453287433.06.0.917991277181.issue26161@psf.upfronthosting.co.za>
Message-ID: <1453287453.68.0.17295340208.issue26161@psf.upfronthosting.co.za>


Changes by STINNER Victor :


Removed file: http://bugs.python.org/file41667/atomic_pointer.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 05:58:39 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 10:58:39 +0000
Subject: [issue26161] Use Py_uintptr_t instead of void* for atomic pointers
In-Reply-To: <1453287433.06.0.917991277181.issue26161@psf.upfronthosting.co.za>
Message-ID: <1453287519.89.0.321594602455.issue26161@psf.upfronthosting.co.za>


STINNER Victor added the comment:

(Oops, I attached the wrong patch. It's now fixed.)

----------
Added file: http://bugs.python.org/file41668/atomic_pointer.patch

_______________________________________
Python tracker 

_______________________________________

From mal at egenix.com  Wed Jan 20 06:03:15 2016
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 20 Jan 2016 12:03:15 +0100
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1453286295.09.0.678350929745.issue25702@psf.upfronthosting.co.za>
References: <1453286295.09.0.678350929745.issue25702@psf.upfronthosting.co.za>
Message-ID: <569F6973.6080500@egenix.com>

On 20.01.2016 11:38, Antoine Pitrou wrote:
>> If not, then the patch would also effect the not-so-tiny fraction
>> of Python users on Windows ;-)
> 
> I don't see how enabling LTO for gcc and clang could ever affect our Windows users ;-)

You have a point there, but perhaps we could start offering
an ICC compiled version for Windows ;-)

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Wed Jan 20 06:03:26 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 20 Jan 2016 11:03:26 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1453286295.09.0.678350929745.issue25702@psf.upfronthosting.co.za>
Message-ID: <569F6973.6080500@egenix.com>


Marc-Andre Lemburg added the comment:

On 20.01.2016 11:38, Antoine Pitrou wrote:
>> If not, then the patch would also effect the not-so-tiny fraction
>> of Python users on Windows ;-)
> 
> I don't see how enabling LTO for gcc and clang could ever affect our Windows users ;-)

You have a point there, but perhaps we could start offering
an ICC compiled version for Windows ;-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 06:12:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Jan 2016 11:12:05 +0000
Subject: [issue25982] multiprocessing docs for Namespace lacks class definition
In-Reply-To: <1451523296.03.0.873921755549.issue25982@psf.upfronthosting.co.za>
Message-ID: <20160120111157.94202.14227@psf.io>


Roundup Robot added the comment:

New changeset 32ee5d197500 by Senthil Kumaran in branch '3.5':
issue25982 - Add a class definition for managers.Namespace in the multiprocessing docs.
https://hg.python.org/cpython/rev/32ee5d197500

New changeset f97da0952a2e by Senthil Kumaran in branch 'default':
merge from 3.5
https://hg.python.org/cpython/rev/f97da0952a2e

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 06:19:02 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Jan 2016 11:19:02 +0000
Subject: [issue25982] multiprocessing docs for Namespace lacks class definition
In-Reply-To: <1451523296.03.0.873921755549.issue25982@psf.upfronthosting.co.za>
Message-ID: <20160120111858.14199.90635@psf.io>


Roundup Robot added the comment:

New changeset 8d7aadd40d30 by Senthil Kumaran in branch '2.7':
issue25982 - Add a class definition for managers.Namespace in the multiprocessing docs.
https://hg.python.org/cpython/rev/8d7aadd40d30

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 06:19:37 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 20 Jan 2016 11:19:37 +0000
Subject: [issue25982] multiprocessing docs for Namespace lacks class definition
In-Reply-To: <1451523296.03.0.873921755549.issue25982@psf.upfronthosting.co.za>
Message-ID: <1453288777.38.0.0681560326739.issue25982@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the report. Fixed.

----------
assignee: davin -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
type: enhancement -> behavior
versions:  -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 06:25:50 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 20 Jan 2016 11:25:50 +0000
Subject: [issue12215] TextIOWrapper: issues with interlaced read-write
In-Reply-To: <1306759084.05.0.928785750761.issue12215@psf.upfronthosting.co.za>
Message-ID: <1453289150.11.0.364198469275.issue12215@psf.upfronthosting.co.za>


Changes by Mark Lawrence :


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 06:26:44 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 20 Jan 2016 11:26:44 +0000
Subject: [issue8519] doc: termios and ioctl reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1453289204.97.0.903533299933.issue8519@psf.upfronthosting.co.za>


Changes by Mark Lawrence :


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 06:27:43 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 20 Jan 2016 11:27:43 +0000
Subject: [issue1674555] sys.path in tests contains system directories
Message-ID: <1453289263.17.0.471565891396.issue1674555@psf.upfronthosting.co.za>


Changes by Mark Lawrence :


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 06:28:44 2016
From: report at bugs.python.org (Ali Razmjoo)
Date: Wed, 20 Jan 2016 11:28:44 +0000
Subject: [issue26162] thread error
Message-ID: <1453289324.96.0.367077041612.issue26162@psf.upfronthosting.co.za>


New submission from Ali Razmjoo:

Hello,

I've got a problem while using threading in python 2.7.10 windows.
I copied errors in here https://gist.github.com/Ali-Razmjoo/d503171d338c6381f94f

with 845 threads,870 and 1000. there isn't any problem or error with 840-830 threads!

----------
messages: 258667
nosy: Ali Razmjoo
priority: normal
severity: normal
status: open
title: thread error
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 06:31:37 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Jan 2016 11:31:37 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <20160120113134.5455.1971@psf.io>


Roundup Robot added the comment:

New changeset 775b74e0e103 by Victor Stinner in branch 'default':
co_lnotab supports negative line number delta
https://hg.python.org/cpython/rev/775b74e0e103

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 06:34:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 11:34:01 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1453289641.97.0.829019562221.issue26107@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Nice work, my issue21385 is also related. Basically, transforming non-Python code into Python meant that all line number information, which otherwise would have been useful for debugging, had to be discarded, or debug builds of Python would dump cores.

Ok, it looks like there are multiple use cases for negative line numbers, and the change doesn't really break anything in practice. I tried to explain exactly who is impacted and how to update the code in the Porting section of What's New in Python 3.6.

For each review Serhiy. I pushed the the change to Python 3.6.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 06:35:39 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 11:35:39 +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: <1453289739.85.0.357928200009.issue21385@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Good news: this issue has been fixed by the commit of the issue #26107.

----------
resolution:  -> fixed
status: open -> closed
superseder:  -> PEP 511: code.co_lnotab: use signed line number delta to support moving instructions in an optimizer

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 06:36:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 11:36:19 +0000
Subject: [issue16956] Allow signed line number deltas in the code object's
 line number table
In-Reply-To: <1358102554.86.0.0981281614451.issue16956@psf.upfronthosting.co.za>
Message-ID: <1453289779.44.0.863236513948.issue16956@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Good news: this issue has been fixed in issue #26107.

----------
resolution:  -> fixed
status: open -> closed
superseder:  -> PEP 511: code.co_lnotab: use signed line number delta to support moving instructions in an optimizer

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 06:37:02 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 11:37:02 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <1453289822.53.0.749863944724.issue26107@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I closed issues #16956 and #21385 as duplicates of this issue.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 06:37:31 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 11:37:31 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1453289851.36.0.097295811677.issue17611@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FYI The issue #26107 changed code.co_lnotab to support negative line number deltas.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 07:37:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 12:37:44 +0000
Subject: [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
Message-ID: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The buildbot "x86 Ubuntu Shared 3.x" build 12691 failed, the previous builds succeeded. Changes:

* f97da0952a2ebe08f2e5999c7473c776c59f3a16 (issue #25982)
* 775b74e0e103f816382a0fc009b6ac51ea956750 (issue #26107)

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/12691/steps/test/logs/stdio

======================================================================
FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_set.py", line 736, in test_hash_effectiveness
    self.assertGreater(4*u, t)
AssertionError: 192 not greater than 256

======================================================================
FAIL: test_hash_effectiveness (test.test_set.TestFrozenSetSubclass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_set.py", line 736, in test_hash_effectiveness
    self.assertGreater(4*u, t)
AssertionError: 192 not greater than 256

----------
components: Tests
keywords: buildbot
messages: 258674
nosy: haypo
priority: normal
severity: normal
status: open
title: FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 07:39:00 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 12:39:00 +0000
Subject: [issue26164] test_with_pip() of test_venv fails on Windows buildbots
Message-ID: <1453293540.51.0.991113408845.issue26164@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86%20Windows7%203.5/builds/591/steps/test/logs/stdio

======================================================================
FAIL: test_with_pip (test.test_venv.EnsurePipTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.5.bolen-windows7\build\lib\test\test_venv.py", line 379, in test_with_pip
    self.assertEqual(err, "")
AssertionError: "d:\\temp\\tmpcyw9drz0\\lib\\site-package[323 chars]\r\n" != ''
- d:\temp\tmpcyw9drz0\lib\site-packages\pip\pep425tags.py:89: RuntimeWarning: Config variable 'Py_DEBUG' is unset, Python ABI tag may be incorrect
-   warn=(impl == 'cp')):
- d:\temp\tmpcyw9drz0\lib\site-packages\pip\pep425tags.py:93: RuntimeWarning: Config variable 'WITH_PYMALLOC' is unset, Python ABI tag may be incorrect
-   warn=(impl == 'cp')):

----------
messages: 258675
nosy: dstufft, haypo
priority: normal
severity: normal
status: open
title: test_with_pip() of test_venv fails on Windows buildbots
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 07:39:22 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 20 Jan 2016 12:39:22 +0000
Subject: [issue21776] distutils.upload uses the wrong order of exceptions
In-Reply-To: <1402911209.04.0.940354382674.issue21776@psf.upfronthosting.co.za>
Message-ID: <1453293562.35.0.911986365096.issue21776@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Lib/distutils/command/upload.py has changed a bit after d86214c98a9c. Here is an updated patch.

----------
nosy: +berker.peksag
stage:  -> patch review
versions: +Python 3.6
Added file: http://bugs.python.org/file41669/issue21776_v2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 07:40:24 2016
From: report at bugs.python.org (Donald Stufft)
Date: Wed, 20 Jan 2016 12:40:24 +0000
Subject: [issue26164] test_with_pip() of test_venv fails on Windows buildbots
In-Reply-To: <1453293540.51.0.991113408845.issue26164@psf.upfronthosting.co.za>
Message-ID: <1453293624.41.0.520032981418.issue26164@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Upstream issue for this is https://github.com/pypa/pip/issues/3383.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 07:41:38 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 12:41:38 +0000
Subject: [issue26145] PEP 511: Add sys.set_code_transformers()
In-Reply-To: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>
Message-ID: <1453293698.76.0.650719210096.issue26145@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Note: ast.PyCF_TRANSFORMED_AST is not implemented yet.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 08:03:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 13:03:19 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1453294999.24.0.3170772514.issue25702@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy:  -haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 08:05:51 2016
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Wed, 20 Jan 2016 13:05:51 +0000
Subject: [issue26152] A non-breaking space in a source
In-Reply-To: <1453204897.88.0.969876573405.issue26152@psf.upfronthosting.co.za>
Message-ID: <1453295151.13.0.502868861472.issue26152@psf.upfronthosting.co.za>


Adam Barto? added the comment:

That explains the message. But why is the caret at a wrong place?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 08:06:04 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 20 Jan 2016 13:06:04 +0000
Subject: [issue18858] dummy_threading lacks threading.get_ident() equivalent
In-Reply-To: <1377638843.21.0.0472654933915.issue18858@psf.upfronthosting.co.za>
Message-ID: <1453295164.95.0.365728519499.issue18858@psf.upfronthosting.co.za>


Berker Peksag added the comment:

dummy_threading.get_ident() works for me:

    >>> import dummy_threading as dt
    >>> dt.get_ident()
    -1
    >>> import threading
    >>> threading.get_ident()
    140498493105920

Here is a patch to compare threading and dummy_threading modules.

----------
keywords: +patch
nosy: +berker.peksag
stage: test needed -> patch review
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4
Added file: http://bugs.python.org/file41670/issue18858.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 08:16:43 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Wed, 20 Jan 2016 13:16:43 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1453295803.4.0.5126054749.issue8604@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

For reference, we added our own atomic_writing() context manager in Jupyter/IPython, after someone lost work when save failed on a full disk. We initially went for the same approach - write to a temporary file, fsync, rename over the original file - but it caused issues with network filesystems and folders synced by Dropbox or similar services.

As a result we switched to an approach that copies the old file to a temporary name, writes the new data directly to the old name, then removes the temporary copy on success, or renames it back to the old name on failure. This is certainly less rigorous, but it means that we're not replacing the file on every save, and it's less of a problem if copying file attributes with copystat() fails.

I'm sure there are use cases for atomic writing where these problems won't come up, but I hope this is a useful data point, at least for documenting any atomic writing solution.

----------
nosy: +takluyver

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 08:57:16 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Jan 2016 13:57:16 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1453298236.46.0.932766852031.issue25702@psf.upfronthosting.co.za>


R. David Murray added the comment:

My understanding is that we (starting with Guido) have made a blanket exception for 2.7 for useful performance and build-system-only related patches.  That doesn't mean *anything* can go in (the usual rules about "is this worth it/backward compatible/won't break things" still apply) but it is a lower bar than is true for other maintenance only releases.  Perhaps my understanding is in error, though.  

I believe Intel is committed to supporting this, so if there do turn out to be any maintenance issues they can handle them.  (Which IIUC is Nick's argument: if someone wants to support 2.7 with stuff we are willing to let in, we should let them as long as they credibly commit to supporting it.)  I'm currently part of that Intel support, though, so someone else should rule on this.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 09:15:04 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 14:15:04 +0000
Subject: [issue25843] lambdas on the same line may incorrectly share code
 objects
In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za>
Message-ID: <1453299304.84.0.626182935135.issue25843@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Let me try to explain this issue again.

"f1, f2 = lambda: 1, lambda: 1.0" is compiled to two MAKE_FUNCTION instructions, MAKE_FUNCTION takes a code object as parameter (and a name). The Python compiler merges constants which are seen as "equal", with exceptions to not merge values of different types, or float of different sign.

Merging duplicate code objects is a cool micro optimization, I prefer to keep it. My patch keeps this micro optimization, but fix the bug: it ensures that equal constants having different types are not seen as equal. For example, 0 is equal to 0.0, but if when used for code constants, the code objects are seen a different.

Patch version 3:

* as suggested by Armin Rigo & Serhiy Storchaka: use id(obj) in the constant key for unknown constant types -- in practice, this patch is never taken, it's just to be extra safe (I checked manually by running the whole test suite when an assertion, assertion not in the posted patch)
* add a lot of unit tests
* add a documentation to _PyCode_ConstantKey()

@Serhiy: does it look good to you now?

> Would option (1) work if wrap 1 and 1.0 in a tuple? In a list? In a custom collection?

My patch now uses id(obj) in the "constant key" for unknown types. The compiler only emits simple type (int, str, ...), tuple, frozenset and code objects.

You *can* other types if you patch manually constants with custom objects, since code_richcomp() now uses the "constant key" function to compare constants. For example, my fat project has a replace_consts() function to inject builtin functions in constants:
http://fatoptimizer.readthedocs.org/en/latest/fat.html#replace_consts

There is also @asconstants decorator of codetransformer which allow to inject arbitrary types in function constants:
https://pypi.python.org/pypi/codetransformer

----------
Added file: http://bugs.python.org/file41671/code_richcompare-3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 09:16:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 14:16:14 +0000
Subject: [issue25843] code_richcompare() don't use constant type when
 comparing code constants
In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za>
Message-ID: <1453299374.48.0.293538217911.issue25843@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
title: lambdas on the same line may incorrectly share code objects -> code_richcompare() don't use constant type when comparing code constants

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 09:22:34 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 14:22:34 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1453299754.67.0.156198377053.issue8604@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It looks like each platform and each filesystem behave differently, with subtle differencies with different kernel versions. I'm not more sure that the Python stdlib is the best place to host an implementation of an "atomic write" API.

I now suggest to create a project on PyPI, play with it, try to handle as much platforms as possible, etc. Then when it is considered as stable and robust enough, propose to integrate it to the Python stdlib.

Python stdlib is not the best place for best effort algorithm, we prefer to only add reliable and portable code. And leave "other code" outside the stdlib.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 10:39:45 2016
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 20 Jan 2016 15:39:45 +0000
Subject: [issue25934] ICC compiler: ICC treats denormal floating point numbers
 as 0.0
In-Reply-To: <1450911743.93.0.393041043786.issue25934@psf.upfronthosting.co.za>
Message-ID: <1453304385.53.0.760308273777.issue25934@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Ah, it's been a while since I tested that, so my reporting was inaccurate.  The problem is actually that the compile fails:

..\Modules\mathmodule.c(1924): error C2099: initializer is not a constant [C:\cpython\PCbuild\pythoncore.vcxproj]
..\Modules\mathmodule.c(1925): error C2099: initializer is not a constant [C:\cpython\PCbuild\pythoncore.vcxproj]

..\Python\dtoa.c(1215): error C2099: initializer is not a constant [C:\cpython\PCbuild\pythoncore.vcxproj]

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 10:52:03 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 20 Jan 2016 15:52:03 +0000
Subject: [issue25934] ICC compiler: ICC treats denormal floating point numbers
 as 0.0
In-Reply-To: <1450911743.93.0.393041043786.issue25934@psf.upfronthosting.co.za>
Message-ID: <1453305123.89.0.281489968852.issue25934@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Thanks. The offending lines in the math module are:

static const double degToRad = Py_MATH_PI / 180.0;
static const double radToDeg = 180.0 / Py_MATH_PI;

It would be trivial to replace these with suitable constants.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 10:54:49 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 20 Jan 2016 15:54:49 +0000
Subject: [issue25934] ICC compiler: ICC treats denormal floating point numbers
 as 0.0
In-Reply-To: <1450911743.93.0.393041043786.issue25934@psf.upfronthosting.co.za>
Message-ID: <1453305289.01.0.764597736363.issue25934@psf.upfronthosting.co.za>


Steve Dower added the comment:

I'm -0 on changing the universal default (and want to call out that it's a relevant porting note for 3.6, not appropriate for 3.5), but we can presumably fix those in case someone wants to use strict for their own build.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 10:59:36 2016
From: report at bugs.python.org (=?utf-8?q?Samuel_BOV=C3=89E?=)
Date: Wed, 20 Jan 2016 15:59:36 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
 mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1453305576.93.0.333228690792.issue4806@psf.upfronthosting.co.za>


Samuel BOV?E added the comment:

Up for this bug. I got this bug in my code and loose one hour to understand what happened. Please review Martin's patch !

----------
nosy: +Samuel BOV?E

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 11:07:03 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 20 Jan 2016 16:07:03 +0000
Subject: [issue25934] ICC compiler: ICC treats denormal floating point numbers
 as 0.0
In-Reply-To: <1450911743.93.0.393041043786.issue25934@psf.upfronthosting.co.za>
Message-ID: <1453306023.62.0.0109319201868.issue25934@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

The dtoa.c occurrence is also straightforward to fix. It's coming from this declaration:

    static const double tinytens[] = { 1e-16, 1e-32, 1e-64, 1e-128,
                      9007199254740992.*9007199254740992.e-256};

We need to be a tiny bit careful here, since dtoa.c is fragile code and relies on exact representation of some floats. But this isn't one of them: the only thing that tinytens is used for is getting a first approximation to the correct strtod conversion before the main iteration kicks in.

So replacing that last tinytens value with a suitably precise constant should be okay. The *exact* value of the constant we need is 0x1.8062864ac6f43p-745, or in decimal: 

8.11296384146066798564414657510725945755617084762542409283393077939218873123696010224953185884350111344494845510586594487062499326481633636403965073720792027659736980514301906428513324403012698167973428740345918815412673646248939187125560378562250718330485204443480974365425682653185460026731686712157238961539250106472701178830382576220700577401565213825995547382545061286464557591871221948351734365233811730381171156150018612038234137396963100802781483162471536048255738998621259419238986828005847002315384502722411971989039148624688058131226853220141492784023284912109375E-225

But 8.112963841460668e-225 should be good enough (along with a comment explaining why the expression was changed). If MSVC supported C99's hex constants, we could just use 0x1.8062864ac6f43p-745. But it doesn't. :-(

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 11:23:36 2016
From: report at bugs.python.org (koobs)
Date: Wed, 20 Jan 2016 16:23:36 +0000
Subject: [issue24520] Stop using deprecated floating-point environment
 functions on FreeBSD
In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za>
Message-ID: <1453307016.04.0.553294790308.issue24520@psf.upfronthosting.co.za>


koobs added the comment:

This issue is becoming increasingly important as FreeBSD 11.0-RELEASE time nears.

What remains to be done/identified/answers here to make progress?

----------
versions: +Python 2.7, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 11:26:50 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 20 Jan 2016 16:26:50 +0000
Subject: [issue8519] doc: termios and ioctl reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1453307210.0.0.0168352447862.issue8519@psf.upfronthosting.co.za>


Changes by Guido van Rossum :


----------
nosy:  -Guido.van.Rossum

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 11:28:00 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 16:28:00 +0000
Subject: [issue24520] Stop using deprecated floating-point environment
 functions on FreeBSD
In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za>
Message-ID: <1453307280.18.0.235751378179.issue24520@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Andrew Turner: "Can this be applied?"

koobs: "What remains to be done/identified/answers here to make progress?"

*I* don't understand if replacing fpsetmask() with fedisableexcept() is enough, or if we also need to starting putting "#pragma STDC FENV_ACCESS ON" in all .c file using a C double? It's not a rhetorical question, I don't understand the consequence of the attached patch.

If two FreeBSD developers (Andrew Turner and koobs) are confident, maybe I should trust them and apply blindly the patch without trying to understand it :-D

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 11:30:30 2016
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Jan 2016 16:30:30 +0000
Subject: [issue24520] Stop using deprecated floating-point environment
 functions on FreeBSD
In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za>
Message-ID: <1453307430.74.0.908537131596.issue24520@psf.upfronthosting.co.za>


Stefan Krah added the comment:

1) Feedback whether the compiler used on FreeBSD recognizes FENV_ACCESS.

2) If not, an indication why the man page mentions it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 11:57:43 2016
From: report at bugs.python.org (=?utf-8?q?Gedai_Tam=C3=A1s_Bence?=)
Date: Wed, 20 Jan 2016 16:57:43 +0000
Subject: [issue25687] Error during test case and tearDown
In-Reply-To: <1448092467.41.0.746674123801.issue25687@psf.upfronthosting.co.za>
Message-ID: <1453309063.36.0.908850299959.issue25687@psf.upfronthosting.co.za>


Gedai Tam?s Bence added the comment:

I think it's in the docs, although if you don't find it sufficient I might try to update it.

`tearDown method `_
"This is called even if the test method raised an exception [...] Any exception, other than AssertionError or SkipTest, raised by this method will be considered an error rather than a test failure. This method will only be called if the setUp() succeeds, regardless of the outcome of the test method."

----------
nosy: +beng94

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 12:03:03 2016
From: report at bugs.python.org (Andrew Turner)
Date: Wed, 20 Jan 2016 17:03:03 +0000
Subject: [issue24520] Stop using deprecated floating-point environment
 functions on FreeBSD
In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za>
Message-ID: <1453309383.45.0.729655209325.issue24520@psf.upfronthosting.co.za>


Andrew Turner added the comment:

I think this patch is correct.

Clang, as shipped by FreeBSD, doesn't support FENV_ACCESS. It raises the following warning:

fenv_test.c:2:14: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas]
#pragma STDC FENV_ACCESS ON
             ^
1 warning generated.

I expect the man page mentions it because it is mentioned in the standard. In the bugs section it does say the pragma is unimplemented.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 12:10:25 2016
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Jan 2016 17:10:25 +0000
Subject: [issue24520] Stop using deprecated floating-point environment
 functions on FreeBSD
In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za>
Message-ID: <1453309825.19.0.336900680901.issue24520@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Thanks, then the patch looks good to me.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 12:36:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 17:36:12 +0000
Subject: [issue26165] devguide: table summarizing status of Python branches
Message-ID: <1453311372.86.0.442915333055.issue26165@psf.upfronthosting.co.za>


New submission from STINNER Victor:

A frequent question is to get the status of a Python branch: is it still maintained? when does the support stop?

Attached patch adds a short table giving the current status of Python branches between 2.6 and 3.6 (default).

I sorted branches by their status, nor by their value, to show immediatly that 2.7 is still at the top :-)

For the future end-of-life, I took the year of the last binary release and I added 5 years. Is that right?

----------
components: Devguide
files: branch_status.patch
keywords: patch
messages: 258696
nosy: ezio.melotti, haypo, willingc
priority: normal
severity: normal
status: open
title: devguide: table summarizing status of Python branches
Added file: http://bugs.python.org/file41672/branch_status.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 12:36:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 17:36:23 +0000
Subject: [issue26165] devguide: table summarizing status of Python branches
In-Reply-To: <1453311372.86.0.442915333055.issue26165@psf.upfronthosting.co.za>
Message-ID: <1453311383.0.0.885316271066.issue26165@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +koobs, larry

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 12:38:52 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 20 Jan 2016 17:38:52 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1453311532.15.0.959592315999.issue25702@psf.upfronthosting.co.za>


Brett Cannon added the comment:

To help answer MAL's question about Windows: I know the python.org installers are **not** built with PGO, but I don't know about LTO.

----------
nosy: +steve.dower

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 12:40:17 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 20 Jan 2016 17:40:17 +0000
Subject: [issue18858] dummy_threading lacks threading.get_ident() equivalent
In-Reply-To: <1377638843.21.0.0472654933915.issue18858@psf.upfronthosting.co.za>
Message-ID: <1453311617.83.0.980512796971.issue18858@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
assignee:  -> berker.peksag
stage: patch review -> commit review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 12:41:54 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 17:41:54 +0000
Subject: [issue26165] devguide: table summarizing status of Python branches
In-Reply-To: <1453311372.86.0.442915333055.issue26165@psf.upfronthosting.co.za>
Message-ID: <1453311714.58.0.63487938617.issue26165@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The table is inspired by http://docs.openstack.org/releases/ which only gives the status, not the past or scheduled end-of-life date.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 12:41:57 2016
From: report at bugs.python.org (koobs)
Date: Wed, 20 Jan 2016 17:41:57 +0000
Subject: [issue26165] devguide: table summarizing status of Python branches
In-Reply-To: <1453311372.86.0.442915333055.issue26165@psf.upfronthosting.co.za>
Message-ID: <1453311717.29.0.0332737320358.issue26165@psf.upfronthosting.co.za>


koobs added the comment:

OH THANK YOU!

If possible, add Months or Quarter (Q1-4) for the EoL's, if those are defined, would be great.

We @ FreeBSD/Python would like to proactively (as early as possible) set DEPRECATED dates in our ports to ensure our users have ample time to upgrade to later versions, ideally in cadence with Python.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 12:49:43 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 20 Jan 2016 17:49:43 +0000
Subject: [issue26166] zlib compressor/decompressor objects should support copy
 protocol
Message-ID: <1453312183.38.0.668863762812.issue26166@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

zlib.compressobj and zlib.decompressobj objects (actually zlib.Compress and zlib.Decompress, the other names are the function constructors I guess?) have a .copy() method, but don't implement `__copy__` or `__deepcopy__`. This leads to the mildly silly result that a copyable object can't be copied using the common copy protocol.

I see two solutions:

1. Implement `__copy__` and `__deepcopy__` directly for the zlib objects
2. Have the copy module include them in _copy_dispatch mapped to the existing _copy_with_copy_method (and use a similar approach for _deepcopy_dispatch, since AFAICT this isn't a case where deep copying differs from shallow copying)

The former makes for more C code in CPython, and would require matching updates in the zlib used by all alternate CPython interpreters, but is probably faster and introduces no new cross-module dependencies.

The latter would make zlib an import dependency of copy (or vice versa, if zlib messed with copy's internals on import), but involves only a trivial amount of new Python code and wouldn't require any changes by alternate Python implementations that used the core copy module (when they update to the new copy, they get the support for free).

----------
components: Extension Modules, Library (Lib)
messages: 258700
nosy: josh.r
priority: normal
severity: normal
status: open
title: zlib compressor/decompressor objects should support copy protocol
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 12:49:53 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 20 Jan 2016 17:49:53 +0000
Subject: [issue26166] zlib compressor/decompressor objects should support copy
 protocol
In-Reply-To: <1453312183.38.0.668863762812.issue26166@psf.upfronthosting.co.za>
Message-ID: <1453312193.45.0.779990409168.issue26166@psf.upfronthosting.co.za>


Changes by Josh Rosenberg :


----------
type:  -> enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 12:53:02 2016
From: report at bugs.python.org (Tim Peters)
Date: Wed, 20 Jan 2016 17:53:02 +0000
Subject: [issue26150] SequenceMatcher's algorithm is not correct
In-Reply-To: <1453201598.83.0.994407990741.issue26150@psf.upfronthosting.co.za>
Message-ID: <1453312382.88.0.506140960382.issue26150@psf.upfronthosting.co.za>


Tim Peters added the comment:

Please read the responses to this older report:

http://bugs.python.org/issue25391

As they say, it's functioning as designed and documented, so this isn't "a bug".  For that reason I'm closing this as "not a bug".

As they also say, there are many other possible algorithms (LCS isn't the only other one in use).  Opening an enhancement request instead (to implement additional algorithms) could make sense, but won't get anywhere unless someone volunteers to do the work.

----------
nosy: +tim.peters
resolution:  -> not a bug
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 12:56:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Jan 2016 17:56:01 +0000
Subject: [issue26166] zlib compressor/decompressor objects should support copy
 protocol
In-Reply-To: <1453312183.38.0.668863762812.issue26166@psf.upfronthosting.co.za>
Message-ID: <1453312561.0.0.646710943364.issue26166@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue25007.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Add support of copy protocol to zlib compressors and decompressors

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 13:02:23 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 20 Jan 2016 18:02:23 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1453312943.86.0.270219678198.issue25702@psf.upfronthosting.co.za>


Steve Dower added the comment:

MSVC has had Link-Time Code Generation for many releases, and it should have been used for all 2.7 releases (definitely used in 3.5+) to optimize references between object files. I assume this is equivalent to LTO.

We currently don't use PGO in the official Windows builds, but it is a supported build configuration.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 13:07:38 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 20 Jan 2016 18:07:38 +0000
Subject: [issue26167] Improve copy.copy speed for built-in types
Message-ID: <1453313258.69.0.822432262864.issue26167@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

copy.copy uses a relatively high overhead approach to copying list, set and dict, using:

    def _copy_with_constructor(x):
        return type(x)(x)

This is despite the fact that all three types implement a .copy() method, and there is already a defined method:

    def _copy_with_copy_method(x):
        return x.copy()

that (in %timeit tests) runs with substantially less overhead, in percentage terms; for empty lists, sets and dicts, calling _copy_with_constructor or _copy_with_copy_method directly on them, the times on my machine (Python 3.5.0, Linux x86-64) are:

empty list: 281 ns (constructor), 137 ns (method)
empty set: 275 ns (constructor), 175 ns (method)
empty dict: 372 ns (constructor), 211 ns (method)

The method costs could be trimmed further if _copy_with_copy_method was changed from a Python implementation to using operator.methodcaller, e.g.

    try:
        # If we have _operator, avoids cost of importing Python code; it's part of core modules in CPython, already loaded for free
        from _operator import methodcaller  
    except ImportError:
        from operator import methodcaller

    _copy_with_copy_method = methodcaller('copy')

This doesn't save a whole lot more (shaves another 9-17 ns off the times for the Python version of _copy_with_copy_method), but it's nice in that it avoids reinventing the wheel in the copy module. Combining the two changes (to use methodcaller for _copy_with_copy_method and to have list, set and dict use _copy_with_copy_method) means we can get rid of both Python defined functions in favor of a single use of operator.methodcaller used by all types that previously used either of them.

Obviously not a high priority fix, but I noticed this while trying to figure out a way to fix zlib's lack of support in the copy module ( #26166 which apparently duplicates #25007 ) and how to work around it.

----------
components: Library (Lib)
messages: 258704
nosy: josh.r
priority: normal
severity: normal
status: open
title: Improve copy.copy speed for built-in types
type: performance
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 13:08:19 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 20 Jan 2016 18:08:19 +0000
Subject: [issue26166] zlib compressor/decompressor objects should support copy
 protocol
In-Reply-To: <1453312183.38.0.668863762812.issue26166@psf.upfronthosting.co.za>
Message-ID: <1453313299.18.0.00403085435724.issue26166@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Oops. Sorry. I swear I searched, but I can't figure out how I missed the obvious duplicate there.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 13:12:56 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 20 Jan 2016 18:12:56 +0000
Subject: [issue25007] Add support of copy protocol to zlib compressors and
 decompressors
In-Reply-To: <1441449753.43.0.0389421030599.issue25007@psf.upfronthosting.co.za>
Message-ID: <1453313576.05.0.930183367959.issue25007@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Patch looks good, but incomplete. Supporting __deepcopy__ (as a simple wrapper around __copy__ that ignores the second argument) would provide complete support.

Also, should there be tests? I mean, I assume the .copy() method itself is tested, but just to detect stupid regressions, seems like testing __copy__/__deepcopy__ for identical behavior would be a good thing.

----------
nosy: +josh.r

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 13:13:47 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 20 Jan 2016 18:13:47 +0000
Subject: [issue26167] Improve copy.copy speed for built-in types
 (list/set/dict)
In-Reply-To: <1453313258.69.0.822432262864.issue26167@psf.upfronthosting.co.za>
Message-ID: <1453313627.67.0.00847820487338.issue26167@psf.upfronthosting.co.za>


Changes by Josh Rosenberg :


----------
title: Improve copy.copy speed for built-in types -> Improve copy.copy speed for built-in types (list/set/dict)

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 13:19:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Jan 2016 18:19:47 +0000
Subject: [issue25843] code_richcompare() don't use constant type when
 comparing code constants
In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za>
Message-ID: <1453313987.04.0.973846525046.issue25843@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It looks to me that the patch makes set and frozenset constants to be equal, but makes sets with different order (as {2**62, 1} and {1, 2**62}) differ. And looks you had missed my comments to previous patches.

----------
stage:  -> patch review
versions:  -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 13:26:25 2016
From: report at bugs.python.org (squidevil)
Date: Wed, 20 Jan 2016 18:26:25 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
Message-ID: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>


New submission from squidevil:

Expected behavior:
  Calling Py_BuildValue with a 'N' argument should take ownership of the N object, and on failure (returns NULL), call Py_DECREF() on any N argument.  The documentation explicitly says that this is the intended usage:
    "N": Same as "O", except it doesn't increment the reference count on the object. Useful when the object is created by a call to an object constructor in the argument list.

Actual behavior:
  N objects appear to be abandoned/leaked in some cases.

Example: PyBuildValue("iN", 0, obj);

* calls _Py_BuildValue_SizeT via macro
* calls va_build_value (in modsupport.c)
* calls do_mktuple [0]
* [0] first calls v = PyTuple_New(n=2). If this fails, it returns NULL, leaking obj.
* if [0] creates the tuple v, then it goes on to populate the values in the tuple.
* [0] calls do_mkvalue() to create the "i=0" object.  If this fails, obj is never Py_DECREF()'ed.

Many other leaks are possible, as long as at least one allocation occurs prior to the processing of the N arguments.

----------
components: Interpreter Core
messages: 258708
nosy: squidevil
priority: normal
severity: normal
status: open
title: Py_BuildValue may leak 'N' arguments on PyTuple_New failure
type: resource usage
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 13:26:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Jan 2016 18:26:26 +0000
Subject: [issue25007] Add support of copy protocol to zlib compressors and
 decompressors
In-Reply-To: <1441449753.43.0.0389421030599.issue25007@psf.upfronthosting.co.za>
Message-ID: <1453314386.99.0.315223124808.issue25007@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I agree with Josh. Needed __deepcopy__ and tests. And I think there may be problem with sharing a docstring (that includes a signature) between copy() and __copy__(). It is better to just add separate method that calls the implementation of copy().

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 13:27:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Jan 2016 18:27:52 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
In-Reply-To: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>
Message-ID: <1453314472.77.0.986422419854.issue26168@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
nosy: +serhiy.storchaka
stage:  -> needs patch
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 14:33:40 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 20 Jan 2016 19:33:40 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
In-Reply-To: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>
Message-ID: <1453318420.99.0.830699773669.issue26168@psf.upfronthosting.co.za>


Changes by Josh Rosenberg :


----------
nosy: +josh.r

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 14:57:43 2016
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 20 Jan 2016 19:57:43 +0000
Subject: [issue26162] thread error
In-Reply-To: <1453289324.96.0.367077041612.issue26162@psf.upfronthosting.co.za>
Message-ID: <1453319863.57.0.567962442157.issue26162@psf.upfronthosting.co.za>


Eryk Sun added the comment:

It's no surprise to see a memory error at 845 threads if you're using 32-bit Python, which is limited to 2 GiB of address space. python.exe is built with a default stack reservation of 2000000 bytes, so 845 threads reserve a total of about 1.58 GiB. Consider also that address space is used by mapped DLLs and files, page tables, private data, the process heap(s), and additional worker threads. Plus if it's 64-bit Windows there's a 64-bit stack for each 32-bit thread. The 64-bit stack reserves 256 KiB, which totals an additional 0.2 GiB for 845 threads. Available space is also lost to fragmentation that leaves unusable blocks.

Why do you need so many threads instead of using a thread pool? If you *really* need that many threads and can't switch to 64-bit Python, you'll have to step outside what Python's built-in threading support offers. The following demonstrates calling Windows CreateThread via ctypes. I recommend against doing something like this.

    import ctypes
    from ctypes import wintypes

    kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)

    CREATE_SUSPENDED = 0x00000004
    STACK_SIZE_PARAM_IS_A_RESERVATION = 0x00010000

    def check_handle(result, func, args):
        if result is None:
            raise ctypes.WinError(ctypes.get_last_error())
        return args

    def check_bool(result, func, args):
        if not result:
            raise ctypes.WinError(ctypes.get_last_error())
        return None

    wintypes.LPDWORD = ctypes.POINTER(wintypes.DWORD)
    wintypes.SIZE_T = ctypes.c_size_t
    LPSECURITY_ATTRIBUTES = ctypes.c_void_p
    LPTHREAD_START_ROUTINE = ctypes.WINFUNCTYPE(wintypes.DWORD,
                                                wintypes.LPVOID)

    kernel32.CreateThread.errcheck = check_handle
    kernel32.CreateThread.restype = wintypes.HANDLE
    kernel32.CreateThread.argtypes = (
        LPSECURITY_ATTRIBUTES,  # _In_opt_  lpThreadAttributes
        wintypes.SIZE_T,        # _In_      dwStackSize
        LPTHREAD_START_ROUTINE, # _In_      lpStartAddress
        wintypes.LPVOID,        # _In_opt_  lpParameter
        wintypes.DWORD,         # _In_      dwCreationFlags
        wintypes.LPDWORD,       # _Out_opt_ lpThreadId
    )

    kernel32.CloseHandle.errcheck = check_bool
    kernel32.CloseHandle.argtypes = (wintypes.HANDLE,)

    def CreateThread(lpStartAddress,
                     lpParameter=None,
                     dwStackSize=0,
                     dwCreationFlags=STACK_SIZE_PARAM_IS_A_RESERVATION,
                     lpThreadAttributes=None,
                     close_handle=True):
        tid = (wintypes.DWORD * 1)()
        h = kernel32.CreateThread(lpThreadAttributes,
                                  dwStackSize,
                                  lpStartAddress,
                                  lpParameter,
                                  dwCreationFlags,
                                  tid)
        if close_handle:
            kernel32.CloseHandle(h)
            return tid[0]
        return h, tid[0]

For example, the following creates 2000 worker threads that each reserves 256 KiB for the stack. Since I'm running 32-bit Python on 64-bit Windows, each thread has a corresponding 64-bit thread stack that also reserves 256 KiB. In total it reserves 1 GiB of stack space, which I confirmed using Sysinternals VMMap.

    import time

    @LPTHREAD_START_ROUTINE
    def worker(param):
        if param is None:
            param = 0
        # do some work
        time.sleep(60)
        return 0

    tids = []
    for i in range(2000):
        tid = CreateThread(worker, i, 256*1024)
        tids.append(tid)

----------
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 15:05:58 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Jan 2016 20:05:58 +0000
Subject: [issue26152] A non-breaking space in a source
In-Reply-To: <1453204897.88.0.969876573405.issue26152@psf.upfronthosting.co.za>
Message-ID: <1453320358.66.0.738999348693.issue26152@psf.upfronthosting.co.za>


Martin Panter added the comment:

The caret always points to the end of the token, I think.

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 15:21:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Jan 2016 20:21:39 +0000
Subject: [issue26167] Improve copy.copy speed for built-in types
 (list/set/dict)
In-Reply-To: <1453313258.69.0.822432262864.issue26167@psf.upfronthosting.co.za>
Message-ID: <1453321299.24.0.235927361133.issue26167@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

methodcaller is not needed. We can use just list.copy etc.

Proposed patch speeds up copying list, dict, set, bytearray, slice, NotImplemented. It makes deepcopying list, tuple, dict a little faster.  It makes the code for copying and deepcopying using reduce protocol cleaner and a little faster. It cleans up the module and adds new tests for builtin types.

----------
assignee:  -> serhiy.storchaka
nosy: +alexandre.vassalotti, serhiy.storchaka
stage:  -> patch review
versions:  -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 15:31:52 2016
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Wed, 20 Jan 2016 20:31:52 +0000
Subject: [issue26152] A non-breaking space in a source
In-Reply-To: <1453204897.88.0.969876573405.issue26152@psf.upfronthosting.co.za>
Message-ID: <1453321912.36.0.902903571481.issue26152@psf.upfronthosting.co.za>


Adam Barto? added the comment:

We have one particular invalid token, so why it should point to the next token rather than to the invalid one?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 15:40:13 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Jan 2016 20:40:13 +0000
Subject: [issue26152] A non-breaking space in a source
In-Reply-To: <1453204897.88.0.969876573405.issue26152@psf.upfronthosting.co.za>
Message-ID: <1453322413.31.0.10783653038.issue26152@psf.upfronthosting.co.za>


Martin Panter added the comment:

Assuming Andrew is correct, it sounds like the tokenizer is treating the NBSP and the ?2? as part of the same token, because NBSP is non-ASCII.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 15:48:07 2016
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Wed, 20 Jan 2016 20:48:07 +0000
Subject: [issue26152] A non-breaking space in a source
In-Reply-To: <1453204897.88.0.969876573405.issue26152@psf.upfronthosting.co.za>
Message-ID: <1453322887.57.0.804314405345.issue26152@psf.upfronthosting.co.za>


Adam Barto? added the comment:

It could still point to the first or the last byte of the invalid token rather than to the start of the next token. Also, by the Python implementation of the tokenizer in tokenize module we get an ERRORTOKEN containing a non-breaking space followed by a number token containing 2.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 16:11:21 2016
From: report at bugs.python.org (Stefan Seefeld)
Date: Wed, 20 Jan 2016 21:11:21 +0000
Subject: [issue25520] unittest load_tests protocol not working as documented
In-Reply-To: <1446239702.03.0.964231995407.issue25520@psf.upfronthosting.co.za>
Message-ID: <1453324281.08.0.356694643146.issue25520@psf.upfronthosting.co.za>


Stefan Seefeld added the comment:

Hi, I'm investigating more issues related to test loading, and thus I have discovered issue #16662.

I have found quite a number of inconsistencies and bugs in the loading of tests. But without getting a sense of what the supposed behavior is I find it difficult to come up with workarounds and fixes.

Is there a place where these issues can be discussed (rather than just looking at each bug individually) ?

I'd ultimately like to be able to invoke

  `python -m unittest my.test.subpackage` 

and have unittest pick up all the tests within that recursively, with and without load_tests() functions.

(On a tangential note, I would also like to have a mode where the found tests are listed without being executed. I have hacked a pseudo-TestRunner that does that, but I'm not sure this is the best approach.)

Is there any place where the bigger picture can be discussed ?

Thanks,

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 16:14:07 2016
From: report at bugs.python.org (Soufiane BOUSSALI)
Date: Wed, 20 Jan 2016 21:14:07 +0000
Subject: [issue26169] Buffer OverFlow
Message-ID: <1453324447.34.0.636986980752.issue26169@psf.upfronthosting.co.za>


Changes by Soufiane BOUSSALI :


----------
components: IDLE
files: poc.py
nosy: Soufiane BOUSSALI
priority: normal
severity: normal
status: open
title: Buffer OverFlow
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file41673/poc.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 16:14:42 2016
From: report at bugs.python.org (Soufiane BOUSSALI)
Date: Wed, 20 Jan 2016 21:14:42 +0000
Subject: [issue26169] Buffer OverFlow
Message-ID: <1453324482.02.0.436617793001.issue26169@psf.upfronthosting.co.za>


Changes by Soufiane BOUSSALI :


Added file: http://bugs.python.org/file41674/py2.7.11.png

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 16:16:51 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Jan 2016 21:16:51 +0000
Subject: [issue26165] devguide: table summarizing status of Python branches
In-Reply-To: <1453311372.86.0.442915333055.issue26165@psf.upfronthosting.co.za>
Message-ID: <20160120211641.94222.77041@psf.io>


Roundup Robot added the comment:

New changeset 75b95ada261f by Victor Stinner in branch 'default':
Add a table "Status of Python branches" to the front page
https://hg.python.org/devguide/rev/75b95ada261f

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 16:17:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 21:17:14 +0000
Subject: [issue26165] devguide: table summarizing status of Python branches
In-Reply-To: <1453311372.86.0.442915333055.issue26165@psf.upfronthosting.co.za>
Message-ID: <1453324634.09.0.418554170711.issue26165@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I pushed a first version of the table. It can be adjusted later if needed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 16:24:02 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 21:24:02 +0000
Subject: [issue26165] devguide: table summarizing status of Python branches
In-Reply-To: <1453311372.86.0.442915333055.issue26165@psf.upfronthosting.co.za>
Message-ID: <1453325042.43.0.0791424934297.issue26165@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> If possible, add Months or Quarter (Q1-4) for the EoL's, if those are defined, would be great.

I added the estimated *day* of the end-of-line. But the release manager is free to adjust it.

> We @ FreeBSD/Python would like to proactively (as early as possible) set DEPRECATED dates in our ports to ensure our users have ample time to upgrade to later versions, ideally in cadence with Python.

You may start to deprecate as soon as a branch switches to security only fixes?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 16:27:58 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 20 Jan 2016 21:27:58 +0000
Subject: [issue26169] Buffer OverFlow in IDLE
Message-ID: <1453325278.66.0.602449947152.issue26169@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +kbk, roger.serwy, terry.reedy
title: Buffer OverFlow -> Buffer OverFlow in IDLE

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 16:31:32 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Jan 2016 21:31:32 +0000
Subject: [issue24520] Stop using deprecated floating-point environment
 functions on FreeBSD
In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za>
Message-ID: <20160120213129.14179.66560@psf.io>


Roundup Robot added the comment:

New changeset 76f35f35be50 by Victor Stinner in branch '3.5':
Replace fpgetmask() with fedisableexcept()
https://hg.python.org/cpython/rev/76f35f35be50

New changeset 6134d9ecab60 by Victor Stinner in branch 'default':
Merge 3.5 (issue #24520)
https://hg.python.org/cpython/rev/6134d9ecab60

New changeset 394ae9efc5c2 by Victor Stinner in branch '2.7':
Replace fpgetmask() with fedisableexcept()
https://hg.python.org/cpython/rev/394ae9efc5c2

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 16:33:55 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 21:33:55 +0000
Subject: [issue24520] Stop using deprecated floating-point environment
 functions on FreeBSD
In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za>
Message-ID: <1453325635.78.0.856415582212.issue24520@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"I expect the man page mentions it because it is mentioned in the standard. In the bugs section it does say the pragma is unimplemented."

Ah ah, funnny. Sorry, I was confused by the manual page.

I pushed your patch to Python 2.7, 3.5 and default (3.6) branches.

@koobs: sorry, 3.4 now only accept security fixes :-p

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 17:01:44 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Wed, 20 Jan 2016 22:01:44 +0000
Subject: [issue26152] A non-breaking space in a source
In-Reply-To: <1453204897.88.0.969876573405.issue26152@psf.upfronthosting.co.za>
Message-ID: <1453327304.2.0.254969918971.issue26152@psf.upfronthosting.co.za>


Andrew Barnert added the comment:

> Assuming Andrew is correct, it sounds like the tokenizer is treating the NBSP and the ?2? as part of the same token, because NBSP is non-ASCII.

It's more complicated than that. When you get an invalid character, it splits the token up. So, in this case, you get a separate `ERRORTOKEN` from cols 2-3 and `NUMBER` token from cols 3-4. Even in the case of `1, a\xa0\xa02`, you get a `NAME` token for the `a`, a separate `ERRORTOKEN` for each nbsp, and a `NUMBER` token for the `2`.

But I think the code that generates the `SyntaxError` must be trying to re-generate the "intended token" from the broken one. For example:

    >>> eval('1\xa0\xa02a')
    File "", line 1
      1??2a
     ?  ? ^
    SyntaxError: invalid character in identifier

And if you capture the error and look at it, `e.args[1][1:3]` is 1, 5, which matches what you see.

But if you tokenize it (e.g., `list(tokenize.tokenize(io.BytesIO('1\xa0\xa02a'.encode('utf-8')).readline))`, but you'll probably want to wrap that up in a function if you're playing with it a lot...), you get a `NUMBER` from 0-1, an `ERRORTOKEN` from 1-2, another `ERRORTOKEN` from 2-3, a `NUMBER` from 3-4, and a `NAME` from 4-5. So, why does the `SyntaxError` point at the `NAME` instead of the first `ERRORTOKEN`? Presumably there's some logic that tries to work out that the two `ERRORTOKEN`s, `NUMBER`, and `NAME` were all intended to be one big identifier and points at that instead.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 17:14:10 2016
From: report at bugs.python.org (Maciej Szulik)
Date: Wed, 20 Jan 2016 22:14:10 +0000
Subject: [issue25591] refactor imaplib tests
In-Reply-To: <1447107407.81.0.130095933409.issue25591@psf.upfronthosting.co.za>
Message-ID: <1453328050.24.0.655925011347.issue25591@psf.upfronthosting.co.za>


Maciej Szulik added the comment:

David I think I've re-implemented, using the new style, all the methods from ThreadedNetworkedTests and ThreadedNetworkedTestsSSL, the new classes are NewIMAPTests and NewIMAPSSLTests accordingly.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file41675/new_imap_tests_v3.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 17:42:17 2016
From: report at bugs.python.org (Soufiane BOUSSALI)
Date: Wed, 20 Jan 2016 22:42:17 +0000
Subject: [issue26169] Buffer OverFlow in IDLE 2.7.11
Message-ID: <1453329737.42.0.68845601121.issue26169@psf.upfronthosting.co.za>


Changes by Soufiane BOUSSALI :


----------
title: Buffer OverFlow in IDLE -> Buffer OverFlow in IDLE 2.7.11

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 18:05:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 23:05:23 +0000
Subject: [issue25843] code_richcompare() don't use constant type when
 comparing code constants
In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za>
Message-ID: <1453331123.03.0.807167586262.issue25843@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 4:

Fix _PyCode_ConstantKey:

* always return a tuple
* create a frozenset/set if input is a set/frozenset, items are unordered
* enhance unit tests: compare values using repr() to compare value + type at once
* fix reference leak

Other minor changes to take Serhiy's comments in account.

Thanks Serhiy for good suggestions!

----------
Added file: http://bugs.python.org/file41676/code_richcompare-4.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 18:05:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 23:05:43 +0000
Subject: [issue25843] code_richcompare() don't use constant type when
 comparing code constants
In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za>
Message-ID: <1453331143.14.0.76175309208.issue25843@psf.upfronthosting.co.za>


STINNER Victor added the comment:

And sorry, I missed your comments, it looks like some emails were seen as spam :-/

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 19:57:39 2016
From: report at bugs.python.org (Vinyl Darkscratch-Kazotetsu)
Date: Thu, 21 Jan 2016 00:57:39 +0000
Subject: [issue26170] pip Crash on Unpacking in get_platform() line 119
Message-ID: <1453337857.76.0.99047592718.issue26170@psf.upfronthosting.co.za>


New submission from Vinyl Darkscratch-Kazotetsu:

Since upgrading to pip 8.0, I get a crash whenever I try to run it.  It fails to unpack to major, minor, and micro for the release, saying there's only two values.

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/bin/pip", line 7, in 
    from pip import main
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/__init__.py", line 15, in 
    from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/vcs/subversion.py", line 9, in 
    from pip.index import Link
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/index.py", line 29, in 
    from pip.wheel import Wheel, wheel_ext
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/wheel.py", line 32, in 
    from pip import pep425tags
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/pep425tags.py", line 214, in 
    supported_tags = get_supported()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/pep425tags.py", line 162, in get_supported
    arch = get_platform()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/pep425tags.py", line 119, in get_platform
    major, minor, micro = release.split('.')
ValueError: need more than 2 values to unpack

----------
components: Macintosh
messages: 258726
nosy: Vinyl Darkscratch-Kazotetsu, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: pip Crash on Unpacking in get_platform() line 119
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 20:00:24 2016
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 21 Jan 2016 01:00:24 +0000
Subject: [issue26170] pip Crash on Unpacking in get_platform() line 119
In-Reply-To: <1453337857.76.0.99047592718.issue26170@psf.upfronthosting.co.za>
Message-ID: <1453338024.9.0.375558070691.issue26170@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Hey,

This is actually a bug with pip not with CPython and is being tracked by https://github.com/pypa/pip/issues/3408. It's fixed in pip's repository and we'll soon have an 8.0.1 release out to fix it.

----------
nosy: +dstufft
resolution:  -> third party
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 20:02:42 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Jan 2016 01:02:42 +0000
Subject: [issue26170] pip Crash on Unpacking in get_platform() line 119
In-Reply-To: <1453337857.76.0.99047592718.issue26170@psf.upfronthosting.co.za>
Message-ID: <1453338162.62.0.123867009725.issue26170@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
stage:  -> resolved
type: crash -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 20:24:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jan 2016 01:24:23 +0000
Subject: [issue25704] Update the devguide to 3.5
In-Reply-To: <1448282986.29.0.990424693558.issue25704@psf.upfronthosting.co.za>
Message-ID: <20160121012416.41348.78317@psf.io>


Roundup Robot added the comment:

New changeset 32545ee8d673 by Berker Peksag in branch 'default':
Issue #25704: Update Python version to 3.5 where appropriate
https://hg.python.org/devguide/rev/32545ee8d673

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 20:27:24 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Jan 2016 01:27:24 +0000
Subject: [issue25704] Update the devguide to 3.5
In-Reply-To: <1448282986.29.0.990424693558.issue25704@psf.upfronthosting.co.za>
Message-ID: <1453339644.88.0.228506622745.issue25704@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks, St?phane! Ned applied most of your patch in f53eac8da0b8. I left "sudo apt-get build-dep python3.4" as is since python3.5 is not available in the latest LTS release of Ubuntu.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 21:38:09 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 21 Jan 2016 02:38:09 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1453343889.03.0.439927728557.issue22490@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I believe this behavior (presence of the __PYVENV_LAUNCHER__ and inheritance in child processes) continues to cause problems. See https://github.com/pypa/virtualenv/issues/845 for a simple reproducing of the issue, even on pip 6+.

----------
nosy: +jason.coombs

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 22:10:38 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 21 Jan 2016 03:10:38 +0000
Subject: [issue26167] Improve copy.copy speed for built-in types
 (list/set/dict)
In-Reply-To: <1453313258.69.0.822432262864.issue26167@psf.upfronthosting.co.za>
Message-ID: <1453345838.42.0.583449601253.issue26167@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Good point. Though I don't see any attached patches...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 22:20:36 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Jan 2016 03:20:36 +0000
Subject: [issue26169] Pasting 900000 chars into a tk Entry widget fails
Message-ID: <1453346436.13.0.197116211445.issue26169@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

'\x41' == 'A'.  I don't know what 'BOF' has to do with the character 'A' or a string of them.

A python or pythonw process 'hanging' does not itself mean that there is a buffer overflow, though I can understand why you suspect it.  Python itself is pretty much immune from buffer overflows, but C code is not ;-).

IDLE crashing is not necessarily an IDLE issue.  IDLE is a application written in Python, including tkinter, which runs tcl/tk code.  It is just as vulnerable to Python, tkinter, and tcl/tk bugs and liminations as any other application.  This appears to be an issue about the limitations of the tcl/tk Entry widget.

When I followed the procedure posted with 3.5.1 on 64 bit Win 10 and pasted the megastring into the tk Entry box, the box stayed blank and a blue circle 'waiting' cursor appeared.  Even if the string was copied from the clipboard into process memory, it exceeded the (undocumented?) limits of the widget.

This behavior can be reproduced independently of IDLE with

import tkinter as tk
root = tk.Tk()
entry = tk.Entry(root)
entry.pack()
root.mainloop()

The latter has been waiting for several minutes.  This does not surprise me.

When I clicked the Search dialog Find-next button, the dialog box turned the whitish gray, all too familiar to me, that indicates that a process is no longer responsive.  This also does not surprise me.  The click causes the associated Python callback to be called.  It tries to get the Entry box text that is likely not available, compile it as a regex with re, and then search the editor text. 

Since we do not control tk Entry widgets, I am inclined to close this as '3rd party'.  Serhiy, what do you think?

PS: the test Entry box is still waiting.  Trying to close it fails and brings up a 'Python is not responding' box as in the screenshot.  I has to kill the process with Task Manager, just as with the IDLE Search window.

----------
components: +Tkinter -IDLE
nosy: +serhiy.storchaka -kbk, roger.serwy
title: Buffer OverFlow in IDLE 2.7.11 -> Pasting 900000 chars into a tk Entry widget fails
versions: +Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 22:52:33 2016
From: report at bugs.python.org (Insu Yun)
Date: Thu, 21 Jan 2016 03:52:33 +0000
Subject: [issue26171] heap overflow in zipimporter module
Message-ID: <1453348353.03.0.314168195173.issue26171@psf.upfronthosting.co.za>


New submission from Insu Yun:

in zipimport.c
  1116     bytes_size = compress == 0 ? data_size : data_size + 1;
  1117     if (bytes_size == 0)
  1118         bytes_size++;
  1119     raw_data = PyBytes_FromStringAndSize((char *)NULL, bytes_size);

If compress != 0, then bytes_size = data_size + 1
data_size is not sanitized, so if data_size = -1, then it overflows and becomes 0.
In that case bytes_size becomes 1 and python allocates small heap, but after that in fread, it overflows heap.

----------
files: crash.py
messages: 258733
nosy: Insu Yun
priority: normal
severity: normal
status: open
title: heap overflow in zipimporter module
type: security
versions: Python 3.6
Added file: http://bugs.python.org/file41677/crash.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 00:48:23 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 21 Jan 2016 05:48:23 +0000
Subject: [issue26172] iBook can't open ePub
Message-ID: <1453355303.75.0.605572221579.issue26172@psf.upfronthosting.co.za>


New submission from INADA Naoki:

Script cannot run in iBook is included in ePub.
Attached patch resolves the issue.

----------
assignee: docs at python
components: Documentation
files: epub.patch
keywords: patch
messages: 258734
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: iBook can't open ePub
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41678/epub.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 01:03:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jan 2016 06:03:41 +0000
Subject: [issue26172] iBook can't open ePub
In-Reply-To: <1453355303.75.0.605572221579.issue26172@psf.upfronthosting.co.za>
Message-ID: <20160121060334.111052.53085@psf.io>


Roundup Robot added the comment:

New changeset 562179b7912f by Benjamin Peterson in branch '3.4':
remove script from epub (closes #26172)
https://hg.python.org/cpython/rev/562179b7912f

New changeset 56e68089ad65 by Benjamin Peterson in branch '3.5':
merge 3.4 (#26172)
https://hg.python.org/cpython/rev/56e68089ad65

New changeset 68ec50003aca by Benjamin Peterson in branch 'default':
merge 3.5 (#26172)
https://hg.python.org/cpython/rev/68ec50003aca

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 01:26:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jan 2016 06:26:00 +0000
Subject: [issue26171] heap overflow in zipimporter module
In-Reply-To: <1453348353.03.0.314168195173.issue26171@psf.upfronthosting.co.za>
Message-ID: <20160121062557.14187.22602@psf.io>


Roundup Robot added the comment:

New changeset 01ddd608b85c by Benjamin Peterson in branch '3.4':
prevent buffer overflow in get_data (closes #26171)
https://hg.python.org/cpython/rev/01ddd608b85c

New changeset 985fc64c60d6 by Benjamin Peterson in branch '2.7':
prevent buffer overflow in get_data (closes #26171)
https://hg.python.org/cpython/rev/985fc64c60d6

New changeset 10dad6da1b28 by Benjamin Peterson in branch '3.5':
merge 3.4 (#26171)
https://hg.python.org/cpython/rev/10dad6da1b28

New changeset 2df462852464 by Benjamin Peterson in branch 'default':
merge 3.5 (#26171)
https://hg.python.org/cpython/rev/2df462852464

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 02:20:48 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Jan 2016 07:20:48 +0000
Subject: [issue22872] multiprocessing.Queue raises AssertionError
In-Reply-To: <1415986488.54.0.734820295311.issue22872@psf.upfronthosting.co.za>
Message-ID: <1453360848.04.0.0875526381509.issue22872@psf.upfronthosting.co.za>


Berker Peksag added the comment:

See issue 5001 for more general cleanup in multiprocessing.

> [...] (2) altering the behavior in a new release version (perhaps 3.6 when it comes) and documenting that change appropriately there.

+1. We can also document AssertionError in older Python versions.

----------
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 02:58:55 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jan 2016 07:58:55 +0000
Subject: [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <20160121075852.25900.79875@psf.io>


Roundup Robot added the comment:

New changeset a04d9589e2c4 by Victor Stinner in branch '3.5':
Issue #26106: doc: Move text of licenses to parsed literal block
https://hg.python.org/cpython/rev/a04d9589e2c4

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 03:01:36 2016
From: report at bugs.python.org (Sean Wang)
Date: Thu, 21 Jan 2016 08:01:36 +0000
Subject: [issue2931] optparse: various problems with unicode and gettext
In-Reply-To: <1211297479.44.0.970954846769.issue2931@psf.upfronthosting.co.za>
Message-ID: <1453363296.52.0.208084180874.issue2931@psf.upfronthosting.co.za>


Sean Wang added the comment:

This bug still exists in Python 2.7.10 with optparse version 1.5.3.
When the default_value is not ASCII encoded, it would raise `UnicodeEncodeError: 'ascii' codec can't encode characters`

this error is due to the `str` usage in `expand_default` method:

    def expand_default(self, option):
        if self.parser is None or not self.default_tag:
            return option.help

        default_value = self.parser.defaults.get(option.dest)
        if default_value is NO_DEFAULT or default_value is None:
            default_value = self.NO_DEFAULT_VALUE

        return option.help.replace(self.default_tag, str(default_value))

----------
nosy: +Sean.Wang

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 03:05:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jan 2016 08:05:00 +0000
Subject: [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <20160121080456.111038.3210@psf.io>


Roundup Robot added the comment:

New changeset f2a0a4a45292 by Victor Stinner in branch '2.7':
Issue #26106: doc: Move text of licenses to parsed literal block
https://hg.python.org/cpython/rev/f2a0a4a45292

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 03:05:08 2016
From: report at bugs.python.org (Sean Wang)
Date: Thu, 21 Jan 2016 08:05:08 +0000
Subject: [issue2931] optparse: various problems with unicode and gettext
In-Reply-To: <1211297479.44.0.970954846769.issue2931@psf.upfronthosting.co.za>
Message-ID: <1453363508.22.0.916236433766.issue2931@psf.upfronthosting.co.za>


Sean Wang added the comment:

Sorry, missed one condition:
I used `unicode_literals` in Python 2.7.10, example below:

>>> from __future__ import unicode_literals
>>> str('api??')
Traceback (most recent call last):
  File "", line 1, in 
UnicodeEncodeError: 'ascii' codec can't encode characters in position 3-4: ordinal not in range(128)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 03:08:58 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2016 08:08:58 +0000
Subject: [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <1453363738.04.0.388022816003.issue26106@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks for your effort of translation the doc.

FYI the doc can be read at http://www.afpy.org/doc/python/ and the project (source) is at https://github.com/AFPY/python_doc_fr/

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 03:20:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2016 08:20:44 +0000
Subject: [issue25907] Documentation i18n: Added trans tags in sphinx templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453364444.85.0.318584312142.issue25907@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The patch only changes Doc/tools/templates/indexcontent.html.

(Simplified) example of change on Doc/tools/templates/indexcontent.html:

   "
What's new in Python {{ version }}?
"

becomes

   "
{% trans %}What's new in Python {{ version }}?{% endtrans %}
"

I'm not a big fan of this option. Where does {% trans %}...{% endtrans %} format come from?

Is there an existing format to translate HTML templates?

I found html_translator_class config option in Sphinx:

http://www.sphinx-doc.org/en/stable/config.html?highlight=trans#confval-html_translator_class

Can't you avoid the new tags and use a small HTML parser to extract all strings?

----------
nosy: +ezio.melotti, haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 03:21:29 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2016 08:21:29 +0000
Subject: [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <1453364489.93.0.220250239097.issue26106@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 03:22:27 2016
From: report at bugs.python.org (Sean Wang)
Date: Thu, 21 Jan 2016 08:22:27 +0000
Subject: [issue2931] optparse: various problems with unicode and gettext
In-Reply-To: <1211297479.44.0.970954846769.issue2931@psf.upfronthosting.co.za>
Message-ID: <1453364547.59.0.107297265589.issue2931@psf.upfronthosting.co.za>


Sean Wang added the comment:

when an unicode option.default_value could not be ascii encoded, it would throw exception, detailed logs below:
  File "/Users/seanwang/Documents/dev/foo/bar.py", line 119, in main
    parser.print_help()
  File "/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 1670, in print_help
    file.write(self.format_help().encode(encoding, "replace"))
  File "/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 1650, in format_help
    result.append(self.format_option_help(formatter))
  File "/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 1630, in format_option_help
    result.append(OptionContainer.format_option_help(self, formatter))
  File "/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 1074, in format_option_help
    result.append(formatter.format_option(option))
  File "/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 316, in format_option
    help_text = self.expand_default(option)
  File "/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 288, in expand_default
    return option.help.replace(self.default_tag, str(default_value))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 3-4: ordinal not in range(128)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 03:42:57 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Jan 2016 08:42:57 +0000
Subject: [issue5001] Remove assertion-based checking in multiprocessing
In-Reply-To: <1232382762.58.0.610641171059.issue5001@psf.upfronthosting.co.za>
Message-ID: <1453365777.26.0.583003471965.issue5001@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
nosy: +berker.peksag
type:  -> enhancement
versions: +Python 3.6 -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 03:55:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Jan 2016 08:55:10 +0000
Subject: [issue26169] Pasting 900000 chars into a tk Entry widget fails
In-Reply-To: <1453346436.13.0.197116211445.issue26169@psf.upfronthosting.co.za>
Message-ID: <1453366510.95.0.73807472441.issue26169@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I can't reproduce the issue on Linux with the Entry widget, but can reproduce it with the Text widget. The difference is that the Text widget wraps its content on multiple lines. Looks the code for dynamical splitting the text on lines has quadratic (or larger) complexity. IDLE itself already suffers from similar issue for output text (issue1442493).

For issue1442493 we can preprocess output text. I don't know if we can add a handler for preprocessing pasted text, and wherever it is worth to do. Even if this is possible, new code can be too complex for such corner case.

----------
components: +IDLE
priority: normal -> low
type: crash -> behavior
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 04:17:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Jan 2016 09:17:55 +0000
Subject: [issue15809] 2.7 IDLE  console uses incorrect encoding.
In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za>
Message-ID: <1453367875.11.0.246421700383.issue15809@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It would be nice to add configuration option for IDLE Shell encoding and highlight non-encodable characters in Shell and Editor. But this feature is needed mainly for 2.7.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 04:18:19 2016
From: report at bugs.python.org (Michael Foord)
Date: Thu, 21 Jan 2016 09:18:19 +0000
Subject: [issue25520] unittest load_tests protocol not working as documented
In-Reply-To: <1446239702.03.0.964231995407.issue25520@psf.upfronthosting.co.za>
Message-ID: <1453367899.97.0.862875859637.issue25520@psf.upfronthosting.co.za>


Michael Foord added the comment:

To find and run tests recursively from a test package you want test discovery rather than (necessarily) load_tests.

For a bug report, please describe the behaviour you expect and the behaviour you're seeing instead.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 04:19:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Jan 2016 09:19:10 +0000
Subject: [issue26167] Improve copy.copy speed for built-in types
 (list/set/dict)
In-Reply-To: <1453313258.69.0.822432262864.issue26167@psf.upfronthosting.co.za>
Message-ID: <1453367950.41.0.492449286537.issue26167@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, sorry. Here is a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file41679/copy_speedup.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 04:56:51 2016
From: report at bugs.python.org (Julien)
Date: Thu, 21 Jan 2016 09:56:51 +0000
Subject: [issue25907] Documentation i18n: Added trans tags in sphinx templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453370211.72.0.568196619299.issue25907@psf.upfronthosting.co.za>


Julien added the comment:

@haypo I used the ``{trans}`` ``{endtrans}`` syntax because [Sphinx uses Jinja](http://www.sphinx-doc.org/en/stable/templating.html) and [``{trans}`` is the Jinja syntax for internationalisation](http://jinja.pocoo.org/docs/dev/templates/#i18n)

So ``{trans}`` is the standard syntax in this context and as you see I did not implemented a small script to parse them, Sphinx does it for me and add them in ``po`` files by itself, so Sphinx understand them, without need of some code.

It is possible to parse HTML to extract the strings to translate, but it would also fetch some false positives, and probably won't cut sentences at the right place, typically:

    
The Python Documentation


is easy to parse, extract the sentence, translate it, and, at compile-time, search and replace the sentence by its translation, nice.

    Here are more details about it.

Would be hard to parse: we'll need to introduce an heuristic to tell if we keep the HTML tag in the translation, or split it in three sentences "Here are", "more details", "about it". Sadly, splitting it in three sentences is not possible, because in some languages the order or those blocks may be swapped. So we need to get the  and  inside the sentence to allow translator to move the three part around freely.

Also, the Jinja xgettext parser handle variables inside translation, to start from a non-standard syntax ``{{ variable_name }}`` to a more standard one (normally ``%s`` so the string can be used on almost every languages, but here) ``%(variable)s``.

Those variables are obligatory, without them we'll get *code* inside translations strings, like ``pathto("whatsnew/index")``, which is even uglier than ``%(variable)s``.

Here it is:

     {% trans whatsnew_index=pathto("whatsnew/index") %}or all "What's new" documents since 2.0{% endtrans %}


Which yiels, in po files:

    "or all \"What's new\" documents since 2.0"

Which is better than:

    "or all \"What's new\" documents since 2.0"

Which itself is better (for the re-ordering problem in other languages) than:

    "or"
    "all \"What's new documents"
    "since 2.0"

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 05:05:18 2016
From: report at bugs.python.org (Julien)
Date: Thu, 21 Jan 2016 10:05:18 +0000
Subject: [issue25907] Documentation i18n: Added trans tags in sphinx templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453370718.79.0.714552292507.issue25907@psf.upfronthosting.co.za>


Julien added the comment:

That's also the actual syntax used by existing Sphinx templates:

    mandark at windhowl$ grep -r '{% trans'  ~/.local/lib/python3.4/site-packages/sphinx_rtd_theme/
    footer.html:        {% trans path=pathto('copyright'), copyright=copyright|e %}© Copyright {{ copyright }}.{% endtrans %}
    footer.html:        {% trans copyright=copyright|e %}© Copyright {{ copyright }}.{% endtrans %}
    ...
    ...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 05:07:01 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Jan 2016 10:07:01 +0000
Subject: [issue11551] test_dummy_thread.py test coverage improvement
In-Reply-To: <1300167076.06.0.564640850905.issue11551@psf.upfronthosting.co.za>
Message-ID: <1453370821.68.0.477061061311.issue11551@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Denver.

Two things:

1. MockFunction needs to be replaced with unittest.mock.Mock.
2. Comments from Sandro and Ezio needs to be addressed.

----------
nosy: +berker.peksag
stage: patch review -> needs patch
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 05:19:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2016 10:19:23 +0000
Subject: [issue25907] Documentation i18n: Added trans tags in sphinx templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453371563.34.0.684296468662.issue25907@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> @haypo I used the ``{trans}`` ``{endtrans}`` syntax because [Sphinx uses Jinja](http://www.sphinx-doc.org/en/stable/templating.html) and [``{trans}`` is the Jinja syntax for internationalisation](http://jinja.pocoo.org/docs/dev/templates/#i18n)

Oh ok, fair enough :-)

Doc/tools/templates/ contains 3 HTML files, why not updating the 2 other HTML files?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 05:22:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Jan 2016 10:22:10 +0000
Subject: [issue25843] code_richcompare() don't use constant type when
 comparing code constants
In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za>
Message-ID: <1453371730.64.0.143922840434.issue25843@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I meant that set shouldn't be handled in _PyCode_ConstantKey at all. Only frozenset constants can be considered equal. Sets as well as lists all should be different.

There is yet one issue with string and bytes literals. When run Python with the -b option:

>>> a, b = lambda: 'a', lambda: b'a'
sys:1: BytesWarning: Comparison between bytes and string
sys:1: BytesWarning: Comparison between bytes and string

May be the type should be the first item in the key.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 05:28:08 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Jan 2016 10:28:08 +0000
Subject: [issue25591] refactor imaplib tests
In-Reply-To: <1447107407.81.0.130095933409.issue25591@psf.upfronthosting.co.za>
Message-ID: <1453372088.03.0.16159851424.issue25591@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 05:30:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Jan 2016 10:30:46 +0000
Subject: [issue25591] refactor imaplib tests
In-Reply-To: <1447107407.81.0.130095933409.issue25591@psf.upfronthosting.co.za>
Message-ID: <1453372246.25.0.692125900036.issue25591@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file41680/new_imap_tests_v3.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 05:46:23 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 21 Jan 2016 10:46:23 +0000
Subject: [issue26173] test_ssl.bad_cert_test() exception handling
Message-ID: <1453373183.85.0.754157160572.issue26173@psf.upfronthosting.co.za>


New submission from Martin Panter:

In bad_cert_test(), there are two OSError exception handler; one masking the other. In Python 3, I think we should remove the second (dead) handler. In Python 2, maybe the first OSError handler should catch socket.error instead.

Originally, in r80534, socket.error was caught and ignored, with the vague explanation ?socket.error can really happen here?. Then revision 9297974604ff added an IOError handler, presumably to catch ENOENT for test_nonexisting_cert().

Later, in revisions 50d19c2fac82 and 9297974604ff, socket.error and IOError were both changed to OSError. I guess in Python 3 we should just catch all OSError exceptions and remove the second handler that only wants ENOENT.

In Python 2, there was a large backport of SSL functionality in revision 221a1f9155e2 (Issue 21308). It seems to have brought too much of the OSError alias changes with it. This is probably the cause of the following 2.7 builtbot failure:

http://buildbot.python.org/all/builders/x86%20XP-4%202.7/builds/3580/steps/test/logs/stdio
======================================================================
ERROR: test_nonexisting_cert (test.test_ssl.ThreadedTests)
Connecting with a non-existing cert file
----------------------------------------------------------------------
Traceback (most recent call last):
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\test\test_ssl.py", line 2153, in test_nonexisting_cert
    "wrongcert.pem"))
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\test\test_ssl.py", line 1889, in bad_cert_test
    s.connect((HOST, server.port))
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\ssl.py", line 844, in connect
    self._real_connect(addr, False)
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\ssl.py", line 835, in _real_connect
    self.do_handshake()
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\ssl.py", line 808, in do_handshake
    self._sslobj.do_handshake()
error: [Errno 10054] An existing connection was forcibly closed by the remote host

Errno 10054 is apparently ECONNRESET.

----------
components: Tests
keywords: buildbot
messages: 258754
nosy: martin.panter
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ssl.bad_cert_test() exception handling
versions: Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 06:11:04 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 21 Jan 2016 11:11:04 +0000
Subject: [issue26144] test_pkg test_4 and/or test_7 sometimes fail
In-Reply-To: <1453094860.75.0.307197769475.issue26144@psf.upfronthosting.co.za>
Message-ID: <1453374664.41.0.687954283212.issue26144@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think I traced this to revision fbbf8b160e8d (Issue 9548, Python 3.4). Before that revision, I haven?t been able to produce the failures. Also, reverting that change in the current default branch seems to stop the failures. Attached is the patch that reverts the change, though I am not suggesting that is the ultimate fix.

FTR my main setup is x86-64 Arch Linux; I also see this on a 32-bit Linux computer.

----------
keywords: +3.4regression, patch
Added file: http://bugs.python.org/file41681/revert-bootlocale.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 06:28:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Jan 2016 11:28:47 +0000
Subject: [issue26144] test_pkg test_4 and/or test_7 sometimes fail
In-Reply-To: <1453094860.75.0.307197769475.issue26144@psf.upfronthosting.co.za>
Message-ID: <1453375727.66.0.727060797316.issue26144@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
nosy: +brett.cannon, eric.snow, ncoghlan

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 06:42:47 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Jan 2016 11:42:47 +0000
Subject: [issue8690] multiprocessing.dummy.Queue does not expose same
 interface as multiprocessing.Queue
In-Reply-To: <1273603184.02.0.789462329458.issue8690@psf.upfronthosting.co.za>
Message-ID: <1453376567.09.0.645613536779.issue8690@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
nosy: +berker.peksag
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.6 -Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 07:49:06 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2016 12:49:06 +0000
Subject: [issue25843] code_richcompare() don't use constant type when
 comparing code constants
In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za>
Message-ID: <1453380546.38.0.478915480931.issue25843@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Updated patch version 5.

> I meant that set shouldn't be handled in _PyCode_ConstantKey at all. Only frozenset constants can be considered equal. Sets as well as lists all should be different.

Ok, I dropped support for set type to only keep support for frozenset. set are now always considered as different, as list and other "unsupported types".

> There is yet one issue with string and bytes literals. When run Python with the -b option:
> (...)
> May be the type should be the first item in the key.

Oh, good catch. It's an old bug.

Yeah, putting the type as the first parameter fixes the issue. I made this change. I had to update compile.c to exchange the type and the value in the tuple.

----------
Added file: http://bugs.python.org/file41682/code_richcompare-5.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 10:48:20 2016
From: report at bugs.python.org (Jan Pokorny)
Date: Thu, 21 Jan 2016 15:48:20 +0000
Subject: [issue26174] Exception alias cause destruction of existing variable
Message-ID: <1453391300.18.0.241912144859.issue26174@psf.upfronthosting.co.za>


New submission from Jan Pokorny:

Encountered a weird behavior when working with variable with the same name as exception's alias.

Observed behavior:

- In case variable with the same name (e.g. 'e') already exists when any 'except Error as e' block is executed, the 'e' variable is removed after exception handling finishes (NameError: name 'e' is not defined)

- Happens only in Python 3
- Code reproducing the issue included

Expected behavior:

- Variable is kept in its pre-exception state

Proposed solution:

- Store colliding variable into temporary variable, restore it afterwards

----------
components: Interpreter Core
files: schrodinger.py
messages: 258757
nosy: japokorn
priority: normal
severity: normal
status: open
title: Exception alias cause destruction of existing variable
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file41683/schrodinger.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 10:55:02 2016
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 21 Jan 2016 15:55:02 +0000
Subject: [issue26174] Exception alias cause destruction of existing variable
In-Reply-To: <1453391300.18.0.241912144859.issue26174@psf.upfronthosting.co.za>
Message-ID: <1453391702.86.0.626114646752.issue26174@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy: +ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 11:59:22 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2016 16:59:22 +0000
Subject: [issue26099] site ignores ImportError when running sitecustomize and
 usercustomize
In-Reply-To: <1452696404.05.0.367833198211.issue26099@psf.upfronthosting.co.za>
Message-ID: <1453395562.29.0.879112299561.issue26099@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@Brett: Ping? I'm going to push the fix to Python 3.6.

Tell me if you are ok to backport the change to Python 2.7 and 3.5 too.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 12:00:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2016 17:00:14 +0000
Subject: [issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit
 constants
In-Reply-To: <1453136691.51.0.69393755181.issue26146@psf.upfronthosting.co.za>
Message-ID: <1453395614.88.0.853226232007.issue26146@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
dependencies: +code_richcompare() don't use constant type when comparing code constants

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 12:02:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2016 17:02:57 +0000
Subject: [issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit
 constants
In-Reply-To: <1453136691.51.0.69393755181.issue26146@psf.upfronthosting.co.za>
Message-ID: <1453395777.08.0.76351145522.issue26146@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> We also make no backwards-compatibility guarantees about the AST, so if it simplifies things to switch entirely to Constant from Num, etc. then I said do it.

Replacing Num/Str/... with Constant causes bug in markerlib (used by pip, it breaks indirectly the venv module of the stdlib) and Chameleon benchmark. I only found these projects by mistake. I'm quite sure that much more code rely on the AST "API" even if it's unstable.

I prefer to not break the API for free :-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 12:12:46 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jan 2016 17:12:46 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <20160121171234.25910.8143@psf.io>


Roundup Robot added the comment:

New changeset c6fb1651ea2e by Victor Stinner in branch 'default':
Issue #26107: Fix typo in Objects/lnotab_notes.txt
https://hg.python.org/cpython/rev/c6fb1651ea2e

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 12:38:40 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jan 2016 17:38:40 +0000
Subject: [issue25909] Incorrect documentation for PyMapping_Items and like
In-Reply-To: <1450525085.87.0.352365699992.issue25909@psf.upfronthosting.co.za>
Message-ID: <20160121173837.25906.36901@psf.io>


Roundup Robot added the comment:

New changeset e57949f5d0a9 by Senthil Kumaran in branch '3.5':
issue25909 - Correct the documentation of PyMapping_Items, PyMapping_Keys and
https://hg.python.org/cpython/rev/e57949f5d0a9

New changeset 739e1b0032c6 by Senthil Kumaran in branch 'default':
merge from 3.5
https://hg.python.org/cpython/rev/739e1b0032c6

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 12:39:20 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Jan 2016 17:39:20 +0000
Subject: [issue26099] site ignores ImportError when running sitecustomize and
 usercustomize
In-Reply-To: <1452696404.05.0.367833198211.issue26099@psf.upfronthosting.co.za>
Message-ID: <1453397960.59.0.868186489989.issue26099@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Semantics are fine (I initially misread what you wanted to do; sorry).

And I wouldn't backport since it's an enhancement and not a bugfix.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 12:39:26 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Jan 2016 17:39:26 +0000
Subject: [issue26099] site ignores ImportError when running sitecustomize and
 usercustomize
In-Reply-To: <1452696404.05.0.367833198211.issue26099@psf.upfronthosting.co.za>
Message-ID: <1453397966.58.0.397594722807.issue26099@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
assignee:  -> haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 12:41:42 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 21 Jan 2016 17:41:42 +0000
Subject: [issue25909] Incorrect documentation for PyMapping_Items and like
In-Reply-To: <1450525085.87.0.352365699992.issue25909@psf.upfronthosting.co.za>
Message-ID: <1453398102.42.0.154056563488.issue25909@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the patch. I had to do some minor clarification like mention view types apply only to dict and also remove the sentence which mentioned those equivalent to list(o.values()) and list(o.items()) in the patch.

With those fixed, I have commited the change.

----------
assignee: docs at python -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 12:42:00 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 21 Jan 2016 17:42:00 +0000
Subject: [issue26174] Exception alias cause destruction of existing variable
In-Reply-To: <1453391300.18.0.241912144859.issue26174@psf.upfronthosting.co.za>
Message-ID: <1453398120.45.0.977657616069.issue26174@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I don't believe this is a bug.

1) try/except does not introduce a new scope
2) 'except E as N' is just name assignment
3) except clauses are documented to always delete the exception alias at the end of the except block[0].  The example in the docs could be clarified to show that

   except E as N:
       foo

is really more like

   except E:
       N = sys.exc_info()[1]
       try:
           foo
       finally:
           del N

Note that 'as' assignment with the 'with' statement also overrides a local variable of the same name.  The simplest way to avoid this issue is to use a different name for the exception alias.


[0] https://docs.python.org/3/reference/compound_stmts.html#the-try-statement

----------
nosy: +zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 12:50:08 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Jan 2016 17:50:08 +0000
Subject: [issue26174] Exception alias cause destruction of existing variable
In-Reply-To: <1453391300.18.0.241912144859.issue26174@psf.upfronthosting.co.za>
Message-ID: <1453398608.02.0.294117787767.issue26174@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So the exception is explicitly deleted when the `except` block is exited to prevent leaking memory from the traceback attached to the exception. Hence there's an implicit `del e` at the end of the `except` block which is what you're running up against.

But I'm closing this as 'wont fix' because making this edge case work would be real troublesome and destroy performance whenever you bound the caught exception. Basically you would have to do the equivalent of:

e = 42
try:
  1/0
except ZeroDivisionError as _hidden_e:
  _overridden = False
  try:
    _old_e = e
    _overridden = True
  except NameError:
    pass
  e = _hidden_e
  # `except` block ...
  del e, _hidden_e
  if _hidden_flag:
    e = _old_e

That's a lot of code to run on every `except` clause that just happens to shadow a previously existing variable name. Because we try and not make exceptions too expensive in order to make them usable for occasional control flow, I don't think we can afford to add all of this for this edge case.

----------
nosy: +brett.cannon
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 14:24:14 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 21 Jan 2016 19:24:14 +0000
Subject: [issue11551] test_dummy_thread.py test coverage improvement
In-Reply-To: <1300167076.06.0.564640850905.issue11551@psf.upfronthosting.co.za>
Message-ID: <1453404254.34.0.123830137461.issue11551@psf.upfronthosting.co.za>


Changes by Mark Lawrence :


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 15:15:55 2016
From: report at bugs.python.org (Stefan Seefeld)
Date: Thu, 21 Jan 2016 20:15:55 +0000
Subject: [issue25520] unittest load_tests protocol not working as documented
In-Reply-To: <1446239702.03.0.964231995407.issue25520@psf.upfronthosting.co.za>
Message-ID: <1453407355.65.0.266298868092.issue25520@psf.upfronthosting.co.za>


Stefan Seefeld added the comment:

I believe what I actually want is for the discovery mechanism to be fully implicit. It turns out that already *almost* works right now.

What doesn't work (and what this bug report really was about initially), is the use of the 'discover' command with the '-p "*.py"' argument, which for some reason makes certain tests (all ?) count twice. It looks like packages are visited twice, once as modules, and once via their contained '__init__.py' file...

(For the implicit discovery to work better, I believe, the discovery-specific options need to be made available through the main parser, so they can be used even without the 'discover' command.)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 16:19:49 2016
From: report at bugs.python.org (Soufiane BOUSSALI)
Date: Thu, 21 Jan 2016 21:19:49 +0000
Subject: [issue26169] Crash Python IDLE 2.7.11
In-Reply-To: <1453346436.13.0.197116211445.issue26169@psf.upfronthosting.co.za>
Message-ID: <1453411189.76.0.637933611116.issue26169@psf.upfronthosting.co.za>


Soufiane BOUSSALI added the comment:

The Function Find In Python IDLE 2.7.11 Affected To Crash Python Environnement On Windows Platform

----------
title: Pasting 900000 chars into a tk Entry widget fails -> Crash Python IDLE 2.7.11
Added file: http://bugs.python.org/file41684/py2.7.11.png

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 16:52:01 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 21 Jan 2016 21:52:01 +0000
Subject: [issue25613] fix ssl tests with sslv3 disabled
In-Reply-To: <1447370836.15.0.704598456658.issue25613@psf.upfronthosting.co.za>
Message-ID: <1453413121.33.0.224327194912.issue25613@psf.upfronthosting.co.za>


Martin Panter added the comment:

Sounds like this should be partly fixed via Issue 25530, and now Issue 25724 has been opened about the remaining problem (the patch there includes the same change from the Launchpad link).

----------
nosy: +martin.panter
resolution:  -> duplicate
status: open -> closed
superseder:  -> SSLv3 test failure on Ubuntu 16.04 LTS

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 16:54:34 2016
From: report at bugs.python.org (Gary Fernie)
Date: Thu, 21 Jan 2016 21:54:34 +0000
Subject: [issue26175] Fully implement IOBase abstract on SpooledTemporaryFile
Message-ID: <1453413274.25.0.536987988375.issue26175@psf.upfronthosting.co.za>


New submission from Gary Fernie:

SpooledTemporaryFile does not fully satisfy the abstract for IOBase.
Namely, `seekable`, `readable`, and `writable` are missing.

This was discovered when seeking a SpooledTemporaryFile-backed lzma file.
You may quickly repro this:
`lzma.open(SpooledTemporaryFile()).seek(0)`

----------
files: fix-SpooledTemporaryFile-IOBase-abstract.patch
keywords: patch
messages: 258769
nosy: Gary Fernie
priority: normal
severity: normal
status: open
title: Fully implement IOBase abstract on SpooledTemporaryFile
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41685/fix-SpooledTemporaryFile-IOBase-abstract.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 16:59:10 2016
From: report at bugs.python.org (=?utf-8?q?Gedai_Tam=C3=A1s_Bence?=)
Date: Thu, 21 Jan 2016 21:59:10 +0000
Subject: [issue19225] lack of PyExc_BufferError doc
In-Reply-To: <1381485777.95.0.364414099437.issue19225@psf.upfronthosting.co.za>
Message-ID: <1453413550.0.0.503017510621.issue19225@psf.upfronthosting.co.za>


Gedai Tam?s Bence added the comment:

Let me try to solve this issue. Will be back in 4 days.

----------
nosy: +beng94

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 17:00:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jan 2016 22:00:04 +0000
Subject: [issue18620] multiprocessing page leaves out important part of Pool
 example
In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za>
Message-ID: <20160121220001.14177.82831@psf.io>


Roundup Robot added the comment:

New changeset c89f4f59872f by Berker Peksag in branch '3.5':
Issue #18620: Improve Pool examples in multiprocessing documentation
https://hg.python.org/cpython/rev/c89f4f59872f

New changeset 9f201578d8d9 by Berker Peksag in branch 'default':
Issue #18620: Improve Pool examples in multiprocessing documentation
https://hg.python.org/cpython/rev/9f201578d8d9

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 17:06:58 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jan 2016 22:06:58 +0000
Subject: [issue18620] multiprocessing page leaves out important part of Pool
 example
In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za>
Message-ID: <20160121220654.41340.83184@psf.io>


Roundup Robot added the comment:

New changeset 9480e217ade0 by Berker Peksag in branch '2.7':
Issue #18620: Improve Pool examples in multiprocessing documentation
https://hg.python.org/cpython/rev/9480e217ade0

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 17:08:58 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Jan 2016 22:08:58 +0000
Subject: [issue18620] multiprocessing page leaves out important part of Pool
 example
In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za>
Message-ID: <1453414138.96.0.916690903295.issue18620@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Davin. I tweaked code style a bit and removed trailing whitespaces.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 17:24:52 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 21 Jan 2016 22:24:52 +0000
Subject: [issue24930] test_ssl: try more protocols in test_options()
In-Reply-To: <1440458283.72.0.838708859069.issue24930@psf.upfronthosting.co.za>
Message-ID: <1453415092.2.0.406598316458.issue24930@psf.upfronthosting.co.za>


Martin Panter added the comment:

Your patch removes the testing of getting ctx.options. However, OP_NO_SSLv3 was enabled by default and added to the test in Issue 25530, so I suspect that problem is no longer valid.

I guess that leaves the rest of your patch which exercises other protocol values.

----------
components: +Tests -Library (Lib)
nosy: +martin.panter
stage:  -> patch review
title: test_ssl broker was fixed -> test_ssl: try more protocols in test_options()
type: crash -> enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 17:35:30 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 21 Jan 2016 22:35:30 +0000
Subject: [issue24761] ERROR: test_dh_params (test.test_ssl.ThreadedTests)
Message-ID: <1453415730.95.0.869694876918.issue24761@psf.upfronthosting.co.za>


New submission from Martin Panter:

Same error log with a few more details in Issue 24985.

----------
nosy: +martin.panter
resolution:  -> duplicate
status: open -> closed
superseder:  -> Python install test fails - OpenSSL - "dh key too small"

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 17:36:31 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Jan 2016 22:36:31 +0000
Subject: [issue25830] _TypeAlias: Discrepancy between docstring and behavior
In-Reply-To: <1449662252.92.0.779493267097.issue25830@psf.upfronthosting.co.za>
Message-ID: <1453415791.43.0.68863214272.issue25830@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Looks like the docstring is a bit misleading. ``isinstance(m, Match)`` behavior is already tested in the test suite: https://hg.python.org/cpython/file/default/Lib/test/test_typing.py#l1297

----------
nosy: +berker.peksag, gvanrossum

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 17:45:02 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 21 Jan 2016 22:45:02 +0000
Subject: [issue24985] Python install test fails - OpenSSL - "dh key too small"
In-Reply-To: <1441223895.76.0.826003370838.issue24985@psf.upfronthosting.co.za>
Message-ID: <1453416302.42.0.252011790935.issue24985@psf.upfronthosting.co.za>


Martin Panter added the comment:

I suspect this is fixed in 3.4.4. The 512-bit file was replaced by a 1024-bit (or 2014-bit if you believe the commit message :) one in Issue 23844, revision 1ad7c0253abe.

----------
components: +Tests -Installation
nosy: +martin.panter
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> test_ssl: fails on recent libressl version with BAD_DH_P_LENGTH

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 18:25:22 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 21 Jan 2016 23:25:22 +0000
Subject: [issue25830] _TypeAlias: Discrepancy between docstring and behavior
In-Reply-To: <1453415791.43.0.68863214272.issue25830@psf.upfronthosting.co.za>
Message-ID: 


Guido van Rossum added the comment:

Actually isinstance() shouldn't be supported by most things in typing.py
(except for those that mimic existing collection ABCs). Even issubclass()
should be taken out according to the BDFL-delegate for PEP 484. See
https://github.com/ambv/typehinting/issues/136

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 18:40:14 2016
From: report at bugs.python.org (Insu Yun)
Date: Thu, 21 Jan 2016 23:40:14 +0000
Subject: [issue26171] heap overflow in zipimporter module
In-Reply-To: <1453348353.03.0.314168195173.issue26171@psf.upfronthosting.co.za>
Message-ID: <1453419614.27.0.67236780112.issue26171@psf.upfronthosting.co.za>


Insu Yun added the comment:

in zipimport.c
  1116     bytes_size = compress == 0 ? data_size : data_size + 1;
  1117     if (bytes_size == 0)
  1118         bytes_size++;
  1119     raw_data = PyBytes_FromStringAndSize((char *)NULL, bytes_size);

If compress != 0, then bytes_size = data_size + 1
data_size is not sanitized, so if data_size = -1, then it overflows and becomes 0.
In that case bytes_size becomes 1 and python allocates small heap, but after that in fread, it overflows heap.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 19:49:28 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Jan 2016 00:49:28 +0000
Subject: [issue26169] Pasting 900000 chars into a tk Entry widget fails
In-Reply-To: <1453346436.13.0.197116211445.issue26169@psf.upfronthosting.co.za>
Message-ID: <1453423768.88.0.458367923228.issue26169@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Soufiane, when a core developer (indicated by the Python icon after the name) changes a header, do not change it back.  Comment on the change if you want, but leave it as is.

My revised title accurately describes the core problem: the paste operation does not complete after the 10-15 minutes I allowed; I suspect and presume that it never will.  Asking tk to do something else while the pasting is ongoing or hung results in a crash.

Serhiy, I am puzzled that you added IDLE back as a component.  I demonstrated that the symptom can be reproduced with no involvement of idlelib at all.  I only left this open for you to decide if a) tkinter is involved and b) if you might want to change tkinter in response.  I otherwise consider this issue outside of reasonable expectations, equivalent to the won't-fix fact that CPython will not compile, for instance, a machine-generated tuple display nested 100,000 levels deep.

----------
components:  -IDLE
title: Crash Python IDLE 2.7.11 -> Pasting 900000 chars into a tk Entry widget fails

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 20:58:36 2016
From: report at bugs.python.org (Srujan Chaitanya)
Date: Fri, 22 Jan 2016 01:58:36 +0000
Subject: [issue26176] EmailMessage example doesn't work
Message-ID: <1453427916.73.0.91814079944.issue26176@psf.upfronthosting.co.za>


New submission from Srujan Chaitanya:

Example provided in 19.1.14.1. Examples using the Provisional API
at https://docs.python.org/3.4/library/email-examples.html?highlight=email%20example

Doesn't work. This could be a EmailMessage class issue also?

----------
assignee: docs at python
components: Documentation
messages: 258781
nosy: Srujan Chaitanya, docs at python
priority: normal
severity: normal
status: open
title: EmailMessage example doesn't work
type: behavior
versions: Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 21:30:11 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 22 Jan 2016 02:30:11 +0000
Subject: [issue26175] Fully implement IOBase abstract on SpooledTemporaryFile
In-Reply-To: <1453413274.25.0.536987988375.issue26175@psf.upfronthosting.co.za>
Message-ID: <1453429811.57.0.0390461207751.issue26175@psf.upfronthosting.co.za>


Martin Panter added the comment:

It would be nice to add test cases for this.

Looking at , there is a version changed notice for the truncate() method. So perhaps this should be added as a new feature for 3.6. On the other hand, the documentation doesn?t mention the specific API, so I would assume the relevant IOBase subclass, and this would be a bug.

----------
components: +Library (Lib)
nosy: +martin.panter
stage:  -> patch review
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 21:39:11 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 22 Jan 2016 02:39:11 +0000
Subject: [issue23965] test_ssl failure on Fedora 22
In-Reply-To: <1429109042.15.0.0394513301498.issue23965@psf.upfronthosting.co.za>
Message-ID: <1453430351.61.0.23488264182.issue23965@psf.upfronthosting.co.za>


Martin Panter added the comment:

I suspect the patches here are out of date considering SSL v3 has been disabled by default in Python via Issue 25613, revision 56f64ec9259f. Is there any bits of the patches worth resurrecting (for cleaner logic, future-proofing or something)? Or is this completely out of date now?

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 21:40:39 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 22 Jan 2016 02:40:39 +0000
Subject: [issue23965] test_ssl failure on Fedora 22
In-Reply-To: <1429109042.15.0.0394513301498.issue23965@psf.upfronthosting.co.za>
Message-ID: <1453430439.24.0.131386807429.issue23965@psf.upfronthosting.co.za>


Martin Panter added the comment:

Sorry bug disabling v3 by default is Issue 25530

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 21:49:38 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 22 Jan 2016 02:49:38 +0000
Subject: [issue25724] SSLv3 test failure on Ubuntu 16.04 LTS
In-Reply-To: <1448379899.26.0.590688499284.issue25724@psf.upfronthosting.co.za>
Message-ID: <1453430978.85.0.512143119361.issue25724@psf.upfronthosting.co.za>


Martin Panter added the comment:

This sounds like a Ubuntu-specific hack. Maybe it would be better to adjust the @skip_if_broken_ubuntu_ssl decorator?

Also, according to Issue 25530, Python 3.4+ and 2.7 set OP_NO_SSLv3 by default, and according to Issue 23845, maybe some versions of Open SSL do too. But in these cases it is still configurable.

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 21:58:58 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 22 Jan 2016 02:58:58 +0000
Subject: [issue23845] test_ssl: fails on recent libressl with
 SSLV3_ALERT_HANDSHAKE_FAILURE
In-Reply-To: <1427926862.2.0.277939784676.issue23845@psf.upfronthosting.co.za>
Message-ID: <1453431538.86.0.238008002018.issue23845@psf.upfronthosting.co.za>


Martin Panter added the comment:

Is this still relevant? At least the first part of the patch won?t be needed after SSLv3 was also disabling by default in Python: Issue 25530, revision 56f64ec9259f. See also Issue 25724 about Ubuntu disabling it a different way.

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 23:52:43 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 22 Jan 2016 04:52:43 +0000
Subject: [issue23965] test_ssl failure on Fedora 22
In-Reply-To: <1429109042.15.0.0394513301498.issue23965@psf.upfronthosting.co.za>
Message-ID: <1453438363.82.0.691266731545.issue23965@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

This is working fine on Fedora 23, so yeah, I think the change to always disallow SSLv3 by default resolved it.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 00:25:22 2016
From: report at bugs.python.org (David Heffernan)
Date: Fri, 22 Jan 2016 05:25:22 +0000
Subject: [issue26108] Calling PyInitialize with 2.7.11 on Windows x64
 terminates process
In-Reply-To: <1452765230.72.0.612722422255.issue26108@psf.upfronthosting.co.za>
Message-ID: <1453440322.41.0.133874725962.issue26108@psf.upfronthosting.co.za>


David Heffernan added the comment:

Why was this closed as "not a bug"? Shouldn't it have been closed as a duplicate?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 01:51:29 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Jan 2016 06:51:29 +0000
Subject: [issue26177] tkinter: Canvas().keys returns empty strings.
Message-ID: <1453445489.52.0.0197706093826.issue26177@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

tkinter wraps tk widgets as option-value mappings with subscripting and .keys().  The latter does not work for Canvas (subscripting does).  First tested with 3.5.1, Win 10. First Text versus Canvas contrast below was confirmed with 2.7.11.

>>> import tkinter as tk
>>> tk.Text().keys()
['autoseparators', 'background', 'bd', 'bg', 'blockcursor', 'tabstyle', 
...
'takefocus', 'undo', 'width', 'wrap', 'xscrollcommand', 'yscrollcommand']
>>> tk.Canvas().keys()
['', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '']

Explanation: Widget classes inherit keys from Misc via BaseWidget and Widget.  Misc.keys calls into tk.

    def keys(self):
        """Return a list of all resource names of this widget."""
        return [x[0][1:] for x in
                self.tk.splitlist(self.tk.call(self._w, 'configure'))]

The call returns different types for Text and Canvas.

>>> self = tk.Text()
>>> self.tk.call(self._w, 'configure')  # tuple of tuples
(('-autoseparators', 'autoSeparators', 'AutoSeparators', 1, 1),
 ('-background', 'background', 'Background', , 'SystemWindow'), )
>>> self = tk.Canvas()
>>> self.tk.call(self._w, 'configure')  # tcl list as single string
'{-background background Background SystemButtonFace SystemButtonFace} {-bd borderWidth} {-bg background} {-borderwidth borderWidth BorderWidth 0 0} ...'

This difference between widgets seems odd.  A bug in tcl/tk/_tkinter?

tk.splitlist appears to return the Text tuple of tuples as is.  It splits the Canvas string into a tuple of strings

('-background background Background SystemButtonFace SystemButtonFace', '-bd borderWidth', ... )

but does not split the inner strings.  As a consequence, x[0] is the first character of each string ('{' as it turns out, though not relevant) and the slice [1:] of a single char string is always ''.

Possible remedy: tk.split also leaves tuple of tuples alone *and* splits the inner strings to a tuple.

>>> self.tk.split(self.tk.call(self._w, 'configure'))
(('-background', 'background', 'Background', 'SystemButtonFace', 'red'), ('-bd', 'borderWidth'), ...)

So a fix (if the different returns are not changed) is to change 'splitlines' to 'split'.  With this change, keys (extracted as a function) gives the expected list.

>>> keys(tk.Canvas())
['background', 'bd', ..., 'yscrollincrement']

A test for Canvas().keys should be added somewhere.

----------
messages: 258789
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: tkinter: Canvas().keys returns empty strings.
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 02:02:48 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Jan 2016 07:02:48 +0000
Subject: [issue26177] tkinter: Canvas().keys returns empty strings.
In-Reply-To: <1453445489.52.0.0197706093826.issue26177@psf.upfronthosting.co.za>
Message-ID: <1453446168.52.0.638864713917.issue26177@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Bug came from https://stackoverflow.com/questions/34911069/tk-canvas-options-keys-list-empy.  Bryan Oakley answered that tk.Canvas().configure().keys() does work, making sorted(x.configure.keys()) a replacement for x.keys that should work for all widgets.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 03:48:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Jan 2016 08:48:48 +0000
Subject: [issue26177] tkinter: Canvas().keys returns empty strings.
In-Reply-To: <1453445489.52.0.0197706093826.issue26177@psf.upfronthosting.co.za>
Message-ID: <1453452528.11.0.0750228784409.issue26177@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 04:33:07 2016
From: report at bugs.python.org (Raimon Esteve)
Date: Fri, 22 Jan 2016 09:33:07 +0000
Subject: [issue26049] Poor performance when reading large xmlrpc data
In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za>
Message-ID: <1453455187.58.0.338991175715.issue26049@psf.upfronthosting.co.za>


Changes by Raimon Esteve :


----------
nosy: +resteve

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 06:06:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Jan 2016 11:06:01 +0000
Subject: [issue26177] tkinter: Canvas().keys returns empty strings.
In-Reply-To: <1453445489.52.0.0197706093826.issue26177@psf.upfronthosting.co.za>
Message-ID: <1453460761.72.0.932191722472.issue26177@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

split() has many warts, it shouldn't be used. It is enough just call splitlist() for elements of a list.

Proposed patch fixes Misc.keys(). It also adds tests for missed options (some of them are not explicitly documented).

----------
components: +Library (Lib), Tkinter
keywords: +patch
Added file: http://bugs.python.org/file41686/tkinter_keys.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 06:23:15 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jan 2016 11:23:15 +0000
Subject: [issue26099] site ignores ImportError when running sitecustomize and
 usercustomize
In-Reply-To: <1452696404.05.0.367833198211.issue26099@psf.upfronthosting.co.za>
Message-ID: <20160122112311.6054.55419@psf.io>


Roundup Robot added the comment:

New changeset c873a479a6a3 by Victor Stinner in branch 'default':
site: error on sitecustomize import error
https://hg.python.org/cpython/rev/c873a479a6a3

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 06:23:56 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 11:23:56 +0000
Subject: [issue26099] site ignores ImportError when running sitecustomize and
 usercustomize
In-Reply-To: <1452696404.05.0.367833198211.issue26099@psf.upfronthosting.co.za>
Message-ID: <1453461836.31.0.863678953553.issue26099@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Brett: "Semantics are fine (I initially misread what you wanted to do; sorry)."

Ok, I pushed my change.

Brett: "And I wouldn't backport since it's an enhancement and not a bugfix."

Ok, fine.

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 06:28:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Jan 2016 11:28:36 +0000
Subject: [issue26169] Pasting 900000 chars into a tk Entry widget fails
In-Reply-To: <1453346436.13.0.197116211445.issue26169@psf.upfronthosting.co.za>
Message-ID: <1453462116.62.0.0233889774561.issue26169@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I want to say that may be we can make a workaround for this issue in IDLE if it is worth. The "wont fix" resolution looks reasonable to me, but this doesn't mean that the issue couldn't be solved in principle (though the solution can be very costly). I'm closing this issue, but only because we have too  much other open IDLE issues, and with very good chance this issue will never solved.

Other issue is that it would be nice to make IDLE and Tkinter more responsive. Allow to interrupt long-running Tk operation and ask the user to save his files before quit. But this is separate issue.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 06:37:50 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jan 2016 11:37:50 +0000
Subject: [issue25843] code_richcompare() don't use constant type when
 comparing code constants
In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za>
Message-ID: <20160122113746.24749.20613@psf.io>


Roundup Robot added the comment:

New changeset 6c33d4cc9b8f by Victor Stinner in branch 'default':
code_richcompare() now uses the constants types
https://hg.python.org/cpython/rev/6c33d4cc9b8f

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 06:40:37 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 11:40:37 +0000
Subject: [issue25843] code_richcompare() don't use constant type when
 comparing code constants
In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za>
Message-ID: <1453462837.45.0.921487511579.issue25843@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I pushed my latest patch with minor changes in comments.

I will wait for buildbots before backporting the change to Python 2.7 and 3.5. For the backport, I will probably remove the optimization on frozenset since it's only useful for AST optimizers (the optimization is a new feature, I considered that it was worth it to add it Python 3.6 as part of my work on the PEP 511).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 06:50:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Jan 2016 11:50:00 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>
Message-ID: <1453463400.18.0.939657933558.issue19883@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Synchronized with current sources.

----------
components: +Extension Modules
keywords: +needs review
nosy: +benjamin.peterson
versions:  -Python 3.4
Added file: http://bugs.python.org/file41687/zipimport_int_overflow_3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 08:04:43 2016
From: report at bugs.python.org (=?utf-8?q?Gedai_Tam=C3=A1s_Bence?=)
Date: Fri, 22 Jan 2016 13:04:43 +0000
Subject: [issue19225] lack of PyExc_BufferError doc
In-Reply-To: <1381485777.95.0.364414099437.issue19225@psf.upfronthosting.co.za>
Message-ID: <1453467883.75.0.0394457131567.issue19225@psf.upfronthosting.co.za>


Gedai Tam?s Bence added the comment:

I've created a new table for warnings and added the missing exceptions to the exceptions table.

I did not find a link for VMSError, but I added it to the table.

Note that the exceptions table is not absolutely in alphabetical order, I can fix it as well, if it's needed.

----------
keywords: +patch
Added file: http://bugs.python.org/file41688/doc_exceptions.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 08:05:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 13:05:11 +0000
Subject: [issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit
 constants
In-Reply-To: <1453136691.51.0.69393755181.issue26146@psf.upfronthosting.co.za>
Message-ID: <1453467911.53.0.292186952701.issue26146@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 2:

- rework the whole patch
- add unit tests
- fix AST validation: the code was completly wrong in patch 1, I don't understand how it worked :-p Validate also correctly nested tuple and nested frozenset.
- add a comment to explain why obj2ast_constant() doesn't have to Py_INCREF() singletons
- handle also Ellipsis
- revert changes on set_context(). It seems like set_context() is only called with code emited directly by the compiler (not by compile(custom_ast_tree, ...)). If someone finds a way to call set_context() with an ast.Constant, we can support this case later.

----------
Added file: http://bugs.python.org/file41689/constant-2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 08:13:54 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jan 2016 13:13:54 +0000
Subject: [issue26161] Use Py_uintptr_t instead of void* for atomic pointers
In-Reply-To: <1453287433.06.0.917991277181.issue26161@psf.upfronthosting.co.za>
Message-ID: <20160122131351.24751.92589@psf.io>


Roundup Robot added the comment:

New changeset ff68ffcc6244 by Victor Stinner in branch 'default':
Use Py_uintptr_t for atomic pointers
https://hg.python.org/cpython/rev/ff68ffcc6244

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 08:14:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 13:14:09 +0000
Subject: [issue26161] Use Py_uintptr_t instead of void* for atomic pointers
In-Reply-To: <1453287433.06.0.917991277181.issue26161@psf.upfronthosting.co.za>
Message-ID: <1453468449.12.0.0838079834319.issue26161@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 08:15:40 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 13:15:40 +0000
Subject: [issue26164] test_with_pip() of test_venv fails on Windows buildbots
In-Reply-To: <1453293540.51.0.991113408845.issue26164@psf.upfronthosting.co.za>
Message-ID: <1453468540.78.0.342356989053.issue26164@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It looks like the issue was fixed with the upgrade of pip to 8.0.2: changeset c75802aaa4de (merge into default: changeset ca78f5e41012).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 08:15:59 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 13:15:59 +0000
Subject: [issue26164] test_with_pip() of test_venv fails on Windows buildbots
In-Reply-To: <1453293540.51.0.991113408845.issue26164@psf.upfronthosting.co.za>
Message-ID: <1453468559.7.0.790029192967.issue26164@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 08:16:15 2016
From: report at bugs.python.org (Donald Stufft)
Date: Fri, 22 Jan 2016 13:16:15 +0000
Subject: [issue26164] test_with_pip() of test_venv fails on Windows buildbots
In-Reply-To: <1453293540.51.0.991113408845.issue26164@psf.upfronthosting.co.za>
Message-ID: <1453468575.44.0.830938036316.issue26164@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Yes, it should have been. Sorry forgot this issue was opened.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 08:33:03 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jan 2016 13:33:03 +0000
Subject: [issue25876] test_gdb: use subprocess._args_from_interpreter_flags()
 to test Python with more options
In-Reply-To: <1450212038.89.0.962872352971.issue25876@psf.upfronthosting.co.za>
Message-ID: <20160122133257.64596.94765@psf.io>


Roundup Robot added the comment:

New changeset 05ea3efadead by Victor Stinner in branch 'default':
Issue #25876: test_gdb: use subprocess._args_from_interpreter_flags() to test
https://hg.python.org/cpython/rev/05ea3efadead

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 08:35:02 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 13:35:02 +0000
Subject: [issue25876] test_gdb: use subprocess._args_from_interpreter_flags()
 to test Python with more options
In-Reply-To: <1450212038.89.0.962872352971.issue25876@psf.upfronthosting.co.za>
Message-ID: <1453469702.26.0.834483697231.issue25876@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 08:35:34 2016
From: report at bugs.python.org (Devyn Johnson)
Date: Fri, 22 Jan 2016 13:35:34 +0000
Subject: [issue26178] Python C-API: __all__ Creator
Message-ID: <1453469734.25.0.137084363575.issue26178@psf.upfronthosting.co.za>


New submission from Devyn Johnson:

When creating Python modules via th C-API, it would be wonderful if there were an easier and more efficient way of creating an "__all__" for the module. In my opinion, an API function should be made; i.e., something like PyALL("FUNC1", "FUNC2", ...)


Currently, I use something like the below code.

"""
PyObject *create_all(void);

PyObject *create_all(void) {  // Create __all__
#define _ALLSTRING "[ssssss"
#define _ENDSTRING "]"
    return Py_BuildValue(
        _ALLSTRING
#if defined(ENV64BIT) && (defined(__x86_64__) || defined(__x86_64))
        "sss"
#ifdef __BMI2__
        "ssss"
#endif
#endif
        _ENDSTRING,
        // STRING CONVERSIONS
        "lowercasestr",
        "uppercasestr",
        // FIND AND REPLACE/REMOVE
        "strreplace",
        "strreplace_once",
        "rmgravequote",
        // ASSEMBLY-RELATED COMMANDS
#if defined(ENV64BIT) && (defined(__x86_64__) || defined(__x86_64))
        "rdtsc",
        "get_vendor_id",
        "get_cpu_stepping",
#ifdef __BMI2__
        "is_fpu_aval",
        "is_avx_aval",
        "is_fma_aval",
        "is_aes_aval",
#endif
#endif
        "nop"
    );
}

// Some code excluded

MODINIT {  // Initialize module
    PyObject *m;
    m = PyModule_Create(&module);
    PyModule_AddObject(m, "__all__", create_all());
    PyModule_AddStringConstant(m, "__author__", __author__);
    PyModule_AddStringConstant(m, "__version__", __version__);
    if (m == NULL)
        return NULL;
    return m;
}
"""

----------
components: Interpreter Core
messages: 258804
nosy: Devyn Johnson
priority: normal
severity: normal
status: open
title: Python C-API: __all__ Creator
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 08:43:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 13:43:24 +0000
Subject: [issue26178] Python C-API: __all__ Creator
In-Reply-To: <1453469734.25.0.137084363575.issue26178@psf.upfronthosting.co.za>
Message-ID: <1453470204.34.0.0584353248124.issue26178@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Seting __all__ is usually need to exclude some symbols from "from module import *". In Python, it's common to write public or private (name prefixed by "_") helper functions which are excluded from __all__. In C extensions, you have to explicitly expose a function. Why would you expose a function but exclude it from __all__?

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 08:47:23 2016
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 22 Jan 2016 13:47:23 +0000
Subject: [issue26178] Python C-API: __all__ Creator
In-Reply-To: <1453469734.25.0.137084363575.issue26178@psf.upfronthosting.co.za>
Message-ID: <1453470443.4.0.313351851503.issue26178@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I agree, and that's pretty much what Guido said here, too:

https://mail.python.org/pipermail/python-dev/2001-February/012591.html

----------
nosy: +skrah

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 09:01:59 2016
From: report at bugs.python.org (Devyn Johnson)
Date: Fri, 22 Jan 2016 14:01:59 +0000
Subject: [issue26178] Python C-API: __all__ Creator
In-Reply-To: <1453469734.25.0.137084363575.issue26178@psf.upfronthosting.co.za>
Message-ID: <1453471319.82.0.260605040417.issue26178@psf.upfronthosting.co.za>


Devyn Johnson added the comment:

Thanks, @skrah and @haypo . I never thought of it that way. I made "__all__" in my extensions because "__all__" was used in many Python scripts. Thanks for the alternative perspective.

----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 09:02:55 2016
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 22 Jan 2016 14:02:55 +0000
Subject: [issue26108] Calling PyInitialize with 2.7.11 on Windows x64
 terminates process
In-Reply-To: <1452765230.72.0.612722422255.issue26108@psf.upfronthosting.co.za>
Message-ID: <1453471375.41.0.370727604306.issue26108@psf.upfronthosting.co.za>


Changes by Eryk Sun :


----------
resolution: not a bug -> duplicate
superseder:  -> 32-bit 2.7.11 installer creates registry keys that are incompatible with the installed python27.dll

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 09:03:29 2016
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 22 Jan 2016 14:03:29 +0000
Subject: [issue26108] Calling PyInitialize with 2.7.11 on Windows x64
 terminates process
In-Reply-To: <1452765230.72.0.612722422255.issue26108@psf.upfronthosting.co.za>
Message-ID: <1453471409.21.0.070311198786.issue26108@psf.upfronthosting.co.za>


Changes by Eryk Sun :


----------
stage:  -> resolved

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 09:04:35 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jan 2016 14:04:35 +0000
Subject: [issue25876] test_gdb: use subprocess._args_from_interpreter_flags()
 to test Python with more options
In-Reply-To: <1450212038.89.0.962872352971.issue25876@psf.upfronthosting.co.za>
Message-ID: <20160122140432.64616.85724@psf.io>


Roundup Robot added the comment:

New changeset 9faa15da2dde by Victor Stinner in branch 'default':
Issue #25876: Fix also test_set() of test_gdb when -E command line is used
https://hg.python.org/cpython/rev/9faa15da2dde

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 09:06:20 2016
From: report at bugs.python.org (Devyn Johnson)
Date: Fri, 22 Jan 2016 14:06:20 +0000
Subject: [issue26179] Python C-API "unused-parameter" warnings
Message-ID: <1453471580.75.0.72814531944.issue26179@psf.upfronthosting.co.za>


New submission from Devyn Johnson:

When compiling Python C-API extensions with "-Wextra", warnings like 

warning: unused parameter ?self? [-Wunused-parameter]

appear for code (like below). It seems like a minor issue for a warning to appear when "PyObject *self, PyObject *args" is required. Is there an underlying issue in the API?

static PyObject *mathfunc_ismersenneprime(PyObject *self, PyObject *args) {
    sllint num;
    ASSERT_LONGLONG_ARG(num);
    if (num < (sllint)0) ERR_POSITIVE_INT;
    returnbool(islonglongmersenneprime(num));
}

----------
components: Interpreter Core
messages: 258809
nosy: Devyn Johnson
priority: normal
severity: normal
status: open
title: Python C-API "unused-parameter" warnings
type: behavior
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 09:13:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 14:13:41 +0000
Subject: [issue26179] Python C-API "unused-parameter" warnings
In-Reply-To: <1453471580.75.0.72814531944.issue26179@psf.upfronthosting.co.za>
Message-ID: <1453472021.53.0.650701351197.issue26179@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Is there an underlying issue in the API?

You can use self if your code. If you don't need it, you can use Py_UNUSED() macro available since Python 3.4.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 09:14:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 14:14:15 +0000
Subject: [issue26179] Python C-API "unused-parameter" warnings
In-Reply-To: <1453471580.75.0.72814531944.issue26179@psf.upfronthosting.co.za>
Message-ID: <1453472055.75.0.604666705958.issue26179@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Please don't open bug reports to ask questions on your own code. The bug tracker is not forum.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 09:18:44 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 22 Jan 2016 14:18:44 +0000
Subject: [issue26108] Calling PyInitialize with 2.7.11 on Windows x64
 terminates process
In-Reply-To: <1452765230.72.0.612722422255.issue26108@psf.upfronthosting.co.za>
Message-ID: <1453472324.82.0.786764863641.issue26108@psf.upfronthosting.co.za>


Steve Dower added the comment:

I read the issue as "running an embedded Python interpreter without a reachable standard library fails", which is by design. But for 2.7 it's also apparently the design to rely on an installed copy of Python for this. (This second part is no longer recommended for 3.5+ as there are more reliable options.)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 09:46:51 2016
From: report at bugs.python.org (Devyn Johnson)
Date: Fri, 22 Jan 2016 14:46:51 +0000
Subject: [issue26179] Python C-API "unused-parameter" warnings
In-Reply-To: <1453471580.75.0.72814531944.issue26179@psf.upfronthosting.co.za>
Message-ID: <1453474011.36.0.571117115978.issue26179@psf.upfronthosting.co.za>


Devyn Johnson added the comment:

Thank you and sorry.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 09:59:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jan 2016 14:59:49 +0000
Subject: [issue25843] code_richcompare() don't use constant type when
 comparing code constants
In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za>
Message-ID: <20160122145946.565.68410@psf.io>


Roundup Robot added the comment:

New changeset 8e0a736b82ff by Victor Stinner in branch '3.5':
code_richcompare() now uses the constants types
https://hg.python.org/cpython/rev/8e0a736b82ff

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 10:17:29 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 15:17:29 +0000
Subject: [issue25843] code_richcompare() don't use constant type when
 comparing code constants
In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za>
Message-ID: <1453475849.88.0.719679576401.issue25843@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I will probably remove the optimization on frozenset since it's only useful for AST optimizers (the optimization is a new feature, I considered that it was worth it to add it Python 3.6 as part of my work on the PEP 511).

Hum, it doesn't work: test_compile_ast() of test_compile fails without this code. The test relies (indirectly) on the fact that two code objects using a frozenset constant are equal.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 10:24:46 2016
From: report at bugs.python.org (Milan Zamazal)
Date: Fri, 22 Jan 2016 15:24:46 +0000
Subject: [issue26180] multiprocessing.util._afterfork_registry leak in
 threaded environment
Message-ID: <1453476286.88.0.329468896089.issue26180@psf.upfronthosting.co.za>


New submission from Milan Zamazal:

When calling multiprocessing.managers.BaseManager repeatedly from a client, each time from a new thread, new entry with (already existent) multiprocessing.util.ForkAwareLocal instance is inserted as a value into multiprocessing.util._afterfork_registry dictionary on each of the calls.  So the dictionary grows on each client call and may grow so indefinitely, causing memory leak if nothing else.

The attached file demonstrates the problem (Python 2.7 version, it's reproducible on 3.4 as well after 2->3 adjustments).  Just run it and look at the output.  The printed dictionary contains 10 entries holding the same ForkAwareLocal instance although there should be probably just one such entry there.

----------
components: Library (Lib)
files: bug.py
messages: 258816
nosy: mzamazal
priority: normal
severity: normal
status: open
title: multiprocessing.util._afterfork_registry leak in threaded environment
type: resource usage
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file41690/bug.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 10:51:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jan 2016 15:51:28 +0000
Subject: [issue25843] code_richcompare() don't use constant type when
 comparing code constants
In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za>
Message-ID: <20160122155123.64127.82311@psf.io>


Roundup Robot added the comment:

New changeset 9e13d97ceca2 by Victor Stinner in branch '2.7':
code_richcompare() now uses the constants types
https://hg.python.org/cpython/rev/9e13d97ceca2

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 10:54:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 15:54:05 +0000
Subject: [issue25843] code_richcompare() don't use constant type when
 comparing code constants
In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za>
Message-ID: <1453478045.29.0.955340115568.issue25843@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ok, the fix is now pushed to Python 2.7, 3.5 and 3.6.

Thanks Tijs Van Oevelen for your bug report ;-)

A workaround look to define the two lambda functions on two different lines. Or maybe cast explicitly to float? I don't think that it's a common bug so you should be able to survive with it until the next bugfix version is released :-)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 11:04:35 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 16:04:35 +0000
Subject: [issue24520] Stop using deprecated floating-point environment
 functions on FreeBSD
In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za>
Message-ID: <1453478675.66.0.00761343225268.issue24520@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> @koobs: sorry, 3.4 now only accept security fixes :-p

I wrote a table giving the status of each Python branch to know which ones still accept bugfixes or not:
https://docs.python.org/devguide/#status-of-python-branches

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 11:06:32 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 16:06:32 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
 mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1453478792.11.0.538527709096.issue4806@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +yselivanov

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 11:22:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 16:22:09 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>
Message-ID: <1453479729.48.0.404711469443.issue26058@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 5: a global counter is now used to set ma_version field of dictionaries. The global counter is incremented each time that a dictionary is created and each time that a dictionary is modified.

A dictionary version is now unique: two dictionaries cannot have the same version. So if a guard stores a version, the check on the version will fail if a different dictionary is used.

----------
Added file: http://bugs.python.org/file41691/dict_version-5.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 11:27:42 2016
From: report at bugs.python.org (=?utf-8?q?Gedai_Tam=C3=A1s_Bence?=)
Date: Fri, 22 Jan 2016 16:27:42 +0000
Subject: [issue21949] Document the Py_SIZE() macro.
In-Reply-To: <1404935084.68.0.420259951718.issue21949@psf.upfronthosting.co.za>
Message-ID: <1453480062.66.0.526994007171.issue21949@psf.upfronthosting.co.za>


Gedai Tam?s Bence added the comment:

Py_SIZE: https://docs.python.org/3.5/c-api/structures.html#c.Py_SIZE
PyList_New: https://docs.python.org/3.5/c-api/list.html#c.PyList_New

I think they're documented now, so I guess the issue can be closed.

----------
nosy: +beng94

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 11:33:22 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 16:33:22 +0000
Subject: [issue26145] PEP 511: Add sys.set_code_transformers()
In-Reply-To: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>
Message-ID: <1453480402.17.0.195570182702.issue26145@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Rebased patch.

----------
Added file: http://bugs.python.org/file41692/transformers-3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 11:35:32 2016
From: report at bugs.python.org (Alex)
Date: Fri, 22 Jan 2016 16:35:32 +0000
Subject: [issue26181] argparse can't handle positional argument after list
 (help message is wrong)
Message-ID: <1453480532.52.0.987369969347.issue26181@psf.upfronthosting.co.za>


New submission from Alex:

This code is meant to take a filename and a list of integers as arguments.  The filename is required, the integers are optional:

import argparse
parser = argparse.ArgumentParser()
parser.add_argument('filename')
parser.add_argument('-L', metavar='integer', type=int, nargs='+')
args = parser.parse_args()
print(args)  # see what we got

It produces the following help message:
usage: demo.py [-h] [-L integer [integer ...]] filename

However, the filename argument does not work if it's given in that position (after the list of ints).  Instead, it tries to use filename as another list element:

$ python demo.py -L 1 2 3 test.txt
usage: demo.py [-h] [-L integer [integer ...]] filename
demo.py: error: argument -L: invalid int value: 'test.txt'

Changing the order of the arguments works as intended:

$ python demo.py test.txt -L 1 2 3 
Namespace(L=[1, 2, 3], filename='test.txt')

Probably the simplest fix would be to amend the help message to show the positional argument before the list:

usage: demo.py [-h] filename [-L integer [integer ...]]

----------
components: Library (Lib)
messages: 258823
nosy: atpage
priority: normal
severity: normal
status: open
title: argparse can't handle positional argument after list (help message is wrong)
type: behavior
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 11:40:44 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 22 Jan 2016 16:40:44 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>
Message-ID: <1453480844.58.0.144269779353.issue26058@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Patch version 5: a global counter is now used to set ma_version field of dictionaries. The global counter is incremented each time that a dictionary is created and each time that a dictionary is modified.

This is great, thank you, Victor.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 11:43:52 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 22 Jan 2016 16:43:52 +0000
Subject: [issue21949] Document the Py_SIZE() macro.
In-Reply-To: <1404935084.68.0.420259951718.issue21949@psf.upfronthosting.co.za>
Message-ID: <1453481032.16.0.953542325.issue21949@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for triaging! The relevant commit is 760c5cfacbaa.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 11:45:21 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 16:45:21 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>
Message-ID: <1453481121.18.0.366446195005.issue26058@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> This is great, thank you, Victor.

I will update the PEP 509 later for the global counter.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 11:47:21 2016
From: report at bugs.python.org (Julien)
Date: Fri, 22 Jan 2016 16:47:21 +0000
Subject: [issue25907] Documentation i18n: Added trans tags in sphinx templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453481241.74.0.266807580335.issue25907@psf.upfronthosting.co.za>


Julien added the comment:

And here are the i18n tags for the sidebar, thanks @haypo it was a good idea to translate them too ^-^

----------
Added file: http://bugs.python.org/file41693/i18n-tags-in-sidebar.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 11:47:50 2016
From: report at bugs.python.org (Julien)
Date: Fri, 22 Jan 2016 16:47:50 +0000
Subject: [issue25907] Documentation i18n: Added trans tags in sphinx templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453481270.29.0.324929112409.issue25907@psf.upfronthosting.co.za>


Julien added the comment:

And tags for the layout template.

----------
Added file: http://bugs.python.org/file41694/i18n-tags-in-layout.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 11:48:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 16:48:10 +0000
Subject: [issue26145] PEP 511: Add sys.set_code_transformers()
In-Reply-To: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>
Message-ID: <1453481290.3.0.674522780231.issue26145@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 4: Fix sys_set_code_transformers(), initialize seq to NULL to fix a crash on error handling.

----------
Added file: http://bugs.python.org/file41695/transformers-4.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 12:01:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jan 2016 17:01:04 +0000
Subject: [issue25907] Documentation i18n: Added trans tags in sphinx templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <20160122170055.7348.87932@psf.io>


Roundup Robot added the comment:

New changeset b1615165fa4a by Victor Stinner in branch '3.5':
doc: i18n HTML templates
https://hg.python.org/cpython/rev/b1615165fa4a

New changeset 5af5b36c197e by Victor Stinner in branch 'default':
Merge 3.5 (i18n doc, issue #25907)
https://hg.python.org/cpython/rev/5af5b36c197e

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 12:02:17 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 17:02:17 +0000
Subject: [issue25907] Documentation i18n: Added trans tags in sphinx templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453482137.82.0.552521111199.issue25907@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I applied 3 patches to branches 3.5 and default (3.6), but the patches don't apply cleanly to Python 2.7.

Can you please cook patches for Python 2.7?

(I suggest to focus on translation of the Python 3 documentation, but for me, it's cheap to apply such patch to Python 2.7.)

----------
versions: +Python 2.7, Python 3.5, Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 12:04:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 17:04:57 +0000
Subject: [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>
Message-ID: <1453482297.67.0.512984726274.issue26163@psf.upfronthosting.co.za>


STINNER Victor added the comment:

as i expected, the bug disappeared. I'm not interested to investigate a random failure which only occurred once. I close the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 14:06:06 2016
From: report at bugs.python.org (Marco Buttu)
Date: Fri, 22 Jan 2016 19:06:06 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords
Message-ID: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>


New submission from Marco Buttu:

I saw that async and await will become keywords in Python 3.7 :

https://www.python.org/dev/peps/pep-0492/#deprecation-plans

I enabled the deprecation warnings in Python 3.5.1 and Python 3.6 dev, and I noticed that assigning to async or await does not issue any deprecation warning: 

$ python -Wd -c "import sys; print(sys.version); async = 33"
3.5.1 (default, Jan 21 2016, 19:59:28)
[GCC 4.8.4]

$ python -Wd -c "import sys; print(sys.version); async = 33"
3.6.0a0 (default:4b434a4770a9, Jan 12 2016, 13:01:29)
[GCC 4.8.4]

----------
components: Interpreter Core
messages: 258833
nosy: marco.buttu
priority: normal
severity: normal
status: open
title: Deprecation warnings for the future async and await keywords
type: enhancement
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 14:28:59 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 22 Jan 2016 19:28:59 +0000
Subject: [issue26140] inspect.iscoroutinefunction raises TypeError when checks
 Mock of function or coroutinefunction
In-Reply-To: <1453261574.88.0.59851332474.issue26140@psf.upfronthosting.co.za>
Message-ID: 


Guido van Rossum added the comment:

Am I really still needed on this issue?

On Tue, Jan 19, 2016 at 7:46 PM, Hiroyuki Takagi 
wrote:

>
> Hiroyuki Takagi added the comment:
>
> Thank you for reviewing patch.
>
> I wrote test and updated patch. To pass the test, both this patch and
> issue25599's patch are required.
>
> Changes of the patch:
> - copy __code__ not only functions but also methods
> - add autospec (create_autospec) suppoort
>
> I have completely missed about autospec, thank you for a mention about it.
> For autospec, simply copying original __code__ to funcopy makes error on
> existing tests.
> That's why I changed the src of exec, but it seems to be quite ad-hoc. It
> may be better to be improved, but I don't have any good idea, sorry.
>
> On the tests of this patch, I wonder if it's better to use assertIs(..,
> True/False) instead of assertTrue/False, since it was one of the problem in
> issue25599.
> To apply this change and pass test, need to change
> asyncio.iscoroutinefunction to return bool. The change would be very easy,
> just update issue25599's patch like `return_value = bool(getattr(func, ...`.
>
> ----------
> Added file: http://bugs.python.org/file41664/mock2.patch
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 15:43:48 2016
From: report at bugs.python.org (Thomas Levine)
Date: Fri, 22 Jan 2016 20:43:48 +0000
Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated
In-Reply-To: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za>
Message-ID: <1453495428.27.0.135540062927.issue20120@psf.upfronthosting.co.za>


Thomas Levine added the comment:

I noticed something else that might be interesting.
If I delete my .pypirc and have setuptools create it,

  python3.5 -c 'import setuptools; setuptools.setup()' register

the .pypirc is created with the un-escaped percent sign and without error.
I receive the error when I try to use the .pypirc next time.

If a different config parser is being used in the writing, perhaps we could at least use the same one in both places.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 16:05:11 2016
From: report at bugs.python.org (Roger Cook)
Date: Fri, 22 Jan 2016 21:05:11 +0000
Subject: [issue26183] 2.7.11 won't clean install on Windows 10 x64
Message-ID: <1453496711.72.0.869603030432.issue26183@psf.upfronthosting.co.za>


New submission from Roger Cook:

The Windows installer stops the installation and backs out on a clean system. Here is the relevant section of the log file (msiexec /i python-2.7.11.amd64.msi /l*v):

MSI (s) (14:90) [15:13:32:577]: Executing op: ActionStart(Name=RemovePip,,)
Action 15:13:32: RemovePip. 
MSI (s) (14:90) [15:13:32:578]: Executing op: CustomActionSchedule(Action=RemovePip,ActionType=3090,Source=C:\Python27\python.exe,Target=-B -m ensurepip._uninstall,)
MSI (s) (14:90) [15:13:32:579]: Note: 1: 1721 2: RemovePip 3: C:\Python27\python.exe 4: -B -m ensurepip._uninstall 
MSI (s) (14:90) [15:13:32:579]: Note: 1: 2262 2: Error 3: -2147287038 
Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: RemovePip, location: C:\Python27\python.exe, command: -B -m ensurepip._uninstall 
MSI (s) (14:90) [15:13:37:027]: Note: 1: 2262 2: Error 3: -2147287038 
MSI (s) (14:90) [15:13:37:027]: Product: Python 2.7.10 (64-bit) -- Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: RemovePip, location: C:\Python27\python.exe, command: -B -m ensurepip._uninstall 

Action ended 15:13:37: InstallFinalize. Return value 3.

--- end log ---

It appears that the installer tries to call the Python executable before it has been put in place. This fails, and the installer backs out.

Workaround: Install 2.7.10, then install 2.7.11 over it.

----------
components: Installation
messages: 258836
nosy: Roger Cook
priority: normal
severity: normal
status: open
title: 2.7.11 won't clean install on Windows 10 x64
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 16:17:59 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jan 2016 21:17:59 +0000
Subject: [issue21949] Document the Py_SIZE() macro.
In-Reply-To: <1404935084.68.0.420259951718.issue21949@psf.upfronthosting.co.za>
Message-ID: <20160122211755.3708.93042@psf.io>


Roundup Robot added the comment:

New changeset 63183596db79 by Gregory P. Smith in branch '2.7':
Per issue21949 and issue1629: Document the Py_SIZE, Py_TYPE, Py_REFCNT macros.
https://hg.python.org/cpython/rev/63183596db79

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 16:17:59 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jan 2016 21:17:59 +0000
Subject: [issue1629] Py_Size() should be named Py_SIZE()
In-Reply-To: <1197661541.29.0.0994895685418.issue1629@psf.upfronthosting.co.za>
Message-ID: <20160122211755.3708.63715@psf.io>


Roundup Robot added the comment:

New changeset 63183596db79 by Gregory P. Smith in branch '2.7':
Per issue21949 and issue1629: Document the Py_SIZE, Py_TYPE, Py_REFCNT macros.
https://hg.python.org/cpython/rev/63183596db79

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 16:18:28 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 22 Jan 2016 21:18:28 +0000
Subject: [issue21949] Document the Py_SIZE() macro.
In-Reply-To: <1404935084.68.0.420259951718.issue21949@psf.upfronthosting.co.za>
Message-ID: <1453497508.96.0.0897833407483.issue21949@psf.upfronthosting.co.za>


Changes by Gregory P. Smith :


----------
resolution: out of date -> fixed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 17:07:28 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 22 Jan 2016 22:07:28 +0000
Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated
In-Reply-To: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za>
Message-ID: <1453500448.89.0.668683712125.issue20120@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

Setuptools 19 has been out for over a month now with no adverse consequences. ?ukasz and David, as you both originally tagged this as won't fix, how would you feel about interpreting this as a defect and regression over Python 2.7 and fixing it it all Python 3 versions that receive bug fixes and bringing it into parity with Setuptools? If you give me the green light, I'll apply the patches.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 17:31:00 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Jan 2016 22:31:00 +0000
Subject: [issue26184] raise an error when create_module() is not defined by
 exec_module() is for loaders
Message-ID: <1453501860.77.0.669534801782.issue26184@psf.upfronthosting.co.za>


New submission from Brett Cannon:

As explained in https://docs.python.org/3/reference/import.html#loaders, as of Python 3.6 an error is to be raised when a loader defines exec_module() but not create_module(). Probably should raise a TypeError.

----------
components: Interpreter Core
messages: 258840
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: raise an error when create_module() is not defined by exec_module() is for loaders
type: behavior
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 17:38:36 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Jan 2016 22:38:36 +0000
Subject: [issue26169] Pasting 900000 chars into a tk Entry widget fails
In-Reply-To: <1453346436.13.0.197116211445.issue26169@psf.upfronthosting.co.za>
Message-ID: <1453502316.77.0.4823525279.issue26169@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I understand now what you were thinking. Even a timeout might not work for this because one could paste and within a second click Find-next and likely trigger the crash.

I tested printing, copying, and finding 'a'*10000 and it worked.  I think this is good enough, with probability 1.0, for any real use ;-).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 18:27:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jan 2016 23:27:05 +0000
Subject: [issue25791] Raise an ImportWarning when __spec__.parent/__package__
 isn't defined for a relative import
In-Reply-To: <1449175692.43.0.67090220632.issue25791@psf.upfronthosting.co.za>
Message-ID: <20160122232702.7364.50452@psf.io>


Roundup Robot added the comment:

New changeset 219c44fe8968 by Brett Cannon in branch 'default':
Issue #25791: Warn when __package__ != __spec__.parent.
https://hg.python.org/cpython/rev/219c44fe8968

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 18:27:30 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Jan 2016 23:27:30 +0000
Subject: [issue25791] Raise an ImportWarning when __spec__.parent/__package__
 isn't defined for a relative import
In-Reply-To: <1449175692.43.0.67090220632.issue25791@psf.upfronthosting.co.za>
Message-ID: <1453505250.17.0.762926722857.issue25791@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 18:28:21 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Jan 2016 23:28:21 +0000
Subject: [issue26177] tkinter: Canvas().keys returns empty strings.
In-Reply-To: <1453445489.52.0.0197706093826.issue26177@psf.upfronthosting.co.za>
Message-ID: <1453505301.39.0.216474479656.issue26177@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

With patch applied to 3.5, tk.Canvas().keys() works and test_tk and other three files pass with -ugui.

Is avoiding splitlist calls when not needed worthwhile?  Tests also pass with 

    def keys(self):
        """Return a list of all resource names of this widget."""
        config = self.tk.call(self._w, 'configure')
        if type(config) == tuple:
            return [x[0][1:] for x in config]
        else:  # str
            splitlist = self.tk.splitlist
            return [splitlist(x)[0][1:] for x in
                splitlist(config)]

I am a bit curious why Canvas gives a different return.  Is the special casing in _tkinter or tk itself?  Otherwise, looks good to me.

----------
stage: patch review -> commit review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 18:28:43 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Jan 2016 23:28:43 +0000
Subject: [issue21762] update the import machinery to only use __spec__
In-Reply-To: <1402781631.86.0.838758150876.issue21762@psf.upfronthosting.co.za>
Message-ID: <1453505323.78.0.310365629619.issue21762@psf.upfronthosting.co.za>


Brett Cannon added the comment:

__package__ != __spec__.parent now triggers an ImportWarning.

----------
dependencies: +Raise an ImportWarning when __spec__.parent/__package__ isn't defined for a relative import

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 18:30:17 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Jan 2016 23:30:17 +0000
Subject: [issue21762] update the import machinery to only use __spec__
In-Reply-To: <1402781631.86.0.838758150876.issue21762@psf.upfronthosting.co.za>
Message-ID: <1453505417.75.0.366555091817.issue21762@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I think that leaves the following attributes to be updated/checked for dependencies in importlib (and if they are found, raise ImportWarning when they differ):

1. __path__
2. __loader__
3. __file__
4. __cached__

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 18:30:38 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Jan 2016 23:30:38 +0000
Subject: [issue26095] Update porting HOWTO to special-case Python 2 code,
 not Python 3
In-Reply-To: <1452651397.71.0.110404454924.issue26095@psf.upfronthosting.co.za>
Message-ID: <1453505438.8.0.151802691052.issue26095@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
assignee: docs at python -> brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 18:51:29 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Jan 2016 23:51:29 +0000
Subject: [issue26128] Let the subprocess.STARTUPINFO constructor take arguments
In-Reply-To: <1452887119.07.0.716350004713.issue26128@psf.upfronthosting.co.za>
Message-ID: <1453506689.18.0.0633194965447.issue26128@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

STARTUPINFO is a class whose instances have 5 attributes.  Being able to set attributes on creation is pretty normal.  If one can optionally be set in __init__, same should be true for all.  I would recommend that params be keyword-only.

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 18:52:37 2016
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 22 Jan 2016 23:52:37 +0000
Subject: [issue26128] Let the subprocess.STARTUPINFO constructor take arguments
In-Reply-To: <1452887119.07.0.716350004713.issue26128@psf.upfronthosting.co.za>
Message-ID: <1453506757.53.0.624649268624.issue26128@psf.upfronthosting.co.za>


Ram Rachum added the comment:

Agreed on keywords-only.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 18:56:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jan 2016 23:56:04 +0000
Subject: [issue25234] test_eintr.test_os_open hangs under Xcode 7
In-Reply-To: <1443210079.4.0.780575467942.issue25234@psf.upfronthosting.co.za>
Message-ID: <20160122235601.3706.28870@psf.io>


Roundup Robot added the comment:

New changeset 9d65a195246b by Brett Cannon in branch 'default':
Issue #25234: Skip test_eintr.test_open() under OS X to avoid hanging
https://hg.python.org/cpython/rev/9d65a195246b

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 18:56:16 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Jan 2016 23:56:16 +0000
Subject: [issue25234] test_eintr.test_os_open hangs under Xcode 7
In-Reply-To: <1443210079.4.0.780575467942.issue25234@psf.upfronthosting.co.za>
Message-ID: <1453506976.18.0.292669095847.issue25234@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 19:12:31 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Jan 2016 00:12:31 +0000
Subject: [issue26149] Suggest PyCharm Community as an editor for Unix platforms
In-Reply-To: <1453153728.95.0.733172914649.issue26149@psf.upfronthosting.co.za>
Message-ID: <1453507951.11.0.731632229294.issue26149@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Berker, I agree with you.  The doc section is woefully incomplete and unix-specific.  It probably dates back to when Python only ran on unix.

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 19:27:10 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Jan 2016 00:27:10 +0000
Subject: [issue26180] multiprocessing.util._afterfork_registry leak in
 threaded environment
In-Reply-To: <1453476286.88.0.329468896089.issue26180@psf.upfronthosting.co.za>
Message-ID: <1453508830.91.0.156287082115.issue26180@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Please post your 3.x version.  3.4 only gets security patches now.

----------
nosy: +terry.reedy
versions: +Python 3.5, Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 19:39:12 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jan 2016 00:39:12 +0000
Subject: [issue18018] SystemError: Parent module '' not loaded,
 cannot perform relative import
In-Reply-To: <1369011708.43.0.213176616662.issue18018@psf.upfronthosting.co.za>
Message-ID: <20160123003908.122731.5092@psf.io>


Roundup Robot added the comment:

New changeset c4e4886c6052 by Brett Cannon in branch 'default':
Issue #18018: Raise an ImportError if a relative import is attempted
https://hg.python.org/cpython/rev/c4e4886c6052

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 19:41:33 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 23 Jan 2016 00:41:33 +0000
Subject: [issue18018] SystemError: Parent module '' not loaded,
 cannot perform relative import
In-Reply-To: <1369011708.43.0.213176616662.issue18018@psf.upfronthosting.co.za>
Message-ID: <1453509693.69.0.262967404631.issue18018@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks to everyone for providing feedback. I went with ImportError in the end as that's what the pure Python implementation of __import__() already raised.

----------
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 00:44:35 2016
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 23 Jan 2016 05:44:35 +0000
Subject: [issue25934] ICC compiler: ICC treats denormal floating point numbers
 as 0.0
In-Reply-To: <1450911743.93.0.393041043786.issue25934@psf.upfronthosting.co.za>
Message-ID: <1453527875.55.0.00870480341831.issue25934@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Here's a patch that specifies /fp:strict if it looks like ICC is being used for the build.  It also adds a convenient property for checking whether it's an ICC build ($(ICCBuild)).  This doesn't change anything for MSVC builds but allows ICC builds to pass test_math, test_cmath, test_audioop, etc.; as such, it should be applied to all three branches.

As far as replacing the non-constants that MSVC doesn't like, I'm +1 but not too bothered about it.  I'm happy to test if anyone supplies a patch for it.

----------
keywords: +patch
versions: +Python 2.7
Added file: http://bugs.python.org/file41696/issue25934.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 03:17:37 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Jan 2016 08:17:37 +0000
Subject: [issue26149] Suggest PyCharm Community as an editor for Unix platforms
In-Reply-To: <1453153728.95.0.733172914649.issue26149@psf.upfronthosting.co.za>
Message-ID: <1453537056.99.0.786529222958.issue26149@psf.upfronthosting.co.za>


Georg Brandl added the comment:

> The doc section is woefully incomplete and unix-specific.

That might be because the doc section is called "Using Python on Unix platforms".

----------
nosy: +georg.brandl

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 03:27:34 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Jan 2016 08:27:34 +0000
Subject: [issue26149] Suggest PyCharm Community as an editor for Unix platforms
In-Reply-To: <1453153728.95.0.733172914649.issue26149@psf.upfronthosting.co.za>
Message-ID: <1453537654.75.0.163669200338.issue26149@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The two links for VIM and Emacs are useful for Unix developers that happen to use these editors, but I agree that we should link to the wiki instead of having other links to specific editors.
If we want to recommend a few specific ones, we could list their names so that people can find them in the wiki.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 04:33:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Jan 2016 09:33:44 +0000
Subject: [issue26177] tkinter: Canvas().keys returns empty strings.
In-Reply-To: <1453445489.52.0.0197706093826.issue26177@psf.upfronthosting.co.za>
Message-ID: <1453541624.5.0.288850745584.issue26177@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Is avoiding splitlist calls when not needed worthwhile?

We can't guarantee that future release of Tk wouldn't return a list of strings. Calling splitlist() for a tuple is cheap (but looks cumbersome).

> I am a bit curious why Canvas gives a different return.  Is the special casing in _tkinter or tk itself?

Tk is full of such inconsistencies. A result for one widget can be a list of numbers, but for other it is a list of strings or a list of special Tcl objects. One method can return empty list, other returns empty string. One widgets truncate floating point parameters, others round them up or down.

I'll commit the patch after testing with Tk 8.5 and 8.4.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 05:00:11 2016
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 23 Jan 2016 10:00:11 +0000
Subject: [issue25907] Documentation i18n: Added trans tags in sphinx templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453543211.05.0.542453998702.issue25907@psf.upfronthosting.co.za>


INADA Naoki added the comment:

O/T

Hi, Julien.

I'm maintainer of Python Document Japanese translation project.  (http://docs.python.jp/ )
We use Transifex to ease many volunteers working on translating.

https://www.transifex.com/python-doc-ja/python-35/dashboard/

Repository of Python 3.5 Japanese document is here: https://github.com/python-doc-ja/cpython-doc-intl

----------
nosy: +naoki

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 05:12:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Jan 2016 10:12:50 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>
Message-ID: <1453543970.56.0.0835293660213.issue19883@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch addresses Victor's comments and adds (mandatory now) parenthesis. Thank you Victor.

----------
assignee:  -> serhiy.storchaka
Added file: http://bugs.python.org/file41697/zipimport_int_overflow_4.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 05:41:53 2016
From: report at bugs.python.org (Matthew Zipay)
Date: Sat, 23 Jan 2016 10:41:53 +0000
Subject: [issue26185] zipfile.ZipInfo slots can raise unexpected AttributeError
Message-ID: <1453545713.56.0.930101536202.issue26185@psf.upfronthosting.co.za>


New submission from Matthew Zipay:

The zipfile.ZipInfo.__init__ method permits several of ZipInfo's slot attributes to go uninitialized unless the object is obtained from ZipFile.getinfo() or ZipFile.infolist().

As a result, accessing those attributes (header_offset, CRC, compress_size, or file_size) or attempting to repr() a ZipInfo object can fail unexpectedly with AttributeError. (I say "unexpectedly" because ZipInfo.__init__ and its attributes are public/documented, so the attributes ought to be properly initialized regardless of how the object gets created.)

A simple test to illustrate:

>>> import zipfile
>>> zinfo = zipfile.ZipInfo()
>>> repr(zinfo)
Traceback (most recent call last):
  File "", line 1, in 
  File "********/cpython/Lib/zipfile.py", line 376, in __repr__
    result.append(' file_size=%r' % self.file_size)
AttributeError: file_size

(If you assign zinfo.file_size = None, it next fails on compress_size.)

This problem has been noted before - see issues 3039 and 22217 - but has not been resolved.

Patch including tests is attached.

----------
components: Library (Lib)
files: zipfile.ZipInfo.patch
keywords: patch
messages: 258859
nosy: Matthew Zipay
priority: normal
severity: normal
status: open
title: zipfile.ZipInfo slots can raise unexpected AttributeError
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41698/zipfile.ZipInfo.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 06:12:00 2016
From: report at bugs.python.org (Julien)
Date: Sat, 23 Jan 2016 11:12:00 +0000
Subject: [issue25907] Documentation i18n: Added trans tags in sphinx templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453547520.32.0.709479142127.issue25907@psf.upfronthosting.co.za>


Julien added the comment:

@haypo: And here is the patch for 2.7, and here is the result of the patch applied and new msgids translated: http://www.afpy.org/doc/python/2.7/

----------
Added file: http://bugs.python.org/file41699/trans-tags-in-2.7.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 06:22:46 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 23 Jan 2016 11:22:46 +0000
Subject: [issue26185] zipfile.ZipInfo slots can raise unexpected AttributeError
In-Reply-To: <1453545713.56.0.930101536202.issue26185@psf.upfronthosting.co.za>
Message-ID: <1453548166.27.0.86416549692.issue26185@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +alanmcintyre, serhiy.storchaka, twouters

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 06:23:01 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 23 Jan 2016 11:23:01 +0000
Subject: [issue26185] zipfile.ZipInfo slots can raise unexpected AttributeError
In-Reply-To: <1453545713.56.0.930101536202.issue26185@psf.upfronthosting.co.za>
Message-ID: <1453548181.05.0.040164855001.issue26185@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
stage:  -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 06:23:31 2016
From: report at bugs.python.org (Julien)
Date: Sat, 23 Jan 2016 11:23:31 +0000
Subject: [issue25907] Documentation i18n: Added trans tags in sphinx templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453548211.03.0.6084600295.issue25907@psf.upfronthosting.co.za>


Julien added the comment:

@naoki Not sure, but with those patches you'll may be able to translate the documentation without forking it. Like we're doing here: https://github.com/afpy/python_doc_fr

Also did you contacted the upstream to ask them if they want to cross-link your versions ? Sphinx don't natively support it, but it still doable and can be a nice way to advertise our efforts (I mean, I'm sure a lot of french people don't know we're doing it and stuck to the english version).

I heard we used transfiex too like 6 years ago, long before me being on the project, I may drop an eye on it, thanks.

It may be a bit out of the scope of this issue, so let's continue elsewhere, like by email if you want I'm julien at palard dot fr.

BTW, nice to hear we're not alone to translate the Python doc :-))).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 06:23:34 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 23 Jan 2016 11:23:34 +0000
Subject: [issue26183] 2.7.11 won't clean install on Windows 10 x64
In-Reply-To: <1453496711.72.0.869603030432.issue26183@psf.upfronthosting.co.za>
Message-ID: <1453548214.63.0.842655953391.issue26183@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 06:25:34 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 23 Jan 2016 11:25:34 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1453548334.78.0.283362441704.issue26182@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
components: +asyncio
nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 06:28:20 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 23 Jan 2016 11:28:20 +0000
Subject: [issue26181] argparse can't handle positional argument after list
 (help message is wrong)
In-Reply-To: <1453480532.52.0.987369969347.issue26181@psf.upfronthosting.co.za>
Message-ID: <1453548500.47.0.154203542177.issue26181@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +bethard
versions: +Python 3.5, Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 06:54:04 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Jan 2016 11:54:04 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1453543970.56.0.0835293660213.issue19883@psf.upfronthosting.co.za>
Message-ID: 


STINNER Victor added the comment:

Serhiy Storchaka added the comment:
> Updated patch addresses Victor's comments and adds (mandatory now) parenthesis. Thank you Victor.

Do  you mean braces {...}?

The new patch looks good to me, thanks for taking all my comments in account ;-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 06:55:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jan 2016 11:55:34 +0000
Subject: [issue25907] Documentation i18n: Added trans tags in sphinx templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <20160123115531.65051.40042@psf.io>


Roundup Robot added the comment:

New changeset 72edb81e456b by Victor Stinner in branch '2.7':
doc: i18n HTML templates
https://hg.python.org/cpython/rev/72edb81e456b

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 06:57:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Jan 2016 11:57:15 +0000
Subject: [issue25907] Documentation i18n: Added trans tags in sphinx templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453550235.69.0.440513344734.issue25907@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> @haypo: And here is the patch for 2.7, and here is the result of the patch applied and new msgids translated: http://www.afpy.org/doc/python/2.7/

Thanks. I also pushed this change.

@INADA Naoki, @Julien: Don't hesitate to bug me if you want to push other changes to make your work easier.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 07:04:34 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Jan 2016 12:04:34 +0000
Subject: [issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit
 constants
In-Reply-To: <1453136691.51.0.69393755181.issue26146@psf.upfronthosting.co.za>
Message-ID: <1453550674.53.0.50789892508.issue26146@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@Serhiy: Would you mind reviewing constant-2.patch? I reviewed my own patch and added some comments, I found a refleak ;-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 07:11:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Jan 2016 12:11:43 +0000
Subject: [issue26145] PEP 511: Add sys.set_code_transformers()
In-Reply-To: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>
Message-ID: <1453551103.07.0.51658275564.issue26145@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Note: ast.PyCF_TRANSFORMED_AST is not implemented yet.

Additionnal pycf_transformed_ast.patch implements it. The patch should be applied on top of transformers-4.patch.

Note: PyCF_TRANSFORMED_AST has the same value (0x1000) than the old constant CO_GENERATOR_ALLOWED. This constant was removed in Python 2.5.0 by the changeset 6b42920accc9 in 2006. Is it an issue?

----------
Added file: http://bugs.python.org/file41700/pycf_transformed_ast.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 07:50:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Jan 2016 12:50:13 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>
Message-ID: <1453553413.8.0.505831476939.issue26058@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 6: remove now unused function _testcapi.dict_set_version(). I also moved tests to test_pep509.py to make it more explicit that the implementation of the PEP 509 is not part the Python dictionary type specification, other Python implementations can choose to not implement it.

----------
Added file: http://bugs.python.org/file41701/dict_version-6.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 08:02:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Jan 2016 13:02:15 +0000
Subject: [issue26098] PEP 510: Specialize functions with guards
In-Reply-To: <1452689568.12.0.253530674137.issue26098@psf.upfronthosting.co.za>
Message-ID: <1453554135.57.0.468403977593.issue26098@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 4:

* Keywords are now supported everywhere and tested by unit tests
* Inline specode_check() into PyFunction_GetSpecializedCode()

----------
Added file: http://bugs.python.org/file41702/specialize-4.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 08:16:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jan 2016 13:16:47 +0000
Subject: [issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit
 constants
In-Reply-To: <1453136691.51.0.69393755181.issue26146@psf.upfronthosting.co.za>
Message-ID: <20160123131644.548.763@psf.io>


Roundup Robot added the comment:

New changeset 5de1bd759f3b by Victor Stinner in branch 'default':
Issue #26146: marshal.loads() now uses the empty frozenset singleton
https://hg.python.org/cpython/rev/5de1bd759f3b

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 08:18:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Jan 2016 13:18:33 +0000
Subject: [issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit
 constants
In-Reply-To: <1453136691.51.0.69393755181.issue26146@psf.upfronthosting.co.za>
Message-ID: <1453555113.52.0.199808700672.issue26146@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> New changeset 5de1bd759f3b by Victor Stinner in branch 'default':
> Issue #26146: marshal.loads() now uses the empty frozenset singleton
> https://hg.python.org/cpython/rev/5de1bd759f3b

This change is not directly related to this issue.

It's required by test_singleton_empty_frozenset() of test_set when an AST transformer replaces frozenset(), frozenset([]), etc. calls with an empty frozenset constant.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 11:00:13 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 23 Jan 2016 16:00:13 +0000
Subject: [issue26183] 2.7.11 won't clean install on Windows 10 x64
In-Reply-To: <1453496711.72.0.869603030432.issue26183@psf.upfronthosting.co.za>
Message-ID: <1453564813.84.0.354994704822.issue26183@psf.upfronthosting.co.za>


Steve Dower added the comment:

This is trying to remove 2.7.10, so I guess it's not as clean as you think.

You'll need to repair the 2.7.10 install (not just reinstall it - it has to be the right version so you can choose repair) and then try again.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 12:17:09 2016
From: report at bugs.python.org (Soufiane BOUSSALI)
Date: Sat, 23 Jan 2016 17:17:09 +0000
Subject: [issue26169] Pasting 900000 chars into a tk Entry widget fails
In-Reply-To: <1453346436.13.0.197116211445.issue26169@psf.upfronthosting.co.za>
Message-ID: <1453569429.8.0.138258852808.issue26169@psf.upfronthosting.co.za>


Soufiane BOUSSALI added the comment:

thanks terry reedy For Fixing This Stack Overflow :)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 14:28:00 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 23 Jan 2016 19:28:00 +0000
Subject: [issue26186] LazyLoader rejecting use of SourceFileLoader
Message-ID: <1453577280.26.0.226746274701.issue26186@psf.upfronthosting.co.za>


New submission from Brett Cannon:

It was privately reported to me that importlib.util.LazyLoader rejects using importlib.machinery.SourceFileLoader (or at least _frozen_importlib.SourceFileLoader). At least a test should be added for LazyLoader to make sure it will happily accept importlib.machinery.SourceFileLoader, and if it rejects the one from _frozen_importlib, tweak the test to accept loaders from there as well.

----------
assignee: brett.cannon
components: Library (Lib)
messages: 258873
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: LazyLoader rejecting use of SourceFileLoader
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 14:34:32 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 23 Jan 2016 19:34:32 +0000
Subject: [issue26187] sqlite3 trace callback prints duplicate line
Message-ID: <1453577672.38.0.77226221379.issue26187@psf.upfronthosting.co.za>


New submission from Aviv Palivoda:

I am running the following script:

------------------------------------------
>>> import sqlite3
>>> import os
>>> import time
>>> con1 = sqlite3.connect("/tmp/test.db")
>>> con2 = sqlite3.connect("/tmp/test.db")
>>> con1.set_trace_callback(print)
>>> cur = con1.cursor()
>>> cur.execute("create table test(a)")
create table test(a)

>>> con2.execute("create table test2(a)")

>>> cur.execute("insert into test(a) values(1)")
BEGIN 
insert into test(a) values(1)
insert into test(a) values(1)

>>> for a in con1.execute("select * from test"):
...     print("result:", a)
... 
select * from test
result: (1,)
-------------------------------------------

As you can see i get duplicate traceback print of the "insert into test(a) values(1)" line. The duplicate print has no effect on the actual db.

I have tested this both on python 3.4.3 and 3.6.0a0 on ubuntu14.04

----------
components: Extension Modules
messages: 258874
nosy: ghaering, palaviv
priority: normal
severity: normal
status: open
title: sqlite3 trace callback prints duplicate line
type: behavior
versions: Python 3.4, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 14:38:47 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 23 Jan 2016 19:38:47 +0000
Subject: [issue26186] LazyLoader rejecting use of SourceFileLoader
In-Reply-To: <1453577280.26.0.226746274701.issue26186@psf.upfronthosting.co.za>
Message-ID: <1453577927.7.0.118269862918.issue26186@psf.upfronthosting.co.za>


Brett Cannon added the comment:

One way to possibly improve this is to remove the create_module() check and replace it with a warning if create_module() doesn't return None. Another option is to use an assert statement. The final option is to just drop the check entirely, although that can make debugging difficult.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 14:38:58 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 23 Jan 2016 19:38:58 +0000
Subject: [issue26186] LazyLoader rejecting use of SourceFileLoader
In-Reply-To: <1453577280.26.0.226746274701.issue26186@psf.upfronthosting.co.za>
Message-ID: <1453577938.39.0.402141526326.issue26186@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
nosy: +eric.snow, ncoghlan

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 17:08:55 2016
From: report at bugs.python.org (Blaize Rhodes)
Date: Sat, 23 Jan 2016 22:08:55 +0000
Subject: [issue26074] Add a method to pip.. pip.require("package_name")
In-Reply-To: <1452423120.4.0.471254538905.issue26074@psf.upfronthosting.co.za>
Message-ID: <1453586935.52.0.993714540538.issue26074@psf.upfronthosting.co.za>


Blaize Rhodes added the comment:

Righto.. will talk to the pip dudes.  Thanks for your time.  

(@matrixise The reason I posted this here is because pip is included as part of the cpython distribution.  None of the documentation I've seen suggests that this isn't a forum for discussing the std python libs, and indeed there seem to be many enhancement requests for python libs in this bug db.  It seems that pip has some special status as included as part of the std python distribution but not part of the std libs.  I would have thought that it was obvious from the context that I was unaware of this fact at the time I posted the request.  Does that answer your question?  What's with the attitude?  You've never made a mistake I take it?).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 17:18:31 2016
From: report at bugs.python.org (Thomas Nyberg)
Date: Sat, 23 Jan 2016 22:18:31 +0000
Subject: [issue23076] list(pathlib.Path().glob("")) fails with IndexError
In-Reply-To: <1418860780.4.0.558535328721.issue23076@psf.upfronthosting.co.za>
Message-ID: <1453587511.3.0.218335438132.issue23076@psf.upfronthosting.co.za>


Thomas Nyberg added the comment:

I added a patch which causes glob to raise a ValueError exception if it is called with an empty string. I also added a test verifying the change and have run all the tests and they pass.

Though I've been reading the developer guide, I'm a bit unfamiliar with the process here so I'm not totally sure I'm doing this right. I created the patch relative to the current default branch (even though the discussion here seems to indicate it should maybe be applied going back a few versions).

----------
hgrepos: +331
keywords: +patch
nosy: +thomas.nyberg
Added file: http://bugs.python.org/file41703/pathlib_glob.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 17:41:09 2016
From: report at bugs.python.org (Keith Dart)
Date: Sat, 23 Jan 2016 22:41:09 +0000
Subject: [issue26186] LazyLoader rejecting use of SourceFileLoader
In-Reply-To: <1453577280.26.0.226746274701.issue26186@psf.upfronthosting.co.za>
Message-ID: <1453588869.14.0.785756899333.issue26186@psf.upfronthosting.co.za>


Changes by Keith Dart :


----------
nosy: +kdart

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 19:45:27 2016
From: report at bugs.python.org (Kevin Norris)
Date: Sun, 24 Jan 2016 00:45:27 +0000
Subject: [issue26160] Tutorial incorrectly claims that (explicit) relative
 imports don't work in the main module
In-Reply-To: <1453273352.49.0.425335373136.issue26160@psf.upfronthosting.co.za>
Message-ID: <1453596327.77.0.270797600669.issue26160@psf.upfronthosting.co.za>


Kevin Norris added the comment:

>It could be misleading saying ?the name of the current package?, because the import could be relative to the a higher level parent package if more than one dot is specified.

While this is correct, Python still uses __package__ to determine what to import in that case.  I simply replaced "__package__" with "the name of the current package" to make it easier to read, much as the original text replaces "__name__" with "the name of the current module."

>Then point out that relative imports won?t work with ``python file.py`` or interactive mode, but don?t mention ?-m? (or the other ways to run scripts and modules).

SGTM if you can find a reasonable way of phrasing that.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 21:06:03 2016
From: report at bugs.python.org (Nicholas Chammas)
Date: Sun, 24 Jan 2016 02:06:03 +0000
Subject: [issue26188] Provide more helpful error message when `await` is
 called inside non-`async` method
Message-ID: <1453601163.58.0.356009781594.issue26188@psf.upfronthosting.co.za>


New submission from Nicholas Chammas:

Here is the user interaction:

```python
$ python3
Python 3.5.1 (default, Dec  7 2015, 21:59:10) 
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.1.76)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def oh_hai():
...     await something()
  File "", line 2
    await something()
                  ^
SyntaxError: invalid syntax
```

It would be helpful if Python could tell the user something more specific about _why_ the syntax is invalid. Is that possible?

For example, in the case above, an error message along the following lines would be much more helpful:

```
SyntaxError: Cannot call `await` inside non-`async` method.
```

Without a hint like this, it's too easy to miss the obvious and waste time eye-balling the code, like I did. :-)

----------
components: Interpreter Core
messages: 258879
nosy: Nicholas Chammas
priority: normal
severity: normal
status: open
title: Provide more helpful error message when `await` is called inside non-`async` method
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 21:29:03 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sun, 24 Jan 2016 02:29:03 +0000
Subject: [issue26189] Non-interactive interpreter returns control to cmd.exe
 early
Message-ID: <1453602542.98.0.731550634512.issue26189@psf.upfronthosting.co.za>


New submission from Ivan Pozdeev:

When running python.exe from windows console non-interactively, cmd.exe prompt appears immediately after starting:

C:\>python -c "import time; time.sleep(2); print 'bla-bla-bla'"

C:\>bla-bla-bla


Not only this prevents from cmd to setting ERRORLEVEL to the return code, this makes it impossible to run scripts that expect input from console because Python and cmd get input lines in turns (I typed both inputs 2 times in the following example):

C:\>python -c "s=raw_input('1st:'); print s; s=raw_input('2nd:'); print s"

C:\>1st:abcdef
'abcdef' is not recognized as an internal or external command,
operable program or batch file.

C:\>abcdef
abcdef
2nd:123456
'123456' is not recognized as an internal or external command,
operable program or batch file.

C:\>123456
123456


----------
components: IO
messages: 258880
nosy: Ivan.Pozdeev
priority: normal
severity: normal
status: open
title: Non-interactive interpreter returns control to cmd.exe early
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 21:53:57 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sun, 24 Jan 2016 02:53:57 +0000
Subject: [issue26189] Interpreter returns control to cmd.exe early
In-Reply-To: <1453602542.98.0.731550634512.issue26189@psf.upfronthosting.co.za>
Message-ID: <1453604037.73.0.31912896419.issue26189@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

This also happens when running interactively - so the interactive interpreter has to be run from a non-console program to be usable.

This doesn't happen with other programs (e.g. Cygwin bash) or IPython console.

----------
title: Non-interactive interpreter returns control to cmd.exe early -> Interpreter returns control to cmd.exe early

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 21:56:24 2016
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 24 Jan 2016 02:56:24 +0000
Subject: [issue26189] Interpreter returns control to cmd.exe early
In-Reply-To: <1453602542.98.0.731550634512.issue26189@psf.upfronthosting.co.za>
Message-ID: <1453604184.18.0.674200100641.issue26189@psf.upfronthosting.co.za>


Zachary Ware added the comment:

What version of Python are you using, where did you get it from, and what version of Windows are you using?

----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 22:43:27 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sun, 24 Jan 2016 03:43:27 +0000
Subject: [issue26189] Interpreter returns control to cmd.exe early
In-Reply-To: <1453602542.98.0.731550634512.issue26189@psf.upfronthosting.co.za>
Message-ID: <1453607007.79.0.0329347507584.issue26189@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 20:40:30) [MSC v.1500 64 bit (AMD64)] on win32
WinXP x64 SP2

I also tested with PowerShell 1.0. Python opens another window, but the shell's prompt also shows up immediately.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 23:15:23 2016
From: report at bugs.python.org (Steve Dower)
Date: Sun, 24 Jan 2016 04:15:23 +0000
Subject: [issue26189] Interpreter returns control to cmd.exe early
In-Reply-To: <1453602542.98.0.731550634512.issue26189@psf.upfronthosting.co.za>
Message-ID: <1453608923.74.0.7013849287.issue26189@psf.upfronthosting.co.za>


Steve Dower added the comment:

That'd suggest a change in the link options since 2.7.10, probably SUBSYSTEM. Or possibly there's a config option that prevents allocating a console correctly on startup.

FWIW, I don't think WinXP 64-bit was ever considered trustworthy, so it may be a bug in the OS that never got fixed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 24 01:43:02 2016
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 24 Jan 2016 06:43:02 +0000
Subject: [issue26189] Interpreter returns control to cmd.exe early
In-Reply-To: <1453602542.98.0.731550634512.issue26189@psf.upfronthosting.co.za>
Message-ID: <1453617782.52.0.480349219819.issue26189@psf.upfronthosting.co.za>


Eryk Sun added the comment:

Try forcing cmd to wait using the "start" command:

    C:\>start /b /w python -c "raise SystemExit(42)"
    C:\>echo %errorlevel%
    42

----------
nosy: +eryksun

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 24 04:53:35 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 24 Jan 2016 09:53:35 +0000
Subject: [issue26188] Provide more helpful error message when `await` is
 called inside non-`async` method
In-Reply-To: <1453601163.58.0.356009781594.issue26188@psf.upfronthosting.co.za>
Message-ID: <1453629215.35.0.0916174852287.issue26188@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
components: +asyncio
nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 24 05:06:39 2016
From: report at bugs.python.org (aditya gupta)
Date: Sun, 24 Jan 2016 10:06:39 +0000
Subject: [issue26188] Provide more helpful error message when `await` is
 called inside non-`async` method
In-Reply-To: <1453601163.58.0.356009781594.issue26188@psf.upfronthosting.co.za>
Message-ID: <1453629999.27.0.749491462708.issue26188@psf.upfronthosting.co.za>


Changes by aditya gupta :


----------
nosy: +aditya gupta

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 24 05:42:56 2016
From: report at bugs.python.org (=?utf-8?q?Maximilian_K=C3=B6hl?=)
Date: Sun, 24 Jan 2016 10:42:56 +0000
Subject: [issue26190] GC memory leak using weak and cyclic references
Message-ID: <1453632176.06.0.994495814039.issue26190@psf.upfronthosting.co.za>


New submission from Maximilian K?hl:

In the attached code the object initially bind to `a` is never garbage collected although there are no references left. The finalizer of `b` is executed and the weak reference to it becomes dead however the garbage collector does not free the object itself and it could be resurrected with `gc.get_objects()`.

Output:
gc: collecting generation 2...
gc: objects in each generation: 27 0 5795
gc: collectable 
gc: collectable 
finalize: b <__main__.A object at 0x7f158796acc0>
gc: done, 3 unreachable, 0 uncollectable, 0.0005s elapsed
gc: collecting generation 2...
gc: objects in each generation: 1 0 5812
gc: done, 0.0005s elapsed
gc: collecting generation 2...
gc: objects in each generation: 1 0 5812
gc: done, 0.0005s elapsed
[...]

----------
components: Interpreter Core
files: gc_test_code.py
messages: 258886
nosy: koehlma
priority: normal
severity: normal
status: open
title: GC memory leak using weak and cyclic references
type: resource usage
versions: Python 3.5
Added file: http://bugs.python.org/file41704/gc_test_code.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 24 06:14:20 2016
From: report at bugs.python.org (=?utf-8?q?Maximilian_K=C3=B6hl?=)
Date: Sun, 24 Jan 2016 11:14:20 +0000
Subject: [issue26190] GC memory leak using weak and cyclic references
In-Reply-To: <1453632176.06.0.994495814039.issue26190@psf.upfronthosting.co.za>
Message-ID: <1453634060.53.0.715888853367.issue26190@psf.upfronthosting.co.za>


Changes by Maximilian K?hl :


----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 24 10:05:08 2016
From: report at bugs.python.org (Anders Rundgren)
Date: Sun, 24 Jan 2016 15:05:08 +0000
Subject: [issue26191] pip on Windows doesn't honor Case
Message-ID: <1453647908.67.0.442004366007.issue26191@psf.upfronthosting.co.za>


New submission from Anders Rundgren:

pip install Crypto

Terminates correctly and the package is there as well.
Unfortunately the directory is named "crypto" rather than "Crypto" so when I perform

>>>import Crypto

the interpreter fails.

>>>import crypto 

seems to work but is incompatible over platforms.

If this is a problem with pycrypto or pip is beyond my knowledge of python.

----------
components: Installation
messages: 258887
nosy: anders.rundgren.net at gmail.com
priority: normal
severity: normal
status: open
title: pip on Windows doesn't honor Case
type: compile error
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 24 10:49:57 2016
From: report at bugs.python.org (=?utf-8?q?=C6=A6OB_COASTN?=)
Date: Sun, 24 Jan 2016 15:49:57 +0000
Subject: [issue26192] python3 k1om dissociation permanence: libffi
Message-ID: <1453650595.09.0.833212655161.issue26192@psf.upfronthosting.co.za>


New submission from ?OB COASTN:

initial patch attached for Python-3.4.4
This patch requires rework.

I am willing to implement the __MIC__ or __KNC__ into a new patch if this is in fact the route forward that seems optimal.

Thanks,
Rob


> Enabling the build system for Intel MIC k1om is non-trivial using
> Python-3.4.4
> Using Python2 for the k1om is very popular, but I require Python3
> support on k1om.
>
> The first requirement to complete this build involved the download and
> extraction of pre-built MPSS RPM's.
> Then built required host python bins using GCC.
> Lastly, build MIC bins using ICC.
> The exacts are appended to the end of this message.
>
> I would like to discuss a few change requirements that trial and error
> has revealed.
>
> 1.) libffi requires the University OF Cantabria patch because the k1om
> is not binary compatible with x86_64. [attached]
>
> These libffi changes could be implemented using the __MIC__ or __KNC__
> macros.
> *see https://software.intel.com/en-us/node/514528

----------
files: 0001-k1om-libffi.patch
keywords: patch
messages: 258888
nosy: ?OB COASTN
priority: normal
severity: normal
status: open
title: python3 k1om dissociation permanence: libffi
type: compile error
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41705/0001-k1om-libffi.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 24 11:04:01 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 24 Jan 2016 16:04:01 +0000
Subject: [issue26192] python3 k1om dissociation permanence: libffi
In-Reply-To: <1453650595.09.0.833212655161.issue26192@psf.upfronthosting.co.za>
Message-ID: <1453651441.19.0.179821137354.issue26192@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
components: +Extension Modules
nosy: +doko
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 24 11:09:57 2016
From: report at bugs.python.org (=?utf-8?q?=C6=A6OB_COASTN?=)
Date: Sun, 24 Jan 2016 16:09:57 +0000
Subject: [issue26193] python3 k1om dissociation permanence: readelf
Message-ID: <1453651797.54.0.364540683305.issue26193@psf.upfronthosting.co.za>


New submission from ?OB COASTN:

> 2.) ./configure script halts during failure to locate readelf for the host.
>
> I simply commented out these lines in the ./configure file:
>  #if test "$cross_compiling" = yes; then
>     #case "$READELF" in
>     #readelf|:)
>     #as_fn_error $? "readelf for the host is required for cross
> builds" "$LINENO" 5
>     #;;
>     #esac
> #fi
>
> Ideally, ./configure would support ICC and k1om.
> Am I missing something in the configure/make commands below?
> Is it possible to bypass the readelf requirement when cross-compiling for
> k1om?
>
> Additionally, are any of the command line parameters below unnecessary?
> PKG_CONFIG_LIBDIR
> PKG_CONFIG_PATH
> PYTHON_FOR_BUILD
> _PYTHON_HOST_PLATFORM
> HOSTPGEN
> HOSTARCH
> BUILDARCH
>
>
> Thanks,
> Rob
>
>
>
>
> #copy/unpack the k1om bins tarball
> cd /home/
> wget mpss-3.4.6-k1om.tar
> tar xvf mpss-3.4.6-k1om.tar
> cd /home/mpss-3.4.6/k1om/
> for rpm in *.rpm; do rpm2cpio $rpm | cpio -idm; done
>
> #vars
> PythonVersion=Python-3.4.4
> k1om_rpm=/home/mpss-3.4.6/k1om/
> INSTALLPREFIX=/home/Python/release/$PythonVersion-mic
> SRC=/home/Python/$PythonVersion
>
> echo "Compiling host Python"
> cd $SRC && make distclean
> cd $SRC && ./configure
> cd $SRC && make python Parser/pgen
> rm -f $SRC/hostpython
> mv $SRC/python $SRC/hostpython
> rm -f $SRC/Parser/hostpgen
> mv $SRC/Parser/pgen $SRC/Parser/hostpgen
> cd $SRC && make distclean
>
> echo "Configuring Python for MIC..."
> cd $SRC && CONFIG_SITE=config.site \
> ./configure \
> CC="icc -mmic" \
> CFLAGS="-I$k1om_rpm/include -I$k1om_rpm/usr/include -wd10006" \
> CXX="icpc -mmic" \
> CPPFLAGS="-I$k1om_rpm/include -I$k1om_rpm/usr/include -wd10006" \
> PKG_CONFIG_LIBDIR="$k1om_rpm/usr/lib64/pkgconfig" \
> PKG_CONFIG_PATH="$k1om_rpm/usr/lib64/pkgconfig" \
> --host=x86_64-k1om-linux \
> --build=x86_64-linux-gnu \
> --with-cxx-main="icpc -mmic" \
> --disable-ipv6
> echo "done"
>
> echo "Compiling Python for MIC..."
> cd $SRC && make \
> PYTHON_FOR_BUILD=./hostpython \
> _PYTHON_HOST_PLATFORM=x86_64-k1om-linux \
> HOSTPGEN=./Parser/hostpgen \
> HOSTARCH=x86_64-k1om-linux \
> BUILDARCH=x86_64-linux-gnu \
> EXTRA_CFLAGS="-fp-model precise -shared -fPIC" \
> LDFLAGS="-L$k1om_rpm/lib64 -L$k1om_rpm/usr/lib64"
> echo "done"
>
> echo "Installing Python for MIC"
> mkdir -p $INSTALLPREFIX
> cd $SRC && make install \
> PYTHON_FOR_BUILD=./hostpython \
> _PYTHON_HOST_PLATFORM=x86_64-k1om-linux \
> prefix=$INSTALLPREFIX
> echo "done"

----------
components: Cross-Build
messages: 258889
nosy: ?OB COASTN
priority: normal
severity: normal
status: open
title: python3 k1om dissociation permanence: readelf
type: compile error
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 24 11:14:51 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 24 Jan 2016 16:14:51 +0000
Subject: [issue26191] pip on Windows doesn't honor Case
In-Reply-To: <1453647908.67.0.442004366007.issue26191@psf.upfronthosting.co.za>
Message-ID: <1453652091.36.0.953514725594.issue26191@psf.upfronthosting.co.za>


SilentGhost added the comment:

Assuming that you're talking about https://pypi.python.org/pypi/crypto/ - it is unfortunate that pip is so lax with capitalisation rules when installing a package, but as far as I can see there isn't a "Crypto" package anywhere and you're never encouraged to use such a capitalisation in their docs.

Feel free to submit an issue on pip tracker, but this doesn't at all seem suitable for this one.

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: compile error -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 24 11:17:47 2016
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 24 Jan 2016 16:17:47 +0000
Subject: [issue26191] pip on Windows doesn't honor Case
In-Reply-To: <1453647908.67.0.442004366007.issue26191@psf.upfronthosting.co.za>
Message-ID: <1453652267.9.0.877967173306.issue26191@psf.upfronthosting.co.za>


Donald Stufft added the comment:

If you're trying to use PyCrypto then you need to install PyCrypto, crypto is a different package. Try ``pip install PyCrypto``.

----------
nosy: +dstufft

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 24 11:47:26 2016
From: report at bugs.python.org (Anders Rundgren)
Date: Sun, 24 Jan 2016 16:47:26 +0000
Subject: [issue26191] pip on Windows doesn't honor Case
In-Reply-To: <1453647908.67.0.442004366007.issue26191@psf.upfronthosting.co.za>
Message-ID: <1453654046.65.0.700605537653.issue26191@psf.upfronthosting.co.za>


Anders Rundgren added the comment:

You are right. Pardon me for erring :-(

Thanks for the quick response BTW!

Anders

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 24 12:47:04 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Jan 2016 17:47:04 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
Message-ID: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The behavior of deque.insert() in a bounded deque is a bit odd:

>>> from collections import deque
>>> d = deque(range(20), maxlen=10)
>>> d
deque([10, 11, 12, 13, 14, 15, 16, 17, 18, 19], maxlen=10)
>>> d.insert(3, 'New')
>>> d
deque([19, 10, 11, 'New', 13, 14, 15, 16, 17, 18], maxlen=10)
#       ^   ^        ^--- The 12 got replaced
#       |   \--- The elements before the insertion point got rotated
#       \--- The final element got rotated to first position

With append/appendleft/extend/extendleft, the intended and useful behavior for maxlen is to pop from the opposite end.  But for deque.insert(), the best and most useful behavior invariants are less obvious.

Ideally, the effect of d.insert(0, item) would be the same as d.appendleft(item), and the effect of d.insert(len(d), item) would be the same as d.append(item).  

Also, d.insert(i, newitem) should have the post-condition:

  assert d[i] == newitem if i < len(d) else d[-1] == newitem

Having decided where to put the newitem, the question turns to deciding which element should be popped-off to maintain the size invariant.

I'm thinking that it should always be the rightmost element that gets popped, so that items before the inserted element never get moved.  This matches what insert() does for unbounded deques, making it the least surprising choice.

----------
assignee: rhettinger
components: Extension Modules
messages: 258893
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Undefined behavior for deque.insert() when len(d) == maxlen
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 24 18:35:56 2016
From: report at bugs.python.org (Katie McLaughlin)
Date: Sun, 24 Jan 2016 23:35:56 +0000
Subject: [issue25296] Simple End-of-life guide covering all unsupported
 versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1453678556.84.0.20600047667.issue25296@psf.upfronthosting.co.za>


Katie McLaughlin added the comment:

Hello!

I recently saw an announcement[0] about the adding of the lifecycle status right at the top of the devguide[1]. I believe this was added as part of Issue 26165[2]

Given this, can this issue be marked as Resolved?

0 - https://twitter.com/gvanrossum/status/690227337015590912
1 - https://docs.python.org/devguide/#status-of-python-branches
2 - https://bugs.python.org/issue26165

----------
nosy: +Katie McLaughlin

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 24 20:55:22 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 25 Jan 2016 01:55:22 +0000
Subject: [issue25296] Simple End-of-life guide covering all unsupported
 versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1453686922.07.0.459981473237.issue25296@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 24 21:54:44 2016
From: report at bugs.python.org (Alex Robinson)
Date: Mon, 25 Jan 2016 02:54:44 +0000
Subject: [issue26195] Windows frozen .exe multiprocessing.Queue access is
 denied exception
Message-ID: <1453690484.95.0.111987955887.issue26195@psf.upfronthosting.co.za>


New submission from Alex Robinson:

A pyinstaller 3.0 frozen .exe Python 2.7.10 program under Windows 7 that uses a multiprocessing.Queue to send things to a multiprocessing.Process leads to the process getting access-is-denied exceptions on every q.get() call.

And, when the program can't exit. Or leaves a dangling process for every Process.

An unsatisfying fix for this is to put the following code somewhere in the program:

"""
    Do what must be done to make multiprocessing work in .exe files.

    This involves monkey patching multiprocessing.forking under Windows
    so when the a program using a multiprocessing.Process exits,
    there won't be processes left running.

    Hint from   http://stackoverflow.com/questions/33764448/pathos-multiprocessing-pipe-and-queue-on-windows

    .           The bottom line is we get "access is denied" when trying
    .           to get from the multiprocessing.Queue when we're an .exe file.

    .           So, in multiprocessing.forking.duplicate(),
    .           we change 'inheritable' to default to True
    .           from the normal code's False.

"""

import  sys
import  multiprocessing
import  multiprocessing.forking


#
#
#
#
def duplicate(handle, target_process = None, inheritable = True) :
    return(multiprocessing.forking.kludge_to_fix_dangling_processes(handle, target_process, inheritable))

if  (not hasattr(multiprocessing.forking, 'kludge_to_fix_dangling_processes')) and (sys.platform == 'win32') :
    multiprocessing.forking.kludge_to_fix_dangling_processes    = multiprocessing.forking.duplicate
    multiprocessing.forking.duplicate                           = duplicate

----------
components: Library (Lib)
messages: 258895
nosy: alex_python_org
priority: normal
severity: normal
status: open
title: Windows frozen .exe multiprocessing.Queue access is denied exception
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 03:22:10 2016
From: report at bugs.python.org (Milan Zamazal)
Date: Mon, 25 Jan 2016 08:22:10 +0000
Subject: [issue26180] multiprocessing.util._afterfork_registry leak in
 threaded environment
In-Reply-To: <1453476286.88.0.329468896089.issue26180@psf.upfronthosting.co.za>
Message-ID: <1453710130.77.0.39507594036.issue26180@psf.upfronthosting.co.za>


Milan Zamazal added the comment:

Python 3.x version attached.

----------
Added file: http://bugs.python.org/file41706/bug3.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 04:40:16 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 25 Jan 2016 09:40:16 +0000
Subject: [issue26187] sqlite3 trace callback prints duplicate line
In-Reply-To: <1453577672.38.0.77226221379.issue26187@psf.upfronthosting.co.za>
Message-ID: <1453714816.96.0.924197364406.issue26187@psf.upfronthosting.co.za>


Changes by Xiang Zhang <18518281186 at 126.com>:


----------
nosy: +xiang.zhang

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 05:31:04 2016
From: report at bugs.python.org (Michael Foord)
Date: Mon, 25 Jan 2016 10:31:04 +0000
Subject: [issue26140] inspect.iscoroutinefunction raises TypeError when checks
 Mock of function or coroutinefunction
In-Reply-To: <1453030972.84.0.0646105171888.issue26140@psf.upfronthosting.co.za>
Message-ID: <1453717864.45.0.60766239034.issue26140@psf.upfronthosting.co.za>


Changes by Michael Foord :


----------
nosy:  -gvanrossum

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 06:25:35 2016
From: report at bugs.python.org (Charles Daffern)
Date: Mon, 25 Jan 2016 11:25:35 +0000
Subject: [issue26196] Argparse breaks when a switch is given an argument
 beginning with a dash
Message-ID: <1453721135.68.0.519114761572.issue26196@psf.upfronthosting.co.za>


New submission from Charles Daffern:

Example code demonstrating the problem:

# {{{
import argparse

def try_args(*args):
    parser = argparse.ArgumentParser()
    parser.add_argument("-a")
    print("Trying:", args)
    try:
        print(parser.parse_args(args))
    except SystemExit:
        print("FAILED!")

try_args("-a", "-")  # Works fine
try_args("-a", "-a")  # Breaks
try_args("-a", "--")  # Breaks
try_args("-a", "--things--")  # Breaks
# }}}

This behaviour is contrary to optparse:

# {{{
import optparse

def try_args(*args):
    parser = optparse.OptionParser()
    parser.add_option("-a")
    print("Trying:", args)
    try:
        print(parser.parse_args(list(args)))
    except SystemExit:
        print("FAILED!")

try_args("-a", "-")  # Works
try_args("-a", "-a")  # Works
try_args("-a", "--")  # Works
try_args("-a", "--things--")  # Works
# }}}

It is also contrary to many other utilities, including python itself:

# {{{
$ python -c -c
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'c' is not defined
$ printf 'hello\nworld\n-- pick me\netc\n' | grep -e --
-- pick me
$ gawk -f --
gawk: fatal: can't open source file `--' for reading (No such file or directory)
$ vim -u --
E282: Cannot read from "--"
Press ENTER or type command to continue
$ man -M --asdf man
No manual entry for man
$ less -b --sdfkds
Number is required after -b (--buffers)
Missing filename ("less --help" for help)
$ perl -e --fasd
Can't modify constant item in predecrement (--) at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
# }}}

I first encountered this problem when using a text scrolling utility someone had written in python, and tried to pass "--" as the text separator. The program just bailed out, and it turned out that it wasn't the author's fault but a problem in argparse itself.

----------
components: Library (Lib)
messages: 258897
nosy: Charles Daffern
priority: normal
severity: normal
status: open
title: Argparse breaks when a switch is given an argument beginning with a dash
type: behavior
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 06:48:59 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 25 Jan 2016 11:48:59 +0000
Subject: [issue26196] Argparse breaks when a switch is given an argument
 beginning with a dash
In-Reply-To: <1453721135.68.0.519114761572.issue26196@psf.upfronthosting.co.za>
Message-ID: <1453722539.14.0.660458587839.issue26196@psf.upfronthosting.co.za>


SilentGhost added the comment:

If you're to drop the space between the argument and its value, e.g. try_args('-a-a'), it seems to work as intended. The third example (
try_args("-a", "--")) still wouldn't work, but it looks like a reasonable workaround to me.

----------
nosy: +SilentGhost, bethard

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 07:57:17 2016
From: report at bugs.python.org (Francesco Pelizza)
Date: Mon, 25 Jan 2016 12:57:17 +0000
Subject: [issue26197] arange from numpy function has some limits....I propose
 a python function that overcome
Message-ID: <1453726637.54.0.637888159754.issue26197@psf.upfronthosting.co.za>


New submission from Francesco Pelizza:

arange from numpy is a function to generate list of floats from a start to an end number with a defined float number.

The "arange" function works fine for some cases, but in my case where I have to generate numbers that constitute parameters in a Quantum Mechanical calculation, numbers can be missing or be more than what I want, since many time each number is calculated in a couple of days or more. I need to avoid extra numbers or missing numbers to avoid loss of data. And sometimes the script will pass to a cycle function wrong numbers for start and stop, or the same number as starting and ending point, but I can not avoid this because they are numbers coming from Quantum World, and I need a function that sort out anything on its own because is inserted in for loops and things like that.

Also arange function does not take the "stop" number as the last number of the list, but it will terminate before, so to have the last wanted number in the list you have to use the formulae  arange(start,stop+inc,inc) or arange(start,stop+n,inc) where n allows is bigger than zero.

Some cases that give me problems are the following:
Defective lists of numbers:
1) arange(1,10+0.0000001,0.00000001) some numbers are missing
2) arange(1,10+0.0000001,1) generate float without any decimal after the point
3) arange(1,10,0.0000001) some numbers are missing
4) ...other combination gives problems

Empty lists of numbers:
1) arange(1,10,-1)
2) arange(1,-10,1)
3) arange(1,1,1)
4) arange(1,1,0.5)
5) arange(1,-10,0.005)
6) so on....

I made a python function that goes across any of these problems, taking account of using the absolute value of the given incremental step number.

Numbers can be float or integers, any exception of number ordering is kept under control to generate anyway at least a list of one number, if the stop number is bigger than the starting one, they get switched to generate anyway a list of numbers. And it can go down until 14 decimal places of incremental steps without generating wrong numbers due to the binary conversion of floats!
Some use of this function are eventually weird or really exotic, but in using python as a code to deal with computation without crashing for silly numbers ordering from the quantum world, is essential.

Do you agree with the improvements I put in this function called "CYCLE" can be of help?

I would like to share it with the community.

Here attached the function I made

----------
components: Library (Lib)
files: CYCLE.py
messages: 258899
nosy: Francesco Pelizza
priority: normal
severity: normal
status: open
title: arange from numpy function has some limits....I propose a python function that overcome
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file41707/CYCLE.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 08:01:30 2016
From: report at bugs.python.org (Francesco Pelizza)
Date: Mon, 25 Jan 2016 13:01:30 +0000
Subject: [issue26197] arange from numpy function has some limits....I propose
 a python function that overcome these limitations
In-Reply-To: <1453726637.54.0.637888159754.issue26197@psf.upfronthosting.co.za>
Message-ID: <1453726890.31.0.584366761634.issue26197@psf.upfronthosting.co.za>


Changes by Francesco Pelizza :


----------
title: arange from numpy function has some limits....I propose a python function that overcome -> arange from numpy function has some limits....I propose a python function that overcome these limitations

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 08:01:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Jan 2016 13:01:41 +0000
Subject: [issue26197] arange from numpy function has some limits....I propose
 a python function that overcome these limitations
In-Reply-To: <1453726637.54.0.637888159754.issue26197@psf.upfronthosting.co.za>
Message-ID: <1453726901.12.0.250828849443.issue26197@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It looks like an issue for numpy no? http://www.scipy.org/scipylib/bug-report.html

I'm not sure that such function fits into Python stdlib.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 09:35:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Jan 2016 14:35:27 +0000
Subject: [issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit
 constants
In-Reply-To: <1453136691.51.0.69393755181.issue26146@psf.upfronthosting.co.za>
Message-ID: <1453732527.93.0.81046028829.issue26146@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 3: fix a reference leak in validate_constant().

----------
Added file: http://bugs.python.org/file41708/constant-3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 09:36:26 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 25 Jan 2016 14:36:26 +0000
Subject: [issue26197] arange from numpy function has some limits....I propose
 a python function that overcome these limitations
In-Reply-To: <1453726637.54.0.637888159754.issue26197@psf.upfronthosting.co.za>
Message-ID: <1453732586.94.0.718224431291.issue26197@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

NumPy isn't a part of CPython. As haypo said, please submit that to their tracker instead.

----------
nosy: +ebarry
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 10:00:38 2016
From: report at bugs.python.org (Chris Hogan)
Date: Mon, 25 Jan 2016 15:00:38 +0000
Subject: [issue24923] Append system paths in setup.py instead of prepending
In-Reply-To: <1440428121.6.0.746141080033.issue24923@psf.upfronthosting.co.za>
Message-ID: <1453734038.06.0.986194131044.issue24923@psf.upfronthosting.co.za>


Chris Hogan added the comment:

Zach, 

3.x had the desired behavior.  We didn't have to make any changes.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 10:59:41 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Mon, 25 Jan 2016 15:59:41 +0000
Subject: [issue26189] Interpreter returns control to cmd.exe early
In-Reply-To: <1453602542.98.0.731550634512.issue26189@psf.upfronthosting.co.za>
Message-ID: <1453737581.37.0.0595931154441.issue26189@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

@eryksun tried that already, same effect:

C:\>start /b /w python -c "print 'bla-bla-bl
a'; raise SystemExit(42)"

C:\>bla-bla-bla
echo %errorlevel%
0

I'll try to pinpoint the issue to an OS/OS family/update or Python version.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 11:13:08 2016
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Mon, 25 Jan 2016 16:13:08 +0000
Subject: [issue26198] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError
Message-ID: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>


New submission from Hrvoje Nik?i?:

The documentation for the "es#" format (and the "et#" that derives from it) documents the possibility of providing an already allocated buffer. Buffer overflow is detected and handled as follows: "If the buffer is not large enough, a ValueError will be set."

However, the actual behavior is to raise a TypeError. Inspecting the code in getargs.c reveals that convertsimple() handles buffer overflow by returning a formatted message to its caller, convertitem(). Calls to convertitem() that return an error call seterror() to set the error, and seterror() unconditionally sets the PyExc_TypeError.

This is not a big issue in practice, and since the behavior is not new, it might be best to simply update the documentation to match the existing practice instead of changing the behavior and risking breaking working code.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 258905
nosy: docs at python, hniksic
priority: normal
severity: normal
status: open
title: PyArg_ParseTuple with format "et#" and "es#" detects overflow by raising TypeError instead of ValueError
type: behavior
versions: Python 2.7, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 11:20:52 2016
From: report at bugs.python.org (Raphael Das Gupta)
Date: Mon, 25 Jan 2016 16:20:52 +0000
Subject: [issue26199] fix broken link to
 hamcrest.library.integration.match_equality in unittest.mock "getting
 started" documentation
Message-ID: <1453738852.52.0.691213360087.issue26199@psf.upfronthosting.co.za>


New submission from Raphael Das Gupta:

On

* https://docs.python.org/3.3/library/unittest.mock-examples.html#more-complex-argument-matching
* https://docs.python.org/3.4/library/unittest.mock-examples.html#more-complex-argument-matching
* https://docs.python.org/3.5/library/unittest.mock-examples.html#more-complex-argument-matching
* https://docs.python.org/3.6/library/unittest.mock-examples.html#more-complex-argument-matching

the link to hamcrest.library.integration.match_equality documentation at the very end of the page is broken.

(Earlier versions didn't have this documentation page.)

----------
assignee: docs at python
components: Documentation
hgrepos: 332
messages: 258906
nosy: das-g, docs at python
priority: normal
severity: normal
status: open
title: fix broken link to hamcrest.library.integration.match_equality in unittest.mock "getting started" documentation
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 11:24:48 2016
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Mon, 25 Jan 2016 16:24:48 +0000
Subject: [issue26198] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1453739088.32.0.119323532622.issue26198@psf.upfronthosting.co.za>


Hrvoje Nik?i? added the comment:

The problem can be encountered and easily reproduced by calling os.path functions, such as os.path.abspath, with a sufficiently large string on Windows:

>>> os.path.abspath("a" * 1024)
Traceback (most recent call last):
  File "", line 1, in 
  File "P:\...\lib\ntpath.py", line 471, in abspath
TypeError: must be (buffer overflow), not str

The error message is somewhat confusing, making it look like the "must be" and "not" arguments are swapped. Ideally, the message could be along the lines of "must be a string of no more than X characters".

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 11:36:24 2016
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 25 Jan 2016 16:36:24 +0000
Subject: [issue24923] Append system paths in setup.py instead of prepending
In-Reply-To: <1440428121.6.0.746141080033.issue24923@psf.upfronthosting.co.za>
Message-ID: <1453739784.53.0.465389110208.issue24923@psf.upfronthosting.co.za>


Zachary Ware added the comment:

In that case, does this patch do what you want it to do?

----------
stage:  -> patch review
Added file: http://bugs.python.org/file41710/issue24923.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 11:42:26 2016
From: report at bugs.python.org (Raphael Das Gupta)
Date: Mon, 25 Jan 2016 16:42:26 +0000
Subject: [issue26199] fix broken link to
 hamcrest.library.integration.match_equality in unittest.mock "getting
 started" documentation
In-Reply-To: <1453738852.52.0.691213360087.issue26199@psf.upfronthosting.co.za>
Message-ID: <1453740146.77.0.251176831873.issue26199@psf.upfronthosting.co.za>


Changes by Raphael Das Gupta :


----------
keywords: +patch
Added file: http://bugs.python.org/file41709/0d413f60cc23.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 11:56:06 2016
From: report at bugs.python.org (Raphael Das Gupta)
Date: Mon, 25 Jan 2016 16:56:06 +0000
Subject: [issue26199] fix broken link to
 hamcrest.library.integration.match_equality in unittest.mock "getting
 started" documentation
In-Reply-To: <1453738852.52.0.691213360087.issue26199@psf.upfronthosting.co.za>
Message-ID: <1453740966.37.0.455161397933.issue26199@psf.upfronthosting.co.za>


Raphael Das Gupta added the comment:

0d413f60cc23.diff generated with the 'Create Patch' button of this bug tracker is crap. (I guess it's a diff of upstream's tip to my repo's tip, thus reverting all changes of upstream that this daggy fix isn't based on.)

Use fix-broken-link-to-pyhamcrest-match_equality.diff instead. (Created with hg export.)

----------
Added file: http://bugs.python.org/file41711/fix-broken-link-to-pyhamcrest-match_equality.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 12:14:25 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 25 Jan 2016 17:14:25 +0000
Subject: [issue26196] Argparse breaks when a switch is given an argument
 beginning with a dash
In-Reply-To: <1453721135.68.0.519114761572.issue26196@psf.upfronthosting.co.za>
Message-ID: <1453742065.69.0.476894104093.issue26196@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I believe this is a duplicate of issue 9334. There's a lot of discussion there.

----------
nosy: +eric.smith
stage:  -> resolved
status: open -> closed
superseder:  -> argparse does not accept options taking arguments beginning with dash (regression from optparse)

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 12:17:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Jan 2016 17:17:24 +0000
Subject: [issue25783] test_traceback.test_walk_stack() fails when run directly
 (without regrtest)
In-Reply-To: <1449078273.26.0.535537969115.issue25783@psf.upfronthosting.co.za>
Message-ID: <1453742244.89.0.236122573609.issue25783@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@Robert: Can you please take a look at the attached patch? Does it look good to you?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 12:23:53 2016
From: report at bugs.python.org (Chris Hogan)
Date: Mon, 25 Jan 2016 17:23:53 +0000
Subject: [issue24923] Append system paths in setup.py instead of prepending
In-Reply-To: <1440428121.6.0.746141080033.issue24923@psf.upfronthosting.co.za>
Message-ID: <1453742633.9.0.901208786682.issue24923@psf.upfronthosting.co.za>


Chris Hogan added the comment:

I should be able to try it out today or tomorrow.  I'll let you know.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 13:03:44 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Jan 2016 18:03:44 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
Message-ID: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Application of the SETREF macro was not code neutral in a number of cases.  The SETREF macro always uses Py_XDECREF where the original code correctly used a faster and lighter Py_DECREF.

There should be an XSETREF variant and more care should be taken when applying these macros wholesale to the entire code base.

----------
assignee: serhiy.storchaka
components: Interpreter Core
messages: 258913
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: SETREF adds unnecessary work in some cases
type: performance
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 13:08:28 2016
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 25 Jan 2016 18:08:28 +0000
Subject: [issue26189] Interpreter returns control to cmd.exe early
In-Reply-To: <1453602542.98.0.731550634512.issue26189@psf.upfronthosting.co.za>
Message-ID: <1453745308.24.0.384334619926.issue26189@psf.upfronthosting.co.za>


Eryk Sun added the comment:

That the wait failed to get the 42 exit code means that the "python" command (which may not actually be python.exe) is spawning a child process to run the command and not waiting for it to exit. Please try the following using the absolute path to python.exe:

    C:\>start "title" /b /w "PATH\TO\python.exe" -c "raise SystemExit(42)"
    C:\>echo %errorlevel%
    42

In this case "title" is required because cmd parses the first quoted string prior to the executable as the title. Without "title" it would parse the path to python.exe as the title and try to execute "-c".

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 13:10:19 2016
From: report at bugs.python.org (Barun Parruck)
Date: Mon, 25 Jan 2016 18:10:19 +0000
Subject: [issue26198] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1453745419.87.0.139232073712.issue26198@psf.upfronthosting.co.za>


Barun Parruck added the comment:

I just changed the ValueError to TypeError. This is my first attempt at fixing anything, so let me know if I've screwed up anywhere.

----------
keywords: +patch
nosy: +Barun Parruck
Added file: http://bugs.python.org/file41712/typeerror.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 13:27:22 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Mon, 25 Jan 2016 18:27:22 +0000
Subject: [issue26189] Interpreter returns control to cmd.exe early
In-Reply-To: <1453602542.98.0.731550634512.issue26189@psf.upfronthosting.co.za>
Message-ID: <1453746442.95.0.946593605993.issue26189@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

@eryksun That's it! "python" was actually launching a shortcut in my "shortcuts to often-used commands around the system" folder!

Thank goodness (this time, "Goodness" is Brian Curtin with 90617:a9d34685ec47, Sat May 10 12:52:59 2014 -0500 (so tell him he can add this to the list of his nicknames ;) )), the installer now has an option to add the EXEs to PATH, making this hack unneeded.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 14:05:45 2016
From: report at bugs.python.org (Barun Parruck)
Date: Mon, 25 Jan 2016 19:05:45 +0000
Subject: [issue26198] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1453748745.86.0.0822819679579.issue26198@psf.upfronthosting.co.za>


Barun Parruck added the comment:

Added a patch that changes the documentation to reflect TypeError instead of ValueError*

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 14:25:40 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Jan 2016 19:25:40 +0000
Subject: [issue26201] Faster type checking in listobject.c
Message-ID: <1453749940.01.0.185085396815.issue26201@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

A number of fine-grained methods in Objects/listobject.c use PyList_Check().  They include PyList_Size, PyList_GetItem, PyList_SetItem, PyList_Insert, and PyList_Append.

The PyList_Check() works by making two sequentially dependent memory fetches:

    movq    8(%rdi), %rax
    testb   $2, 171(%rax)
    je  L1645

This patch proposes a fast path for the common case of an exact match, using PyList_CheckExact() as an early-out before the PyList_Check() test:

    leaq    _PyList_Type(%rip), %rdx # parallelizable
    movq    8(%rdi), %rax            # only 1 memory access
    cmpq    %rdx, %rax               # macro-fusion  
    je  L1604                        # early-out
    testb   $2, 171(%rax)            # fallback to 2nd memory access
    je  L1604

This technique won't help outside of Objects/listobject.c because the initial LEA instruction becomes a MOV for the global offset table, nullifying the advantage.

----------
assignee: serhiy.storchaka
components: Interpreter Core
files: list_check_fastpath.diff
keywords: patch
messages: 258918
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Faster type checking in listobject.c
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file41713/list_check_fastpath.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 15:10:55 2016
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 25 Jan 2016 20:10:55 +0000
Subject: [issue26201] Faster type checking in listobject.c
In-Reply-To: <1453749940.01.0.185085396815.issue26201@psf.upfronthosting.co.za>
Message-ID: <1453752654.99.0.0272828128891.issue26201@psf.upfronthosting.co.za>


Jeremy Kloth added the comment:

Added review

----------
nosy: +jkloth

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 15:26:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Jan 2016 20:26:38 +0000
Subject: [issue26201] Faster type checking in listobject.c
In-Reply-To: <1453749940.01.0.185085396815.issue26201@psf.upfronthosting.co.za>
Message-ID: <1453753598.15.0.640521225331.issue26201@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please provide any microbencmarks that show the benefit of this optimization?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 15:53:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Jan 2016 20:53:06 +0000
Subject: [issue26202] The range() object is deepcopied as atomic
Message-ID: <1453755186.26.0.578500471201.issue26202@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The range() object is immutable, but is not atomic, and copy.deepcopy() shouldn't return it unchanged.

>>> class I(int): pass  # mutable index
... 
>>> import copy
>>> r = range(I(10))
>>> r2 = copy.deepcopy(r)
>>> r.stop.attr = 'spam'
>>> r2.stop.attr
'spam'

This is Python 3 only issue because in 2.7 the xrange() object doesn't exposes start/stop/step attributes.

Proposed patch fixes the copy module.

----------
components: Library (Lib)
files: deepcopy_range.patch
keywords: patch
messages: 258921
nosy: alexandre.vassalotti, fdrake, haypo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: The range() object is deepcopied as atomic
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41714/deepcopy_range.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 16:00:53 2016
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 25 Jan 2016 21:00:53 +0000
Subject: [issue26189] Interpreter returns control to cmd.exe early
In-Reply-To: <1453602542.98.0.731550634512.issue26189@psf.upfronthosting.co.za>
Message-ID: <1453755653.9.0.919965828607.issue26189@psf.upfronthosting.co.za>


Eryk Sun added the comment:

By shortcut I'm guessing you mean a batch file. A regular .LNK shortcut works fine if .LNK is in PATHEXT. I sometimes use a shortcut when I need to set the default to "Run as administrator". (I add a "runas" verb to the ProgIds to add this option to the menu for .PY, .PYZ, .PYW, and .PYWZ files, but the shell doesn't allow setting the default in the advanced properties like with a shortcut.)

An alternative to adding Python to PATH is to use the py launcher and virtual environments. This is especially useful when you have multiple versions installed.

----------
stage:  -> resolved

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 16:06:30 2016
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Caron?=)
Date: Mon, 25 Jan 2016 21:06:30 +0000
Subject: [issue26203] nesting venv in virtualenv segfaults
Message-ID: <1453755990.33.0.69898482015.issue26203@psf.upfronthosting.co.za>


New submission from Andr? Caron:

When trying to create a new virtual environment using Python 3.5's venv package from a virtual environment created by the popular 3rd-party virtualenv  package, I get a segfault.

Nested virtual environments work fine both with venv and virtualenv, but using one inside the other doesn't work.  This suggests a subtle incompatibility between the two implementations.

I'm not sure whether compatibility between the implementations is a goal or not at the moment, but there is extensive tooling that uses the 3rd party virtualenv implementation.  For example, I run tests with Tox, which uses virtualenv.  I cannot test any package that uses the standard venv because everything crashes.  As a result of this, I will avoid moving to the standard implementation.

I put up some sample scripts up on GitHub to show how to reproduce the issue.  I hope they can help explain the issue.

https://github.com/AndreLouisCaron/nested-venv-bug

Cheers,

Andr?

----------
components: Library (Lib)
messages: 258923
nosy: Andr? Caron
priority: normal
severity: normal
status: open
title: nesting venv in virtualenv segfaults
type: crash
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 16:08:19 2016
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Caron?=)
Date: Mon, 25 Jan 2016 21:08:19 +0000
Subject: [issue25833] pyvenv: venvs cannot be moved because activate scripts
 hard-code paths
In-Reply-To: <1449760528.92.0.724215878047.issue25833@psf.upfronthosting.co.za>
Message-ID: <1453756099.35.0.480073898311.issue25833@psf.upfronthosting.co.za>


Changes by Andr? Caron :


----------
nosy: +Andr? Caron

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 16:09:07 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Jan 2016 21:09:07 +0000
Subject: [issue26201] Faster type checking in listobject.c
In-Reply-To: <1453749940.01.0.185085396815.issue26201@psf.upfronthosting.co.za>
Message-ID: <1453756147.88.0.363599678921.issue26201@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Jeremy, thanks for the keen eyes.  Attaching a revised patch.

Serhiy, pure python code doesn't directly access any of the C-API functions touched by the patch, so timeit-style examples aren't possible.  The beneficiaries of the change are external modules.  I suppose we could write a small C extension just to time this but that seems like overkill.

It is a general purpose optimization technique to reduce the number of memory accesses in fine-grained functions.  That technique has worked well elsewhere in the core where measurable progress was made in many small steps that were individually hard to measure.

----------
assignee: serhiy.storchaka -> rhettinger
Added file: http://bugs.python.org/file41715/list_check_fastpath2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 16:18:38 2016
From: report at bugs.python.org (Florian Bruhin)
Date: Mon, 25 Jan 2016 21:18:38 +0000
Subject: [issue26203] nesting venv in virtualenv segfaults
In-Reply-To: <1453755990.33.0.69898482015.issue26203@psf.upfronthosting.co.za>
Message-ID: <1453756718.52.0.371210842162.issue26203@psf.upfronthosting.co.za>


Changes by Florian Bruhin :


----------
nosy: +The Compiler, dstufft, vinay.sajip

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 16:23:00 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Jan 2016 21:23:00 +0000
Subject: [issue26202] The range() object is deepcopied as atomic
In-Reply-To: <1453755186.26.0.578500471201.issue26202@psf.upfronthosting.co.za>
Message-ID: <1453756980.27.0.270648386194.issue26202@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hum ok, it's a bug :-) It should be fixed. Do you want to work on a patch?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 16:24:46 2016
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 25 Jan 2016 21:24:46 +0000
Subject: [issue26202] The range() object is deepcopied as atomic
In-Reply-To: <1453755186.26.0.578500471201.issue26202@psf.upfronthosting.co.za>
Message-ID: <1453757086.69.0.385069422899.issue26202@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I don't have much experience with the copy module, but I don't see any problems with the code.

Does copy.copy suffer from the same problem?  If yes, is it fixed with this same patch, or is more work needed?

----------
nosy: +ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 16:25:18 2016
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 25 Jan 2016 21:25:18 +0000
Subject: [issue26202] The range() object is deepcopied as atomic
In-Reply-To: <1453755186.26.0.578500471201.issue26202@psf.upfronthosting.co.za>
Message-ID: <1453757118.07.0.53164371095.issue26202@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Victor, patch was already attached.  ;)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 16:35:37 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Jan 2016 21:35:37 +0000
Subject: [issue26201] Faster type checking in listobject.c
In-Reply-To: <1453749940.01.0.185085396815.issue26201@psf.upfronthosting.co.za>
Message-ID: <1453757737.67.0.708132902698.issue26201@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Could you please provide any microbencmarks that show the benefit of this optimization?

Yeah, analyzing the assembler seems overkill to me. I'm not sure that it really make the code faster (but it makes the code more complex).

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 16:44:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Jan 2016 21:44:51 +0000
Subject: [issue26202] The range() object is deepcopied as atomic
In-Reply-To: <1453755186.26.0.578500471201.issue26202@psf.upfronthosting.co.za>
Message-ID: <1453758291.43.0.596682540521.issue26202@psf.upfronthosting.co.za>


STINNER Victor added the comment:

deepcopy_range.patch looks good to me.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 16:47:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Jan 2016 21:47:24 +0000
Subject: [issue26202] The range() object is deepcopied as atomic
In-Reply-To: <1453755186.26.0.578500471201.issue26202@psf.upfronthosting.co.za>
Message-ID: <1453758444.75.0.160318781331.issue26202@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Returning the same range() object from copy.copy() is correct. This is shallow copying.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 17:37:51 2016
From: report at bugs.python.org (Roger Cook)
Date: Mon, 25 Jan 2016 22:37:51 +0000
Subject: [issue26183] 2.7.11 won't clean install on Windows 10 x64
In-Reply-To: <1453496711.72.0.869603030432.issue26183@psf.upfronthosting.co.za>
Message-ID: <1453761471.18.0.40780419264.issue26183@psf.upfronthosting.co.za>


Roger Cook added the comment:

Installing a VM and running it there, it installs.

Is there a manual removal procedure to follow when the automated uninstall fails?

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 18:18:45 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Jan 2016 23:18:45 +0000
Subject: [issue26201] Faster type checking in listobject.c
In-Reply-To: <1453749940.01.0.185085396815.issue26201@psf.upfronthosting.co.za>
Message-ID: <1453763925.39.0.173900272112.issue26201@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Writing your own static optimizer from scratch is overkill.  Following basic techniques from the Agner Fog manuals and Intel optimization manuals is quite reasonable in comparison.

Unless you see an actual defect in the patch, I'm applying it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 18:26:51 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Mon, 25 Jan 2016 23:26:51 +0000
Subject: [issue26189] Interpreter returns control to cmd.exe early
In-Reply-To: <1453602542.98.0.731550634512.issue26189@psf.upfronthosting.co.za>
Message-ID: <1453764411.37.0.290871682244.issue26189@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

@eryksun That is (was) an .lnk indeed, and adding ".lnk" to PATHEXT is exactly what I did to make it work. This is much more maintainable than registry hacks.

An .lnk is launched with ShellExecute which returns control immediately upon successful launch (see http://stackoverflow.com/questions/31855240/execute-exe-as-jpg/31861241#31861241 for how this happens from `cmd' prompt).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 19:06:24 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 26 Jan 2016 00:06:24 +0000
Subject: [issue26203] nesting venv in virtualenv segfaults
In-Reply-To: <1453755990.33.0.69898482015.issue26203@psf.upfronthosting.co.za>
Message-ID: <1453766784.09.0.242659838177.issue26203@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

By design, the stdlib venv functionality expects to work from an installed Python. However, the Python in a virtualenv venv is not an installed Python - it copies some files from the Python it was installed from and does various other hacks in order to work (I'm not using 'hack' as a pejorative here - it's just what virtualenv has to do).

Thus, you cannot use venv to create an environment from a virtualenv venv's Python. For this to work seamlessly, there would probably need to be coupling between  venv and virtualenv - virtualenv has potentially to be updated with additional hacks every time there is a new Python release, in order to keep working.

It doesn't make sense to couple the stdlib closely with a third-party package. Does it work the other way around? I realise this doesn't help you with tox, and of course tox has to use virtualenv because of supporting older versions of Python ...

----------
nosy: +carljm
resolution:  -> not a bug

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 19:07:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 00:07:51 +0000
Subject: [issue26201] Faster type checking in listobject.c
In-Reply-To: <1453749940.01.0.185085396815.issue26201@psf.upfronthosting.co.za>
Message-ID: <1453766871.21.0.531957609511.issue26201@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Unless you see an actual defect in the patch, I'm applying it.

Well, Serhiy Storchaka asked for a microbenchmark. For an optimization, it's a reasonable request no?


> Writing your own static optimizer from scratch is overkill.

My goal is to get speedup on macro benchmarks.

It's hard to get a real speedup on macro benchmark using micro-optimizations, even if we combine a lot of them. I'm not saying that micro optimization is a waste of time, I like micro-optimizing Python, but we should not abuse of it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 19:11:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Jan 2016 00:11:42 +0000
Subject: [issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit
 constants
In-Reply-To: <1453136691.51.0.69393755181.issue26146@psf.upfronthosting.co.za>
Message-ID: <20160126001137.64620.86340@psf.io>


Roundup Robot added the comment:

New changeset 27e5437f442c by Victor Stinner in branch 'default':
Add ast.Constant
https://hg.python.org/cpython/rev/27e5437f442c

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 19:19:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 00:19:15 +0000
Subject: [issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit
 constants
In-Reply-To: <1453136691.51.0.69393755181.issue26146@psf.upfronthosting.co.za>
Message-ID: <1453767555.69.0.188236437218.issue26146@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I pushed an enhanced version of constant-3.patch:

* fix the compiler: don't emit LOAD_CONST for ast.Constant if the value is a string (str) or a number (int, float, complex), as done previously for ast.Str and ast.Num

* add unit tests on: the compiler (ensure that LOAD_CONST is emitted for constants), ast.get_docstring() and ast.literal_eval()

----------
components: +Interpreter Core
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 19:47:30 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Jan 2016 00:47:30 +0000
Subject: [issue26201] Faster type checking in listobject.c
In-Reply-To: <1453749940.01.0.185085396815.issue26201@psf.upfronthosting.co.za>
Message-ID: <1453769250.74.0.448704020971.issue26201@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Well, Serhiy Storchaka asked for a microbenchmark. 
> For an optimization, it's a reasonable request no?

As noted above, it not reasonable for a C-API that isn't used internally because there is no reasonable way to measure the effect without writing a C extension.

FWIW, I look at assembly to see direct evidence for the effect of a change.  It makes it easy to see how many memory accesses happen on a given path.

If you're going to be in the optimization business, I really wish you would read some of the basics in the field so that each and every technique doesn't have to be re-proved to you each time it used.  Here's a short-list I put together for those who were interested : https://dl.dropboxusercontent.com/u/3967849/sftalk/_build/html/misc.html#optimization-resources

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 20:00:40 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 01:00:40 +0000
Subject: [issue26204] compiler: don't emit LOAD_CONST instructions for
 constant expressions?
Message-ID: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The bytecode compilers ignores ast.Str and ast.Num nodes:

----------------------------
>>> def func():
...     123
...     "test"
... 
>>> import dis; dis.dis(func)
  3           0 LOAD_CONST               0 (None)
              3 RETURN_VALUE
----------------------------

But other ast nodes which are constant are not ignored:

----------------------------
>>> def func2():
...     b'bytes'
...     (1, 2)
... 
>>> import dis; dis.dis(func2)
  2           0 LOAD_CONST               1 (b'bytes')
              3 POP_TOP

  3           4 LOAD_CONST               4 ((1, 2))
              7 POP_TOP
              8 LOAD_CONST               0 (None)
             11 RETURN_VALUE
----------------------------

I don't understand the point of loading a constant and then unload it (POP_TOP).


Attached patch changes the compiler to not emit LOAD_CONST+POP_TOP anymore.


My patch only affects constants. Example with the patch:
----------------------------
>>> def f():
...  x
... 
>>> import dis
>>> dis.dis(f)
  2           0 LOAD_GLOBAL              0 (x)
              3 POP_TOP
              4 LOAD_CONST               0 (None)
              7 RETURN_VALUE
----------------------------

The compiler still emits "LOAD_GLOBAL x" for the instruction "x".

Ignoring the Python instruction "x" would change the Python semantics, because the function would not raise a NameError anymore if x is not defined.

Note: I noticed this inefficient bytecode while working on the issue #26146 (add ast.Constant).

----------
components: Interpreter Core
files: compiler.patch
keywords: patch
messages: 258939
nosy: haypo, yselivanov
priority: normal
severity: normal
status: open
title: compiler: don't emit LOAD_CONST instructions for constant expressions?
versions: Python 3.6
Added file: http://bugs.python.org/file41716/compiler.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 20:01:06 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 01:01:06 +0000
Subject: [issue26204] compiler: don't emit LOAD_CONST instructions for
 constant statements?
In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>
Message-ID: <1453770066.31.0.858114067223.issue26204@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
title: compiler: don't emit LOAD_CONST instructions for constant expressions? -> compiler: don't emit LOAD_CONST instructions for constant statements?

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 20:40:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 01:40:33 +0000
Subject: [issue26201] Faster type checking in listobject.c
In-Reply-To: <1453749940.01.0.185085396815.issue26201@psf.upfronthosting.co.za>
Message-ID: <1453772433.36.0.751976524935.issue26201@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> As noted above, it not reasonable for a C-API that isn't used internally because there is no reasonable way to measure the effect without writing a C extension.

Come on, there is a lot of C functions in Python using the C PyList_xxx() API. It's easy to write a benchmark on it in pure Python. Example.


Without the patch (best of 10 runs):

$ for i in $(seq 1 10); do ./python -m timeit -s 's="a " * 10**5' 's.split()'; done
1000 loops, best of 3: 1.40 msec per loop

With the patch (best of 10 runs):

$ for i in $(seq 1 10); do ./python -m timeit -s 's="a " * 10**5' 's.split()'; done
1000 loops, best of 3: 1.49 msec per loop

It looks like list_check_fastpath2.diff makes PyList_Append() *slower* (6%) in practice. I expected it to be *faster*.


Please try to reproduce my microbenchmark, timeit is not really reliable, and I hate microbenchmarks, it's easy to make mistakes :-/

Note: It looks like s.split() creates a list of 'a' strings where all 'a' strings are the same singleton. So I don't think that creating substrings has an important cost.


> If you're going to be in the optimization business, I really wish you would read some of the basics in the field so that each and every technique doesn't have to be re-proved to you each time it used.

It's easy to convince me: show me a benchmark where your patch makes the code faster :-) I don't think that there is a strict rule for a miniumum speedup in CPython. I'm open for discussion :-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 20:41:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 01:41:52 +0000
Subject: [issue26201] Faster type checking in listobject.c
In-Reply-To: <1453749940.01.0.185085396815.issue26201@psf.upfronthosting.co.za>
Message-ID: <1453772512.63.0.877405456906.issue26201@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +pitrou, yselivanov

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 21:16:27 2016
From: report at bugs.python.org (Roscoe R.Higgins)
Date: Tue, 26 Jan 2016 02:16:27 +0000
Subject: [issue26205] Inconsistency concerning nested scopes
Message-ID: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>


New submission from Roscoe R.Higgins:

In chapter 9. Classes of the Python3.5 documentation it says: 

"At any time during execution, there are at least three nested scopes whose namespaces are directly accessible:",

followed by a list containing 4 items.
Further down a middle scope is mentioned (although mentioned by name). This was confusing for a while.

----------
assignee: docs at python
components: Documentation
messages: 258941
nosy: Roscoe R. Higgins, docs at python
priority: normal
severity: normal
status: open
title: Inconsistency concerning nested scopes
type: behavior
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 21:30:31 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Jan 2016 02:30:31 +0000
Subject: [issue26201] Faster type checking in listobject.c
In-Reply-To: <1453749940.01.0.185085396815.issue26201@psf.upfronthosting.co.za>
Message-ID: <1453775431.58.0.670539535577.issue26201@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I've lost interest in talking with you.  AFAICT you aren't doing anything to help advance or study the patch.  You're just being a PITA and are now enlisting people to gang-up on a trivial patch.  This is disgusting.

----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 21:45:10 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Jan 2016 02:45:10 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453776310.29.0.893493832677.issue26194@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Mark, Serhiy and Timmy, do you have any thoughts on what is the right behavior?

One option is to always pop the rightmost element to make room, but that results in a weird asymmetry between d.insert(len(d), item) and what d.append(item) would do.  I can't seem to come with a coherent set of invariants that doesn't have a surprising discontinuity.

Another option is to "refuse the temptation to guess" at what the user intends for the popped-off element to be and to raise an exception.  But that isn't very user friendly either.

----------
nosy: +mark.dickinson, serhiy.storchaka, tim.peters

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 22:12:33 2016
From: report at bugs.python.org (Fantix King)
Date: Tue, 26 Jan 2016 03:12:33 +0000
Subject: [issue23794] http package should support HTTP/2
In-Reply-To: <1427479110.25.0.801999785412.issue23794@psf.upfronthosting.co.za>
Message-ID: <1453777953.95.0.846806940545.issue23794@psf.upfronthosting.co.za>


Changes by Fantix King :


----------
nosy: +Fantix King

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 22:38:40 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Jan 2016 03:38:40 +0000
Subject: [issue18898] Apply the setobject optimizations to dictionaries
In-Reply-To: <1378012493.62.0.577402281969.issue18898@psf.upfronthosting.co.za>
Message-ID: <1453779520.47.0.194497469706.issue18898@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Hi, what's the status of this issue? Is anyone working one it?

In the present environment, I feel like advancing this work would be an uphill battle and that much of my time investment would be wasted unnecessarily.

That's too bad, because significant r&d time has already been invested and it has had nice payoffs with set objects.

----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 22:59:11 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Jan 2016 03:59:11 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453780751.6.0.860292011939.issue26194@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
keywords: +patch
Added file: http://bugs.python.org/file41717/full_deque.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 23:23:21 2016
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 26 Jan 2016 04:23:21 +0000
Subject: [issue26189] Interpreter returns control to cmd.exe early
In-Reply-To: <1453602542.98.0.731550634512.issue26189@psf.upfronthosting.co.za>
Message-ID: <1453782201.5.0.210485589702.issue26189@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> An .lnk is launched with ShellExecute which returns control
> immediately upon successful launch

cmd calls ShellExecuteEx, not ShellExecute, and it uses the flags SEE_MASK_NO_CONSOLE (0x8000, don't create a new console) and SEE_MASK_NOCLOSEPROCESS (0x0040, return a process handle if possible). 

Here's a walk-through with a debugger attached to cmd while executing a LNK shortcut to "C:\Program Files\Python27\python.exe": 

    C:\Temp>.\python.lnk -c "import sys,time;time.sleep(60);sys.exit(42)"
    Breakpoint 0 hit
    SHELL32!ShellExecuteExW:
    00007ff9`a5710e20 48895c2408      mov     qword ptr [rsp+8],rbx
                                        ss:000000a3`eb3af3a0=000000a3eb597ca0
    0:000> ; as /x info @rcx
    0:000> ; as /x sz @@(*((unsigned long *)${info}))
    0:000> bd 2,3,4; pt; be 2,3,4

ShellExecuteEx returns the process handle:

    0:000> ?? *((void **)(${info} + ${sz} - 8)); * hProcess
    void * 0x00000000`000002fc
    0:000> !handle 2fc
    Handle 2fc
      Type          Process
    0:000> g

cmd uses the handle to read the ImageSubsystem type from the process environment block (PEB), for which 3 is a console process and 2 is a GUI process.

    Breakpoint 1 hit
    cmd!GetProcessSubsystemType:
    00007ff7`a133faf4 48895c2410      mov     qword ptr [rsp+10h],rbx
                                        ss:000000a3`eb3af458=000000a3eb585640
    0:000> g
    Breakpoint 2 hit
    KERNELBASE!ReadProcessMemory:
    00007ff9`a49ac230 4883ec48        sub     rsp,48h
    0:000> as /x buf @r8
    0:000> pt
    KERNELBASE!ReadProcessMemory+0x2b:
    00007ff9`a49ac25b c3              ret

    0:000> ?? ((ntdll!_PEB *)${buf})->ImageSubsystem
    unsigned long 3
    0:000> g

Since it's a console process, cmd waits and queries the exit code.

    Breakpoint 3 hit    
    KERNELBASE!WaitForSingleObject:
    00007ff9`a49840c0 4533c0          xor     r8d,r8d
    0:000> r rcx
    rcx=00000000000002fc
    0:000> g

    Breakpoint 4 hit
    KERNELBASE!GetExitCodeProcess:
    00007ff9`a49c46d0 4053            push    rbx
    0:000> as /x rc @rdx
    0:000> pt
    KERNELBASE!GetExitCodeProcess+0x3a:
    00007ff9`a49c470a c3              ret
    0:000> ?? *((unsigned long *)${rc})
    unsigned long 0x2a
    0:000> ? 0x2a
    Evaluate expression: 42 = 00000000`0000002a

It sets the exit code in the 'hidden' environment variable "=ExitCode" as a unsigned hexadecimal number.

    C:\Temp>echo %=ExitCode%
    0000002A

You can also query the signed value using the pseudo environment variable "errorlevel".

    C:\Temp>echo %errorlevel%
    42

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 23:51:06 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 26 Jan 2016 04:51:06 +0000
Subject: [issue26204] compiler: don't emit LOAD_CONST instructions for
 constant statements?
In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>
Message-ID: <1453783866.0.0.39019099099.issue26204@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

The patch looks alright.

Will the following code compile OK?  What will it compile to?

   if 1:
      42

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 01:38:23 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Jan 2016 06:38:23 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453790303.44.0.872538997694.issue26194@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Another take: Do a regular insertion with no special cases, followed by a pop from the right:

>>> for i in range(len(d) + 1):
	s = list(d)
	s.insert(i, None)      
	_ = s.pop()
	print(i, s)
	
0 [None, 'a', 'b']
1 ['a', None, 'b']
2 ['a', 'b', None]
3 ['a', 'b', 'c']

Nice parts:
* Doesn't change pop direction depending on the inputs
* Guarantee that entries to the left of i will keep their position.
* Post condition of d[i]==newelem applies whenever i exists.

Not nice part:
* Initially surprising that d.insert(len(d), newelem) does not actually insert newelem.
* d.insert(len(d), newelem) not the same as d.append(newelem).

Another alternative is to raise an exception for the one case where index==maxlen, with the theory being that d[index] won't be a valid index so you can't insert anything there.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 02:24:36 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Jan 2016 07:24:36 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453793076.77.0.194506006558.issue26194@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


Added file: http://bugs.python.org/file41718/full_deque_alt.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 03:41:34 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Jan 2016 08:41:34 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453797694.34.0.320498499783.issue26194@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The plain-insert-followed-by-a-pop-on-the-right is giving reasonable results with nice properties:

d.insert(0, i)
-----------------------------------
0 --> deque([0], maxlen=4)
1 --> deque([1, 0], maxlen=4)
2 --> deque([2, 1, 0], maxlen=4)
3 --> deque([3, 2, 1, 0], maxlen=4)
4 --> deque([4, 3, 2, 1], maxlen=4)
5 --> deque([5, 4, 3, 2], maxlen=4)
6 --> deque([6, 5, 4, 3], maxlen=4)
7 --> deque([7, 6, 5, 4], maxlen=4)
8 --> deque([8, 7, 6, 5], maxlen=4)
9 --> deque([9, 8, 7, 6], maxlen=4)

d.insert(len(d), i)
-----------------------------------
0 --> deque([0], maxlen=4)
1 --> deque([0, 1], maxlen=4)
2 --> deque([0, 1, 2], maxlen=4)
3 --> deque([0, 1, 2, 3], maxlen=4)
4 --> deque([0, 1, 2, 3], maxlen=4)
5 --> deque([0, 1, 2, 3], maxlen=4)
6 --> deque([0, 1, 2, 3], maxlen=4)
7 --> deque([0, 1, 2, 3], maxlen=4)
8 --> deque([0, 1, 2, 3], maxlen=4)
9 --> deque([0, 1, 2, 3], maxlen=4)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 06:19:11 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 26 Jan 2016 11:19:11 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1453807151.54.0.00698509656964.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Serhiy, any chance you'd have some time to review my patch(es)? Or is there someone else interested in zipfile I might interest? Thanks :-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 07:24:08 2016
From: report at bugs.python.org (paul)
Date: Tue, 26 Jan 2016 12:24:08 +0000
Subject: [issue24683] Type confusion in json encoding
In-Reply-To: <1437548518.74.0.524291765031.issue24683@psf.upfronthosting.co.za>
Message-ID: <1453811048.07.0.17422465193.issue24683@psf.upfronthosting.co.za>


paul added the comment:

Proof of EIP control.

----------
Added file: http://bugs.python.org/file41719/eip.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 07:25:03 2016
From: report at bugs.python.org (paul)
Date: Tue, 26 Jan 2016 12:25:03 +0000
Subject: [issue24683] Type confusion in json encoding
In-Reply-To: <1437548518.74.0.524291765031.issue24683@psf.upfronthosting.co.za>
Message-ID: <1453811103.14.0.36476530515.issue24683@psf.upfronthosting.co.za>


paul added the comment:

GDB dump of running ./python eip.py

_______________________________________________________________________________
     eax:37A317DD ebx:B7A54268  ecx:BFFFE22C  edx:11223344     eflags:00010217
     esi:B7A61060 edi:B7AA6714  esp:BFFFE20C  ebp:B7A317DC     eip:11223344
     cs:0073  ds:007B  es:007B  fs:0000  gs:0033  ss:007B    o d I t s z A P C
[007B:BFFFE20C]---------------------------------------------------------[stack]
BFFFE23C : 10 FA A1 B7  60 10 A6 B7 - 68 42 A5 B7  00 60 A2 B7 ....`...hB...`..
BFFFE22C : 60 17 A6 B7  10 68 2B 08 - 00 60 A2 B7  DC 17 A3 B7 `....h+..`......
BFFFE21C : 2C E2 FF BF  DC 17 A3 B7 - 3C E2 FF BF  00 00 00 00 ,.......<.......
BFFFE20C : AE 07 0D 08  60 10 A6 B7 - 68 42 A5 B7  DD 17 A3 37 ....`...hB.....7
[0073:11223344]---------------------------------------------------------[ code]
=> 0x11223344:  Error while running hook_stop:
Cannot access memory at address 0x11223344
0x11223344 in ?? ()

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 08:02:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 13:02:10 +0000
Subject: [issue26206] test_socket.testRecvmsgPeek() timeout on "AMD64 Debian
 root 3.x" buildbot
Message-ID: <1453813330.04.0.627005992155.issue26206@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The bug started between build 3071 and 3072:
* http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/3071
* http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/3072

Maybe it's an issue on the buildbot, not on the code directly?

http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/3142/steps/test/logs/stdio

[300/400] test_socket
Timeout (1:00:00)!
Thread 0x00002b16599dab20 (most recent call first):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_socket.py", line 1920 in doRecvmsg
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_socket.py", line 2376 in testRecvmsgPeek
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/case.py", line 600 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/case.py", line 648 in __call__
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 122 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 122 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/runner.py", line 176 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/support/__init__.py", line 1780 in _run_suite
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/support/__init__.py", line 1814 in run_unittest
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_socket.py", line 5345 in test_main
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/runtest.py", line 162 in runtest_inner
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/runtest.py", line 115 in runtest
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/main.py", line 295 in run_tests_sequential
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/main.py", line 356 in run_tests
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/main.py", line 392 in main
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/main.py", line 433 in main
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/main.py", line 455 in main_in_temp_cwd
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/__main__.py", line 3 in 
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/runpy.py", line 85 in _run_code
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/runpy.py", line 184 in _run_module_as_main
make: *** [buildbottest] Error 1

----------
components: Tests
keywords: buildbot
messages: 258952
nosy: haypo
priority: normal
severity: normal
status: open
title: test_socket.testRecvmsgPeek() timeout on "AMD64 Debian root 3.x" buildbot
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 08:04:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 13:04:15 +0000
Subject: [issue26206] test_socket.testRecvmsgPeek() timeout on "AMD64 Debian
 root 3.x" buildbot
In-Reply-To: <1453813330.04.0.627005992155.issue26206@psf.upfronthosting.co.za>
Message-ID: <1453813455.43.0.399879035721.issue26206@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Info about the buildbot (regrtest headers):

== CPython 3.6.0a0 (default:fadc4b53b840, Jan 26 2016, 18:14:53) [GCC 4.7.2]
==   Linux-3.2.0-4-amd64-x86_64-with-debian-7.9 little-endian
==   hash algorithm: siphash24 64bit
==   /root/buildarea/3.x.angelico-debian-amd64/build/build/test_python_26835

Info about the failing test:

    @requireAttrs(socket, "MSG_PEEK")
    def testRecvmsgPeek(self):
        # Check that MSG_PEEK in flags enables examination of pending
        # data without consuming it.

The unit test is old, it was introduced in 2011:

changeset:   72029:c64216addd7f
parent:      72027:1702749b1060
user:        Nick Coghlan 
date:        Mon Aug 22 11:55:57 2011 +1000
files:       Doc/library/socket.rst Doc/whatsnew/3.3.rst Lib/ssl.py Lib/test/test_socket.py Lib/test/test_ssl.py Misc/NEWS Modules/socketmodule.c
description:
Add support for the send/recvmsg API to the socket module. Patch by David Watson and Heiko Wundram. (Closes #6560)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 08:04:48 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 13:04:48 +0000
Subject: [issue26206] test_socket.testRecvmsgPeek() timeout on "AMD64 Debian
 root 3.x" buildbot
In-Reply-To: <1453813330.04.0.627005992155.issue26206@psf.upfronthosting.co.za>
Message-ID: <1453813488.21.0.693367413667.issue26206@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +Rosuav

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 08:09:42 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 13:09:42 +0000
Subject: [issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot
Message-ID: <1453813782.88.0.185045860262.issue26207@psf.upfronthosting.co.za>


New submission from STINNER Victor:

It looks like the buildbot started to fail with the build http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/7166/

The change 37dc870175be43cdcb6920cc642a99fc10cd4bb4 of issue #25850 changed Lib/distutils/_msvccompiler.py: "Use cross-compilation by default for 64-bit Windows.". It's an interesting suspect.

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/7214/steps/test/logs/stdio

test test_distutils failed

======================================================================
ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\_msvccompiler.py", line 480, in link
    self.spawn([self.linker] + ld_args)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\_msvccompiler.py", line 503, in spawn
    return super().spawn(cmd)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\ccompiler.py", line 909, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\spawn.py", line 38, in spawn
    _spawn_nt(cmd, search_path, dry_run=dry_run)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\spawn.py", line 81, in _spawn_nt
    "command %r failed with exit status %d" % (cmd, rc))
distutils.errors.DistutilsExecError: command 'C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\BIN\\x86_amd64\\link.exe' failed with exit status 1101

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\tests\test_install.py", line 215, in test_record_extensions
    cmd.run()
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\command\install.py", line 539, in run
    self.run_command('build')
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\dist.py", line 974, in run_command
    cmd_obj.run()
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\command\build.py", line 135, in run
    self.run_command(cmd_name)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\dist.py", line 974, in run_command
    cmd_obj.run()
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\command\build_ext.py", line 338, in run
    self.build_extensions()
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\command\build_ext.py", line 447, in build_extensions
    self._build_extensions_serial()
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\command\build_ext.py", line 472, in _build_extensions_serial
    self.build_extension(ext)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\command\build_ext.py", line 557, in build_extension
    target_lang=language)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\ccompiler.py", line 717, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\_msvccompiler.py", line 483, in link
    raise LinkError(msg)
distutils.errors.LinkError: command 'C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\BIN\\x86_amd64\\link.exe' failed with exit status 1101

----------
components: Tests, Windows
keywords: buildbot
messages: 258954
nosy: haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 08:10:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 13:10:03 +0000
Subject: [issue25850] Building extensions with MSVC 2015 Express fails
In-Reply-To: <1449955225.5.0.401578921369.issue25850@psf.upfronthosting.co.za>
Message-ID: <1453813803.89.0.150075814836.issue25850@psf.upfronthosting.co.za>


STINNER Victor added the comment:

test_distutils is now failing on "AMD64 Windows7 SP1 3.x" buildbot: please see issue #26207.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 08:11:06 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 13:11:06 +0000
Subject: [issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot
In-Reply-To: <1453813782.88.0.185045860262.issue26207@psf.upfronthosting.co.za>
Message-ID: <1453813866.4.0.324163449181.issue26207@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Same issue on Windows 8 and Windows 10 buildbots:

* http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x/builds/1716/steps/test/logs/stdio
* http://buildbot.python.org/all/builders/AMD64%20Windows10%203.x/builds/598/steps/test/logs/stdio

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 08:52:00 2016
From: report at bugs.python.org (Jeremy Kloth)
Date: Tue, 26 Jan 2016 13:52:00 +0000
Subject: [issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot
In-Reply-To: <1453813782.88.0.185045860262.issue26207@psf.upfronthosting.co.za>
Message-ID: <1453816320.41.0.671296923901.issue26207@psf.upfronthosting.co.za>


Changes by Jeremy Kloth :


----------
nosy: +jkloth

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 09:08:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Jan 2016 14:08:30 +0000
Subject: [issue26198] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1453817310.99.0.912695925173.issue26198@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch fixes minor bugs in Python/getargs.c:

1. Replaces TypeError with confusing error message for buffer overflow for "es#" and "et#" format units to ValueError with correct error message. Due to the risk to break working code, may be we will left TypeError in maintained releases, but error message should be fixed in any case.

2. Replaces all other TypeError with confusing error message to SystemError with correct error message. All this errors are programming errors (incorrect use of PyArg_Parse* functions) and aren't occurred in valid extensions.

3. Fixes error messages for "k" and "K" format units.

4. Fixes error messages for "es" and "et" format units.

5. Fixes error messages for "compat" mode (looks as this mode is not used and can be freely removed in Python 3).

----------
assignee: docs at python -> serhiy.storchaka
nosy: +serhiy.storchaka
stage:  -> patch review
versions: +Python 3.6
Added file: http://bugs.python.org/file41720/pyarg_parse_encoded_string.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 09:17:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Jan 2016 14:17:38 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1453817858.72.0.0341988087022.issue26039@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Your patches are great Thomas! This is just what I want to implement. It will take some time to make a careful review. Besides possible corrections I think these features will be added in 3.6. But new features need tests and documenting.

----------
assignee:  -> serhiy.storchaka
stage:  -> test needed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 09:19:06 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 26 Jan 2016 14:19:06 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1453817946.74.0.0373988388346.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Thanks! I will work on docs and tests.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 09:29:23 2016
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Tue, 26 Jan 2016 14:29:23 +0000
Subject: [issue26198] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1453818562.99.0.0301241636143.issue26198@psf.upfronthosting.co.za>


Hrvoje Nik?i? added the comment:

Barun, Serhiy, thanks for picking this up so quickly.

I would further suggest to avoid using a fixed buffer in abspath (_getfullpathname, but only abspath seems to call it). Other filesystem calls are using the interface where PyArg_ParseTuple allocates the buffer. This makes it easier to handling errors from the native layer by catching OSError or similar, instead of the very generic TypeError (or ValueError).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 12:11:03 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Jan 2016 17:11:03 +0000
Subject: [issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot
In-Reply-To: <1453813782.88.0.185045860262.issue26207@psf.upfronthosting.co.za>
Message-ID: <1453828263.35.0.388368290806.issue26207@psf.upfronthosting.co.za>


Steve Dower added the comment:

So the more interesting error message is higher up:

xxmodule.c
xxmodule.obj : warning LNK4197: export 'PyInit_xx' specified multiple times; using first specification
   Creating library d:\temp\tmptzty591d\Debug\temp\tmptzty591d\xx_d.cp36-win_amd64.lib and object d:\temp\tmptzty591d\Debug\temp\tmptzty591d\xx_d.cp36-win_amd64.exp
LINK : /LTCG specified but no code generation required; remove /LTCG from the link command line to improve linker performance
LINK : fatal error LNK1101: incorrect MSPDB140.DLL version; recheck installation of this product

It's entirely possible that this was an issue with VS 2015 that has been resolved in VS 2015 Update 1. Let me check with some people who may know.

In the meantime, it would be handy if the owners could confirm that the buildbots are running VS 2015 and not Update 1 (released in November, so if you haven't installed anything that recently then it's unrelated). Also the full version numbers of the following files:

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\mspdb140.dll
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\link.exe
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_arm\link.exe

----------
assignee:  -> steve.dower

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 12:14:46 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Jan 2016 17:14:46 +0000
Subject: [issue19698] Implement _imp.exec_builtin and exec_dynamic
In-Reply-To: <1385137675.64.0.235823443194.issue19698@psf.upfronthosting.co.za>
Message-ID: <1453828486.04.0.92277403838.issue19698@psf.upfronthosting.co.za>


Brett Cannon added the comment:

At this point both FrozenImporter and BuiltinImporter support exec_module(), so the only thing left to do is to document when FrozenImporter and WindowsRegistryFinder gained their exec_module() implementations (BuiltinImporter already has a note about it).

----------
assignee:  -> docs at python
keywords: +easy
nosy: +docs at python
priority: critical -> low
stage: test needed -> needs patch
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 12:32:17 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 26 Jan 2016 17:32:17 +0000
Subject: [issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot
In-Reply-To: <1453813782.88.0.185045860262.issue26207@psf.upfronthosting.co.za>
Message-ID: <1453829537.46.0.0146820024545.issue26207@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Steve, I'm assuming you meant "x86_amd64" rather than "x86_arm" on that last filename?

Note that this issue is restricted to Debug builds (as suggested by the issue being with mspdb140.dll), the Non-Debug buildbot is not failing.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 12:32:53 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Jan 2016 17:32:53 +0000
Subject: [issue26203] nesting venv in virtualenv segfaults
In-Reply-To: <1453755990.33.0.69898482015.issue26203@psf.upfronthosting.co.za>
Message-ID: <1453829573.58.0.052405487265.issue26203@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 12:37:16 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Jan 2016 17:37:16 +0000
Subject: [issue26205] Inconsistency concerning nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1453829836.18.0.766099149415.issue26205@psf.upfronthosting.co.za>


Brett Cannon added the comment:

https://docs.python.org/3/tutorial/classes.html for the docs that Roscoe is talking about.

So the sentence is technically correct, it just takes careful reading to grasp what's being said. There are "at least three nested scopes", but there can be *up to* four scopes. Since "the scopes of any enclosing functions" is not necessarily true for all code scopes, you end up with at least three, but possibly four scopes.

Obviously the wording could be clearer, so if you want to sign the CLA, Roscoe, and propose a rewording that would be appreciated!

----------
nosy: +brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 12:46:59 2016
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 26 Jan 2016 17:46:59 +0000
Subject: [issue26208] decimal C module's exceptions don't match the Python
 version
Message-ID: <1453830419.58.0.782557332566.issue26208@psf.upfronthosting.co.za>


New submission from Petr Viktorin:

Exceptions from the decimal module are quite unfriendly:

    >>> Decimal(42) / Decimal(0)
    ...
    decimal.DivisionByZero: []

    >>> huge = Decimal('9' * 99)
    >>> huge.quantize(Decimal('0.1'))
    ...
    decimal.InvalidOperation: []


compared to the pure Python implementation:

    decimal.DivisionByZero: x / 0

    decimal.InvalidOperation: quantize result has too many digits for current context


If I'm reading http://bugs.python.org/issue21227 right, the exception argument is a of signals, and indicates the complete set of signals raised by the operation. However, this is (AFAICS) not documented, and not portable (since it's not present in the Python version).

I believe this behavior should be
- either dropped in favor of friendlier error messages (or possibly moved to a more internal attribute of the exception, and documented as an optional CPython feature),
- or documented, and implemented in _pydecimal as well.

Which of those actions would be right seems to be a question of whether the exception argument is part of the API.

----------
components: Library (Lib)
messages: 258965
nosy: encukou, skrah
priority: normal
severity: normal
status: open
title: decimal C module's exceptions don't match the Python version

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 14:11:53 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Jan 2016 19:11:53 +0000
Subject: [issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot
In-Reply-To: <1453813782.88.0.185045860262.issue26207@psf.upfronthosting.co.za>
Message-ID: <1453835513.34.0.0522582901881.issue26207@psf.upfronthosting.co.za>


Steve Dower added the comment:

Yep, that's what I meant. So many cross compilers these days...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 14:22:30 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 19:22:30 +0000
Subject: [issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot
In-Reply-To: <1453813782.88.0.185045860262.issue26207@psf.upfronthosting.co.za>
Message-ID: <1453836150.21.0.772174675228.issue26207@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> It's entirely possible that this was an issue with VS 2015 that has been resolved in VS 2015 Update 1. Let me check with some people who may know.

If a fix cannot be found quickly, would it be possible to revert the Python change until VS is fixed and the fix is deployed to all buildbots? I'm trying to keep green buildbots. It helps me to validate my work on multiple platforms ;)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 14:25:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Jan 2016 19:25:56 +0000
Subject: [issue26204] compiler: don't emit LOAD_CONST instructions for
 constant statements?
In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>
Message-ID: <1453836356.55.0.302144628288.issue26204@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

It looks to me that this optimization was added to avoid spending executing time for docstrings. Other cases almost never occur in real code and are not worth to be optimized. But the patch makes the code cleaner (it would even more cleaner if collapse all kinds of constants in Constant).

----------
nosy: +serhiy.storchaka
stage:  -> commit review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 14:29:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Jan 2016 19:29:11 +0000
Subject: [issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot
In-Reply-To: <1453813782.88.0.185045860262.issue26207@psf.upfronthosting.co.za>
Message-ID: <1453836551.7.0.380331226089.issue26207@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It would be easier to just temporary skip some tests on particular platforms.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 14:46:03 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Jan 2016 19:46:03 +0000
Subject: [issue26208] decimal C module's exceptions don't match the Python
 version
In-Reply-To: <1453830419.58.0.782557332566.issue26208@psf.upfronthosting.co.za>
Message-ID: <1453837563.79.0.63943729582.issue26208@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

If it doesn't take too much effort, I would like the see the exception messages made more user friendly and kept more in-sync with the pure Python version.

----------
assignee:  -> skrah
nosy: +rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 15:34:38 2016
From: report at bugs.python.org (Lorenzo Ancora)
Date: Tue, 26 Jan 2016 20:34:38 +0000
Subject: [issue26209] TypeError in smtpd module with string arguments
Message-ID: <1453840478.59.0.371405366995.issue26209@psf.upfronthosting.co.za>


New submission from Lorenzo Ancora:

smtpd.PureProxy(localaddr="host1", remoteaddr="host2")

...produces the error:

[...] smtpd.py", line 657, in __init__
    gai_results = socket.getaddrinfo(*localaddr, type=socket.SOCK_STREAM)
TypeError: getaddrinfo() got multiple values for argument 'type'

The module only works with:

smtpd.PureProxy(localaddr=("host1", 25), remoteaddr=("host2", 25))

The documentation does not specify the format of the INPUT parameters, only the CLI syntax with hostnames as "host:port" strings.
The underlying library should convert them to tuples or at least the documentation should be completed.

----------
components: Library (Lib)
messages: 258971
nosy: lorenzo.ancora
priority: normal
severity: normal
status: open
title: TypeError in smtpd module with string arguments
type: behavior
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 15:42:18 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 26 Jan 2016 20:42:18 +0000
Subject: [issue26209] TypeError in smtpd module with string arguments
In-Reply-To: <1453840478.59.0.371405366995.issue26209@psf.upfronthosting.co.za>
Message-ID: <1453840938.37.0.839755097244.issue26209@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 15:54:11 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Jan 2016 20:54:11 +0000
Subject: [issue26208] decimal C module's exceptions don't match the Python
 version
In-Reply-To: <1453830419.58.0.782557332566.issue26208@psf.upfronthosting.co.za>
Message-ID: <1453841651.77.0.585197149549.issue26208@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Yes, ideally the exceptions should be in sync. I don't find the list
of signals entirely uninteresting, but implementing it in _pydecimal
would require #8613 to be solved, which is unlikely to happen.


In _decimal the exceptions come directly from libmpdec, so in order
to have the same error messages as _pydecimal I'd need to implement
detailed error codes and store them somewhere in the context.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 15:54:46 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Jan 2016 20:54:46 +0000
Subject: [issue26208] decimal C module's exceptions don't match the Python
 version
In-Reply-To: <1453830419.58.0.782557332566.issue26208@psf.upfronthosting.co.za>
Message-ID: <1453841686.62.0.395520850992.issue26208@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 16:10:08 2016
From: report at bugs.python.org (=?utf-8?q?Yannick_Duch=C3=AAne?=)
Date: Tue, 26 Jan 2016 21:10:08 +0000
Subject: [issue26210] `HTMLParser.handle_data` may be invoked although
 `HTMLParser.reset` was invoked
Message-ID: <1453842608.52.0.40675264133.issue26210@psf.upfronthosting.co.za>


New submission from Yannick Duch?ne:

`HTMLParser.handle_data` may be invoked although `HTMLParser.reset` was invoked. This occurs at least when `HTMLParser.reset` was invoked during `HTMLParser.handle_endtag`.

According to the documentation, `HTMLParser.reset` discard all data, so it should immediately stop the parser.

Additionally as an aside, it's strange `HTMLParser.reset` is invoked during object creation as it's invoking a method on an object which is potentially not entirely initialized (that matters with derived classes).

----------
components: Library (Lib)
messages: 258973
nosy: Hibou57
priority: normal
severity: normal
status: open
title: `HTMLParser.handle_data` may be invoked although `HTMLParser.reset` was invoked
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 16:34:00 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Jan 2016 21:34:00 +0000
Subject: [issue26201] Faster type checking in listobject.c
In-Reply-To: <1453749940.01.0.185085396815.issue26201@psf.upfronthosting.co.za>
Message-ID: <1453844040.55.0.443845348529.issue26201@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
Removed message: http://bugs.python.org/msg258942

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 16:36:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 21:36:27 +0000
Subject: [issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot
In-Reply-To: <1453836551.7.0.380331226089.issue26207@psf.upfronthosting.co.za>
Message-ID: 


STINNER Victor added the comment:

Serhiy Storchaka added the comment:
> It would be easier to just temporary skip some tests on particular platforms.

Ah yes, I also like this option. Well, it's up to you Steve :-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 16:47:21 2016
From: report at bugs.python.org (=?utf-8?q?Yannick_Duch=C3=AAne?=)
Date: Tue, 26 Jan 2016 21:47:21 +0000
Subject: =?utf-8?q?=5Bissue26211=5D_HTMLParser=3A_=E2=80=9CAssertionError=3A_we_sh?=
 =?utf-8?q?ould_not_get_here!=E2=80=9D?=
Message-ID: <1453844837.54.0.120197785601.issue26211@psf.upfronthosting.co.za>


New submission from Yannick Duch?ne:

Using HTMLParser on the attached file, I got this:

      File "/usr/lib/python3.5/html/parser.py", line 111, in feed
        self.goahead(0)
      File "/usr/lib/python3.5/html/parser.py", line 171, in goahead
        k = self.parse_starttag(i)
      File "/usr/lib/python3.5/html/parser.py", line 303, in parse_starttag
        endpos = self.check_for_whole_start_tag(i)
      File "/usr/lib/python3.5/html/parser.py", line 383, in check_for_whole_start_tag
        raise AssertionError("we should not get here!")
    AssertionError: we should not get here!

The file purposely contains an error, as I was to check the behaviour of my application in the case of this error???I finally triggered one in the library :-P

----------
components: Library (Lib)
files: sample.html
messages: 258975
nosy: Hibou57
priority: normal
severity: normal
status: open
title: HTMLParser: ?AssertionError: we should not get here!?
versions: Python 3.5
Added file: http://bugs.python.org/file41721/sample.html

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 17:01:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 22:01:33 +0000
Subject: [issue26204] compiler: don't emit LOAD_CONST instructions for
 constant statements?
In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>
Message-ID: <1453845693.38.0.0964972703029.issue26204@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy: "It looks to me that this optimization was added to avoid spending executing time for docstrings."

Hum, let me dig Mercurial history.
----
changeset:   39364:8ef3f8cf90e1
branch:      legacy-trunk
user:        Neal Norwitz 
date:        Fri Aug 04 05:09:28 2006 +0000
files:       Lib/test/test_code.py Misc/NEWS Python/compile.c
description:
Bug #1333982: string/number constants were inappropriately stored
in the byte code and co_consts even if they were not used, ie
immediately popped off the stack.
---

https://bugs.python.org/issue1333982#msg26659:
"For reference, an optimization that got lost: (...) 'a' is the docstring, but the 'b' previously did not show up anywhere in the code object.  Now there is the LOAD_CONST/POP_TOP pair."

Ah, it was a regression introduced by the new AST compiler. But the change introduced a new optimization: numbers are now also ignored. In Python 2.4 (before AST), numbers were not ignored:
---
>>> def f():
...  "a"
...  1
...  "b"
... 

>>> import dis; dis.dis(f)
  3           0 LOAD_CONST               1 (1)
              3 POP_TOP             
              4 LOAD_CONST               2 (None)
              7 RETURN_VALUE        
---


If we continue to dig deeper, before AST, I found:
---
changeset:   4991:8276916e1ea8
branch:      legacy-trunk
user:        Guido van Rossum 
date:        Fri Jan 17 21:04:03 1997 +0000
files:       Python/compile.c
description:
Add co_stacksize field to codeobject structure, and stacksize argument
to PyCode_New() argument list.  Move MAXBLOCKS constant to conpile.h.

Added accurate calculation of the actual stack size needed by the
generated code.

Also commented out all fprintf statements (except for a new one to
diagnose stack underflow, and one in #ifdef'ed out code), and added
some new TO DO suggestions (now that the stacksize is taken of the TO
DO list).
---

This patch added the following code to com_expr_stmt() in Python/compile.c:

+       /* Forget it if we have just a doc string here */
+       if (NCH(n) == 1 && get_rawdocstring(n) != NULL)
+               return;

I'm unable to find the exact part of the compiler which ignores strings in statement expressions.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 17:05:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 22:05:19 +0000
Subject: [issue26204] compiler: don't emit LOAD_CONST instructions for
 constant statements?
In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>
Message-ID: <1453845919.69.0.439646073362.issue26204@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"""
Will the following code compile OK?  What will it compile to?

   if 1:
      42
"""

compile OK: what do you mean? This code doesn't make any sense to me :-)


Currently text strings statements are ignored:
---
>>> def f():
...  if 1:
...   "abc"
... 
>>> import dis
>>> dis.dis(f)
  3           0 LOAD_CONST               0 (None)
              3 RETURN_VALUE
---


But byte strings emit a LOAD_CONST+POP_TOP:
---
>>> def g():
...  if 1:
...   b'bytes'
... 
>>> dis.dis(g)
  3           0 LOAD_CONST               1 (b'bytes')
              3 POP_TOP
              4 LOAD_CONST               0 (None)
              7 RETURN_VALUE
---


With my patch, all constants statements will be ignored. Example with my patch:
---
>>> def h():
...  if 1:
...   b'bytes'
... 
>>> import dis; dis.dis(h)
  3           0 LOAD_CONST               0 (None)
              3 RETURN_VALUE
---

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 17:07:13 2016
From: report at bugs.python.org (=?utf-8?q?Yannick_Duch=C3=AAne?=)
Date: Tue, 26 Jan 2016 22:07:13 +0000
Subject: [issue26205] Inconsistency concerning nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1453846033.76.0.995363799979.issue26205@psf.upfronthosting.co.za>


Yannick Duch?ne added the comment:

Better at least two, if I'm not wrong: the innermost scope may be the module's scope. So there is always at least the module scope and the built?ins scope, at least two up to four.

(if I have not overlooked something)

----------
nosy: +Hibou57

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 17:09:08 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 22:09:08 +0000
Subject: [issue26204] compiler: don't emit LOAD_CONST instructions for
 constant statements?
In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>
Message-ID: <1453846148.27.0.154927762061.issue26204@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy: "It looks to me that this optimization was added to avoid spending executing time for docstrings. Other cases almost never occur in real code and are not worth to be optimized. But the patch makes the code cleaner (it would even more cleaner if collapse all kinds of constants in Constant)."

Oh, I don't really care of performance. The bytecode just doesn't make any sense to me. I don't understand why we load a constant.

Maybe the compiler should emit a warning to say that the code doesn't make sense at all and is ignored?

Example with GCC:

$ cat x.c 
int main()
{
    1;
}


$ gcc x.c -Wall -o x
x.c: In function 'main':
x.c:3:5: warning: statement with no effect [-Wunused-value]
     1;
     ^

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 17:21:50 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Jan 2016 22:21:50 +0000
Subject: [issue26205] Inconsistency concerning nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1453846910.85.0.615159782017.issue26205@psf.upfronthosting.co.za>


Brett Cannon added the comment:

It depends on how you want to view things as to whether you can claim there are two or three scopes for module-level code. While it's true that the local scope operates just like global scope, to Python it's more like local == global rather than the local scope simply doesn't exist (hence why `locals()` never throws an exception saying the scope doesn't exist but instead is the same as `globals()`).

The "three scope" phrasing also predates nested scopes from back when Python had its LGB scoping rules: Local-Global-Builtin. Back then we just said Python had three scopes and left it at that since it was basically always true and didn't confuse anyone.

At this point I'm fine with just removing the number from the sentence and saying something like "At any time during execution, there are various nested scopes whose namespaces are directly accessible:".

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 17:22:08 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Jan 2016 22:22:08 +0000
Subject: [issue26205] Inconsistency concerning nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1453846928.91.0.299722489205.issue26205@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
stage:  -> needs patch
type: behavior -> 
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 17:33:02 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 22:33:02 +0000
Subject: [issue26204] compiler: don't emit LOAD_CONST instructions for
 constant statements?
In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>
Message-ID: <1453847582.53.0.0969666623432.issue26204@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Maybe the compiler should emit a warning to say that the code doesn't make sense at all and is ignored?

Oh ok, now I recall a similar issue that I posted 3 years ago: issue #17516, "Dead code should be removed".

Example of suspicious code:

def func():
   func2(),

func() calls func2() and then create a tuple of 1 item with the func2() result. See my changeset 33bdd0a985b9 for examples in the Python source code. The parser or compiler should maybe help to developer to catch such strange code :-)

In some cases, the code really contains code explicitly dead:

def test_func():
   return
   do_real_stuff()

do_real_stuff() is never called. Maybe it was a deliberate choice, maybe it was a mistake in a very old code base, bug introduced after multiple refactoring, and high turn over in a team? Again, we should emit a warning on such case?

Hum, these warnings have a larger scope than this specific issue (don't emit LOAD_CONST for constants in expressions).

See also the related thread on python-dev for the specific case of triple quoted strings ("""string"""): https://mail.python.org/pipermail/python-dev/2013-March/124925.html

It was admitted that it's a convenient way to insert a comment and it must not emit a warning (at least, not by default?)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 17:39:17 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 22:39:17 +0000
Subject: [issue26204] compiler: ignore constants used as statements? (don't
 emit LOAD_CONST+POP_TOP)
In-Reply-To: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>
Message-ID: <1453847957.44.0.118040184351.issue26204@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
title: compiler: don't emit LOAD_CONST instructions for constant statements? -> compiler: ignore constants used as statements? (don't emit LOAD_CONST+POP_TOP)

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 17:50:28 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Tue, 26 Jan 2016 22:50:28 +0000
Subject: [issue24905] Allow incremental I/O to blobs in sqlite3
In-Reply-To: <1440144321.97.0.0781853247945.issue24905@psf.upfronthosting.co.za>
Message-ID: <1453848628.43.0.675886248837.issue24905@psf.upfronthosting.co.za>


Changes by Aviv Palivoda :


----------
nosy: +palaviv

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 18:11:56 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Jan 2016 23:11:56 +0000
Subject: [issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit
 constants
In-Reply-To: <1453136691.51.0.69393755181.issue26146@psf.upfronthosting.co.za>
Message-ID: <20160126231153.24735.25294@psf.io>


Roundup Robot added the comment:

New changeset c5df914e73ad by Victor Stinner in branch 'default':
Fix a refleak in validate_constant()
https://hg.python.org/cpython/rev/c5df914e73ad

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 18:39:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Jan 2016 23:39:49 +0000
Subject: [issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit
 constants
In-Reply-To: <1453136691.51.0.69393755181.issue26146@psf.upfronthosting.co.za>
Message-ID: <20160126233946.64612.10736@psf.io>


Roundup Robot added the comment:

New changeset 04444d0d0a05 by Victor Stinner in branch 'default':
Issue #26146: remove useless code
https://hg.python.org/cpython/rev/04444d0d0a05

New changeset 58086f0a953a by Victor Stinner in branch 'default':
Issue #26146: enhance ast.Constant error message
https://hg.python.org/cpython/rev/58086f0a953a

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 18:40:33 2016
From: report at bugs.python.org (R. Jones)
Date: Tue, 26 Jan 2016 23:40:33 +0000
Subject: [issue26212] Python with ncurses6.0 will not load _curses module.
Message-ID: <1453851633.31.0.356555678785.issue26212@psf.upfronthosting.co.za>


New submission from R. Jones:

I am trying to compile Python-2.7.10.  This is being done as a user, not root and I don't have access to /usr/local other than to avoid all the broken stuff in it.

My local is /appl/local

I am installing Python in /appl/local/python-2.7.10

I have ncursest as part of my /appl/local, but python keeps wanting to link with /usr/ccs/lib/libcurses.so.  UGH.
"ncursest" was built instead of "ncurses" because I used "--with-pthread" and "--enable-reentrant"


I rebuilt ncurses without those two flags but with --with-termlib which built libtinfo.so.  When compiling the _curses module, I get this error:

*** WARNING: renaming "_curses" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.10-sun4u.32bit-2.7/_curses.so: symbol _unctrl: referenced symbol not found

In this case I can see unctrl is in tinfo...but no matter what I do, I cannot get it to add -ltinfo to the link line.

$ nm -s libtinfo.so | grep unctrl
0001d4f8 T unctrl
00039170 r unctrl_blob.5682
00039070 r unctrl_c1.5681
0001d30c T unctrl_sp
00039572 r unctrl_table.5680


So my next attempt was to make a private copy of ncurses for Python without --with-termlib, but had to add --enable-termcap and install it in /appl/local/python-2.7.10/lib

$ ls -al /appl/local/python-2.7.10/lib
total 15584
drwxr-xr-x   4 gfp-ip   gfp-ip      1024 Jan 26 16:45 .
drwxr-xr-x   6 gfp-ip   gfp-ip        96 Jan 26 15:31 ..
-rw-r--r--   1 gfp-ip   gfp-ip    120560 Jan 26 15:32 libform.a
-rwxr-xr-x   1 gfp-ip   gfp-ip      1055 Jan 26 15:32 libform.la
lrwxrwxrwx   1 gfp-ip   gfp-ip        16 Jan 26 15:32 libform.so -> libform.so.6.0.0
lrwxrwxrwx   1 gfp-ip   gfp-ip        16 Jan 26 15:32 libform.so.6 -> libform.so.6.0.0
-rwxr-xr-x   1 gfp-ip   gfp-ip     95604 Jan 26 15:32 libform.so.6.0.0
-rw-r--r--   1 gfp-ip   gfp-ip     61908 Jan 26 15:32 libmenu.a
-rwxr-xr-x   1 gfp-ip   gfp-ip      1055 Jan 26 15:32 libmenu.la
lrwxrwxrwx   1 gfp-ip   gfp-ip        16 Jan 26 15:32 libmenu.so -> libmenu.so.6.0.0
lrwxrwxrwx   1 gfp-ip   gfp-ip        16 Jan 26 15:32 libmenu.so.6 -> libmenu.so.6.0.0
-rwxr-xr-x   1 gfp-ip   gfp-ip     48060 Jan 26 15:32 libmenu.so.6.0.0
-rw-r--r--   1 gfp-ip   gfp-ip    174364 Jan 26 15:32 libncurses++.a
-rwxr-xr-x   1 gfp-ip   gfp-ip      1295 Jan 26 15:32 libncurses++.la
lrwxrwxrwx   1 gfp-ip   gfp-ip        21 Jan 26 15:32 libncurses++.so -> libncurses++.so.6.0.0
lrwxrwxrwx   1 gfp-ip   gfp-ip        21 Jan 26 15:32 libncurses++.so.6 -> libncurses++.so.6.0.0
-rwxr-xr-x   1 gfp-ip   gfp-ip    114812 Jan 26 15:32 libncurses++.so.6.0.0
-rw-r--r--   1 gfp-ip   gfp-ip    628332 Jan 26 15:31 libncurses.a
-rwxr-xr-x   1 gfp-ip   gfp-ip      1019 Jan 26 15:31 libncurses.la
lrwxrwxrwx   1 gfp-ip   gfp-ip        19 Jan 26 15:31 libncurses.so -> libncurses.so.6.0.0
lrwxrwxrwx   1 gfp-ip   gfp-ip        19 Jan 26 15:31 libncurses.so.6 -> libncurses.so.6.0.0
-rwxr-xr-x   1 gfp-ip   gfp-ip    478356 Jan 26 15:31 libncurses.so.6.0.0
-rw-r--r--   1 gfp-ip   gfp-ip     26324 Jan 26 15:31 libpanel.a
-rwxr-xr-x   1 gfp-ip   gfp-ip      1062 Jan 26 15:31 libpanel.la
lrwxrwxrwx   1 gfp-ip   gfp-ip        17 Jan 26 15:31 libpanel.so -> libpanel.so.6.0.0
lrwxrwxrwx   1 gfp-ip   gfp-ip        17 Jan 26 15:31 libpanel.so.6 -> libpanel.so.6.0.0
-rwxr-xr-x   1 gfp-ip   gfp-ip     23652 Jan 26 15:31 libpanel.so.6.0.0

$ nm /appl/local/python-2.7.10/lib/libncurses.so | grep unctrl
0004acac T unctrl
00067540 r unctrl_blob.5717
00067440 r unctrl_c1.5716
0004aac0 T unctrl_sp
00067942 r unctrl_table.5715

So ONCE again, compiling Python module _curses with the new lib:
Script started on Tue Jan 26 19:36:55 2016
$ make
running build
running build_ext
building dbm using ndbm
building '_curses' extension
gcc -fPIC -fno-strict-aliasing -I/appl/local/python-2.7.10/include -I/appl/local/include -DNCURSES_OPAQUE=0 -DNCURSES_REENTRANT=0 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/appl/local/python-2.7.10/include -I/appl/local/include -I/usr/local/include -I/appl/logs/local_build/src/python.org/Python-2.7.10/Include -I/appl/logs/local_build/src/python.org/Python-2.7.10 -c /appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_cursesmodule.c -o build/temp.solaris-2.10-sun4u.32bit-2.7/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_cursesmodule.o
/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_cursesmodule.c: In function 'PyCursesWindow_ChgAt':
/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_cursesmodule.c:713:9: warning: implicit declaration of function 'mvwchgat' [-Wimplicit-function-declaration]
/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_cursesmodule.c:717:9: warning: implicit declaration of function 'wchgat' [-Wimplicit-function-declaration]
gcc -shared -L/appl/local/python-2.7.10/lib -Wl,-rpath,/appl/local/python-2.7.10/lib -lncurses -R/appl/local/python-2.7.10/lib -L/appl/local/lib -L/appl/local/python-2.7.10/lib -Wl,-rpath,/appl/local/python-2.7.10/lib -lncurses -R/appl/local/python-2.7.10/lib -L/appl/local/lib -fno-strict-aliasing -I/appl/local/python-2.7.10/include -I/appl/local/include -DNCURSES_OPAQUE=0 -DNCURSES_REENTRANT=0 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/appl/local/python-2.7.10/include -I/appl/local/include -DNCURSES_OPAQUE=0 -DNCURSES_REENTRANT=0 build/temp.solaris-2.10-sun4u.32bit-2.7/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_cursesmodule.o -L/appl/local/python-2.7.10/lib -L/appl/local/lib -L/usr/local/lib -L. -Wl,-R/appl/local/python-2.7.10/lib -lncurses -lpython2.7 -o build/lib.solaris-2.10-sun4u.32bit-2.7/_curses.so

*** WARNING: renaming "_curses" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.10-sun4u.32bit-2.7/_curses.so: symbol _unctrl: referenced symbol not found

building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -I/appl/local/python-2.7.10/include -I/appl/local/include -DNCURSES_OPAQUE=0 -DNCURSES_REENTRANT=0 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/appl/local/python-2.7.10/include -I/appl/local/include -I/usr/local/include -I/appl/logs/local_build/src/python.org/Python-2.7.10/Include -I/appl/logs/local_build/src/python.org/Python-2.7.10 -c /appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_curses_panel.c -o build/temp.solaris-2.10-sun4u.32bit-2.7/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_curses_panel.o
gcc -shared -L/appl/local/python-2.7.10/lib -Wl,-rpath,/appl/local/python-2.7.10/lib -lncurses -R/appl/local/python-2.7.10/lib -L/appl/local/lib -L/appl/local/python-2.7.10/lib -Wl,-rpath,/appl/local/python-2.7.10/lib -lncurses -R/appl/local/python-2.7.10/lib -L/appl/local/lib -fno-strict-aliasing -I/appl/local/python-2.7.10/include -I/appl/local/include -DNCURSES_OPAQUE=0 -DNCURSES_REENTRANT=0 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/appl/local/python-2.7.10/include -I/appl/local/include -DNCURSES_OPAQUE=0 -DNCURSES_REENTRANT=0 build/temp.solaris-2.10-sun4u.32bit-2.7/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_curses_panel.o -L/appl/local/python-2.7.10/lib -L/appl/local/lib -L/usr/local/lib -L. -Wl,-R/appl/local/python-2.7.10/lib -lpanel -lncurses -lpython2.7 -o build/lib.solaris-2.10-sun4u.32bit-2.7/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing it failed: No module named _curses

Python build finished, but the necessary bits to build these modules were not found:
_bsddb             bsddb185           linuxaudiodev   
ossaudiodev                                           
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
_curses            _curses_panel

Here is LDD output for the built python:
$ ldd python
        libncurses.so.6 =>       /appl/local/python-2.7.10/lib/libncurses.so.6
        libpython2.7.so.1.0 =>   /appl/local/python-2.7.10/lib/libpython2.7.so.1.0
        libsocket.so.1 =>        /lib/libsocket.so.1
        libnsl.so.1 =>   /lib/libnsl.so.1
        librt.so.1 =>    /lib/librt.so.1
        libdl.so.1 =>    /lib/libdl.so.1
        libm.so.2 =>     /lib/libm.so.2
        libc.so.1 =>     /lib/libc.so.1
        libgcc_s.so.1 =>         /appl/local/lib/libgcc_s.so.1
        libmp.so.2 =>    /lib/libmp.so.2
        libmd.so.1 =>    /lib/libmd.so.1
        libscf.so.1 =>   /lib/libscf.so.1
        libaio.so.1 =>   /lib/libaio.so.1
        libdoor.so.1 =>  /lib/libdoor.so.1
        libuutil.so.1 =>         /lib/libuutil.so.1
        libgen.so.1 =>   /lib/libgen.so.1
        /platform/SUNW,Netra-T12/lib/libc_psr.so.1
        /platform/SUNW,Netra-T12/lib/libmd_psr.so.1

$ nm /appl/local/python-2.7.10/lib/libncurses.so.6 | grep unctrl
0004acac T unctrl
00067540 r unctrl_blob.5717
00067440 r unctrl_c1.5716
0004aac0 T unctrl_sp
00067942 r unctrl_table.5715


Unfortunately I see this in /usr/ccs/lib/libcurses.so
$ nm /usr/ccs/lib/libcurses.so | grep unctrl
0003d5e8 D _unctrl
0000cb00 T unctrl


I don't see any reference to unctrl except this: 
./Modules/_cursesmodule.c:        knp = unctrl(rtn);
./Modules/_cursesmodule.c:    return PyString_FromString(unctrl(ch));
./Modules/_cursesmodule.c:    {"unctrl",              (PyCFunction)PyCurses_UnCtrl, METH_VARARGS},

none of which is referencing _unctrl

so it seems that python can never work with ncurses6...even though it seems there is support for it in the code.

Any help?

----------
components: Extension Modules
messages: 258984
nosy: jonesrw
priority: normal
severity: normal
status: open
title: Python with ncurses6.0 will not load _curses module.
type: compile error
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 18:40:45 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Jan 2016 23:40:45 +0000
Subject: [issue26213] Document BUILD_LIST_UNPACK & BUILD_TUPLE_UNPACK
Message-ID: <1453851645.07.0.698993321818.issue26213@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Turns out the BUILD_TUPLE_UNPACK and BUILD_LIST_UNPACK opcodes are undocumented in the dis module.

----------
assignee: docs at python
components: Documentation
messages: 258985
nosy: benjamin.peterson, brett.cannon, docs at python
priority: low
severity: normal
stage: needs patch
status: open
title: Document BUILD_LIST_UNPACK & BUILD_TUPLE_UNPACK
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 18:59:01 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Jan 2016 23:59:01 +0000
Subject: [issue26213] Document BUILD_*_UNPACK opcodes
In-Reply-To: <1453851645.07.0.698993321818.issue26213@psf.upfronthosting.co.za>
Message-ID: <1453852741.16.0.50606359406.issue26213@psf.upfronthosting.co.za>


Brett Cannon added the comment:

There are also BUILD_SET_UNPACK and BUILD_MAP_UNPACK as well.

----------
title: Document BUILD_LIST_UNPACK & BUILD_TUPLE_UNPACK -> Document BUILD_*_UNPACK opcodes

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 19:02:36 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Wed, 27 Jan 2016 00:02:36 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1453852956.24.0.0180907453672.issue26039@psf.upfronthosting.co.za>


Changes by Thomas Kluyver :


Added file: http://bugs.python.org/file41722/zipinfo-from-file2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 19:44:41 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Jan 2016 00:44:41 +0000
Subject: [issue26128] Let the subprocess.STARTUPINFO constructor take arguments
In-Reply-To: <1452887119.07.0.716350004713.issue26128@psf.upfronthosting.co.za>
Message-ID: <1453855481.26.0.611977443884.issue26128@psf.upfronthosting.co.za>


Changes by Martin Panter :


----------
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 20:45:08 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Jan 2016 01:45:08 +0000
Subject: [issue19225] lack of PyExc_BufferError doc
In-Reply-To: <1381485777.95.0.364414099437.issue19225@psf.upfronthosting.co.za>
Message-ID: <1453859108.16.0.583878854158.issue19225@psf.upfronthosting.co.za>


Martin Panter added the comment:

General approach looks good. I left some review comments.

VMSError: I think this is Python 2 only, where it seems to be in a similar situation to WindowsError. According to Issue 16136 it was removed in Python 3.4. But it looks like your patch is against Python 3.

If you want to fix the alphabetical order, I think that is okay to do in the same patch. Otherwise, the current state is okay, but please put your BufferError in the right place :)

----------
nosy: +martin.panter
stage: needs patch -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 21:21:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Jan 2016 02:21:19 +0000
Subject: [issue26181] argparse can't handle positional argument after list
 (help message is wrong)
In-Reply-To: <1453480532.52.0.987369969347.issue26181@psf.upfronthosting.co.za>
Message-ID: <1453861279.47.0.45210842068.issue26181@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think we should discuss this in the existing reports:

Issue 9182: Mention the ?--? divider in the documentation and usage as a workaround. Perhaps you could mention your proposal to put positional arguments before the options there.

Issue 9338: Change the implementation to be smarter in this situation.

----------
nosy: +martin.panter
resolution:  -> duplicate
status: open -> closed
superseder:  -> document ?--? as a way to distinguish option w/ narg='+' from positional argument in argparse

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 21:28:31 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Jan 2016 02:28:31 +0000
Subject: [issue26188] Provide more helpful error message when `await` is
 called inside non-`async` method
In-Reply-To: <1453601163.58.0.356009781594.issue26188@psf.upfronthosting.co.za>
Message-ID: <1453861711.75.0.83842820395.issue26188@psf.upfronthosting.co.za>


Martin Panter added the comment:

According to PEP 492, ?await? is still allowed to be an ordinary identifier in non-async functions until Python 3.7. Which means you are still allowed to write

def oh_hai():
    await = "something"

The proposed error message would need to be smart enough to distinguish the two cases.

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 21:37:41 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 27 Jan 2016 02:37:41 +0000
Subject: =?utf-8?q?=5Bissue26211=5D_HTMLParser=3A_=E2=80=9CAssertionError=3A_we_sh?=
 =?utf-8?q?ould_not_get_here!=E2=80=9D?=
In-Reply-To: <1453844837.54.0.120197785601.issue26211@psf.upfronthosting.co.za>
Message-ID: <1453862261.81.0.260992860652.issue26211@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Test your html file and can not get the AssertionError. Seems everything works fine. Could you please provide more info?

----------
nosy: +xiang.zhang

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 22:01:32 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 27 Jan 2016 03:01:32 +0000
Subject: =?utf-8?q?=5Bissue26211=5D_HTMLParser=3A_=E2=80=9CAssertionError=3A_we_sh?=
 =?utf-8?q?ould_not_get_here!=E2=80=9D?=
In-Reply-To: <1453844837.54.0.120197785601.issue26211@psf.upfronthosting.co.za>
Message-ID: <1453863692.67.0.661703463328.issue26211@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

After reading Issue26210, I can get the AssertionError when there is a self.reset() in handle_endtag. I don't think it's proper to use reset in the process of parsing. From the samples I find on Web, reset is commonly used to set extra attributes on the parser so you can apply your own logic when parsing. I can not understand why reset is called in handle_endtag.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 22:11:13 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 27 Jan 2016 03:11:13 +0000
Subject: [issue26210] `HTMLParser.handle_data` may be invoked although
 `HTMLParser.reset` was invoked
In-Reply-To: <1453842608.52.0.40675264133.issue26210@psf.upfronthosting.co.za>
Message-ID: <1453864273.52.0.211787611349.issue26210@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

reset just set some attributes to the initial states and it does not control the parsing process. So reading the gohead function, even if reset is called in handle_endtag and all data are discarded, it is still possible for the process to move forward.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 22:15:42 2016
From: report at bugs.python.org (R. Jones)
Date: Wed, 27 Jan 2016 03:15:42 +0000
Subject: [issue26212] Python with ncurses6.0 will not load _curses module on
 Solaris 10
In-Reply-To: <1453851633.31.0.356555678785.issue26212@psf.upfronthosting.co.za>
Message-ID: <1453864542.16.0.150881618229.issue26212@psf.upfronthosting.co.za>


R. Jones added the comment:

Note:  This issue is on Solaris 10 using GCC 4.7.2 and the Solaris linker "ld".

----------
title: Python with ncurses6.0 will not load _curses module. -> Python with ncurses6.0 will not load _curses module on Solaris 10

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 22:28:53 2016
From: report at bugs.python.org (=?utf-8?q?=C6=A6OB_COASTN?=)
Date: Wed, 27 Jan 2016 03:28:53 +0000
Subject: =?utf-8?q?=5Bissue22625=5D_When_cross-compiling=2C_don=E2=80=99t_try_to_e?=
 =?utf-8?q?xecute_binaries?=
In-Reply-To: <1413226219.68.0.732560661241.issue22625@psf.upfronthosting.co.za>
Message-ID: <1453865333.75.0.0201910287118.issue22625@psf.upfronthosting.co.za>


?OB COASTN added the comment:

Similar patch used for 3.5
Additionally required:
-Python/importlib_external.h: $(srcdir)/Lib/importlib/_bootstrap_external.py Programs/_freeze_importlib
+Python/importlib_external.h: $(srcdir)/Lib/importlib/_bootstrap_external.py
+	$(MAKE) Programs/_freeze_importlib
 	./Programs/_freeze_importlib \
 		$(srcdir)/Lib/importlib/_bootstrap_external.py Python/importlib_external.h

----------
nosy: +mancoast

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 00:46:13 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jan 2016 05:46:13 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <20160127054610.6068.46002@psf.io>


Roundup Robot added the comment:

New changeset ce3d47eaeb21 by Raymond Hettinger in branch '3.5':
Issue #26194: Fix undefined behavior for deque.insert() when len(d) == maxlen
https://hg.python.org/cpython/rev/ce3d47eaeb21

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 00:46:42 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Jan 2016 05:46:42 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453873602.4.0.793927729142.issue26194@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 01:59:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Jan 2016 06:59:14 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453877954.19.0.836103527316.issue26194@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

New behavior looks less surprising to me.

Old behavior is even more weird for negative indices:

>>> from collections import deque
>>> d = deque(range(20), maxlen=10)
>>> d
deque([10, 11, 12, 13, 14, 15, 16, 17, 18, 19], maxlen=10)
>>> d.insert(-3, 'New')
>>> d
deque([11, 12, 13, 14, 15, 16, 'New', 18, 19, 10], maxlen=10)

Note that new element not just replaced the old one in the middle of the deque, but all context was rotated one position left.

Patched code behave less surprising.

>>> d.insert(-3, 'New')
>>> d                                                                   
deque([10, 11, 12, 13, 14, 15, 'New', 16, 17, 18], maxlen=10)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 02:42:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Jan 2016 07:42:30 +0000
Subject: [issue17394] Add slicing support to collections.deque
In-Reply-To: <1362972021.66.0.443403979058.issue17394@psf.upfronthosting.co.za>
Message-ID: <1453880550.66.0.978219013894.issue17394@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Synchronized with current sources and added mandatory now braces.

----------
Added file: http://bugs.python.org/file41723/deque_slices_2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 03:05:13 2016
From: report at bugs.python.org (=?utf-8?q?Yannick_Duch=C3=AAne?=)
Date: Wed, 27 Jan 2016 08:05:13 +0000
Subject: =?utf-8?q?=5Bissue26211=5D_HTMLParser=3A_=E2=80=9CAssertionError=3A_we_sh?=
 =?utf-8?q?ould_not_get_here!=E2=80=9D?=
In-Reply-To: <1453844837.54.0.120197785601.issue26211@psf.upfronthosting.co.za>
Message-ID: <1453881913.42.0.505776709197.issue26211@psf.upfronthosting.co.za>


Yannick Duch?ne added the comment:

`reset` is called to stop the parser.

If really `reset` should not be called during parser hooks execution, then the documentation should says so and an error should be raised when `reset` is invoked.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 03:08:41 2016
From: report at bugs.python.org (Tuomas Salo)
Date: Wed, 27 Jan 2016 08:08:41 +0000
Subject: [issue26214] textwrap should minimize breaks
Message-ID: <1453882121.55.0.184610339904.issue26214@psf.upfronthosting.co.za>


New submission from Tuomas Salo:

This code:

    import textwrap
    textwrap.wrap("123 123 1234567", width=5)

currently* produces this output:

    ['123', '123 1', '23456', '7']

I would expect the textwrap module to only break words when absolutely necessary. That is, I would have expected it to produce one break less:

    ['123', '123', '12345', '67']

This is of course a matter of taste - the current implementation produces more efficiently filled lines.

(* I only have access to Python 2.7 and 3.4)

----------
messages: 258999
nosy: Tuomas Salo
priority: normal
severity: normal
status: open
title: textwrap should minimize breaks
type: behavior
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 03:09:25 2016
From: report at bugs.python.org (Tuomas Salo)
Date: Wed, 27 Jan 2016 08:09:25 +0000
Subject: [issue26214] textwrap should minimize number of breaks in extra long
 words
In-Reply-To: <1453882121.55.0.184610339904.issue26214@psf.upfronthosting.co.za>
Message-ID: <1453882165.46.0.404068774902.issue26214@psf.upfronthosting.co.za>


Changes by Tuomas Salo :


----------
title: textwrap should minimize breaks -> textwrap should minimize number of breaks in extra long words

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 03:10:48 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 27 Jan 2016 08:10:48 +0000
Subject: [issue26214] textwrap should minimize number of breaks in extra long
 words
In-Reply-To: <1453882121.55.0.184610339904.issue26214@psf.upfronthosting.co.za>
Message-ID: <1453882248.12.0.55140296861.issue26214@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +georg.brandl
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 03:11:28 2016
From: report at bugs.python.org (=?utf-8?q?Yannick_Duch=C3=AAne?=)
Date: Wed, 27 Jan 2016 08:11:28 +0000
Subject: [issue26210] `HTMLParser.handle_data` may be invoked although
 `HTMLParser.reset` was invoked
In-Reply-To: <1453842608.52.0.40675264133.issue26210@psf.upfronthosting.co.za>
Message-ID: <1453882288.26.0.0279098201112.issue26210@psf.upfronthosting.co.za>


Yannick Duch?ne added the comment:

The documentation says:
> Reset the instance. Loses all unprocessed data.

How can parsing go ahead with all unprocessed data lost? This is the ?Loses all unprocessed data? which made me believe it is to stop it.

May be the documentation is unclear.

By the way, if `reset` does not stop the parser, then a `stop` method is missing. I searched for it, and as there was nothing else and could not imagine the parser cannot be stopped, I though `reset` is the way to stop it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 03:31:50 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Jan 2016 08:31:50 +0000
Subject: [issue17394] Add slicing support to collections.deque
In-Reply-To: <1362972021.66.0.443403979058.issue17394@psf.upfronthosting.co.za>
Message-ID: <1453883510.27.0.724806076759.issue17394@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thank you for doing this work.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 03:45:08 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 27 Jan 2016 08:45:08 +0000
Subject: [issue26210] `HTMLParser.handle_data` may be invoked although
 `HTMLParser.reset` was invoked
In-Reply-To: <1453842608.52.0.40675264133.issue26210@psf.upfronthosting.co.za>
Message-ID: <1453884308.56.0.648979098592.issue26210@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Actually it does move forward since in goahead, it first store a "copy" of the initial self.rawdata and use it to control the flow. If you make some change to self.rawdata when parsing, for example call reset, goahead can not feel it. But methods parse_* can. So the data conflicts.

I think it's not proper to change self.rawdata when parsing. You can easily get various errors by doing that.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 04:10:23 2016
From: report at bugs.python.org (=?utf-8?q?Yannick_Duch=C3=AAne?=)
Date: Wed, 27 Jan 2016 09:10:23 +0000
Subject: [issue26210] `HTMLParser.handle_data` may be invoked although
 `HTMLParser.reset` was invoked
In-Reply-To: <1453842608.52.0.40675264133.issue26210@psf.upfronthosting.co.za>
Message-ID: <1453885823.39.0.640795815951.issue26210@psf.upfronthosting.co.za>


Yannick Duch?ne added the comment:

Thanks Xiang, for the clear explanations.

So an error should be triggered when `reset` is invoked while it should not. And remains the issue about how to stop the parser: should an exception be raised and caught at an outer invocation level? Something like raising StopIteration? (I don't enjoy using exceptions for flow control, but that seems to be the Python way, cheese).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 04:11:16 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Jan 2016 09:11:16 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453885876.48.0.758689990449.issue26194@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

But the postcondition d[i] == newitem is broken if i is negative.

>>> d = deque('ABC', maxlen=3)
>>> d.insert(-1, None)
>>> d
deque(['A', None, 'B'], maxlen=3)

I would expected ['A', 'B', None].

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 04:14:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Jan 2016 09:14:12 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453886052.72.0.0400949227817.issue26194@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I would expected ['A', 'B', None].

Hum, it seems consistent with list behaviour, no?

>>> x=list("abc")
>>> x.insert(-1, "X")
>>> x
['a', 'b', 'X', 'c']

-1 is the same than len(x)-1 (2 in this example).

deque(['A', None, 'B'], maxlen=3) seems correct to me.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 04:16:13 2016
From: report at bugs.python.org (=?utf-8?q?Yannick_Duch=C3=AAne?=)
Date: Wed, 27 Jan 2016 09:16:13 +0000
Subject: =?utf-8?q?=5Bissue26211=5D_HTMLParser=3A_=E2=80=9CAssertionError=3A_we_sh?=
 =?utf-8?q?ould_not_get_here!=E2=80=9D?=
In-Reply-To: <1453844837.54.0.120197785601.issue26211@psf.upfronthosting.co.za>
Message-ID: <1453886173.07.0.0428093861407.issue26211@psf.upfronthosting.co.za>


Yannick Duch?ne added the comment:

I'm closing this issue, as the the issue http://bugs.python.org/issue26210 is the real one and this one seems to be a variant of the former.

----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 04:24:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Jan 2016 09:24:01 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453886641.8.0.0776478286876.issue26194@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

-1 is the position before the last element ('C'). After popping-off extra element the result can be ['A', 'B', None] or ['B', None, 'C'].

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 04:25:44 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Jan 2016 09:25:44 +0000
Subject: [issue26206] test_socket.testRecvmsgPeek() timeout on "AMD64 Debian
 root 3.x" buildbot
In-Reply-To: <1453813330.04.0.627005992155.issue26206@psf.upfronthosting.co.za>
Message-ID: <1453886744.78.0.196478750943.issue26206@psf.upfronthosting.co.za>


Martin Panter added the comment:

A few more details from :

* Affects Python 3 but not 2.7.
* Offending test case: RecvmsgUDP6Test.testRecvmsgPeek()
* Seems to correspond with the buildbot VM?s config recently being rebuilt

----------
nosy: +martin.panter
versions: +Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 04:26:52 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 27 Jan 2016 09:26:52 +0000
Subject: [issue26210] `HTMLParser.handle_data` may be invoked although
 `HTMLParser.reset` was invoked
In-Reply-To: <1453842608.52.0.40675264133.issue26210@psf.upfronthosting.co.za>
Message-ID: <1453886812.64.0.849372832699.issue26210@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Hmm, I don't know whether I am right or not. Let's wait for a core member to clarify. If I am wrong, I am quite sorry.

I don't think invoking reset when parsing should raise an error(and I don't know how to achieve that). When to invoke a subroutine is determined by the programmer. You can always put a well-written subroutine in some wrong place and then cause error. And I don't see how to stop the process either.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 04:27:16 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Jan 2016 09:27:16 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453886836.63.0.849669398124.issue26194@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> -1 is the position before the last element ('C'). After popping-off extra element the result can be ['A', 'B', None] or ['B', None, 'C'].

Oh ok :-) Now I'm confused, I don't know what is the expected behaviour :-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 04:27:38 2016
From: report at bugs.python.org (tony gaetani)
Date: Wed, 27 Jan 2016 09:27:38 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1453886858.83.0.221544251337.issue9694@psf.upfronthosting.co.za>


Changes by tony gaetani :


----------
nosy: +tonygaetani

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 05:06:13 2016
From: report at bugs.python.org (=?utf-8?q?Yannick_Duch=C3=AAne?=)
Date: Wed, 27 Jan 2016 10:06:13 +0000
Subject: [issue26210] `HTMLParser.handle_data` may be invoked although
 `HTMLParser.reset` was invoked
In-Reply-To: <1453842608.52.0.40675264133.issue26210@psf.upfronthosting.co.za>
Message-ID: <1453889173.61.0.600400194979.issue26210@psf.upfronthosting.co.za>


Yannick Duch?ne added the comment:

> And I don't see how to stop the process either.

I just did it with `raise StopIteration`, caught at a proper place (in the procedure which invokes `feed` and `close`), and it seems to be fine, I have no more strange behaviours. At least, I cannot see a cleaner way.

Now `reset` is invoked after end of parsing only (thus to be able to have a next round).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 05:11:03 2016
From: report at bugs.python.org (=?utf-8?q?Yannick_Duch=C3=AAne?=)
Date: Wed, 27 Jan 2016 10:11:03 +0000
Subject: [issue26210] `HTMLParser.handle_data` may be invoked although
 `HTMLParser.reset` was invoked
In-Reply-To: <1453842608.52.0.40675264133.issue26210@psf.upfronthosting.co.za>
Message-ID: <1453889463.86.0.685824821163.issue26210@psf.upfronthosting.co.za>


Changes by Yannick Duch?ne :


----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 05:54:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Jan 2016 10:54:44 +0000
Subject: [issue26098] PEP 510: Specialize functions with guards
In-Reply-To: <1452689568.12.0.253530674137.issue26098@psf.upfronthosting.co.za>
Message-ID: <1453892084.89.0.513130386213.issue26098@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 5: implement PyFunction_RemoveSpecialized() and PyFunction_RemoveAllSpecialized() functions (with unit tests!).

I'm not sure that PyFunction_RemoveSpecialized() must return 0 (success) if the removed specialized code doesn't exist (invalid index).

----------
Added file: http://bugs.python.org/file41724/specialize-5.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 06:08:47 2016
From: report at bugs.python.org (yuriy_levchenko)
Date: Wed, 27 Jan 2016 11:08:47 +0000
Subject: [issue26215] remove gc from CPython
Message-ID: <1453892927.49.0.620193472963.issue26215@psf.upfronthosting.co.za>


New submission from yuriy_levchenko:

I permanently use gc.disable() but CPython create object with GC_Head.
it's use big memory.
I suggest add define to a few file that remove use GC_Head and allocate extra memory.

----------
messages: 259013
nosy: yuriy_levchenko
priority: normal
severity: normal
status: open
title: remove gc from CPython
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 06:12:56 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Jan 2016 11:12:56 +0000
Subject: [issue26215] remove gc from CPython
In-Reply-To: <1453892927.49.0.620193472963.issue26215@psf.upfronthosting.co.za>
Message-ID: <1453893176.94.0.197711030076.issue26215@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 06:17:43 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Jan 2016 11:17:43 +0000
Subject: [issue24841] Some test_ssl network tests fail if svn.python.org is
 not accessible.
In-Reply-To: <1439252941.43.0.787973342114.issue24841@psf.upfronthosting.co.za>
Message-ID: <1453893463.13.0.997298689864.issue24841@psf.upfronthosting.co.za>


Martin Panter added the comment:

The two changes to test_ssl.py look okay to me, although they will need updating since the Issue 24841 changeover to pythontest.net.

But I don?t think it is a good idea to add ENOTCONN to the list of errors ignored by all transient_internet() tests. In most cases, ENOTCONN suggests a programming error, not a network problem. I think a better solution would be to call connect_ex() again in test_non_blocking_connect_ex(), and retrieve the result (probably also ECONNREFUSED like the other failures, or 0 if successful).

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 06:20:21 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jan 2016 11:20:21 +0000
Subject: [issue25843] code_richcompare() don't use constant type when
 comparing code constants
In-Reply-To: <1449861793.94.0.13967463155.issue25843@psf.upfronthosting.co.za>
Message-ID: <20160127112018.24721.35232@psf.io>


Roundup Robot added the comment:

New changeset 16f60cd918e0 by Victor Stinner in branch 'default':
PEP 511
https://hg.python.org/peps/rev/16f60cd918e0

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 06:20:21 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jan 2016 11:20:21 +0000
Subject: [issue26107] PEP 511: code.co_lnotab: use signed line number delta to
 support moving instructions in an optimizer
In-Reply-To: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>
Message-ID: <20160127112018.24721.49274@psf.io>


Roundup Robot added the comment:

New changeset 16f60cd918e0 by Victor Stinner in branch 'default':
PEP 511
https://hg.python.org/peps/rev/16f60cd918e0

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 06:20:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jan 2016 11:20:23 +0000
Subject: [issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit
 constants
In-Reply-To: <1453136691.51.0.69393755181.issue26146@psf.upfronthosting.co.za>
Message-ID: <20160127112018.24721.3496@psf.io>


Roundup Robot added the comment:

New changeset 16f60cd918e0 by Victor Stinner in branch 'default':
PEP 511
https://hg.python.org/peps/rev/16f60cd918e0

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 06:50:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Jan 2016 11:50:46 +0000
Subject: [issue26173] test_ssl.bad_cert_test() exception handling
In-Reply-To: <1453373183.85.0.754157160572.issue26173@psf.upfronthosting.co.za>
Message-ID: <1453895446.11.0.25027058917.issue26173@psf.upfronthosting.co.za>


Changes by Martin Panter :


----------
keywords: +patch
Added file: http://bugs.python.org/file41725/bad-cert-py3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 06:55:07 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Jan 2016 11:55:07 +0000
Subject: [issue25868] test_eintr.test_sigwaitinfo() hangs on "AMD64 FreeBSD
 CURRENT 3.x" buildbot
In-Reply-To: <1450174856.95.0.354294896083.issue25868@psf.upfronthosting.co.za>
Message-ID: <1453895707.7.0.361553825793.issue25868@psf.upfronthosting.co.za>


Martin Panter added the comment:

(Wrote this ages ago but never hit send:)

Here is another theory to explain the hang: When sigwaitinfo() is being called, and the SIGALRM signal arrives, it executes the signal handler (both the C handler and later the Python handler). If the SIGUSR1 signal arrives while either of these signal handlers are executing, it will be missed, and when sigwaitinfo() resumes it will hang. This would also be avoided by blocking SIGUSR1.

I wonder why the hang only seems to happen with BSD though.

----------
components: +Tests
keywords: +buildbot
versions: +Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 07:19:22 2016
From: report at bugs.python.org (Anish Shah)
Date: Wed, 27 Jan 2016 12:19:22 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1453897162.5.0.402414061147.issue26182@psf.upfronthosting.co.za>


Changes by Anish Shah :


----------
nosy: +anish.shah

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 07:58:16 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Wed, 27 Jan 2016 12:58:16 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1453899496.34.0.818821635415.issue25702@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

As Steve mentioned, the Microsoft compiler uses LTO (they call it Link-Time Code Generation) and the flags are used when compiling CPython on Windows systems. Thus our proposal to enable it on GCC and CLANG also.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 08:25:53 2016
From: report at bugs.python.org (Julien Baley)
Date: Wed, 27 Jan 2016 13:25:53 +0000
Subject: [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1453901153.07.0.0375724502377.issue25314@psf.upfronthosting.co.za>


Julien Baley added the comment:

This issue has now been open for nearly three months. I think my patch is an improvement over the current documentation. If people want to improve the documentation further, they can probably submit a patch for that.

What can I do to get this accepted?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 08:36:20 2016
From: report at bugs.python.org (allensll)
Date: Wed, 27 Jan 2016 13:36:20 +0000
Subject: [issue26216] run runtktests.py error when test tkinter
Message-ID: <1453901780.17.0.263140202656.issue26216@psf.upfronthosting.co.za>


New submission from allensll:

When I run the following:
python ...\Python35\Lib\tkinter\test\runtktests.py
Error:
SystemError: Parent module 'tkinter.test' not loaded, cannot perform relative import
When I add "import tkinter.test" into runtktests.py,it's working.

----------
components: Tkinter
messages: 259021
nosy: allensll
priority: normal
severity: normal
status: open
title: run runtktests.py error when test tkinter
type: behavior
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 09:12:19 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 27 Jan 2016 14:12:19 +0000
Subject: [issue1528593] Printing: No print dialog or page setup
Message-ID: <1453903939.26.0.474067713449.issue1528593@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
nosy:  -gpolo, kbk
versions: +Python 3.5, Python 3.6 -Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 09:41:39 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Wed, 27 Jan 2016 14:41:39 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1453905699.85.0.889236095858.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

The '2' versions of the two different patches include some docs and tests for these new features.

----------
Added file: http://bugs.python.org/file41726/zipfile-open-w2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 10:06:17 2016
From: report at bugs.python.org (=?utf-8?q?Gedai_Tam=C3=A1s_Bence?=)
Date: Wed, 27 Jan 2016 15:06:17 +0000
Subject: [issue19225] lack of PyExc_BufferError doc
In-Reply-To: <1381485777.95.0.364414099437.issue19225@psf.upfronthosting.co.za>
Message-ID: <1453907177.25.0.616118646129.issue19225@psf.upfronthosting.co.za>


Gedai Tam?s Bence added the comment:

Thanks Martin for the review!

I tried to fix the problems, I hope now it'll be good.

Changes:
- fixed uppercase 'B'
- removed VMSError
- moved notes after versionchanged
- added two indices for the different tables
* put BufferError in it's place

I didn't fix the alphabetical order to keep the patch clean. If you find this patch good, I'll fix that as well if it's needed.

----------
Added file: http://bugs.python.org/file41727/doc_exceptions_v1.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 10:46:05 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 27 Jan 2016 15:46:05 +0000
Subject: [issue26217] Fatal error when importing ``test.test_os`` in debug
 mode on Windows
Message-ID: <1453909565.67.0.482630553936.issue26217@psf.upfronthosting.co.za>


New submission from Emanuel Barry:

I compiled CPython from latest trunk on GitHub (revision a587bc1eea903dfac94a85324cc6ab39755769a8), compiled with Py_DEBUG and went to run the test suite. Here's the (rather long) output:

E:\GitHub\cpython\PCbuild\win32>python_d -m test
== CPython 3.6.0a0 (default, Jan 26 2016, 23:23:12) [MSC v.1900 32 bit (Intel)]
==   Windows-7-6.1.7601-SP1 little-endian
==   hash algorithm: siphash24 32bit
==   E:\GitHub\cpython\build\test_python_464
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0,
dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0,
bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
[  1/400] test_grammar
[  2/400] test_opcodes
[  3/400] test_dict
[  4/400] test_builtin
[  5/400] test_exceptions
[  6/400] test_types
[  7/400] test_unittest
[  8/400] test_doctest
[  9/400] test_doctest2
[ 10/400] test_support
[ 11/400] test___all__
Assertion failed: compact->wstr_length == 0, file ..\Objects\unicodeobject.c, line 427
Fatal Python error: Aborted

Current thread 0x00000a88 (most recent call first):
  File "E:\GitHub\cpython\lib\ctypes\util.py", line 64 in find_library
  File "E:\GitHub\cpython\lib\uuid.py", line 473 in 
  File "", line 222 in _call_with_frames_removed
  File "", line 656 in exec_module
  File "", line 673 in _load_unlocked
  File "", line 958 in _find_and_load_unlocked
  File "", line 969 in _find_and_load
  File "E:\GitHub\cpython\lib\test\test_os.py", line 29 in 
  File "", line 222 in _call_with_frames_removed
  File "", line 656 in exec_module
  File "", line 673 in _load_unlocked
  File "", line 958 in _find_and_load_unlocked
  File "", line 969 in _find_and_load
  File "", line 1 in 
  File "E:\GitHub\cpython\lib\test\test___all__.py", line 23 in check_all
  File "E:\GitHub\cpython\lib\test\test___all__.py", line 105 in test_all
  File "E:\GitHub\cpython\lib\unittest\case.py", line 600 in run
  File "E:\GitHub\cpython\lib\unittest\case.py", line 648 in __call__
  File "E:\GitHub\cpython\lib\unittest\suite.py", line 122 in run
  File "E:\GitHub\cpython\lib\unittest\suite.py", line 84 in __call__
  File "E:\GitHub\cpython\lib\unittest\suite.py", line 122 in run
  File "E:\GitHub\cpython\lib\unittest\suite.py", line 84 in __call__
  File "E:\GitHub\cpython\lib\unittest\suite.py", line 122 in run
  File "E:\GitHub\cpython\lib\unittest\suite.py", line 84 in __call__
  File "E:\GitHub\cpython\lib\test\support\__init__.py", line 1679 in run
  File "E:\GitHub\cpython\lib\test\support\__init__.py", line 1780 in _run_suite
  File "E:\GitHub\cpython\lib\test\support\__init__.py", line 1814 in run_unittest
  File "E:\GitHub\cpython\lib\test\libregrtest\runtest.py", line 161 in test_runner
  File "E:\GitHub\cpython\lib\test\libregrtest\runtest.py", line 162 in runtest_inner
  File "E:\GitHub\cpython\lib\test\libregrtest\runtest.py", line 126 in runtest
  File "E:\GitHub\cpython\lib\test\libregrtest\main.py", line 295 in run_tests_sequential
  File "E:\GitHub\cpython\lib\test\libregrtest\main.py", line 356 in run_tests
  File "E:\GitHub\cpython\lib\test\libregrtest\main.py", line 392 in main
  File "E:\GitHub\cpython\lib\test\libregrtest\main.py", line 433 in main
  File "E:\GitHub\cpython\lib\test\libregrtest\main.py", line 455 in main_in_temp_cwd
  File "E:\GitHub\cpython\lib\test\__main__.py", line 3 in 
  File "E:\GitHub\cpython\lib\runpy.py", line 85 in _run_code
  File "E:\GitHub\cpython\lib\runpy.py", line 184 in _run_module_as_main

E:\GitHub\cpython\PCbuild\win32>python_d
Python 3.6.0a0 (default, Jan 26 2016, 23:23:12) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import test.test___all__
>>> import unittest
>>> unittest.main(test.test___all__)

<...>

test.test_openpty
test.test_operator
test.test_optparse
test.test_ordered_dict
test.test_os
Assertion failed: compact->wstr_length == 0, file ..\Objects\unicodeobject.c, line 427

E:\GitHub\cpython\PCbuild\win32>python_d
Python 3.6.0a0 (default, Jan 26 2016, 23:23:12) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import test.test_os
Assertion failed: compact->wstr_length == 0, file ..\Objects\unicodeobject.c, line 427

Call stack (from importing 'test.test_os'):

 	ucrtbased.dll!0f7d81f0()	Unknown
 	[Frames below may be incorrect and/or missing, no symbols loaded for ucrtbased.dll]	
 	[External Code]	
>	python36_d.dll!_PyUnicode_CheckConsistency(_object * op, int check_content) Line 427	C
 	python36_d.dll!resize_compact(_object * unicode, int length) Line 920	C
 	python36_d.dll!unicode_resize(_object * * p_unicode, int length) Line 1844	C
 	python36_d.dll!PyUnicode_Append(_object * * p_left, _object * right) Line 11301	C
 	python36_d.dll!unicode_concatenate(_object * v, _object * w, _frame * f, unsigned char * next_instr) Line 5318	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 1565	C
 	python36_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4815	C
 	python36_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4741	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3194	C
 	python36_d.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4029	C
 	python36_d.dll!PyEval_EvalCodeEx(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure) Line 4050	C
 	python36_d.dll!PyEval_EvalCode(_object * co, _object * globals, _object * locals) Line 777	C
 	python36_d.dll!builtin_exec_impl(PyModuleDef * module, _object * source, _object * globals, _object * locals) Line 957	C
 	python36_d.dll!builtin_exec(PyModuleDef * module, _object * args) Line 275	C
 	python36_d.dll!PyCFunction_Call(_object * func, _object * args, _object * kwds) Line 109	C
 	python36_d.dll!ext_do_call(_object * func, _object * * * pp_stack, int flags, int na, int nk) Line 5041	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3233	C
 	python36_d.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4029	C
 	python36_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4824	C
 	python36_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4741	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3194	C
 	python36_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4815	C
 	python36_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4741	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3194	C
 	python36_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4815	C
 	python36_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4741	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3194	C
 	python36_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4815	C
 	python36_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4741	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3194	C
 	python36_d.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4029	C
 	python36_d.dll!PyEval_EvalCodeEx(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure) Line 4050	C
 	python36_d.dll!function_call(_object * func, _object * arg, _object * kw) Line 604	C
 	python36_d.dll!PyObject_Call(_object * func, _object * arg, _object * kw) Line 2170	C
 	python36_d.dll!_PyObject_CallMethodIdObjArgs(_object * callable, _Py_Identifier * name, ...) Line 2428	C
 	python36_d.dll!PyImport_ImportModuleLevelObject(_object * name, _object * given_globals, _object * locals, _object * given_fromlist, int level) Line 1633	C
 	python36_d.dll!builtin___import__(_object * self, _object * args, _object * kwds) Line 213	C
 	python36_d.dll!PyCFunction_Call(_object * func, _object * args, _object * kwds) Line 98	C
 	python36_d.dll!PyObject_Call(_object * func, _object * arg, _object * kw) Line 2170	C
 	python36_d.dll!PyEval_CallObjectWithKeywords(_object * func, _object * arg, _object * kw) Line 4592	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 2759	C
 	python36_d.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4029	C
 	python36_d.dll!PyEval_EvalCodeEx(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure) Line 4050	C
 	python36_d.dll!PyEval_EvalCode(_object * co, _object * globals, _object * locals) Line 777	C
 	python36_d.dll!builtin_exec_impl(PyModuleDef * module, _object * source, _object * globals, _object * locals) Line 957	C
 	python36_d.dll!builtin_exec(PyModuleDef * module, _object * args) Line 275	C
 	python36_d.dll!PyCFunction_Call(_object * func, _object * args, _object * kwds) Line 109	C
 	python36_d.dll!ext_do_call(_object * func, _object * * * pp_stack, int flags, int na, int nk) Line 5041	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3233	C
 	python36_d.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4029	C
 	python36_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4824	C
 	python36_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4741	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3194	C
 	python36_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4815	C
 	python36_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4741	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3194	C
 	python36_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4815	C
 	python36_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4741	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3194	C
 	python36_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4815	C
 	python36_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4741	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3194	C
 	python36_d.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4029	C
 	python36_d.dll!PyEval_EvalCodeEx(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure) Line 4050	C
 	python36_d.dll!function_call(_object * func, _object * arg, _object * kw) Line 604	C
 	python36_d.dll!PyObject_Call(_object * func, _object * arg, _object * kw) Line 2170	C
 	python36_d.dll!_PyObject_CallMethodIdObjArgs(_object * callable, _Py_Identifier * name, ...) Line 2428	C
 	python36_d.dll!PyImport_ImportModuleLevelObject(_object * name, _object * given_globals, _object * locals, _object * given_fromlist, int level) Line 1633	C
 	python36_d.dll!builtin___import__(_object * self, _object * args, _object * kwds) Line 213	C
 	python36_d.dll!PyCFunction_Call(_object * func, _object * args, _object * kwds) Line 98	C
 	python36_d.dll!PyObject_Call(_object * func, _object * arg, _object * kw) Line 2170	C
 	python36_d.dll!PyEval_CallObjectWithKeywords(_object * func, _object * arg, _object * kw) Line 4592	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 2759	C
 	python36_d.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4029	C
 	python36_d.dll!PyEval_EvalCodeEx(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure) Line 4050	C
 	python36_d.dll!PyEval_EvalCode(_object * co, _object * globals, _object * locals) Line 777	C
 	python36_d.dll!run_mod(_mod * mod, _object * filename, _object * globals, _object * locals, PyCompilerFlags * flags, _arena * arena) Line 970	C
 	python36_d.dll!PyRun_InteractiveOneObject(_iobuf * fp, _object * filename, PyCompilerFlags * flags) Line 233	C
 	python36_d.dll!PyRun_InteractiveLoopFlags(_iobuf * fp, const char * filename_str, PyCompilerFlags * flags) Line 112	C
 	python36_d.dll!PyRun_AnyFileExFlags(_iobuf * fp, const char * filename, int closeit, PyCompilerFlags * flags) Line 74	C
 	python36_d.dll!run_file(_iobuf * fp, const wchar_t * filename, PyCompilerFlags * p_cf) Line 318	C
 	python36_d.dll!Py_Main(int argc, wchar_t * * argv) Line 768	C
 	python_d.exe!wmain(int argc, wchar_t * * argv) Line 14	C
 	[External Code]	

This was compiled using Microsoft Visual Studio Community 2015

----------
messages: 259024
nosy: ebarry
priority: normal
severity: normal
status: open
title: Fatal error when importing ``test.test_os`` in debug mode on Windows
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 10:50:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Jan 2016 15:50:24 +0000
Subject: [issue26217] Fatal error when importing ``test.test_os`` in debug
 mode on Windows
In-Reply-To: <1453909565.67.0.482630553936.issue26217@psf.upfronthosting.co.za>
Message-ID: <1453909824.68.0.125667778513.issue26217@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hum, it looks like resize_compact() clears wstr, but don't reset wstr_length to 0. Attached patch should fix that.

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file41728/wstr_len.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 10:56:27 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 27 Jan 2016 15:56:27 +0000
Subject: [issue26217] Fatal error when importing ``test.test_os`` in debug
 mode on Windows
In-Reply-To: <1453909565.67.0.482630553936.issue26217@psf.upfronthosting.co.za>
Message-ID: <1453910187.49.0.402598339752.issue26217@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

This fixed it, thanks!

----------
stage:  -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 11:01:38 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jan 2016 16:01:38 +0000
Subject: [issue26217] Fatal error when importing ``test.test_os`` in debug
 mode on Windows
In-Reply-To: <1453909565.67.0.482630553936.issue26217@psf.upfronthosting.co.za>
Message-ID: <20160127160127.4141.45850@psf.io>


Roundup Robot added the comment:

New changeset 8de6f19afc86 by Victor Stinner in branch '3.5':
Fix resize_compact()
https://hg.python.org/cpython/rev/8de6f19afc86

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 11:10:06 2016
From: report at bugs.python.org (Wallison Resende Santos)
Date: Wed, 27 Jan 2016 16:10:06 +0000
Subject: [issue26218] Set PrependPath default to true
Message-ID: <1453911006.83.0.905556840018.issue26218@psf.upfronthosting.co.za>


New submission from Wallison Resende Santos:

Please, set the PrependPath configuration to true. It's a good option for console developers on windows.

----------
components: Installation
messages: 259028
nosy: Wallison Resende Santos
priority: normal
severity: normal
status: open
title: Set PrependPath default to true
type: behavior
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 11:11:42 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 27 Jan 2016 16:11:42 +0000
Subject: [issue26217] Fatal error when importing ``test.test_os`` in debug
 mode on Windows
In-Reply-To: <1453909565.67.0.482630553936.issue26217@psf.upfronthosting.co.za>
Message-ID: <1453911102.91.0.356223154119.issue26217@psf.upfronthosting.co.za>


Changes by Emanuel Barry :


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 11:13:54 2016
From: report at bugs.python.org (Bruno Salvino)
Date: Wed, 27 Jan 2016 16:13:54 +0000
Subject: [issue26218] Set PrependPath default to true
In-Reply-To: <1453911006.83.0.905556840018.issue26218@psf.upfronthosting.co.za>
Message-ID: <1453911234.88.0.816557877129.issue26218@psf.upfronthosting.co.za>


Bruno Salvino added the comment:

Please, set the PrependPath configuration to true.

----------
nosy: +Bruno Salvino

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 11:20:06 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Jan 2016 16:20:06 +0000
Subject: [issue25868] test_eintr.test_sigwaitinfo() hangs on "AMD64 FreeBSD
 CURRENT 3.x" buildbot
In-Reply-To: <1453895707.7.0.361553825793.issue25868@psf.upfronthosting.co.za>
Message-ID: 


STINNER Victor added the comment:

> This would also be avoided by blocking SIGUSR1.

Sorry, I'm lost on this old and complex issue. Can you please propose a patch?

If it doesn't break test_eintr on Linux and FreeBSD, we can just push
it and take a look sometimes at FreeBSD buildbots ;-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 11:25:16 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 27 Jan 2016 16:25:16 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1453911916.95.0.121789021455.issue26182@psf.upfronthosting.co.za>


Changes by Guido van Rossum :


----------
nosy:  -gvanrossum

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 11:30:04 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Jan 2016 16:30:04 +0000
Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated
In-Reply-To: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za>
Message-ID: <1453912204.66.0.772844917005.issue20120@psf.upfronthosting.co.za>


R. David Murray added the comment:

So fixing distutils to use RawConfigParser?  How likely is that to break currently working python3-only code?  I'm imagining from what you wrote that your answer is "very close to zero', but I'd like explicit confirmation :)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 11:49:13 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 27 Jan 2016 16:49:13 +0000
Subject: [issue25507] IDLE: user code 'import tkinter;
 tkinter.font' should fail
In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za>
Message-ID: <1453913353.26.0.405019425899.issue25507@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Ouch.  Moving the idleConf import was a blunder.  It disabled printing in 2.7.11, 3.4.4, and 3.5.1.  When I revert, I will also augment the htest to test the printing and save-as functions.  Still have to remember to run it though.

This sort of functional test is not the main intended use of htests.  When refactoring for this issue, automated tests should be added, with mocks used to avoid consequential actions that cannot be part of a buildbot test.  For print_window, '''pipe = os.popen(command, "r")''' (https://hg.python.org/cpython/file/tip/Lib/idlelib/IOBinding.py#l463) should be replaced by '''pipe = runcommand(command)''' and 'def runcommand(command): return os.pipe(command, 'r')''' (with subprocess used instead?) added at module level.  Then runcommand can be replaced by a mock when testing, and the value of the passed command checked.

----------
nosy:  -python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 11:49:24 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 27 Jan 2016 16:49:24 +0000
Subject: [issue25507] IDLE: user code 'import tkinter;
 tkinter.font' should fail
In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za>
Message-ID: <1453913364.43.0.0124043230121.issue25507@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
versions:  -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 11:52:37 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jan 2016 16:52:37 +0000
Subject: [issue25507] IDLE: user code 'import tkinter;
 tkinter.font' should fail
In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za>
Message-ID: <20160127165234.544.24224@psf.io>


Roundup Robot added the comment:

New changeset 34ca24fa1b4a by Terry Jan Reedy in branch '2.7':
Issue #25507: revert incorrect movement of idleConf import in a37ea1d56e98.
https://hg.python.org/cpython/rev/34ca24fa1b4a

New changeset 86105a109830 by Terry Jan Reedy in branch '3.5':
Issue #25507: revert incorrect movement of idleConf import in c548ad75160c.
https://hg.python.org/cpython/rev/86105a109830

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 12:11:27 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 27 Jan 2016 17:11:27 +0000
Subject: [issue26219] implement per-opcode cache in ceval
Message-ID: <1453914687.03.0.978372578059.issue26219@psf.upfronthosting.co.za>


Changes by Yury Selivanov :


----------
assignee: yselivanov
components: Interpreter Core
nosy: yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: implement per-opcode cache in ceval
type: performance
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 12:15:08 2016
From: report at bugs.python.org (Quentin Pradet)
Date: Wed, 27 Jan 2016 17:15:08 +0000
Subject: [issue26220] Unicode HOWTO references a question mark that isn't in
 snippet
Message-ID: <1453914908.97.0.691892593639.issue26220@psf.upfronthosting.co.za>


New submission from Quentin Pradet:

>From https://docs.python.org/3.6/howto/unicode.html#the-string-type:

> The following examples show the differences::
>
>     >>> b'\x80abc'.decode("utf-8", "strict")  #doctest: +NORMALIZE_WHITESPACE
>     Traceback (most recent call last):
>         ...
>     UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 0:
>       invalid start byte
>     >>> b'\x80abc'.decode("utf-8", "replace")
>     '\ufffdabc'
>     >>> b'\x80abc'.decode("utf-8", "backslashreplace")
>     '\\x80abc'
>     >>> b'\x80abc'.decode("utf-8", "ignore")
>     'abc'
>
> (In this code example, the Unicode replacement character has been replaced by
> a question mark because it may not be displayed on some systems.)

I think the whole sentence after the snippet can be removed because this is exactly what Python 3.2+ outputs. It looks like the commit which added this sentence dates from Python 3.1: https://github.com/python/cpython/commit/34d4c82af56ebc1b65514a118f0ec7feeb8e172f, but another commit around Python 3.3 removed it: https://github.com/python/cpython/commit/63172c46706ae9b2a3bc80d639504a57fff4e716.

----------
assignee: docs at python
components: Documentation
messages: 259034
nosy: Quentin.Pradet, docs at python
priority: normal
severity: normal
status: open
title: Unicode HOWTO references a question mark that isn't in snippet
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 12:21:31 2016
From: report at bugs.python.org (Ian Kelly)
Date: Wed, 27 Jan 2016 17:21:31 +0000
Subject: [issue25675] doc for BaseEventLoop.run_in_executor() says its a
 coroutine, but it is not
In-Reply-To: <1447970161.65.0.436017258107.issue25675@psf.upfronthosting.co.za>
Message-ID: <1453915291.12.0.304098322777.issue25675@psf.upfronthosting.co.za>


Ian Kelly added the comment:

The asyncio docs also have this note, so this is technically not a bug:

Note: In this documentation, some methods are documented as coroutines, even if they are plain Python functions returning a Future. This is intentional to have a freedom of tweaking the implementation of these functions in the future. If such a function is needed to be used in a callback-style code, wrap its result with ensure_future().

Since the intention seems to be to document something that can be awaited without specifying the implementation, I think that these functions should be documented as returning awaitables. However GvR in python-ideas said:

IMO [the docs] should be very clear about the distinction between functions that return Futures and functions that return coroutines (of either kind). I think it's fine if they are fuzzy about whether the latter return a PEP 492 style coroutine (i.e. defined with async def) or a pre-PEP-492 coroutine (marked with @asyncio.coroutine), since those are almost entirely interchangeable, and the plan is to eventually make everything a PEP 492 coroutine.

Source: http://thread.gmane.org/gmane.comp.python.ideas/38045/focus=38046

----------
nosy: +ikelly

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 12:25:33 2016
From: report at bugs.python.org (Ian Kelly)
Date: Wed, 27 Jan 2016 17:25:33 +0000
Subject: [issue26221] asynco run_in_executor swallows StopIteration
Message-ID: <1453915533.75.0.0706458699162.issue26221@psf.upfronthosting.co.za>


New submission from Ian Kelly:

I was playing around with this class for adapting regular iterators to async iterators using BaseEventLoop.run_in_executor:


import asyncio

class AsyncIteratorWrapper:

    def __init__(self, iterable, loop=None, executor=None):
        self._iterator = iter(iterable)
        self._loop = loop or asyncio.get_event_loop()
        self._executor = executor

    async def __aiter__(self):
        return self

    async def __anext__(self):
        try:
            return await self._loop.run_in_executor(
                    self._executor, next, self._iterator)
        except StopIteration:
            raise StopAsyncIteration


Unfortunately this fails because when next raises StopIteration, run_in_executor swallows the exception and just returns None back to the coroutine, resulting in an infinite iterator of Nones.

----------
components: asyncio
messages: 259036
nosy: gvanrossum, haypo, ikelly, yselivanov
priority: normal
severity: normal
status: open
title: asynco run_in_executor swallows StopIteration
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 12:45:28 2016
From: report at bugs.python.org (Rasmus Rynning Rasmussen)
Date: Wed, 27 Jan 2016 17:45:28 +0000
Subject: [issue26222] Missing code in linux_distribution python 2.7.11
Message-ID: <1453916728.01.0.709818070841.issue26222@psf.upfronthosting.co.za>


New submission from Rasmus Rynning Rasmussen:

During the transition from python 2.7.10 to 2.7.11 some code seems to have been lost. platform.linux_distribution() is not able to recognise Debian based distributions in python 2.7.11.

The following code was present in platform.py, python 2.7.10, but seems to be missing in 2.7.11

# check for the LSB /etc/lsb-release file first, needed so
# that the distribution doesn't get identified as Debian.
    try:
        with open("/etc/lsb-release", "rU") as etclsbrel:
            for line in etclsbrel:
                m = _distributor_id_file_re.search(line)
                if m:
                    _u_distname = m.group(1).strip()
                m = _release_file_re.search(line)
                if m:
                    _u_version = m.group(1).strip()
                m = _codename_file_re.search(line)
                if m:
                    _u_id = m.group(1).strip()
            if _u_distname and _u_version:
                return (_u_distname, _u_version, _u_id)
    except (EnvironmentError, UnboundLocalError):
        pass

----------
components: Build
messages: 259037
nosy: Rasmus Rynning Rasmussen
priority: normal
severity: normal
status: open
title: Missing code in linux_distribution python 2.7.11
type: performance
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 12:51:49 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 27 Jan 2016 17:51:49 +0000
Subject: [issue10401] Globals / builtins cache
In-Reply-To: <1289597080.96.0.9732660757.issue10401@psf.upfronthosting.co.za>
Message-ID: <1453917109.0.0.29393193185.issue10401@psf.upfronthosting.co.za>


Changes by INADA Naoki :


----------
nosy: +naoki

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 13:00:07 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Jan 2016 18:00:07 +0000
Subject: [issue26182] Deprecation warnings for the future async and await
 keywords
In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>
Message-ID: <1453917607.55.0.24781703953.issue26182@psf.upfronthosting.co.za>


Brett Cannon added the comment:

If someone wants to try and fix this, I would look at how the warning for the 'with' statement was handled (it will either be in the compiler while generating bytecode or somewhere in the parser, but I'm fairly certain it's the compiler).

----------
nosy: +brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 13:09:32 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 27 Jan 2016 18:09:32 +0000
Subject: [issue25507] IDLE: user code 'import tkinter;
 tkinter.font' should fail
In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za>
Message-ID: <1453918172.04.0.950831154391.issue25507@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Problem was reported here https://stackoverflow.com/questions/35021370/i-cant-print-from-python-idle-in-windows-10

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 13:13:22 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Jan 2016 18:13:22 +0000
Subject: [issue26215] Make GC_Head a compile-time option
In-Reply-To: <1453892927.49.0.620193472963.issue26215@psf.upfronthosting.co.za>
Message-ID: <1453918402.8.0.895401845923.issue26215@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
title: remove gc from CPython -> Make GC_Head a compile-time option

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 13:15:00 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Jan 2016 18:15:00 +0000
Subject: [issue26219] implement per-opcode cache in ceval
Message-ID: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>


New submission from Brett Cannon:

I assume there's going to be a patch or more of a description of what your idea is? :)

----------
nosy: +brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 13:27:15 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 27 Jan 2016 18:27:15 +0000
Subject: [issue26221] asynco run_in_executor swallows StopIteration
In-Reply-To: <1453915533.75.0.0706458699162.issue26221@psf.upfronthosting.co.za>
Message-ID: <1453919235.34.0.493514625665.issue26221@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

What are you trying to do here? Can you post a simple example of an iterator that you would like to use with this? Without that it just raises my hackles -- it seems totally wrong to run an iterator in another thread. (Or is the iterator really a coroutine/future?)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 13:27:27 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 27 Jan 2016 18:27:27 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1453919247.95.0.18982575143.issue26219@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Yeah, I needed a URL of the issue for my email to python-dev ;)

Here's a link to the email, that explains a lot about this patch: https://mail.python.org/pipermail/python-dev/2016-January/142945.html

The patch is also attached (opcache1.patch).

----------
keywords: +patch
Added file: http://bugs.python.org/file41729/opcache1.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 13:31:20 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Jan 2016 18:31:20 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453919480.46.0.66067542494.issue26194@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The expected behavior should be "insert normally as if the deque were unbounded and then pop-off the rightmost element to restore the maxlen invariant".

The applied fix does that for non-negative indices but gives the wrong result for negative indicies:

  >>> from collections import deque
  >>> d = deque('abcde', maxlen=5)
  >>> d.insert(-1, 'f')
  >>> list(d)
  ['a', 'b', 'c', 'f', 'd']
  >>> s = list('abcde')
  >>> s.insert(-1, 'f'); del s[-1]
  >>> s
  ['a', 'b', 'c', 'd', 'f']

I think the behavior can be made explainable and also be useful for common cases, but there is likely no getting around odd looking results with negative index insertions into bounded deques already at their maximum size.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 13:33:23 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 27 Jan 2016 18:33:23 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1453919603.46.0.130160582579.issue26219@psf.upfronthosting.co.za>


Changes by Yury Selivanov :


----------
nosy: +haypo, ncoghlan

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 13:34:14 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 27 Jan 2016 18:34:14 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1453919654.12.0.535626771682.issue26219@psf.upfronthosting.co.za>


Changes by Yury Selivanov :


----------
dependencies: +Speedup method calls 1.2x

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 13:34:44 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 27 Jan 2016 18:34:44 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1453919684.16.0.970028824979.issue26219@psf.upfronthosting.co.za>


Changes by Yury Selivanov :


----------
dependencies: +PEP 509: Add ma_version to PyDictObject

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 13:45:49 2016
From: report at bugs.python.org (Ian Kelly)
Date: Wed, 27 Jan 2016 18:45:49 +0000
Subject: [issue26221] asynco run_in_executor swallows StopIteration
In-Reply-To: <1453915533.75.0.0706458699162.issue26221@psf.upfronthosting.co.za>
Message-ID: <1453920349.92.0.761425220481.issue26221@psf.upfronthosting.co.za>


Ian Kelly added the comment:

The idea is that the wrapped iterator is something potentially blocking, like a database cursor that doesn't natively support asyncio. Usage would be something like this:


async def get_data():
    cursor.execute('select * from stuff')
    async for row in AsyncIteratorWrapper(cursor):
        process(row)


Investigating this further, I think the problem is actually in await, not run_in_executor:

>>> async def test():
...     fut = asyncio.Future()
...     fut.set_exception(StopIteration())
...     print(await fut)
... 
>>> loop.run_until_complete(test())
None

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 13:52:38 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 27 Jan 2016 18:52:38 +0000
Subject: [issue26221] asynco run_in_executor swallows StopIteration
In-Reply-To: <1453915533.75.0.0706458699162.issue26221@psf.upfronthosting.co.za>
Message-ID: <1453920758.13.0.696225220969.issue26221@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

StopIteration has a special meaning. Don't use set_exception() with it.

You probably need a more roundabout way to do this.

Instead of submitting each __next__() call to the executor separately, you should submit something to the executor that pulls the items from the iterator and sticks them into a queue; then on the asyncio side you pull them out of the queue.

You can use an asyncio.Queue as the queue, and use loop.call_soon_threadsafe() to put things into that queue from the tread.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 13:56:05 2016
From: report at bugs.python.org (Tim Peters)
Date: Wed, 27 Jan 2016 18:56:05 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453920965.54.0.103658001421.issue26194@psf.upfronthosting.co.za>


Tim Peters added the comment:

I'd raise an exception when trying to insert into a bounded deque that's already full.  There's simply no way to guess what was _intended_; it's dead easy for the user to implement what they _do_ intend (first make room by deleting the specific item they no longer want); and I can't think of a use case compelling enough to justify whatever arbitrary non-exceptional behavior may be implemented instead.

WRT the behavior you settled on, sure, it's explainable.  That doesn't imply it's useful, though ;-)  I'd rather have an exception.  It's plain bizarre that after

    d.insert(i, x)

one can't even rely on

    assert any(y is x for y in d)

succeeding.  Implementing behavior that allows that invariant to fail is _really_ user-unfriendly ;-)

In contrast, what .append() and .appendleft() do for a full bounded deque are compelling (and don't violate the weak invariant above).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 14:15:13 2016
From: report at bugs.python.org (Serge Stroobandt)
Date: Wed, 27 Jan 2016 19:15:13 +0000
Subject: [issue26223] decimal.to_eng_string() does not implement engineering
 notation in all cases.
Message-ID: <1453922113.08.0.48679853518.issue26223@psf.upfronthosting.co.za>


New submission from Serge Stroobandt:

In https://docs.python.org/2/library/string.html#formatstrings the proprietary (IBM) specifcation "Decimal Arithmetic Specification" http://www.gobosoft.com/eiffel/gobo/math/decimal/daconvs.html is incorrectly being heralded as "the" specifiaction for engineering notation.

However, upon reading this IBM specifation carefully, one will note that the specifaction itself actually admits not applying the engineering notation in the case of infinite numbers.

An emphasized version of the exact quote accompanied with a discussion can be found here: http://stackoverflow.com/a/17974598/2192488

Correct behaviour for decimal.to_eng_string() would be to equally employ engineering notation in the case of infinite numbers.

I suggest renaming the current behaviour to decimal.to_ibm_string().

References:
http://www.augustatech.edu/math/molik/notation.pdf
https://en.wikipedia.org/wiki/Engineering_notation
https://en.wikipedia.org/wiki/General_Conference_on_Weights_and_Measures
http://www.bipm.org/en/CGPM/db/11/11/

PS: I am a MSc in Electronic Engineering.

----------
components: Extension Modules
files: engineering_notation.pdf
messages: 259047
nosy: Keith.Brafford, eric.smith, ezio.melotti, serge.stroobandt
priority: normal
severity: normal
status: open
title: decimal.to_eng_string() does not implement engineering notation in all cases.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file41730/engineering_notation.pdf

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 14:23:53 2016
From: report at bugs.python.org (David Heffernan)
Date: Wed, 27 Jan 2016 19:23:53 +0000
Subject: [issue26108] Calling PyInitialize with 2.7.11 on Windows x64
 terminates process
In-Reply-To: <1452765230.72.0.612722422255.issue26108@psf.upfronthosting.co.za>
Message-ID: <1453922633.92.0.315221560941.issue26108@psf.upfronthosting.co.za>


David Heffernan added the comment:

Thanks for following up Steve, and thanks for changing resolution to dupe. 

As for 3.5 and embedding the docs are much the same as 2.7 in that the example code at https://docs.python.org/3/extending/embedding.html doesn't explicitly set Python home. 

Anyway, I'm very happy with how this report has been dealt with. Thank you all.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 14:36:42 2016
From: report at bugs.python.org (Ian Kelly)
Date: Wed, 27 Jan 2016 19:36:42 +0000
Subject: [issue26221] asynco run_in_executor swallows StopIteration
In-Reply-To: <1453915533.75.0.0706458699162.issue26221@psf.upfronthosting.co.za>
Message-ID: <1453923402.65.0.780452838472.issue26221@psf.upfronthosting.co.za>


Ian Kelly added the comment:

Fair enough. I think there should be some documentation though to the effect that coroutines aren't robust to passing StopIteration across coroutine boundaries. It's particularly surprising with PEP-492 coroutines, since those aren't even iterators and intuitively should ignore StopIteration like normal functions do.

As it happens, this variation (moving the try-except into the executor thread) does turn out to work but is probably best avoided for the same reason. I don't think it's obviously bad code though:


class AsyncIteratorWrapper:

    def __init__(self, iterable, loop=None, executor=None):
        self._iterator = iter(iterable)
        self._loop = loop or asyncio.get_event_loop()
        self._executor = executor

    async def __aiter__(self):
        return self

    async def __anext__(self):
        def _next(iterator):
            try:
                return next(iterator)
            except StopIteration:
                raise StopAsyncIteration
        return await self._loop.run_in_executor(
                self._executor, _next, self._iterator)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 14:50:13 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 27 Jan 2016 19:50:13 +0000
Subject: [issue26223] decimal.to_eng_string() does not implement engineering
 notation in all cases.
In-Reply-To: <1453922113.08.0.48679853518.issue26223@psf.upfronthosting.co.za>
Message-ID: <1453924213.04.0.00134748627848.issue26223@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
versions: +Python 3.6 -Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 14:53:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Jan 2016 19:53:22 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453924402.9.0.0325789509682.issue26194@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What if implement the bahavior described by Raymond for index -len(d) <= i < len(d), but raise an exception if the index is out of this range?

The result of deque('abc', maxlen=3).insert(i, 'X') would be:

-4: error
-3: ['X', 'a', 'b']
-2: ['a', 'X', 'b']
-1: ['a', 'b', 'X']
 0: ['X', 'a', 'b']
 1: ['a', 'X', 'b']
 2: ['a', 'b', 'X']
 3: error

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 14:58:30 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 27 Jan 2016 19:58:30 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1453924710.56.0.077387489396.issue26219@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

BTW, there are a couple of unit-tests that fail.  Both can be easily fixed.

To really move this thing forward, we need to profile the memory usage.  First, it would be interesting to see how much additional memory is consumed if we optimize every code object.  That will give us an idea of the overhead, and if it is significant, we can experiment with various heuristics to minimize it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 15:01:58 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Jan 2016 20:01:58 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1453924918.56.0.629039390102.issue26219@psf.upfronthosting.co.za>


Brett Cannon added the comment:

If you run hg.python.org/benchmarks on Linux it has a flag to measure memory.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 15:03:40 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Jan 2016 20:03:40 +0000
Subject: [issue26215] Make GC_Head a compile-time option
In-Reply-To: <1453892927.49.0.620193472963.issue26215@psf.upfronthosting.co.za>
Message-ID: <1453925020.65.0.726664494202.issue26215@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Could you please try to elaborate a little bit the issue?

> I permanently use gc.disable() but CPython create object with GC_Head.
it's use big memory.

You propose to remove GC_Head for everywhere? Or do you want a configure option?

What do you mean by "big memory"? Do you have an estimation of the "overhead" on an application?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 15:16:28 2016
From: report at bugs.python.org (Serge Stroobandt)
Date: Wed, 27 Jan 2016 20:16:28 +0000
Subject: [issue26223] decimal.to_eng_string() does not implement engineering
 notation in all cases.
In-Reply-To: <1453922113.08.0.48679853518.issue26223@psf.upfronthosting.co.za>
Message-ID: <1453925788.34.0.28803318324.issue26223@psf.upfronthosting.co.za>


Serge Stroobandt added the comment:

An emphasized version of the exact quote is here now:
http://stackoverflow.com/a/35045233/2192488

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 15:18:53 2016
From: report at bugs.python.org (Tim Peters)
Date: Wed, 27 Jan 2016 20:18:53 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453925933.77.0.403267854953.issue26194@psf.upfronthosting.co.za>


Tim Peters added the comment:

My opinion doesn't change:  I'd rather see an exception.  I see no use case for inserting "into the middle" of a full bounded queue.  If I had one, it would remain trivial to force the specific behavior I intended.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 15:25:33 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 27 Jan 2016 20:25:33 +0000
Subject: [issue26221] asynco run_in_executor swallows StopIteration
In-Reply-To: <1453923402.65.0.780452838472.issue26221@psf.upfronthosting.co.za>
Message-ID: 


Guido van Rossum added the comment:

Can you suggest a sentence to insert into the docs and a place where
to insert it? (As you can imagine I'm pretty blind for such issues
myself.)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 15:27:39 2016
From: report at bugs.python.org (Tom Parker)
Date: Wed, 27 Jan 2016 20:27:39 +0000
Subject: [issue26183] 2.7.11 won't clean install on Windows 10 x64
In-Reply-To: <1453496711.72.0.869603030432.issue26183@psf.upfronthosting.co.za>
Message-ID: <1453926459.35.0.140595840778.issue26183@psf.upfronthosting.co.za>


Tom Parker added the comment:

FYI, I ran into this same issue, I believe this was caused by my selecting Python tools when installing Visual Studio 2015 Community edition. But I removed it and the issued didn't go away.

Then I deleted some empty python registry keys and voila the installer worked.

----------
nosy: +tomparker

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 15:33:17 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Jan 2016 20:33:17 +0000
Subject: [issue26223] decimal.to_eng_string() does not implement engineering
 notation in all cases.
In-Reply-To: <1453922113.08.0.48679853518.issue26223@psf.upfronthosting.co.za>
Message-ID: <1453926797.33.0.196126204723.issue26223@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The decimal module strives to exactly follow the spec even when our sensibilities suggest otherwise. Perhaps, we can add a note to the current docs describing the situation.  The API itself is a settled issue, that ship sailed a very long time ago (the problem with a standard library is that it becomes standard that people rely on and is hard to change after the fact without causing issues for users).

----------
assignee:  -> rhettinger
nosy: +facundobatista, mark.dickinson, rhettinger, skrah, tim.peters

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 15:34:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Jan 2016 20:34:33 +0000
Subject: [issue26221] asynco run_in_executor swallows StopIteration
In-Reply-To: <1453915533.75.0.0706458699162.issue26221@psf.upfronthosting.co.za>
Message-ID: <1453926873.99.0.0715591209234.issue26221@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy:  -haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 15:41:30 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 27 Jan 2016 20:41:30 +0000
Subject: [issue26223] decimal.to_eng_string() does not implement engineering
 notation in all cases.
In-Reply-To: <1453922113.08.0.48679853518.issue26223@psf.upfronthosting.co.za>
Message-ID: <1453927290.77.0.309957835378.issue26223@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Agreed. And, since any API change would just be a 3.6+ change, this would increase the difficulty of moving between 2.7 and 3.x. Which is not something we want.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 15:45:38 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 27 Jan 2016 20:45:38 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1453927538.31.0.315768133059.issue26219@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> If you run hg.python.org/benchmarks on Linux it has a flag to measure memory.

Great.  I'll re-run the benchmarks.  BTW, the latest results are here: https://gist.github.com/1st1/aed69d63a2ff4de4c7be

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 15:46:33 2016
From: report at bugs.python.org (Serge Stroobandt)
Date: Wed, 27 Jan 2016 20:46:33 +0000
Subject: [issue26223] decimal.to_eng_string() does not implement engineering
 notation in all cases.
In-Reply-To: <1453922113.08.0.48679853518.issue26223@psf.upfronthosting.co.za>
Message-ID: <1453927593.78.0.776270157819.issue26223@psf.upfronthosting.co.za>


Serge Stroobandt added the comment:

@rhettinger
I completely agree with not creating a backward incompatibility at this point in time.

The real issue is that decimal.to_eng_string() was written to a (unfortunately chosen) proprietary specification which does not entirely correspond to the engineering notation.

A quick web search shows that a lot of people are in search of a *true* engineering notation implementation. In the phylosophy of "batteries included" it is a pity this useful and very common notation is currently missing in Python.

I would therefore suggest adding a decimal.to_true_eng_string() with the true engineering notation.

Hence, this bug could be reclassified as asuggestion for enhancement.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 16:01:33 2016
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 27 Jan 2016 21:01:33 +0000
Subject: [issue26223] decimal.to_eng_string() does not implement engineering
 notation in all cases.
In-Reply-To: <1453922113.08.0.48679853518.issue26223@psf.upfronthosting.co.za>
Message-ID: <1453928493.95.0.922292220878.issue26223@psf.upfronthosting.co.za>


Stefan Krah added the comment:

The spec was the only reasonable choice at the time decimal.py was
written.  Incidentally, it is basically IEEE-754-2008 with arbitrary
precision extensions; this isn't surprising since Mike Cowlishaw was
on the IEEE committee and wrote the spec at the same time.

There are very few decNumber-specific remainders in the spec -- this
may be one of those (though I did not bother to look up if the IEEE
standard specifies formatting at all).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 16:24:58 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Jan 2016 21:24:58 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453929898.14.0.0189237481772.issue26194@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

My only aversion to raising an exception is that it goes against the original intent of maxlen as giving an automatic-pop-to-make-room behavior.

Rather that introduce a discontinuity, I like the "smoothness" of letting d.insert(len(d), obj) follow the insert-normally-then-pop-from-the-right rule as opposed to having a special case.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 16:36:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Jan 2016 21:36:24 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1453930584.97.0.522400430388.issue26219@psf.upfronthosting.co.za>


STINNER Victor added the comment:

If I understand correctly, this change requires to wait until the PEP 509 is accepted, right? Well, I'm not really suprised, since global cache is mentioned as an use case of the PEP 509, and other global cache patches are mentioned in Prior Art.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 16:43:11 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 27 Jan 2016 21:43:11 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1453930991.92.0.810181219678.issue26219@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Yes, this patch depends on PEP 509.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 16:58:57 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 27 Jan 2016 21:58:57 +0000
Subject: [issue26183] 2.7.11 won't clean install on Windows 10 x64
In-Reply-To: <1453496711.72.0.869603030432.issue26183@psf.upfronthosting.co.za>
Message-ID: <1453931937.91.0.680707315103.issue26183@psf.upfronthosting.co.za>


Steve Dower added the comment:

VS 2015 won't cause this (I also work on that product as my day job, so I know exactly what it does and doesn't do), but the registry corruption probably did.

The pip support that's in the 2.7 installer is not the most robust code, and it can easily run into issues when your install is broken that make it fail. Repairing your prior install before uninstalling it is the easiest way to fix this in practically every case.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 17:00:07 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 27 Jan 2016 22:00:07 +0000
Subject: [issue26108] Calling PyInitialize with 2.7.11 on Windows x64
 terminates process
In-Reply-To: <1452765230.72.0.612722422255.issue26108@psf.upfronthosting.co.za>
Message-ID: <1453932007.93.0.894622213543.issue26108@psf.upfronthosting.co.za>


Steve Dower added the comment:

That's true, though if you use the embeddable distribution of Python 3.5 you automatically get the equivalent behavior because of a new option (the "applocal" option in pyvenv.cfg, which is enabled in that distro by default).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 17:01:58 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Jan 2016 22:01:58 +0000
Subject: [issue26098] PEP 510: Specialize functions with guards
In-Reply-To: <1452689568.12.0.253530674137.issue26098@psf.upfronthosting.co.za>
Message-ID: <1453932118.55.0.127997847051.issue26098@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FIXME: sys.getsizecode(func) doesn't include specialized code and guards.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 17:05:14 2016
From: report at bugs.python.org (Tom Parker)
Date: Wed, 27 Jan 2016 22:05:14 +0000
Subject: [issue26183] 2.7.11 won't clean install on Windows 10 x64
In-Reply-To: <1453931937.91.0.680707315103.issue26183@psf.upfronthosting.co.za>
Message-ID: 


Tom Parker added the comment:

Ah OK :) I had done a W10 reset to wipe my PC before reinstalling VS so I could't imagine where else the python registry keys could have come from.

My install sequence was:

SQL Server 2012 Developer
Visual Studio 2015 Community Edition
Office 365
Inkscape - maybe??
Then Python 2.7.11

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 17:56:59 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 27 Jan 2016 22:56:59 +0000
Subject: [issue17394] Add slicing support to collections.deque
In-Reply-To: <1362972021.66.0.443403979058.issue17394@psf.upfronthosting.co.za>
Message-ID: <1453935418.99.0.0286149636305.issue17394@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

It seems odd to have a slice of a deque return a list. Are there any other examples of non-buffer protocol objects behaving like this in the standard library/built-ins? Only examples I can come up with are mmap objects and ctypes arrays (which are making raw binary data available in Python); it seems rather surprising that a Python level type like deque would slice to produce a list.

----------
nosy: +josh.r

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 18:02:49 2016
From: report at bugs.python.org (Udi Oron)
Date: Wed, 27 Jan 2016 23:02:49 +0000
Subject: [issue26224] Add "version added" for documentation of asyncio.timeout
 for documentation of python 3.4, 3.5, 3.6
Message-ID: <1453935768.98.0.383268297204.issue26224@psf.upfronthosting.co.za>


New submission from Udi Oron:

It seems like `asyncio.timeout` is going to be added in 3.4.5, 3.5.2 and 3.6.

The current live documentation of python 3.4 and python 3.5.1 does not include a comment regarding it is not yet available in the current released versions of python.

The documentation should include a `.. versionadded:: 3.4.5`, `.. versionadded:: 3.5.2` or `.. versionadded:: 3.6` according to the branch.

----------
assignee: docs at python
components: Documentation, asyncio
files: asyncio-timeout.patch
keywords: patch
messages: 259071
nosy: Udi Oron, docs at python, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Add "version added" for documentation of asyncio.timeout for documentation of python 3.4, 3.5, 3.6
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41731/asyncio-timeout.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 18:36:37 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 27 Jan 2016 23:36:37 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453937797.64.0.276060685022.issue26194@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

I agree with Tim that arbitrarily deciding that insert should behave more like appendleft is surprising. This really feels like guessing at what the user wants, silently doing something that really isn't predictable.

Any of the following seem nicer (not exactly arguing for any but #1):

1. Raising an exception for full deque
2. Making insert pop left when full (and possibly make insertleft that will pop right; the name isn't perfect, but it would make the symmetry between "no suffix pops left and 'left' suffix pops right" line up with other deque methods)
3. Adding an optional argument to say which end should be popped (defaulting to "raise an exception", probably no good though, since it would break Sequence rules.

----------
nosy: +josh.r

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 18:48:21 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Jan 2016 23:48:21 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453938501.16.0.867948740625.issue26194@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


Added file: http://bugs.python.org/file41732/full_deque2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 19:01:28 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Thu, 28 Jan 2016 00:01:28 +0000
Subject: [issue26225] New misleading wording in execution model documenation
Message-ID: <1453939288.53.0.211010759952.issue26225@psf.upfronthosting.co.za>


New submission from Andrew Barnert:

In #24129, the wording describing class local bindings in 4.2.2 "Resolution of names" was changed for Python 3.4, 3.5, and 3.6. The new version is a lot clearer for classes--but now it's misleading for `exec`/`eval`.

---

> Class definition blocks and arguments to exec() and eval() are
> special in the context of name resolution. A class definition is...

... and then proceeds to explain how class lookup works, without ever mentioning `exec` and `eval`. This implies that they work the same way as classes, but of course that's not true:

    i = 'global'
    def f():
        i = 'nonlocal'
        class C:
            print(i)
            i = 'local'
            print(i)
    f()

That prints `global`, then `local`. But with `exec`:

    i = 'global'
    def f():
        i = 'nonlocal'
        exec("print(i)\ni = 'local'\nprint(i)\n")
    f()

That prints `nonlocal` then `local`.

I think just putting a paragraph break between the first sentence and the rest of the paragraph might be sufficient to avoid the confusion here. Or just removing any mention of `eval` and `exec`. If not, this probably needs a new one-liner paragraph saying something like "Arguments to `exec()` and `eval()` are also special, as described later."

---

Meanwhile, if you keep reading, you'll eventually find that `exec` is described in a later section, 4.2.4 "Interaction with dynamic features", but that's _also_ misleading:

> The eval() and exec() functions do not have access to the full
> environment for resolving names. Names may be resolved in the
> local and global namespaces of the caller. Free variables are not
> resolved in the nearest enclosing namespace, but in the global
> namespace.

If that were true, the `exec` example would have printed `global`, right?

I'm pretty sure that what's going on here is that `exec` implicitly calls `locals()` (or, rather, the C-API equivalent), which constructs a locals dict on demand, which, only if you're inside a function block, includes not just the currently-bound fast locals, but _also_ the cell_contents of the currently-bound free variables. So, as far as `exec` is concerned, `i` is not an unbound local, or a free variable, but a local, which is bound to the `'nonlocal'` cell value of `i` at the time `exec` was called.

Which means the following actually _does_ print `global`:

    i = 'global'
    def f():
        exec("print(i)\ni = 'local'\nprint(i)\n")
        i = 'nonlocal'
    f()

I have no idea how to make this clear. Maybe the simplest is to not try to give a full explanation here, and instead punt to the `locals()` function definition? Maybe something like this:

> The `eval()` and `exec()` functions do not have access to the full environment for resolving names, but rather to the approximation of that environment as constructed by the `locals()` function. Free variables that are not captured as locals are not resolved in the nearest enclosing namespace, but in the global...

... and from there, the same as the current paragraph.

----------
assignee: docs at python
components: Documentation
messages: 259073
nosy: abarnert, docs at python
priority: normal
severity: normal
status: open
title: New misleading wording in execution model documenation

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 19:01:40 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Thu, 28 Jan 2016 00:01:40 +0000
Subject: [issue26225] New misleading wording in execution model documenation
In-Reply-To: <1453939288.53.0.211010759952.issue26225@psf.upfronthosting.co.za>
Message-ID: <1453939300.92.0.635944218852.issue26225@psf.upfronthosting.co.za>


Changes by Andrew Barnert :


----------
type:  -> enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 19:19:19 2016
From: report at bugs.python.org (paul j3)
Date: Thu, 28 Jan 2016 00:19:19 +0000
Subject: [issue26181] argparse can't handle positional argument after list
 (help message is wrong)
In-Reply-To: <1453480532.52.0.987369969347.issue26181@psf.upfronthosting.co.za>
Message-ID: <1453940359.29.0.611086866885.issue26181@psf.upfronthosting.co.za>


paul j3 added the comment:

There are 2 issues

parsing - how to reserve one or more arguments for use by following 'positionals'.  Fixes have been proposed in other bug/issues, but aren't trivial.

usage formatting - the stock formatter displays all optionals first, followed by all positionals.  In a multiline display positionals go on a new line.

Changes to the help formatter that would block this reordering have been discussed on Stackoverflow, but I don't recall such an issue here.  It can be done by changing one method in a subclassed formatter.

The immediate solution is to give your parser a custom usage line - one that puts the positional in the correct order.

----------
nosy: +paul.j3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 19:25:56 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Thu, 28 Jan 2016 00:25:56 +0000
Subject: [issue26226] Various test suite failures on Windows
Message-ID: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za>


New submission from Emanuel Barry:

Compiled latest master and ran test suite (Py_DEBUG build). A few failures here and there, and some tests skipped. I haven't yet looked into getting the proper libraries to make some of the skipped tests execute, I'm trying to make the whole test suite pass first.

Attached file includes verbose output for all failed tests. The end of the file and the traceback at the end of the message here happen, then Python hangs and never resumes (tested for ~20 minutes).

Python 3.6.0a0 (default, Jan 27 2016, 10:49:09) [MSC v.1900 32 bit (Intel)] on w
in32
Type "help", "copyright", "credits" or "license" for more information.
>>> import test.regrtest
>>> test.regrtest.main_in_temp_cwd() # same as 'py -m test'
== CPython 3.6.0a0 (default, Jan 27 2016, 10:49:09) [MSC v.1900 32 bit (Intel)]
==   Windows-7-6.1.7601-SP1 little-endian
==   hash algorithm: siphash24 32bit
==   E:\GitHub\cpython\build\test_python_13304
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0,
dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0,
bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
[  1/400] test_grammar
[  2/400] test_opcodes
[  3/400] test_dict
[  4/400] test_builtin
[  5/400] test_exceptions
[  6/400] test_types
[  7/400] test_unittest
[  8/400] test_doctest
[  9/400] test_doctest2
[ 10/400] test_support
[ 11/400] test___all__
[ 12/400] test___future__
[ 13/400] test__locale
[ 14/400] test__opcode
[ 15/400] test__osx_support
[ 16/400] test_abc
[ 17/400] test_abstract_numbers
[ 18/400] test_aifc
[ 19/400] test_argparse
[ 20/400] test_array
[ 21/400] test_asdl_parser
[ 22/400] test_ast
[ 23/400] test_asynchat
[ 24/400] test_asyncio
E:\GitHub\cpython\lib\asyncio\sslproto.py:327: ResourceWarning: unclosed transport

  warnings.warn("unclosed transport %r" % self, ResourceWarning)
test test_asyncio failed -- multiple errors occurred; run in verbose mode for details
[ 25/400/1] test_asyncore
[ 26/400/1] test_atexit
[ 27/400/1] test_audioop
[ 28/400/1] test_augassign
[ 29/400/1] test_base64
[ 30/400/1] test_bigaddrspace
[ 31/400/1] test_bigmem
[ 32/400/1] test_binascii
[ 33/400/1] test_binhex
[ 34/400/1] test_binop
[ 35/400/1] test_bisect
[ 36/400/1] test_bool
[ 37/400/1] test_buffer
[ 38/400/1] test_bufio
[ 39/400/1] test_bytes
[ 40/400/1] test_bz2
[ 41/400/1] test_calendar
[ 42/400/1] test_call
[ 43/400/1] test_capi
[ 44/400/1] test_cgi
[ 45/400/1] test_cgitb
[ 46/400/1] test_charmapcodec
[ 47/400/1] test_class
[ 48/400/1] test_cmath
[ 49/400/1] test_cmd
[ 50/400/1] test_cmd_line
[ 51/400/1] test_cmd_line_script
[ 52/400/1] test_code
[ 53/400/1] test_code_module
test test_code_module failed -- multiple errors occurred; run in verbose mode for details
[ 54/400/2] test_codeccallbacks
[ 55/400/2] test_codecencodings_cn
[ 56/400/2] test_codecencodings_hk
[ 57/400/2] test_codecencodings_iso2022
test test_codecencodings_iso2022 failed -- multiple errors occurred; run in verbose mode for details
[ 58/400/3] test_codecencodings_jp
[ 59/400/3] test_codecencodings_kr
[ 60/400/3] test_codecencodings_tw
[ 61/400/3] test_codecmaps_cn
[ 62/400/3] test_codecmaps_hk
[ 63/400/3] test_codecmaps_jp
[ 64/400/3] test_codecmaps_kr
[ 65/400/3] test_codecmaps_tw
[ 66/400/3] test_codecs
[ 67/400/3] test_codeop
[ 68/400/3] test_collections
[ 69/400/3] test_colorsys
[ 70/400/3] test_compare
[ 71/400/3] test_compile
[ 72/400/3] test_compileall
[ 73/400/3] test_complex
[ 74/400/3] test_concurrent_futures
[ 75/400/3] test_configparser
[ 76/400/3] test_contains
[ 77/400/3] test_contextlib
[ 78/400/3] test_copy
[ 79/400/3] test_copyreg
[ 80/400/3] test_coroutines
[ 81/400/3] test_cprofile
[ 82/400/3] test_crashers
[ 83/400/3] test_crypt
test_crypt skipped -- No module named '_crypt'
[ 84/400/3] test_csv
[ 85/400/3] test_ctypes
[ 86/400/3] test_curses
test_curses skipped -- Use of the 'curses' resource not enabled
[ 87/400/3] test_datetime
[ 88/400/3] test_dbm
[ 89/400/3] test_dbm_dumb
[ 90/400/3] test_dbm_gnu
test_dbm_gnu skipped -- No module named '_gdbm'
[ 91/400/3] test_dbm_ndbm
test_dbm_ndbm skipped -- No module named '_dbm'
[ 92/400/3] test_decimal
[ 93/400/3] test_decorators
[ 94/400/3] test_defaultdict
[ 95/400/3] test_deque
[ 96/400/3] test_descr
[ 97/400/3] test_descrtut
[ 98/400/3] test_devpoll
test_devpoll skipped -- test works only on Solaris OS family
[ 99/400/3] test_dictcomps
[100/400/3] test_dictviews
[101/400/3] test_difflib
[102/400/3] test_dis
[103/400/3] test_distutils

E:\GitHub\cpython\build\test_python_13304>exit 1

E:\GitHub\cpython\build\test_python_13304>exit 0
Warning -- files was modified by test_distutils
test test_distutils failed -- multiple errors occurred; run in verbose mode for details
[104/400/4] test_docxmlrpc
[105/400/4] test_dummy_thread
[106/400/4] test_dummy_threading
[107/400/4] test_dynamic
[108/400/4] test_dynamicclassattribute
[109/400/4] test_eintr
[110/400/4] test_email
[111/400/4] test_ensurepip
[112/400/4] test_enum
[113/400/4] test_enumerate
[114/400/4] test_eof
[115/400/4] test_epoll
test_epoll skipped -- test works only on Linux 2.6
[116/400/4] test_errno
[117/400/4] test_exception_variations
[118/400/4] test_extcall
[119/400/4] test_faulthandler
[120/400/4] test_fcntl
test_fcntl skipped -- No module named 'fcntl'
[121/400/4] test_file
[122/400/4] test_file_eintr
[123/400/4] test_filecmp
[124/400/4] test_fileinput
[125/400/4] test_fileio
[126/400/4] test_finalization
[127/400/4] test_float
[128/400/4] test_flufl
[129/400/4] test_fnmatch
[130/400/4] test_fork1
test_fork1 skipped -- object  has no attribute 'fork'
[131/400/4] test_format
[132/400/4] test_fractions
[133/400/4] test_frame
[134/400/4] test_fstring
[135/400/4] test_ftplib
[136/400/4] test_funcattrs
[137/400/4] test_functools
[138/400/4] test_future
[139/400/4] test_future3
[140/400/4] test_future4
[141/400/4] test_future5
[142/400/4] test_gc
[143/400/4] test_gdb
test_gdb skipped -- Couldn't find gdb on the path
[144/400/4] test_generators
[145/400/4] test_genericpath
[146/400/4] test_genexps
[147/400/4] test_getargs2
[148/400/4] test_getopt
[149/400/4] test_getpass
[150/400/4] test_gettext
[151/400/4] test_glob
[152/400/4] test_global
[153/400/4] test_grp
test_grp skipped -- No module named 'grp'
[154/400/4] test_gzip
[155/400/4] test_hash
[156/400/4] test_hashlib
[157/400/4] test_heapq
[158/400/4] test_hmac
[159/400/4] test_html
[160/400/4] test_htmlparser
[161/400/4] test_http_cookiejar
[162/400/4] test_http_cookies
[163/400/4] test_httplib
test test_httplib failed -- multiple errors occurred; run in verbose mode for details
[164/400/5] test_httpservers
Exception in thread Thread-857:
Traceback (most recent call last):
  File "E:\GitHub\cpython\lib\threading.py", line 916, in _bootstrap_inner
    self.run()
  File "E:\GitHub\cpython\lib\test\test_httpservers.py", line 42, in run
    self.server = HTTPServer(('localhost', 0), self.request_handler)
  File "E:\GitHub\cpython\lib\socketserver.py", line 443, in __init__
    self.server_bind()
  File "E:\GitHub\cpython\lib\http\server.py", line 140, in server_bind
    self.server_name = socket.getfqdn(host)
  File "E:\GitHub\cpython\lib\socket.py", line 662, in getfqdn
    hostname, aliases, ipaddrs = gethostbyaddr(name)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc9 in position 0: invalid
continuation byte

----------
files: failed_tests_output.txt
messages: 259075
nosy: ebarry
priority: normal
severity: normal
status: open
title: Various test suite failures on Windows
Added file: http://bugs.python.org/file41733/failed_tests_output.txt

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 19:26:38 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Thu, 28 Jan 2016 00:26:38 +0000
Subject: [issue26226] Various test suite failures on Windows
In-Reply-To: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za>
Message-ID: <1453940798.95.0.42698180252.issue26226@psf.upfronthosting.co.za>


Changes by Emanuel Barry :


----------
stage:  -> needs patch
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 19:33:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 00:33:03 +0000
Subject: [issue26226] Various test suite failures on Windows
In-Reply-To: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za>
Message-ID: <1453941183.92.0.0298183741903.issue26226@psf.upfronthosting.co.za>


STINNER Victor added the comment:

For the test_httpservers failure, can you please try the following commands on your PC?

>>> socket.gethostname()
'selma'
>>> socket.gethostbyaddr(socket.gethostname())
('selma', [], ['2a01:e34:ec8d:4c70:3ea9:f4ff:fe65:c0c', 'fe80::3ea9:f4ff:fe65:c0c'])

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 19:44:48 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Thu, 28 Jan 2016 00:44:48 +0000
Subject: [issue26226] Various test suite failures on Windows
In-Reply-To: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za>
Message-ID: <1453941888.47.0.569899634644.issue26226@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Well, it has a non-ASCII character in it, so I wouldn't be surprised if this was the issue :)

Latest master (3.6):

>>> import socket
>>> socket.gethostname()
'?manuel-PC'
>>> socket.gethostbyaddr(socket.gethostname())
Traceback (most recent call last):
  File "", line 1, in 
socket.gaierror: [Errno 11004] getaddrinfo failed

Python 2.7.11:

>>> import socket
>>> socket.gethostname()
'\xc9manuel-PC'
>>> socket.gethostbyaddr(socket.gethostname())
('\xc9manuel-PC.home', [], ['fe80::c9b7:5117:eea4:a104'])

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 19:58:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 00:58:51 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
Message-ID: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>


New submission from STINNER Victor:

On Windows, socket.gethostbyaddr() must decode the hostname from the ANSI code page, not from UTF-8. See for example this issue:
https://bugs.python.org/issue26226#msg259077

Attached patch changes the socket module to decode hostnames from the ANSI code page on Windows.

See also issues #9377, #16652 and #5004.

----------
components: Unicode, Windows
messages: 259078
nosy: ebarry, ezio.melotti, haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows: socket.gethostbyaddr(name) fails for non-ASCII hostname
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 19:59:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 00:59:13 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1453942753.66.0.154126589447.issue26227@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
keywords: +patch
Added file: http://bugs.python.org/file41734/gethostbyaddr_encoding.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 20:05:18 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 01:05:18 +0000
Subject: [issue9377] socket,
 PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za>
Message-ID: <1453943118.54.0.694700208109.issue9377@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FYI I created the issue #26227 to change the encoding used to decode hostnames on Windows. UTF-8 doesn't seem to be the right encoding, it fails on non-ASCII hostnames. I propose to use the ANSI code page.

Sorry, I didn't read this issue, but it looks like IDNA isn't the good encoding to decode hostnames *on Windows*.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 20:07:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 01:07:51 +0000
Subject: [issue26226] Various test suite failures on Windows
In-Reply-To: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za>
Message-ID: <1453943271.2.0.572178685121.issue26226@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm surprised by the test_codecencodings_iso2022 failures. Example:

======================================================================
FAIL: test_incrementaldecoder (test.test_codecencodings_iso2022.Test_ISO2022_KR)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\GitHub\cpython\lib\test\multibytecodec_support.py", line 208, in test_incrementaldecoder
    self.assertEqual(ostream.getvalue(), self.tstring[1])
AssertionError: b'\xe[334 chars]\x80\n\xed\x9a\xa8\xec\x9c\xa8\xec\xa0\x81\xec[1668 chars]4.\n' != b'\xe[334 chars]\x80\r\n\xed\x9a\xa8\xec\x9c\xa8\xec\xa0\x81\x[1682 chars]\r\n'



It looks like Python uses the wrong encoding to decode stdout of child processes:

======================================================================
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\GitHub\cpython\lib\distutils\tests\test_build_ext.py", line 61, in test_build_ext
    cmd.run()
  File "E:\GitHub\cpython\lib\distutils\command\build_ext.py", line 338, in run
    self.build_extensions()
  File "E:\GitHub\cpython\lib\distutils\command\build_ext.py", line 447, in build_extensions
    self._build_extensions_serial()
  File "E:\GitHub\cpython\lib\distutils\command\build_ext.py", line 472, in _build_extensions_serial
    self.build_extension(ext)
  File "E:\GitHub\cpython\lib\distutils\command\build_ext.py", line 532, in build_extension
    depends=ext.depends)
  File "E:\GitHub\cpython\lib\distutils\_msvccompiler.py", line 306, in compile
    self.initialize()
  File "E:\GitHub\cpython\lib\distutils\_msvccompiler.py", line 199, in initialize
    vc_env = _get_vc_env(plat_spec)
  File "E:\GitHub\cpython\lib\distutils\_msvccompiler.py", line 92, in _get_vc_env
    universal_newlines=True,
  File "E:\GitHub\cpython\lib\subprocess.py", line 636, in check_output
    **kwargs).stdout
  File "E:\GitHub\cpython\lib\subprocess.py", line 705, in run
    stdout, stderr = process.communicate(input, timeout=timeout)
  File "E:\GitHub\cpython\lib\subprocess.py", line 1062, in communicate
    stdout = self.stdout.read()
  File "E:\GitHub\cpython\lib\encodings\cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x90 in position 49: character maps to 

It would help to add a print() to lib\distutils\_msvccompiler.py:92 to get the executed command, then run manually the command, and see non-ASCII characters in the output.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 20:10:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 01:10:15 +0000
Subject: [issue26226] Various test suite failures on Windows
In-Reply-To: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za>
Message-ID: <1453943415.23.0.44809658142.issue26226@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Python 2.7.11:

>>> import socket
>>> socket.gethostname()
'\xc9manuel-PC'

This one works on Python 3 because the Python function is implemented with a call to the Windows native API.

>>> socket.gethostbyaddr(socket.gethostname())
('\xc9manuel-PC.home', [], ['fe80::c9b7:5117:eea4:a104'])

This one fails on Python 3 because it uses the gethostbyaddr() C function and then decodes the hostname from UTF-8, whereas the hostname looks more to be encoded to ISO 8859-1 or something like that. IMHO it should be decoded from the ANSI code page.

I opened the issue #26227 to track this bug.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 20:24:36 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 01:24:36 +0000
Subject: [issue26173] test_ssl.bad_cert_test() exception handling
In-Reply-To: <1453373183.85.0.754157160572.issue26173@psf.upfronthosting.co.za>
Message-ID: <1453944276.21.0.50318794169.issue26173@psf.upfronthosting.co.za>


Martin Panter added the comment:

There are more mistakes in the history of test_nonexisting_cert(). In revision 8a281bfc058d (Python 2.6), the method was added as testWrongCert(), with an existing but non-matching certificate file. But when this was ported to Python 3 in r66311, the wrongcert.pem file was not added, so Python 3 was actually testing the behaviour when the specified certificate file was missing. Then in r80596, the test method was renamed and a comment added assuming the Python 3 version with the missing file. However we already test the behaviour of missing files in test_errors().

I do not understand the ECONNRESET failure on Windows. Perhaps there is a race to do with the server closing the connection when the client should be reporting a certificate mismatch. It seems like a bug, and I suspect r80534 is not the correct fix. But I?m not in a position to investigate so I will leave that code as it is.

For Python 2 I propose wrong-cert-py2.patch:

* Rename WRONGCERT ? NONEXISTINGCERT, not to be confused with wrongcert.pem
* Repurpose test_nonexisting_cert() ? test_wrong_cert()
* Remove ENOENT exception handling from bad_cert_test()

----------
Added file: http://bugs.python.org/file41735/wrong-cert-py2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 20:29:15 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 28 Jan 2016 01:29:15 +0000
Subject: [issue26225] New misleading wording in execution model documenation
In-Reply-To: <1453939288.53.0.211010759952.issue26225@psf.upfronthosting.co.za>
Message-ID: <1453944555.49.0.579877434499.issue26225@psf.upfronthosting.co.za>


Eryk Sun added the comment:

The class example defines "i" as a local variable, which means the CPython operation used for unoptimized code (class or module/exec) is LOAD_NAME, which searches locals, globals, and builtins. The result differs from the exec example because a class is executed with a new locals dict to capture the class namespace. 

I think a more interesting case to explain is code that uses LOAD_CLASSDEREF. This operation tries locals and nonlocals, but not globals or builtins.

    i = 'global'
    def f():
        i = 'nonlocal'
        class C:
            print(i)

    >>> f()
    nonlocal

    i = 'global'
    def f():
        class C:
            print(i)
        i = 'nonlocal'

    >>> f()
    Traceback (most recent call last):
      File "", line 1, in 
      File "", line 2, in f
      File "", line 3, in C
    NameError: free variable 'i' referenced before assignment in enclosing scope

    i = 'global'
    def f():
        class C:
            locals()['i'] = 'local'
            print(i)
        i = 'nonlocal'

    >>> f()
    local

    i = 'global'
    def f():
        i = 'nonlocal'
        class C:
            nonlocal i
            print(i)
            i = 'new nonlocal'
            print(i)
        print(i)

    >>> f()
    nonlocal
    new nonlocal
    new nonlocal

----------
nosy: +eryksun

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 20:51:44 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 01:51:44 +0000
Subject: [issue26173] test_ssl.bad_cert_test() exception handling
In-Reply-To: <1453373183.85.0.754157160572.issue26173@psf.upfronthosting.co.za>
Message-ID: <1453945904.94.0.229045075224.issue26173@psf.upfronthosting.co.za>


Martin Panter added the comment:

wrong-cert-py3.patch is similar but also adds the wrongcert.pem file from Python 2.

----------
keywords:  -buildbot
stage: needs patch -> patch review
Added file: http://bugs.python.org/file41736/wrong-cert-py3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 21:34:48 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 28 Jan 2016 02:34:48 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1453948488.53.0.640928481976.issue26227@psf.upfronthosting.co.za>


Steve Dower added the comment:

Might be nice to switch the socket APIs to the Unicode ones universally. That would also clear up a range of deprecation warnings on build.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 21:44:21 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 28 Jan 2016 02:44:21 +0000
Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated
In-Reply-To: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za>
Message-ID: <1453949061.06.0.559078797544.issue20120@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I also expect very close to zero, given the still heavy adoption of Python 2 and the fact that .pypirc is not Python specific.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 22:23:04 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 28 Jan 2016 03:23:04 +0000
Subject: [issue26226] Various test suite failures on Windows
In-Reply-To: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za>
Message-ID: <1453951384.25.0.659660369975.issue26226@psf.upfronthosting.co.za>


Changes by Zachary Ware :


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 22:30:09 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 03:30:09 +0000
Subject: [issue25868] test_eintr.test_sigwaitinfo() hangs on "AMD64 FreeBSD
 CURRENT 3.x" buildbot
In-Reply-To: <1450174856.95.0.354294896083.issue25868@psf.upfronthosting.co.za>
Message-ID: <1453951809.39.0.305342559176.issue25868@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is my patch which blocks SIGUSR1. I have only tested it on Linux.

I also added a counter to the SIGALRM handler, so we can verify that it does get called by the Python sigwaitinfo() implementation.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file41737/sigwaitinfo-block.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 23:04:21 2016
From: report at bugs.python.org (Chris Torek)
Date: Thu, 28 Jan 2016 04:04:21 +0000
Subject: [issue26228] pty.spawn hangs on FreeBSD 9.3, 10.x
Message-ID: <1453953861.58.0.104331734212.issue26228@psf.upfronthosting.co.za>


New submission from Chris Torek:

The pty.spawn() code assumes that when the process on the slave side of the pty quits, the master side starts raising OSError when read-from or written-to.

That used to be true in FBSD, but then someone fixed (?) it, and now the master side simply returns EOF when read-from.  Furthermore, writes to the master simply disappear into the aether (this may be an OS bug, but even if the writes raised OSError, you would still have to type something in on stdin to get it copied over to get the error raised to get out of the loop).

The fix here makes an assumption that is true when using the built-in read calls: EOF on the master indicates that the slave is no longer reachable in any way and the whole thing should finish up immediately.  It might perhaps need a bit of documentation should someone want to substitute in their own read function (see enhancement request in issue22865).

I also fixed (sort of) issue17824, but only barely minimally, and put in a comment that it should really use the same mechanism as subprocess (but I think that should be a separate patch).

----------
files: pty.patch
keywords: patch
messages: 259088
nosy: Chris Torek
priority: normal
severity: normal
status: open
title: pty.spawn hangs on FreeBSD 9.3, 10.x
Added file: http://bugs.python.org/file41738/pty.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 23:04:46 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 28 Jan 2016 04:04:46 +0000
Subject: [issue17394] Add slicing support to collections.deque
In-Reply-To: <1362972021.66.0.443403979058.issue17394@psf.upfronthosting.co.za>
Message-ID: <1453953886.96.0.29107479721.issue17394@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Returning a deque is preferred.  For this stage, I just want to review the code and make sure it algorithmically correct (slicing is complicated and has a lot of cases).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 23:13:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 04:13:23 +0000
Subject: [issue26220] Unicode HOWTO references a question mark that isn't in
 snippet
In-Reply-To: <1453914908.97.0.691892593639.issue26220@psf.upfronthosting.co.za>
Message-ID: <20160128041320.30766.20232@psf.io>


Roundup Robot added the comment:

New changeset 63c1c7cdad0f by Martin Panter in branch '3.5':
Issue #26220: Remove outdated comment about a question mark
https://hg.python.org/cpython/rev/63c1c7cdad0f

New changeset dbf90175ea50 by Martin Panter in branch 'default':
Issue #26220: Merge Unicode how-to from 3.5
https://hg.python.org/cpython/rev/dbf90175ea50

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 23:18:43 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 04:18:43 +0000
Subject: [issue26220] Unicode HOWTO references a question mark that isn't in
 snippet
In-Reply-To: <1453914908.97.0.691892593639.issue26220@psf.upfronthosting.co.za>
Message-ID: <1453954723.73.0.0177005887047.issue26220@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the report Quentin.

----------
nosy: +martin.panter
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 00:23:51 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Thu, 28 Jan 2016 05:23:51 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1453958631.08.0.21412860698.issue26227@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

FWIW this patch doesn't fix the test_httpservers failure (or any other) in #26226

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 01:08:25 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 06:08:25 +0000
Subject: [issue26228] pty.spawn hangs on FreeBSD 9.3, 10.x
In-Reply-To: <1453953861.58.0.104331734212.issue26228@psf.upfronthosting.co.za>
Message-ID: <1453961305.39.0.0623564825524.issue26228@psf.upfronthosting.co.za>


Martin Panter added the comment:

I agree with all the changes you made. I made one review comment.

It would be nice to add a test case to expose the problem. Correct me if I am wrong, but it doesn?t look like pty.spawn() is tested at all.

FWIW on Linux, reading from the master end seems to raise EIO if the slave has been closed. And writing to the master when the slave is closed seems to fill up a buffer and eventually blocks.

Ideally I think the best solution for handing exec() failure (Issue 17824) would be to eliminate fork-exec with posix_spawn(); see Issue 20104. But as you say, that?s a separate problem.

----------
components: +Library (Lib)
nosy: +martin.panter
stage:  -> patch review
type:  -> behavior
versions: +Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 01:26:15 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Jan 2016 06:26:15 +0000
Subject: [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1453962375.67.0.244403412264.issue25314@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Hi Julien, thanks for your patch and sorry for the lack of reviews. I find the new wording in the second hunk confusing:

``'store_true'`` and ``'store_false'`` - These store the values ``False`` respectively (Note that these default to ``False`` and ``True``  respectively).  These are special cases of ``'store_const'``.

On first read, It seems to contradict itself.  I know what is meant, but I think it should be expanded a bit.

Also, the part about ``store_const`` should still mention the default for its value (not for the const). I suppose it's ``None``?

----------
nosy: +georg.brandl

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 01:28:42 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Thu, 28 Jan 2016 06:28:42 +0000
Subject: [issue26002] make statistics.median_grouped more efficient
In-Reply-To: <1451830918.88.0.211778162331.issue26002@psf.upfronthosting.co.za>
Message-ID: <1453962522.25.0.601998541448.issue26002@psf.upfronthosting.co.za>


Upendra Kumar added the comment:

Can someone please review my patch?  I think it can increase the performance significantly of the median_grouped() function. But, I don't have any standard way of checking if it would improve or will be an overkill for the median_grouped() function?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 01:40:24 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 06:40:24 +0000
Subject: [issue26199] fix broken link to
 hamcrest.library.integration.match_equality in unittest.mock "getting
 started" documentation
In-Reply-To: <1453738852.52.0.691213360087.issue26199@psf.upfronthosting.co.za>
Message-ID: <20160128064021.30752.15436@psf.io>


Roundup Robot added the comment:

New changeset e4b0f003ad13 by Berker Peksag in branch '3.5':
Issue #26199: Fix broken link in unittest.mock-examples.rst
https://hg.python.org/cpython/rev/e4b0f003ad13

New changeset 7c38a47fd4d5 by Berker Peksag in branch 'default':
Issue #26199: Fix broken link in unittest.mock-examples.rst
https://hg.python.org/cpython/rev/7c38a47fd4d5

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 01:41:58 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 28 Jan 2016 06:41:58 +0000
Subject: [issue26199] fix broken link to
 hamcrest.library.integration.match_equality in unittest.mock "getting
 started" documentation
In-Reply-To: <1453738852.52.0.691213360087.issue26199@psf.upfronthosting.co.za>
Message-ID: <1453963318.09.0.657114508711.issue26199@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Raphael!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 01:51:27 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 06:51:27 +0000
Subject: [issue20598] argparse docs: '7'.split() is confusing magic
In-Reply-To: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za>
Message-ID: <1453963887.05.0.422753468386.issue20598@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch changing all the '. . .'.split() calls to lists of strings. I think the illustrations are actually less complicated to understand when you see the list directly, and they more consistent with the remaining illustrations that already use lists, but I see Benjamin disagrees.

----------
keywords: +patch
nosy: +martin.panter
stage:  -> patch review
versions: +Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41739/arg-list.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 02:01:54 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 07:01:54 +0000
Subject: [issue26034] venv documentation out of date
In-Reply-To: <1452141532.31.0.700374014076.issue26034@psf.upfronthosting.co.za>
Message-ID: <20160128070148.62668.55561@psf.io>


Roundup Robot added the comment:

New changeset d2a32b78be96 by Berker Peksag in branch '3.5':
Issue #26034: Sync documentation of --clear with its behavior
https://hg.python.org/cpython/rev/d2a32b78be96

New changeset 5764cc02244d by Berker Peksag in branch 'default':
Issue #26034: Sync documentation of --clear with its behavior
https://hg.python.org/cpython/rev/5764cc02244d

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 02:03:28 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 28 Jan 2016 07:03:28 +0000
Subject: [issue20598] argparse docs: '7'.split() is confusing magic
In-Reply-To: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za>
Message-ID: <1453964608.94.0.0858474957939.issue20598@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I don't feel that strongly about it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 02:03:52 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 28 Jan 2016 07:03:52 +0000
Subject: [issue26034] venv documentation out of date
In-Reply-To: <1452141532.31.0.700374014076.issue26034@psf.upfronthosting.co.za>
Message-ID: <1453964632.67.0.276837783796.issue26034@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, Dan. Most of the docs has already been updated in c3c188a0325a. I've updated the remaining ones.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 02:06:04 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 28 Jan 2016 07:06:04 +0000
Subject: [issue26002] make statistics.median_grouped more efficient
In-Reply-To: <1451830918.88.0.211778162331.issue26002@psf.upfronthosting.co.za>
Message-ID: <1453964764.79.0.807396305126.issue26002@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This code looks good and will certainly reduce the number of comparisons in non-trivial cases.

FWIW, It looks like the index functions are lifted directly from the bisect docs.

Steven, any objections?

----------
nosy: +rhettinger
stage:  -> patch review
versions:  -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 02:13:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 07:13:34 +0000
Subject: [issue26034] venv documentation out of date
In-Reply-To: <1452141532.31.0.700374014076.issue26034@psf.upfronthosting.co.za>
Message-ID: <20160128071331.30746.45632@psf.io>


Roundup Robot added the comment:

New changeset 9c5370405393 by Berker Peksag in branch '3.5':
Issue #26034: Improve wording of clear parameter
https://hg.python.org/cpython/rev/9c5370405393

New changeset 0fb96a43d381 by Berker Peksag in branch 'default':
Issue #26034: Improve wording of clear parameter
https://hg.python.org/cpython/rev/0fb96a43d381

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 02:22:38 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Thu, 28 Jan 2016 07:22:38 +0000
Subject: [issue26002] make statistics.median_grouped more efficient
In-Reply-To: <1451830918.88.0.211778162331.issue26002@psf.upfronthosting.co.za>
Message-ID: <1453965758.32.0.105178567511.issue26002@psf.upfronthosting.co.za>


Upendra Kumar added the comment:

Yeah, I slightly modified the functions from the bisect docs to suit for the purpose here.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 02:25:11 2016
From: report at bugs.python.org (Anders Rundgren)
Date: Thu, 28 Jan 2016 07:25:11 +0000
Subject: [issue26229] Make number serialization ES6/V8 compatible
Message-ID: <1453965911.58.0.319543725596.issue26229@psf.upfronthosting.co.za>


New submission from Anders Rundgren:

ECMA has in their latest release defined that JSON elements must be ordered during serialization.  This is easy to accomplish using Python's OrderedDict.  What is less trivial is that numbers have to be formatted in a certain way as well.  I have tested 100 millions specific and random values and found out that Python 3.5.1 is mathematically identical to ES6/V8 but has some differences in formatting:

   IEEE Double        ECMAScript 6/V8            Python 3.5.1

c43211ede4974a35, -333333333333333300000,    -3.333333333333333e+20
c3fce97ca0f21056, -33333333333333336000,     -3.3333333333333336e+19
c3c7213080c1a6ac, -3333333333333334000,      -3.333333333333334e+18
c39280f39a348556, -333333333333333400,       -3.333333333333334e+17
c35d9b1f5d20d557, -33333333333333340,        -3.333333333333334e+16

c327af4c4a80aaac, -3333333333333334,         -3333333333333334.0

bf0179ec9cbd821e, -0.000033333333333333335,  -3.3333333333333335e-05
becbf647612f3696, -0.0000033333333333333333, -3.3333333333333333e-06

4024000000000000, 10,                        10.0
0000000000000000, 0,                         0.0
4014000000000000, 5,                         5.0
3f0a36e2eb1c432d, 0.00005,                   5e-05
3ed4f8b588e368f1, 0.000005,                  5e-06

3ea0c6f7a0b5ed8d, 5e-7,                      5e-07

Why could this be important?

https://github.com/Microsoft/ChakraCore/issues/149

# Python test program
import binascii
import struct
import json

f = open('c:\\es6\\numbers\\es6testfile100m.txt','rb')

l = 0;
string = '';

while True:
  byte = f.read(1);
  if len(byte) == 0:
    exit(0)
  if byte == b'\n':
    l = l + 1;
    i = string.find(',')
    if i <= 0 or i >= len(string) - 1:
      print('Bad string: ' + str(i))
      exit(0)
    hex = string[:i]
    while len(hex) < 16:
      hex = '0' + hex
    o = dict()
    o['double'] = struct.unpack('>d',binascii.a2b_hex(hex))[0]
    py3Double = json.dumps(o)[11:-1]
    es6Double = string[i + 1:]
    if es6Double != py3Double:
      es6Dpos = es6Double.find('.')
      py3Dpos = py3Double.find('.')
      es6Epos = es6Double.find('e')
      py3Epos = py3Double.find('e')
      if py3Epos > 0:
        py3Exp = int(py3Double[py3Epos + 1:])
      if es6Dpos < 0 and py3Dpos > 0:
        if es6Epos < 0 and py3Epos > 0:
          py3New = py3Double[:py3Dpos] + py3Double[py3Dpos + 1:py3Epos - len(py3Double)]
          q = py3Exp - py3Epos + py3Dpos
          while q >= 0:
            py3New += '0'
            q -= 1
          if py3New != es6Double:
            print('E1: ' + py3New)
            exit(0)
        elif py3Epos < 0:
          py3New = py3Double[:-2]
          if py3New != es6Double:
            print('E2: ' + py3New)
            exit(0)
        else:
          print (error + hex + '#' + es6Double + '#' + py3Double)
          exit(0)
      elif es6Dpos > 0 and py3Dpos > 0 and py3Epos > 0 and es6Epos < 0:
        py3New = py3Double[py3Dpos - 1:py3Dpos] + py3Double[py3Dpos + 1:py3Epos - len(py3Double)]
        q = py3Exp + 1
        while q < 0:
          q += 1
          py3New = '0' + py3New
        py3New = py3Double[0:py3Dpos - 1] + '0.' + py3New 
        if py3New != es6Double:
          print('E3: ' + py3New + '#' + es6Double)
          exit(0)
      elif es6Dpos == py3Dpos and py3Epos > 0 and es6Epos > 0:
        py3New = py3Double[:py3Epos + 2] + str(abs(py3Exp))
        if py3New != es6Double:
          print('E4: ' + py3New + '#' + es6Double)
          exit(0)
      elif es6Dpos > 0 and py3Dpos < 0 and py3Epos > 0 and es6Epos < 0:
        py3New = py3Double[:py3Epos - len(py3Double)]
        q = py3Exp + 1
        while q < 0:
          q += 1
          py3New = '0' + py3New
        py3New = '0.' + py3New 
        if py3New != es6Double:
          print('E5: ' + py3New + '#' + es6Double)
          exit(0)
      else:
        print ('Unexpected: ' + hex + '#' + es6Double + '#' + py3Double)
        exit(0)
    string = ''
    if l % 10000 == 0:
      print(l)
  else:
    string += byte.decode(encoding='UTF-8')

----------
components: Interpreter Core
messages: 259105
nosy: anders.rundgren.net at gmail.com
priority: normal
severity: normal
status: open
title: Make number serialization ES6/V8 compatible
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 02:55:38 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 28 Jan 2016 07:55:38 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1453967738.59.0.13864031506.issue26227@psf.upfronthosting.co.za>


Eryk Sun added the comment:

The patch is missing the "errors" parameter of PyUnicode_DecodeLocale. But it should call PyUnicode_DecodeMBCS instead. In the "C" locale, PyUnicode_DecodeLocale is Latin-1 because the CRT mbstowcs just casts the values to wchar_t.

socket_getnameinfo also decodes as UTF-8:

    >>> socket.getnameinfo(('127.0.0.1', 20), 0)
    Traceback (most recent call last):
      File "", line 1, in 
    UnicodeDecodeError: 'utf-8' codec can't decode byte 0x82 in position 0: invalid start byte

Steve, does your suggestion include reimplementing socket.gethostbyaddr and socket.gethostbyname_ex using GetNameInfoW and GetAddrInfoW? gethostbyaddr and gethostbyname are deprecated and lack a Unicode implementation.

----------
nosy: +eryksun

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 03:07:25 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 28 Jan 2016 08:07:25 +0000
Subject: [issue26223] decimal.to_eng_string() does not implement engineering
 notation in all cases.
In-Reply-To: <1453922113.08.0.48679853518.issue26223@psf.upfronthosting.co.za>
Message-ID: <1453968445.11.0.391105978826.issue26223@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I also agree that we shouldn't change the current code. As Raymond says, it may be worth a doc change.

Serge: I was confused by your initial report. If I understand the StackOverflow question correctly, this isn't about the output for *infinite* numbers (e.g., `Decimal('inf')` and `Decimal('-inf')`), and I'm not sure what that would mean. Rather, it's about the output for small finite numbers, where an exponent wouldn't be used in the normal scientific notation. So some people would (understandably) rather see:

>>> Decimal('123456').to_eng_string()
'123.456e3'
>>> Decimal('0.02').to_eng_string()
'20e-3'

than the current

>>> Decimal('123456').to_eng_string()
'123456'
>>> Decimal('0.02').to_eng_string()
'0.02'

for example. Is that what you meant? 

Stefan: IEEE 754 does cover formatting (in section 5.12, "Details of conversion between floating-point data and external character sequences"), but has nothing to say about engineering formats.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 03:48:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 08:48:27 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1453970907.7.0.802122810462.issue26227@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The patch is missing the "errors" parameter of PyUnicode_DecodeLocale.

Woops, I shouldn't write patch in the middle of the night :-) Hopefully, I didn't push it :-) PyUnicode_DecodeLocale() should only be used when the encoding depends on the *currenet* value of LC_CTYPE.

Here, the ANSI code page is fine, and so PyUnicode_DecodeFSDefault() should be used instead.

> socket_getnameinfo also decodes as UTF-8

Hum, let met try a new patch. It decodes hostname from the ANSI code page on Windows for:

* socket.getnameinfo()
* socket.gethostbyaddr()
* socket.gethostbyname_ex()

The behaviour on other platforms is unchanged.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 03:49:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 08:49:24 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1453970964.61.0.907742348078.issue26227@psf.upfronthosting.co.za>


Changes by STINNER Victor :


Added file: http://bugs.python.org/file41740/gethostbyaddr_encoding-2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 04:00:19 2016
From: report at bugs.python.org (Julien Baley)
Date: Thu, 28 Jan 2016 09:00:19 +0000
Subject: [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1453971619.98.0.369273051909.issue25314@psf.upfronthosting.co.za>


Julien Baley added the comment:

Hi Georg,

thanks for your answer. I think maybe you're missing a bit in there?

"``'store_true'`` and ``'store_false'`` - These store the values ``True`` and ``False`` respectively (Note that these default to ``False`` and ``True``  respectively).  These are special cases of ``'store_const'``."  (added "``True`` andd")

But if I'm correct, you're talking of the parenthesis which would be confusing? Can we come up with a better wording?

"(and default to False and True if the action is not triggered)" ?

As for `store_const`, R. David Murray says it has no default. It is technically correct: store_const behaves like any other action in that it defaults to whatever the argument `default` in `add_argument` is set to.
The fact that `default` defaults to None is indicated in 16.4.3.5. default:
"The default keyword argument of add_argument(), whose value defaults to None,"
Therefore, I believe it is more correct the way R. David Murray suggested.

What do you think?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 04:20:32 2016
From: report at bugs.python.org (tom liu)
Date: Thu, 28 Jan 2016 09:20:32 +0000
Subject: [issue26230] Cookies do not correct if cookiename includes [ or ]
Message-ID: <1453972832.46.0.774490417388.issue26230@psf.upfronthosting.co.za>


Changes by tom liu :


----------
components: Extension Modules
nosy: tom_lt
priority: normal
severity: normal
status: open
title: Cookies do not correct if cookiename includes [ or ]
type: behavior
versions: Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 04:21:50 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 28 Jan 2016 09:21:50 +0000
Subject: [issue21201] Uninformative error message in multiprocessing.Manager()
In-Reply-To: <1397236820.61.0.692426224091.issue21201@psf.upfronthosting.co.za>
Message-ID: <1453972910.44.0.579819502739.issue21201@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Looks good to me. Perhaps we can use utils.info() to print the exception.

----------
nosy: +berker.peksag, davin
stage:  -> patch review
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 04:29:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Jan 2016 09:29:11 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1453973351.9.0.747564685526.issue26227@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added comments on Rietveld.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 04:41:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 09:41:03 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1453974063.09.0.258642734771.issue26227@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Added comments on Rietveld.

Crap. It's easy to miss a compilation error on extensions :-/

I used "make && ./python -m test -v test_socket" to validate  gethostbyaddr_encoding-2.patch and it succeded.

Maybe we should setup.py to *fail* if an extension failed to be compiled?

New patch should have less typos :-) I also checked for reference leak using ./python -m test -R 3:3 test_socket => no leak.


> Why not use PyUnicode_DecodeFSDefault on all platforms? It is used in
gethostname() on Unix.

I don't know which encoding is the best choice on UNIX. I prefer to move step by step and fix an obvious bug on Windows blocking ?manuel (see his issue #26226). (?manuel uses ?manuel-PC for its hostname, an non-ASCII hostname ;-))

I guess that UTF-8 works in most cases on UNIX, whereas using the locale encoding can introduce regressions if the hostname is non-ASCII. For example, decoding non-ASCII hostname would fail with LANG=C which forces an ASCII locale encoding.

The issue #9377 proposes a more advanced code to choose the encoding to decode hostnames. Sorry, I didn't follow this issue recently, so I don't know if it proposes to use surrogateescape and/or IDNA.

I prefer to discuss the encoding used on UNIX in a new issue (or better continue the existing discussion on issue #9377?).

----------
Added file: http://bugs.python.org/file41741/gethostbyaddr_encoding-3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 04:42:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 09:42:57 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453974063.09.0.258642734771.issue26227@psf.upfronthosting.co.za>
Message-ID: 


STINNER Victor added the comment:

By the way, thanks for your reviews. Code review rocks ;-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 04:46:58 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 28 Jan 2016 09:46:58 +0000
Subject: [issue26230] Cookies do not correct if cookiename includes [ or ]
Message-ID: <1453974418.61.0.137317614242.issue26230@psf.upfronthosting.co.za>


New submission from SilentGhost:

You'd have to provide more information if you'd like that looked into.

----------
nosy: +SilentGhost
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 04:52:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Jan 2016 09:52:35 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1453974755.31.0.994698264912.issue26194@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

full_deque2.diff LGTM. But I have added minor suggestions on Rietveld.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 04:54:36 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 28 Jan 2016 09:54:36 +0000
Subject: [issue20598] argparse docs: '7'.split() is confusing magic
In-Reply-To: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za>
Message-ID: <1453974875.99.0.999408394585.issue20598@psf.upfronthosting.co.za>


SilentGhost added the comment:

I think it's worth saying that this wasn't a random choice intended to confuse beginners. Strings used represent input that is identical to the command-line input: if one wants to test it, one can just copy that string directly into the propmpt, it might be harder to reconstruct it from a list of strings.

----------
nosy: +SilentGhost

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 05:07:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Jan 2016 10:07:00 +0000
Subject: [issue20598] argparse docs: '7'.split() is confusing magic
In-Reply-To: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za>
Message-ID: <1453975620.65.0.540213975078.issue20598@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Using str.split() for splitting full command line on arguments is anti-idiom. More correct way is to use shlex. But this is overkill for argparse examples (and in most cases we already have a list sys.argv). Explicit lists look clear enough.

The patch LGTM.

----------
assignee: docs at python -> martin.panter
nosy: +serhiy.storchaka
stage: patch review -> commit review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 05:10:56 2016
From: report at bugs.python.org (Serge Stroobandt)
Date: Thu, 28 Jan 2016 10:10:56 +0000
Subject: [issue26223] decimal.to_eng_string() does not implement engineering
 notation in all cases.
In-Reply-To: <1453922113.08.0.48679853518.issue26223@psf.upfronthosting.co.za>
Message-ID: <1453975856.29.0.231610202294.issue26223@psf.upfronthosting.co.za>


Serge Stroobandt added the comment:

Mark: Don't shoot the messenger!
I literally quoted the implemented proprietary specification.
However, I do agree that the term "numbers (or bases) with an infinte decimal representation" would be more appropriate in this context.

Also, improving documentation is good, but having a new function with the desired *true* engineering notation would be even better! Admittedly, this was my ultimate objective for filing this enhancement bug.

Thanks for commenting on StackExchange.

----------
type: behavior -> enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 05:28:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 10:28:35 +0000
Subject: [issue26230] Cookies do not correct if cookiename includes [ or ]
In-Reply-To: <1453974418.61.0.137317614242.issue26230@psf.upfronthosting.co.za>
Message-ID: <1453976915.29.0.554809511786.issue26230@psf.upfronthosting.co.za>


Martin Panter added the comment:

Is this a duplicate of Issue 25228? If not, can you please explain what the problem is, perhaps with a demo, what it does wrong, and what you expect the result should be.

----------
nosy: +martin.panter
stage:  -> test needed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 05:35:05 2016
From: report at bugs.python.org (tom liu)
Date: Thu, 28 Jan 2016 10:35:05 +0000
Subject: [issue26230] Cookies do not correct if cookiename includes [ or ]
In-Reply-To: <1453974418.61.0.137317614242.issue26230@psf.upfronthosting.co.za>
Message-ID: <1453977305.16.0.487253607531.issue26230@psf.upfronthosting.co.za>


tom liu added the comment:

similar to issue25228.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 05:35:10 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 10:35:10 +0000
Subject: [issue19023] ctypes docs: Unimplemented and undocumented features
In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>
Message-ID: <20160128103507.24402.79270@psf.io>


Roundup Robot added the comment:

New changeset 732fdd03e708 by Martin Panter in branch '3.5':
Issue #19023: Document ctypes array and pointer classes
https://hg.python.org/cpython/rev/732fdd03e708

New changeset a78cbb2125a8 by Martin Panter in branch 'default':
Issue #19023: Merge ctypes doc and tests from 3.5
https://hg.python.org/cpython/rev/a78cbb2125a8

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 05:43:17 2016
From: report at bugs.python.org (Jacky)
Date: Thu, 28 Jan 2016 10:43:17 +0000
Subject: [issue26231] HTTPResponse.close() should consume all remaining data
 in body if any
Message-ID: <1453977797.39.0.133146806463.issue26231@psf.upfronthosting.co.za>


New submission from Jacky:

HTTPResponse.close() in httplib should consume all remaining data in body if any. Or the followed request would get the unread content from the previous request, which result in the wrong result.

The following code shown that the second request will get a wrong status code if calling HTTPResponse.close() on the first response.

The whole code consists of a HTTP server and a client. The server will always return 403 for testing.


def client():
    conn = httplib.HTTPConnection(HOST, PORT)
    conn.request('GET', PATH, None, headers={})
    rsp = conn.getresponse()
    print rsp.status
    rsp.close()  # close response

    conn.request('GET', PATH, None, headers={})
    rsp2 = conn.getresponse()
    print rsp2.status  # --> should be 403

The full version see the attached file (The server used Tornado)

----------
components: Library (Lib)
files: zzz.py
messages: 259122
nosy: Jacky
priority: normal
severity: normal
status: open
title: HTTPResponse.close() should consume all remaining data in body if any
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file41742/zzz.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 05:53:22 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 28 Jan 2016 10:53:22 +0000
Subject: [issue16731] xxlimited/xxmodule docstrings ambiguous
In-Reply-To: <1355946646.69.0.259699636535.issue16731@psf.upfronthosting.co.za>
Message-ID: <1453978402.76.0.661964246727.issue16731@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I think the difference between xxlimited and xxmodule is still a bit ambiguous. I would expect a mention of PEP 384 or a link to https://docs.python.org/3/c-api/stable.html to explain what Py_LIMITED_API really is.

+#ifndef Py_LIMITED_API
+# error "This file requires Py_LIMITED_API"
+#endif

I don't have a strong opinion about this, but I think the error message could be more informative (e.g. you must define a Py_LIMITED_API macro) Or we can improve https://docs.python.org/3/c-api/stable.html to give an example there.

----------
nosy: +berker.peksag, serhiy.storchaka
stage:  -> patch review
type:  -> enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 05:59:57 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 10:59:57 +0000
Subject: [issue26231] HTTPResponse.close() should consume all remaining data
 in body if any
In-Reply-To: <1453977797.39.0.133146806463.issue26231@psf.upfronthosting.co.za>
Message-ID: <1453978797.8.0.134691517561.issue26231@psf.upfronthosting.co.za>


Martin Panter added the comment:

The documentation already says you have to read the whole response before sending a new request: . So I think this is more like a new feature than a bug fix, and would have to go into 3.6.

But I am not sure it is a good idea. What if the response is a large multi-megabyte download? In that case, it might make more sense to shut down the connection and start a new one.

It might be possible to add extra error checking to prevent reading a second response until the first is complete. I am not sure if that is practical or worthwhile though.

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 06:44:04 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 28 Jan 2016 11:44:04 +0000
Subject: [issue26230] Cookies do not correct if cookiename includes [ or ]
In-Reply-To: <1453974418.61.0.137317614242.issue26230@psf.upfronthosting.co.za>
Message-ID: <1453981444.45.0.850914862981.issue26230@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
stage: test needed -> resolved
superseder:  -> Regression in cookie parsing with brackets and quotes

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 07:48:36 2016
From: report at bugs.python.org (Raphael Das Gupta)
Date: Thu, 28 Jan 2016 12:48:36 +0000
Subject: [issue26199] fix broken link to
 hamcrest.library.integration.match_equality in unittest.mock "getting
 started" documentation
In-Reply-To: <1453738852.52.0.691213360087.issue26199@psf.upfronthosting.co.za>
Message-ID: <1453985316.61.0.165835943906.issue26199@psf.upfronthosting.co.za>


Raphael Das Gupta added the comment:

You're welcome. Thanks for applying the patch.

Shouldn't it be applied to other affected versions (3.3 and 3.4), too, though?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 08:03:37 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Jan 2016 13:03:37 +0000
Subject: [issue26136] DeprecationWarning for PEP 479 (generator_stop)
In-Reply-To: <1453001479.54.0.173509242949.issue26136@psf.upfronthosting.co.za>
Message-ID: <1453986217.81.0.398728043755.issue26136@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
keywords: +easy
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 08:07:32 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Jan 2016 13:07:32 +0000
Subject: [issue26160] Tutorial incorrectly claims that (explicit) relative
 imports don't work in the main module
In-Reply-To: <1453273352.49.0.425335373136.issue26160@psf.upfronthosting.co.za>
Message-ID: <1453986452.67.0.0159476237597.issue26160@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 08:07:59 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 28 Jan 2016 13:07:59 +0000
Subject: [issue26199] fix broken link to
 hamcrest.library.integration.match_equality in unittest.mock "getting
 started" documentation
In-Reply-To: <1453738852.52.0.691213360087.issue26199@psf.upfronthosting.co.za>
Message-ID: <1453986479.88.0.0825323742125.issue26199@psf.upfronthosting.co.za>


Berker Peksag added the comment:

3.3 and 3.4 are in security-fix-only mode, which means they won't get bugfix and documentation updates anymore. See https://docs.python.org/devguide/devcycle.html for details.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 08:19:55 2016
From: report at bugs.python.org (Jacky)
Date: Thu, 28 Jan 2016 13:19:55 +0000
Subject: [issue26231] HTTPResponse.close() should consume all remaining data
 in body if any
In-Reply-To: <1453977797.39.0.133146806463.issue26231@psf.upfronthosting.co.za>
Message-ID: <1453987195.52.0.579852108176.issue26231@psf.upfronthosting.co.za>


Jacky added the comment:

In my opinion, HTTPResponse.close() should do really close work. Not only releasing the underlying file obj but also need to consume the remaining data to make sure the request complete.

If close() does not consume the remaining data, the user would have to do it after invoking close(), regardless of how large the data is. But how do do it, the HTTPResponse has been closed. So we have to use HTTPConnection.sock to do read work. However, this looks somewhat weird.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 08:31:19 2016
From: report at bugs.python.org (Kevin Dwyer)
Date: Thu, 28 Jan 2016 13:31:19 +0000
Subject: [issue26222] Missing code in linux_distribution python 2.7.11
In-Reply-To: <1453916728.01.0.709818070841.issue26222@psf.upfronthosting.co.za>
Message-ID: <1453987879.9.0.924575163769.issue26222@psf.upfronthosting.co.za>


Kevin Dwyer added the comment:

The quoted code doesn't exist in 2.7.10 (https://hg.python.org/cpython/file/v2.7.10/Lib/platform.py)

It looks like it's from a patch applied by Debian themselves: see http://sources.debian.net/src/python2.7/2.7.11-3/debian/patches/platform-lsbrelease.diff/?hl=33#L33

----------
nosy: +kdwyer

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 09:05:35 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 28 Jan 2016 14:05:35 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1453989935.03.0.828132248861.issue26227@psf.upfronthosting.co.za>


Steve Dower added the comment:

I couldn't remember the names of the alternate functions Windows provides to do the encoding for you, but yes. There are socket APIs there that do encoding and handle memory allocation more safely.

Apart from bugs like this, it's not really urgent and it requires someone motivated to do it. Might be a good project for someone at the PyCon sprints.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 09:08:17 2016
From: report at bugs.python.org (David Szotten)
Date: Thu, 28 Jan 2016 14:08:17 +0000
Subject: [issue26232] Mock(spec=spec) has no effect
Message-ID: <1453990097.49.0.0657857764216.issue26232@psf.upfronthosting.co.za>


New submission from David Szotten:

Unless i misunderstand the docs, i would expect `Mock(foo)` to have the same effect as `create_autospec(foo)`, but that doesn't appear to be the case:

>>> m1 = mock.Mock(spec=lambda: None)
>>> m2 = mock.create_autospec(spec=lambda: None)
>>> m1(1)

>>> m2(1)
# snip
TypeError: too many positional arguments

----------
components: Library (Lib)
messages: 259130
nosy: davidszotten
priority: normal
severity: normal
status: open
title: Mock(spec=spec) has no effect
type: behavior
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 09:12:10 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Thu, 28 Jan 2016 14:12:10 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1453990330.82.0.465002106779.issue26227@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Yes, it's not all that urgent. And Victor's latest patch doesn't work, either :(

I wonder if there's a way to (temporarily) modify the output of ``socket.gethostname()`` to be able to test such weird corner cases.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 09:18:45 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 28 Jan 2016 14:18:45 +0000
Subject: [issue24841] Some test_ssl network tests fail if svn.python.org is
 not accessible.
In-Reply-To: <1439252941.43.0.787973342114.issue24841@psf.upfronthosting.co.za>
Message-ID: <1453990725.13.0.662394805816.issue24841@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> although they will need updating since the Issue 24841 changeover to pythontest.net.

I think you meant issue 25940, right? :)

Do you want me to wait for issue 25940?

----------
versions:  -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 09:23:18 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 14:23:18 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1453990998.51.0.905154513679.issue26227@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Yes, it's not all that urgent. And Victor's latest patch doesn't work, either :(

Could you please elaborate? The patch applies cleanly? You rebuild the socket module? Which error message do you get?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 09:41:39 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Thu, 28 Jan 2016 14:41:39 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1453992099.11.0.0922125456964.issue26227@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Oh, sorry. The patch applies without any problem, then I re-compile everything and run, and the same error happens. I re-compiled just now to make double sure.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 09:45:53 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 14:45:53 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <20160128144549.24404.3721@psf.io>


Roundup Robot added the comment:

New changeset 0681f0a1fe6e by Victor Stinner in branch '3.5':
Windows: Decode hostname from ANSI code page
https://hg.python.org/cpython/rev/0681f0a1fe6e

New changeset 26f6d8cc2749 by Victor Stinner in branch 'default':
Merge 3.5: Issue #26227
https://hg.python.org/cpython/rev/26f6d8cc2749

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 09:48:17 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 14:48:17 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1453992497.62.0.624270682252.issue26227@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Oh, sorry. The patch applies without any problem, then I re-compile everything and run, and the same error happens. I re-compiled just now to make double sure.

I tested my patch on Windows. I called my computer h??a (3 non-ASCII letters!). Without the patch, I get the UTF-8 decoding error, as expected. With the patch, it gets the nice "h??a" Unicode string, correctly decoded. I tested socket.getfqdn().

My patch will not fix all your issues at once :-) In the issue #26226, I saw at least 3 different bugs. But I'm now sure that my patch fixes a real bug, so I pushed it to Python 3.5 and default (3.6).

Thanks for the bug report Emanuel ;-)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 09:51:39 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Thu, 28 Jan 2016 14:51:39 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1453992699.03.0.277205683466.issue26227@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

If it worked for you, I assume it's fine and I probably did something wrong on my side. Thanks for the fix!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 09:51:42 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 14:51:42 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1453992702.17.0.965943930593.issue26227@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Steve:
"""
I couldn't remember the names of the alternate functions Windows provides to do the encoding for you, but yes. There are socket APIs there that do encoding and handle memory allocation more safely.

Apart from bugs like this, it's not really urgent and it requires someone motivated to do it. Might be a good project for someone at the PyCon sprints.
"""

Yeah, using the native Windows API is better, it gives access to the full Unicode character set. But it requires to spend time on the C code, and *I* am not interested to work on such project.

If you are motived, please open a new issue for that. If you are not motivated, I'm not sure that it's worth to open a bug report. Using an hostname not encodable to the ANSI code page would probably cause serious issues (not in Python, but in other applications).

When I played with filenames non-encodable to the ANSI code page, I also get errors from multiple applications, whereas Python now uses the native Windows API to access the filesystem. So sometimes Python is better than some other applications, sometimes it's as good :-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 09:58:29 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 14:58:29 +0000
Subject: [issue24705] sysconfig._parse_makefile doesn't expand ${} vars
 appearing before $() vars
In-Reply-To: <1437739980.61.0.17161588188.issue24705@psf.upfronthosting.co.za>
Message-ID: <20160128145821.62660.31009@psf.io>


Roundup Robot added the comment:

New changeset dec734dfe2fe by Berker Peksag in branch '3.5':
Issue #24705: Add a test case for ef84d21f5292
https://hg.python.org/cpython/rev/dec734dfe2fe

New changeset f9a18032cc22 by Berker Peksag in branch 'default':
Issue #24705: Add a test case for ef84d21f5292
https://hg.python.org/cpython/rev/f9a18032cc22

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 09:59:40 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 28 Jan 2016 14:59:40 +0000
Subject: [issue24705] sysconfig._parse_makefile doesn't expand ${} vars
 appearing before $() vars
In-Reply-To: <1437739980.61.0.17161588188.issue24705@psf.upfronthosting.co.za>
Message-ID: <1453993180.48.0.718176795693.issue24705@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I've added a test case for ef84d21f5292. I think this can be closed now. Please reopen if not.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 10:04:02 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 28 Jan 2016 15:04:02 +0000
Subject: [issue26232] Mock(spec=spec) has no effect
In-Reply-To: <1453990097.49.0.0657857764216.issue26232@psf.upfronthosting.co.za>
Message-ID: <1453993442.12.0.980339217011.issue26232@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
nosy: +michael.foord

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 10:11:46 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 15:11:46 +0000
Subject: [issue26233] select.epoll.wait() should away calling malloc() each
 time
Message-ID: <1453993905.97.0.27003618713.issue26233@psf.upfronthosting.co.za>


New submission from STINNER Victor:

My colleague Fabio M. Di Nitto noticed that the memory allocation on the heap (PyMem_Malloc()) in select.epoll.wait() can have an impact on performance when select.epoll.wait() is a busy applicatin.

He proposed attached patch to allocate memory on the stack for up to FD_SETSIZE-1 events: see attached patch.

----------
components: Library (Lib)
files: epoll_stack.patch
keywords: patch
messages: 259141
nosy: haypo, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: select.epoll.wait() should away calling malloc() each time
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file41743/epoll_stack.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 10:44:14 2016
From: report at bugs.python.org (Michael Foord)
Date: Thu, 28 Jan 2016 15:44:14 +0000
Subject: [issue26232] Mock(spec=spec) has no effect
In-Reply-To: <1453990097.49.0.0657857764216.issue26232@psf.upfronthosting.co.za>
Message-ID: <1453995854.13.0.112210658981.issue26232@psf.upfronthosting.co.za>


Michael Foord added the comment:

create_autospec and Mock(spec=spec) are very different. Mock(spec=spec) creates a mock object with the same *attributes* as the original. It does not create functions like create_autospec can.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 10:52:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 15:52:43 +0000
Subject: [issue26233] select.epoll.wait() should away calling malloc() each
 time
In-Reply-To: <1453993905.97.0.27003618713.issue26233@psf.upfronthosting.co.za>
Message-ID: <1453996363.57.0.359000785259.issue26233@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I dislike allocating large memory block on the stack, we should not abuse it.

I propose instead to store the memory block allocated on the heap in the epoll object. Attached patch implements this idea.

The buffer is stolen from the epoll object when epoll.poll() is called. Then it is stored again inside the epoll object, except if another thread stored a larger buffer in the meanwhile. The largest buffer is also kept.

The buffer exchange is protected by the GIL.

My patch also overallocates the buffer by 50% to avoid calling realloc() to many times. Using the selectors module, maxevents is the number of registered FD. Using asyncio, the number of registered FD changes a lot.

Side effect: the memory block is not released after the call to epoll.poll(). If you can it with an insane max_events, it will bloat your memory until your close the poller.

If the approach is considered interested and efficient, I can work on a similar patch for other pollers.

----------
Added file: http://bugs.python.org/file41744/epoll_buffer.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 11:01:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Jan 2016 16:01:12 +0000
Subject: [issue26233] select.epoll.wait() should away calling malloc() each
 time
In-Reply-To: <1453993905.97.0.27003618713.issue26233@psf.upfronthosting.co.za>
Message-ID: <1453996871.99.0.552083946745.issue26233@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Any benchmarks?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 11:17:56 2016
From: report at bugs.python.org (David Szotten)
Date: Thu, 28 Jan 2016 16:17:56 +0000
Subject: [issue26232] Mock(spec=spec) has no effect
In-Reply-To: <1453990097.49.0.0657857764216.issue26232@psf.upfronthosting.co.za>
Message-ID: <1453997876.02.0.384801061782.issue26232@psf.upfronthosting.co.za>


David Szotten added the comment:

thanks, and apologies for the noise

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 11:42:48 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 16:42:48 +0000
Subject: [issue26233] select.epoll.wait() should away calling malloc() each
 time
In-Reply-To: <1453993905.97.0.27003618713.issue26233@psf.upfronthosting.co.za>
Message-ID: <1453999368.37.0.283032319147.issue26233@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Any benchmarks?

Wait, it's easier to write a patch than to cook a benchmark :-)

Attached script bench_epoll_poll.py creates a lot of sockets and call epoll.poll() in non-blocking mode (timeout=0). You can decide to create or not events.

It looks like performance when epoll.poll() gets events are unchanged with my patch.

The performance are better when epoll.poll() doesn't get any event: between 6% and 20% faster.

I'm not completly sure that it's worth it since we are talking about nanoseconds. The largest seen difference was 94 nanoseconds: 420 ns => 326 ns.

My microbenchmark is unstable. Even if it runs the benchmark 25 or 50 times and take the minimum, I have to run it between 3 and 10 times to see the "real" minimum timing... It's a common problem for microbenchmarks with timing smaller than 1 ms.


Create read+events (10 sockets):

*  Without the patch: Best of 25 runs (100000 loops, 10 FDs): 1294 ns per call to epoll.poll()
*  With the patch: Best of 50 runs (100000 loops, 10 FDs): 1221 ns (-6%) per call to epoll.poll()

Create read+events (8000 sockets):

*  Without the patch: Best of 25 runs (10 loops, 16000 FDs): 4.6 ms per call to epoll.poll()
*  With the patch: Best of 25 runs (10 loops, 16000 FDs): 4.6 ms (same) per call to epoll.poll()

Don't create events (10 sockets):

*  Without the patch: Best of 50 runs (100000 loops, 10 FDs): 367 ns per call to epoll.poll()
*  With the patch: Best of 50 runs (100000 loops, 10 FDs): 343 ns (-7%) per call to epoll.poll()

Don't create events (1000 sockets):

*  Without the patch: Best of 50 runs (100000 loops, 1000 FDs): 420 ns per call to epoll.poll()
*  With the patch: Best of 50 runs (100000 loops, 1000 FDs): 326 ns (-22%) per call to epoll.poll()

Don't create events (16000 sockets):

*  Without the patch: Best of 50 runs (100000 loops, 16000 FDs): 422 ns per call to epoll.poll()
*  With the patch: Best of 50 runs (100000 loops, 16000 FDs): 338 ns (-20%) per call to epoll.poll()

----------
Added file: http://bugs.python.org/file41745/bench_epoll_poll.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 11:45:53 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 28 Jan 2016 16:45:53 +0000
Subject: [issue26233] select.epoll.poll() should away calling malloc() each
 time
In-Reply-To: <1453993905.97.0.27003618713.issue26233@psf.upfronthosting.co.za>
Message-ID: <1453999553.37.0.228038171039.issue26233@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Overallocating by 50% might be overkill here; I wouldn't imagine most users of epoll.poll would use anything but:

1. Limit to 1 event
2. Limit to some constant K events
3. Use default maxevents (FD_SETSIZE - 1)

Even if called in pathological order, that would only involve three progressive reallocations before steady state; potentially avoiding one of them (if K and FD_SETSIZE - 1 are within the 50% overallocation) in a relatively uncommon case doesn't seem like it's worth the guaranteed waste in the common case.

----------
nosy: +josh.r
title: select.epoll.wait() should away calling malloc() each time -> select.epoll.poll() should away calling malloc() each time

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 11:48:46 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 28 Jan 2016 16:48:46 +0000
Subject: [issue21201] Uninformative error message in multiprocessing.Manager()
In-Reply-To: <1397236820.61.0.692426224091.issue21201@psf.upfronthosting.co.za>
Message-ID: <1453999726.21.0.611956309934.issue21201@psf.upfronthosting.co.za>


Changes by Mark Lawrence :


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 12:09:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 17:09:05 +0000
Subject: [issue26233] select.epoll.poll() should away calling malloc() each
 time
In-Reply-To: <1453993905.97.0.27003618713.issue26233@psf.upfronthosting.co.za>
Message-ID: <1454000945.98.0.5743702265.issue26233@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Overallocating by 50% might be overkill here; I wouldn't imagine most users of epoll.poll would use anything but: (...)

See my second message:
"My patch also overallocates the buffer by 50% to avoid calling realloc() to many times. Using the selectors module, maxevents is the number of registered FD. Using asyncio, the number of registered FD changes a lot."

If you use selectors or asyncio, max_events depends on the current number of registered FD and it almost changes at each call to epoll.poll().

asyncio only registers an FD to listen for read events when the application starts to read on this FD. There is also an optimization: it first tries to read bytes in non-blocking mode. It only registers the FD if it receives 0 byte (if recv() fails with a "woud block" error). It's similar for write events.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 12:15:12 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 17:15:12 +0000
Subject: [issue25868] test_eintr.test_sigwaitinfo() hangs on "AMD64 FreeBSD
 CURRENT 3.x" buildbot
In-Reply-To: <1450174856.95.0.354294896083.issue25868@psf.upfronthosting.co.za>
Message-ID: <20160128171509.24418.60527@psf.io>


Roundup Robot added the comment:

New changeset ddce15b21c21 by Victor Stinner in branch '3.5':
Backport fixes on test_eintr
https://hg.python.org/cpython/rev/ddce15b21c21

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 12:15:12 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 17:15:12 +0000
Subject: [issue25234] test_eintr.test_os_open hangs under Xcode 7
In-Reply-To: <1443210079.4.0.780575467942.issue25234@psf.upfronthosting.co.za>
Message-ID: <20160128171509.24418.98465@psf.io>


Roundup Robot added the comment:

New changeset ddce15b21c21 by Victor Stinner in branch '3.5':
Backport fixes on test_eintr
https://hg.python.org/cpython/rev/ddce15b21c21

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 12:58:01 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 17:58:01 +0000
Subject: [issue26198] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <20160128175758.16754.99031@psf.io>


Roundup Robot added the comment:

New changeset 1c690cb4def8 by Serhiy Storchaka in branch '3.5':
Issue #26198: Added tests for "es", "et", "es#", "et#" and "C" format units
https://hg.python.org/cpython/rev/1c690cb4def8

New changeset 745ad3010384 by Serhiy Storchaka in branch 'default':
Issue #26198: Added tests for "es", "et", "es#", "et#" and "C" format units
https://hg.python.org/cpython/rev/745ad3010384

New changeset 60a2d67dacb3 by Serhiy Storchaka in branch '2.7':
Issue #26198: Added tests for string-related format units of PyArg_Parse*()
https://hg.python.org/cpython/rev/60a2d67dacb3

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 13:38:50 2016
From: report at bugs.python.org (paul j3)
Date: Thu, 28 Jan 2016 18:38:50 +0000
Subject: [issue20598] argparse docs: '7'.split() is confusing magic
In-Reply-To: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za>
Message-ID: <1454006330.06.0.729408874328.issue20598@psf.upfronthosting.co.za>


paul j3 added the comment:

I can understand changing 

    '7'.split()

but this change is IMO ugly:

-     >>> print(parser.parse_args('--foo B cmd --arg1 XX ZZ'.split()))
+     >>> print(parser.parse_args(['--foo', 'B', 'cmd', '--arg1', 'XX', 'ZZ']))

I've answered a lot of argparse questions on Stackoverflow, and don't recall anyone being confused by the use of 'split' in the documentation.  The documentation as a whole is overwealming to many users.  But not this detail.

Many SO answers use the split idiom.  Being aware of this issue I have edited some of my answers to use lists, even if I used split when creating them in Ipython.   But only in the short cases.

Other times I copy-n-paste a complete (short) script, along with one or more sample runs (bash line plus printout).  That kind of display is closer to what most new users expect and see.  But it does not fit with the doctest format used in the argparse documentation.

Come to think of it, the doctest example format might be a greater hindrance to understanding than the split idiom.  New users tend to construct complete scripts, and then complain that it doesn't do what they want.  Often I have to ask them to print sys.argv to see what the shell is giving the parser.  And to print args to see what parser is giving back.  New users aren't in habit of using interactive test inputs as illustrated in the docs.

The patch proposed here may be nice in terms of consistency, but I don't think it improves readability.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 13:44:32 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 28 Jan 2016 18:44:32 +0000
Subject: [issue26229] Make number serialization ES6/V8 compatible
In-Reply-To: <1453965911.58.0.319543725596.issue26229@psf.upfronthosting.co.za>
Message-ID: <1454006672.23.0.35919258047.issue26229@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
components: +Extension Modules -Interpreter Core
nosy: +ezio.melotti, pitrou, rhettinger
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 13:45:36 2016
From: report at bugs.python.org (Kevin Dwyer)
Date: Thu, 28 Jan 2016 18:45:36 +0000
Subject: [issue26222] Missing code in linux_distribution python 2.7.11
In-Reply-To: <1453916728.01.0.709818070841.issue26222@psf.upfronthosting.co.za>
Message-ID: <1454006736.1.0.653412820106.issue26222@psf.upfronthosting.co.za>


Changes by Kevin Dwyer :


----------
type: performance -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 14:33:33 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 19:33:33 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>
Message-ID: <20160128193327.24406.31081@psf.io>


Roundup Robot added the comment:

New changeset 687be1cbe587 by Serhiy Storchaka in branch '3.5':
Issue #19883: Fixed possible integer overflows in zipimport.
https://hg.python.org/cpython/rev/687be1cbe587

New changeset f4631dc56ecf by Serhiy Storchaka in branch 'default':
Issue #19883: Fixed possible integer overflows in zipimport.
https://hg.python.org/cpython/rev/f4631dc56ecf

New changeset cebcd2fd3e1f by Serhiy Storchaka in branch '2.7':
Issue #19883: Fixed possible integer overflows in zipimport.
https://hg.python.org/cpython/rev/cebcd2fd3e1f

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 14:44:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 19:44:43 +0000
Subject: [issue26202] The range() object is deepcopied as atomic
In-Reply-To: <1453755186.26.0.578500471201.issue26202@psf.upfronthosting.co.za>
Message-ID: <20160128194440.30748.21602@psf.io>


Roundup Robot added the comment:

New changeset 5772eae17a82 by Serhiy Storchaka in branch '3.5':
Issue #26202: copy.deepcopy() now correctly copies range() objects with
https://hg.python.org/cpython/rev/5772eae17a82

New changeset d5d0b62c2830 by Serhiy Storchaka in branch 'default':
Issue #26202: copy.deepcopy() now correctly copies range() objects with
https://hg.python.org/cpython/rev/d5d0b62c2830

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 14:46:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Jan 2016 19:46:46 +0000
Subject: [issue26202] The range() object is deepcopied as atomic
In-Reply-To: <1453755186.26.0.578500471201.issue26202@psf.upfronthosting.co.za>
Message-ID: <1454010406.83.0.925408195062.issue26202@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Victor.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 14:59:29 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 28 Jan 2016 19:59:29 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1454011169.42.0.331742937873.issue26194@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Since slicing is going to be added to deques, it is worth thinking about what the behavior should be there as well:

   d = deque('abcde', maxlen=7)
   d[3:4] = 'efghijklm'

Side note: repetition behaves like extend() using maxlen to decide how much to truncate from the left:

    >>> from collections import deque
    >>> d = deque('abcde', maxlen=8)
    >>> d *= 2
    >>> d
    deque(['c', 'd', 'e', 'a', 'b', 'c', 'd', 'e'], maxlen=8)

Ideally, the deque API should be coherent and simple taken as a whole so that the behaviors are consistent and predictable as possible even if the general rules lead to some oddities in some uncommon cases.  

One such general rule could be:  "When maxlen is defined, operations proceed as if the deque were unbounded and then truncation is applied to the left" (this is like the rule in decimal where inputs to operations are treated as precise and context rounding is applied after the operation).  The general rule would fit a mental models of "inserted new data is prioritized over old data", that "maxlen is all about automatically evicting data to make room for the newer data", and that "methods without 'left' in their name correspond to newest data on the right and next to be evicted on the left".

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 15:30:36 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 28 Jan 2016 20:30:36 +0000
Subject: [issue26186] LazyLoader rejecting use of SourceFileLoader
In-Reply-To: <1453577280.26.0.226746274701.issue26186@psf.upfronthosting.co.za>
Message-ID: <1454013036.24.0.585719322242.issue26186@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I think I'm liking the following approach:

  if __debug__:
    hopefully_None = loader.create_module(spec)
    if hopefully_None is not None:
        warnings.warn("watch out!", ImportWarning)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 15:40:29 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 20:40:29 +0000
Subject: [issue26233] select.epoll.poll() should avoid calling malloc() each
 time
In-Reply-To: <1453993905.97.0.27003618713.issue26233@psf.upfronthosting.co.za>
Message-ID: <1454013629.15.0.657877905599.issue26233@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
title: select.epoll.poll() should away calling malloc() each time -> select.epoll.poll() should avoid calling malloc() each time

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 15:54:26 2016
From: report at bugs.python.org (paul j3)
Date: Thu, 28 Jan 2016 20:54:26 +0000
Subject: [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1454014466.44.0.455339759237.issue25314@psf.upfronthosting.co.za>


paul j3 added the comment:

How about:

    These store the values True and False respectively (and default to False and True if absent).

The reference to `store_const` is confusing, since almost no one uses that action.

The `store_const` paragraph has:

    (Note that the const keyword argument defaults to the rather unhelpful None.) 

But the most common `store` action also defaults to the default default None.  In fact most action types do that.

With 'store' action, None is a useful default, since its impossible to provide in the commandline.  Thus

     if args.foo is None:

is a clear test that 'foo' was not present in the commandline.  I can imagine using the same test on a 'store_const' argument (though I've never had the need to use it or recommend it).

I'm almost of the opinion that we should remove that parenthetical remark.

The 'const' parameter is used most often with 'store' and "nargs='?'", as illustrated in that 'nargs' subsection.

To complicate things, if I provide a "argument_default='boo'" parameter in the parser definition, it overrides all of these default defaults, including for 'store_true'.  In that case an explicit 'default=False' is *required*, not superfluous.

To further complicate things, 'parser.set_defaults' can override all of these.

We've almost given users too many ways of setting 'default'. :)  Fortunately in practice they don't use most of them.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 16:19:12 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 21:19:12 +0000
Subject: [issue26222] Missing code in linux_distribution python 2.7.11
In-Reply-To: <1453916728.01.0.709818070841.issue26222@psf.upfronthosting.co.za>
Message-ID: <1454015952.76.0.73007651115.issue26222@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think Kevin is right. Debian often carries its own downstream patches. In this case, the patch was proposed in Issue 9514, which is closed as ?won?t fix?. In Python 3, linux_distribution() is apparently deprecated (Issue 1322).

----------
components: +Library (Lib) -Build
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 16:31:53 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 28 Jan 2016 21:31:53 +0000
Subject: [issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot
In-Reply-To: <1453813782.88.0.185045860262.issue26207@psf.upfronthosting.co.za>
Message-ID: <1454016713.15.0.0934282008197.issue26207@psf.upfronthosting.co.za>


Steve Dower added the comment:

This has been confirmed as a bug in VS 2015 RTM that was fixed in Update 1.

It only affects debug builds, which are not common and I expect most people using them to be keeping VS up to date.

I'd rather not add extra logic to distutils just to detect this case. Ideally, the buildbots should be updated to VS 2015 Update 1 at some point.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 16:34:01 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 21:34:01 +0000
Subject: [issue24841] Some test_ssl network tests fail if svn.python.org is
 not accessible.
In-Reply-To: <1439252941.43.0.787973342114.issue24841@psf.upfronthosting.co.za>
Message-ID: <1454016841.42.0.759351582873.issue24841@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes sorry I did mean Issue 25940 (too many bug numbers!), but only the main change which has already been made (revision adf750b1252d etc). So you don?t have to wait for that.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 16:37:40 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 21:37:40 +0000
Subject: [issue20598] argparse docs: '7'.split() is confusing magic
In-Reply-To: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za>
Message-ID: <1454017060.46.0.818574523162.issue20598@psf.upfronthosting.co.za>


Martin Panter added the comment:

I don?t want to make any controversial changes. Half the purpose of the patch was to let people see what it would look like. Another option would be to only do the single or empty list changes, and leave most of the longer lists as they are with split().

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 16:53:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 21:53:46 +0000
Subject: [issue26198] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1454018026.43.0.930755786706.issue26198@psf.upfronthosting.co.za>


Martin Panter added the comment:

One review comment

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 17:06:17 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 22:06:17 +0000
Subject: [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1454018777.89.0.383535198063.issue25314@psf.upfronthosting.co.za>


Martin Panter added the comment:

I definitely agree with removing the remark about the ?const? value with store_const. People here seem to be overloading the terms ?default? and ?argument?. When using store_const, it seems the programmer must also specify a value for the ?const? parameter to add_argument(). It is incorrect to say it is None if not explicitly set.

On the other hand, I think if the end user omits a CLI argument configured with store_const, then the argparse module will substitute None, or the value of the ?default? parameter to add_argument().

For the original report about store_true/false, perhapse it would be sufficient to port revision 49677cc6d83a to Python 3. Although there is a stray ?using? that should probably be fixed.

----------
nosy: +martin.panter
versions: +Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 17:24:48 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 22:24:48 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>
Message-ID: <1454019888.4.0.201398637749.issue19883@psf.upfronthosting.co.za>


Martin Panter added the comment:

This seems to be causing an infinite loop in 2.7, in test_cmd_line_script.CmdLineTest.test_module_in_package_in_zipfile():

test_module_in_package_in_zipfile (test.test_cmd_line_script.CmdLineTest) ... ^C
Test suite interrupted by signal SIGINT.
1 test omitted:
    test_cmd_line_script
[Exit 1]
[vadmium at localhost cpython]$ sudo strace -p 11412 2>&1 | head
Process 11412 attached - interrupt to quit
lseek(3, 1024, SEEK_SET)                = 1024
lseek(3, 1024, SEEK_SET)                = 1024
lseek(3, 1024, SEEK_SET)                = 1024
lseek(3, 1024, SEEK_SET)                = 1024
lseek(3, 1024, SEEK_SET)                = 1024
lseek(3, 1024, SEEK_SET)                = 1024
lseek(3, 1024, SEEK_SET)                = 1024
lseek(3, 1024, SEEK_SET)                = 1024
lseek(3, 1024, SEEK_SET)                = 1024
[vadmium at localhost cpython]$ ls -l /proc/11412/fdtotal 0
lr-x------ 1 vadmium users 64 Jan 29 22:23 0 -> pipe:[1249749]
l-wx------ 1 vadmium users 64 Jan 29 22:23 1 -> pipe:[1249750]
l-wx------ 1 vadmium users 64 Jan 29 22:23 2 -> pipe:[1249750]
lr-x------ 1 vadmium users 64 Jan 29 22:23 3 -> /tmp/tmpHMiuOm/test_zip.zip (deleted)
[vadmium at localhost cpython]$ kill 11412

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 17:34:27 2016
From: report at bugs.python.org (Julien Baley)
Date: Thu, 28 Jan 2016 22:34:27 +0000
Subject: [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1454020467.57.0.183459271184.issue25314@psf.upfronthosting.co.za>


Julien Baley added the comment:

I like paul.j3's suggestion, but it would probably make more sense to have it consistent with python2 and port the change Martin pointed to.

How does one do that?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 17:36:37 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 22:36:37 +0000
Subject: [issue26198] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1454020597.46.0.463538351091.issue26198@psf.upfronthosting.co.za>


Martin Panter added the comment:

Also, test_getargs2 seems faulty on 2.7. I am seeing MemoryError; some of the buildbots are segfaulting.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 17:38:13 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 22:38:13 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>
Message-ID: <20160128223806.45909.80463@psf.io>


Roundup Robot added the comment:

New changeset 82ee3c24bb86 by Serhiy Storchaka in branch '2.7':
Fixed an infinite loop in zipimport caused by cebcd2fd3e1f (issue #19883).
https://hg.python.org/cpython/rev/82ee3c24bb86

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 17:39:08 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Jan 2016 22:39:08 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>
Message-ID: <1454020748.54.0.354886195088.issue19883@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Martin.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 17:56:45 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 22:56:45 +0000
Subject: [issue26198] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <20160128225642.24917.53785@psf.io>


Roundup Robot added the comment:

New changeset d0b4be7d2134 by Serhiy Storchaka in branch '2.7':
Fixed a crash in new tests in test_getargs2 added in 60a2d67dacb3 (issue #26198).
https://hg.python.org/cpython/rev/d0b4be7d2134

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 18:03:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Jan 2016 23:03:04 +0000
Subject: [issue26198] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1454022184.85.0.106170326701.issue26198@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Martin. This was 64-bit specific bug.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 18:08:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Jan 2016 23:08:09 +0000
Subject: [issue26198] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1454022489.58.0.0973287282689.issue26198@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is updated patch.

----------
Added file: http://bugs.python.org/file41746/pyarg_parse_encoded_string_2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 18:09:54 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 23:09:54 +0000
Subject: [issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot
In-Reply-To: <1454016713.15.0.0934282008197.issue26207@psf.upfronthosting.co.za>
Message-ID: 


STINNER Victor added the comment:

> I'd rather not add extra logic to distutils just to detect this case.

Hum, does it make sense to skip some tests on VS 2015 without the
update? (Is it difficult to detect VS version?)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 18:21:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 23:21:49 +0000
Subject: [issue19023] ctypes docs: Unimplemented and undocumented features
In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>
Message-ID: <20160128232139.45903.51181@psf.io>


Roundup Robot added the comment:

New changeset 034b077d3015 by Martin Panter in branch '2.7':
Issue #19023: Document ctypes array and pointer classes
https://hg.python.org/cpython/rev/034b077d3015

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 18:31:03 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 23:31:03 +0000
Subject: [issue19023] ctypes docs: Unimplemented and undocumented features
In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>
Message-ID: <1454023863.83.0.934427250707.issue19023@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay I have committed the Array and _Pointer stuff. I suggest if anyone wants to work on the Union classes, they open a separate report. (I never understood what they are for. C doesn?t have much little or big endian stuff; byte order mostly depends on the ABI, so why is ctypes different?)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 18:54:30 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 28 Jan 2016 23:54:30 +0000
Subject: [issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot
In-Reply-To: <1453813782.88.0.185045860262.issue26207@psf.upfronthosting.co.za>
Message-ID: <1454025270.14.0.841433820063.issue26207@psf.upfronthosting.co.za>


Steve Dower added the comment:

For this particular issue, the way to detect it is to read HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\DevDiv\vc\Servicing\14.0\Tools.X86.X64 at UpdateVersion and see if it is at least "14.0.23506".

This doesn't extend to other VS versions, but it should be sufficient to skip the tests for this bug. I really don't want that check in the actual stdlib.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 19:07:33 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 29 Jan 2016 00:07:33 +0000
Subject: [issue26234] The typing module includes 're' and 'io' in __all__
Message-ID: <1454026053.81.0.969583520836.issue26234@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

If you write "from typing import *" you get "re" and "io" for free, which is surprising if this import occurs after an actual "import re" or "import io".

The solution is not to include those two in __all__. You can still use them -- use "from typing import re" explicitly or reference them as "typing.re".

Because typing is provisional I'll fix this in 3.5.2 as well.

----------
messages: 259177
nosy: gvanrossum
priority: release blocker
severity: normal
status: open
title: The typing module includes 're' and 'io' in __all__
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 19:10:00 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 29 Jan 2016 00:10:00 +0000
Subject: [issue26234] The typing module includes 're' and 'io' in __all__
In-Reply-To: <1454026053.81.0.969583520836.issue26234@psf.upfronthosting.co.za>
Message-ID: <1454026200.15.0.621430586344.issue26234@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Cross-reference: https://github.com/python/typing/issues/178

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 19:10:30 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 29 Jan 2016 00:10:30 +0000
Subject: [issue26234] The typing module includes 're' and 'io' in __all__
In-Reply-To: <1454026053.81.0.969583520836.issue26234@psf.upfronthosting.co.za>
Message-ID: <1454026230.78.0.125142925004.issue26234@psf.upfronthosting.co.za>


Changes by Guido van Rossum :


----------
assignee:  -> gvanrossum
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 19:16:38 2016
From: report at bugs.python.org (paul j3)
Date: Fri, 29 Jan 2016 00:16:38 +0000
Subject: [issue26235] argparse docs: Positional * argument in mutually
 exclusive group requires a default parameter
Message-ID: <1454026598.04.0.15054739834.issue26235@psf.upfronthosting.co.za>


New submission from paul j3:

The documentation for Mutual exclusion

https://docs.python.org/3/library/argparse.html#mutual-exclusion

needs a note that a mutually exclusive group may contain one positional argument.  But that argument must be either nargs='?', or nargs='*'.  If '*' it must also have a default parameter (other than None).

(this issue came up recently on stackoverflow.  It may have also been raised in the past as a bug/issue, but I don't have time at moment to search.  I had to search through several layers of code to remember all the details.)

http://stackoverflow.com/questions/35044288/how-can-i-create-an-argparse-mutually-exclusive-group-with-multiple-positional-p

----------
assignee: docs at python
components: Documentation
messages: 259179
nosy: docs at python, paul.j3
priority: normal
severity: normal
status: open
title: argparse docs: Positional * argument in mutually exclusive group requires a default parameter
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 19:19:28 2016
From: report at bugs.python.org (Jeremy Kloth)
Date: Fri, 29 Jan 2016 00:19:28 +0000
Subject: [issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot
In-Reply-To: <1453813782.88.0.185045860262.issue26207@psf.upfronthosting.co.za>
Message-ID: <1454026768.66.0.634380312562.issue26207@psf.upfronthosting.co.za>


Jeremy Kloth added the comment:

I'm upgrading the VS installation on my buildbot currently so this should be a non-issue going forward.

However, I think it would be good to add/change the bug title to include something about the /LTCG error so as to enable better searching when developers do encounter this error in their own projects.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 19:42:37 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 29 Jan 2016 00:42:37 +0000
Subject: [issue26189] Interpreter returns control to cmd.exe early
In-Reply-To: <1453782201.5.0.210485589702.issue26189@psf.upfronthosting.co.za>
Message-ID: <56AAA7FB.9040702@mail.mipt.ru>


Ivan Pozdeev added the comment:

Here, ShellExecuteExW is indeed called, with the specified parameters, 
but the hProcess member is still NULL after the call. This must be the 
reason for the discrepancy.

----------
nosy: +Vano

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 20:32:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 29 Jan 2016 01:32:46 +0000
Subject: [issue26234] The typing module includes 're' and 'io' in __all__
In-Reply-To: <1454026053.81.0.969583520836.issue26234@psf.upfronthosting.co.za>
Message-ID: <1454031166.16.0.408499158528.issue26234@psf.upfronthosting.co.za>


Martin Panter added the comment:

I would argue against changing this. They seem to be documented classes, so I guess this would break pydoc. It is a similar situation to os.open(), threading.enumerate(), etc. But I don?t have a strong opinion, and accept other people like keeping __all__ a minimal set of names and not reflecting the full API.

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 20:33:29 2016
From: report at bugs.python.org (Jeremy Kloth)
Date: Fri, 29 Jan 2016 01:33:29 +0000
Subject: [issue26207] test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot
In-Reply-To: <1453813782.88.0.185045860262.issue26207@psf.upfronthosting.co.za>
Message-ID: <1454031209.42.0.968051376887.issue26207@psf.upfronthosting.co.za>


Jeremy Kloth added the comment:

My buildbot updated to VS2015.1 successfully.  test_distutils is passing again.

As to the bug title, it should mention the incorrect DLL version error, not the /LTCG *warning*.  That's what I get for just doing a quick scan of the comments.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 20:48:07 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 29 Jan 2016 01:48:07 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1454032087.36.0.569339105178.issue26039@psf.upfronthosting.co.za>


Martin Panter added the comment:

I left some review comments.

Since the rules for read-only and write-only access are so different, would it make more sense to have a separate method? Maybe your writefile() name, or open_write() or something? I am not too fussed, but unless there is a chance of being able to open a read-write random access file, I find these split-personality open() methods a bit ?un-Pythonic?. On the other hand, I guess it is superficially consistent with other open() functions.

Also, perhaps if you guaranteed the write-only option returned a file-like object, you could use shutil.copyfileobj() rather than a custom read-write loop.

----------
nosy: +martin.panter
stage: test needed -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 21:49:45 2016
From: report at bugs.python.org (TarotRedhand)
Date: Fri, 29 Jan 2016 02:49:45 +0000
Subject: [issue26155] 3.5.1 installer issue on Win 7 32 bit
In-Reply-To: <1453213607.65.0.0758375238655.issue26155@psf.upfronthosting.co.za>
Message-ID: <1454035785.94.0.637063283301.issue26155@psf.upfronthosting.co.za>


TarotRedhand added the comment:

Sorry for the delay but RL intervened. Because of the size of the log files (total of 17.7 megs), rather than post the contents in one these windows I placed them into a 7zip 7z archive. I am attaching them to this message.

I hope this helps.

----------
Added file: http://bugs.python.org/file41747/Python 351 logs.7z

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 21:56:54 2016
From: report at bugs.python.org (TarotRedhand)
Date: Fri, 29 Jan 2016 02:56:54 +0000
Subject: [issue26155] 3.5.1 installer issue on Win 7 32 bit
In-Reply-To: <1453213607.65.0.0758375238655.issue26155@psf.upfronthosting.co.za>
Message-ID: <1454036214.34.0.614226770751.issue26155@psf.upfronthosting.co.za>


TarotRedhand added the comment:

Please ignore the part about the 7z being attached to the last message. 
This site wanted me to divulge certain personal information, that I am not prepared to give, before it would upload that file.

I have instead placed it into my dropbox/public folder the address is

https://dl.dropboxusercontent.com/u/15541064/Python/Python%20351%20logs.7z

As I said before I hope this is of use.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 22:04:18 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 29 Jan 2016 03:04:18 +0000
Subject: [issue17890] argparse: mutually exclusive groups full of suppressed
 args can cause AssertionErrors
In-Reply-To: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za>
Message-ID: <1454036658.28.0.135396999873.issue17890@psf.upfronthosting.co.za>


Changes by Martin Panter :


Added file: http://bugs.python.org/file30108/7691d1d4b955.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 22:09:22 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jan 2016 03:09:22 +0000
Subject: [issue26173] test_ssl.bad_cert_test() exception handling
In-Reply-To: <1453373183.85.0.754157160572.issue26173@psf.upfronthosting.co.za>
Message-ID: <20160129030918.24398.2439@psf.io>


Roundup Robot added the comment:

New changeset 14463726a4a0 by Martin Panter in branch '2.7':
Issue #26173: Fix test_ssl confusion with non-existing cert and wrongcert.pem
https://hg.python.org/cpython/rev/14463726a4a0

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 22:30:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 29 Jan 2016 03:30:00 +0000
Subject: [issue22363] argparse AssertionError with
 add_mutually_exclusive_group and help=SUPPRESS
In-Reply-To: <1410176787.11.0.945188170372.issue22363@psf.upfronthosting.co.za>
Message-ID: <1454038200.4.0.750885659284.issue22363@psf.upfronthosting.co.za>


Martin Panter added the comment:

I left one review comment, but it seems there is more discussion at Issue 17890, which also originally proposed a very similar fix.

----------
nosy: +martin.panter
resolution:  -> duplicate
stage:  -> patch review
status: open -> closed
superseder:  -> argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 22:31:48 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 29 Jan 2016 03:31:48 +0000
Subject: [issue17890] argparse: mutually exclusive groups full of
 help-suppressed args can cause AssertionErrors
In-Reply-To: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za>
Message-ID: <1454038308.97.0.690290392343.issue17890@psf.upfronthosting.co.za>


Martin Panter added the comment:

See duplicate Issue 22363 for the traceback, and a workaround. There is also a patch there similar to Garrett?s original fix, but using the RE r'%s *%s ?'.

I restored the diff from Garrett?s repository, in case it is still useful.

Yogesh: I am not familiar with how the code works, and I struggle to be excited at using regular expressions to build a usage message :). But can you explain why you changed Garrett?s original fix? Does it affect intentional double spaces (or tabs, non-ASCII spaces, etc) in customizable parts of the usage message?

----------
nosy: +martin.panter
stage:  -> patch review
title: argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors -> argparse: mutually exclusive groups full of help-suppressed args can cause AssertionErrors

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 22:34:46 2016
From: report at bugs.python.org (Julia Dolgova)
Date: Fri, 29 Jan 2016 03:34:46 +0000
Subject: [issue26236] urllib2 initiate irregular call to gethostbyaddr
Message-ID: <1454038486.05.0.415307366057.issue26236@psf.upfronthosting.co.za>


New submission from Julia Dolgova:

I'm using python 2.7. My system is windows 7(64-bit). I also use proxy.
urllib2.urlopen usually implements 0,2..1sec but sometimes sends a strange UDP to 137 port (netbios-ns) of the remote server, waits 4..6 sec. and then sends HTTP-request.

If I disable Netbios over TCP/IP in my system settings no UDP to 137 port is sent, but urlopen still implements 4..6sec.

I've found out that the delay happens in 
_socket.gethostbyaddr(HostName)
called by socket.getfqdn(HostName)
called by urllib.proxy_bypass_registry(HostName)
called by urllib.proxy_bypass(HostName)
called by urllib2.ProxyHandler.proxy_open 

HostName='pykasso.rc-online.ru'

"nslookup pykasso.rc-online.ru" works quickly in my computer

I suppose the problem is that the hostname is passed into gethostbyaddr instead of IP

If I add an IP-verification of the string before socket.getfqdn() call in urllib.proxy_bypass_registry()
try:
        socket.inet_aton(rawHost) #### I added this operator
        fqdn = socket.getfqdn(rawHost)
        if fqdn != rawHost:
               host.append(fqdn)
except socket.error:
        pass

then no delay happens.

My proposal is to make an IP-verification in urllib.proxy_bypass_registry() or to add an opportunity for a programmer to refuse a proxy bypass attempt

----------
components: Library (Lib), Windows
messages: 259190
nosy: juliadolgova, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: urllib2 initiate irregular call to gethostbyaddr
type: performance
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 22:37:19 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 29 Jan 2016 03:37:19 +0000
Subject: [issue26234] The typing module includes 're' and 'io' in __all__
In-Reply-To: <1454026053.81.0.969583520836.issue26234@psf.upfronthosting.co.za>
Message-ID: <1454038639.59.0.275633970562.issue26234@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Well, PEP 484 and typing.py are provisional. So small changes, even to documented behavior, are fine.  (I'm also changing @overload, per the change in PEP 484 that was discussed recently.)

Can you suggest a doc change?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 22:56:43 2016
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 29 Jan 2016 03:56:43 +0000
Subject: [issue26189] Interpreter returns control to cmd.exe early
In-Reply-To: <1453602542.98.0.731550634512.issue26189@psf.upfronthosting.co.za>
Message-ID: <1454039803.73.0.690975977832.issue26189@psf.upfronthosting.co.za>


Eryk Sun added the comment:

Ensure that the .lnk target is the expected path to python.exe:

    C:\Temp>py -3 -c ^
    More? "from win32com import client^
    More?
    More? lnk = client.Dispatch('WScript.Shell').^
    More? CreateShortCut('python.lnk')^
    More?
    More? print('target:\n%s' % lnk.Targetpath)
    target:
    C:\Program Files\Python27\python.exe

You can attach a debugger to cmd and set a breakpoint on CreateProcessW. The first time it's called is for the failed attempt to execute the .lnk as a PE image (cmd doesn't make assumptions about file extensions). The 2nd time, if called, should be from a ShellExecute worker thread. For example (this time using Windows 7):

    C:\Temp>.\python.lnk -c "import sys;sys.exit(42)"

    Breakpoint 0 hit
    kernel32!CreateProcessW:
    00000000`76c307a0 4883ec68        sub     rsp,68h
    0:000> du @rdx
    00000000`003942f0  ".\python.lnk  -c "import sys;sys"
    00000000`00394330  ".exit(42)""
    0:000> g

    Breakpoint 0 hit
    kernel32!CreateProcessW:
    00000000`76c307a0 4883ec68        sub     rsp,68h
    0:001> du @rdx
    00000000`003d3640  ""C:\Program Files\Python27\pytho"
    00000000`003d3680  "n.exe"  -c "import sys;sys.exit("
    00000000`003d36c0  "42)""
    0:001> k2
    Child-SP          RetAddr           Call Site
    00000000`0149e4e8 000007fe`fde3b9c3 kernel32!CreateProcessW
    00000000`0149e4f0 000007fe`fde3b72b SHELL32!_SHCreateProcess+0x32b
    0:001> g

    C:\Temp>echo %errorlevel%
    42

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 23:21:38 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 29 Jan 2016 04:21:38 +0000
Subject: [issue26234] The typing module includes 're' and 'io' in __all__
In-Reply-To: <1454026053.81.0.969583520836.issue26234@psf.upfronthosting.co.za>
Message-ID: <1454041298.45.0.0135417713955.issue26234@psf.upfronthosting.co.za>


Martin Panter added the comment:

My concern with pydoc is that currently when you do ?python -m pydoc typing? you get stuff like

CLASSES
    builtins.object
        typing.io
        typing.re
        [. . .]
    
    io = class typing.io(builtins.object)
     |  Wrapper namespace for IO generic classes.
     |  [. . .]
    
    re = class typing.re(builtins.object)
     |  Wrapper namespace for re type aliases.
     |  [. . .]

If I comment out these two entries from typing.__all__, there is no longer any mention of ?re? or ?io? in the pydoc output.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 00:00:08 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jan 2016 05:00:08 +0000
Subject: [issue26173] test_ssl.bad_cert_test() exception handling
In-Reply-To: <1453373183.85.0.754157160572.issue26173@psf.upfronthosting.co.za>
Message-ID: <20160129045831.16748.26527@psf.io>


Roundup Robot added the comment:

New changeset c75ae81b5058 by Martin Panter in branch '3.5':
Issue #26173: Fix test_ssl confusion with non-existing cert and wrongcert.pem
https://hg.python.org/cpython/rev/c75ae81b5058

New changeset 284b3de802b7 by Martin Panter in branch 'default':
Issue #26173: Merge wrongcert test from 3.5
https://hg.python.org/cpython/rev/284b3de802b7

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 00:07:30 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 29 Jan 2016 05:07:30 +0000
Subject: [issue26234] The typing module includes 're' and 'io' in __all__
In-Reply-To: <1454041298.45.0.0135417713955.issue26234@psf.upfronthosting.co.za>
Message-ID: 


Guido van Rossum added the comment:

I'm no expert on pydoc, but I don't think it should be a reason to
keep these two names in __all__; __all__ is there primarily to guide
"import *" and it's clear that "from typing import *" overwriting a
previously-imported re or io module is a bad idea.

But maybe pydoc just needs to learn to look for another variable in
addition to __all__? Maybe __alldoc__?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 00:11:39 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 29 Jan 2016 05:11:39 +0000
Subject: [issue26206] test_socket.testRecvmsgPeek() timeout on "AMD64 Debian
 root 3.x" buildbot
In-Reply-To: <1453813330.04.0.627005992155.issue26206@psf.upfronthosting.co.za>
Message-ID: <1454044299.35.0.0449963793625.issue26206@psf.upfronthosting.co.za>


Martin Panter added the comment:

The problem has apparently been fixed at the buildbot end

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 02:51:18 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 29 Jan 2016 07:51:18 +0000
Subject: [issue12912] xmlrpclib.__version__ not bumped with updates
In-Reply-To: <1315316505.08.0.403062949645.issue12912@psf.upfronthosting.co.za>
Message-ID: <1454053878.9.0.336530548355.issue12912@psf.upfronthosting.co.za>


Berker Peksag added the comment:

xmlrpc.client.__version__ is used by Transport.user_agent and it has been changed to use sys.version[:3] in 197d703fb23e. It's too late for 2.7 so I think this can be closed now.

Thanks for the report, Rob!

----------
nosy: +berker.peksag
resolution:  -> out of date
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 03:25:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Jan 2016 08:25:52 +0000
Subject: [issue25698] The copy_reg module becomes unexpectedly empty in
 test_cpickle
In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za>
Message-ID: <1454055952.56.0.23432680191.issue25698@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

One solution is to skip tests caused deep recursion.

The better solution would be to fix import machinery to not produce empty modules.

----------
keywords: +patch
Added file: http://bugs.python.org/file41748/issue25698_skip_tests.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 04:04:28 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 29 Jan 2016 09:04:28 +0000
Subject: [issue26173] test_ssl.bad_cert_test() exception handling
In-Reply-To: <1453373183.85.0.754157160572.issue26173@psf.upfronthosting.co.za>
Message-ID: <1454058268.81.0.231674492009.issue26173@psf.upfronthosting.co.za>


Martin Panter added the comment:

I was mistaken about what test_wrong_cert() is doing. It tells the _server_ to check the _client?s_ certificate (the opposite way around from HTTPS for example). Now I understand this, I see it is fine for the client to raise ECONNRESET if the server rejected its certificate.

In separate-test.patch, I decoupled test_wrong_cert() from the other three bad_cert_test() tests because they are testing different stuff. Changes to test_wrong_cert():

* Fix ResourceWarning in my previous change by closing the SSL socket
* Catch socket.error rather than OSError to fix the buildbot failures in 2.7 (The change does nothing in Python 3 because they are aliases.)
* Make test_wrong_cert() stricter by only allowing ECONNRESET or SSLError

Changes to the other three tests:

* Moved them to BasicSocketTests and do not run a server
* Only accept SSLError from wrap_socket(), drop OSError handling and connect() call

----------
Added file: http://bugs.python.org/file41749/separate-test.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 04:09:34 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Jan 2016 09:09:34 +0000
Subject: [issue25698] The copy_reg module becomes unexpectedly empty in
 test_cpickle
In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za>
Message-ID: <1454058574.45.0.517384820051.issue25698@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that makes import machinery to not left empty module in case of recursion error. I prefer this solution.

----------
Added file: http://bugs.python.org/file41750/issue25698_fix_remove_module.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 04:10:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Jan 2016 09:10:19 +0000
Subject: [issue25698] The copy_reg module becomes unexpectedly empty in
 test_cpickle
In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za>
Message-ID: <1454058619.22.0.137690464968.issue25698@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
priority: normal -> high
stage:  -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 04:40:26 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 29 Jan 2016 09:40:26 +0000
Subject: [issue26237] UnboundLocalError error while handling exception
Message-ID: <1454060426.66.0.838628390922.issue26237@psf.upfronthosting.co.za>


New submission from ???? ?????????:

This works right in Python 2.7, but fails in python3:

UnboundLocalError: local variable 'e' referenced before assignment


def test():
    try:
        raise Exception('a')
    except Exception as e:
        pass
    else:
        return
    print(e)

test()

----------
messages: 259201
nosy: mmarkk
priority: normal
severity: normal
status: open
title: UnboundLocalError error while handling exception
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 04:42:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Jan 2016 09:42:33 +0000
Subject: [issue26237] UnboundLocalError error while handling exception
In-Reply-To: <1454060426.66.0.838628390922.issue26237@psf.upfronthosting.co.za>
Message-ID: <1454060553.53.0.719269354369.issue26237@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Yes, it's a deliberate change in the Python language. You have to copy "e" to a different variable:

err = None
try:
  ...
except Exception as exc:
  err = exc
print(err)

----------
nosy: +haypo
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 05:06:08 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 29 Jan 2016 10:06:08 +0000
Subject: [issue26125] Incorrect error message in the module
 asyncio.selector_events.
In-Reply-To: <1452865979.87.0.840611229209.issue26125@psf.upfronthosting.co.za>
Message-ID: <1454061968.66.0.567960718201.issue26125@psf.upfronthosting.co.za>


Berker Peksag added the comment:

https://github.com/python/asyncio/pull/313 has been merged. Do we need to commit this patch to the CPython repo or will it be merged with the next sync? (e.g. f4fe55dd5659)

----------
nosy: +berker.peksag

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 06:08:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Jan 2016 11:08:51 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
In-Reply-To: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>
Message-ID: <1454065731.08.0.951670548261.issue26168@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Current code already decref obj if creating previous argument is failed. But a leak if PyTuple_New() fails is possible.

Proposed patch fixes this leak and adds a test for the case when creating previous argument is failed. Testing the failure of PyTuple_New() is problematic.

----------
assignee:  -> serhiy.storchaka
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file41751/pybuildvalue_leak.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 07:00:40 2016
From: report at bugs.python.org (=?utf-8?b?5bGx5pys5rOw5a6H?=)
Date: Fri, 29 Jan 2016 12:00:40 +0000
Subject: [issue23548] TypeError in event loop finalizer, new in Python 3.4.3
In-Reply-To: <1425139981.48.0.523334940185.issue23548@psf.upfronthosting.co.za>
Message-ID: <1454068840.63.0.706110221925.issue23548@psf.upfronthosting.co.za>


???? added the comment:

> I may workaround the bug during Python finalization if more users report this issue.

+1 in my project:
https://github.com/cybozu/passh/issues/1

Anyway, I'd like to express my gratitude to asyncio.

----------
nosy: +????

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 07:08:51 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Fri, 29 Jan 2016 12:08:51 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1454069331.14.0.690103010061.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Here's a new version of the zf.open() patch following Martin's review (thanks Martin!).

I agree that it feels a bit awkward having two completely different actions for zf.open(), but it is a familiar interface, and since the mode parameter is already there, it requires a minimum of new public API. But I'm happy to add a new method like open_write() or write_handle() if people prefer that.

The comments on the other patch are minimal, I'll put a new version of that together as well.

----------
Added file: http://bugs.python.org/file41752/zipfile-open-w3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 07:14:21 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Fri, 29 Jan 2016 12:14:21 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1454069661.01.0.558359385386.issue26039@psf.upfronthosting.co.za>


Changes by Thomas Kluyver :


Added file: http://bugs.python.org/file41753/zipinfo-from-file3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 07:35:46 2016
From: report at bugs.python.org (lirenke)
Date: Fri, 29 Jan 2016 12:35:46 +0000
Subject: [issue26238] httplib use wrong hostname in https request with SNI
 support
Message-ID: <1454070946.61.0.657909359351.issue26238@psf.upfronthosting.co.za>


New submission from lirenke:

httplib give openssl SNI extension message like IP:PORT string. 
the apache server would return 400 code if SNI/request ServerName mismatch.

In class HTTPSConnection, we hope call self._get_hostport() before give the value to server_hostname.

===
if self._tunnel_host:
	server_hostname = self._tunnel_host
else:
	server_hostname = self.host

self.sock = self._context.wrap_socket(self.sock,
									  server_hostname=server_hostname)

===

----------
components: Library (Lib)
messages: 259207
nosy: lvhancy
priority: normal
severity: normal
status: open
title: httplib use wrong hostname in https request with SNI support
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 08:25:45 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Fri, 29 Jan 2016 13:25:45 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1454073945.16.0.978167459703.issue26227@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

For future reference, Victor's patch does fix it, I was checking the wrong thing when testing.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 09:10:03 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Fri, 29 Jan 2016 14:10:03 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1454076603.54.0.0409682148227.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Thanks Serhiy for review comments.

----------
Added file: http://bugs.python.org/file41754/zipinfo-from-file4.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 09:34:33 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 29 Jan 2016 14:34:33 +0000
Subject: [issue26229] Make number serialization ES6/V8 compatible
In-Reply-To: <1453965911.58.0.319543725596.issue26229@psf.upfronthosting.co.za>
Message-ID: <1454078073.72.0.823173900888.issue26229@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Do you have a pointer to the spec which requires -333333333333333300000 vs. -3.333333333333333e+20, for example?

----------
nosy: +eric.smith

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 10:43:48 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 29 Jan 2016 15:43:48 +0000
Subject: [issue26125] Incorrect error message in the module
 asyncio.selector_events.
In-Reply-To: <1454061968.66.0.567960718201.issue26125@psf.upfronthosting.co.za>
Message-ID: 


Guido van Rossum added the comment:

Usually Yury or Victor takes care of this sooner or later. If you want
to you can keep this open as a release blocker with that as a task.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 11:01:15 2016
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 29 Jan 2016 16:01:15 +0000
Subject: [issue26180] multiprocessing.util._afterfork_registry leak in
 threaded environment
In-Reply-To: <1453476286.88.0.329468896089.issue26180@psf.upfronthosting.co.za>
Message-ID: <1454083275.61.0.466846159463.issue26180@psf.upfronthosting.co.za>


Changes by Nir Soffer :


----------
nosy: +nirs

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 11:07:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Jan 2016 16:07:49 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1454073945.16.0.978167459703.issue26227@psf.upfronthosting.co.za>
Message-ID: 


STINNER Victor added the comment:

He he, no problem. Thanks again for the bug report. I'm surprised that
nobody reported it before.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 11:16:30 2016
From: report at bugs.python.org (Torsten Landschoff)
Date: Fri, 29 Jan 2016 16:16:30 +0000
Subject: [issue1475692] replacing obj.__dict__ with a subclass of dict
Message-ID: <1454084190.38.0.567967446933.issue1475692@psf.upfronthosting.co.za>


Torsten Landschoff added the comment:

I just bumped into this issue because I was shown by a colleague that my implementation of immutable objects (by replacing __dict__ with an ImmutableDict that inherits from dict and blocks write accesses) is ineffective - ouch!

I'd expect that Python either rejects subclasses of dict for obj.__dict__ or actually implements accessing correctly. Especially since the enum module created the impression for me that replacing __dict__ is a viable approach (enum.py uses __prepare__ in the meta class to provide a different dict class for enum types, just found https://www.python.org/dev/peps/pep-3115/).

Interestingly the PEP 3115 example code notes the following:

# Note that we replace the classdict with a regular
# dict before passing it to the superclass, so that we
# don't continue to record member names after the class
# has been created.

----------
nosy: +torsten

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 11:31:16 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 29 Jan 2016 16:31:16 +0000
Subject: [issue26207] distutils msvccompiler fails due to mspdb140.dll error
 on debug builds
In-Reply-To: <1453813782.88.0.185045860262.issue26207@psf.upfronthosting.co.za>
Message-ID: <1454085076.41.0.18169949257.issue26207@psf.upfronthosting.co.za>


Changes by Steve Dower :


----------
title: test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot -> distutils msvccompiler fails due to mspdb140.dll error on debug builds

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 11:36:31 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 29 Jan 2016 16:36:31 +0000
Subject: [issue26155] 3.5.1 installer issue on Win 7 32 bit
In-Reply-To: <1453213607.65.0.0758375238655.issue26155@psf.upfronthosting.co.za>
Message-ID: <1454085391.42.0.694401228612.issue26155@psf.upfronthosting.co.za>


Steve Dower added the comment:

Looks like the log files were attached just fine.

>From a first glance, the logs don't show anything being installed into your documents folder.

Could you list the files you are seeing, where they are and where you believe they should be?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 12:13:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Jan 2016 17:13:35 +0000
Subject: [issue1475692] replacing obj.__dict__ with a subclass of dict
Message-ID: <1454087615.02.0.995765192408.issue1475692@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Python uses concrete class API (PyDict_GetItem and like) for resolving attributes. Using general mapping API would slow down attribute lookup in common case. This is performance critical part of Python and we should be very careful changing it.

On the other side, you still can have a benefit from using dict subclasses as __dict__. OrderedDict allows you to iterate dict in predefined order, and defaultdict allows you to create attributes with default values on demand (but __getattr__ is more universal method).

See also issue10977.

----------
nosy: +rhettinger, serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 12:14:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Jan 2016 17:14:48 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>
Message-ID: <1454087688.34.0.239123476418.issue19883@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 Jan 29 12:21:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Jan 2016 17:21:20 +0000
Subject: [issue26194] Undefined behavior for deque.insert() when len(d) ==
 maxlen
In-Reply-To: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>
Message-ID: <1454088080.14.0.0559288643085.issue26194@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

*All* reasons look reasonable.  May be discuss this on Python-Dev or ask BDFL?

>From my point it looks that correct implementation of the insertion is too complex and this feature should go only in development release (if any).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 12:45:15 2016
From: report at bugs.python.org (Julian Taylor)
Date: Fri, 29 Jan 2016 17:45:15 +0000
Subject: [issue23601] use small object allocator for dict key storage
In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za>
Message-ID: <1454089515.33.0.657079355537.issue23601@psf.upfronthosting.co.za>


Julian Taylor added the comment:

ping, this has been sitting for 4 years and two python releases. Its about time this stupidly simple thing gets merged.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 12:54:14 2016
From: report at bugs.python.org (Tim Peters)
Date: Fri, 29 Jan 2016 17:54:14 +0000
Subject: [issue23601] use small object allocator for dict key storage
In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za>
Message-ID: <1454090054.69.0.0544498932729.issue23601@psf.upfronthosting.co.za>


Tim Peters added the comment:

+1 from me.  Julian, you have the patience of a saint ;-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 15:02:38 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 29 Jan 2016 20:02:38 +0000
Subject: [issue26229] Make number serialization ES6/V8 compatible
In-Reply-To: <1453965911.58.0.319543725596.issue26229@psf.upfronthosting.co.za>
Message-ID: <1454097758.73.0.46750586259.issue26229@psf.upfronthosting.co.za>


Changes by Mark Dickinson :


----------
nosy: +mark.dickinson

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 15:32:11 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 29 Jan 2016 20:32:11 +0000
Subject: [issue26229] Make number serialization ES6/V8 compatible
In-Reply-To: <1453965911.58.0.319543725596.issue26229@psf.upfronthosting.co.za>
Message-ID: <1454099531.07.0.376997204695.issue26229@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Eric: I suspect he's talking about section 7.1.12.1 of the 6th edition of ECMA-262; a PDF can be found here: http://www.ecma-international.org/ecma-262/6.0/ECMA-262.pdf. Clause 6 applies to this particular example:

"""
If k <= n <= 21, return the String consisting of the code units of the k digits of the decimal representation of s (in order, with no leading zeroes), followed by n?k occurrences of the code unit 0x0030 (DIGIT ZERO).
"""

here 'k' is the number of significant digits in the shortest possible representation (i.e., the number of significant digits that Python's repr will use), and n is the "adjusted exponent" of the input (so k = 16 and n = 21 in this case, because 10**20 <= target_value < 10**21).

I'm not convinced of the importance / value of making Python's json implementation exactly correspond to that of Google's JS engine, though. For one thing, there's no spec: ECMA-262 isn't good enough, since (as noted in the spec), the least significant digit isn't necessarily defined by their requirements, so it's still perfectly possible for two JS implementations to both conform with the specification and still give different output strings.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 15:37:53 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 29 Jan 2016 20:37:53 +0000
Subject: [issue26229] Make number serialization ES6/V8 compatible
In-Reply-To: <1453965911.58.0.319543725596.issue26229@psf.upfronthosting.co.za>
Message-ID: <1454099873.91.0.902382927066.issue26229@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Here's the relevant part of the JCS document, from Appendix A of https://cyberphone.github.io/openkeystore/resources/docs/jcs.html#ECMAScript_Compatibility_Mode:

"""
Numbers *must* be expressed as specified by EMCAScript [ES6] using the improved serialization algorithm featured in Google's V8 JavaScript engine [V8]. That is, in the ECMAScript compatibility mode there are no requirements saving the textual value of numbers. This also means that the JCS Sample Signature in incompatible with the ECMAScript mode since it uses unnormalized numbers.
"""

I think exactly matching Google's implementation is an unreasonable requirement, and I don't see any evidence that JCS usage is widespread enough to warrant making changes to the JSON float output format.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 15:40:21 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Jan 2016 20:40:21 +0000
Subject: [issue26229] Make number serialization ES6/V8 compatible
In-Reply-To: <1453965911.58.0.319543725596.issue26229@psf.upfronthosting.co.za>
Message-ID: <1454100021.91.0.573404883171.issue26229@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

That said, someone interested in this should probably voice their concerns towards the JCS standardizers, as the restrictions it imposes on number serialization are clearly an impediment to implementing their protocol.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 16:40:30 2016
From: report at bugs.python.org (squidevil)
Date: Fri, 29 Jan 2016 21:40:30 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
In-Reply-To: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>
Message-ID: <1454103630.87.0.80573248278.issue26168@psf.upfronthosting.co.za>


squidevil added the comment:

It looks like this patch is against the "default" cpython (3.x) branch.  The 2.7 branch is missing the if(itemfailed) code in do_mktuple whose else clause was modified by the patch.

It looks like some of this needs to be backported to 2.7?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 17:00:48 2016
From: report at bugs.python.org (Jeremy Fergason)
Date: Fri, 29 Jan 2016 22:00:48 +0000
Subject: [issue26239] distutils link-objects is not normalized
Message-ID: <1454104848.79.0.657615243425.issue26239@psf.upfronthosting.co.za>


New submission from Jeremy Fergason:

When giving setup.cfg a link-objects argument build fails with an error message about cannot concatenate string with list.  

Need to add the following line to: Lib/distutils/command/build_ext.py

self.ensure_string_list('link_objects')

See patch here:

https://github.com/jdfergason/cpython/compare/master...jdfergason-distutils-fix?quick_pull=1

----------
components: Distutils
messages: 259223
nosy: dstufft, eric.araujo, jdfergason
priority: normal
severity: normal
status: open
title: distutils link-objects is not normalized
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 18:57:13 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 29 Jan 2016 23:57:13 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
In-Reply-To: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>
Message-ID: <1454111833.41.0.878498086836.issue26168@psf.upfronthosting.co.za>


Martin Panter added the comment:

Left a review.

Squidevil: You say if do_mkvalue() fails, the N object is not released. But looking at the code, I think it gets stored in the tuple, and then the tuple is released: . So the only leak I can see is if the tuple construction fails.

Serhiy?s patch fixes do_mktuple(), but I think the same problem would affect do_mkdict() and do_mklist() as well.

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 19:03:45 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Jan 2016 00:03:45 +0000
Subject: [issue26234] The typing module includes 're' and 'io' in __all__
In-Reply-To: <1454026053.81.0.969583520836.issue26234@psf.upfronthosting.co.za>
Message-ID: <1454112225.01.0.187284827274.issue26234@psf.upfronthosting.co.za>


Martin Panter added the comment:

The __alldoc__ is an interesting idea to think about. Anyway, I haven?t actually tried the typing module yet, so I will let you decide the best way forward.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 19:22:59 2016
From: report at bugs.python.org (squidevil)
Date: Sat, 30 Jan 2016 00:22:59 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
In-Reply-To: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>
Message-ID: <1454113379.6.0.709729174131.issue26168@psf.upfronthosting.co.za>


squidevil added the comment:

Martin Panter: You're right.  The DECREF on v when itemfailed will decref the N object and prevent the leak.  My original analysis was wrong on that count.

You're right, do_mklist and do_mkdict (in 2.7.11 at least) have similar problems, bailing after list or dict creation failure, without continuing to process the rest of the items.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 19:50:15 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Jan 2016 00:50:15 +0000
Subject: [issue26195] Windows frozen .exe multiprocessing.Queue access is
 denied exception
In-Reply-To: <1453690484.95.0.111987955887.issue26195@psf.upfronthosting.co.za>
Message-ID: <1454115015.93.0.228419771583.issue26195@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
nosy: +jnoller, sbt

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 20:12:03 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Jan 2016 01:12:03 +0000
Subject: [issue25934] ICC compiler: ICC treats denormal floating point numbers
 as 0.0
In-Reply-To: <1450911743.93.0.393041043786.issue25934@psf.upfronthosting.co.za>
Message-ID: <20160130011158.62662.62783@psf.io>


Roundup Robot added the comment:

New changeset 296fb7c10a7d by Zachary Ware in branch '2.7':
Issue #25934: Default to /fp:strict for ICC builds
https://hg.python.org/cpython/rev/296fb7c10a7d

New changeset 747b415e96c4 by Zachary Ware in branch '3.5':
Issue #25934: Default to /fp:strict for ICC builds
https://hg.python.org/cpython/rev/747b415e96c4

New changeset c080ef5989f7 by Zachary Ware in branch 'default':
Issue #25934: Merge with 3.5
https://hg.python.org/cpython/rev/c080ef5989f7

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 20:39:40 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Jan 2016 01:39:40 +0000
Subject: [issue26205] Inconsistency concerning nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1454117980.9.0.295620738317.issue26205@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Would 'three or more' be any clearer than 'at least three'?  They mean the same, but the first seems better to me in this context.

The real problem with this section are a) the use of Guido's first person 'I' and b) statements that were not changed when nested scope were added, but should have been.

"If a name is declared global, then all references and assignments go directly to the middle scope containing the module?s global names."

The global scope is no longer the middle scope.  Roscoe pointed at this.  With that removed, the sentence says that if a name is declared global, assignments go to global scope.  This would be more meaningful if prefixed by a revised version of the following, which is several paragraphs down.

"A special quirk of Python is that ? if no global statement is in effect ? assignments to names always go into the innermost scope."

The special quirk part should go; 'global' would now have to be 'global or nonlocal', but I now think the following, preceeding the revised 'global' sentence above, would be better.

"By default, assignments to names always go into the innermost, local, namespace."

In other words, I think the sentence Roscoe flagged is the least of the problems with this section.

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 20:48:22 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Jan 2016 01:48:22 +0000
Subject: [issue26209] TypeError in smtpd module with string arguments
In-Reply-To: <1453840478.59.0.371405366995.issue26209@psf.upfronthosting.co.za>
Message-ID: <1454118502.92.0.442742161055.issue26209@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am guessing that 25 is the default port.  Autoconversion of 'host' to ('host', 25) would be a new feature ('enhancement') that would have to wait for the next Python version (3.6 or later).  Is there any precedent for this in any other module?

Does 2.7 act the same as 3.5?  A doc improvement could go there also.

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 20:59:54 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Jan 2016 01:59:54 +0000
Subject: [issue26212] Python with ncurses6.0 will not load _curses module on
 Solaris 10
In-Reply-To: <1453851633.31.0.356555678785.issue26212@psf.upfronthosting.co.za>
Message-ID: <1454119194.46.0.695249752004.issue26212@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The tracker is not a help forum.  It is for patching CPython.  You might do better to ask for help in python-list or Stackoverflow or elsewhere to try to determine whether you need to do something different or if the problem is with Solaris or if indeed CPython needs to be patched somewhere.

----------
nosy: +jcea, terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 21:02:54 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Jan 2016 02:02:54 +0000
Subject: [issue26214] textwrap should minimize number of breaks in extra long
 words
In-Reply-To: <1453882121.55.0.184610339904.issue26214@psf.upfronthosting.co.za>
Message-ID: <1454119374.75.0.674835365558.issue26214@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
type: behavior -> enhancement
versions:  -Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 21:05:20 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Jan 2016 02:05:20 +0000
Subject: [issue26216] run runtktests.py error when test tkinter
In-Reply-To: <1453901780.17.0.263140202656.issue26216@psf.upfronthosting.co.za>
Message-ID: <1454119520.7.0.682756357864.issue26216@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 21:18:07 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Jan 2016 02:18:07 +0000
Subject: [issue26218] Set PrependPath default to true
In-Reply-To: <1453911006.83.0.905556840018.issue26218@psf.upfronthosting.co.za>
Message-ID: <1454120287.24.0.291749273981.issue26218@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Are you are referring to the option in the Windows installer to prepend the currently-being-installed Python directory (and the scripts directory) to the system PATH variable?  Is so, making this the default has been proposed and rejected before.  Some developers think it a bad idea. In any case, the current choice is not a bug.

----------
components: +Windows
nosy: +paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
type: behavior -> enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 21:27:45 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Jan 2016 02:27:45 +0000
Subject: [issue26222] Missing code in linux_distribution python 2.7.11
In-Reply-To: <1453916728.01.0.709818070841.issue26222@psf.upfronthosting.co.za>
Message-ID: <1454120865.67.0.263580855693.issue26222@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

>From the last two comments, it looks like this should be closed as 'not a bug'.

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 21:42:42 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Jan 2016 02:42:42 +0000
Subject: [issue26235] argparse docs: Positional * argument in mutually
 exclusive group requires a default parameter
In-Reply-To: <1454026598.04.0.15054739834.issue26235@psf.upfronthosting.co.za>
Message-ID: <1454121762.1.0.176414472168.issue26235@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
nosy: +bethard

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 22:18:08 2016
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Sat, 30 Jan 2016 03:18:08 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <1454123888.05.0.866165004563.issue25924@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

I've created a Mac OS 10.4 virtual machine and reproduced the getaddrinfo concurrency bug there using the attached h_resolv.c. The man page on that OS version indeed includes the "not thread-safe" warning.

The same test passes on my Mac OS 10.10 system.

I am convinced that getaddrinfo is thread-safe on Mac OS 10.5+, and I'm attaching a patch to disable the lock on these systems.

----------
keywords: +patch
Added file: http://bugs.python.org/file41755/25924-getaddrinfo-is-thread-safe.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 22:30:27 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 30 Jan 2016 03:30:27 +0000
Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe
In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za>
Message-ID: <1454124627.51.0.901673160643.issue25924@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Thanks for the thorough work! Hopefully we can apply this fix to 3.5, 3.6 and even 2.7.

----------
nosy: +gvanrossum

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 22:52:38 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 30 Jan 2016 03:52:38 +0000
Subject: [issue26218] Set PrependPath default to true
In-Reply-To: <1453911006.83.0.905556840018.issue26218@psf.upfronthosting.co.za>
Message-ID: <1454125958.97.0.675064589446.issue26218@psf.upfronthosting.co.za>


Steve Dower added the comment:

Sorry, not happening.

There's a very prominent checkbox on the first page of the installer, which was added under protest.

I'd suggest learning the py.exe launcher instead, which does not suffer from any of the issues that are caused by modifying the global PATH variable.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 00:06:40 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Jan 2016 05:06:40 +0000
Subject: [issue23601] use small object allocator for dict key storage
In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za>
Message-ID: <1454130400.0.0.283183862685.issue23601@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

If there are no objects, I'll apply the patch tomorrow.

----------
assignee:  -> rhettinger
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 00:14:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Jan 2016 05:14:19 +0000
Subject: [issue26225] New misleading wording in execution model documenation
In-Reply-To: <1453939288.53.0.211010759952.issue26225@psf.upfronthosting.co.za>
Message-ID: <1454130859.83.0.483569917515.issue26225@psf.upfronthosting.co.za>


Martin Panter added the comment:

Calling exec() with only one argument is equivalent to exec(..., globals(), locals()). It does not create a new scope for names. So an equivalent of your three-level example is more like

>>> i = 'global'
>>> def f():
...     i = 'nonlocal'
...     class_locals = dict()
...     exec("print(i)\ni = 'local'\nprint(i)\n", globals(), class_locals)
... 
>>> f()
global
local

If exec() worked like a function rather than a class, the first print(i) would trigger an UnboundLocalError instead:

>>> i = 'global'
>>> def f():
...     i = 'nonlocal'
...     def g():
...         print(i)
...         i = 'local'
...     g()
... 
>>> f()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 6, in f
  File "", line 4, in g
UnboundLocalError: local variable 'i' referenced before assignment

In your first exec() example, i='nonlocal' is passed to exec() via the default locals parameter, and the exec() uses that value rather than deferring to its globals. To be a free variable, ?i? has to be used but not defined. Even if you dropped the ?i = 'local' ? assignment, it is still defined via the implicit locals parameter.

Your proposal for ?Interaction with dynamic features? sounds reasonable.

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 00:18:03 2016
From: report at bugs.python.org (Antony Lee)
Date: Sat, 30 Jan 2016 05:18:03 +0000
Subject: [issue26240] Docstring of the subprocess module should be cleaned up
Message-ID: <1454131083.41.0.870668221205.issue26240@psf.upfronthosting.co.za>


New submission from Antony Lee:

subprocess.__doc__ currently contains copies for the docstrings of a bunch of functions in the module (... but not subprocess.run).  The docs for the Popen class should be moved into that class' docstring.  The module's docstring also mentions the list2cmdline "method" (actually a function, and the qualifier "method"/"function" is missing the second time this function is mentioned ("The list2cmdline is designed ...")), but that function doesn't appear in `__all__` and thus not in the official HTML docs (yes, I know pydoc subprocess.list2cmdline works).

----------
assignee: docs at python
components: Documentation
messages: 259238
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Docstring of the subprocess module should be cleaned up
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 01:18:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Jan 2016 06:18:54 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
 mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1454134734.98.0.0843479059271.issue4806@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think this is ready to push for Python 3. Python 2 might need an extra Py_TPFLAGS_HAVE_ITER check, perhaps reusing some code from the Issue 5218 patch.

----------
stage: patch review -> commit review
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 01:47:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Jan 2016 06:47:41 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
 mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <20160130064737.87371.35038@psf.io>


Roundup Robot added the comment:

New changeset 1a8dc350962b by Martin Panter in branch '3.5':
Issue #4806: Avoid masking original TypeError in call with * unpacking
https://hg.python.org/cpython/rev/1a8dc350962b

New changeset 1261f5f6fc95 by Martin Panter in branch 'default':
Issue #4806: Merge * unpacking fix from 3.5
https://hg.python.org/cpython/rev/1261f5f6fc95

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 02:02:34 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Jan 2016 07:02:34 +0000
Subject: [issue26240] Docstring of the subprocess module should be cleaned up
In-Reply-To: <1454131083.41.0.870668221205.issue26240@psf.upfronthosting.co.za>
Message-ID: <1454137354.88.0.550610978725.issue26240@psf.upfronthosting.co.za>


Martin Panter added the comment:

IMO the doc strings should be reduced down so that it is a concise summary, and divided or merged into doc strings of each class, method, function. Less important details should be moved to the main RST documentation (if they aren?t already there).

Regarding list2cmdline(), see the comment next to __all__ in the source code, and Issue 11827. BTW modifying __all__ would not automatically affect what is written in the RST files, which is where the ?official? HTML docs come from :)

----------
nosy: +martin.panter
stage:  -> needs patch
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 02:39:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Jan 2016 07:39:25 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
In-Reply-To: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>
Message-ID: <1454139565.76.0.737593625317.issue26168@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Rather rare reference leak is not the worst bug here.

Following example

    const char *s = ...;
    PyObject *b = PyBytes_New(...);
    return PyBuildValue("(Ns)s", b, s, PyBytes_AS_STRING(b));

works if s is correct UTF-8 encoded string. But if it is not correct UTF-8 encoded string, the first "s" is failed and the inner tuple is deallocated together with the borrowed reference to b. The second "s" then reads freed memory.

----------
type: resource usage -> crash

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 02:56:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Jan 2016 07:56:39 +0000
Subject: [issue26216] run runtktests.py error when test tkinter
In-Reply-To: <1453901780.17.0.263140202656.issue26216@psf.upfronthosting.co.za>
Message-ID: <1454140599.94.0.721643956804.issue26216@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is rather import machinery issue. The simple reproducer:

$ ./python -c "import importlib; importlib.import_module('.bar', 'foo')"
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/serhiy/py/cpython/Lib/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 981, in _gcd_import
  File "", line 931, in _sanity_check
SystemError: Parent module 'foo' not loaded, cannot perform relative import

SystemError means programming error and shouldn't be triggered by user code.

----------
nosy: +brett.cannon, eric.snow, ncoghlan

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 04:22:04 2016
From: report at bugs.python.org (Anders Rundgren)
Date: Sat, 30 Jan 2016 09:22:04 +0000
Subject: [issue26241] repr() and str() are identical for floats in 3.5
Message-ID: <1454145724.12.0.226148276857.issue26241@psf.upfronthosting.co.za>


New submission from Anders Rundgren:

According to the documentation repr() and str() are different when it comes to number formatting.  A test with a 100 million random and selected IEEE 64-bit values returned no differences

----------
components: Interpreter Core
messages: 259244
nosy: anders.rundgren.net at gmail.com
priority: normal
severity: normal
status: open
title: repr() and str() are identical for floats in 3.5
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 04:29:14 2016
From: report at bugs.python.org (Anders Rundgren)
Date: Sat, 30 Jan 2016 09:29:14 +0000
Subject: [issue26229] Make number serialization ES6/V8 compatible
In-Reply-To: <1453965911.58.0.319543725596.issue26229@psf.upfronthosting.co.za>
Message-ID: <1454146154.32.0.892507059108.issue26229@psf.upfronthosting.co.za>


Anders Rundgren added the comment:

As I said, the problem is close to fixed in 3.5.

You should not consider the JCS specification as the [sole] target but the ability to creating a normalized JSON object which has many uses including calculating a hash of such objects.

##################################################################
# Convert a Python double/float into an ES6/V8 compatible string #
##################################################################
def convert2Es6Format(value):
# Convert double/float to str using the native Python formatter
    pyDouble = str(value)
    pySign = ''
    if pyDouble.find('-') == 0:
#
#     Save sign separately, it doesn't have any role in the rest
#
        pySign = '-'
        pyDouble = pyDouble[1:]
    pyExpStr = ''
    pyExpVal = 0
    q = pyDouble.find('e')
    if q > 0:
#
# Grab the exponent and remove it from the number
#
        pyExpStr = pyDouble[q:]
        if pyExpStr[2:3] == '0':
#
# Supress leading zero on exponents
#
            pyExpStr = pyExpStr[0:2] + pyExpStr[3:]
        pyDouble = pyDouble[0:q]
        pyExpVal = int(pyExpStr[1:])
#
# Split number in pyFirst + pyDot + pyLast
#
    pyFirst = pyDouble
    pyDot = ''
    pyLast = ''
    q = pyDouble.find('.')
    if q > 0:
        pyDot = '.'
        pyFirst = pyDouble[0:q]
        pyLast = pyDouble[q + 1:]
#
# Now the string is split into: pySign + pyFirst + pyDot + pyLast + pyExpStr
#
    if pyLast == '0':
#
# Always remove trailing .0
#
        pyDot = ''
        pyLast = ''
    if pyExpVal > 0 and pyExpVal < 21:
#
# Integers are shown as is with up to 21 digits
#
        pyFirst += pyLast
        pyLast = ''
        pyDot = ''
        pyExpStr = ''
        q = pyExpVal - len(pyFirst)
        while q >= 0:
            q -= 1;
            pyFirst += '0'
    elif pyExpVal < 0 and pyExpVal > -7:
#
# Small numbers are shown as 0.etc with e-6 as lower limit
#
        pyLast = pyFirst + pyLast
        pyFirst = '0'
        pyDot = '.'
        pyExpStr = ''
        q = pyExpVal
        while q < -1:
            q += 1;
            pyLast = '0' + pyLast
#
# The resulting sub-strings are concatenated
#
    return pySign + pyFirst + pyDot + pyLast + pyExpStr

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 04:33:35 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 30 Jan 2016 09:33:35 +0000
Subject: [issue26241] repr() and str() are identical for floats in 3.5
In-Reply-To: <1454145724.12.0.226148276857.issue26241@psf.upfronthosting.co.za>
Message-ID: <1454146415.84.0.584448062576.issue26241@psf.upfronthosting.co.za>


SilentGhost added the comment:

Would you mind linking to the relevant part of documentation?

----------
nosy: +SilentGhost

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 04:43:12 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Jan 2016 09:43:12 +0000
Subject: [issue26241] repr() and str() are identical for floats in 3.5
In-Reply-To: <1454145724.12.0.226148276857.issue26241@psf.upfronthosting.co.za>
Message-ID: <1454146992.27.0.512758296312.issue26241@psf.upfronthosting.co.za>


Martin Panter added the comment:

This discrepancy was supposed to be eliminated in 3.2; see Issue 9337. So assuming you are looking at the right version, it is the documentation that is at fault.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python, martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 04:53:28 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 30 Jan 2016 09:53:28 +0000
Subject: [issue26222] Missing code in linux_distribution python 2.7.11
In-Reply-To: <1453916728.01.0.709818070841.issue26222@psf.upfronthosting.co.za>
Message-ID: <1454147608.14.0.552646236946.issue26222@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 04:58:55 2016
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 30 Jan 2016 09:58:55 +0000
Subject: [issue26241] repr() and str() are identical for floats in 3.5
In-Reply-To: <1454145724.12.0.226148276857.issue26241@psf.upfronthosting.co.za>
Message-ID: <1454147935.53.0.495553783626.issue26241@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> A test with a 100 million random and selected IEEE 64-bit values 
> returned no differences

The float type's tp_str and tp_repr both call float_repr in Objects/floatobject.c. See the 3.5.1 PyFloat_Type definition [1].

Perhaps you were reading something in reference to Python 2, which has separate float_str and float_repr functions. See the 2.7.11 PyFloat_Type definition [2] and the header file where PyFloat_STR_PRECISION is defined to be 12 digits [3].

[1]: https://hg.python.org/cpython/file/v3.5.1/Objects/floatobject.c#l1839
[2]: https://hg.python.org/cpython/file/v2.7.11/Objects/floatobject.c#l2118
[3]: https://hg.python.org/cpython/file/v2.7.11/Include/floatobject.h#l24

----------
nosy: +eryksun

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 05:19:32 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 30 Jan 2016 10:19:32 +0000
Subject: [issue26241] repr() and str() are identical for floats in 3.5
In-Reply-To: <1454145724.12.0.226148276857.issue26241@psf.upfronthosting.co.za>
Message-ID: <1454149172.44.0.0116263086191.issue26241@psf.upfronthosting.co.za>


Changes by Mark Dickinson :


----------
nosy: +mark.dickinson

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 05:31:52 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 30 Jan 2016 10:31:52 +0000
Subject: [issue26241] repr() and str() are identical for floats in 3.5
In-Reply-To: <1454145724.12.0.226148276857.issue26241@psf.upfronthosting.co.za>
Message-ID: <1454149912.97.0.422988153887.issue26241@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Closing: as Martin pointed out, the behaviour is intentional, and without a reference to a particular part of the documentation this issue isn't useful. (Anders: if you find a part of the 3.5 documentation that does state that str and repr are different for floats, please feel free to re-open and link to that section of the documentation so that it can be fixed.)

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 06:03:30 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Jan 2016 11:03:30 +0000
Subject: [issue26216] run runtktests.py error when test tkinter
In-Reply-To: <1453901780.17.0.263140202656.issue26216@psf.upfronthosting.co.za>
Message-ID: <1454151810.08.0.437328475467.issue26216@psf.upfronthosting.co.za>


Martin Panter added the comment:

According to Issue 18018, the SystemError is changed to ImportError in 3.6, and in Python 2 (or before 3.3) it raised ValueError.

To me, the more important question is: is running runtktests.py as a file meant to be supported, or should it be run as python -m tkinter.test.runtktests?

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 06:21:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Jan 2016 11:21:46 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
 mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1454152906.75.0.593186961936.issue4806@psf.upfronthosting.co.za>


Martin Panter added the comment:

In Python 2, the old-style ?instance? objects are making it hard to fix this like in Python 3. And completely removing the custom error message seems a bit drastic for 2.7.

Instead, I propose to just check for a generator type after the TypeError is caught, and don?t bother checking for other kinds of iterables and sequences.

----------
stage: commit review -> patch review
Added file: http://bugs.python.org/file41756/check-generator-py2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 06:23:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Jan 2016 11:23:40 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
In-Reply-To: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>
Message-ID: <1454153020.0.0.629955803415.issue26168@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Previous attempt to fix reference leaks was in issue984722.

Proposed patch uses different approach. It correctly fixes reference leaks after error in processing dict items (like "{()s(())N"), fixes leaksafter memory errors on creating tuple, list or dict, fixes issue20024 for lists and dicts, fixes use-after-free issue described in msg259242.

But the patch has a disadvantage in comparison with current code. If user converter ("O&") accepts Python objects and steal its reference (as "N"), this reference will be leaked. This is a price for avoiding potential use-after-free issues. Current stdlib code doesn't use converters that steal Python object reference. May be we should document this limitation.

----------
nosy: +mwh, rhettinger, shredwheat
Added file: http://bugs.python.org/file41757/pybuildvalue_leak2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 06:25:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Jan 2016 11:25:58 +0000
Subject: [issue20024] Py_BuildValue() can call Python code with an exception
 set
In-Reply-To: <1387451611.0.0.792673049242.issue20024@psf.upfronthosting.co.za>
Message-ID: <1454153158.92.0.708272391863.issue20024@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Committed patch fixed the issue only for tuples, but not for lists or dicts. See more general patch in issue26168.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 06:36:59 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Jan 2016 11:36:59 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
In-Reply-To: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>
Message-ID: <1454153819.07.0.523529399983.issue26168@psf.upfronthosting.co.za>


Martin Panter added the comment:

I was going to suggest just documenting your use-after-free case as a limitation of the N format. I doubt there is much demand to give away a borrowed reference with N _and_ rely on that borrowed reference staying alive for other parameters. It seems a lot of churn just to avoid a theoretical problem.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 07:16:39 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Sat, 30 Jan 2016 12:16:39 +0000
Subject: [issue26185] zipfile.ZipInfo slots can raise unexpected AttributeError
In-Reply-To: <1453545713.56.0.930101536202.issue26185@psf.upfronthosting.co.za>
Message-ID: <1454156199.71.0.863017073051.issue26185@psf.upfronthosting.co.za>


Changes by Thomas Kluyver :


----------
nosy: +takluyver

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 07:18:39 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Sat, 30 Jan 2016 12:18:39 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1454156319.41.0.460846902984.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Updated version of the ZipInfo.from_file() patch attached.

----------
Added file: http://bugs.python.org/file41758/zipinfo-from-file5.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 09:23:19 2016
From: report at bugs.python.org (Anders Rundgren)
Date: Sat, 30 Jan 2016 14:23:19 +0000
Subject: [issue26241] repr() and str() are identical for floats in 3.5
In-Reply-To: <1454145724.12.0.226148276857.issue26241@psf.upfronthosting.co.za>
Message-ID: <1454163799.98.0.523943905762.issue26241@psf.upfronthosting.co.za>


Anders Rundgren added the comment:

Apparently the docs have changed since 2.7:
https://docs.python.org/3.5/tutorial/floatingpoint.html

However, the documentation still "sort of" mentions repr() as the most accurate form which isn't entirely correct since it nowadays is identical to str() for floats.

No big deal, I just thought I was doing something wrong :-)

related: http://bugs.python.org/issue26229

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 10:23:32 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Sat, 30 Jan 2016 15:23:32 +0000
Subject: [issue1475692] replacing obj.__dict__ with a subclass of dict
Message-ID: <1454167412.27.0.559101422091.issue1475692@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Just FYI, if you're only trying to make immutable objects, that's what subclassing tuple with properties and __slots__ = () is for (collections.namedtuple does exactly this, building the Python declaration as a string and then eval-ing it to produce a tuple subclass with named property accessors). The only negative is that it still acts like a sequence, but usually that's not a big problem.

----------
nosy: +josh.r

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 10:49:42 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Sat, 30 Jan 2016 15:49:42 +0000
Subject: [issue26039] More flexibility in zipfile interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1454168982.83.0.902433861636.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Thanks Martin for more review; updated open-to-write patch attached.

----------
Added file: http://bugs.python.org/file41759/zipfile-open-w4.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 10:51:24 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Jan 2016 15:51:24 +0000
Subject: [issue23076] list(pathlib.Path().glob("")) fails with IndexError
In-Reply-To: <1418860780.4.0.558535328721.issue23076@psf.upfronthosting.co.za>
Message-ID: <20160130155121.30752.25139@psf.io>


Roundup Robot added the comment:

New changeset 35bf4f9e68f3 by Berker Peksag in branch '3.5':
Issue #23076: Path.glob() now raises a ValueError if it's called with an
https://hg.python.org/cpython/rev/35bf4f9e68f3

New changeset 0a6290195f7c by Berker Peksag in branch 'default':
Issue #23076: Path.glob() now raises a ValueError if it's called with an
https://hg.python.org/cpython/rev/0a6290195f7c

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 11:03:15 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 30 Jan 2016 16:03:15 +0000
Subject: [issue23076] list(pathlib.Path().glob("")) fails with IndexError
In-Reply-To: <1418860780.4.0.558535328721.issue23076@psf.upfronthosting.co.za>
Message-ID: <1454169795.64.0.0557771165776.issue23076@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Thomas!

> Though I've been reading the developer guide, I'm a bit unfamiliar with the process here so I'm not totally sure I'm doing this right.

You did everything right :) I just tweaked the test a bit.

> I created the patch relative to the current default branch (even though the discussion here seems to indicate it should maybe be applied going back a few versions).

Backporting a patch is (most of the time) the core developer's responsibility. However, if the patch is going to be very different in maintenance branches (let's say 2.7 for example), it would be really helpful to attach a separate patch for 2.7.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior
versions:  -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 12:19:35 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 30 Jan 2016 17:19:35 +0000
Subject: [issue26209] TypeError in smtpd module with string arguments
In-Reply-To: <1453840478.59.0.371405366995.issue26209@psf.upfronthosting.co.za>
Message-ID: <1454174375.14.0.324756385558.issue26209@psf.upfronthosting.co.za>


Berker Peksag added the comment:

There is a strong change that smtpd is going to be deprecated in Python 3.6. See issue 25008 for details.

+1 for improving documentation.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
keywords: +easy
nosy: +berker.peksag, docs at python
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 12:25:23 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 30 Jan 2016 17:25:23 +0000
Subject: [issue24905] Allow incremental I/O to blobs in sqlite3
In-Reply-To: <1440144321.97.0.0781853247945.issue24905@psf.upfronthosting.co.za>
Message-ID: <1454174723.51.0.597503909334.issue24905@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

I opened a pull request for blob support in the pysqlite github repository:
https://github.com/ghaering/pysqlite/pull/93

I will do the needed changes for python3 and will post a patch soon.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 12:26:28 2016
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 30 Jan 2016 17:26:28 +0000
Subject: [issue26242] reST formatting error in Doc/library/importlib.rst
Message-ID: <1454174788.27.0.0600197935954.issue26242@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

https://hg.python.org/cpython/file/default/Doc/library/importlib.rst#l1124

the spacing is wrong, it should be:

.. versionchanged:: 3.5

----------
assignee: docs at python
components: Documentation
messages: 259263
nosy: alex, docs at python, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: reST formatting error in Doc/library/importlib.rst
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 12:30:09 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Jan 2016 17:30:09 +0000
Subject: [issue26242] reST formatting error in Doc/library/importlib.rst
In-Reply-To: <1454174788.27.0.0600197935954.issue26242@psf.upfronthosting.co.za>
Message-ID: <20160130173006.24931.87118@psf.io>


Roundup Robot added the comment:

New changeset 9a31895a1c9d by Berker Peksag in branch '3.5':
Issue #26242: Fix another one in importlib.rst
https://hg.python.org/cpython/rev/9a31895a1c9d

New changeset 5452e4b5c007 by Berker Peksag in branch 'default':
Issue #26242: Fix another one in importlib.rst
https://hg.python.org/cpython/rev/5452e4b5c007

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 12:32:39 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 30 Jan 2016 17:32:39 +0000
Subject: [issue26242] reST formatting error in Doc/library/importlib.rst
In-Reply-To: <1454174788.27.0.0600197935954.issue26242@psf.upfronthosting.co.za>
Message-ID: <1454175159.39.0.972352836185.issue26242@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I just fixed a similar one in 23cc4b894caf :) Thanks!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 13:41:08 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 30 Jan 2016 18:41:08 +0000
Subject: [issue26243] zlib.compress level as keyword argument
Message-ID: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za>


New submission from Aviv Palivoda:

Currently zlib.compress allow only positional arguments. For code readability reasons i think that we should allow the level argument to be keyword argument. Now when someone uses zlib.compress he will be able to do zlib.compess(some_data, level=7) instead of zlib.compress(some_data, 7).

There is a patch included with the change.

----------
components: Extension Modules
files: zlib-compress-level-keyword.patch
keywords: patch
messages: 259266
nosy: nadeem.vawda, palaviv, twouters
priority: normal
severity: normal
status: open
title: zlib.compress level as keyword argument
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file41760/zlib-compress-level-keyword.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 13:48:48 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 30 Jan 2016 18:48:48 +0000
Subject: [issue26244] zlib.compressobj level default value documentation
Message-ID: <1454179728.88.0.137425597988.issue26244@psf.upfronthosting.co.za>


New submission from Aviv Palivoda:

In the zlib.compressobj documentation the default value of the compress level is -1 while it is actually 6.

patch is included

----------
assignee: docs at python
components: Documentation, Extension Modules
files: zlib-compressobj-level-doc.patch
keywords: patch
messages: 259267
nosy: docs at python, nadeem.vawda, palaviv, twouters
priority: normal
severity: normal
status: open
title: zlib.compressobj level default value documentation
versions: Python 3.6
Added file: http://bugs.python.org/file41761/zlib-compressobj-level-doc.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 15:39:39 2016
From: report at bugs.python.org (Niv Ben-David)
Date: Sat, 30 Jan 2016 20:39:39 +0000
Subject: [issue25690] Replacement for unittest.mock.mock_open
In-Reply-To: <1448122983.8.0.049241542179.issue25690@psf.upfronthosting.co.za>
Message-ID: <1454186378.99.0.888055169066.issue25690@psf.upfronthosting.co.za>


Niv Ben-David added the comment:

Regarding the documentation changes, my version simply mocks `open` more "closely", so for the most part I can't think of any changes to the documentation. I've added a bit about the mock object acting as a map of file names to mock objects. Should I add anything else?

Regarding the tests, I've tried changing as little as possible to make sure I don't have any backward compatibility issues. However, some changes had to be made:
* By default, `open`'s mode is 'r', the new mock_open imitates this behavior, and so the test shows. Also, calling `open` as a context manager will call `close` in `__exit__`. These are the majority of changes to the testing code.
* test_mock_open_write and test_mock_open_read_with_argument: These functionalities' testing is taken care of by the new mock_open tests.
* test_readlines_data: I removed the `create` argument to `patch`. Must've been by accident. Fixed this in the new patch.

Sorry about the (very) late response, I've been preoccupied lately.

----------
Added file: http://bugs.python.org/file41762/mock_open.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 16:00:40 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Jan 2016 21:00:40 +0000
Subject: [issue26244] zlib.compressobj level default value documentation
In-Reply-To: <1454179728.88.0.137425597988.issue26244@psf.upfronthosting.co.za>
Message-ID: <1454187640.38.0.836688032273.issue26244@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?m not sure that is perfectly correct. It really does default to -1, and that is passed to the underlying zlib library (-1 = Z_DEFAULT_COMPRESSION). It is the zlib library that decides that this means 6, but in theory I guess it could be configured or modified in the future with a different default. Perhaps we should clarify the text in the documentation (including the doc string) to say this instead?

At the very least, the documentation should continue to say that -1 is acceptable, and what it means.

----------
nosy: +martin.panter
stage:  -> patch review
versions: +Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 16:35:13 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Jan 2016 21:35:13 +0000
Subject: [issue26243] zlib.compress level as keyword argument
In-Reply-To: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za>
Message-ID: <1454189713.19.0.525681295865.issue26243@psf.upfronthosting.co.za>


Martin Panter added the comment:

Seems like a reasonable enhancement. A couple of points:

* Watch out for the parameter names. Should it be ?bytes? or ?data??
* Z_DEFAULT_COMPRESSION is -1 not 6 (see Issue 26244)
* Needs a version changed notice, and probably a What?s New update

----------
nosy: +martin.panter
stage:  -> patch review
type: behavior -> enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 17:27:53 2016
From: report at bugs.python.org (Serge Stroobandt)
Date: Sat, 30 Jan 2016 22:27:53 +0000
Subject: [issue26223] decimal.to_eng_string() does not implement engineering
 notation in all cases.
In-Reply-To: <1453922113.08.0.48679853518.issue26223@psf.upfronthosting.co.za>
Message-ID: <1454192873.44.0.147881693568.issue26223@psf.upfronthosting.co.za>


Serge Stroobandt added the comment:

Related issue:
https://bugs.python.org/issue8060

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 17:33:57 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 30 Jan 2016 22:33:57 +0000
Subject: [issue26241] repr() and str() are identical for floats in 3.5
In-Reply-To: <1454145724.12.0.226148276857.issue26241@psf.upfronthosting.co.za>
Message-ID: <1454193237.55.0.314810387083.issue26241@psf.upfronthosting.co.za>


Changes by Eric V. Smith :


----------
nosy: +eric.smith

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 20:08:41 2016
From: report at bugs.python.org (Nicholas Chammas)
Date: Sun, 31 Jan 2016 01:08:41 +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: <1454202521.44.0.42514777002.issue7850@psf.upfronthosting.co.za>


Nicholas Chammas added the comment:

As of Python 3.5.1 [0], it looks like

1) the `aliased` and `terse` parameters of `platform.platform()` are documented to take integers instead of booleans (contrary to what Marc-Andre requested), and 

2) calling `platform.platform()` with `aliased` set to 1 or True still returns "Darwin" on OS X.

Is this by design?

[0] https://docs.python.org/3.5/library/platform.html#platform.platform

----------
nosy: +Nicholas Chammas

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 21:07:41 2016
From: report at bugs.python.org (Patrik Dufresne)
Date: Sun, 31 Jan 2016 02:07:41 +0000
Subject: [issue24110] zipfile.ZipFile.write() does not accept bytes arcname
In-Reply-To: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za>
Message-ID: <1454206061.09.0.894529134407.issue24110@psf.upfronthosting.co.za>


Patrik Dufresne added the comment:

Manage to work around this issue by using surrogateescape for arcname and filename. For me it's no longer an issue.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 21:10:46 2016
From: report at bugs.python.org (Patrik Dufresne)
Date: Sun, 31 Jan 2016 02:10:46 +0000
Subject: [issue23252] Add support of writing to unseekable file in zipfile
In-Reply-To: <1421438148.04.0.307260333821.issue23252@psf.upfronthosting.co.za>
Message-ID: <1454206246.68.0.406332919479.issue23252@psf.upfronthosting.co.za>


Patrik Dufresne added the comment:

While this path provide support to create Zip file for non-seekable stream. It doesn't support reading a file from a non-seekable stream.

----------
nosy: +Patrik Dufresne

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 21:19:12 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 31 Jan 2016 02:19:12 +0000
Subject: [issue26173] test_ssl.bad_cert_test() exception handling
In-Reply-To: <1453373183.85.0.754157160572.issue26173@psf.upfronthosting.co.za>
Message-ID: <1454206752.13.0.239805612006.issue26173@psf.upfronthosting.co.za>


Martin Panter added the comment:

Updated patch; thanks for the comments Berker

----------
Added file: http://bugs.python.org/file41763/separate-test-py3.v2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 04:09:24 2016
From: report at bugs.python.org (Yoha)
Date: Sun, 31 Jan 2016 09:09:24 +0000
Subject: [issue22923] No prompt for "display all X possibilities" on
 completion-enabled input()
In-Reply-To: <1416735942.39.0.542265470543.issue22923@psf.upfronthosting.co.za>
Message-ID: <1454231364.68.0.892899768877.issue22923@psf.upfronthosting.co.za>


Changes by Yoha :


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 04:31:55 2016
From: report at bugs.python.org (Yoha)
Date: Sun, 31 Jan 2016 09:31:55 +0000
Subject: [issue26245] AttributeError (GL_READ_WRITE) when importing OpenGL.GL
Message-ID: <1454232715.33.0.584791017033.issue26245@psf.upfronthosting.co.za>


New submission from Yoha:

Importing `OpenGL.GL` fails on Python 3.5:

```
Python 3.5.1+ (default, Jan 13 2016, 15:09:18) 
[GCC 5.3.1 20160101] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import OpenGL.GL
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/OpenGL/GL/__init__.py", line 3, in 
    from OpenGL.GL.VERSION.GL_1_1 import *
  File "/usr/lib/python3/dist-packages/OpenGL/GL/VERSION/GL_1_1.py", line 10, in 
    from OpenGL import platform, constants, constant, arrays
  File "/usr/lib/python3/dist-packages/OpenGL/arrays/__init__.py", line 22, in 
    formathandler.FormatHandler.loadAll()
  File "/usr/lib/python3/dist-packages/OpenGL/arrays/formathandler.py", line 28, in loadAll
    cls.loadPlugin( entrypoint )
  File "/usr/lib/python3/dist-packages/OpenGL/arrays/formathandler.py", line 35, in loadPlugin
    plugin_class = entrypoint.load()
  File "/usr/lib/python3/dist-packages/OpenGL/plugins.py", line 14, in load
    return importByName( self.import_path )
  File "/usr/lib/python3/dist-packages/OpenGL/plugins.py", line 28, in importByName
    module = __import__( ".".join(moduleName), {}, {}, moduleName)
  File "/usr/lib/python3/dist-packages/OpenGL/arrays/vbo.py", line 430, in 
    def mapVBO( vbo, access=GL.GL_READ_WRITE ):
AttributeError: module 'OpenGL.GL' has no attribute 'GL_READ_WRITE'
```

It seems to work fine in Python 3.4:

```
Python 3.4.4 (default, Jan  5 2016, 15:35:18) 
[GCC 5.3.1 20160101] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import OpenGL.GL
>>> 
```

Or by first importing `OpenGL.GLU`:

```
Python 3.5.1+ (default, Jan 13 2016, 15:09:18) 
[GCC 5.3.1 20160101] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import OpenGL.GLU
>>> import OpenGL.GL
>>> 
```

----------
components: Extension Modules
messages: 259276
nosy: yoha
priority: normal
severity: normal
status: open
title: AttributeError (GL_READ_WRITE) when importing OpenGL.GL
type: crash
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 04:44:35 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 31 Jan 2016 09:44:35 +0000
Subject: [issue26245] AttributeError (GL_READ_WRITE) when importing OpenGL.GL
In-Reply-To: <1454232715.33.0.584791017033.issue26245@psf.upfronthosting.co.za>
Message-ID: <1454233475.68.0.973978888202.issue26245@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, Yoha. Your third example shows that this is either an error in PyOpenGL or there is something wrong in your PyOpenGL installation. Please report this to their issue tracker.

----------
nosy: +berker.peksag
resolution:  -> third party
stage:  -> resolved
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 04:49:23 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 31 Jan 2016 09:49:23 +0000
Subject: [issue26173] test_ssl.bad_cert_test() exception handling
In-Reply-To: <1453373183.85.0.754157160572.issue26173@psf.upfronthosting.co.za>
Message-ID: <1454233763.09.0.934761874451.issue26173@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Looks good to me. Thanks Martin.

----------
nosy: +berker.peksag
stage: patch review -> commit review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 05:05:17 2016
From: report at bugs.python.org (Liang Bo Wang)
Date: Sun, 31 Jan 2016 10:05:17 +0000
Subject: [issue26246] Code output toggle button uses removed jQuery method
Message-ID: <1454234717.37.0.159058452495.issue26246@psf.upfronthosting.co.za>


New submission from Liang Bo Wang:

The code output toggle button (the `>>>` button on the top right) has been disappeared and not functional on the current online documentation (both 3.4+ and 2.7). 


For example, see any doc page that has interpreter outputs:

    https://docs.python.org/3/tutorial/introduction.html#numbers
    https://docs.python.org/3.5/tutorial/introduction.html#numbers
    https://docs.python.org/3.4/tutorial/introduction.html#numbers
    https://docs.python.org/2/tutorial/introduction.html#numbers


These toggle buttons are created dynamically using jQuery by the script at Doc/tools/static/copybutton.js. However, the method .toggle() it used for click event handling has been deprecated since jQuery 1.8 and removed since jQuery 1.9.

    https://api.jquery.com/toggle-event/


Current Python documentation ships with jQuery v1.11.1 and it has a new .toggle() method with totally different behavior, which controls animation and hide the element. Therefore those buttons are invisible and has no effect.

    https://api.jquery.com/toggle/


To achieve the old behavior, one now needs to create this toggle event on one's own. The most popular way to store the toggle state is by jQuery's .data() data storage.

A patch is attached to make the button functional again.

----------
assignee: docs at python
components: Documentation
files: copybutton_js.patch
keywords: patch
messages: 259279
nosy: Liang Bo Wang, docs at python, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: Code output toggle button uses removed jQuery method
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41764/copybutton_js.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 09:23:21 2016
From: report at bugs.python.org (Ismail s)
Date: Sun, 31 Jan 2016 14:23:21 +0000
Subject: [issue26247] Document Chrome/Chromium for python2.7
Message-ID: <1454250201.34.0.379638558981.issue26247@psf.upfronthosting.co.za>


New submission from Ismail s:

The table of browser types in https://docs.python.org/2.7/library/webbrowser.html?highlight=webbrowser#webbrowser.register does not say that Google Chrome/Chromium is available on python2.7, even though it is (https://hg.python.org/cpython/file/2.7/Lib/webbrowser.py#l307).

Also, according to the docs for python.3.5 (https://docs.python.org/3.5/library/webbrowser.html?highlight=webbrowser#webbrowser.register , just below the table), support for google chrome/chromium was added in python3.3, so maybe this was backported to python2.7 and the docs not updated?

----------
assignee: docs at python
components: Documentation
messages: 259280
nosy: Ismail s, docs at python
priority: normal
severity: normal
status: open
title: Document Chrome/Chromium for python2.7
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 09:37:52 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 31 Jan 2016 14:37:52 +0000
Subject: [issue26247] Document Chrome/Chromium for python2.7
In-Reply-To: <1454250201.34.0.379638558981.issue26247@psf.upfronthosting.co.za>
Message-ID: <1454251072.5.0.0175937518888.issue26247@psf.upfronthosting.co.za>


SilentGhost added the comment:

It's due to issue 17536 and particularly 5a1429e9b621
I presume doko would be happy to follow up on that.

----------
nosy: +SilentGhost, doko

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 11:43:42 2016
From: report at bugs.python.org (Ben Hoyt)
Date: Sun, 31 Jan 2016 16:43:42 +0000
Subject: [issue26248] Improve scandir DirEntry docs,
 especially re symlinks and caching
Message-ID: <1454258622.6.0.285150622743.issue26248@psf.upfronthosting.co.za>


New submission from Ben Hoyt:

Per Guido's comment about DirEntry documentation on Issue 26032, especially http://bugs.python.org/issue26032#msg257665, it'd be good to improve the docs of the scandir DirEntry methods with regard to symlinks and caching.

Attaching my stab at a documentation fix. Changes here are:

1) Clarify that the return values of is_dir()/is_file()/etc are cached separately for follow_symlinks True and False.
2) Be more specific about when the functions require a system call, and how it relates to caching and follow_symlinks.
3) DRY up common stuff between is_dir and is_file by saying "Caching, system calls made, and exceptions raised are as per is_dir" in is_file.
4) Tweak to the first paragraph of docs for is_dir/is_file to simplify: assume the follow_symlinks=True default, then note the follow_symlinks=False non-default case after.

I think they're all improvements, though I'm not sure about #3. Is it better to just repeat those couple of paragraphs verbatim?

I'm also not 100% sure about mentioning the DT_UNKNOWN thing. But you really can't get more specific about when system calls are required on Unix without mentioning it.

----------
assignee: docs at python
components: Documentation
files: direntry_doc_improvements.patch
keywords: patch
messages: 259282
nosy: benhoyt, docs at python, gvanrossum, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve scandir DirEntry docs, especially re symlinks and caching
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41765/direntry_doc_improvements.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 11:46:05 2016
From: report at bugs.python.org (Ben Hoyt)
Date: Sun, 31 Jan 2016 16:46:05 +0000
Subject: [issue26032] Use scandir() to speed up pathlib globbing
In-Reply-To: <1452120927.04.0.31788168865.issue26032@psf.upfronthosting.co.za>
Message-ID: <1454258765.16.0.938809292792.issue26032@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

Guido, I've made some tweaks and improvements to the DirEntry docs here: http://bugs.python.org/issue26248 -- the idea is to fix the issues you mentioned to clarify when system calls are required with symlinks, mentioning that the results are cached separately for follow_symlinks True and False, etc.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 11:56:33 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 31 Jan 2016 16:56:33 +0000
Subject: [issue23601] use small object allocator for dict key storage
In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za>
Message-ID: <20160131165629.17884.9985@psf.io>


Roundup Robot added the comment:

New changeset 425fec4a79c7 by Raymond Hettinger in branch 'default':
Issue #23601:  Use small object allocator for dict key objects
https://hg.python.org/cpython/rev/425fec4a79c7

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 11:56:51 2016
From: report at bugs.python.org (Ian Kelly)
Date: Sun, 31 Jan 2016 16:56:51 +0000
Subject: [issue26221] asynco run_in_executor swallows StopIteration
In-Reply-To: <1453915533.75.0.0706458699162.issue26221@psf.upfronthosting.co.za>
Message-ID: <1454259411.45.0.301572727088.issue26221@psf.upfronthosting.co.za>


Ian Kelly added the comment:

The place I'd expect to find it is in https://docs.python.org/3/library/asyncio-task.html#coroutines, in the list of "things a coroutine can do". The first two bullets in the list say that any exceptions raised will be propagated. Maybe there should be a note after the bullet list to the effect that "StopIteration carries special meaning to coroutines and will not be propagated if raised by an awaited coroutine or future."

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 11:57:34 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Jan 2016 16:57:34 +0000
Subject: [issue23601] use small object allocator for dict key storage
In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za>
Message-ID: <1454259454.51.0.421610584026.issue23601@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks for the patch and for your patience.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 12:37:46 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 31 Jan 2016 17:37:46 +0000
Subject: [issue26248] Improve scandir DirEntry docs,
 especially re symlinks and caching
In-Reply-To: <1454258622.6.0.285150622743.issue26248@psf.upfronthosting.co.za>
Message-ID: <20160131173741.58302.64076@psf.io>


Roundup Robot added the comment:

New changeset f2c68cb17e31 by Victor Stinner in branch '3.5':
Enhance os.scandir() doc
https://hg.python.org/cpython/rev/f2c68cb17e31

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 12:40:25 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2016 17:40:25 +0000
Subject: [issue26248] Improve scandir DirEntry docs,
 especially re symlinks and caching
In-Reply-To: <1454258622.6.0.285150622743.issue26248@psf.upfronthosting.co.za>
Message-ID: <1454262025.73.0.584824408725.issue26248@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The change looks good to me. I pushed it to 3.5 & 3.6. It will be online in a few hours at:
https://docs.python.org/dev/library/os.html#os.DirEntry

I keep the issue open a few days to see if some others have other suggestions.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 12:43:24 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sun, 31 Jan 2016 17:43:24 +0000
Subject: [issue26244] zlib.compressobj level default value documentation
In-Reply-To: <1454179728.88.0.137425597988.issue26244@psf.upfronthosting.co.za>
Message-ID: <1454262204.27.0.596350751521.issue26244@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

I think that we can leave the level=-1 as the default in the documentation. What should be added is what Z_DEFAULT_COMPRESSION means.
I tried to be as close as possible to the zlib module documentation.

----------
Added file: http://bugs.python.org/file41766/zlib-compressobj-level-doc2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 12:48:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2016 17:48:24 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
Message-ID: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The issue #23601 showed speedup for the dict type by replacing PyMem_Malloc() with PyObject_Malloc() in dictobject.c.

When I worked on the PEP 445, it was discussed to use the Python fast memory allocator for small memory allocations (<= 512 bytes), but I think that nobody tested on benchmark.

So I open an issue to discuss that.

By the way, we should also benchmark the Windows memory allocator which limits fragmentations. Maybe we can skip the Python small memory allocator on recent version of Windows?

Attached patch implements the change. The main question is the speedup on various kinds of memory allocations (need a benchmark) :-)

I will try to run benchmarks.

--

If the patch slows down Python, maybe we can investigate if some Python types (like dict) mostly uses "small" memory blocks (<= 512 bytes).

----------
files: pymem.patch
keywords: patch
messages: 259290
nosy: haypo, rhettinger, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Change PyMem_Malloc to use PyObject_Malloc allocator?
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file41767/pymem.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 12:48:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2016 17:48:49 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1454262529.08.0.551960036904.issue26249@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +jtaylor

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 12:48:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2016 17:48:49 +0000
Subject: [issue23601] use small object allocator for dict key storage
In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za>
Message-ID: <1454262529.23.0.939719838833.issue23601@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Nice change. I opened the issue #26249 to continue the investigation.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 12:51:52 2016
From: report at bugs.python.org (hao Qing)
Date: Sun, 31 Jan 2016 17:51:52 +0000
Subject: [issue26250] no document for sqlite3.Cursor.connection
Message-ID: <1454262712.53.0.251399487214.issue26250@psf.upfronthosting.co.za>


New submission from hao Qing:

it does have the Cursor.connection member in the pydoc result.
$ pydoc sqlite3.Cursor.connection
Help on member descriptor sqlite3.Cursor.connection in sqlite3.Cursor:

sqlite3.Cursor.connection
lines 1-3/3 (END)

but there is no document about sqlite3.Cursor.connection at here.
https://docs.python.org/2/library/sqlite3.html#sqlite3.Cursor

and so to version 3
https://docs.python.org/3/library/sqlite3.html#sqlite3.Cursor

----------
components: Library (Lib)
messages: 259292
nosy: hao Qing
priority: normal
severity: normal
status: open
title: no document for sqlite3.Cursor.connection
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 12:55:40 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2016 17:55:40 +0000
Subject: [issue26251] Use "Low-fragmentation Heap" memory allocator on Windows
Message-ID: <1454262940.96.0.668805369213.issue26251@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Python has a memory allocator optimized for allocations <= 512 bytes: PyObject_Malloc(). It was discussed to replace it by the native "Low-fragmentation Heap" memory allocator on Windows.

I'm not aware of anyone who tried that. I would nice to try, especially to run benchmarks.

See also the issue #26249: "Change PyMem_Malloc to use PyObject_Malloc allocator?".

----------
components: Windows
messages: 259293
nosy: haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Use "Low-fragmentation Heap" memory allocator on Windows
type: performance
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 12:56:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2016 17:56:10 +0000
Subject: [issue26251] Use "Low-fragmentation Heap" memory allocator on Windows
In-Reply-To: <1454262940.96.0.668805369213.issue26251@psf.upfronthosting.co.za>
Message-ID: <1454262970.75.0.189844334402.issue26251@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Low-fragmentation Heap":
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366750%28v=vs.85%29.aspx

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 12:56:13 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 31 Jan 2016 17:56:13 +0000
Subject: [issue26252] Add an example to importlib docs on setting up an
 importer
Message-ID: <1454262973.06.0.14692878532.issue26252@psf.upfronthosting.co.za>


New submission from Brett Cannon:

This past week a lot of people have asked me about how to set up an importer. It's enough to warrant adding an example in the new Examples section of the importlib docs to explain how to do this using the pre-existing classes in importlib.machinery for illustrative  purposes.

----------
assignee: brett.cannon
components: Documentation
messages: 259295
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Add an example to importlib docs on setting up an importer
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 12:57:08 2016
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 31 Jan 2016 17:57:08 +0000
Subject: [issue26252] Add an example to importlib docs on setting up an
 importer
In-Reply-To: <1454262973.06.0.14692878532.issue26252@psf.upfronthosting.co.za>
Message-ID: <1454263028.99.0.247280182843.issue26252@psf.upfronthosting.co.za>


Changes by Donald Stufft :


----------
nosy: +dstufft

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 12:57:54 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2016 17:57:54 +0000
Subject: [issue26251] Use "Low-fragmentation Heap" memory allocator on Windows
In-Reply-To: <1454262940.96.0.668805369213.issue26251@psf.upfronthosting.co.za>
Message-ID: <1454263074.63.0.473874854914.issue26251@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The issue #19246 "high fragmentation of the memory heap on Windows" was rejected but discussed the Windows Low Fragmented Heap.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 12:59:22 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2016 17:59:22 +0000
Subject: [issue26249] Change PyMem_Malloc to use PyObject_Malloc allocator?
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1454263162.49.0.2973359107.issue26249@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ok, to avoid confusion, I opened an issue specific to Windows for its "Low-fragmentation Heap": issue #26251.

Other issues related to memory allocators.

Merged:

- issue #21233: Add *Calloc functions to CPython memory allocation API (extension of the PEP 445, asked by numpy)
- issue #13483: Use VirtualAlloc to allocate memory arenas (implementation of the PEP 445)
- issue #3329: API for setting the memory allocator used by Python

Open:

- issue #18835: Add aligned memory variants to the suite of PyMem functions/macros => this one is still open, the status is unclear :-/

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 13:00:42 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Jan 2016 18:00:42 +0000
Subject: [issue26252] Add an example to importlib docs on setting up an
 importer
In-Reply-To: <1454262973.06.0.14692878532.issue26252@psf.upfronthosting.co.za>
Message-ID: <1454263242.16.0.311328817814.issue26252@psf.upfronthosting.co.za>


Changes by Antoine Pitrou :


----------
nosy: +pitrou

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 13:10:28 2016
From: report at bugs.python.org (Paul Hammant)
Date: Sun, 31 Jan 2016 18:10:28 +0000
Subject: [issue26119] Windows Installer can sometimes silently fail pip stage
In-Reply-To: <1452830051.37.0.928414799264.issue26119@psf.upfronthosting.co.za>
Message-ID: <1454263828.82.0.395968433107.issue26119@psf.upfronthosting.co.za>


Paul Hammant added the comment:

Chronalog for today, below. Status - can reproduce at will, can't produce %TEMP% files was for - there aren't any.

0. I deleted all Python prefixed files from %TEMP%

1. I uninstalled Python 3.4 via it's windows installer. It progressed to completion. I noted after that there was still a C:\python34 directory with some remaining items in it. There was also still a PYTHONHOME environmental variable.

2. I installed Python 2.7 via it's canonical windows installer, and (as per this bug filing) it barfs, and then (with a couple of clicks from me) proceeds to undo the installation.

3. I've checked the %TEMP% folder. There's nothing in there with a matching timestamp, nor anything at all prefixed with 'Python'

4. If I redo #2 and explicitly de-select pip, the installation completes as expected.

5. If I uninstall (via the installer) and attempt to reinstall WITH pip, it barfs (as per this bug filing)

6. If I delete the PYTHONHOME env-var and attempt, it works.

Conclusion - Pip aspect of WindowsInstaller gets caught out on presence of erroneous PYTHONHOME. It does so for Python 2.7.x replaceing and Python 3.5.x or the opposite order.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 13:20:07 2016
From: report at bugs.python.org (Jeff Allen)
Date: Sun, 31 Jan 2016 18:20:07 +0000
Subject: [issue22121] IDLE should start with HOME as the initial working
 directory
In-Reply-To: <1406966032.01.0.548285467026.issue22121@psf.upfronthosting.co.za>
Message-ID: <1454264407.22.0.560481102494.issue22121@psf.upfronthosting.co.za>


Jeff Allen added the comment:

I'm also interested in a smooth experience for beginners.

I have a factual observation with respect to Terry's comment:
'''Windows icons have a Shortcut tab with a Start-in field.  We should like to put %USERPROFILE% there, but this does not work -- msg253393.'''
... I note that several menu shortcuts have "Start in" set to %HOMEDRIVE%%HOMEPATH%. Examples are notepad, Internet Explorer and the command prompt. (This is on Win7x64.) What we want seems to be a normal thing to do, and achieved by some, but perhaps by a post installation script.

Alternatively, once a .py file exists where you want to work, right-click "Edit with IDLE" provides the CWD we'd like best. Idea: add a New >> Python File context menu item. Encourage users to create a new file that way, then open it, and everything from there is smooth. (New issue if liked.)

----------
nosy: +jeff.allen

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 13:51:59 2016
From: report at bugs.python.org (Michael Cuthbert)
Date: Sun, 31 Jan 2016 18:51:59 +0000
Subject: [issue17446] doctest test finder doesnt find line numbers of
 properties
In-Reply-To: <1363536507.07.0.43500928967.issue17446@psf.upfronthosting.co.za>
Message-ID: <1454266319.39.0.503739011862.issue17446@psf.upfronthosting.co.za>


Michael Cuthbert added the comment:

this is my first contribution to Python core so I really have no idea how to do this, but I have found a solution (works in Py3.4, 2.7):

in doctest.py after line 1087 ("lineno = getattr(obj, 'co_firstlineno', None)-1")  add these lines:

        if lineno is None and isinstance(obj, property) and \
                obj.fget is not None:
            obj = obj.fget.__code__
            lineno = getattr(obj, 'co_firstlineno', None) 
            # no need for -1 because of decorator. 

I can try to make a patch file for this, but just want to be sure I'm on the right track for contributing first.  I know how to do a Git pull, but not hg/patch.

(p.s., I think the current code "lineno = getattr(obj, 'co_firstlineno', None)-1" has an error; if the getattr does not find 'co_firstlineno', it will return None and then subtract 1 from None which is a TypeError).

----------
nosy: +Michael Cuthbert

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 15:37:47 2016
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 31 Jan 2016 20:37:47 +0000
Subject: [issue26252] Add an example to importlib docs on setting up an
 importer
In-Reply-To: <1454262973.06.0.14692878532.issue26252@psf.upfronthosting.co.za>
Message-ID: <1454272667.37.0.791450315712.issue26252@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy: +ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 15:38:02 2016
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 31 Jan 2016 20:38:02 +0000
Subject: [issue26186] LazyLoader rejecting use of SourceFileLoader
In-Reply-To: <1453577280.26.0.226746274701.issue26186@psf.upfronthosting.co.za>
Message-ID: <1454272682.74.0.245018661676.issue26186@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy: +ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 15:42:29 2016
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 31 Jan 2016 20:42:29 +0000
Subject: [issue26252] Add an example to importlib docs on setting up an
 importer
In-Reply-To: <1454262973.06.0.14692878532.issue26252@psf.upfronthosting.co.za>
Message-ID: <1454272949.98.0.76792825059.issue26252@psf.upfronthosting.co.za>


Changes by Chris Rebert :


----------
nosy: +cvrebert

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 16:56:58 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 31 Jan 2016 21:56:58 +0000
Subject: [issue26045] Improve error message for http.client when posting
 unicode string
In-Reply-To: <1452205637.36.0.0359255361227.issue26045@psf.upfronthosting.co.za>
Message-ID: <1454277418.16.0.549884777131.issue26045@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is my cut down version of Guido?s patch. Now it only adds the message when someone passes a text string as the HTTPConnection.request(body=...) parameter:

>>> c.request("POST", "", body="Celebrate \U0001F389")
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/proj/python/cpython/Lib/http/client.py", line 1098, in request
    self._send_request(method, url, body, headers)
  File "/home/proj/python/cpython/Lib/http/client.py", line 1142, in _send_request
    body = _encode(body, 'body')
  File "/home/proj/python/cpython/Lib/http/client.py", line 161, in _encode
    (name.title(), data[err.start:err.end], name)) from None
UnicodeEncodeError: 'latin-1' codec can't encode character '\U0001f389' in position 10: Body ('?') is not valid Latin-1. Use body.encode('utf-8') if you want to send it encoded in UTF-8.

What do people think?

----------
Added file: http://bugs.python.org/file41768/utfpatch.v2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 17:00:18 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 31 Jan 2016 22:00:18 +0000
Subject: [issue26244] zlib.compressobj level default value documentation
In-Reply-To: <1454179728.88.0.137425597988.issue26244@psf.upfronthosting.co.za>
Message-ID: <1454277618.44.0.110881336818.issue26244@psf.upfronthosting.co.za>


Martin Panter added the comment:

This version looks great to me.

----------
versions: +Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 17:45:30 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 31 Jan 2016 22:45:30 +0000
Subject: [issue26173] test_ssl.bad_cert_test() exception handling
In-Reply-To: <1453373183.85.0.754157160572.issue26173@psf.upfronthosting.co.za>
Message-ID: <20160131224527.24937.57925@psf.io>


Roundup Robot added the comment:

New changeset 6d068205b580 by Martin Panter in branch '3.5':
Issue #26173: Separate bad cert file tests and client rejection test
https://hg.python.org/cpython/rev/6d068205b580

New changeset 3b211ee66b82 by Martin Panter in branch 'default':
Issue #26173: Merge SSL tests from 3.5
https://hg.python.org/cpython/rev/3b211ee66b82

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 19:55:23 2016
From: report at bugs.python.org (Patrik Dufresne)
Date: Mon, 01 Feb 2016 00:55:23 +0000
Subject: [issue26253] tarfile in stream mode always set zlib compression level
 to 9
Message-ID: <1454288123.43.0.462874591937.issue26253@psf.upfronthosting.co.za>


New submission from Patrik Dufresne:

When using tarfile.open(mode='w|gz'), the compression level is hard-coded to 9. Seed _Stream._init_write_gz():
    self.zlib.compressobj(9,

1. In regards to zlib, I would start by replacing the value of 9 by zlib.Z_DEFAULT_COMPRESSION. This is the default value and zipfile is using it. Why using something different.

2. Then, I would also love to control the compression level when calling tarfile.open()

----------
components: Library (Lib)
messages: 259304
nosy: Patrik Dufresne
priority: normal
severity: normal
status: open
title: tarfile in stream mode always set zlib compression level to 9
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 20:17:53 2016
From: report at bugs.python.org (Eric Fahlgren)
Date: Mon, 01 Feb 2016 01:17:53 +0000
Subject: [issue26252] Add an example to importlib docs on setting up an
 importer
In-Reply-To: <1454262973.06.0.14692878532.issue26252@psf.upfronthosting.co.za>
Message-ID: <1454289473.52.0.815102762769.issue26252@psf.upfronthosting.co.za>


Changes by Eric Fahlgren :


----------
nosy: +eric.fahlgren

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 20:23:15 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 01 Feb 2016 01:23:15 +0000
Subject: [issue17446] doctest test finder doesnt find line numbers of
 properties
In-Reply-To: <1363536507.07.0.43500928967.issue17446@psf.upfronthosting.co.za>
Message-ID: <1454289795.56.0.338396637272.issue17446@psf.upfronthosting.co.za>


Changes by Mark Lawrence :


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 20:50:17 2016
From: report at bugs.python.org (Evgeny Kapun)
Date: Mon, 01 Feb 2016 01:50:17 +0000
Subject: [issue26254] ssl server doesn't work with ECC certificates
Message-ID: <1454291417.3.0.6306970178.issue26254@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

I tried to use ssl module to create a server with a certificate that uses an ECC key. However, this didn't work. Here is how to reproduce this:

First, generate a key and a certificate:

    $ openssl req -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -x509 -keyout key.pem -out cert.pem
    (type some passphrase, then just press Enter in response to the questions that it asks)

Then run this Python program:

    from socket import socket
    from ssl import wrap_socket
    s = socket()
    s.bind(('localhost', 12345))
    s.listen()
    wrap_socket(s.accept()[0], 'key.pem', 'cert.pem', True)

This program will wait for a connection, so try to connect:

    $ openssl s_client -connect localhost:12345

The program will ask for a passphrase, so type it. After that, you will get an exception:

    Traceback (most recent call last):
      File "test.py", line 6, in 
        wrap_socket(s.accept()[0], 'key.pem', 'cert.pem', True)
      File "/usr/lib/python3.5/ssl.py", line 1064, in wrap_socket
        ciphers=ciphers)
      File "/usr/lib/python3.5/ssl.py", line 747, in __init__
        self.do_handshake()
      File "/usr/lib/python3.5/ssl.py", line 983, in do_handshake
        self._sslobj.do_handshake()
      File "/usr/lib/python3.5/ssl.py", line 628, in do_handshake
        self._sslobj.do_handshake()
    ssl.SSLError: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:645)

If the certificate uses RSA key, it works. With ECC, I had no luck. I tried creating a context explicitly and using set_ciphers method to enable more ciphers. While it appears to support ECDSA ciphersuites, it can't use them for some reason.

----------
components: Extension Modules
messages: 259305
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: ssl server doesn't work with ECC certificates
type: behavior
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 20:51:30 2016
From: report at bugs.python.org (Timo Furrer)
Date: Mon, 01 Feb 2016 01:51:30 +0000
Subject: [issue17446] doctest test finder doesnt find line numbers of
 properties
In-Reply-To: <1363536507.07.0.43500928967.issue17446@psf.upfronthosting.co.za>
Message-ID: <1454291490.18.0.668218540335.issue17446@psf.upfronthosting.co.za>


Timo Furrer added the comment:

I took the ideas from @Michael.Cuthbert and wrote a proper test. It's my first patch so I hope everything's fine with it. If not I'm happy for feedback :)

----------
keywords: +patch
nosy: +Timo Furrer
Added file: http://bugs.python.org/file41769/fix_issue_17446.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 21:28:39 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 01 Feb 2016 02:28:39 +0000
Subject: [issue26238] httplib use wrong hostname in https request with SNI
 support
In-Reply-To: <1454070946.61.0.657909359351.issue26238@psf.upfronthosting.co.za>
Message-ID: <1454293719.07.0.792135426327.issue26238@psf.upfronthosting.co.za>


Martin Panter added the comment:

The code fragment you posted looks like it is from HTTPSConnection.connect() . But _get_hostport() is already called to set self.host in __init__(), and to set self._tunnel_host in set_tunnel(). So I do not understand what you are proposing. Can you provide a patch?

Failing that, can you give a demonstration where the SNI and ?request ServerName? (is this the Host header field?) mismatch?

The only potential bug I can see is if you specify the host by IP address, the IP address is sent as the SNI, when RFC 6066 seems to say a literal IP address is not permitted.

Client (run in Python 2.7.11):
>>> conn = HTTPSConnection("127.0.0.1:44300", context=ssl._create_unverified_context())
>>> conn.request("GET", "/")

Server (run in Python 3.6):
>>> server = socket()
>>> server.bind(("localhost", 44300))
>>> server.listen()
>>> context = SSLContext(PROTOCOL_SSLv23)
>>> @context.set_servername_callback
... def callback(conn, name, context):
...     print(f"Requested server name {name!r}")
...     context = SSLContext(PROTOCOL_SSLv23)
...     context.load_cert_chain("Lib/test/keycert.pem")
...     conn.context = context
... 
>>> [conn, _] = server.accept()
>>> wrapped = context.wrap_socket(conn, server_side=True)
Requested server name '127.0.0.1'

My understanding is the client shouldn?t use SNI here, in which case the server name would be None.

----------
nosy: +martin.panter
stage:  -> test needed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 22:13:43 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 01 Feb 2016 03:13:43 +0000
Subject: [issue26253] tarfile in stream mode always set zlib compression level
 to 9
In-Reply-To: <1454288123.43.0.462874591937.issue26253@psf.upfronthosting.co.za>
Message-ID: <1454296423.22.0.321330773541.issue26253@psf.upfronthosting.co.za>


Martin Panter added the comment:

It looks like the default has been hard-coded to 9 ever since tarfile was added to Python. The gzip module is also hard-coded to 9 since it was added. If tarfile is changed, maybe gzip should too.

Why would you want to use zlib?s default (apparently 6)? Memory usage or speed perhaps? If we do change the default, maybe it is best to only do it in 3.6. I don?t see it as a bug fix, and there is a chance it could break someone?s code.

To be able to control the compression level, perhaps you can already do it by wrapping the tar stream with GzipFile (untested):

gz_writer = GzipFile(fileobj=raw_writer, mode="wb", compresslevel=...)
tar_writer = tarfile.open(fileobj=gz_writer, mode="w|")
tar_writer.addfile(...)
tar_writer.close()
gz_writer.close()

If the default is changed, it certainly makes sense to add an easy compression level parameter, to be able to restore the old behaviour.

----------
nosy: +martin.panter
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 23:01:25 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 01 Feb 2016 04:01:25 +0000
Subject: [issue26119] Windows Installer can sometimes silently fail pip stage
In-Reply-To: <1452830051.37.0.928414799264.issue26119@psf.upfronthosting.co.za>
Message-ID: <1454299285.25.0.0395509464888.issue26119@psf.upfronthosting.co.za>


Steve Dower added the comment:

It's not clear which version of Python you are having trouble with, but it apparently isn't 3.5.

The PYTHONHOME variable is never set or modified by our installers, but some earlier versions may be affected by it. We recommend never setting environment variables globally - only in the command prompt when you're about to use them.

If the issue is with 3.4, it won't get fixed. Future releases of that branch will not come with builds for Windows.

Once you've cleared the stray variable, please let us know if you have trouble with 2.7 and/or 3.5.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 23:12:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 01 Feb 2016 04:12:00 +0000
Subject: [issue26173] test_ssl.bad_cert_test() exception handling
In-Reply-To: <1453373183.85.0.754157160572.issue26173@psf.upfronthosting.co.za>
Message-ID: <20160201041154.45927.26231@psf.io>


Roundup Robot added the comment:

New changeset 6f7b2b7a029a by Martin Panter in branch '2.7':
Issue #26173: Separate bad cert file tests and client rejection test
https://hg.python.org/cpython/rev/6f7b2b7a029a

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 23:43:36 2016
From: report at bugs.python.org (Thomas Caswell)
Date: Mon, 01 Feb 2016 04:43:36 +0000
Subject: [issue24266] raw_input + readline: Ctrl+C during search breaks
 readline
In-Reply-To: <1432306683.9.0.470835567306.issue24266@psf.upfronthosting.co.za>
Message-ID: <1454301816.69.0.0797952413222.issue24266@psf.upfronthosting.co.za>


Thomas Caswell added the comment:

I do not think that readline-cancel.patch is sufficient. The clean up function that readline uses internally (http://git.savannah.gnu.org/cgit/readline.git/tree/isearch.c#n720 ) also cleans up the context that used by isearch.

The functions to cleanup the context (and a pointer to the context) are exposed on `rlprivate.h` so python _can_ get at them to support old versions of rl. Once started down that path for isearch mode, might as well vendor all of rl_callback_sigcleanup() which will end up being 50-100 LoC (some of the helper functions will also need to be vendored).

----------
nosy: +tcaswell

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 23:49:19 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 01 Feb 2016 04:49:19 +0000
Subject: [issue26045] Improve error message for http.client when posting
 unicode string
In-Reply-To: <1454277418.16.0.549884777131.issue26045@psf.upfronthosting.co.za>
Message-ID: 


Guido van Rossum added the comment:

LGTM.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 23:51:56 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 01 Feb 2016 04:51:56 +0000
Subject: [issue24266] raw_input + readline: Ctrl+C during search breaks
 readline
In-Reply-To: <1432306683.9.0.470835567306.issue24266@psf.upfronthosting.co.za>
Message-ID: <1454302316.18.0.603483321768.issue24266@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think it might be best to wait until we are sure that the new Readline 7 API is stable (Is already the case?), push something like readline-sigcleanup.patch, and don?t bother with hacks for Readline 6 (or Editline etc).

----------

_______________________________________
Python tracker 

_______________________________________