, argc=6, argv=0x7ffdfcb8cfe8, init=, fini=, rtld_fini=, stack_end=0x7ffdfcb8cfd8) at libc-start.c:291 #12 0x000000000049d639 in _start () Problem looks obvious: (gdb) p (((PyObject*)(op))->ob_type) $86202 = (struct _typeobject *) 0x0 But `subtract_refs()` from `Modules/gcmodule.c:385` is iterating a very long chained list, and I'm not sure it's of any help iterating over it. Can provide core dump if of any help. Python version: Python 2.7.12 PIP version: pip 8.1.2 from /usr/lib/python2.7/dist-packages (python 2.7) Looks reproductible: ``` $ python -m pip install --user ansible Collecting ansible Collecting jinja2 (from ansible) Using cached Jinja2-2.8-py2.py3-none-any.whl Collecting setuptools (from ansible) Using cached setuptools-24.0.3-py2.py3-none-any.whl Collecting PyYAML (from ansible) Collecting pycrypto>=2.6 (from ansible) Collecting paramiko (from ansible) Using cached paramiko-2.0.1-py2.py3-none-any.whl Collecting MarkupSafe (from jinja2->ansible) Collecting cryptography>=1.1 (from paramiko->ansible) Collecting pyasn1>=0.1.7 (from paramiko->ansible) Using cached pyasn1-0.1.9-py2.py3-none-any.whl Collecting enum34 (from cryptography>=1.1->paramiko->ansible) Using cached enum34-1.1.6-py2-none-any.whl Collecting idna>=2.0 (from cryptography>=1.1->paramiko->ansible) Using cached idna-2.1-py2.py3-none-any.whl Collecting cffi>=1.4.1 (from cryptography>=1.1->paramiko->ansible) Using cached cffi-1.7.0-cp27-cp27mu-manylinux1_x86_64.whl Collecting ipaddress (from cryptography>=1.1->paramiko->ansible) Using cached ipaddress-1.0.16-py27-none-any.whl Collecting six>=1.4.1 (from cryptography>=1.1->paramiko->ansible) Using cached six-1.10.0-py2.py3-none-any.whl Collecting pycparser (from cffi>=1.4.1->cryptography>=1.1->paramiko->ansible) Installing collected packages: MarkupSafe, jinja2, setuptools, PyYAML, pycrypto, enum34, idna, pycparser, cffi, ipaddress, six, pyasn1, cryptography, paramiko, ansible Successfully installed MarkupSafe-0.23 PyYAML-3.11 ansible-2.1.0.0 cffi-1.7.0 cryptography-1.4 enum34-1.1.6 idna-2.1 ipaddress-1.0.16 jinja2-2.8 paramiko-2.0.1 pyasn1-0.1.9 pycparser-2.14 pycrypto-2.6.1 setuptools-24.0.3 six-1.10.0 Segmentation fault (core dumped) ``` I tried installing only a few packages to see if one in particular causes the bug and yes, cffi may be the one: ``` $ python -m pip install --user cffi Collecting cffi Using cached cffi-1.7.0-cp27-cp27mu-manylinux1_x86_64.whl Collecting pycparser (from cffi) Installing collected packages: pycparser, cffi Successfully installed cffi-1.7.0 pycparser-2.14 Segmentation fault (core dumped) ``` But not pycparser alone: ``` $ python -m pip install --user pycparser Collecting pycparser Installing collected packages: pycparser Successfully installed pycparser-2.14 ``` ---------- components: Interpreter Core messages: 270633 nosy: sizeof priority: normal severity: normal status: open title: Segfault in gcmodule.c:360 visit_decref versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 14:14:01 2016 From: report at bugs.python.org (Marc) Date: Sun, 17 Jul 2016 18:14:01 +0000 Subject: [New-bugs-announce] [issue27543] from module import function creates package reference to the module Message-ID: <1468779241.06.0.301525903069.issue27543@psf.upfronthosting.co.za> New submission from Marc: Hello, I've found an issue in python 2.7 and 3.4 and I don't if this is a bug or a feature that acts strange to me. The import of a module or method from a module creates a reference in the package to that module only the first time, which could lead to unexpected behavior. Description: In following code there's one line marked with 'this line fixes the code to what I expected' 1. Without that line package.a.test() results in 'from module a' 2. With the line package.a.test() results in 'from module b' Situation 1 is unexpected because I did not create the reference to 'module a', python did that with the statement 'from package.a import test' and this will happen from any place in the code that loads 'module a' for the first time. The documentation says that this reference will not be created. Kind regards, Marc # FILES USED # # test.py # package # __init__.py # a.py # b.py # --------------------- # Content of a.py: def test(): print('from module a') # --------------------- # Content of a.py: def test(): print('from module b') # --------------------- # Content of __init__.py #import a # <--- this line fixes the code to what I expected import b as a from a import test # --------------------- # Content of test.py import package print(dir(package)) package.a.test() ---------- components: Interpreter Core messages: 270658 nosy: m.nijland priority: normal severity: normal status: open title: from module import function creates package reference to the module type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 17 21:25:16 2016 From: report at bugs.python.org (hannah) Date: Mon, 18 Jul 2016 01:25:16 +0000 Subject: [New-bugs-announce] [issue27544] Document checking dict types Message-ID: <1468805116.02.0.14575319212.issue27544@psf.upfronthosting.co.za> New submission from hannah: While there is documentation that dict.keys(), dict.values(), and dict.items() are now view objects(https://docs.python.org/3/library/stdtypes.html#dict-views), there's no mention dictviews, dict_keys, dict_values, and dict_items not being built-ins. This is confusing because type(dict.keys()) returns dict_keys, type(dict.values()) returns dict_values, etc., and the documentation uses `dictview` as the object signature, and so it's unclear how to do object introspection on dictview objects. The #python-dev channel suggested that the canonical way to do the object introspection is to use the collections.abc.mapview types; the documentation for dicts should reflect this (and that dictview and the rest are not __builtin__ types/in the python namspace). ---------- assignee: docs at python components: Documentation messages: 270672 nosy: docs at python, story645 priority: normal severity: normal status: open title: Document checking dict types 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 Sun Jul 17 23:08:09 2016 From: report at bugs.python.org (Decorater) Date: Mon, 18 Jul 2016 03:08:09 +0000 Subject: [New-bugs-announce] [issue27545] missing pyshellext.vcxproj prevents puilding 3.6 Message-ID: <1468811289.51.0.698571569689.issue27545@psf.upfronthosting.co.za> New submission from Decorater: I have a issue with building 3.6 now since I got the last hg update it seems the github repo is broken too. This does need a fix. ---------- components: Build messages: 270677 nosy: Decorater priority: normal severity: normal status: open title: missing pyshellext.vcxproj prevents puilding 3.6 type: compile error versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 00:10:10 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 18 Jul 2016 04:10:10 +0000 Subject: [New-bugs-announce] [issue27546] Integrate tkinter and asyncio (and async) Message-ID: <1468815010.57.0.709565417017.issue27546@psf.upfronthosting.co.za> New submission from Terry J. Reedy: The last week of last February, there was a discussion of this topic on python-ideas as part of "How the heck does async/await work in Python 3.5". I would like to re-start the discussion along with rescuing the two big chunks of code that were posted. Guido, you said "it would be very useful to have an asyncio loop integrated with Tkinter". Were you thinking of something added to either the asyncio or tkinter modules? What would be the minimum that you think would be worth adding? What would a mininal test look like? There are, of course, multiple strategies. Maxime posted the code I copied into the attached tkselector.py. No example usage was given. I cannot run it on Windows because it uses a unix-only function. Maxime, for us to use this, you need to sign the contributor agreement, which can be done via the net. See https://www.python.org/psf/contrib/ As soon as I submit this, I will also upload my tkloop.py. It defines a TkEventLoop class that adds root.update in the run_forever method. It then uses the class for working example of a asyncio callback modifying a tk widget at times intervals. As I note in the doc string, there is an issue with asyncio's _run_once() blocking forever. I recently noticed that idlelib.run.main does something similar, running a loop that gets user input with 1/20 second timeout and calling tkapp.eval('update') whenever there is none. Motivations: 1. Mix gui events (key, mouse, and others) with i/o events. 2. Use gui events with the new async syntax. My simple example, in the callback typical of tkinter apps, has widgets, callback, and dynamics defined in different places. I would like to be able to write the app in a more 'natural' style, using loops: something like async def display_date(interval, end_time, loop=ai.get_event_loop()): label = tk.Label(root) label.pack() async for tick in timer(interval, end_time, loop): label['text'] = datetime.datetime.now() Some python-tkinter beginners try to do something like this, except that for time delays they use while and time.sleep. There have been many Stackoverflow questions about the resulting failures. I would like to find out if I presume that converting my example to something like the above, using TkEventLoop, could be done easily enough by someone who knows how. For only supporting tk events, it would be better to have a tkinter implementation of the needed subset of asyncio.events.AbstractEventLoop. The run and call methods are needed, the io methods not, but I am not sure where to draw the line in between. The implementation of a few methods should be fairly easy: run_forever is mainloop, close is destroy; run_until_complete will be harder. ---------- files: tkselector.py messages: 270688 nosy: Maxime S, gvanrossum, serhiy.storchaka, terry.reedy, yselivanov priority: normal severity: normal stage: test needed status: open title: Integrate tkinter and asyncio (and async) type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43769/tkselector.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 01:39:04 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 05:39:04 +0000 Subject: [New-bugs-announce] [issue27547] Integer Overflow Crash On float(array.array()) Message-ID: <1468820344.69.0.285015698444.issue27547@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow because python doesn't check the length as it does with bytearray() and it still goes on, so by doing something like: >>> import array >>> float(array.array("L",b"a"*0xFFFFFFFFFFFFFFF+100000**8000000000)) It returns: Python(2179,0x7fff7ad6a000) malloc: *** mach_vm_map(size=1152921504606851072) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug And then it just crashes Or you can skip the error and just do: >>> import array >>> float(array.array("L",b"a"*0xFFFFFFFFFFFFFFF**10000000000**80000000000000000)) That will just make python freeze until you restart it, which is as good as crashed. The file would be: import array float(array.array("L",b"a"*0xFFFFFFFFFFFFFFF**10000000000**80000000000000000)) Hope it helps ;) ---------- messages: 270700 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow Crash On float(array.array()) versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 01:54:55 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 05:54:55 +0000 Subject: [New-bugs-announce] [issue27548] Integer Overflow On bin() Message-ID: <1468821295.01.0.886780512463.issue27548@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow in bin() because python incorrectly checks the length of the input in bin(). bin(0xFFFFFFFFFFFFFFF+100000**8000000000) That line will freeze python until you restart it, which basically is a crash because python stops working completely. Hope it helps ;) ---------- messages: 270702 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow On bin() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 01:54:59 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 05:54:59 +0000 Subject: [New-bugs-announce] [issue27549] Integer Overflow Crash On bytearray() Message-ID: <1468821299.76.0.127950361859.issue27549@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow because python doesn't check the length correctly on bytearray: bytearray(0xFFFFFFFFFFFFFFF**10000000000**80000000000000000) That will not return an overflow message, and even though my hex knowledge is very bad I do believe 0xFFFFFFFFFFFFFFF**10000000000**80000000000000000 is more than 0xFFFFFFFFFFFFFFFF which does return a overflow message. Hope it helps ;) ---------- messages: 270703 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow Crash On bytearray() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 01:56:32 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 05:56:32 +0000 Subject: [New-bugs-announce] [issue27550] Integer Overflow Crash On Arithmetic Operations Message-ID: <1468821392.71.0.241203163582.issue27550@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow because python doesn't check the length correctly on arithmetic operations: 0xFFFFFFFFFFFFFFF**10000000000**80000000000000000 Just that line will freeze python, no oveflow message appears, no memory error, and python basically crashes because it just stops working. Hope it helps ;) ---------- messages: 270704 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow Crash On Arithmetic Operations versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 01:56:39 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 05:56:39 +0000 Subject: [New-bugs-announce] [issue27551] Integer Overflow On print() Message-ID: <1468821399.2.0.180204407388.issue27551@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow because python doesn't check the length correctly on print() statements: print(0xFFFFFFFFFFFFFFF**10000000000**80000000000000000) That will overflow and python would stop working, so it would be as good as crashed :) Hope it helps ;) ---------- messages: 270705 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow On print() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:02:39 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 06:02:39 +0000 Subject: [New-bugs-announce] [issue27552] Integer Overflow On min() Message-ID: <1468821759.48.0.396391812874.issue27552@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow on min() statements because python incorrectly checks the length to put the overflow message, so it is possible to overflow min() min(0xFFFFFFFFFFFFFFF+100000**8000000000) That line freezes python until you restart it, which is basically as if you were crashing it, the effect is the same, python stops working. Hope it helps ;) ---------- messages: 270706 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow On min() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:04:24 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 06:04:24 +0000 Subject: [New-bugs-announce] [issue27553] Integer Overflow On unicode() Message-ID: <1468821864.13.0.013612270682.issue27553@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow in unicode() because python incorrectly checks the length of unicode(): unicode(0xFFFFFFFFFFFFFFF+100000**8000000000) That freezes python until you restart it which is basically the same effect as crashing python. Hope it helps ;) ---------- messages: 270707 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow On unicode() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:05:41 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 06:05:41 +0000 Subject: [New-bugs-announce] [issue27554] Integer Overflow On dir() Message-ID: <1468821941.88.0.767862457306.issue27554@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow in dir(): dir(0xFFFFFFFFFFFFFFF+100000**8000000000) That line will freeze python until you restart it, which makes it have the same effect as a crash. Hope it helps ;) ---------- messages: 270708 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow On dir() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:11:29 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 06:11:29 +0000 Subject: [New-bugs-announce] [issue27555] Integer Overflow on oct() Message-ID: <1468822289.98.0.19542711871.issue27555@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow on oct() because of incorrectly checking the length. oct(0xFFFFFFFFFFFFFFF+100000**8000000000) That line will freeze python until you restart it, which is as good as crashed. Hope it helps ;) ---------- messages: 270709 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow on oct() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:14:00 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 06:14:00 +0000 Subject: [New-bugs-announce] [issue27556] Integer overflow on hex() Message-ID: <1468822440.54.0.519269097524.issue27556@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow on hex() because python incorrectly checks the length of the value to return overflow message if it were too big. hex(0xFFFFFFFFFFFFFFF+100000**8000000000) That line will freeze python until you restart it, which is the same thing as crashing python. Hope it helps ;) ---------- messages: 270710 nosy: pabstersac priority: normal severity: normal status: open title: Integer overflow on hex() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:21:48 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 06:21:48 +0000 Subject: [New-bugs-announce] [issue27557] Integer Overflow on int() Message-ID: <1468822908.93.0.0686992762741.issue27557@psf.upfronthosting.co.za> New submission from pablo sacristan: There is an integer overflow on int() because python incorrectly checks the length of the input. int(0xFFFFFFFFFFFFFFF+100000**8000000000) That line of code will freeze python until you restart it, which is as annoying as if python had crashed. Hope it helps ;) ---------- messages: 270711 nosy: pabstersac priority: normal severity: normal status: open title: Integer Overflow on int() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 02:26:43 2016 From: report at bugs.python.org (Romuald Brunet) Date: Mon, 18 Jul 2016 06:26:43 +0000 Subject: [New-bugs-announce] [issue27558] SystemError inside multiprocessing.dummy Pool.map Message-ID: <1468823203.61.0.708048243679.issue27558@psf.upfronthosting.co.za> New submission from Romuald Brunet: Raising without a previous exception inside a method called from multiprocessing.dummy.Pool.map will trigger a SystemError. SystemError: PyEval_EvalFrameEx returned NULL without setting an error Traceback (most recent call last): File "example.py", line 16, in main() File "example.py", line 11, in main result = pool.map(test, [1]) File "/usr/local/Cellar/python3/3.5.2/Frameworks/Python.framework/Versions/3.5/lib/python3.5/multiprocessing/pool.py", line 260, in map return self._map_async(func, iterable, mapstar, chunksize).get() File "/usr/local/Cellar/python3/3.5.2/Frameworks/Python.framework/Versions/3.5/lib/python3.5/multiprocessing/pool.py", line 608, in get raise self._value File "/usr/local/Cellar/python3/3.5.2/Frameworks/Python.framework/Versions/3.5/lib/python3.5/multiprocessing/pool.py", line 119, in worker result = (True, func(*args, **kwds)) File "/usr/local/Cellar/python3/3.5.2/Frameworks/Python.framework/Versions/3.5/lib/python3.5/multiprocessing/pool.py", line 44, in mapstar return list(map(*args)) SystemError: PyEval_EvalFrameEx returned NULL without setting an error Reproducible example is attached ---------- components: Interpreter Core files: example.py messages: 270713 nosy: Romuald priority: normal severity: normal status: open title: SystemError inside multiprocessing.dummy Pool.map type: behavior versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file43772/example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 05:08:05 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 09:08:05 +0000 Subject: [New-bugs-announce] [issue27559] Crash On bytearray() Message-ID: <1468832885.3.0.732999083359.issue27559@psf.upfronthosting.co.za> New submission from pablo sacristan: There is a crash on bytearray(), not really a crash but rather the process gets killed by the kernel, but that is a crash, and the keyboard interrupt stops working while bytearray is working, so you can either restart python or wait for python to get killed by the kernel. The biggest problem is that while bytearray() is trying to do something, you can't interrupt it just doesn't work for some reason. This should be enough for bytearray to crash : bytearray(0xFFFFFFFFFF) It crashes after some time with a Killed: 9 error. Hope it helps ;) ---------- messages: 270731 nosy: pabstersac priority: normal severity: normal status: open title: Crash On bytearray() versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 05:08:54 2016 From: report at bugs.python.org (pablo sacristan) Date: Mon, 18 Jul 2016 09:08:54 +0000 Subject: [New-bugs-announce] [issue27560] zlib.compress() crash and keyboard interrupt stops working Message-ID: <1468832934.6.0.711776862351.issue27560@psf.upfronthosting.co.za> New submission from pablo sacristan: zlib.compress crashes when you put a lot of stuff into it and even when you try keyboard interrupts it doesn't work for some reason, and Python gets killed because trying to compress so much data gets the Python process get killed by the kernel. If you put a large amount of data in it will get killed quicker. A problem is that keyboard interrupts stop working while the program is running, which is usually around 5 - 15 seconds during which python stops working (including interrupts) until it gets killed by the kernel. This may be used to crash python remotely if a server takes user input and runs it through zlib.compress(b'variable' * 2**32) which is not very likely. You probably should set a limit for what you compress and how much it is. The output is: Killed: 9 Even though you try doing keyboard interrupt it doesn't work. ---------- files: crash.py messages: 270732 nosy: pabstersac priority: normal severity: normal status: open title: zlib.compress() crash and keyboard interrupt stops working Added file: http://bugs.python.org/file43774/crash.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 09:30:51 2016 From: report at bugs.python.org (Kirk Hansen) Date: Mon, 18 Jul 2016 13:30:51 +0000 Subject: [New-bugs-announce] [issue27561] Warn against subclassing builtins, and overriding their methods Message-ID: <1468848651.49.0.804648096873.issue27561@psf.upfronthosting.co.za> New submission from Kirk Hansen: I tried subclassing dict, and overriding its __setitem__ and __getitem__ and got some interesting results. See http://stackoverflow.com/questions/38362420/subclassing-dict-dict-update-returns-incorrrect-value-python-bug?noredirect=1#comment64142710_38362420 for an example. I tried sub-classing UserDict.UserDict and experienced some of the same problems. Eventually, I discovered that subclassing MutableMapping was my best bet. After an hour or two of searching and reading I discovered that CPython will not call overridden built-in methods of the same object (https://pypy.readthedocs.io/en/latest/cpython_differences.html#subclasses-of-built-in-types). This behaviour could (and did) cause some hard to track down bugs in code. I briefly looked at the later versions of python documentation and didn't see a mention of this (sorry if it's there), but python2.7 definitely does not mention this. In fact, python2.7 seems to __encourage__ users to subclass the built-ins (see the note https://docs.python.org/2.7/library/stdtypes.html?highlight=dict#built-in-types). Subclassing dict to __extend__ functionality is great, but there should be a big bad warning when trying to __override__ built-ins like __setitem__ and __getitem__. ---------- assignee: docs at python components: Documentation messages: 270754 nosy: Kirk Hansen, docs at python priority: normal severity: normal status: open title: Warn against subclassing builtins, and overriding their methods 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 Mon Jul 18 09:48:21 2016 From: report at bugs.python.org (Iovan Irinel) Date: Mon, 18 Jul 2016 13:48:21 +0000 Subject: [New-bugs-announce] [issue27562] Import error encodings (Windows xp compatibility) Message-ID: <1468849701.41.0.980015051967.issue27562@psf.upfronthosting.co.za> New submission from Iovan Irinel: I have python embeded intro my application. I wanted to upgrade to python 2.7.12 i use also a static library. Not DLL. I have defined "Py_NO_ENABLE_SHARE" Ok, all work fine with 2.7.6 I want to say this error happen just when i run it under windows xp. Under windows 10 it works , my application start.. Pythoncore and application is build with v140_xp toolset i user visual studio 2015. I can make a video with error if is necessary. Thanks. Traceback (most recent call last): File "Lib/site.py", line 548, in File "Lib/site.py", line 537, in main File "Lib/site.py", line 465, in aliasmbcs File "Lib/locale.py", line 13, in ImportError: No module named encodings I made more test and i come with a reply. ---------- components: Windows messages: 270756 nosy: Iovan Irinel, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Import error encodings (Windows xp compatibility) versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 10:27:43 2016 From: report at bugs.python.org (Ram Rachum) Date: Mon, 18 Jul 2016 14:27:43 +0000 Subject: [New-bugs-announce] [issue27563] docs for `gc.get_referrers` should explain the result format (i.e. what keys in the dict mean) Message-ID: <1468852063.19.0.0147283697672.issue27563@psf.upfronthosting.co.za> Changes by Ram Rachum : ---------- assignee: docs at python components: Documentation nosy: cool-RR, docs at python priority: normal severity: normal status: open title: docs for `gc.get_referrers` should explain the result format (i.e. what keys in the dict mean) 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 Mon Jul 18 11:29:06 2016 From: report at bugs.python.org (Tom Middleton) Date: Mon, 18 Jul 2016 15:29:06 +0000 Subject: [New-bugs-announce] [issue27564] 2.7.12 Windows Installer package broken. Message-ID: <1468855746.01.0.612957751077.issue27564@psf.upfronthosting.co.za> New submission from Tom Middleton: I was running: 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. I downloaded the msi for Python 2.7.12 and attempted to run it. During the installation it gave me the following error: "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." Then it "rolls back" the action, which killed my current 2.7.11 installation. Despite that it states: "Python 2.7.12 setup ended prematurely because of an error. Your system has not been modified. To install this program at a later time, please run the installation again." (pardon any typos in the error messages since I wasn't able to copy the text directly.) I attempted this twice with the same result. Thanks, Tom ---------- components: Installation messages: 270762 nosy: busfault priority: normal severity: normal status: open title: 2.7.12 Windows Installer package broken. type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 15:31:04 2016 From: report at bugs.python.org (Claudiu Saftoiu) Date: Mon, 18 Jul 2016 19:31:04 +0000 Subject: [New-bugs-announce] [issue27565] Offer error context manager for code.interact Message-ID: <1468870264.4.0.689422874662.issue27565@psf.upfronthosting.co.za> New submission from Claudiu Saftoiu: When debugging code that raises unexpected exceptions, I often find myself doing this: try: some_code except: import code; code.interact(local=locals()) raise My suggestion is a context manager to make this less verbose: with code.interact_on_error(): some_code The effect would be the same: if an exception is caught, `code.interact` is called with the locals of the function, and re-raised when `code.interact` ends. ---------- components: Library (Lib) messages: 270786 nosy: Claudiu Saftoiu priority: normal severity: normal status: open title: Offer error context manager for code.interact type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 15:50:39 2016 From: report at bugs.python.org (David D) Date: Mon, 18 Jul 2016 19:50:39 +0000 Subject: [New-bugs-announce] [issue27566] Freeze: winmakemakefile.py: clean: Linux instead of Windows command Message-ID: <1468871439.96.0.540268707664.issue27566@psf.upfronthosting.co.za> New submission from David D: The command for the clean target in the Windows makefile is the same as the one in the Linux one: using `rm -f`. Should be changed to `del /f` or `erase /f`. ---------- components: Demos and Tools, Windows messages: 270787 nosy: David D, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Freeze: winmakemakefile.py: clean: Linux instead of Windows command 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 Mon Jul 18 16:00:36 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Mon, 18 Jul 2016 20:00:36 +0000 Subject: [New-bugs-announce] [issue27567] Add constants EPOLLRDHUP and EPOLLHUP to module select. Message-ID: <1468872036.69.0.576706331519.issue27567@psf.upfronthosting.co.za> New submission from ???? ?????????: These constants are supported since Linux kernel 2.6.17 ---------- messages: 270788 nosy: mmarkk priority: normal severity: normal status: open title: Add constants EPOLLRDHUP and EPOLLHUP to module select. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 18:30:13 2016 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Mon, 18 Jul 2016 22:30:13 +0000 Subject: [New-bugs-announce] [issue27568] "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts Message-ID: <1468881013.81.0.152859673137.issue27568@psf.upfronthosting.co.za> New submission from R?mi Rampin: https://httpoxy.org/ It is possible to set the HTTP_PROXY in CGI scripts by passing the Proxy header. If the script is a Python script and downloads files, urllib will happily use the attacker-supplied proxy to make requests. This should be mitigated like it is in Perl (since 2001), Ruby, and libraries like curl. See also: bug against python-requests https://github.com/kennethreitz/requests/issues/3422 ---------- components: Library (Lib) messages: 270795 nosy: remram priority: normal severity: normal status: open title: "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI scripts type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 21:47:21 2016 From: report at bugs.python.org (Ricardo Esperanza) Date: Tue, 19 Jul 2016 01:47:21 +0000 Subject: [New-bugs-announce] [issue27569] Windows install problems Message-ID: <1468892841.27.0.521360350751.issue27569@psf.upfronthosting.co.za> New submission from Ricardo Esperanza: Downloaded 3.5.2 package and recived following errors during install also tried with 3.6 version and got same errors Using Win 10 X64 attached complete log [13A0:26B4][2016-07-18T22:40:59]i305: Verified acquired payload: exe_JustForMe at path: C:\Users\Ricardo\AppData\Local\Package Cache\.unverified\exe_JustForMe, moving to: C:\Users\Ricardo\AppData\Local\Package Cache\{33B10015-A9B1-4210-B50A-26C6443979B0}v3.5.2150.0\exe.msi. [13A0:0EE0][2016-07-18T22:40:59]e000: Error 0x80070643: Failed to install MSI package. [13A0:0EE0][2016-07-18T22:40:59]e000: Error 0x80070643: Failed to configure per-user MSI package. [13A0:0EE0][2016-07-18T22:40:59]i319: Applied execute package: core_JustForMe, result: 0x80070643, restart: None [13A0:0EE0][2016-07-18T22:40:59]e000: Error 0x80070643: Failed to execute MSI package. [13A0:0EE0][2016-07-18T22:40:59]i318: Skipped rollback of package: core_JustForMe, action: Uninstall, already: Absent ---------- components: Installation files: Python 3.5.2 (32-bit)_20160718224049.log messages: 270801 nosy: ricardoe priority: normal severity: normal status: open title: Windows install problems versions: Python 3.5 Added file: http://bugs.python.org/file43782/Python 3.5.2 (32-bit)_20160718224049.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 18 22:57:10 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 19 Jul 2016 02:57:10 +0000 Subject: [New-bugs-announce] [issue27570] Avoid memcpy(. . ., NULL, 0) etc calls Message-ID: <1468897030.77.0.552858173381.issue27570@psf.upfronthosting.co.za> New submission from Martin Panter: This patch fixes errors reported by GCC?s undefined behaviour sanitizer about calling functions with a null pointer: ./configure CC="gcc -fsanitize=undefined" Using Issue 22605 as a precedent, I propose to avoid calling memcpy() and memmove() for zero-length copies when there may be a null pointer. ---------- components: Interpreter Core, ctypes files: memcpy-null.patch keywords: patch messages: 270806 nosy: martin.panter priority: normal severity: normal stage: patch review status: open title: Avoid memcpy(. . ., NULL, 0) etc calls type: behavior versions: Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43784/memcpy-null.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 03:03:03 2016 From: report at bugs.python.org (Decorater) Date: Tue, 19 Jul 2016 07:03:03 +0000 Subject: [New-bugs-announce] [issue27571] 3.6 Seems to be ignoring all pyd's installed and compiled by pip Message-ID: <1468911783.53.0.349371581627.issue27571@psf.upfronthosting.co.za> New submission from Decorater: in 3.5 the following would succed: >>>import nacl._sodium None but in 3.6 (I even compiled it for 3.6 specifically) this happens: >>>import nacl._sodium Traceback (most recent call last): import nacl._sodium ImportError: No module named 'nacl._sodium' ---------- messages: 270815 nosy: Decorater priority: normal severity: normal status: open title: 3.6 Seems to be ignoring all pyd's installed and compiled by pip versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 04:56:16 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 19 Jul 2016 08:56:16 +0000 Subject: [New-bugs-announce] [issue27572] Support bytes-like objects when base is given to int() Message-ID: <1468918576.73.0.596747914515.issue27572@psf.upfronthosting.co.za> New submission from Xiang Zhang: Right now, int() supports bytes-like objects when *base* is not given: >>> int(memoryview(b'100')) 100 When *base* is given bytes-like objects are not supported: >>> int(memoryview(b'100'), base=2) Traceback (most recent call last): File "", line 1, in TypeError: int() can't convert non-string with explicit base Is there any obvious reason not to support it when *base* is given? I suggest add it. ---------- components: Interpreter Core files: bytes_like_support_to_int.patch keywords: patch messages: 270818 nosy: martin.panter, xiang.zhang priority: normal severity: normal status: open title: Support bytes-like objects when base is given to int() versions: Python 3.6 Added file: http://bugs.python.org/file43789/bytes_like_support_to_int.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 08:55:40 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 19 Jul 2016 12:55:40 +0000 Subject: [New-bugs-announce] [issue27573] code.interact() should print an exit message Message-ID: <1468932940.76.0.523388198835.issue27573@psf.upfronthosting.co.za> New submission from Steven D'Aprano: Way too often I've lost track of whether I'm in the code.interact() REPL or the original REPL, or hit Ctrl-D once too often, and accidentally quit the real REPL. It is easy to lose track, since the real and imitation REPL both use the same prompts. It would be useful if code.interact() and the InteractiveConsole printed a message when they exited. ---------- components: Library (Lib) files: code.patch keywords: patch messages: 270822 nosy: steven.daprano priority: normal severity: normal status: open title: code.interact() should print an exit message type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43791/code.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 12:03:55 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Jul 2016 16:03:55 +0000 Subject: [New-bugs-announce] [issue27574] Faster parsing keyword arguments Message-ID: <1468944235.85.0.107735525995.issue27574@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Parsing keyword arguments is much more slow than parsing positional arguments. Parsing time can be larger that useful execution time. $ ./python -m timeit "b'a:b:c'.split(b':', 1)" 1000000 loops, best of 3: 0.638 usec per loop $ ./python -m timeit "b'a:b:c'.split(b':', maxsplit=1)" 1000000 loops, best of 3: 1.64 usec per loop The main culprit is that Python strings are created for every keyword name on every call. Proposed patch adds alternative API that caches keyword names as Python strings in special object. Argument Clinic is changed to use this API in generated file. An effect of the optimization: $ ./python -m timeit "b'a:b:c'.split(b':', maxsplit=1)" 1000000 loops, best of 3: 0.826 usec per loop Invocations of PyArg_ParseTupleAndKeywords() in non-generated code are kept, since API is not stable yet. Later I'm going to cache parsed format strings and speed up parsing positional arguments too. ---------- components: Interpreter Core files: faster_keyword_args_parse.patch keywords: patch messages: 270832 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Faster parsing keyword arguments type: performance versions: Python 3.6 Added file: http://bugs.python.org/file43794/faster_keyword_args_parse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 19 13:51:47 2016 From: report at bugs.python.org (David Su) Date: Tue, 19 Jul 2016 17:51:47 +0000 Subject: [New-bugs-announce] [issue27575] dict viewkeys intersection slow for large dicts Message-ID: <1468950707.74.0.640405379684.issue27575@psf.upfronthosting.co.za> New submission from David Su: In dictobject.c, the function dictviews_and performs a very expensive set creation operation on the keys of the self dict object: >From Python 2.7: ... static PyObject* dictviews_and(PyObject* self, PyObject *other) { PyObject *result = PySet_New(self); ... tmp = PyObject_CallMethod(result, "intersection_update", "(O)", other); ... Similar logic can be found in the Python 3 code as well. For large dicts (~10 000 000 keys), it takes a significant amount of time to copy the keys into a new set, and also wastes a lot of memory. This issue is amplified when the intersection operation is performed many times. This implementation uses O(len(self)) time and space, while it is expected to use O(min(len(self), len(other)) time and space. Solution 1: Manually copy the keys of the dict into a set, and perform all intersection operations on that set. However, still wastes lots of memory. Solution 2 (Recommended): Port the intersection logic from the set class to the dict view class. ---------- components: Library (Lib) messages: 270836 nosy: David Su2 priority: normal severity: normal status: open title: dict viewkeys intersection slow for large dicts 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 Tue Jul 19 17:01:30 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 19 Jul 2016 21:01:30 +0000 Subject: [New-bugs-announce] [issue27576] An unexpected difference between dict and OrderedDict Message-ID: <1468962090.7.0.636707577928.issue27576@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: Consider the following code: $ cat x.py from collections import OrderedDict class X: def items(self): print('items') return [] def keys(self): print('keys') return [] print(dict(X())) print(OrderedDict(X())) When I run it under python 3.4, I get $ python3.4 x.py keys {} keys OrderedDict() but under python 3.5, I get $ python3.5 x.py keys {} items OrderedDict() Under 3.4 both dict and OrderedDict constructors call the keys() method of the underlying object (and then call __getitem__ repeatedly if keys() returns a non-empty list), but in 3.5 OrderedDict behavior changed and it calls the values() method instead. ---------- keywords: 3.4regression messages: 270842 nosy: belopolsky priority: normal severity: normal status: open title: An unexpected difference between dict and OrderedDict type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 04:17:22 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 20 Jul 2016 08:17:22 +0000 Subject: [New-bugs-announce] [issue27577] tuple and list parameter name conflicts between doc and implementation Message-ID: <1469002642.37.0.996165914529.issue27577@psf.upfronthosting.co.za> New submission from Xiang Zhang: For tuple and list, their signatures are tuple([iterable]) and list([iterable]). But actually they support keyword argument *sequence*. The parameter names in doc are sometimes just placeholders but sometimes are real parameter names. So I suggest make the implementation and doc more compliant. One method is make the parameter name in implementation *iterable*. The other is totally suppress keyword argument since it is never documented. This is not a necessary change but I think the compliment is not a bad idea. ---------- components: Interpreter Core messages: 270858 nosy: serhiy.storchaka, xiang.zhang priority: normal severity: normal status: open title: tuple and list parameter name conflicts between doc and implementation type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 08:05:58 2016 From: report at bugs.python.org (Alexander Todorov) Date: Wed, 20 Jul 2016 12:05:58 +0000 Subject: [New-bugs-announce] [issue27578] inspect.findsource raises exception with empty __init__.py Message-ID: <1469016358.37.0.125453636257.issue27578@psf.upfronthosting.co.za> New submission from Alexander Todorov: $ python2 Python 2.7.5 (default, Oct 11 2015, 17:47:16) [GCC 4.8.3 20140911 (Red Hat 4.8.3-9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import inspect >>> from pykickstart import handlers >>> inspect.getsource(handlers) Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python2.7/inspect.py", line 701, in getsource lines, lnum = getsourcelines(object) File "/usr/lib64/python2.7/inspect.py", line 690, in getsourcelines lines, lnum = findsource(object) File "/usr/lib64/python2.7/inspect.py", line 538, in findsource raise IOError('could not get source code') IOError: could not get source code >>> There is a `pykickstart/handlers/__init__.py` file which is empty and the above import works fine as you can see. However `inspect.findsource` raises an exception. The same problem exists in Python 3.5 as well. The error comes from here: 532 module = getmodule(object, file) 533 if module: 534 lines = linecache.getlines(file, module.__dict__) 535 else: 536 lines = linecache.getlines(file) 537 if not lines: 538 raise IOError('could not get source code') At this point `lines` is an empty list and we raise the exception. I'm hitting this problem when using a mutation testing tool that relies on getsource (which calls findsource). One possible workaround is to add a comment in the __init__.py file and everything seems to be working then. Another one is to patch the tool I'm using to take into account empty __init__.py files. ---------- components: Library (Lib) messages: 270867 nosy: Alexander Todorov priority: normal severity: normal status: open title: inspect.findsource raises exception with empty __init__.py type: behavior versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 20 10:42:29 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 20 Jul 2016 14:42:29 +0000 Subject: [New-bugs-announce] [issue27579] Add a tutorial for AsyncIO in the documentation Message-ID: <1469025749.21.0.829921979586.issue27579@psf.upfronthosting.co.za> New submission from St?phane Wirtel: The documentation of AsyncIO is well written for a developer, but it's a reference. We have the description of all the methods, classes, etc... But we want to learn to develop with AsyncIO, it's difficult, because there is no many examples in this reference and we have to look for some examples on Internet. Could we add a AsyncIO tutorial|cookbook|howto ? because we have a "Logging Cookbook" but not a "AsyncIO 101". Thank you Stephane ---------- assignee: docs at python components: Documentation messages: 270876 nosy: asvetlov, docs at python, haypo, matrixise, yselivanov priority: normal severity: normal status: open title: Add a tutorial for AsyncIO in the documentation versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 01:02:48 2016 From: report at bugs.python.org (Bobby Ocean) Date: Thu, 21 Jul 2016 05:02:48 +0000 Subject: [New-bugs-announce] [issue27580] CSV Null Byte Error Message-ID: <1469077368.13.0.160030895608.issue27580@psf.upfronthosting.co.za> New submission from Bobby Ocean: I think this has been asked before, but it has been awhile and I think needs to be re-addressed. Why doesn't the CSV module handle NULL bytes? Let me do some examples, ascii = [chr(n) for n in range(256)] #No errors print(ascii) #No errors print(dict(zip(ascii,ascii))) #No errors open('temp','r').writelines(ascii) #No errors f=open('temp','r') for line in f: print(line) #No errors f.close() Python hsndles every ascii chr, DEL, ESC, RETURN, etc. It displays those characters, uses them as keys or values, etc. But now try, import csv data = csv.DictReader(ascii) for line in data: print(line) #NULL Byte Error But we can quick fix this easily, ascii.pop(0) data = csv.DictReader(ascii) for line in data: print(line) #No Errors Doesn't it seem odd that we allow the use of every chr as keys, vslues, prints, etc. but then we hold a special exception for using the csv module and yhat special exception is not the ESC or DEL or any other non-printable chr, the exception is for the NULL? ---------- components: Extension Modules messages: 270908 nosy: bobbyocean priority: normal severity: normal status: open title: CSV Null Byte Error type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 01:36:48 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 21 Jul 2016 05:36:48 +0000 Subject: [New-bugs-announce] [issue27581] Fix overflow check in PySequence_Tuple Message-ID: <1469079408.21.0.622161481276.issue27581@psf.upfronthosting.co.za> New submission from Xiang Zhang: Overflow check in PySequence_Tuple relies on undefined behaviour, fix it. ---------- components: Interpreter Core files: overflow_check_in_PySequence_Tuple.patch keywords: patch messages: 270909 nosy: martin.panter, serhiy.storchaka, xiang.zhang priority: normal severity: normal status: open title: Fix overflow check in PySequence_Tuple type: enhancement versions: Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43806/overflow_check_in_PySequence_Tuple.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 07:54:14 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 21 Jul 2016 11:54:14 +0000 Subject: [New-bugs-announce] [issue27582] Mispositioned SyntaxError caret for unknown code points Message-ID: <1469102054.52.0.839726574023.issue27582@psf.upfronthosting.co.za> New submission from Nick Coghlan: Reporting by Rustom Mody on python-ideas, the SyntaxError caret is confusingly mispositioned when an invalid Unicode codepoint appears as part of a larger sequence of invalid codepoints and/or valid identifier characters: >>> varname = ?d?a?t?apoint File "", line 1 varname = ?d?a?t?apoint ^ SyntaxError: invalid character in identifier >>> varname = ?d?a?t?apoint.evidence File "", line 1 varname = ?d?a?t?apoint.evidence ^ SyntaxError: invalid character in identifier >>> varname = ?d?a?t?apoint[evidence] File "", line 1 varname = ?d?a?t?apoint[evidence] ^ SyntaxError: invalid character in identifier >>> varname = ?d?a?t?apoint(evidence) File "", line 1 varname = ?d?a?t?apoint(evidence) ^ SyntaxError: invalid character in identifier If the invalid character is a non-identifiers ASCII character, the error message loses the trailing "in identifier" phrase and points to the correct place: >>> varname = $d$a$t$apoint File "", line 1 varname = $d$a$t$apoint ^ SyntaxError: invalid syntax >>> varname = d$a$t$apoint File "", line 1 varname = d$a$t$apoint ^ SyntaxError: invalid syntax >>> varname = ^d$a$t$apoint File "", line 1 varname = ^d$a$t$apoint ^ SyntaxError: invalid syntax >>> varname = !d$a$t$apoint File "", line 1 varname = !d$a$t$apoint ^ SyntaxError: invalid syntax >>> varname = `d$a$t$apoint File "", line 1 varname = `d$a$t$apoint ^ SyntaxError: invalid syntax ---------- messages: 270914 nosy: ncoghlan priority: normal severity: normal stage: needs patch status: open title: Mispositioned SyntaxError caret for unknown code points type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 08:54:13 2016 From: report at bugs.python.org (rk) Date: Thu, 21 Jul 2016 12:54:13 +0000 Subject: [New-bugs-announce] [issue27583] configparser: modifying default_section at runtime Message-ID: <1469105653.63.0.572086425799.issue27583@psf.upfronthosting.co.za> New submission from rk: Modifying "default_section" in the configparser at runtime does not behave as described. The documentation says about default_section: When default_section is given, it specifies the name for the special section holding default values for other sections and interpolation purposes (normally named "DEFAULT"). This value can be retrieved and changed on runtime using the default_section instance attribute. [https://docs.python.org/3/library/configparser.html] So, if I modify default_section at runtime, the default values for other sections should then come from the new default_section. But this is not the case. Instead, the default-values still come from self._default, which was set by self._read. So, this is either a bug in the library or a bug in the documentation. I've attached a testcase. ---------- components: Library (Lib) files: bug_configparser_default_section.py messages: 270918 nosy: rk priority: normal severity: normal status: open title: configparser: modifying default_section at runtime 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/file43808/bug_configparser_default_section.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 11:36:30 2016 From: report at bugs.python.org (Cathy Avery) Date: Thu, 21 Jul 2016 15:36:30 +0000 Subject: [New-bugs-announce] [issue27584] New addition of vSockets to the python socket module Message-ID: <1469115390.74.0.838831983223.issue27584@psf.upfronthosting.co.za> New submission from Cathy Avery: I have added AF_VSOCK support to python's 3.6 socket module ( socketmodule.c socketmodule.h cloned from https://hg.python.org/cpython ). The implementation is very similar to AF_NETLINK. AF_VSOCK requires the VMware-specific VMCI transport which is currently upstream or the virtio-vsock drivers developed by Stefan Hajnoczi at Red Hat. The virtio-vsock drivers are not upstream yet but more information with source and build instructions can be found at http://qemu-project.org/Features/VirtioVsock. More information on vSocket programming can be found at https://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/ws9_esx60_vmci_sockets.pdf The VMCI transport supports SOCK_DGRAM and SOCK_STREAM on both Linux and Windows. Virtio-vsock currently supports SOCK_STREAM only on Linux. My python addition supports SOCK_STREAM and SOCK_DGRAM calls on Linux only. I have tested my implementation on both driver sets on Linux. Attached is a diff file so you can see which files I've modified. These include a new configure.ac. I have already tested the new file generation by running autoreconf. Also included in the patch is an updated socket.rst file however I could not get the final html page to be double spaced. ---------- components: Library (Lib) files: vsocket.patch hgrepos: 349 keywords: patch messages: 270935 nosy: Cathy Avery, gregory.p.smith priority: normal severity: normal status: open title: New addition of vSockets to the python socket module type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43816/vsocket.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 13:06:41 2016 From: report at bugs.python.org (sss) Date: Thu, 21 Jul 2016 17:06:41 +0000 Subject: [New-bugs-announce] [issue27585] asyncio.Lock deadlock after cancellation Message-ID: <1469120801.4.0.62510822161.issue27585@psf.upfronthosting.co.za> New submission from sss: The lock.py file prints DEADLOCK HERE _locked: False _waiters: deque([]) I think the problem is that acquire() will block because of the cancelled future in _waiters, but release() has already ran so no one will wake it up. ---------- components: asyncio files: lock.py messages: 270944 nosy: gvanrossum, haypo, sss, yselivanov priority: normal severity: normal status: open title: asyncio.Lock deadlock after cancellation versions: Python 3.5 Added file: http://bugs.python.org/file43820/lock.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 21 17:03:42 2016 From: report at bugs.python.org (Bruce Eckel) Date: Thu, 21 Jul 2016 21:03:42 +0000 Subject: [New-bugs-announce] [issue27586] Is this a regular expression library bug? Message-ID: <1469135022.02.0.0194014811902.issue27586@psf.upfronthosting.co.za> New submission from Bruce Eckel: This looks suspicious to me, like it could be a library bug, but before chasing it down I was hoping someone might be able to tell me whether I might be on to something: Traceback (most recent call last): File "update_extracted_example_output.py", line 22, in new_javatext = find_output.sub(new_output, javatext) File "C:\Python35\lib\re.py", line 325, in _subx template = _compile_repl(template, pattern) File "C:\Python35\lib\re.py", line 312, in _compile_repl p = sre_parse.parse_template(repl, pattern) File "C:\Python35\lib\sre_parse.py", line 872, in parse_template raise s.error("missing <") sre_constants.error: missing < at position 100 (line 4, column 41) ---------- components: Library (Lib) messages: 270956 nosy: Bruce Eckel priority: normal severity: normal status: open title: Is this a regular expression library bug? type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 03:22:12 2016 From: report at bugs.python.org (Pavel Belikov) Date: Fri, 22 Jul 2016 07:22:12 +0000 Subject: [New-bugs-announce] [issue27587] Issues, reported by PVS-Studio static analyzer Message-ID: <1469172132.31.0.293406285451.issue27587@psf.upfronthosting.co.za> New submission from Pavel Belikov: To demonstrate the capabilities of our analyzer, we regularly perform analysis of open source projects. We had recently checked the CPython project. Here is the link to the article about it: http://www.viva64.com/en/b/0414/ Official page of the analyzer: http://www.viva64.com/en/pvs-studio/ If you have any questions, or if you are interested in the evaluation of our static analyzer or in any other source code quality control services that our company provides, please contact us at support at viva64.com. ---------- messages: 270974 nosy: pavel-belikov priority: normal severity: normal status: open title: Issues, reported by PVS-Studio static analyzer type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 05:50:51 2016 From: report at bugs.python.org (Gareth Rees) Date: Fri, 22 Jul 2016 09:50:51 +0000 Subject: [New-bugs-announce] [issue27588] Type objects are hashable and comparable for equality but this is not documented Message-ID: <1469181051.15.0.925508125369.issue27588@psf.upfronthosting.co.za> New submission from Gareth Rees: The type objects constructed by the metaclasses in the typing module are hashable and comparable for equality: >>> from typing import * >>> {Mapping[str, int], Mapping[int, str]} {typing.Mapping[int, str], typing.Mapping[str, int]} >>> Union[str, int, float] == Union[float, int, str] True >>> List[int] == List[float] False but this is not clearly documented in the documentation for the typing module (there are a handful of examples using equality, but it's not explicit that these are runnable). It would be nice if there were explicit documentation for these properties of type objects. ---------- assignee: docs at python components: Documentation messages: 270981 nosy: Gareth.Rees, docs at python priority: normal severity: normal status: open title: Type objects are hashable and comparable for equality but this is not documented type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 06:08:25 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 22 Jul 2016 10:08:25 +0000 Subject: [New-bugs-announce] [issue27589] asyncio doc: issue in as_completed() doc Message-ID: <1469182105.52.0.303554063448.issue27589@psf.upfronthosting.co.za> New submission from STINNER Victor: Remark on as_completed() doc by Hynek. https://docs.python.org/dev/library/asyncio-task.html#asyncio.as_completed Futures are yielded in an unexpected order: as soon as a future completes. ---------- assignee: docs at python components: Documentation, asyncio messages: 270982 nosy: docs at python, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio doc: issue in as_completed() doc versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 11:11:06 2016 From: report at bugs.python.org (Yujie Chen) Date: Fri, 22 Jul 2016 15:11:06 +0000 Subject: [New-bugs-announce] [issue27590] tarfile module next() method hides exceptions Message-ID: <1469200266.16.0.443973453456.issue27590@psf.upfronthosting.co.za> New submission from Yujie Chen: I have seen a similar ticket, however that was opened 2 years ago and has nothing more than a brief description. So I opened this new one here, hoping to get some answers. tarfile.TarFile object is iterable and has a next() method. next() will parse the header and save parsed info. During parsing, a lot of checks are done, to make sure the header is valid. And if there is something wrong with the header, exceptions will be thrown. next() catches a lot of them but not reraise what it catches in all cases. I have a tgz file, one of the headers is corrupted with a wrong checksum section. thus during parsing, InvalidHeaderError was thrown. next() catches that but hide it silently. From source code (https://hg.python.org/cpython/file/2.7/Lib/tarfile.py#l2335), we can see that InvalidHeaderError will ONLY be raised if it happens in the beginning of the tar file. Actually, a lot of exceptions are hidden by tarfile module. tarfile module simply thinks these exceptions mark the end of tarball. Why does tarfile module hide so many exceptions? or in other words, why does tarfile treat these exceptions as the end marker of tarball but not errors? Is it because of this from GNU doc: "At the end of the archive file there are two 512-byte blocks filled with binary zeros as an end-of-file marker. A reasonable system should write such end-of-file marker at the end of an archive, but must not assume that such a block exists when reading an archive."? Thanks! ---------- components: Library (Lib) messages: 270990 nosy: JieGhost priority: normal severity: normal status: open title: tarfile module next() method hides exceptions type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 11:12:39 2016 From: report at bugs.python.org (Chris Angelico) Date: Fri, 22 Jul 2016 15:12:39 +0000 Subject: [New-bugs-announce] [issue27591] multiprocessing: Possible uninitialized pointer use in Windows builds Message-ID: <1469200359.36.0.370469252953.issue27591@psf.upfronthosting.co.za> New submission from Chris Angelico: Originally reported (if you can call it "reported") here: http://www.viva64.com/en/b/0414/ AFAICT, this is an easy and inconsequential fix. ---------- files: uninitialized-pointer.patch keywords: patch messages: 270991 nosy: Rosuav priority: normal severity: normal status: open title: multiprocessing: Possible uninitialized pointer use in Windows builds versions: Python 3.6 Added file: http://bugs.python.org/file43832/uninitialized-pointer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 14:02:23 2016 From: report at bugs.python.org (Cristi Fati) Date: Fri, 22 Jul 2016 18:02:23 +0000 Subject: [New-bugs-announce] [issue27592] FIPS_mode() and FIPS_mode_set() functions in Python (ssl) Message-ID: <1469210543.94.0.196720087995.issue27592@psf.upfronthosting.co.za> New submission from Cristi Fati: During last years, the FIPS mode, has become more and more popular, especially in US (probably because it was "promoted" by government institutions). All OpenSSL versions (didn't check 1.0.0 or lower since they're no longer supported), have the "basic FIPS functionality", even if built without openssl-fips module. By "basic FIPS functionality", I mean the 2 functions: - `int FIPS_mode(void)` - used to get the current FIPS mode (for non FIPS openssl, it simply returns 0) - `int FIPS_mode_set(int r)` - used to set the current FIPS mode in the currently loaded libcrypto/libeay32 (for non FIPS openssl it sets the openssl error: "error:0F06D065:common libcrypto routines:FIPS_mode_set:fips mode not supported") The goal of this patch is to add the 2 functions in Python (3.4.4 source tarball) - ssl (and _ssl) module - in order to be able to control FIPS mode from within a Python process (I am aware that some platforms allow setting FIPS at a global level, but this offers more granularity). The patch is simple, for the getter it simply returns the OpenSSL function value, while for the setter it doesn't return anything but throws an exception if some error occurs. Note0 (about how do I set the error): `_setSSLError(ERR_error_string(ERR_get_error(), NULL) , 0, __FILE__, __LINE__);` as opposed to the regular way: `_setSSLError(NULL, 0, __FILE__, __LINE__);`. I didn't use the whole make_ssl_data.py mechanism because: - 1 - it binds against the OpenSSL version used at compile time - 1.1 - on Ux (where Python modules are dynamically linked to OpenSSL), if compiling against one OpenSSL version and at runtime another (newer) version which defines new functionality (and new error codes) is present, if one of those newer errors is encountered, the error message won't be as complete: "ssl.SSLError: fips mode already set (_ssl.c:3763)" as opposed to "ssl.SSLError: error:2D078072:FIPS routines:FIPS_module_mode_set:fips mode already set (_ssl.c:3763)" - 1.2 - on Win (where Python modules are statically linked to OpenSSL), there won't be such a problem. However, regarding static linking (this is not related to this post), this is not a scalable solution (now if only _ssl and _hashlib link to OpenSSL, it's __sort of__ OK, but if another one, or more will be added it won't be), so dynamic linking should be used, although that comes with its problems. 2 possible ways to solve them: - 1.2.1 - simply dynamic link to OpenSSL and at runtime it will fail importing the modules; this will happen a lot since (as opposed to Ux), I think that there's a 90%+ chance that no OpenSSL is installed on a Win machine - 1.2.2 - dynamic link to OpenSSL and also redistribute the OpenSSL dlls (although I didn't check what this would mean from licensing PoV). This would also raise the problem of precedence: which dlls should be used by default if an OpenSSL version is installed on the machine. - 2 - It is simpler (here I might be missing something). To me it seems cleaner to delegate the job to (runtime) OpenSSL instead of make_ssl_data.py and the logic from `fill_and_set_sslerror` (which could be removed in the future, I'd say). Note1: The whole thing could also be applied to hashlib (simply copy the changes from ssl.py to hashlib.py - to have as less duplicate code as possible), but since due to hashlib caching, changing the FIPS mode on the fly won't be reflected in the possibility/impossibility of using a hash (e.g. `md5`), I figured that it doesn't worth the effort. As a workaround, for someone who really needs to set it, they can do it from ssl. ---------- files: Python-3.4.4-ssl_fips.patch keywords: patch messages: 271006 nosy: CristiFati priority: normal severity: normal status: open title: FIPS_mode() and FIPS_mode_set() functions in Python (ssl) type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file43833/Python-3.4.4-ssl_fips.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 17:43:25 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 22 Jul 2016 21:43:25 +0000 Subject: [New-bugs-announce] [issue27593] Deprecate sys._mercurial and create sys._git Message-ID: <1469223805.51.0.614192375682.issue27593@psf.upfronthosting.co.za> New submission from Brett Cannon: This is part of the GitHub migration. And by "deprecate" sys._mercurial I mean fill it with default values (https://www.python.org/dev/peps/pep-0512/#deprecate-sys-mercurial). ---------- components: Library (Lib) messages: 271037 nosy: brett.cannon priority: normal severity: normal status: open title: Deprecate sys._mercurial and create sys._git _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 18:32:06 2016 From: report at bugs.python.org (ap) Date: Fri, 22 Jul 2016 22:32:06 +0000 Subject: [New-bugs-announce] [issue27594] Assertion failure when running "test_ast" tests with coverage. Message-ID: <1469226726.58.0.53789092151.issue27594@psf.upfronthosting.co.za> New submission from ap: This is with a build of the default branch on OS X 10.11.6: $ hg identify fada654c5f72 tip $ ./python.exe --version Python 3.6.0a3+ $ The "test_ast" tests appear to run fine without coverage tracking enabled: $ ./python.exe -m test test_ast Run tests sequentially 0:00:00 [1/1] test_ast 1 test OK. Total duration: 0:00:07 $ But when coverage tracking is enabled, an assertion fails: $ ./python.exe -m test --coverage -D`pwd`/coverage_data test_ast Run tests sequentially 0:00:00 [1/1] test_ast Assertion failed: (line > 0), function _PyCode_CheckLineNumber, file Objects/codeobject.c, line 717. Fatal Python error: Aborted Current thread 0x00007fff76279000 (most recent call first): File "test", line 0 in File "/python-dev/cpython/Lib/test/test_ast.py", line 559 in test_level_as_none File "/python-dev/cpython/Lib/unittest/case.py", line 600 in run File "/python-dev/cpython/Lib/unittest/case.py", line 648 in __call__ File "/python-dev/cpython/Lib/unittest/suite.py", line 122 in run File "/python-dev/cpython/Lib/unittest/suite.py", line 84 in __call__ File "/python-dev/cpython/Lib/unittest/suite.py", line 122 in run File "/python-dev/cpython/Lib/unittest/suite.py", line 84 in __call__ File "/python-dev/cpython/Lib/unittest/suite.py", line 122 in run File "/python-dev/cpython/Lib/unittest/suite.py", line 84 in __call__ File "/python-dev/cpython/Lib/test/support/__init__.py", line 1709 in run File "/python-dev/cpython/Lib/test/support/__init__.py", line 1810 in _run_suite File "/python-dev/cpython/Lib/test/support/__init__.py", line 1844 in run_unittest File "/python-dev/cpython/Lib/test/libregrtest/runtest.py", line 179 in test_runner File "/python-dev/cpython/Lib/test/libregrtest/runtest.py", line 180 in runtest_inner File "/python-dev/cpython/Lib/test/libregrtest/runtest.py", line 144 in runtest File "", line 1 in File "/python-dev/cpython/Lib/trace.py", line 469 in runctx File "/python-dev/cpython/Lib/test/libregrtest/main.py", line 330 in run_tests_sequential File "/python-dev/cpython/Lib/test/libregrtest/main.py", line 406 in run_tests File "/python-dev/cpython/Lib/test/libregrtest/main.py", line 466 in _main File "/python-dev/cpython/Lib/test/libregrtest/main.py", line 446 in main File "/python-dev/cpython/Lib/test/libregrtest/main.py", line 508 in main File "/python-dev/cpython/Lib/test/__main__.py", line 2 in File "/python-dev/cpython/Lib/runpy.py", line 85 in _run_code File "/python-dev/cpython/Lib/runpy.py", line 184 in _run_module_as_main Abort trap: 6 $ ---------- components: Tests messages: 271038 nosy: ap priority: normal severity: normal status: open title: Assertion failure when running "test_ast" tests with coverage. versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 22 18:52:34 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 22 Jul 2016 22:52:34 +0000 Subject: [New-bugs-announce] [issue27595] Document PEP 495 (Local Time Disambiguation) features Message-ID: <1469227954.48.0.374414498519.issue27595@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: PEP 495 has been implemented in issue 24773. This issue is created to track the necessary changes to the datetime module documentation. ---------- assignee: belopolsky components: Documentation messages: 271041 nosy: akira, belopolsky, haypo, stub, tim.peters priority: normal severity: normal stage: needs patch status: open title: Document PEP 495 (Local Time Disambiguation) features type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 06:49:43 2016 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 23 Jul 2016 10:49:43 +0000 Subject: [New-bugs-announce] [issue27596] Build failure with Xcode 8 beta on OSX 10.11 Message-ID: <1469270983.6.0.702583698233.issue27596@psf.upfronthosting.co.za> New submission from Ronald Oussoren: I just noticed that building the Xcode 8 beta 2 on OSX 10.11 results in a link failure of the python binary. Based on a quick glance at the error (before switching back to Xcode 7): 1) macOS 10.12 appears to have a getentropy function that's detected by the configure script. 2) For some reason the build environment for configure and the actual build are different resulting in the link error. Even with the link failure fixed the build will fail because getentropy isn't present on 10.11 and hence the binary won't work on 10.11. IMHO it would be worthwhile to at least create a patch that makes it possible to use Xcode 8 for building on OSX 10.11, and better yet deploy on older OSX releases. Based on the invasiveness of such a patch we could discuss if the patch would be acceptable for merging. ---------- assignee: ronaldoussoren components: Macintosh messages: 271069 nosy: ned.deily, ronaldoussoren priority: low severity: normal stage: needs patch status: open title: Build failure with Xcode 8 beta on OSX 10.11 type: compile error versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 06:58:10 2016 From: report at bugs.python.org (Ram Rachum) Date: Sat, 23 Jul 2016 10:58:10 +0000 Subject: [New-bugs-announce] [issue27597] Add usage examples for TracebackException, StackSummary and FrameSummary Message-ID: <1469271490.04.0.794512221992.issue27597@psf.upfronthosting.co.za> New submission from Ram Rachum: I saw these new interesting classes in the `traceback` docs, but if I were shown an example of how they are used, I might get inspired to use them in my own code. ---------- assignee: docs at python components: Documentation messages: 271072 nosy: cool-RR, docs at python priority: normal severity: normal status: open title: Add usage examples for TracebackException, StackSummary and FrameSummary type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 11:46:49 2016 From: report at bugs.python.org (Brett Cannon) Date: Sat, 23 Jul 2016 15:46:49 +0000 Subject: [New-bugs-announce] [issue27598] Add SizedIterable to collections.abc and typing Message-ID: <1469288809.56.0.543825422436.issue27598@psf.upfronthosting.co.za> New submission from Brett Cannon: See the discussion on python-ideas entitled "An ABC representing "Iterable, Sized, Container"". ---------- components: Library (Lib) messages: 271088 nosy: brett.cannon, gvanrossum priority: normal severity: normal stage: test needed status: open title: Add SizedIterable to collections.abc and typing versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 12:31:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Jul 2016 16:31:32 +0000 Subject: [New-bugs-announce] [issue27599] Buffer overrun in binascii Message-ID: <1469291492.89.0.37008226611.issue27599@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: There is reading one byte past the end of the input buffer in binascii.b2a_qp(). Following example shows the behavior difference depending on the value of this byte: >>> binascii.b2a_qp(memoryview(b'..')[:-1]) b'.' >>> binascii.b2a_qp(bytes(memoryview(b'..')[:-1])) b'=2E' In rare cases (memoryview of mmap object or custom buffer) this can cause a segfault. Maybe there are similar issues with other binascii functions (not checked). ---------- components: Extension Modules messages: 271092 nosy: serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Buffer overrun in binascii type: behavior versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 12:51:08 2016 From: report at bugs.python.org (Thanatas Pongpanotkorn) Date: Sat, 23 Jul 2016 16:51:08 +0000 Subject: [New-bugs-announce] [issue27600] None Message-ID: <1469292668.75.0.484494556791.issue27600@psf.upfronthosting.co.za> Changes by Thanatas Pongpanotkorn : ---------- hgrepos: 350 nosy: xaxadmin priority: normal severity: normal status: open title: None _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 14:17:52 2016 From: report at bugs.python.org (Aleksandr Koshkin) Date: Sat, 23 Jul 2016 18:17:52 +0000 Subject: [New-bugs-announce] [issue27601] Minor inaccuracy in hash documentation Message-ID: <1469297872.54.0.246840894647.issue27601@psf.upfronthosting.co.za> New submission from Aleksandr Koshkin: https://docs.python.org/3.6/library/stdtypes.html#hashing-of-numeric-types Look at semantics example for hash_complex function. The variable 'hash' is clearly misused - it is not defined or refers to builtin function 'hash'. Either way the example is incorrect. ---------- assignee: docs at python components: Documentation messages: 271097 nosy: docs at python, magniff priority: normal severity: normal status: open title: Minor inaccuracy in hash documentation versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 16:41:39 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Jul 2016 20:41:39 +0000 Subject: [New-bugs-announce] [issue27602] Enable py launcher to launch repository Python. Message-ID: <1469306499.45.0.411476180863.issue27602@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Running a repository build by typing a path such as F:\Python\dev\36\PCbuild\win32\python_d.exe is tedious and error prone and I have to remember to omit '\win32' for 2.7 and it takes up much of a command line. I would like to be able to run something like py -register 3.6r # 'r' for repository, or possibly '+' and subsequently have py -3.6r launch the locally compiled but un-installed binary. Possible? I did not find 'py launcher' in Expert's Index or Components, so selected you two from memory and 'Windows'. Please modify Components and Nosy as appropriate. I have an impression that there is a launcher version for Mac but know nothing about it. ---------- components: Windows messages: 271111 nosy: paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware priority: normal severity: normal stage: test needed status: open title: Enable py launcher to launch repository Python. type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 23 23:59:59 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 24 Jul 2016 03:59:59 +0000 Subject: [New-bugs-announce] [issue27603] Migrate IDLE context menu items to shell extension Message-ID: <1469332799.74.0.70339682021.issue27603@psf.upfronthosting.co.za> New submission from Steve Dower: Currently (on Windows) we register a set of subcommands in order to display an expanding list of versions of IDLE when users right-click a .py file. With issue27469, a proper shell extension was added, which means we can now use IContextMenu to implement the menu rather than fixed registry keys. This would allow us to detect all installed versions of IDLE and present them without having to register new keys (i.e. forwards and backwards compatibility). ---------- assignee: terry.reedy components: IDLE, Windows messages: 271123 nosy: paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware priority: low severity: normal stage: needs patch status: open title: Migrate IDLE context menu items to shell extension type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 05:46:21 2016 From: report at bugs.python.org (Ram Rachum) Date: Sun, 24 Jul 2016 09:46:21 +0000 Subject: [New-bugs-announce] [issue27604] More details about `-O` flag Message-ID: <1469353581.38.0.811049911305.issue27604@psf.upfronthosting.co.za> New submission from Ram Rachum: I wanted to ensure that the `-O` flag doesn't really do anything more than remove assert statement and make `__debug__` equal `False`. But the documentation for `-O` doesn't cover it: https://docs.python.org/3/using/cmdline.html#cmdoption-O https://docs.python.org/3/using/cmdline.html#envvar-PYTHONOPTIMIZE It just says "basic optimizations". Are there any other optimizations except the two I mentioned? ---------- assignee: docs at python components: Documentation messages: 271142 nosy: cool-RR, docs at python priority: normal severity: normal status: open title: More details about `-O` flag type: enhancement versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 08:13:15 2016 From: report at bugs.python.org (Vasiliy Faronov) Date: Sun, 24 Jul 2016 12:13:15 +0000 Subject: [New-bugs-announce] [issue27605] Inconsistent calls to __eq__ from built-in __contains__ Message-ID: <1469362395.06.0.246923750082.issue27605@psf.upfronthosting.co.za> New submission from Vasiliy Faronov: Consider the attached example program. I expect it to run successfully, because the Python 3 language reference says [1]: > For container types such as list, tuple, set, frozenset, dict, or collections.deque, the expression `x in y` is equivalent to `any(x is e or x == e for e in y)`. and [2]: > `x==y` calls `x.__eq__(y)` Instead, under Python 3.5.2, the program crashes with an assertion error, because `dict.__contains__` calls `Bar.__eq__` instead of `Foo.__eq__`. The same happens if you replace the dict with a set or a frozenset. But if you replace it with a list or a tuple, the behavior is as documented. This seems to me like a bug in either the implementation or the documentation. The language reference clearly says [3] that equality should be symmetric "if possible", but is not required to be, and indeed that is hard to guarantee when different classes are involved. [1] https://docs.python.org/3/reference/expressions.html#membership-test-details [2] https://docs.python.org/3/reference/datamodel.html#object.__eq__ [3] https://docs.python.org/3/reference/expressions.html#value-comparisons ---------- files: contains_eq.py messages: 271145 nosy: vfaronov priority: normal severity: normal status: open title: Inconsistent calls to __eq__ from built-in __contains__ type: behavior Added file: http://bugs.python.org/file43857/contains_eq.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 08:27:43 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 24 Jul 2016 12:27:43 +0000 Subject: [New-bugs-announce] [issue27606] Android cross-built for armv5te with clang and '-mthumb' crashes with SIGSEGV or SIGILL Message-ID: <1469363263.55.0.186080490257.issue27606@psf.upfronthosting.co.za> New submission from Xavier de Gaye: Android ndk version r11c. The crash happens very early on python startup. The SIGILL occurs when python is built 'with-pydebug'. Python runs fine on the armv5te emulator when built with clang without '-mthumb'. Python runs fine on the armv5te emulator when built with gcc 4.9 with or without '-mthumb'. Attaching the strace and logcat output for each type of build. The backtrace when python is built 'with-pydebug' (but logcat.txt says that the SIGSEGV occurs at PyUnicode_DecodeUTF8Stateful when not built 'with-pydebug'): Program received signal SIGILL, Illegal instruction. 0xb6d77e0a in r_object (p=0xbed89588) at Python/marshal.c:1340 1340 idx = r_ref_reserve(flag, p); (gdb) bt #0 0xb6d77e0a in r_object (p=0xbed89588) at Python/marshal.c:1340 #1 0xb6d76ba2 in PyMarshal_ReadObjectFromString (str=0xb6e5f9ae <_Py_M__importlib> "c", len=30106) at Python/marshal.c:1584 #2 0xb6d72506 in PyImport_ImportFrozenModuleObject (name='_frozen_importlib') at Python/import.c:1187 #3 0xb6d727ec in PyImport_ImportFrozenModule (name=0xb6e49ac0 "_frozen_importlib") at Python/import.c:1236 #4 0xb6d7ff96 in import_init (interp=0xb6919068, sysmod=) at Python/pylifecycle.c:243 #5 0xb6d7fc80 in _Py_InitializeEx_Private (install_sigs=1, install_importlib=1) at Python/pylifecycle.c:413 #6 0xb6d80f30 in Py_InitializeEx (install_sigs=1) at Python/pylifecycle.c:450 #7 0xb6d80f3e in Py_Initialize () at Python/pylifecycle.c:456 #8 0xb6daa5e6 in Py_Main (argc=1, argv=0xb6901068) at Modules/main.c:678 #9 0xb6f9b84c in ?? () ---------- components: Cross-Build files: strace.txt messages: 271146 nosy: Alex.Willmer, xdegaye priority: normal severity: normal status: open title: Android cross-built for armv5te with clang and '-mthumb' crashes with SIGSEGV or SIGILL type: crash versions: Python 3.6 Added file: http://bugs.python.org/file43858/strace.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 11:46:17 2016 From: report at bugs.python.org (Sylvia van Os) Date: Sun, 24 Jul 2016 15:46:17 +0000 Subject: [New-bugs-announce] [issue27607] Enums never match if imported from another file Message-ID: <1469375177.67.0.287991264427.issue27607@psf.upfronthosting.co.za> New submission from Sylvia van Os: If main imports another file, and this file imports an Enum class from main, isinstance will return false for Enum variables set in this file, causing the Enums to never match. A proof of concept is added as a zip. I thank Kwpolska for simplifying my initial proof of concept. To test this, unzip both files into the same directory and launch main.py with Python 3. I have succesfully been able to reproduce this issue on Python 3.4.3. >From discussion on IRC with Vgr, PEP 499 may be related to this issue: https://www.python.org/dev/peps/pep-0499/. ---------- components: Interpreter Core files: a040de8b978dcc4c272c0571d456a382-ea6d8fb8acc988a1f060c94070f70a6ed8439069.zip messages: 271164 nosy: Kwpolska, SylvieLorxu priority: normal severity: normal status: open title: Enums never match if imported from another file type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file43867/a040de8b978dcc4c272c0571d456a382-ea6d8fb8acc988a1f060c94070f70a6ed8439069.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 13:37:20 2016 From: report at bugs.python.org (Aleksandr Koshkin) Date: Sun, 24 Jul 2016 17:37:20 +0000 Subject: [New-bugs-announce] [issue27608] Something wrong with str.upper().lower() chain? Message-ID: <1469381840.71.0.0990195629245.issue27608@psf.upfronthosting.co.za> New submission from Aleksandr Koshkin: For some reason >>> '?'.upper().lower() == '?' False ---------- components: Unicode messages: 271174 nosy: ezio.melotti, haypo, magniff priority: normal severity: normal status: open title: Something wrong with str.upper().lower() chain? type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 20:03:08 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 25 Jul 2016 00:03:08 +0000 Subject: [New-bugs-announce] [issue27609] IDLE completions: format, factor, and fix Message-ID: <1469404988.71.0.674184496094.issue27609@psf.upfronthosting.co.za> New submission from Terry J. Reedy: IDLE completions are currently implemented in two files: autocomplete.py and autocomplete_w.py. (Before 3.6, these were AutoComplete.py and AutoCompleteWindow.py.) The first handles 'open' events, decideds whether to open a window, and gathers possible completions. The second open a popup and works with the sorted list of possible completions. There are several tracker issues already. #15786 Code completion problems with mouse and . These lead to freezes on on Mac. Severity: bad; prioriy: high. #16198 Tabbing in string brings up completion when it should not. #17238 Enhance import statement completion. #18766 Add completions for un-imported modules (by importing). #18903 File completions are case sensitive, should not be on Windows. #21261 Complete dictionary keys. #22554 Popup window for names also. #27099 Convert autocomplete to normal feature, along with other 'extensions'. Add delay to current tab. Negative delay should disable auto-popups. #27534 Move objects needed by run to run.py and import from there. There are more that are not on the tracker. Patches may be attached here or to new issues. A. Use PEP8 style. 1.'return None' when there are non-None returns. 2. Docstrings for all functions. B. Merge autocomplete_w into autocomplete. This was anticipated in the renaming. #27534 should be done first if possible, or soon after. C. Refactor. 1 #27534. 2. Put list and scrollbar in Frame? For future single-window IDLE? This might make testing easier. 3. Anything else making tests easier. D. Make completions work for number literals ("1 .") as well a string literals ("'a'."). E?. Make completions work with Entry as well as Multicall wrapping text? Need use case first. Load Modules may need own code. Question: Why does 'dooneevent' appear in 2.x code and not 3.x code? Tests: The currently only for a subset of autocomplete methods. There are none for the buggy window. First, a patch for A.1, return None. ---------- assignee: terry.reedy messages: 271186 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: IDLE completions: format, factor, and fix type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 21:06:05 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 25 Jul 2016 01:06:05 +0000 Subject: [New-bugs-announce] [issue27610] Add PEP 514 metadata to Windows installer Message-ID: <1469408765.5.0.0268555752017.issue27610@psf.upfronthosting.co.za> New submission from Steve Dower: Now PEP 514 is accepted, we need to set more information when installing Python 3.6. ---------- assignee: steve.dower components: Windows messages: 271197 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Add PEP 514 metadata to Windows installer type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 24 22:07:16 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 25 Jul 2016 02:07:16 +0000 Subject: [New-bugs-announce] [issue27611] test_tix cannot import _default_root after test_idle Message-ID: <1469412436.77.0.964864196793.issue27611@psf.upfronthosting.co.za> New submission from Martin Panter: $ ./python -m unittest -v test.test_{idle,tix} . . . test_tix (unittest.loader._FailedTest) ... ERROR ====================================================================== ERROR: test_tix (unittest.loader._FailedTest) ---------------------------------------------------------------------- ImportError: Failed to import test module: test_tix Traceback (most recent call last): File "/media/disk/home/proj/python/cpython/Lib/unittest/loader.py", line 153, in loadTestsFromName module = __import__(module_name) File "/media/disk/home/proj/python/cpython/Lib/test/test_tix.py", line 11, in from tkinter import tix, TclError File "/media/disk/home/proj/python/cpython/Lib/tkinter/tix.py", line 30, in from tkinter import _cnfmerge, _default_root ImportError: cannot import name '_default_root' Without test_idle, test_tix is skipped for me: $ ./python -m unittest -v test.test_tix test_tix_available (test.test_tix.TestTix) ... skipped 'Tix not available' Reverting to before revision 064b29dde096 (Issue 24137) also fixes the failure. ---------- components: Tests messages: 271206 nosy: martin.panter, serhiy.storchaka, terry.reedy priority: normal severity: normal status: open title: test_tix cannot import _default_root after test_idle type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 02:27:54 2016 From: report at bugs.python.org (Matt Robenolt) Date: Mon, 25 Jul 2016 06:27:54 +0000 Subject: [New-bugs-announce] [issue27612] socket.gethostbyname resolving octal IP addresses incorrectly Message-ID: <1469428074.1.0.701366093272.issue27612@psf.upfronthosting.co.za> New submission from Matt Robenolt: This also affects socket.getaddrinfo on macOS only, but is fine on Linux. I've not tested on Windows to see behavior there. Given the IP address `0177.0000.0000.0001`, which is a valid octal format representing `127.0.0.1`, we can see varying results. Confirmed in both python 2.7 and 3.5. First, socket.gethostbyname is always wrong, and always returns `177.0.0.1`: ``` >>> socket.gethostbyname('0177.0000.0000.0001') '177.0.0.1' ``` This can be seen on both Linux and macOS. With `socket.getaddrinfo`, resolution is correct on Linux, but the bad 177.0.0.1 on macOS. Linux: ``` >>> socket.getaddrinfo('0177.0000.0000.0001', None)[0] (2, 1, 6, '', ('127.0.0.1', 0)) ``` macOS: ``` >>> socket.getaddrinfo('0177.0000.0000.0001', None)[0] (2, 2, 17, '', ('177.0.0.1', 0)) ``` This behavior exists in both 2.7.12 and 3.5.2 at least. I haven't tested many others, but I assume pretty universal. ---------- components: Library (Lib) messages: 271237 nosy: mattrobenolt priority: normal severity: normal status: open title: socket.gethostbyname resolving octal IP addresses incorrectly type: behavior versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 07:42:11 2016 From: report at bugs.python.org (Grigory Statsenko) Date: Mon, 25 Jul 2016 11:42:11 +0000 Subject: [New-bugs-announce] [issue27613] Empty iterator is rendered as a single bracket ] when using json's iterencode Message-ID: <1469446931.7.0.792781039481.issue27613@psf.upfronthosting.co.za> New submission from Grigory Statsenko: JSONEncoder.iterencode doesn't work with empty iterators correctly. Steps: 1. Define an iterator that is recognized by json as a list (inherit from list and define nonzero __len__). 2. Use json.dump with data containing an empty iterator defined as described in step#1 (but doesn't generate any items) Expected result: it should be rendered as an empty list: '[]' Actual result: it is rendered as ']' (only the closing bracket) interestingly enough this behavior is not reproduced when using the dumps function. I tried other alternatives to the standard json module: simplejson, ujson, hjson All of them work as expected in this case (both brackets are rendered). Here is an example of the code that demonstrates this error (compares the results of the dump and dumps functions): import json as json import io class EmptyIterator(list): def __iter__(self): while False: yield 1 def __len__(self): return 1 def dump_to_str(data): return json.dumps(data) def dump_to_file(data): stream = io.StringIO() json.dump(data, stream) return stream.getvalue() data = {'it': EmptyIterator()} print('to str: {0}'.format(dump_to_str(data))) print('to file: {0}'.format(dump_to_file(data))) This prints: to str: {"it": []} to file: {"it": ]} ---------- messages: 271249 nosy: altvod priority: normal severity: normal status: open title: Empty iterator is rendered as a single bracket ] when using json's iterencode type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 11:05:39 2016 From: report at bugs.python.org (earl.chew) Date: Mon, 25 Jul 2016 15:05:39 +0000 Subject: [New-bugs-announce] [issue27614] Race in test_docxmlrpc.py Message-ID: <1469459139.76.0.959920407285.issue27614@psf.upfronthosting.co.za> New submission from earl.chew: The test test_docxmlrpc.py will sometimes hang because of a timing race. I've verified that this code is the same up to version 3.5 and master at https://github.com/python/cpython/blob/master/Lib/test/test_docxmlrpc.py A proposed patch is attached. ---------- components: Library (Lib) files: test_docxmlrpc.py messages: 271279 nosy: earl.chew priority: normal severity: normal status: open title: Race in test_docxmlrpc.py 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/file43881/test_docxmlrpc.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 13:29:19 2016 From: report at bugs.python.org (Al Sweigart) Date: Mon, 25 Jul 2016 17:29:19 +0000 Subject: [New-bugs-announce] [issue27615] IDLE's debugger steps into PyShell.py for calls to print() et al Message-ID: <1469467759.18.0.354149143305.issue27615@psf.upfronthosting.co.za> New submission from Al Sweigart: Currently if the user "steps into" a print(), input(), sys.stdout.write() or other stdio-related call with the Source checkbox checked, it brings up PyShell.py. This is often confusing for beginner programmers (the target audience of IDLE) and most often not helpful for experienced developers who are stepping through their program. Comparing the cost/benefit, I'd be much more helpful for IDLE to not bring up PyShell.py and instead just treat every "step into" of a print()/input()/anything-that-goes-to-pyshell as a "step over" instead. ---------- assignee: terry.reedy components: IDLE messages: 271295 nosy: Al.Sweigart, terry.reedy priority: normal severity: normal status: open title: IDLE's debugger steps into PyShell.py for calls to print() et al versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 13:37:18 2016 From: report at bugs.python.org (Grant Hillebrand) Date: Mon, 25 Jul 2016 17:37:18 +0000 Subject: [New-bugs-announce] [issue27616] filedialog.askdirectory inconsistent on Windows between returning "C:/" and "C:/users" (no trailing slash) Message-ID: <1469468238.61.0.474363149897.issue27616@psf.upfronthosting.co.za> New submission from Grant Hillebrand: When running the following code on Windows 7 (64bit os), and selecting a root drive letter, eg C:, it returns "C:/", with a slash appended. When selecting any other path below root level, eg "C:/users" it returns "C:/users" - no slash appended. This then introduces an odd edge case in processing the output if the path is to be prepended to directory walk data and other file names. Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)] on win32 >>> from tkinter import filedialog >>> SourcePath = filedialog.askdirectory() >>> print(SourcePath) C:/ >>> SourcePath = filedialog.askdirectory() >>> print(SourcePath) C:/NVIDIA >>> ---------- components: Tkinter, Windows messages: 271296 nosy: Grant Hillebrand, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: filedialog.askdirectory inconsistent on Windows between returning "C:/" and "C:/users" (no trailing slash) type: behavior versions: Python 3.3, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 15:28:00 2016 From: report at bugs.python.org (Michael Smith) Date: Mon, 25 Jul 2016 19:28:00 +0000 Subject: [New-bugs-announce] [issue27617] Compiled bdist_wininst missing from embedded distribution Message-ID: <1469474880.88.0.362049415558.issue27617@psf.upfronthosting.co.za> New submission from Michael Smith: It seems that the embedded distribution is missing bdist_wininst.pyc from the python35.zip . If you go to distutils\command, you'll notice only 23 compiled python files, where in the regular web based installer for the same Python version there are 24 python files in similar relevant folder. I encountered this while trying to install a library into the python runtime that had this import statement: import distutils.command.bdist_wininst ---------- components: Distutils messages: 271301 nosy: denimpowell, dstufft, eric.araujo priority: normal severity: normal status: open title: Compiled bdist_wininst missing from embedded distribution type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 16:55:03 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 25 Jul 2016 20:55:03 +0000 Subject: [New-bugs-announce] [issue27618] docs for threading.Lock claim it's a class (since 3.3), but it's not (and has never been, apparently) Message-ID: <1469480103.96.0.342423272445.issue27618@psf.upfronthosting.co.za> New submission from Guido van Rossum: The docs for threading.Lock say 79534: .. versionchanged:: 3.3 79534: Changed from a factory function to a class. but the implementation in threading.py doesn't define a class named Lock, and in fact it is an alias for _thread.allocate_lock. Are the docs wrong, or is the source? Or did this get changed back later? ---------- messages: 271305 nosy: gvanrossum priority: normal severity: normal status: open title: docs for threading.Lock claim it's a class (since 3.3), but it's not (and has never been, apparently) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 20:50:17 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 26 Jul 2016 00:50:17 +0000 Subject: [New-bugs-announce] [issue27619] getopt should strip whitespace from long arguments Message-ID: <1469494217.58.0.75154224673.issue27619@psf.upfronthosting.co.za> New submission from Steven D'Aprano: As reported here: https://mail.python.org/pipermail/python-list/2016-July/711333.html there's a possible annoyance with getopt when you accidentally leave whitespace on a long option. On my Centos system, getopt ignores leading and trailing whitespace on long options. [steve at ando ~]$ getopt -o "" -l " spam , eggs " -- --spam --eggs arg --spam --eggs -- 'arg' Python's getopt should do the same. (Patch attached.) ---------- components: Library (Lib) files: getopt.patch keywords: patch messages: 271310 nosy: steven.daprano priority: normal severity: normal status: open title: getopt should strip whitespace from long arguments type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43884/getopt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 25 20:54:51 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 26 Jul 2016 00:54:51 +0000 Subject: [New-bugs-announce] [issue27620] IDLE: Add keyboard equivalents for mouse actions. Message-ID: <1469494491.39.0.22722488108.issue27620@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Reading https://en.wikipedia.org/wiki/IBM_Common_User_Access and in particular "All operations could be done with either the mouse or the keyboard;", I checked IDLE's dialogs. The Windows dialogs accessed as common dialogs work correctly. I will assume true for other OSes until told otherwise. The new Query widget recogizes for [Ok] but not for [Cancel]. My omission, easily corrected. Search boxes cannot set options with keys. Notepad++ can. The Options dialog has no key equivalents. ---------- assignee: terry.reedy components: IDLE messages: 271311 nosy: terry.reedy priority: normal severity: normal stage: test needed status: open title: IDLE: Add keyboard equivalents for mouse actions. type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 02:02:46 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Jul 2016 06:02:46 +0000 Subject: [New-bugs-announce] [issue27621] incorrectly works in IDLE Query dialogs Message-ID: <1469512966.74.0.594331033204.issue27621@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: When open new Query dialog in IDLE (e.g. "Open Module" dialog), move a focus on the Cancel button and press on keyboard, the OK button is invoked instead of Cancel. ---------- assignee: terry.reedy components: IDLE messages: 271326 nosy: serhiy.storchaka, terry.reedy priority: normal severity: normal status: open title: incorrectly works in IDLE Query dialogs type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 02:20:37 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 26 Jul 2016 06:20:37 +0000 Subject: [New-bugs-announce] [issue27622] int.to_bytes(): docstring is not precise Message-ID: <1469514037.92.0.489318728995.issue27622@psf.upfronthosting.co.za> New submission from ???? ?????????: Docstring says: The signed keyword-only argument determines whether two's complement is used to represent the integer. If signed is False and a negative integer is given, an OverflowError is raised. But actually, (130).to_bytes(1, 'big', signed=True) will also trigger OverflowError ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 271327 nosy: docs at python, mmarkk priority: normal severity: normal status: open title: int.to_bytes(): docstring is not precise type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 02:26:20 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 26 Jul 2016 06:26:20 +0000 Subject: [New-bugs-announce] [issue27623] int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero Message-ID: <1469514380.74.0.642597369558.issue27623@psf.upfronthosting.co.za> New submission from ???? ?????????: As you can see, these conversions are not consistent. What is use case to allow that? =================== In [22]: (-1).to_bytes(0, 'big', signed=True) Out[22]: b'' In [23]: (0).to_bytes(0, 'big', signed=True) Out[23]: b'' As you can see, two different values serialized to same empty bytes sequence. =================== In [28]: int.from_bytes(b'', 'big', signed=True) Out[28]: 0 In [29]: int.from_bytes(b'', 'big', signed=False) Out[29]: 0 Anyway, -1 can not be deserialized. =================== ---------- messages: 271329 nosy: mmarkk priority: normal severity: normal status: open title: int.to_bytes() and int.from_bytes(): raise ValueError when bytes count is zero _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 09:00:53 2016 From: report at bugs.python.org (Doug Hoskisson) Date: Tue, 26 Jul 2016 13:00:53 +0000 Subject: [New-bugs-announce] [issue27624] unclear documentation on Queue.qsize() Message-ID: <1469538053.41.0.353171937214.issue27624@psf.upfronthosting.co.za> New submission from Doug Hoskisson: The documentation for Queue.qsize(): "Return the approximate size of the queue." "approximate" is unclear. It might suggest some strategy used for approximating, or it might be the exact size at an arbitrary time. It should be made more clear. ---------- assignee: docs at python components: Documentation messages: 271362 nosy: Doug Hoskisson, docs at python priority: normal severity: normal status: open title: unclear documentation on Queue.qsize() versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 09:52:00 2016 From: report at bugs.python.org (Palm Kevin) Date: Tue, 26 Jul 2016 13:52:00 +0000 Subject: [New-bugs-announce] [issue27625] "make install" fails when no zlib support available Message-ID: <1469541120.27.0.508347520885.issue27625@psf.upfronthosting.co.za> New submission from Palm Kevin: It seems that on linux (red hat), the "make install" fails when no zlib support is available. (I have no zlib installed and I don't want to do so) I reproduced the problem with both python 3.5.1 and python 3.5.2 The command 'configure' and 'make' produced no errors, but the 'make install' failed with this error message: if test "xupgrade" != "xno" ; then \ case upgrade in \ upgrade) ensurepip="--upgrade" ;; \ install|*) ensurepip="" ;; \ esac; \ LD_LIBRARY_PATH=/usr/ls/tmp/py/Python-3.5.2:/usr/ls/app/python35/lib:./ls/lib:./ls/lib:/usr/molis/uniface9606/common/lib:/usr/molis/dlm/Linux/amd64:/usr/oracle/product/11.2.0/lib:/usr/oracle/product/11.2.0/lib: ./python -E -m ensurepip \ $ensurepip --root=/ ; \ fi Traceback (most recent call last): File "/usr/ls/tmp/py/Python-3.5.2/Lib/runpy.py", line 184, in _run_module_as_main "__main__", mod_spec) File "/usr/ls/tmp/py/Python-3.5.2/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/usr/ls/tmp/py/Python-3.5.2/Lib/ensurepip/__main__.py", line 4, in ensurepip._main() File "/usr/ls/tmp/py/Python-3.5.2/Lib/ensurepip/__init__.py", line 209, in _main default_pip=args.default_pip, File "/usr/ls/tmp/py/Python-3.5.2/Lib/ensurepip/__init__.py", line 116, in bootstrap _run_pip(args + [p[0] for p in _PROJECTS], additional_paths) File "/usr/ls/tmp/py/Python-3.5.2/Lib/ensurepip/__init__.py", line 40, in _run_pip import pip zipimport.ZipImportError: can't decompress data; zlib not available make: *** [install] Error 1 zlib is not required to run Python 3.5, it should thus not be required neither for setting up python. ---------- components: Build messages: 271366 nosy: palm.kevin priority: normal severity: normal status: open title: "make install" fails when no zlib support available type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 11:05:32 2016 From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=) Date: Tue, 26 Jul 2016 15:05:32 +0000 Subject: [New-bugs-announce] [issue27626] Spelling fixes Message-ID: <1469545532.64.0.917176953717.issue27626@psf.upfronthosting.co.za> Changes by Ville Skytt? : ---------- files: spelling.patch keywords: patch nosy: scop priority: normal severity: normal status: open title: Spelling fixes type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43895/spelling.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 12:00:04 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 26 Jul 2016 16:00:04 +0000 Subject: [New-bugs-announce] [issue27627] clang fails to build ctypes on Android armv7 Message-ID: <1469548804.03.0.253610844682.issue27627@psf.upfronthosting.co.za> New submission from Xavier de Gaye: The build is done with: clang --sysroot=/opt/android-ndk/platforms/android-21/arch-arm -target armv7-none-linux-androideabi -gcc-toolchain /opt/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 The error message: clang --sysroot=/opt/android-ndk/platforms/android-21/arch-arm -target armv7-none-linux-androideabi -gcc-toolchain /opt/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Wno-unused-value -Wno-empty-body -Qunused-arguments -Wno-parentheses-equality -Werror=declaration-after-statement -Ibuild/temp.linux-arm-3.6/libffi/include -Ibuild/temp.linux-arm-3.6/libffi -I./Modules/_ctypes/libffi/src -IInclude -I/sdcard/org.bitbucket.pyona/include -I. -I/home/xavier/src/android/pyona/build/python3.6-install-android-21-armv7/org.bitbucket.pyona/include -I/opt/android-ndk/platforms/android-21/arch-arm/usr/include -I./Include -I/home/xavier/src/android/pyona/build/python3.6-android-21-armv7 -c ./Modules/_ctypes/libffi/src/arm/sysv.S -o build/temp.linux-arm-3.6./Modules/_ctypes/libffi/src/arm/sysv.o -Wall -fexceptions ./Modules/_ctypes/libffi/src/arm/sysv.S:399:2: error: invalid instruction stmeqia r2, {r0, r1} ^ ---------- components: Cross-Build messages: 271385 nosy: Alex.Willmer, Chi Hsuan Yen, xdegaye priority: normal severity: normal stage: needs patch status: open title: clang fails to build ctypes on Android armv7 type: compile error versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 13:34:35 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Tue, 26 Jul 2016 17:34:35 +0000 Subject: [New-bugs-announce] [issue27628] ipaddress incompatibility with ipaddr: __contains__ between networks Message-ID: <1469554475.46.0.86096360489.issue27628@psf.upfronthosting.co.za> New submission from ?ukasz Langa: ipaddr historically let users compare if one network is within another network: https://github.com/google/ipaddr-py/blob/master/ipaddr.py#L643 ipaddress specifically prohibits this comparison: https://hg.python.org/cpython/file/tip/Lib/ipaddress.py#l675 What is the reason behind this change? I propose we restore this functionality for 3.6. It's a behavior change but arguably backwards compatible in the sense that between 3.3 and 3.5 this __contains__ comparison always returns False. It's also more on par with what ipaddr did in the past. Thoughts? ---------- assignee: pmoody components: Library (Lib) messages: 271399 nosy: berker.peksag, lukasz.langa, ncoghlan, pmoody priority: normal severity: normal stage: needs patch status: open title: ipaddress incompatibility with ipaddr: __contains__ between networks type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 19:21:45 2016 From: report at bugs.python.org (nemunaire) Date: Tue, 26 Jul 2016 23:21:45 +0000 Subject: [New-bugs-announce] [issue27629] Cannot create raw ssl.SSLSocket Message-ID: <1469575305.76.0.392837082138.issue27629@psf.upfronthosting.co.za> New submission from nemunaire: I got this stacktrace: File "test_ssl.py", line 3, in sock = ssl.SSLSocket(server_hostname="docs.python.org") File "/usr/lib/python3.4/ssl.py", line 536, in __init__ if sock.getsockopt(SOL_SOCKET, SO_TYPE) != SOCK_STREAM: AttributeError: 'NoneType' object has no attribute 'getsockopt' with this minimal code: import ssl sock = ssl.SSLSocket(server_hostname="docs.python.org") sock.connect(("docs.python.org", 443)) sock.sendall(b"GET /3/library/ssl.html HTTP/1.0\r\nHost: docs.python.org\r\n\r\n") print(sock.recv(4096).decode()) Whereas the None socket is correctly handled a few lines later: https://hg.python.org/cpython/file/tip/Lib/ssl.py#l715 All Python >= 3.3 are affected (since https://hg.python.org/cpython/rev/a00842b783cf) and can be patched with the same file, attached to this issue. ---------- components: Library (Lib) files: fix_sslsocket_init_without_socket_3.3-3_6.patch keywords: patch messages: 271419 nosy: nemunaire priority: normal severity: normal status: open title: Cannot create raw ssl.SSLSocket type: behavior versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43900/fix_sslsocket_init_without_socket_3.3-3_6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 26 21:07:13 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 27 Jul 2016 01:07:13 +0000 Subject: [New-bugs-announce] [issue27630] Generator._encoded_EMTPY misspelling in email package Message-ID: <1469581633.21.0.276257861067.issue27630@psf.upfronthosting.co.za> New submission from Martin Panter: In the Generator.flatten() (Lib/email/generator.py), the code sets, among others, the instance attributes _EMPTY (correct spelling) and _encoded_EMTPY (misspelling). Further down in that class, _encoded_EMPTY (correct spelling) is set as a class attribute, and this correctly-spelt version appears to be used in the _handle_message_delivery_status() method. The BytesGenerator class inherits Generator and overrides the correctly-spelt _encoded_EMPTY class attribute. It seems that both _EMPTY and the misspelt _encoded_EMTPY instance attributes are not used. Perhaps they should be removed. Or perhaps they are not doing the job they were intended for and there is a real bug. ---------- components: email messages: 271424 nosy: barry, martin.panter, r.david.murray priority: normal severity: normal status: open title: Generator._encoded_EMTPY misspelling in email package versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 02:41:51 2016 From: report at bugs.python.org (Ammar Askar) Date: Wed, 27 Jul 2016 06:41:51 +0000 Subject: [New-bugs-announce] [issue27631] .exe is appended to python executable based on filesystem case insensitivity Message-ID: <1469601711.28.0.541702866764.issue27631@psf.upfronthosting.co.za> New submission from Ammar Askar: I encountered some odd behavior today, I compiled python inside VirtualBox, however, I compiled it inside a shared folder. The OS outside of VirtualBox is Windows, so the shared folder naturally is case-insensitive. The actual virtual OS is Debian Linux. Upon running make, I found that oddly enough the executable created was called `python.exe`. Running `make install` still installs it to the correct python name. I did some digging around and from what I can tell this is the change that makes the built python executable have an exe extension or not depending on file system case insensitivity. https://hg.python.org/cpython/rev/d64dfbdc5f8c It's from way long ago from 2001 and I can't figure out why exactly this change was made. The commit message hints that it has something to do with Mac's file system. I asked a friend who used MacOS back then and he reports that it had no file extensions back then either. As far as I know, the only OS that really requires file extension is windows, and besides, this exact situation is what the https://www.gnu.org/software/automake/manual/html_node/EXEEXT.html variable is for, which is used in the configure.ac file already. It seems a little odd that whether or not to put .exe in the build executable is based on file system case insensitivity. ---------- components: Build messages: 271436 nosy: ammar2 priority: normal severity: normal status: open title: .exe is appended to python executable based on filesystem case insensitivity 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 Jul 27 04:28:32 2016 From: report at bugs.python.org (Michael Felt) Date: Wed, 27 Jul 2016 08:28:32 +0000 Subject: [New-bugs-announce] [issue27632] build on AIX fails when builddir != srcdir, more than bad path to ld_so_aix Message-ID: <1469608112.86.0.803958819971.issue27632@psf.upfronthosting.co.za> New submission from Michael Felt: Note: - Only examined on Python 2.7, but expect the same issue (from Python 3.4.X, 3.5.X and 3.6.X based on earlier attempts to use a separate builddir SUMMARY: * when builddir==srcdir build completes normally, (see DETAILS2:) * when builddir!=srcdir ... ** "configure" completes, no error messages ** "make" completes: some warnings, and I am surprised that make does not stop when message "unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory" appears The ./python executable can be executed (no other tests done yet) root at x064:[/data/prj/aixtools/python/Python-2.7.12]./python Python 2.7.12 (default, Jul 27 2016, 07:26:36) [C] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> * make install DESTDIR=/some/where/for/packaging - FAILS * in DETAILS3: I show that 'helping' by setting a symbolic link (messages continue), then a hard-link (ld_so_aix messages go away) also fails COMMENTS: * the Bitfield messages are 'known' and occur in all versions of Python (2.7.X, 3.3.X, 3.4.X, 3.5.X and 3.6.X - 3.2.X, (3.1.X and 3.0.X never tried)) * I hae no idea what all the "Skipping" is about, leaving in details as FYI DETAILS (verbatum): root at x064:[/data/prj/aixtools/python/Python-2.7.12]buildaix --without-computed-gotos VRMF 2.7.12.0 xlc is /usr/vacpp/bin/xlc + [[ 0 -eq 0 ]] + CC=xlc_r + export CC + CC=xlc_r CPPFLAGS="-I/opt/include -I/opt/buildaix/include" CFLAGS="-I/opt/include -O2 -qmaxmem=-1 -I/opt/buildaix/includes"\ ../src/Python-2.7.12/configure\ --prefix=/opt \ --sysconfdir=/var/Python/etc\ --sharedstatedir=/var/Python/com\ --localstatedir=/var/Python\ --mandir=/usr/share/man\ --infodir=/opt/share/info/Python --without-computed-gotos\ > .buildaix/configure.out + make > .buildaix/make.out "../src/Python-2.7.12/Objects/typeobject.c", line 6243.26: 1506-068 (W) Operation between types "void*" and "struct _object*(*)(struct _object*)" is not allowed. "../src/Python-2.7.12/Objects/typeobject.c", line 6290.22: 1506-068 (W) Operation between types "void*" and "long(*)(struct _object*)" is not allowed. "../src/Python-2.7.12/Objects/typeobject.c", line 6490.18: 1506-068 (W) Operation between types "void*" and "long(*)(struct _object*)" is not allowed. unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for M is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for N is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for O is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for P is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for Q is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for R is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for S is not valid. Type unsigned assumed. unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory "/data/prj/aixtools/python/src/Python-2.7.12/Modules/pyexpat.c", line 1538.27: 1506-068 (W) Operation between types "void*" and "void(*)(void*,const char*,int)" is not allowed. unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 3406.27: 1506-068 (W) Operation between types "void*" and "int(*)(void)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 3954.31: 1506-280 (W) Function argument assignment between types "int(*)(void)" and "void*" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5695.63: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,const void*,unsigned long)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5696.62: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,int,unsigned long)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5697.65: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const char*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5698.60: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(void*,struct _object*,struct _object*)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5700.66: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const unsigned short*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/callproc.c", line 837.32: 1506-280 (W) Function argument assignment between types "void(*)(void)" and "void*" is not allowed. Assembler: /tmp/xlcS0JTuaqd.s: line 160: 1252-149 Instruction extsb is not implemented in the current assembly mode COM. unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory + make install DESTDIR=/var/aixtools/python/Python/2.7.12.0 > .buildaix/install.out unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for M is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for N is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for O is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for P is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for Q is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for R is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for S is not valid. Type unsigned assumed. unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory "/data/prj/aixtools/python/src/Python-2.7.12/Modules/pyexpat.c", line 1538.27: 1506-068 (W) Operation between types "void*" and "void(*)(void*,const char*,int)" is not allowed. unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 3406.27: 1506-068 (W) Operation between types "void*" and "int(*)(void)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 3954.31: 1506-280 (W) Function argument assignment between types "int(*)(void)" and "void*" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5695.63: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,const void*,unsigned long)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5696.62: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,int,unsigned long)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5697.65: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const char*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5698.60: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(void*,struct _object*,struct _object*)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5700.66: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const unsigned short*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/callproc.c", line 837.32: 1506-280 (W) Function argument assignment between types "void(*)(void)" and "void*" is not allowed. Assembler: /tmp/xlcS0dZucqd.s: line 160: 1252-149 Instruction extsb is not implemented in the current assembly mode COM. unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory eval $PYTHON_FOR_BUILD ../../Tools/scripts/h2py.py -i "'(u_long)'" /usr/include/netinet/in.h Skipping: __restrict__ = restrict Skipping: __restrict__ = Skipping: __bool__ = _Bool Skipping: __bool__ = unsigned char Skipping: INT64_MIN = (INT64_C(-9223372036854775807)-1) Skipping: INT64_MAX = (INT64_C(9223372036854775807)) Skipping: UINT8_MAX = (255U) Skipping: UINT16_MAX = (65535U) Skipping: UINT32_MAX = (4294967295U) Skipping: UINT64_MAX = (UINT64_C(18446744073709551615)) Skipping: INT_LEAST64_MIN = INT64_MIN Skipping: INT_LEAST64_MAX = INT64_MAX Skipping: UINT_LEAST8_MAX = UINT8_MAX Skipping: UINT_LEAST16_MAX = UINT16_MAX Skipping: UINT_LEAST32_MAX = UINT32_MAX Skipping: UINT_LEAST64_MAX = UINT64_MAX Skipping: INT_FAST64_MIN = INT64_MIN Skipping: INT_FAST64_MAX = INT64_MAX Skipping: UINT_FAST8_MAX = UINT8_MAX Skipping: UINT_FAST16_MAX = UINT16_MAX Skipping: UINT_FAST32_MAX = UINT32_MAX Skipping: UINT_FAST64_MAX = UINT64_MAX Skipping: INTMAX_MIN = INT64_MIN Skipping: INTMAX_MAX = INT64_MAX Skipping: UINTMAX_MAX = UINT64_MAX Skipping: UINTMAX_MAX = UINT32_MAX Skipping: INTPTR_MIN = INT64_MIN Skipping: INTPTR_MAX = INT64_MAX Skipping: UINTPTR_MAX = UINT64_MAX Skipping: UINTPTR_MAX = UINT32_MAX Skipping: PTRDIFF_MIN = INT64_MIN Skipping: PTRDIFF_MAX = INT64_MAX Skipping: WCHAR_MAX = UINT32_MAX Skipping: WCHAR_MAX = UINT16_MAX Skipping: SIZE_MAX = UINT64_MAX Skipping: SIZE_MAX = UINT32_MAX Skipping: strtoumax = _strtoumax32 Skipping: wcstoimax = _wcstoimax32 Skipping: wcstoumax = _wcstoumax32 Skipping: imaxabs = _imaxabs32 Skipping: imaxdiv = _imaxdiv32 Skipping: UINTFAST_MAX = UINT32_MAX Skipping: def ADSP_MASK(_x): return ((1U << 31) >> (_x)) Skipping: def P64(X): return ( *((ptr64 *)&(X)) ) Skipping: fsid_dev = val[0] Skipping: fsid_type = val[1] Skipping: fh_dev = fh_fsid.fsid_dev Skipping: fh_type = fh_fsid.fsid_type Skipping: fh_len = fh_fid.fid_len Skipping: fh_ino = fh_fid.fid_ino Skipping: fh_gen = fh_fid.fid_gen Skipping: __NFDBITS = (sizeof(long) * 8) Skipping: __NUM_ENTRIES = (FD_SETSIZE/__NFDBITS+1) Skipping: def FD_ZERO(p): return { fd_set *__q=p; \ Skipping: NS_PER_TICK = (NS_PER_SEC/HZ) Skipping: TIMEBASE_SZ = (sizeof (struct timebasestruct)) Skipping: def ntimerisset(tvp): return ((tvp)->tv_sec || (tvp)->tv_nsec) Skipping: def ntimerclear(tvp): return (tvp)->tv_sec = (tvp)->tv_nsec = 0 Skipping: def timerisset(tvp): return ((tvp)->tv_sec || (tvp)->tv_usec) Skipping: def timerclear(tvp): return (tvp)->tv_sec = (tvp)->tv_usec = 0 Skipping: CLOCK_REALTIME = ((clockid_t) 9) Skipping: CLOCK_MONOTONIC = ((clockid_t) 10) Skipping: CLOCK_PROCESS_CPUTIME_ID = ((clockid_t) 11) Skipping: CLOCK_THREAD_CPUTIME_ID = ((clockid_t) 12) Skipping: _H_STDDEF = Skipping: offsetof = __offsetof Skipping: NFDBITS = __NFDBITS Skipping: s6_addr32 = s6_addr.s6_addr32 Skipping: s6_addr64 = s6_addr.s6_addr64 Skipping: s6_addr16 = s6_addr.s6_addr16 Skipping: s6_addr8 = s6_addr.s6_addr8 Skipping: s6_addr = s6_addr.s6_addr8 Skipping: INADDR_ANY = (uint32_t)0x00000000 Skipping: INADDR_BROADCAST = (uint32_t)(-1) Skipping: INADDR_UNSPEC_GROUP = (uint32_t)(-536870912) Skipping: INADDR_ALLHOSTS_GROUP = (uint32_t)(-536870911) Skipping: INADDR_ALLRTRS_GROUP = (uint32_t)(-536870910) Skipping: INADDR_MAX_LOCAL_GROUP = (uint32_t)(-536870657) Skipping: MSR_HYPERVISOR = (1152921500311879680)L Skipping: DSCR_PROP_VER0_SIZE = (offsetof(struct dscr_properties, dscr_res)) Skipping: DSCR_PROP_SIZE = (sizeof(struct dscr_properties)) Skipping: FP_IE_IMPL = (fp_ie_impl != 0) Skipping: ASR_VALID = (1LL) Skipping: SLB_PSIZE_MASK = 0x170UL Skipping: def VALID_HANDLE_SSLB(_handle): return (!((_handle) & 0x0f)) Skipping: HANDLE_CLASS_SSLB = 0x80UL Skipping: def htons(hostshort): return (unsigned short)(hostshort) Skipping: def ntohs(netshort): return (unsigned short)(netshort) Skipping: INADDR_LOOPBACK = (uint32_t)0x7f000001 Skipping: s6_addr32 = u6_addr.u6_addr32 Skipping: s6_addr64 = u6_addr.u6_addr64 Skipping: s6_addr16 = u6_addr.u6_addr16 Skipping: s6_addr8 = u6_addr.u6_addr8 Skipping: s6_addr = u6_addr.u6_addr8 Skipping: def HTONLL(x): return (x) = htonll((x)); Skipping: def HTONL(x): return (x) = htonl((x)); Skipping: def HTONS(x): return (x) = htons((x)); Skipping: def NTOHLL(x): return (x) = ntohll((x)); Skipping: def NTOHL(x): return (x) = ntohl((x)); Skipping: def NTOHS(x): return (x) = ntohs((x)); Skipping: def IPV6_GET_VERSION(x): return ((*((u_char *)&(x)) >> 4) & 0xf) Skipping: def IN6_ADDR_V6_TO_V4(a): return ((struct in_addr *)&(a)->s6_addr[12]) Skipping: def satosin(sa): return ((struct sockaddr_in *)(sa)) Skipping: def sintosa(sin): return ((struct sockaddr *)(sin)) Skipping: def ifatoia(ifa): return ((struct in_ifaddr *)(ifa)) Skipping: def satosin6(sa): return ((struct sockaddr_in6 *)(sa)) Skipping: def sin6tosa(sin6): return ((struct sockaddr *)(sin6)) Skipping: def ifatoia6(ifa): return ((struct in6_ifaddr *)(ifa)) Traceback (most recent call last): File "/var/aixtools/python/Python/2.7.12.0/opt/lib/python2.7/compileall.py", line 16, in import struct File "/var/aixtools/python/Python/2.7.12.0/opt/lib/python2.7/struct.py", line 1, in from _struct import * ImportError: No module named _struct make: 1254-004 The error code from the last command is 1. Stop. make install returned an error root at x064:[/data/prj/aixtools/python/Python-2.7.12] DETAILS2: root at x064:[/data/prj/aixtools/python/python-2.7.12]buildaix --without-computed-gotos VRMF 2.7.12.0 xlc is /usr/vacpp/bin/xlc + [[ 0 -eq 0 ]] + CC=xlc_r + export CC + CC=xlc_r CPPFLAGS="-I/opt/include -I/opt/buildaix/include" CFLAGS="-I/opt/include -O2 -qmaxmem=-1 -I/opt/buildaix/includes"\ ./configure\ --prefix=/opt \ --sysconfdir=/var/python/etc\ --sharedstatedir=/var/python/com\ --localstatedir=/var/python\ --mandir=/usr/share/man\ --infodir=/opt/share/info/python --without-computed-gotos\ > .buildaix/configure.out + make > .buildaix/make.out "Objects/typeobject.c", line 6243.26: 1506-068 (W) Operation between types "void*" and "struct _object*(*)(struct _object*)" is not allowed. "Objects/typeobject.c", line 6290.22: 1506-068 (W) Operation between types "void*" and "long(*)(struct _object*)" is not allowed. "Objects/typeobject.c", line 6490.18: 1506-068 (W) Operation between types "void*" and "long(*)(struct _object*)" is not allowed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for M is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for N is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for O is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for P is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for Q is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for R is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for S is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12/Modules/pyexpat.c", line 1538.27: 1506-068 (W) Operation between types "void*" and "void(*)(void*,const char*,int)" is not allowed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes.c", line 3406.27: 1506-068 (W) Operation between types "void*" and "int(*)(void)" is not allowed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes.c", line 3954.31: 1506-280 (W) Function argument assignment between types "int(*)(void)" and "void*" is not allowed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes.c", line 5695.63: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,const void*,unsigned long)" is not allowed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes.c", line 5696.62: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,int,unsigned long)" is not allowed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes.c", line 5697.65: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const char*,int)" is not allowed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes.c", line 5698.60: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(void*,struct _object*,struct _object*)" is not allowed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/_ctypes.c", line 5700.66: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const unsigned short*,int)" is not allowed. "/data/prj/aixtools/python/python-2.7.12/Modules/_ctypes/callproc.c", line 837.32: 1506-280 (W) Function argument assignment between types "void(*)(void)" and "void*" is not allowed. Assembler: /tmp/xlcS0YSYiqd.s: line 160: 1252-149 Instruction extsb is not implemented in the current assembly mode COM. + make install DESTDIR=/var/aixtools/aixtools/python/2.7.12.0 > .buildaix/install.out + mkinstallp.ksh /var/aixtools/aixtools/python/2.7.12.0 > .buildaix/mkinstallp.out ============================== aixtools.python:aixtools.python.man.en_US:2.7.12.0::I:T:::::N:man pages::::0:: aixtools.python:aixtools.python.rte:2.7.12.0::I:T:::::N:built 27-Jul-2016 0744 UTC::::0:: ============================== root at x064:[/data/prj/aixtools/python/python-2.7.12] DETAILS3: root at x064:[/data/prj/aixtools/python/Python-2.7.12]buildaix --without-computed-gotos VRMF 2.7.12.0 xlc is /usr/vacpp/bin/xlc + [[ 0 -eq 0 ]] + CC=xlc_r + export CC + CC=xlc_r CPPFLAGS="-I/opt/include -I/opt/buildaix/include" CFLAGS="-I/opt/include -O2 -qmaxmem=-1 -I/opt/buildaix/includes"\ ../src/Python-2.7.12/configure\ --prefix=/opt \ --sysconfdir=/var/Python/etc\ --sharedstatedir=/var/Python/com\ --localstatedir=/var/Python\ --mandir=/usr/share/man\ --infodir=/opt/share/info/Python --without-computed-gotos\ > .buildaix/configure.out + make > .buildaix/make.out root at x064:[/data/prj/aixtools/python/Python-2.7.12]find . -name ld_so_aix ./Modules/ld_so_aix root at x064:[/data/prj/aixtools/python/Python-2.7.12]ls ../src/Python-2.7.12/Modules Setup.config.in _heapqmodule.c _ssl_data.h bz2module.c datetimemodule.c gdbmmodule.c main.c posixmodule.h shamodule.c testcapi_long.h yuvconvert.c Setup.dist _hotshot.c _struct.c cPickle.c dbmmodule.c getaddrinfo.c makesetup puremodule.c signalmodule.c threadmodule.c zipimport.c _bisectmodule.c _io _testcapimodule.c cStringIO.c dlmodule.c getbuildinfo.c makexp_aix pwdmodule.c socketmodule.c timemodule.c zlib _bsddb.c _json.c _tkinter.c cdmodule.c errnomodule.c getnameinfo.c mathmodule.c pyexpat.c socketmodule.h timing.h zlibmodule.c _codecsmodule.c _localemodule.c _weakref.c cgen.py expat getpath.c md5.c python.c spwdmodule.c timingmodule.c _collectionsmodule.c _lsprof.c addrinfo.h cgensupport.c fcntlmodule.c glmodule.c md5.h readline.c sre.h tkappinit.c _csv.c _math.c almodule.c cgensupport.h flmodule.c grpmodule.c md5module.c resource.c sre_constants.h tkinter.h _ctypes _math.h ar_beos cjkcodecs fmmodule.c imageop.c mmapmodule.c rotatingtree.c stropmodule.c unicodedata.c _curses_panel.c _multiprocessing arraymodule.c clmodule.c fpectlmodule.c imgfile.c nismodule.c rotatingtree.h sunaudiodev.c unicodedata_db.h _cursesmodule.c _randommodule.c audioop.c cmathmodule.c fpetestmodule.c itertoolsmodule.c operator.c selectmodule.c svmodule.c unicodename_db.h _elementtree.c _sqlite binascii.c config.c.in future_builtins.c ld_so_aix.in ossaudiodev.c sgimodule.c symtablemodule.c xxmodule.c _functoolsmodule.c _sre.c bsddb.h cryptmodule.c gc_weakref.txt ld_so_beos parsermodule.c sha256module.c syslogmodule.c xxsubtype.c _hashopenssl.c _ssl.c bsddbmodule.c cstubs gcmodule.c linuxaudiodev.c posixmodule.c sha512module.c termios.c yuv.h root at x064:[/data/prj/aixtools/python/Python-2.7.12]ln -s ./Modules/ld_so_aix ../src/Python-2.7.12/Modules root at x064:[/data/prj/aixtools/python/Python-2.7.12]ls -l ../src/Python-2.7.12/Modules/ld_so_aix lrwxrwxrwx 1 root system 19 Jul 27 08:00 ../src/Python-2.7.12/Modules/ld_so_aix -> ./Modules/ld_so_aix root at x064:[/data/prj/aixtools/python/Python-2.7.12] This fails as a symbolic link: root at x064:[/data/prj/aixtools/python/Python-2.7.12]buildaix --without-computed-gotos VRMF 2.7.12.0 do_configure: using existing Makefile do_configure: run distclean to get a standard AIX configure -rw-r----- 1 root system 52350 Jul 27 07:57 ./Makefile -rw-r----- 1 root system 732150 Jul 27 07:57 config.log -rwxr-x--x 1 root system 39198 Jul 27 07:57 config.status + > .buildaix/make.out "../src/Python-2.7.12/Objects/typeobject.c", line 6243.26: 1506-068 (W) Operation between types "void*" and "struct _object*(*)(struct _object*)" is not allowed. "../src/Python-2.7.12/Objects/typeobject.c", line 6290.22: 1506-068 (W) Operation between types "void*" and "long(*)(struct _object*)" is not allowed. "../src/Python-2.7.12/Objects/typeobject.c", line 6490.18: 1506-068 (W) Operation between types "void*" and "long(*)(struct _object*)" is not allowed. unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for M is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for N is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for O is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for P is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for Q is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for R is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for S is not valid. Type unsigned assumed. unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory unable to execute '../src/Python-2.7.12/Modules/ld_so_aix': No such file or directory interruptedroot at x064:[/data/prj/aixtools/python/Python-2.7.12] root at x064:[/data/prj/aixtools/python/Python-2.7.12]ln -f ./Modules/ld_so_aix ../src/Python-2.7.12/Modules root at x064:[/data/prj/aixtools/python/Python-2.7.12]ls -l ../src/Python-2.7.12/Modules/ld_so_aix -rwxr-x--x 2 root system 6208 Jul 27 07:57 ../src/Python-2.7.12/Modules/ld_so_aix Trying again as a hard-link - fewer messages, but it still fails. root at x064:[/data/prj/aixtools/python/Python-2.7.12]make clean find ../src/Python-2.7.12 -name '*.py[co]' -exec rm -f {} ';' find . -name '*.[oa]' -exec rm -f {} ';' find . -name '*.s[ol]' -exec rm -f {} ';' find . -name '*.so.[0-9]*.[0-9]*' -exec rm -f {} ';' find build -name 'fficonfig.h' -exec rm -f {} ';' || true find build -name 'fficonfig.py' -exec rm -f {} ';' || true rm -f Lib/lib2to3/*Grammar*.pickle rm -rf build root at x064:[/data/prj/aixtools/python/Python-2.7.12]buildaix --without-computed-gotos VRMF 2.7.12.0 do_configure: using existing Makefile do_configure: run distclean to get a standard AIX configure -rw-r----- 1 root system 52350 Jul 27 07:57 ./Makefile -rw-r----- 1 root system 732150 Jul 27 07:57 config.log -rwxr-x--x 1 root system 39198 Jul 27 07:57 config.status + > .buildaix/make.out "../src/Python-2.7.12/Objects/typeobject.c", line 6243.26: 1506-068 (W) Operation between types "void*" and "struct _object*(*)(struct _object*)" is not allowed. "../src/Python-2.7.12/Objects/typeobject.c", line 6290.22: 1506-068 (W) Operation between types "void*" and "long(*)(struct _object*)" is not allowed. "../src/Python-2.7.12/Objects/typeobject.c", line 6490.18: 1506-068 (W) Operation between types "void*" and "long(*)(struct _object*)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for M is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for N is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for O is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for P is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for Q is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for R is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for S is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/pyexpat.c", line 1538.27: 1506-068 (W) Operation between types "void*" and "void(*)(void*,const char*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 3406.27: 1506-068 (W) Operation between types "void*" and "int(*)(void)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 3954.31: 1506-280 (W) Function argument assignment between types "int(*)(void)" and "void*" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5695.63: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,const void*,unsigned long)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5696.62: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,int,unsigned long)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5697.65: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const char*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5698.60: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(void*,struct _object*,struct _object*)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5700.66: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const unsigned short*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/callproc.c", line 837.32: 1506-280 (W) Function argument assignment between types "void(*)(void)" and "void*" is not allowed. Assembler: /tmp/xlcS0Jxigid.s: line 160: 1252-149 Instruction extsb is not implemented in the current assembly mode COM. + make install DESTDIR=/var/aixtools/python/Python/2.7.12.0 > .buildaix/install.out "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for M is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for N is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for O is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for P is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for Q is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for R is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for S is not valid. Type unsigned assumed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/pyexpat.c", line 1538.27: 1506-068 (W) Operation between types "void*" and "void(*)(void*,const char*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 3406.27: 1506-068 (W) Operation between types "void*" and "int(*)(void)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 3954.31: 1506-280 (W) Function argument assignment between types "int(*)(void)" and "void*" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5695.63: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,const void*,unsigned long)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5696.62: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,int,unsigned long)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5697.65: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const char*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5698.60: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(void*,struct _object*,struct _object*)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/_ctypes.c", line 5700.66: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const unsigned short*,int)" is not allowed. "/data/prj/aixtools/python/src/Python-2.7.12/Modules/_ctypes/callproc.c", line 837.32: 1506-280 (W) Function argument assignment between types "void(*)(void)" and "void*" is not allowed. Assembler: /tmp/xlcS0hxAmMd.s: line 160: 1252-149 Instruction extsb is not implemented in the current assembly mode COM. Traceback (most recent call last): File "/var/aixtools/python/Python/2.7.12.0/opt/lib/python2.7/compileall.py", line 16, in import struct File "/var/aixtools/python/Python/2.7.12.0/opt/lib/python2.7/struct.py", line 1, in from _struct import * ImportError: No module named _struct make: 1254-004 The error code from the last command is 1. Stop. make install returned an error root at x064:[/data/prj/aixtools/python/Python-2.7.12] ---------- components: Installation messages: 271440 nosy: Michael.Felt priority: normal severity: normal status: open title: build on AIX fails when builddir != srcdir, more than bad path to ld_so_aix type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 05:30:33 2016 From: report at bugs.python.org (Florian Preinstorfer) Date: Wed, 27 Jul 2016 09:30:33 +0000 Subject: [New-bugs-announce] [issue27633] Doc: Add missing version info to email.parser Message-ID: <1469611833.34.0.859096267207.issue27633@psf.upfronthosting.co.za> New submission from Florian Preinstorfer: The versionchanged field has no version info for message_from_string(). ---------- files: email-parser-add_version_info.patch keywords: patch messages: 271442 nosy: notizblock priority: normal severity: normal status: open title: Doc: Add missing version info to email.parser type: enhancement versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43908/email-parser-add_version_info.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 07:54:56 2016 From: report at bugs.python.org (Przemyslaw Wegrzyn) Date: Wed, 27 Jul 2016 11:54:56 +0000 Subject: [New-bugs-announce] [issue27634] selectors.SelectSelectors fails if select.select was patched Message-ID: <1469620496.01.0.933139136376.issue27634@psf.upfronthosting.co.za> New submission from Przemyslaw Wegrzyn: The SelectSelector makes a local copy of select.select() built-in and calls it via self._select later on. It no longer works if select.select() built-in is replaced with function (something gevent's monkey patching does). Currently gevent employs a workaround - it overwrites SelectSelector._select. It wouldn't be necessary if SelectSelector could cope with select.select() being a regular function. Attached is a file reproducing the issue. ---------- components: Library (Lib) files: t_s.py messages: 271446 nosy: Przemyslaw Wegrzyn priority: normal severity: normal status: open title: selectors.SelectSelectors fails if select.select was patched type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file43909/t_s.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 13:07:25 2016 From: report at bugs.python.org (July Tikhonov) Date: Wed, 27 Jul 2016 17:07:25 +0000 Subject: [New-bugs-announce] [issue27635] pickle documentation says that unpickling may not call __new__ Message-ID: <1469639245.7.0.966654223743.issue27635@psf.upfronthosting.co.za> New submission from July Tikhonov: A note just below object.__setstate__() documentation https://docs.python.org/3.6/library/pickle.html#object.__setstate__ says that """ ? the type should implement __getnewargs__() or __getnewargs_ex__() to establish such an invariant; otherwise, neither __new__() nor __init__() will be called. """ I believe that note about not calling __new__() was relevant in python2. I could not find case in python3 in which __new__() would not be called. And __init__() is not called anyway, as far as I understand (unless explicitly by __setstate__() or something). Python 3.6.0a3+ (default:da9898e7e90d, Jul 27 2016, 19:51:12) [GCC 4.9.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> class C: ... def __getstate__(self): return {'foo' : self.foo} ... def __setstate__(self, state): self.foo = state['foo'] ... def __new__(cls): ... print('__new__ is called'); return super().__new__(cls) ... def __init__(self): ... print('__init__ is called'); self.foo = None; super().__init__() ... >>> c = C(); c.foo = 'bar' __new__ is called __init__ is called >>> import pickle >>> c2 = pickle.loads(pickle.dumps(c)) __new__ is called >>> c2.foo 'bar' ---------- assignee: docs at python components: Documentation messages: 271465 nosy: docs at python, july priority: normal severity: normal status: open title: pickle documentation says that unpickling may not call __new__ versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 23:04:28 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 28 Jul 2016 03:04:28 +0000 Subject: [New-bugs-announce] [issue27636] Refactor IDLE htest Message-ID: <1469675068.09.0.412407912627.issue27636@psf.upfronthosting.co.za> New submission from Terry J. Reedy: idlelib.idle_test.htest Extract a App(Tk) subclass from run function and nested function. Pass that as master instead of bare root. Extract HTest(Toplevel) class with the common code in files with an htest function. Attach HTest to App as an attribute so htest functions can instantiate or subclass. ---------- assignee: terry.reedy components: IDLE messages: 271486 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Refactor IDLE htest type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 23:15:12 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 28 Jul 2016 03:15:12 +0000 Subject: [New-bugs-announce] [issue27637] int.to_bytes(-1, ...) should automatically choose required count of bytes Message-ID: <1469675712.56.0.174576481029.issue27637@psf.upfronthosting.co.za> New submission from ???? ?????????: It will be nice if `int.to_bytes` be able to automatically choose number of bytes to serialize. If so, I could write serialisation code: def serialize(value: int, signed=True) -> bytes: x = value.to_bytes(-1, 'big', signed=signed) l = value.to_bytes(4, 'big', signed=False) return l + x assert len(serialize(0)) == 4 + 0 # see Issue27623 assert len(serialize(120)) == 4 + 1 assert len(serialize(130)) == 4 + 2 assert len(serialize(130), False) == 4 + 1 ---------- components: Library (Lib) messages: 271488 nosy: mmarkk priority: normal severity: normal status: open title: int.to_bytes(-1, ...) should automatically choose required count of bytes type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 27 23:32:33 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 28 Jul 2016 03:32:33 +0000 Subject: [New-bugs-announce] [issue27638] int.to_bytes() and int.from_bytes() should support 'net' and 'host' byte orders Message-ID: <1469676753.14.0.293041836709.issue27638@psf.upfronthosting.co.za> New submission from ???? ?????????: int.to_bytes() and int.from_bytes() should support 'net' and 'host' byte orders. I will provide a patch. ---------- messages: 271490 nosy: mmarkk priority: normal severity: normal status: open title: int.to_bytes() and int.from_bytes() should support 'net' and 'host' byte orders _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 02:15:07 2016 From: report at bugs.python.org (Anton Backer) Date: Thu, 28 Jul 2016 06:15:07 +0000 Subject: [New-bugs-announce] [issue27639] UserList.__getitem__ doesn't account for slices Message-ID: <1469686507.89.0.362648270021.issue27639@psf.upfronthosting.co.za> New submission from Anton Backer: The docs for UserList say: > List operations which return a new sequence attempt to create an instance of the actual implementation class. However, UserList([])[:] returns a list, not a UserList. ---------- components: Library (Lib) files: patch messages: 271503 nosy: staticshock priority: normal severity: normal status: open title: UserList.__getitem__ doesn't account for slices type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file43914/patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 06:05:17 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 28 Jul 2016 10:05:17 +0000 Subject: [New-bugs-announce] [issue27640] add the '--disable-test-suite' option to configure Message-ID: <1469700317.99.0.84265252625.issue27640@psf.upfronthosting.co.za> New submission from Xavier de Gaye: Do not install the Python test suite when configure is run with '--disable-test-suite'. This about divides by two the size of the installed standard library. Related to issue 26852: add the '--enable-legacy-pyc-files' option to configure. The attached listdirs.py script may be used to check that the set of sub-directories in the std library is not changed by the patch. ---------- assignee: xdegaye components: Build files: disable-test-suite.patch keywords: patch messages: 271514 nosy: doko, martin.panter, xdegaye priority: normal severity: normal stage: patch review status: open title: add the '--disable-test-suite' option to configure type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43917/disable-test-suite.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:04:44 2016 From: report at bugs.python.org (Thomas Perl) Date: Thu, 28 Jul 2016 11:04:44 +0000 Subject: [New-bugs-announce] [issue27641] Do not build Programs/_freeze_importlib when cross-compiling Message-ID: <1469703884.83.0.465404999691.issue27641@psf.upfronthosting.co.za> New submission from Thomas Perl: Based on http://bugs.python.org/issue27490 and http://bugs.python.org/msg271495, here is a patch that makes sure Programs/_freeze_importlib is only built when not cross-compiling. ---------- components: Cross-Build files: python-freeze-importlib-cross-compiling.patch keywords: patch messages: 271519 nosy: Alex.Willmer, Thomas Perl, martin.panter priority: normal severity: normal status: open title: Do not build Programs/_freeze_importlib when cross-compiling type: behavior versions: Python 2.7, Python 3.6 Added file: http://bugs.python.org/file43920/python-freeze-importlib-cross-compiling.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 07:58:25 2016 From: report at bugs.python.org (Decorater) Date: Thu, 28 Jul 2016 11:58:25 +0000 Subject: [New-bugs-announce] [issue27642] import and __import__() fails silently without a ImportError and does not add the module to the file's namespace. Message-ID: <1469707105.59.0.0648357664764.issue27642@psf.upfronthosting.co.za> New submission from Decorater: So, I have some code. I tried to make a 'plugin' for my bot I made in python. However it seems to not be able to import it which it should be able to. The code I used is here: https://bpaste.net/show/e4445c47490d I dont even know why it is not addign it to the file's namespace or even adding it to sys.modules either. ---------- messages: 271533 nosy: Decorater priority: normal severity: normal status: open title: import and __import__() fails silently without a ImportError and does not add the module to the file's namespace. versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 11:01:29 2016 From: report at bugs.python.org (Michael Felt) Date: Thu, 28 Jul 2016 15:01:29 +0000 Subject: [New-bugs-announce] [issue27643] test_ctypes fails on AIX with xlc Message-ID: <1469718089.88.0.404760174195.issue27643@psf.upfronthosting.co.za> New submission from Michael Felt: I am preparing a system with gcc to see if it is compiler related, i.e., goes away with gcc. On the one hand, fingers crossed - but on the other, having bitfields working regardless of the compiler should be preferred. This issue is similar to a Solaris (C compiler) http://bugs.python.org/issue16275 During the build using clc _ get these messages - which make me hope it is an unexpected compiler issue. "/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for M is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for N is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for O is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for P is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for Q is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for R is not valid. Type unsigned assumed. "/data/prj/aixtools/python/python-2.7.12.1/Modules/_ctypes/_ctypes_test.c", line 382.5: 1506-159 (E) Bit field type specified for S is not valid. Type unsigned assumed. Note: I modified test_bitfields to do an additional print. Maybe this gives an idea about what the issue is (when considering the compiler messages) root at x064:[/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test]../../../python ./runtests.py A 0x1001f 0 B 0x2001d 0 C 0x3001a 0 D 0x40016 0 E 0x50011 0 F 0x6000b 0 G 0x70004 0 H 0x80018 4 I 0x9000f 4 M 0x1000e 6 N 0x2000c 6 O 0x30009 6 P 0x40005 6 Q 0x50000 6 R 0x6000a 8 S 0x70003 8 .............s....................ssss............................ssssssssssssssssssssssssssss...s.......s.....................sssssssssssssssssssss......s...........s....s.....................FF...s...............................................s.............sssss.ss....s.......ss..sss...................s......s.....................s..................................................s...........ss.sssss................s.s.............s. ====================================================================== FAIL: test_ints (ctypes.test.test_bitfields.C_Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test/test_bitfields.py", line 41, in test_ints self.assertEqual((name, i, getattr(b, name)), (name, i, func(byref(b), name))) AssertionError: Tuples differ: ('A', 1, -1) != ('A', 1, 1) First differing element 2: -1 1 - ('A', 1, -1) ? - + ('A', 1, 1) ====================================================================== FAIL: test_shorts (ctypes.test.test_bitfields.C_Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test/test_bitfields.py", line 48, in test_shorts self.assertEqual((name, i, getattr(b, name)), (name, i, func(byref(b), name))) AssertionError: Tuples differ: ('M', 1, -1) != ('M', 1, 1) First differing element 2: -1 1 - ('M', 1, -1) ? - + ('M', 1, 1) ---------------------------------------------------------------------- Ran 440 tests in 0.883s (0 modules skipped) Unavailable resources: printing, refcount FAILED (failures=2) root at x064:[/data/prj/aixtools/python/python-2.7.12.1/Lib/ctypes/test] ---------- messages: 271555 nosy: Michael.Felt priority: normal severity: normal status: open title: test_ctypes fails on AIX with xlc versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 13:29:04 2016 From: report at bugs.python.org (Michael Lee) Date: Thu, 28 Jul 2016 17:29:04 +0000 Subject: [New-bugs-announce] [issue27644] Expand documentation about type aliases and NewType in the typing module Message-ID: <1469726944.72.0.582694680461.issue27644@psf.upfronthosting.co.za> New submission from Michael Lee: This is a patch to update the documentation on the typing module. It expands the section on type aliases and adds a section on [NewType][0]. Since support for NewType was [recently added][1] to mypy, it seemed like a prudent time to update the docs to describe this new feature. The section on type aliases was mainly expanded because the distinction between type aliases and NewType could be potentially confusing, so adding extra clarification seemed like a good idea. [0]: https://www.python.org/dev/peps/pep-0484/#newtype-helper-function [1]: https://github.com/python/mypy/pull/1939 ---------- assignee: docs at python components: Documentation files: document_newtype.patch keywords: patch messages: 271572 nosy: docs at python, michael0x2a priority: normal severity: normal status: open title: Expand documentation about type aliases and NewType in the typing module versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43926/document_newtype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 13:48:18 2016 From: report at bugs.python.org (Lele Gaifax) Date: Thu, 28 Jul 2016 17:48:18 +0000 Subject: [New-bugs-announce] [issue27645] Supporting native backup facility of SQLite Message-ID: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za> New submission from Lele Gaifax: It would be nice if the sqlite3 stdlib module could expose the SQLite Online Backup API. I'm willing to implement it, as encouraged by Paul Moore. See also: https://mail.python.org/pipermail/python-dev/2016-July/145570.html ---------- components: Extension Modules messages: 271574 nosy: lelit priority: normal severity: normal status: open title: Supporting native backup facility of SQLite type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 14:30:50 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 28 Jul 2016 18:30:50 +0000 Subject: [New-bugs-announce] [issue27646] yield from expression can be any iterable Message-ID: <1469730650.89.0.176012351897.issue27646@psf.upfronthosting.co.za> New submission from Terry J. Reedy: https://docs.python.org/3/reference/expressions.html#yield-expressions says "When yield from is used, it treats the supplied expression as a subiterator. All values produced by that subiterator ...". To me "treats..expression as a subiterator" means that the expression must *be* an iterator, such as returned by iter or calling a generator function. Hence I was surprised upon reading "yield from " in stdlib code. I confirmed that this usage is correct by trying >>> def g(): yield from (1,2) >>> i = g() >>> next(i), next(i) (1, 2) and then reading the PEP380 Formal Semantics, which begins with "_i = iter(EXPR)". Hence I suggest the following replacement for the quote above: "When yield from is used, the expression must be an iterable. A subiterator is obtained with iter(). All values produced by that subiterator ...". Note that 'subiterator' is spelled in the following sentences 'underlying iterable' (which I am not sure I like) and 'sub-iterator' (and 'sub-generator'). I think we should be consistent for at least the two short 'yield from' paragraphs. ---------- assignee: docs at python components: Documentation messages: 271577 nosy: docs at python, terry.reedy priority: normal severity: normal stage: patch review status: open title: yield from expression can be any iterable type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 28 16:19:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Jul 2016 20:19:54 +0000 Subject: [New-bugs-announce] [issue27647] Update Windows build to Tcl/Tk 8.6.6 Message-ID: <1469737194.88.0.144648917966.issue27647@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Current Tcl/Tk version in Windows build is 8.6.4.2. Tcl/Tk 8.6.6 was released yesterday. https://sourceforge.net/p/tcl/mailman/message/35246302/ ---------- components: Tkinter, Windows messages: 271581 nosy: paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: Update Windows build to Tcl/Tk 8.6.6 versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 00:54:43 2016 From: report at bugs.python.org (=?utf-8?b?6rmA7YOc7ZmY?=) Date: Fri, 29 Jul 2016 04:54:43 +0000 Subject: [New-bugs-announce] [issue27648] Message of webbrowser.py something wrong. Message-ID: <1469768083.59.0.550605115431.issue27648@psf.upfronthosting.co.za> New submission from ???: I'm using Python 3.5.1+ and Ubuntu 16.04. When I open new tab to Chrome using 'webbrowser.open()'. Some message prints next to shell prompt like below. ``` asd ???? ???????... ? ?? ???? ??? ?? Save Page ??? ?????! ['asd'] (Shell prompt) $ ?? ???? ??? ? ?? ??????. ``` First three line is my program's message, please don't care about them. Problem happened at final line. '?? ???? ??? ? ?? ??????.' means Program created new window to existing browser session. I think that message is for webbrowser.py and it prints with shell prompt. So, I was reading webbrowser.py simply but I cannot find where it prints message. Thanks. ---------- components: Library (Lib) messages: 271603 nosy: ??? priority: normal severity: normal status: open title: Message of webbrowser.py something wrong. type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 06:54:15 2016 From: report at bugs.python.org (Ian Cordasco) Date: Fri, 29 Jul 2016 10:54:15 +0000 Subject: [New-bugs-announce] [issue27649] multiprocessing on Windows does not properly manage class attributes Message-ID: <1469789655.87.0.612290090536.issue27649@psf.upfronthosting.co.za> New submission from Ian Cordasco: In trying to add support for multiprocessing on Windows in Flake8, I found that the behaviour of the module is significantly different than on Unix. If you have a class that has class-level attributes on Unix, and you change them, put the class into a Queue (or have it attached to an object that moves through a Queue) then the values you set will be preserved [1]. On Windows [2], the attributes are reset. As a minimal reproduction, I've thrown together this project: https://github.com/sigmavirus24/windows-multiprocessing-bug which is running tox on AppVeyor (https://ci.appveyor.com/project/sigmavirus24/windows-multiprocessing-bug) and Travis CI (https://travis-ci.org/sigmavirus24/windows-multiprocessing-bug) so the behaviours can be compared. For application developers, it would be wonderful if we could rely on the standard library behaving the same way in this case across both operating systems. [1] https://travis-ci.org/sigmavirus24/windows-multiprocessing-bug/jobs/148276925#L158 https://travis-ci.org/sigmavirus24/windows-multiprocessing-bug/jobs/148276926#L158 https://travis-ci.org/sigmavirus24/windows-multiprocessing-bug/jobs/148276927#L157 [2] https://ci.appveyor.com/project/sigmavirus24/windows-multiprocessing-bug/build/1.0.2#L24 ---------- components: Windows messages: 271618 nosy: icordasc, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: multiprocessing on Windows does not properly manage class attributes type: behavior versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 29 16:09:25 2016 From: report at bugs.python.org (Ram Rachum) Date: Fri, 29 Jul 2016 20:09:25 +0000 Subject: [New-bugs-announce] [issue27650] Implement `__repr__` methods for logging.Logger and others Message-ID: <1469822965.14.0.109412472968.issue27650@psf.upfronthosting.co.za> New submission from Ram Rachum: A while ago I was debugging through code that uses the `logging` module, and I was looking at `Logger` objects and possibly other kinds of objects (maybe handlers? It was a while ago.) I was frustrated because I was trying to figure out what a particular logger was, but typing `logger` in the shell just showed the opaque ``. I would like to know the name of the logger without bothering to do `logger.name`. I suggest that we do a run over the `logging` module and see which classes could have a helpful `__repr__` added to them. I might have time to do this, but first I want to know whether there is a general agreement that such a patch would be welcome. ---------- components: Library (Lib) messages: 271646 nosy: cool-RR, vinay.sajip priority: normal severity: normal status: open title: Implement `__repr__` methods for logging.Logger and others type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 05:54:42 2016 From: report at bugs.python.org (eatrawmeat391) Date: Sat, 30 Jul 2016 09:54:42 +0000 Subject: [New-bugs-announce] [issue27651] About bytearray Message-ID: <1469872482.04.0.0838783144311.issue27651@psf.upfronthosting.co.za> New submission from eatrawmeat391: I converted a function name yuke_bpe from C and ran into an unknown issue after running it.The code works but it emptied all of my bytearray. You can reproduce the problem by doing it in the command line from unbpe import yuke_bpe a = bytearray("This is a byte array") b = yuke_bpe(a, 100 ,1) You'll see that bytearray a is empty after the yuke_bpe function calling but the function never touches that variable ---------- components: Windows files: unbpe.py messages: 271674 nosy: eatrawmeat391, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: About bytearray versions: Python 2.7 Added file: http://bugs.python.org/file43947/unbpe.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 06:43:39 2016 From: report at bugs.python.org (Ed Schouten) Date: Sat, 30 Jul 2016 10:43:39 +0000 Subject: [New-bugs-announce] [issue27652] [Patch] Make use of non-standard error number ESHUTDOWN optional Message-ID: <1469875419.81.0.269942843817.issue27652@psf.upfronthosting.co.za> New submission from Ed Schouten: While porting Python over to CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), we noticed that the core Python code maps ESHUTDOWN over to BrokenPipeError. This is fine, except for the fact that ESHUTDOWN is used unconditionally. It's not part of POSIX. Attached is a patch to make its use optional. ---------- components: Interpreter Core files: patch-no-eshutdown messages: 271678 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Make use of non-standard error number ESHUTDOWN optional versions: Python 3.6 Added file: http://bugs.python.org/file43948/patch-no-eshutdown _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 06:50:24 2016 From: report at bugs.python.org (Ed Schouten) Date: Sat, 30 Jul 2016 10:50:24 +0000 Subject: [New-bugs-announce] [issue27653] [Patch] Also disable the use of on CloudABI Message-ID: <1469875824.89.0.74501910418.issue27653@psf.upfronthosting.co.za> New submission from Ed Schouten: While porting Python over to CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), we stumbled upon a small issue that caused the build to fail. As CloudABI is a sandboxed environment, there currently isn't any support for modifying low-level network properties, such as TCP socket attributes. For this reason is missing, just like on a couple of other platforms (Symbian, Cygwin, etc). The attached patch extends the current '#ifndef' to also take CloudABI into consideration. ---------- components: Extension Modules files: patch-no-netinet-tcp_h messages: 271679 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Also disable the use of on CloudABI versions: Python 3.6 Added file: http://bugs.python.org/file43949/patch-no-netinet-tcp_h _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 06:56:14 2016 From: report at bugs.python.org (Ed Schouten) Date: Sat, 30 Jul 2016 10:56:14 +0000 Subject: [New-bugs-announce] [issue27654] [Patch] Use arc4random_buf() on CloudABI Message-ID: <1469876174.92.0.881098138709.issue27654@psf.upfronthosting.co.za> New submission from Ed Schouten: While porting Python over to CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), we stumbled upon a small issue that caused the build to fail. As CloudABI is a sandboxed runtime environment, there is no support for accessing the global filesystem namespace. This means that dev_urandom_noraise()/dev_urandom_python() are not capable of accessing /dev/urandom. The attached change extends these functions to use CloudABI's arc4random_buf() function, which is also present on a lot of other operating systems (the BSDs, Mac OS X, etc). I'm not enabling the use of arc4random_buf() on those operating systems yet, as that should likely be decided by the people responsible for those ports. Alternatively, if we do think arc4random_buf() should be used on all operating systems that support it, we can extend Autoconf to test for its presence. Be sure to let me know and I'll update the patch accordingly. ---------- components: Interpreter Core files: patch-arc4random messages: 271680 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Use arc4random_buf() on CloudABI versions: Python 3.6 Added file: http://bugs.python.org/file43950/patch-arc4random _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 10:30:54 2016 From: report at bugs.python.org (Ed Schouten) Date: Sat, 30 Jul 2016 14:30:54 +0000 Subject: [New-bugs-announce] [issue27655] [Patch] Don't require presence of POLLPRI Message-ID: <1469889054.78.0.928788503913.issue27655@psf.upfronthosting.co.za> New submission from Ed Schouten: RFC 6093 states that applications "SHOULD NOT" make use of TCP's out-of-band data. For this reason, CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) does not provide support for it. This means that its poll() function does provide support for POLLIN and POLLOUT, but not for POLLPRI. Attached is a patch that patches up the selectmodule to not define POLLPRI in case the host environment does not support it. ---------- components: Extension Modules files: pollpri.diff keywords: patch messages: 271689 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Don't require presence of POLLPRI versions: Python 3.6 Added file: http://bugs.python.org/file43951/pollpri.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 11:49:07 2016 From: report at bugs.python.org (Ed Schouten) Date: Sat, 30 Jul 2016 15:49:07 +0000 Subject: [New-bugs-announce] [issue27656] [Patch] Make presence of SCHED_* optional Message-ID: <1469893747.69.0.209169490868.issue27656@psf.upfronthosting.co.za> New submission from Ed Schouten: The SCHED_* constants that are part of POSIX's are all optional: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sched.h.html Python already declares the SCHED_SPORADIC constant as part of the POSIX module optionally, depending on whether it is present in C, but doesn't do this for the other SCHED_* constants. This is problematic for CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), which doesn't support any scheduler interaction at all. Attached is a patch to only define these if present. ---------- components: Extension Modules files: sched.diff keywords: patch messages: 271697 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Make presence of SCHED_* optional versions: Python 3.6 Added file: http://bugs.python.org/file43952/sched.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 15:57:17 2016 From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Lindqvist?=) Date: Sat, 30 Jul 2016 19:57:17 +0000 Subject: [New-bugs-announce] [issue27657] urlparse fails if the path is numeric Message-ID: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za> New submission from Bj?rn Lindqvist: This affects both Python 2 and 3. This is as expected: >>> urlparse('abc:123.html') ParseResult(scheme='abc', netloc='', path='123.html', params='', query='', fragment='') >>> urlparse('123.html:abc') ParseResult(scheme='123.html', netloc='', path='abc', params='', query='', fragment='') >>> urlparse('abc:123/') ParseResult(scheme='abc', netloc='', path='123/', params='', query='', fragment='') This is NOT: >>> urlparse('abc:123') ParseResult(scheme='', netloc='', path='abc:123', params='', query='', fragment='') Expected is path='123' and scheme='abc'. At least according to my reading of the rfc (https://tools.ietf.org/html/rfc1808.html) that is what should happen. ---------- components: Library (Lib) messages: 271702 nosy: Bj?rn.Lindqvist priority: normal severity: normal status: open title: urlparse fails if the path is numeric type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 30 18:19:49 2016 From: report at bugs.python.org (Mario Grgic) Date: Sat, 30 Jul 2016 22:19:49 +0000 Subject: [New-bugs-announce] [issue27658] python 3.5.2 built from source fails to install completely on Mac OS X 10.11.6. Crashes subsequently. Message-ID: <1469917189.39.0.985531249644.issue27658@psf.upfronthosting.co.za> New submission from Mario Grgic: I am on Mac OS X 10.11.6 trying to build and install Python 3.5.2 from source. I only have system Python 2.7.10 , and no other instances of Python 3.x. I configure the build as follows: ./configure --prefix=/Volumes/ramdisk/python3.5.2 The code is built without errors, but when I issue make install I get: cd /Volumes/ramdisk/python3.5.2/share/man/man1; ln -s python3.5.1 python3.1) if test "xupgrade" != "xno" ; then \ case upgrade in \ upgrade) ensurepip="--upgrade" ;; \ install|*) ensurepip="" ;; \ esac; \ ./python.exe -E -m ensurepip \ $ensurepip --root=/ ; \ fi Ignoring indexes: https://pypi.python.org/simple Collecting setuptools Collecting pip Installing collected packages: setuptools, pip /bin/sh: line 7: 15831 Segmentation fault: 11 ./python.exe -E -m ensurepip $ensurepip --root=/ Makefile:1059: recipe for target 'install' failed make: *** [install] Error 139 which crashes the system Python 2.7.10: Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: EXC_I386_GPFLT Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libcrypto.1.0.0.dylib 0x0000000108c82d51 EVP_PKEY_CTX_free + 17 1 libcrypto.1.0.0.dylib 0x0000000108c77742 EVP_MD_CTX_cleanup + 130 2 libcrypto.1.0.0.dylib 0x0000000108c77a9d EVP_DigestFinal + 29 3 _hashlib.cpython-35m-darwin.so 0x0000000108c05d6b EVP_digest + 155 (_hashopenssl.c:148) 4 python.exe 0x000000010835493e PyEval_EvalFrameEx + 24110 (ceval.c:4684) 5 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 6 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 7 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 8 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 9 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 10 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 11 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 12 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 13 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 14 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 15 python.exe 0x000000010834eaee PyEval_EvalCodeEx + 78 (ceval.c:4039) 16 python.exe 0x00000001082b743d function_call + 381 (funcobject.c:627) 17 python.exe 0x000000010828ddd5 PyObject_Call + 101 (abstract.c:2162) 18 python.exe 0x00000001083556a0 PyEval_EvalFrameEx + 27536 (ceval.c:5034) 19 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 20 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 21 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 22 python.exe 0x0000000108359ee2 fast_function + 338 (ceval.c:4803) 23 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 24 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 25 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 26 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 27 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 28 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 29 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 30 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 31 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 32 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 33 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 34 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 35 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 36 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 37 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 38 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 39 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 40 python.exe 0x000000010834ea91 PyEval_EvalCode + 81 (ceval.c:777) 41 python.exe 0x000000010834c2e0 builtin_exec + 528 (bltinmodule.c:957) 42 python.exe 0x00000001082d6ea5 PyCFunction_Call + 165 (methodobject.c:121) 43 python.exe 0x0000000108354f00 PyEval_EvalFrameEx + 25584 (ceval.c:4705) 44 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 45 python.exe 0x0000000108359f60 fast_function + 464 (ceval.c:4818) 46 python.exe 0x000000010835484f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 47 python.exe 0x00000001083596f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 48 python.exe 0x000000010834eaee PyEval_EvalCodeEx + 78 (ceval.c:4039) 49 python.exe 0x00000001082b743d function_call + 381 (funcobject.c:627) 50 python.exe 0x000000010828ddd5 PyObject_Call + 101 (abstract.c:2162) 51 python.exe 0x00000001083976e3 RunModule + 147 (main.c:208) 52 python.exe 0x00000001083970fe Py_Main + 2526 (main.c:709) 53 python.exe 0x00000001082831cd main + 237 (python.c:65) 54 libdyld.dylib 0x00007fff9523b5ad start + 1 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000000000 rbx: 0x149dd2af96bf4325 rcx: 0x00000000000fc080 rdx: 0x0000000000031db0 rdi: 0x149dd2af96bf4325 rsi: 0x000000010856be00 rbp: 0x00007fff5797b130 rsp: 0x00007fff5797b120 r8: 0x0000000000000003 r9: 0x00007fb96b5ba1f0 r10: 0x00000000072e2888 r11: 0x00007fb96b500000 r12: 0x0a0061d3943a3792 r13: 0x0000000109a59fc0 r14: 0x0000000000000001 r15: 0x00007fff5797b1a0 rip: 0x0000000108c82d51 rfl: 0x0000000000010202 cr2: 0x0000000108c82d40 Logical CPU: 2 Error Code: 0x00000000 Trap Number: 13 -------------------------------------------------------- If I add partially installed python 3.5.2 on the system PATH and add alias python=python3 so the makefile calls python3 instead, then installation completes successfully. However, if I now try running pip3 from python3.5.2/bin installation I get another crash in python3 now Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000011 VM Regions Near 0x11: --> __TEXT 00000001025cd000-0000000102778000 [ 1708K] r-x/rwx SM=COW /Volumes/VOLUME/*/*.5 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libcrypto.1.0.0.dylib 0x0000000103301f79 EVP_PKEY_CTX_dup + 25 1 libcrypto.1.0.0.dylib 0x00000001032f692a EVP_MD_CTX_copy_ex + 282 2 _hashlib.cpython-35m-darwin.so 0x0000000103284e03 EVP_hexdigest + 99 (_hashopenssl.c:113) 3 python3.5 0x000000010269f93e PyEval_EvalFrameEx + 24110 (ceval.c:4684) 4 python3.5 0x00000001026a4ee2 fast_function + 338 (ceval.c:4803) 5 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 6 python3.5 0x00000001026a46f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 7 python3.5 0x00000001026a4f60 fast_function + 464 (ceval.c:4818) 8 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 9 python3.5 0x00000001026a4ee2 fast_function + 338 (ceval.c:4803) 10 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 11 python3.5 0x00000001026a46f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 12 python3.5 0x00000001026a4f60 fast_function + 464 (ceval.c:4818) 13 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 14 python3.5 0x00000001026a46f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 15 python3.5 0x00000001026a4f60 fast_function + 464 (ceval.c:4818) 16 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 17 python3.5 0x00000001026a46f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 18 python3.5 0x00000001026a4f60 fast_function + 464 (ceval.c:4818) 19 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 20 python3.5 0x00000001026a4ee2 fast_function + 338 (ceval.c:4803) 21 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 22 python3.5 0x00000001026a4ee2 fast_function + 338 (ceval.c:4803) 23 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 24 python3.5 0x00000001026a46f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 25 python3.5 0x00000001026a4f60 fast_function + 464 (ceval.c:4818) 26 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 27 python3.5 0x00000001026a46f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 28 python3.5 0x00000001026a4f60 fast_function + 464 (ceval.c:4818) 29 python3.5 0x000000010269f84f PyEval_EvalFrameEx + 23871 (ceval.c:4730) 30 python3.5 0x00000001026a46f2 _PyEval_EvalCodeWithName + 4194 (ceval.c:4018) 31 python3.5 0x0000000102699a91 PyEval_EvalCode + 81 (ceval.c:777) 32 python3.5 0x00000001026ca581 PyRun_FileExFlags + 209 (pythonrun.c:976) 33 python3.5 0x00000001026c9c7c PyRun_SimpleFileExFlags + 668 (pythonrun.c:396) 34 python3.5 0x00000001026e23f4 Py_Main + 3284 (main.c:318) 35 python3.5 0x00000001025ce1cd main + 237 (python.c:65) 36 libdyld.dylib 0x00007fff9523b5ad start + 1 Thread 1: 0 libsystem_kernel.dylib 0x00007fff83afb5e2 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff95a85578 _pthread_wqthread + 1283 2 libsystem_pthread.dylib 0x00007fff95a83341 start_wqthread + 13 Thread 2:: Dispatch queue: com.apple.libdispatch-manager 0 libsystem_kernel.dylib 0x00007fff83afbefa kevent_qos + 10 1 libdispatch.dylib 0x00007fff956af165 _dispatch_mgr_invoke + 216 2 libdispatch.dylib 0x00007fff956aedcd _dispatch_mgr_thread + 52 Thread 3: 0 libsystem_kernel.dylib 0x00007fff83afb5e2 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff95a85578 _pthread_wqthread + 1283 2 libsystem_pthread.dylib 0x00007fff95a83341 start_wqthread + 13 Thread 4: 0 libsystem_kernel.dylib 0x00007fff83afb5e2 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff95a85578 _pthread_wqthread + 1283 2 libsystem_pthread.dylib 0x00007fff95a83341 start_wqthread + 13 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000000001 rbx: 0x0000000103b75f48 rcx: 0x0000000000000010 rdx: 0xffffffffffffffd4 rdi: 0x00007fdb83c51140 rsi: 0x00007fdb83ca1410 rbp: 0x00007fff5d630c40 rsp: 0x00007fff5d630c30 r8: 0x0000000000000006 r9: 0x0000000000000000 r10: 0x00000000ffffffff r11: 0x00000000000027c0 r12: 0x990018d2e679ec80 r13: 0x0000000103c78288 r14: 0x00007fff5d630c80 r15: 0x00007fdb83ca3b80 rip: 0x0000000103301f79 rfl: 0x0000000000010202 cr2: 0x0000000000000011 Logical CPU: 2 Error Code: 0x00000004 Trap Number: 14 ---------- components: Installation messages: 271710 nosy: Mario Grgic priority: normal severity: normal status: open title: python 3.5.2 built from source fails to install completely on Mac OS X 10.11.6. Crashes subsequently. type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 03:04:38 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sun, 31 Jul 2016 07:04:38 +0000 Subject: [New-bugs-announce] [issue27659] Check for the existence of crypt() Message-ID: <1469948678.43.0.816389049938.issue27659@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: On Android the crypt() function is missing, causing ugly linking errors when compiling the _crypt module. This patch handles it elegantly. A question: should I include changes to configure and pyconfig.h.in in the patch? ---------- components: Cross-Build files: check-crypt.patch keywords: patch messages: 271727 nosy: Alex.Willmer, Chi Hsuan Yen, xdegaye priority: normal severity: normal status: open title: Check for the existence of crypt() type: compile error versions: Python 3.6 Added file: http://bugs.python.org/file43954/check-crypt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 13:40:09 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 31 Jul 2016 17:40:09 +0000 Subject: [New-bugs-announce] [issue27660] Replace size_t with Py_ssize_t as the type of local variable in list_resize Message-ID: <1469986809.78.0.371731130003.issue27660@psf.upfronthosting.co.za> New submission from Xiang Zhang: In list_resize, new_allocated is of type size_t but I think don't have to be now since it finally have to assign back to self->allocated which is of type Py_ssize_t. With Py_ssize_t, we can check some overflows in the first overflow check and don't need the second overflow check. ---------- components: Interpreter Core files: list_resize.patch keywords: patch messages: 271746 nosy: martin.panter, xiang.zhang priority: normal severity: normal status: open title: Replace size_t with Py_ssize_t as the type of local variable in list_resize type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43957/list_resize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 31 18:12:21 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 31 Jul 2016 22:12:21 +0000 Subject: [New-bugs-announce] [issue27661] Add tzinfo= argument to datetime.combine Message-ID: <1470003141.22.0.331878271067.issue27661@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: Add an optional tzinfo argument to datetime.combine() so that datetime.combine(d, t, info) returns the same object as datetime.combine(d, t).replace(tzinfo=info) but without creating an intermediate naive instance. Guido's LGTM: https://mail.python.org/pipermail/datetime-sig/2016-July/000993.html ---------- assignee: belopolsky messages: 271751 nosy: belopolsky priority: normal severity: normal status: open title: Add tzinfo= argument to datetime.combine type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________