': uninitialized constant FOO (NameError) $ cat test3 " #{ @@ } " $ ruby test3 test3:3: `@@' without identifiers is not allowed as a class variable name test3:3: syntax error, unexpected end-of-input Added the author and the primary reviewer of issue24965. ---------- components: Interpreter Core messages: 283874 nosy: Chi Hsuan Yen, eric.smith, martin.panter priority: normal severity: normal status: open title: Improve error reporting involving f-strings (PEP 498) type: enhancement versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 23 07:11:24 2016 From: report at bugs.python.org (Karsten Tinnefeld) Date: Fri, 23 Dec 2016 12:11:24 +0000 Subject: [New-bugs-announce] [issue29052] Detect Windows platform 32bit/64bit automatically Message-ID: <1482495084.23.0.916471956703.issue29052@psf.upfronthosting.co.za> New submission from Karsten Tinnefeld: When navigating https://www.python.org/ with a browser, in the main menu fly-out Downloads/Download for Windows it suggests to download the 32 bit version of the current 2.x and 3.x releases (leaving out the information that the buttons provide 32 bit binaries). Further, https://www.python.org/downloads/ repeats this pattern in its header area "Download the latest version for Windows". May I suggest that, depending on the User-Agent header, the menu offers 64 bit versions of the interpreter and tools package by default in case the browser suggests it is running on a 64 bit platform? According to own tests and http://www.useragentstring.com/pages/useragentstring.php, this should be possible with a regexp like '(WOW|x)64' on at least IE, FF, Chrome and Edge. ---------- assignee: docs at python components: Documentation messages: 283875 nosy: Karsten Tinnefeld, docs at python priority: normal severity: normal status: open title: Detect Windows platform 32bit/64bit automatically type: enhancement versions: Python 2.7, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 23 09:16:48 2016 From: report at bugs.python.org (bpoaugust) Date: Fri, 23 Dec 2016 14:16:48 +0000 Subject: [New-bugs-announce] [issue29053] Implement >From_ decoding on input from mbox Message-ID: <1482502608.45.0.127449678115.issue29053@psf.upfronthosting.co.za> New submission from bpoaugust: The email package implements mboxo From_ mangling on output by default. However there is no provision to unmangle >From_ on input. This means that it's not possible to import mboxo files correctly. ---------- components: email messages: 283879 nosy: barry, bpoaugust, r.david.murray priority: normal severity: normal status: open title: Implement >From_ decoding on input from mbox type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 23 09:17:17 2016 From: report at bugs.python.org (Cornelius Diekmann) Date: Fri, 23 Dec 2016 14:17:17 +0000 Subject: [New-bugs-announce] [issue29054] pty.py: pty.spawn hangs after client disconnect over nc (netcat) Message-ID: <1482502637.76.0.304881442895.issue29054@psf.upfronthosting.co.za> New submission from Cornelius Diekmann: My OS: Debian GNU/Linux 8.6 (jessie) Python 3.4.2 pty.py from Python-3.5.2/Lib (pty.py is just a tiny, portable python file which did not see many changes) Bug Report Steps to Reproduce: I wrote a very simple python remote shell: #!/usr/bin/env python3 import pty pty.spawn('/bin/sh') It can be run in a terminal (call it TermA) with `nc -e ./myfancypythonremoteshell.py -l -p 6699` In a different terminal (call it TermB), I connect to my fancy remote shell with `nc 127.0.0.1 6699`. The shell works fine. In TermB, I quit by pressing ctrl+c. Observed Behavior: In TermA, the nc process, the python process, and the spawned /bin/sh still exist. They still occupy TermA. Expected Behavior: The client in TermB has disconnected, /bin/sh in TermA can no longer read anything from stdin and it should close down. Ultimately, in TermA, nc should have exited successfully. Fix: End the _copy loop in pty.py once EOF in STDIN is reached. Everything shuts itself down automatically. I included a small patch to demonstrate this behavior. This patch is not meant to go straight into production. I have not verified if this behavior somehow breaks other use cases. This bug report is meant to document exactly one specific use case and supply exactly one line of code change for it. This issue is related to issue26228. Actually, it is complementary. issue26228 wants to return if master_fd is EOF, this issue wants to return if stdin is EOF. Both behaviors together looks good to me. By the way, I hacked a hacky `assert False` into my patch as a placeholder for issue26228's proper handling of exec failures at that part of the code. I suggest to combine the patches of this issue and issue26228. ---------- components: Library (Lib) files: pty.patch keywords: patch messages: 283880 nosy: Cornelius Diekmann, martin.panter priority: normal severity: normal status: open title: pty.py: pty.spawn hangs after client disconnect over nc (netcat) type: enhancement versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file46006/pty.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 23 10:56:58 2016 From: report at bugs.python.org (then0rTh) Date: Fri, 23 Dec 2016 15:56:58 +0000 Subject: [New-bugs-announce] [issue29055] random.choice on empty sequence should hide previous exception [patch] Message-ID: <1482508618.0.0.189699213254.issue29055@psf.upfronthosting.co.za> New submission from then0rTh: Passing empty sequence to random.choice function leads to: Traceback (most recent call last): ... ValueError: number of bits must be greater than zero During handling of the above exception, another exception occurred: Traceback (most recent call last): ... IndexError: Cannot choose from an empty sequence * the ValueError doesn't add any useful information, only bloats stderr * the "During handling" line indicates that something went wrong inside random.py This patch uses `raise x from None` to hide the ValueError, resulting in much cleaner output. -Tested on Python 3.7.0a0 ---------- components: Library (Lib) files: random_choice_errmsg.patch keywords: patch messages: 283884 nosy: mark.dickinson, rhettinger, then0rTh priority: normal severity: normal status: open title: random.choice on empty sequence should hide previous exception [patch] type: behavior versions: Python 3.7 Added file: http://bugs.python.org/file46007/random_choice_errmsg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 23 12:26:56 2016 From: report at bugs.python.org (Dan Passaro) Date: Fri, 23 Dec 2016 17:26:56 +0000 Subject: [New-bugs-announce] [issue29056] logging.Formatter doesn't respect more than one formatException() Message-ID: <1482514016.63.0.534341960628.issue29056@psf.upfronthosting.co.za> New submission from Dan Passaro: If two formatters maintain the default implementation of Formatter.format(), but provide custom behavior for Formatter.formatException(), whichever formatException() is called first and returns something truthy is the only formatException() that is used. This is due to a misplaced check for a cached value. logging.Formatter.format() sets (maybe monkey-patches?) an exc_text attribute onto the record it receives, with a comment indicating it's to prevent needlessly re-formatting the exception. If this value is set, it avoids the call to formatException() and just returns the exc_text attribute. If this check for exc_text is moved to Formatter.formatException() instead, I am sure this behavior will be fixed. I.e. Formatter.formatException()'s first few lines turn into something like: if record.exc_text: return record.exc_text sio = cString.StringIO() # ... and so on (rest of current impl) This way the default implementation still caches, and subclass implementation changes still have an effect. The only problem here is this method has no access to the record object. It's not clear to me what is the best way to solve this. I don't have experience making changes to Python or projects of this size but these are my thoughts: * Since the formatException() API is public it shouldn't be changed (e.g. to add record) * Removing the caching might have a significant performance penalty for certain users, although I haven't really tested it * Users who care can copy format() source code into their subclasses and remove the caching code. Alternatively, a class-level flag can be added to determine whether the cache should be used. Documentation in formatException() is added to indicate this issue. This seems like a very poor solution to me. * Adding @functools.lru_cache() in front of the base implementation (after e.g. making it a staticmethod() or something like that) seems clean from a code POV but could negatively impact memory usage, and might also negatively impact CPU usage if the cache isn't effective. * Adding `self._record = record` to format(), before the call to formatException(), probably has the lowest performance impact and is the change I'd lean towards personally, but seems like bad coding practice. I've attached a script that demonstrates the buggy behavior. If someone can weigh in on what a good strategy is to resolve this issue I'd be glad to supply a patch. ---------- files: logging_formatter_exc_bug.py messages: 283888 nosy: daniel.passaro priority: normal severity: normal status: open title: logging.Formatter doesn't respect more than one formatException() type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46008/logging_formatter_exc_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 23 12:37:29 2016 From: report at bugs.python.org (Pam McA'Nulty) Date: Fri, 23 Dec 2016 17:37:29 +0000 Subject: [New-bugs-announce] [issue29057] Compiler failure on Mac OS X - sys/random.h Message-ID: <1482514649.72.0.460227366509.issue29057@psf.upfronthosting.co.za> New submission from Pam McA'Nulty: make failed on Mac OS X including sys/random.h It looks to be caused by this commit: https://github.com/python/cpython/commit/1958527a2c5dda766b1917ab563622434b3dad0d Restoring the removed ifdefs solves the problem (see github PR) Official patch to follow Failure message. ``` In file included from Python/random.c:16: /usr/include/sys/random.h:37:32: error: unknown type name 'u_int' void read_random(void* buffer, u_int numBytes); ^ /usr/include/sys/random.h:38:33: error: unknown type name 'u_int' void read_frandom(void* buffer, u_int numBytes); ^ /usr/include/sys/random.h:39:33: error: unknown type name 'u_int' int write_random(void* buffer, u_int numBytes); ^ 3 errors generated. make: *** [Python/random.o] Error 1 ``` ---------- components: Build messages: 283889 nosy: Pam.McANulty priority: normal pull_requests: 6 severity: normal status: open title: Compiler failure on Mac OS X - sys/random.h type: compile error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 23 19:11:50 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Dec 2016 00:11:50 +0000 Subject: [New-bugs-announce] [issue29058] Mark new limited C API Message-ID: <1482538310.89.0.583492092721.issue29058@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Functions added to a limited API after 3.2 should be available only when Py_LIMITED_API is not defined or is set to corresponding hexadecimal Python version (e.g. 0x03050000). Proposed patch makes following names available only for corresponding versions of a limited API. Removed declaration: PyErr_SetExcWithArgsKwargs(). Excluded from stable ABI: _PyBytes_DecodeEscape(), PyInit_imp(). 3.3: Py_hexdigits, PyImport_ExecCodeModuleObject(), PyImport_AddModuleObject(), PyImport_ImportFrozenModuleObject(), PyMemoryView_FromMemory(), PyModule_NewObject(), PyModule_GetNameObject(), PyObject_GenericSetDict(), PyErr_GetExcInfo(), PyErr_SetExcInfo(), PyErr_SetImportError(), PyParser_SimpleParseStringFlagsFilename(), PyThread_GetInfo(), PyUnicode_Substring(), PyUnicode_AsUCS4(), PyUnicode_AsUCS4Copy(), PyUnicode_GetLength(), PyUnicode_ReadChar(), PyUnicode_WriteChar(), PyUnicode_DecodeCodePageStateful(), PyUnicode_EncodeCodePage(), PyUnicode_DecodeLocaleAndSize(), PyUnicode_DecodeLocale(), PyUnicode_EncodeLocale(), PyUnicode_FindChar(), and a number of OSError subclasses. 3.4: PyErr_SetFromErrnoWithFilenameObjects(), PyErr_SetExcFromWindowsErrWithFilenameObjects(). 3.5: PyNumber_MatrixMultiply(), PyNumber_InPlaceMatrixMultiply(), PyCodec_NameReplaceErrors(), Py_DecodeLocale(), Py_EncodeLocale(), PyImport_ImportModuleLevelObject(), PyObject_Calloc(), PyExc_StopAsyncIteration, PyExc_RecursionError, PyMem_Calloc(), a number of PyODict_* macros. 3.6: Py_FileSystemDefaultEncodeErrors, PyOS_FSPath(), PyExc_ModuleNotFoundError, PyErr_SetImportErrorSubclass(), PyErr_ResourceWarning(). However it may be better that some was added to stable ABI by mistake. Py_hexdigits looks as a stuff for internal use, PyThread_GetInfo() and PyODict_* macros are not documented. ---------- components: Interpreter Core files: limited-api.patch keywords: patch messages: 283910 nosy: haypo, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Mark new limited C API versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46016/limited-api.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 23 20:33:11 2016 From: report at bugs.python.org (Joseph Hackman) Date: Sat, 24 Dec 2016 01:33:11 +0000 Subject: [New-bugs-announce] [issue29059] Windows: Python not using ANSI compatible console Message-ID: <1482543191.02.0.407458515739.issue29059@psf.upfronthosting.co.za> New submission from Joseph Hackman: On windows, Python does not request that Windows enable VT100 for console output for Python. That is to say that ANSI codes such as \033[91m will function on Mac and Linux Pythons, but not Windows. As there is no good interface in core Python to the kernel32 console operations (and there probably shouldn't be, it would be better to be consistent), I suggest just flipping the bit at startup on Windows. I would be happy to submit a patch, but seek guidance on the best location for addition of code to 'at startup iff a tty is attached'. The following code solves the issue: import platform if platform.system().lower() == 'windows': from ctypes import windll, c_int, byref stdout_handle = windll.kernel32.GetStdHandle(c_int(-11)) mode = c_int(0) windll.kernel32.GetConsoleMode(c_int(stdout_handle), byref(mode)) mode = c_int(mode.value | 4) windll.kernel32.SetConsoleMode(c_int(stdout_handle), mode) Please see: https://msdn.microsoft.com/en-us/library/windows/desktop/ms686033(v=vs.85).aspx (Search for ENABLE_VIRTUAL_TERMINAL_PROCESSING) https://msdn.microsoft.com/en-us/library/windows/desktop/ms683231(v=vs.85).aspx (As for why stdout is -11 on Windows) ---------- components: Windows messages: 283913 nosy: joseph.hackman, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows: Python not using ANSI compatible console type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 23 22:13:53 2016 From: report at bugs.python.org (Daz) Date: Sat, 24 Dec 2016 03:13:53 +0000 Subject: [New-bugs-announce] [issue29060] Changing the installation location still adds AppData filepaths that do not exist to the path variable on Windows 10 Message-ID: <1482549233.73.0.705523991357.issue29060@psf.upfronthosting.co.za> New submission from Daz: New to python issue tracking; prone to ignorance. I'm on Windows 10. I noticed after checking to add Python to my path variable and then changing the location from AppData's directory that after the installation, the filepaths associated with AppData were added to the path variable. The new path and any would-be associated filepaths were not added to the path variable. Thanks in advance if you can at least let me know if this is typical or a problem. ---------- components: Installation messages: 283916 nosy: Dazc priority: normal severity: normal status: open title: Changing the installation location still adds AppData filepaths that do not exist to the path variable on Windows 10 type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 24 01:24:43 2016 From: report at bugs.python.org (Brian Nenninger) Date: Sat, 24 Dec 2016 06:24:43 +0000 Subject: [New-bugs-announce] [issue29061] secrets.randbelow(-1) hangs Message-ID: <1482560683.53.0.415654381831.issue29061@psf.upfronthosting.co.za> New submission from Brian Nenninger: secrets.randbelow(-1) causes the interpreter to hang. It should presumably raise an exception like secrets.randbelow(0) does. This is on Mac OS X 10.11.6, shell transcript below. ========================================================= $ python3 Python 3.6.0 (v3.6.0:41df79263a11, Dec 22 2016, 17:23:13) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import secrets >>> secrets.randbelow(1) 0 >>> secrets.randbelow(0) Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/secrets.py", line 29, in randbelow return _sysrand._randbelow(exclusive_upper_bound) File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/random.py", line 232, in _randbelow r = getrandbits(k) # 0 <= r < 2**k File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/random.py", line 678, in getrandbits raise ValueError('number of bits must be greater than zero') ValueError: number of bits must be greater than zero >>> secrets.randbelow(-1) (hangs using 100% CPU until aborted) ---------- components: Library (Lib) messages: 283923 nosy: Brian Nenninger priority: normal severity: normal status: open title: secrets.randbelow(-1) hangs type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 24 04:21:43 2016 From: report at bugs.python.org (Frank Millman) Date: Sat, 24 Dec 2016 09:21:43 +0000 Subject: [New-bugs-announce] [issue29062] Documentation link error Message-ID: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za> New submission from Frank Millman: If you call up online documentation for Python3.6, and select modules>h>hashlib, it takes you to 15.2. hashlib ? BLAKE2 hash functions It should take you to 15.1. hashlib ? Secure hashes and message digests ---------- assignee: docs at python components: Documentation messages: 283930 nosy: docs at python, frankmillman priority: normal severity: normal status: open title: Documentation link error type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 24 05:41:49 2016 From: report at bugs.python.org (Decorater) Date: Sat, 24 Dec 2016 10:41:49 +0000 Subject: [New-bugs-announce] [issue29063] Fix timemodule compile warnings. Message-ID: <1482576109.57.0.29725831282.issue29063@psf.upfronthosting.co.za> New submission from Decorater: I fixed some Possible Loss of Data warnings. but only the ones for timemodule. There are still some others when building the 64 bit version however. I added some comments that can be removed in another patch if desired otherwise it should look good for now for this module. ---------- components: Build, Interpreter Core, Windows files: timemodule.patch-1.patch keywords: patch messages: 283937 nosy: Decorater, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Fix timemodule compile warnings. versions: Python 3.7 Added file: http://bugs.python.org/file46022/timemodule.patch-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 24 07:55:02 2016 From: report at bugs.python.org (kevin) Date: Sat, 24 Dec 2016 12:55:02 +0000 Subject: [New-bugs-announce] [issue29064] Package numpy can't be used normally Message-ID: <1482584102.8.0.443531506198.issue29064@psf.upfronthosting.co.za> New submission from kevin: I used package numpy,but encounter the following error: Traceback (most recent call last): File "rgbtoyuv.py", line 2, in import numpy as np File "/usr/local/lib/python3.5/site-packages/numpy-1.11.2-py3.5-linux-x86_64.egg/numpy/__init__.py", line 163, in from . import random File "/usr/local/lib/python3.5/site-packages/numpy-1.11.2-py3.5-linux-x86_64.egg/numpy/random/__init__.py", line 99, in from .mtrand import * ImportError: /usr/local/lib/python3.5/site-packages/numpy-1.11.2-py3.5-linux-x86_64.egg/numpy/random/mtrand.cpython-35m-x86_64-linux-gnu.so: undefined symbol: PyFPE_jbuf I have download the numpy install package,and installed. Platform ubuntu16.04 x86_64 python version: 3.5.2 numpy version:1.11.2 and try to version:1.9.0 also,but installed failed. Please help me find the reason,thanks a lot. ---------- components: Library (Lib) messages: 283949 nosy: kevin.zhai80 priority: normal severity: normal status: open title: Package numpy can't be used normally type: resource usage versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 24 17:28:08 2016 From: report at bugs.python.org (Utku Gultopu) Date: Sat, 24 Dec 2016 22:28:08 +0000 Subject: [New-bugs-announce] [issue29065] SSL module problem on Python 3.6.0 and macOS Sierra Message-ID: <1482618488.69.0.324323347363.issue29065@psf.upfronthosting.co.za> New submission from Utku Gultopu: It seems like ssl module is not working for me: (virtualenv) user at host:~$ python Python 3.6.0 (v3.6.0:41df79263a11, Dec 22 2016, 17:23:13) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import ssl >>> import socket >>> context = ssl.create_default_context() >>> conn = context.wrap_socket(socket.socket(socket.AF_INET), server_hostname="www.python.org") >>> conn.connect(("www.python.org", 443)) Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ssl.py", line 1093, in connect self._real_connect(addr, False) File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ssl.py", line 1084, in _real_connect self.do_handshake() File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ssl.py", line 1061, in do_handshake self._sslobj.do_handshake() File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ssl.py", line 683, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749) >>> It seems like a problem with OpenSSL in Sierra itself. Because the following command does not work either: (virtualenv) user at host:~$ openssl s_client -connect www.python.org:443 CONNECTED(00000003) depth=1 /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/businessCategory=Private Organization/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/serialNumber=3359300/street=16 Allen Rd/postalCode=03894-4801/C=US/ST=NH/L=Wolfeboro/O=Python Software Foundation/CN=www.python.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA --- Server certificate -----BEGIN CERTIFICATE----- MIIIWjCCB0KgAwIBAgIQCXCW7BLw16II/CMOsOFe/jANBgkqhkiG9w0BAQsFADB1 MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTE2MDYyOTAwMDAwMFoXDTE4MDkyNzEy MDAwMFowgfgxHTAbBgNVBA8TFFByaXZhdGUgT3JnYW5pemF0aW9uMRMwEQYLKwYB BAGCNzwCAQMTAlVTMRkwFwYLKwYBBAGCNzwCAQITCERlbGF3YXJlMRAwDgYDVQQF EwczMzU5MzAwMRQwEgYDVQQJEwsxNiBBbGxlbiBSZDETMBEGA1UEERMKMDM4OTQt NDgwMTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAk5IMRIwEAYDVQQHEwlXb2xmZWJv cm8xIzAhBgNVBAoTGlB5dGhvbiBTb2Z0d2FyZSBGb3VuZGF0aW9uMRcwFQYDVQQD Ew53d3cucHl0aG9uLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMpgUlIza25mor2AW20yRs8uHtRJs0kXpMF2zATQjhYAgfpqjoKugoWBlMrLCFQj G/Aq8W7pT4WWHCb9Nv2QGdnIEapxi5HSfxc3b1HIRmJDdfxsc2Y4dATfgzIS4wNw jDM9tmYcMZMKZVdW4WxurQIka8r3tBFP944yAllRn8uuFVXSDYALkZOiiWxuMYKA q40hYrDhWO53uKk23HNBo5Kgfvcj3t0ZcMSkzekClxyxgyS1nnkNWIdEEMCP/FFU UXrQt0MEtkmfc++6Ps2SEiHL2T4MEqY8eE0ss6Mvmt+yzy8QsZOArrpxv7l8OwBO 5yB0LU3ByoQan1O/upeNclkCAwEAAaOCBGAwggRcMB8GA1UdIwQYMBaAFD3TUKXW oK3u80pgCmXTIdT4+NYPMB0GA1UdDgQWBBTL2ztKcGS38IxHEASJaOzwHuUqljCC AQsGA1UdEQSCAQIwgf+CDnd3dy5weXRob24ub3Jngg9kb2NzLnB5dGhvbi5vcmeC D2J1Z3MucHl0aG9uLm9yZ4IPd2lraS5weXRob24ub3Jngg1oZy5weXRob24ub3Jn gg9tYWlsLnB5dGhvbi5vcmeCD3B5cGkucHl0aG9uLm9yZ4IUcGFja2FnaW5nLnB5 dGhvbi5vcmeCEGxvZ2luLnB5dGhvbi5vcmeCEmRpc2N1c3MucHl0aG9uLm9yZ4IM dXMucHljb24ub3JnggdweXBpLmlvggxkb2NzLnB5cGkuaW+CCHB5cGkub3Jngg1k b2NzLnB5cGkub3Jngg9kb25hdGUucHlwaS5vcmcwDgYDVR0PAQH/BAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjB1BgNVHR8EbjBsMDSgMqAwhi5o dHRwOi8vY3JsMy5kaWdpY2VydC5jb20vc2hhMi1ldi1zZXJ2ZXItZzEuY3JsMDSg MqAwhi5odHRwOi8vY3JsNC5kaWdpY2VydC5jb20vc2hhMi1ldi1zZXJ2ZXItZzEu Y3JsMEsGA1UdIAREMEIwNwYJYIZIAYb9bAIBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwBwYFZ4EMAQEwgYgGCCsGAQUFBwEBBHww ejAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMFIGCCsGAQUF BzAChkZodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyRXh0 ZW5kZWRWYWxpZGF0aW9uU2VydmVyQ0EuY3J0MAwGA1UdEwEB/wQCMAAwggF9Bgor BgEEAdZ5AgQCBIIBbQSCAWkBZwB2AKS5CZC0GFgUh7sTosxncAo8NZgE+RvfuON3 zQ7IDdwQAAABVkgj4a8AAAQDAEcwRQIhAMhsxamO6hrRjfNmH4Yj/cnJo72cmTHm rSlEi0FHilNtAiB/tDiULYh6rf9H5eKmrV8PRsvFNSflBsQIIF1VejnWrwB2AGj2 mPgfZIK+OozuuSgdTPxxUV1nk9RE0QpnrLtPT/vEAAABVkgj4XYAAAQDAEcwRQIg Ygh+rvtk2KQd2CRaM+whfGgc6waZACSMgwzYVmOZr9sCIQDGs78IDIoPZhNBGfIK xXQdq8DwAjahQboXeJWx/AfAxQB1AFYUBpov18Ls0/XhvUSyPsdGdrm8mRFcwO+U mFXWidDdAAABVkgj4dkAAAQDAEYwRAIgMOOdrhZ0280XsmWuLt7fcFnwtRIu42j7 WmRrQ2NlJLUCIG5Z6vzlhvFNIhN67A0G/hrRH7hzJ13/elILZcjZYJQqMA0GCSqG SIb3DQEBCwUAA4IBAQCuDt1T9tBxAVYp2u10uONL6FTHQlgguQCiN5ANmjp6dUAq 2I1nCgZB9nxhGUFOsdiQ5DFDgJ0xTAgwF4nWAyXEHKjyacoaUOh3Zq7A62r5+0eE P3XDNKIN2TWF3+djFneND/uqqpDGo2bMdcm9l0dvktUP9xQXIZBBkOMJZfXSxh0/ 7H+bDizx+bq/5Dwv97fs770UCz5LqGRuIUaZQvBQblsP5QoBaKEYW5Hsmfu9FWbW 0qreV7KHFp7ONBSKFUefbG0Q37O8oTPr7JnMxTvdUcthJOLcN9IHo2StTzv3Wru0 5njv0zLw7zwePKc9YJ1YBLmLj7vPxyy/XoW8+8hI -----END CERTIFICATE----- subject=/businessCategory=Private Organization/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/serialNumber=3359300/street=16 Allen Rd/postalCode=03894-4801/C=US/ST=NH/L=Wolfeboro/O=Python Software Foundation/CN=www.python.org issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA --- No client certificate CA names sent --- SSL handshake has read 3524 bytes and written 456 bytes --- New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : AES128-SHA Session-ID: 239A88888D772216EDDD8C204996A901BAD27D50B929E6A626955472456077B6 Session-ID-ctx: Master-Key: FB1EAC13FFD2F42DA5BF0364E3A08A869DD129389374416B6574F6D852692888F991B79027143A81963FA7594FFB85BD Key-Arg : None Start Time: 1482618121 Timeout : 300 (sec) Verify return code: 0 (ok) --- Connecting to `www.python.org` (or any other secure site) works on web browsers. Also, `DigiCert High Assurance EV Root CA` exists in the System Roots section of Keychain. I guess the problem might be that ssl module does not use the Keychain, like `openssl` command. Regards ---------- assignee: christian.heimes components: SSL, macOS messages: 283976 nosy: christian.heimes, ned.deily, ronaldoussoren, ugultopu priority: normal severity: normal status: open title: SSL module problem on Python 3.6.0 and macOS Sierra type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 25 02:38:55 2016 From: report at bugs.python.org (Utku Gultopu) Date: Sun, 25 Dec 2016 07:38:55 +0000 Subject: [New-bugs-announce] [issue29066] PIP doesn't honor --trusted-host or --cert options Message-ID: <1482651535.67.0.15058500735.issue29066@psf.upfronthosting.co.za> New submission from Utku Gultopu: Steps to Reproduce ================== 1. Install Python 3.6.0 on macOS Sierra, using the macOS binary installer from python.org. 2. Don't install any SSL certificates. 3. Run `pip install -U channels`. It will fail. 4. Run `pip install -U --trusted-host pypi.python.org channels`. It will fail too. 5. Run `pip --cert ~/cacert.pem install -U channels` (where `cacert.pem` is [this](https://curl.haxx.se/ca/cacert.pem).) It will fail too. Expected Results ================ Command at number 3 to fail, commands at number 4 and 5 to succeed. Actual Results ============== Commands at number 3, 4 and 5 fail. Version Info ============ Python 3.6.0 (v3.6.0:41df79263a11, Dec 22 2016, 17:23:13) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin macOS Sierra 10.12 pip 9.0.1 from /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages (python 3.6) Related Issues ============= 29065 Explanation =========== I installed Python 3.6.0 on macOS Sierra, using the macOS binary installer from python.org. Initially, I didn't install the necessary certificates by running the script /Applications/Python 3.6/Install Certificates.command. When I wanted to install a module where PIP establishes an SSL connection during installation, I got an SSL: CERTIFICATE_VERIFY_FAILED error, as expected. Command at step 3: (virtualenv) user at host:~/Documents/virtualenv$ pip install -U channels Collecting channels Downloading channels-0.17.3-py2.py3-none-any.whl (53kB) 100% |????????????????????????????????| 61kB 299kB/s Requirement already up-to-date: Django>=1.8 in ./lib/python3.6/site-packages (from channels) Collecting asgiref>=0.13 (from channels) Downloading asgiref-1.0.0-py2.py3-none-any.whl Collecting daphne>=0.14.1 (from channels) Downloading daphne-0.15.0-py2.py3-none-any.whl Collecting six (from asgiref>=0.13->channels) Using cached six-1.10.0-py2.py3-none-any.whl Collecting twisted>=16.0 (from daphne>=0.14.1->channels) Downloading Twisted-16.6.0.tar.bz2 (3.0MB) 100% |????????????????????????????????| 3.0MB 265kB/s Complete output from command python setup.py egg_info: Download error on https://pypi.python.org/simple/incremental/: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749) -- Some packages may not be found! Couldn't find index page for 'incremental' (maybe misspelled?) Download error on https://pypi.python.org/simple/: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749) -- Some packages may not be found! No local packages or working download links found for incremental>=16.10.1 Traceback (most recent call last): File "", line 1, in File "/private/var/folders/45/r4yr9bbj29dfbtxqv75_785m0000gn/T/pip-build-o5qosaie/twisted/setup.py", line 21, in setuptools.setup(**_setup["getSetupArgs"]()) File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/distutils/core.py", line 108, in setup _setup_distribution = dist = klass(attrs) File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/dist.py", line 316, in __init__ self.fetch_build_eggs(attrs['setup_requires']) File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/dist.py", line 371, in fetch_build_eggs replace_conflicting=True, File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 846, in resolve dist = best[req.key] = env.best_match(req, ws, installer) File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 1118, in best_match return self.obtain(req, installer) File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 1130, in obtain return installer(requirement) File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/dist.py", line 439, in fetch_build_egg return cmd.easy_install(req) File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/command/easy_install.py", line 668, in easy_install raise DistutilsError(msg) distutils.errors.DistutilsError: Could not find suitable distribution for Requirement.parse('incremental>=16.10.1') ---------------------------------------- Command "python setup.py egg_info" failed with error code 1 in /private/var/folders/45/r4yr9bbj29dfbtxqv75_785m0000gn/T/pip-build-o5qosaie/twisted/ Command at step 4: (virtualenv) user at host:~/Documents/virtualenv$ pip install -U --trusted-host pypi.python.org channels Collecting channels Downloading channels-0.17.3-py2.py3-none-any.whl (53kB) 100% |????????????????????????????????| 61kB 291kB/s Requirement already up-to-date: Django>=1.8 in ./lib/python3.6/site-packages (from channels) Collecting asgiref>=0.13 (from channels) Downloading asgiref-1.0.0-py2.py3-none-any.whl Collecting daphne>=0.14.1 (from channels) Downloading daphne-0.15.0-py2.py3-none-any.whl Collecting six (from asgiref>=0.13->channels) Downloading six-1.10.0-py2.py3-none-any.whl Collecting twisted>=16.0 (from daphne>=0.14.1->channels) Downloading Twisted-16.6.0.tar.bz2 (3.0MB) 100% |????????????????????????????????| 3.0MB 359kB/s Complete output from command python setup.py egg_info: Download error on https://pypi.python.org/simple/incremental/: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749) -- Some packages may not be found! Couldn't find index page for 'incremental' (maybe misspelled?) Download error on https://pypi.python.org/simple/: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749) -- Some packages may not be found! No local packages or working download links found for incremental>=16.10.1 Traceback (most recent call last): File "", line 1, in File "/private/var/folders/45/r4yr9bbj29dfbtxqv75_785m0000gn/T/pip-build-6fteuyi9/twisted/setup.py", line 21, in setuptools.setup(**_setup["getSetupArgs"]()) File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/distutils/core.py", line 108, in setup _setup_distribution = dist = klass(attrs) File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/dist.py", line 316, in __init__ self.fetch_build_eggs(attrs['setup_requires']) File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/dist.py", line 371, in fetch_build_eggs replace_conflicting=True, File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 846, in resolve dist = best[req.key] = env.best_match(req, ws, installer) File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 1118, in best_match return self.obtain(req, installer) File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 1130, in obtain return installer(requirement) File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/dist.py", line 439, in fetch_build_egg return cmd.easy_install(req) File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/command/easy_install.py", line 668, in easy_install raise DistutilsError(msg) distutils.errors.DistutilsError: Could not find suitable distribution for Requirement.parse('incremental>=16.10.1') ---------------------------------------- Command "python setup.py egg_info" failed with error code 1 in /private/var/folders/45/r4yr9bbj29dfbtxqv75_785m0000gn/T/pip-build-6fteuyi9/twisted/ Command at step 5: (virtualenv) user at host:~/Documents/virtualenv$ pip --cert ~/cacert.pem install -U channels Collecting channels Using cached channels-0.17.3-py2.py3-none-any.whl Collecting asgiref>=0.13 (from channels) Using cached asgiref-1.0.0-py2.py3-none-any.whl Collecting daphne>=0.14.1 (from channels) Using cached daphne-0.15.0-py2.py3-none-any.whl Requirement already up-to-date: Django>=1.8 in ./lib/python3.6/site-packages (from channels) Collecting six (from asgiref>=0.13->channels) Using cached six-1.10.0-py2.py3-none-any.whl Collecting twisted>=16.0 (from daphne>=0.14.1->channels) Using cached Twisted-16.6.0.tar.bz2 Complete output from command python setup.py egg_info: Download error on https://pypi.python.org/simple/incremental/: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749) -- Some packages may not be found! Couldn't find index page for 'incremental' (maybe misspelled?) Download error on https://pypi.python.org/simple/: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749) -- Some packages may not be found! No local packages or working download links found for incremental>=16.10.1 Traceback (most recent call last): File "", line 1, in File "/private/var/folders/45/r4yr9bbj29dfbtxqv75_785m0000gn/T/pip-build-_c6zb9_v/twisted/setup.py", line 21, in setuptools.setup(**_setup["getSetupArgs"]()) File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/distutils/core.py", line 108, in setup _setup_distribution = dist = klass(attrs) File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/dist.py", line 316, in __init__ self.fetch_build_eggs(attrs['setup_requires']) File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/dist.py", line 371, in fetch_build_eggs replace_conflicting=True, File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 846, in resolve dist = best[req.key] = env.best_match(req, ws, installer) File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 1118, in best_match return self.obtain(req, installer) File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 1130, in obtain return installer(requirement) File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/dist.py", line 439, in fetch_build_egg return cmd.easy_install(req) File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/command/easy_install.py", line 668, in easy_install raise DistutilsError(msg) distutils.errors.DistutilsError: Could not find suitable distribution for Requirement.parse('incremental>=16.10.1') ---------------------------------------- Command "python setup.py egg_info" failed with error code 1 in /private/var/folders/45/r4yr9bbj29dfbtxqv75_785m0000gn/T/pip-build-_c6zb9_v/twisted/ ---------- assignee: christian.heimes components: SSL, macOS messages: 283987 nosy: christian.heimes, ned.deily, ronaldoussoren, ugultopu priority: normal severity: normal status: open title: PIP doesn't honor --trusted-host or --cert options type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 25 03:25:57 2016 From: report at bugs.python.org (amig) Date: Sun, 25 Dec 2016 08:25:57 +0000 Subject: [New-bugs-announce] [issue29067] Source archive: wrong directory attributes Message-ID: <1482654357.71.0.854296911958.issue29067@psf.upfronthosting.co.za> New submission from amig: In Python-3.6.0.tgz and Python-3.6.0.tar.xz the folders inside have attributes drwxr--r-- instaed of drwxrwxr-x. This leads to setting the user #501 as an owner while unpacking the archives in a folder owned by root with sudo and therefore access denial. ---------- components: Build messages: 283989 nosy: amig priority: normal severity: normal status: open title: Source archive: wrong directory attributes type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 25 08:52:32 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sun, 25 Dec 2016 13:52:32 +0000 Subject: [New-bugs-announce] [issue29068] Fix example code for PyErr_Fetch Message-ID: <1482673952.94.0.428755110908.issue29068@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: Remove an extra * The typo is there in 3.5~3.7 branches. 2.7 branch does not have this example. Nosy the two major commiters to Python/errors.c ---------- assignee: docs at python components: Documentation files: PyErr_Fetch-fix.patch keywords: patch messages: 283993 nosy: Chi Hsuan Yen, docs at python, martin.panter, serhiy.storchaka priority: normal severity: normal status: open title: Fix example code for PyErr_Fetch versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46029/PyErr_Fetch-fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 25 10:38:32 2016 From: report at bugs.python.org (paka) Date: Sun, 25 Dec 2016 15:38:32 +0000 Subject: [New-bugs-announce] [issue29069] Default PyPI URL in docs is not what is really in code Message-ID: <1482680312.49.0.384857389372.issue29069@psf.upfronthosting.co.za> New submission from paka: Currently https://docs.python.org/3.7/distutils/packageindex.html#the-pypirc-file says that URL of the PyPI server defaults to https://www.python.org/pypi. That URL does not work. Lib/distutils/config.py defines DEFAULT_REPOSITORY as https://upload.pypi.org/legacy/, so I'm attaching a patch for docs to update to current default. I might be wrong about value that must be in docs, so guidance is appreciated :) ---------- assignee: docs at python components: Distutils, Documentation files: fix-pypi-url.patch keywords: patch messages: 283997 nosy: docs at python, dstufft, eric.araujo, paka priority: normal severity: normal status: open title: Default PyPI URL in docs is not what is really in code versions: Python 3.7 Added file: http://bugs.python.org/file46034/fix-pypi-url.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 25 11:43:45 2016 From: report at bugs.python.org (Cornelius Diekmann) Date: Sun, 25 Dec 2016 16:43:45 +0000 Subject: [New-bugs-announce] [issue29070] Integration tests for pty.spawn on Linux and all other platforms Message-ID: <1482684225.17.0.467768789806.issue29070@psf.upfronthosting.co.za> New submission from Cornelius Diekmann: As Martin Panter noted, "it doesn?t look like pty.spawn() is tested at all" [issue26228]. So I wrote some very basic integration tests for pty.spawn. They work perfectly on my Linux machine. Line 4 of the library module under test (pty.py) states: "Only tested on Linux." I don't like this comment ;-) There are two possibilities how to proceed from here: 1) The tests work perfectly on all other platforms: then we can remove this comment from pty.py. 2) The tests fail on other platforms: then we can finally document where this module is expected to work and where not. In either case, I need some help by non-Linux users to run theses tests and document their success/failure and whether we have a bug on the specific platform (i.e. pty.spawn should work but does not) or whether the tests should be skipped (i.e. platform does not support ptys at all). It would be really awesome if some *BSD and Windows users would join the nosy list :-) Happy Holidays! ---------- components: Cross-Build, Tests files: PtyLinuxIntegrtionTest.patch keywords: patch messages: 284003 nosy: Alex.Willmer, Cornelius Diekmann, chris.torek, martin.panter priority: normal severity: normal status: open title: Integration tests for pty.spawn on Linux and all other platforms type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file46035/PtyLinuxIntegrtionTest.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 25 20:16:18 2016 From: report at bugs.python.org (Kenzie Togami) Date: Mon, 26 Dec 2016 01:16:18 +0000 Subject: [New-bugs-announce] [issue29071] IDLE doesn't highlight f-strings properly Message-ID: <1482714978.44.0.603392455768.issue29071@psf.upfronthosting.co.za> New submission from Kenzie Togami: IDLE doesn't highlight f-strings like r-strings or u-strings. See the attached screenshot. ---------- assignee: terry.reedy components: IDLE files: python_idle_3.6_bug.png messages: 284010 nosy: Kenzie Togami, terry.reedy priority: normal severity: normal status: open title: IDLE doesn't highlight f-strings properly type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46037/python_idle_3.6_bug.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 26 03:53:33 2016 From: report at bugs.python.org (=?utf-8?b?5YqJ5YqN5bOw?=) Date: Mon, 26 Dec 2016 08:53:33 +0000 Subject: [New-bugs-announce] [issue29072] the message of help(os.environ.setdefault) have some error Message-ID: <1482742413.83.0.382615378598.issue29072@psf.upfronthosting.co.za> New submission from ???: the message `D.setdefault(k[,d])', compiler inform SyntaxError: invalid syntax. I think that it woulld be D.setdefault([k, d]). ---------- assignee: docs at python components: Documentation messages: 284015 nosy: docs at python, ??? priority: normal severity: normal status: open title: the message of help(os.environ.setdefault) have some error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 26 04:52:44 2016 From: report at bugs.python.org (Fabio Sangiovanni) Date: Mon, 26 Dec 2016 09:52:44 +0000 Subject: [New-bugs-announce] [issue29073] bytearray.__mod__() truncates on first \x00 Message-ID: <1482745964.51.0.352448624616.issue29073@psf.upfronthosting.co.za> New submission from Fabio Sangiovanni: Originally posted by Russell Keith-Magee on Twitter: https://twitter.com/freakboy3742/status/812609675283681280 Reproduced successfully on Python 3.5.2 >>> x = bytearray(1) >>> y = {} >>> x % y Python3.5: bytearray(b'') Python3.6: bytearray(b'\x00') also: >>> bytearray([0,1]) % {} # same with [], (), range(42) bytearray(b'') >>> bytearray([1,0]) % {} bytearray(b'\x01') ---------- components: Interpreter Core messages: 284018 nosy: sanjioh priority: normal severity: normal status: open title: bytearray.__mod__() truncates on first \x00 type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 26 07:41:55 2016 From: report at bugs.python.org (iMath) Date: Mon, 26 Dec 2016 12:41:55 +0000 Subject: [New-bugs-announce] [issue29074] repr doesn't give full result for this re math result Message-ID: <1482756115.08.0.598245159081.issue29074@psf.upfronthosting.co.za> New submission from iMath: I tested with Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 bit (Intel)] on win32 re.search(r'http://v.pptv.com/show/.*?\.html.+', 'http://v.pptv.com/show/2bwkox9SS4nsatI.html?rcc_src=P5') does give a match, but it show the result <_sre.SRE_Match object; span=(0, 54), match='http://v.pptv.com/show/2bwkox9SS4nsatI.html?rcc_s> missing rc=P5' in IDLE BTW, py2.7 works fine ---------- components: Regular Expressions messages: 284024 nosy: ezio.melotti, mrabarnett, redstone-cold priority: normal severity: normal status: open title: repr doesn't give full result for this re math result type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 26 13:00:41 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 26 Dec 2016 18:00:41 +0000 Subject: [New-bugs-announce] [issue29075] Update WINVER to Windows 7 Message-ID: <1482775241.44.0.333291277311.issue29075@psf.upfronthosting.co.za> New submission from Steve Dower: Windows Vista SP2 is out of support by the time that Python 3.7 releases (see PEP 0537 and [1]), so we should do the following tasks: * update the definition of Py_WINVER in PC/pyconfig.h to 0x0601 _WIN32_WINNT_WIN7 * remove any dynamic API imports that are not required on Win7 (I don't think?there are many, if any) * remove pre-Win7 supportedOS elements from PC/python.manifest * block Windows Vista in the installer We may also be able to take advantage of new flags, particularly related to security (I think LoadLibrary[Ex] got new flags). If there's anything else we need to do, post it here so we don't forget. References: [1]: https://support.microsoft.com/en-us/lifecycle/search?alpha=Windows%20Vista%20Service%20Pack%202 ---------- components: Windows messages: 284034 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: Update WINVER to Windows 7 type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 26 13:46:40 2016 From: report at bugs.python.org (Elias Zamaria) Date: Mon, 26 Dec 2016 18:46:40 +0000 Subject: [New-bugs-announce] [issue29076] Python 3.6 installer doesn't update "python3" shell command Message-ID: <1482778000.76.0.584407589583.issue29076@psf.upfronthosting.co.za> New submission from Elias Zamaria: I have a Mac running OS X 10.11.6, Python 3.5.2, and fish 2.3.1. I installed Python 3.6.0, and everything seemed to work fine. However, I typed "python3" in my shell and it started Python 3.5.2. I restarted my shell and typed "python3", and it still started Python 3.5.2. I ran "which python3" and it told me "/Library/Frameworks/Python.framework/Versions/3.5/bin/python3". I ran "echo $PATH" and it told me "/Library/Frameworks/Python.framework/Versions/3.5/bin", among other directories that seem unrelated to Python. I thought that maybe the installer updated my ~/.bash_profile, assuming that I am using bash like most people, but I looked in that file, and the only things affecting my path that look Python-related are adding the directories "/Library/Frameworks/Python.framework/Versions/2.7/bin" and "/Library/Frameworks/Python.framework/Versions/3.5/bin". I re-ran the installer, clicked the "Customize" button, made sure that the "Shell profile updater" checkbox was checked, and ran "python3", and it started Python 3.5.2. I can probably fix this by adding the right directory to my $PATH, but I think it is a bug if the installer doesn't make that change for me, or even try to make the change. ---------- components: Installation, macOS messages: 284036 nosy: elias, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Python 3.6 installer doesn't update "python3" shell command versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 26 14:19:02 2016 From: report at bugs.python.org (Steve Wills) Date: Mon, 26 Dec 2016 19:19:02 +0000 Subject: [New-bugs-announce] [issue29077] build failure when enabling dtrace on FreeBSD Message-ID: <1482779942.39.0.346100216113.issue29077@psf.upfronthosting.co.za> New submission from Steve Wills: When enabling dtrace support via the --with-dtrace configure flag, build fails on FreeBSD with this message: /usr/sbin/dtrace -o Include/pydtrace_probes.h -h -s dtrace: option requires an argument -- s Looks like line 882 of Makefile.pre.in: 882 $(DTRACE) $(DFLAGS) -o $@ -h -s $< changing this to: 882 $(DTRACE) $(DFLAGS) -o $@ -h -s $(srcdir)/Include/pydtrace.d avoids that issue. Note that bmake is being used here. After this however, another issue is encountered during linking: Python/ceval.o: In function `_PyEval_EvalFrameDefault': Python/ceval.c:(.text+0xc94): undefined reference to `__dtraceenabled_python___function__entry' Python/ceval.c:(.text+0xcdd): undefined reference to `__dtrace_python___function__entry' Python/ceval.c:(.text+0xff0): undefined reference to `__dtraceenabled_python___line' Python/ceval.c:(.text+0x109f): undefined reference to `__dtrace_python___line' Python/ceval.c:(.text+0x125e): undefined reference to `__dtraceenabled_python___line' Python/ceval.c:(.text+0x12e5): undefined reference to `__dtraceenabled_python___line' Python/ceval.c:(.text+0x1358): undefined reference to `__dtraceenabled_python___line' Python/ceval.c:(.text+0x13f2): undefined reference to `__dtraceenabled_python___line' Python/ceval.c:(.text+0x146c): undefined reference to `__dtraceenabled_python___line' Python/ceval.o:Python/ceval.c:(.text+0x14de): more undefined references to `__dtraceenabled_python___line' follow Python/ceval.o: In function `_PyEval_EvalFrameDefault': Python/ceval.c:(.text+0x87f2): undefined reference to `__dtraceenabled_python___function__return' Python/ceval.c:(.text+0x8833): undefined reference to `__dtrace_python___function__return' Modules/gcmodule.o: In function `collect': Modules/gcmodule.c:(.text+0x380): undefined reference to `__dtraceenabled_python___gc__start' Modules/gcmodule.c:(.text+0x38c): undefined reference to `__dtrace_python___gc__start' Modules/gcmodule.c:(.text+0xe1b): undefined reference to `__dtraceenabled_python___gc__done' Modules/gcmodule.c:(.text+0xe2a): undefined reference to `__dtrace_python___gc__done' which I believe is due to dtrace -G modifying Python/ceval.o and Modules/gcmodule.o. Finally, note that all calls to dtrace -G or dtrace -h on FreeBSD 11.0 should have -xnolibs added to enable use without the DTrace kernel modules loaded. Otherwise dtrace processes the /usr/lib/dtrace scripts unnecessarily, and errors out when it tries to talk to the DTrace kernel code, causing build failure in a jail. (I can provide patches, but suspect you have preferences about how the build system work that I'm not aware of, so wanted to explain before patching in ways that aren't satisfactory.) ---------- messages: 284038 nosy: swills priority: normal severity: normal status: open title: build failure when enabling dtrace on FreeBSD versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 26 15:15:52 2016 From: report at bugs.python.org (Dhushyanth Ramasamy) Date: Mon, 26 Dec 2016 20:15:52 +0000 Subject: [New-bugs-announce] [issue29078] Example in Section 8.1.5 time Objects is broken Message-ID: <1482783352.26.0.821424852315.issue29078@psf.upfronthosting.co.za> New submission from Dhushyanth Ramasamy: The example doesn't import timedelta. This causes an error when attempting to run the example in the interactive window. ---------- assignee: docs at python components: Documentation files: datetime.patch keywords: patch messages: 284042 nosy: docs at python, rdhushyanth priority: normal severity: normal status: open title: Example in Section 8.1.5 time Objects is broken versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46045/datetime.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 26 15:46:14 2016 From: report at bugs.python.org (Georg Mischler) Date: Mon, 26 Dec 2016 20:46:14 +0000 Subject: [New-bugs-announce] [issue29079] pathlib.resolve() causes infinite loop on Windows Message-ID: <1482785174.29.0.0980303906914.issue29079@psf.upfronthosting.co.za> New submission from Georg Mischler: When pathlib.resolve() is invoked on Windows(10) with an absolute path including a non-existing drive, it gets caught in an infinite loop. To reproduce: Select a drive letter that doesn't exist on the system (in my case H:). Run the following line of code: pathlib.Path('h:\\').resolve() Expected result: returns the input string unchanged. Actual result: pathlib.resolve() ends up in an infinite loop, repeatedly calling _getfinalpathname() on the same string. ---------- components: Library (Lib), Windows messages: 284045 nosy: Georg Mischler, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: pathlib.resolve() causes infinite loop on Windows type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 27 04:53:02 2016 From: report at bugs.python.org (Joseph Shen) Date: Tue, 27 Dec 2016 09:53:02 +0000 Subject: [New-bugs-announce] [issue29080] unnecessary hg required for build version 3.6 on Windows Message-ID: <1482832382.86.0.80948215742.issue29080@psf.upfronthosting.co.za> New submission from Joseph Shen: the released 3.6.0 PCbuild/build.bat required hg for building. but this requirement is not necessary for build python from source. maybe it will be better for us to remove this requirement as the old versions. ---------- components: Build messages: 284078 nosy: Joseph.Shen priority: normal severity: normal status: open title: unnecessary hg required for build version 3.6 on Windows type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 27 05:05:12 2016 From: report at bugs.python.org (hywl51) Date: Tue, 27 Dec 2016 10:05:12 +0000 Subject: [New-bugs-announce] [issue29081] time.strptime() return wrong result Message-ID: <1482833112.13.0.0168836521105.issue29081@psf.upfronthosting.co.za> New submission from hywl51: In [1]:import time In [2]: time.strptime('2016 52 0', '%Y %W %w') Out[2]: time.struct_time(tm_year=2017, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=367, tm_isdst=-1) When given the parameters above, the function return the struct_time object with tm_yday=367, that is wrong. I test the codes on Python 2.7.11 and 3.5.1, the error is same. ---------- components: Library (Lib) messages: 284080 nosy: hywl51 priority: normal severity: normal status: open title: time.strptime() return wrong result type: behavior versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 27 05:09:01 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Tue, 27 Dec 2016 10:09:01 +0000 Subject: [New-bugs-announce] [issue29082] In 2.7.13, _ctypes.LoadLibrary no longer accepts Unicode objects Message-ID: <1482833341.48.0.70408057792.issue29082@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: In issue27330, there's one more change besides fixing possible memory leaks. In LoadLibrary function of _ctypes: [1] - if (!PyArg_ParseTuple(args, "O|O:LoadLibrary", &nameobj, &ignored)) + if (!PyArg_ParseTuple(args, "S|O:LoadLibrary", &nameobj, &ignored)) Before this change, both bytes and unicode objects are accepted in _ctypes.LoadLibrary() (Unicode objects are implicitly converted to bytes), and after this change only bytes objects are valid. There are two options: * Revert the relevant PyArg_ParseTuple. It's better to have fewer surprises on 2.7 branch :) * Document the change. I prefer the first option as in our project ```from __future__ import unicode_literals``` is used everywhere, and in Python 3 only Unicode objects are acceptable in _ctypes.LoadLibrary(). Downstream report: https://github.com/rg3/youtube-dl/issues/11540 Added the author and the reviewer in issue27330. [1] e04c054beb53 ---------- components: ctypes messages: 284081 nosy: Chi Hsuan Yen, martin.panter, serhiy.storchaka priority: normal severity: normal status: open title: In 2.7.13, _ctypes.LoadLibrary no longer accepts Unicode objects type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 27 08:41:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Dec 2016 13:41:52 +0000 Subject: [New-bugs-announce] [issue29083] Readd PyArg_VaParse to the stable API Message-ID: <1482846112.52.0.144835029316.issue29083@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Seems PyArg_VaParse() and PyArg_VaParseTupleAndKeywords() were excluded from the stable API by the mistake in fixing issue11626. These functions was in the stable API before 3.3, and the documentation doesn't mention that they are not in the stable API. I think they should be readded to the stable API. ---------- components: Interpreter Core messages: 284097 nosy: loewis, serhiy.storchaka priority: normal severity: normal status: open title: Readd PyArg_VaParse to the stable API type: compile error versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 27 08:59:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Dec 2016 13:59:17 +0000 Subject: [New-bugs-announce] [issue29084] C API of OrderedDict Message-ID: <1482847157.79.0.799208161515.issue29084@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: C API of the C implementation of OrderedDict was added in 3.5 together with the C implementation of OrderedDict. But it was never announced nor documented. Some macros contain bugs. PyODict_Check() and PyODict_CheckExact() are declared in the limited API, but don't work since use PyODict_Type not available in the limited API. PyODict_SIZE() is expanded to syntactically incorrect code and it's name is not consistent with similar macros: PyTuple_GET_SIZE, PyList_GET_SIZE and just added PyDict_GET_SIZE. Many names are just transparent wrappers around PyDict API (and they can't be different). Since PyODict C API is not documented, partially not working and partially redundant, and the C implementation of OrderedDict is optional (other Python implementations can provide just Python implementation of OrderedDict), I think this C API should be made private if not removed. ---------- components: Interpreter Core messages: 284098 nosy: eric.snow, rhettinger, serhiy.storchaka priority: normal severity: normal status: open title: C API of OrderedDict _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 27 12:39:24 2016 From: report at bugs.python.org (Ned Batchelder) Date: Tue, 27 Dec 2016 17:39:24 +0000 Subject: [New-bugs-announce] [issue29085] Python 3.6 on Windows doesn't seed Random() well enough Message-ID: <1482860364.41.0.203895591313.issue29085@psf.upfronthosting.co.za> New submission from Ned Batchelder: Creating two Random() instances in quick succession produces the same sequence, but only on Windows on Python 3.6. On 3.5 or earlier, or on Mac/Linux, the randomization is good. Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 07:18:10) [MSC v.1900 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import random; print(random.Random().randint(1, 999999), random.Random().randint(1, 999999)) 903885 903885 >>> import random; print(*[random.Random().randint(1, 999999) for _ in range(2)]) 996947 56476 >>> import random; print(*[random.Random().randint(1, 999999) for _ in range(2)]) 793282 793282 >>> import random; print(*[random.Random().randint(1, 999999) for _ in range(2)]) 519702 519702 >>> import random; print(*[random.Random().randint(1, 999999) for _ in range(2)]) 230678 230678 >>> import random; print(*[random.Random().randint(1, 999999) for _ in range(3)]) 474701 474701 474701 >>> import random; print(*[random.Random().randint(1, 999999) for _ in range(3)]) 890942 890942 890942 >>> import random; print(*[random.Random().randint(1, 999999) for _ in range(3)]) 997495 997495 997495 >>> import random; print(*[random.Random().randint(1, 999999) for _ in range(5)]) 27803 27803 27803 27803 919401 >>> I would expect each of these runs to produce unique numbers, with no duplicates. ---------- keywords: 3.6regression messages: 284118 nosy: nedbat priority: normal severity: normal status: open title: Python 3.6 on Windows doesn't seed Random() well enough _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 27 14:01:59 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Dec 2016 19:01:59 +0000 Subject: [New-bugs-announce] [issue29086] Document C API that is not part of the limited API Message-ID: <1482865319.03.0.627052322458.issue29086@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: >From the documentation: https://docs.python.org/3/c-api/stable.html In the C API documentation, API elements that are not part of the limited API are marked as "Not part of the limited API." But they don't. Following sample patch adds the notes to Unicode Objects and Codecs C API. I'm going to add them to all C API. What are your though about formatting the note? Should it be before the description, after the description, but before the "deprecated" directive (as in the patch), or after the first paragraph of the description? Should it be on the separate line or be appended at the end of the previous paragraph, or starts the first paragraph (if before the description)? May be introduce a special directive for it? ---------- assignee: docs at python components: Documentation files: unicode-not-part-of-the-limited-api.patch keywords: patch messages: 284125 nosy: docs at python, georg.brandl, serhiy.storchaka priority: normal severity: normal status: open title: Document C API that is not part of the limited API type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46057/unicode-not-part-of-the-limited-api.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 27 14:13:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Dec 2016 19:13:23 +0000 Subject: [New-bugs-announce] [issue29087] UCS4 support functions are not implemented Message-ID: <1482866003.6.0.322450240953.issue29087@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: There is a special section in the documentation of Unicode Objects C API: UCS4 Support. https://docs.python.org/3/c-api/unicode.html#ucs4-support It documents utility functions that work on strings of Py_UCS4 characters like Py_UCS4_strlen(), Py_UCS4_strcpy(), etc. But none of these functions is implemented. May be the documentation should be just removed? ---------- assignee: docs at python components: Documentation, Unicode messages: 284126 nosy: benjamin.peterson, docs at python, ezio.melotti, haypo, lemburg, serhiy.storchaka priority: normal severity: normal status: open title: UCS4 support functions are not implemented type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 27 15:22:35 2016 From: report at bugs.python.org (Kodiologist) Date: Tue, 27 Dec 2016 20:22:35 +0000 Subject: [New-bugs-announce] [issue29088] Inconsistent use of underscore in names that start with "is" Message-ID: <1482870155.37.0.889856609574.issue29088@psf.upfronthosting.co.za> New submission from Kodiologist: Compare ``isinstance``, ``issubclass``, and ``islower`` to ``is_integer``, ``is_fifo``, and ``is_enabled``. In Python 3.6, of all the names in the standard library starting with ``is``, I count 69 names with the underscore and 91 without. It seems better to pick one way or the other and stick with it. I would recommend using the underscore, for legibility. ---------- messages: 284133 nosy: Kodiologist priority: normal severity: normal status: open title: Inconsistent use of underscore in names that start with "is" versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 27 16:27:05 2016 From: report at bugs.python.org (Xezlec) Date: Tue, 27 Dec 2016 21:27:05 +0000 Subject: [New-bugs-announce] [issue29089] Python 2 dictionary keys described incorrectly Message-ID: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za> New submission from Xezlec: In section 5.5 on the page https://docs.python.org/2/tutorial/datastructures.html#dictionaries the requirements given for dictionary keys are not correct. Specifically, it is claimed that only immutable objects (and tuples containing only immutable objects) may be used as keys. This is false, as user-defined mutable objects may be used as keys. I suggest rewording along these lines: "Only user-defined objects and immutable built-in types may be used as keys. Although allowed, it is bad practice to use a mutable user-defined object as a key when equality is determined in any way other than identity (the default)." ---------- assignee: docs at python components: Documentation messages: 284135 nosy: Xezlec, docs at python priority: normal severity: normal status: open title: Python 2 dictionary keys described incorrectly versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 27 21:40:00 2016 From: report at bugs.python.org (Mike Hobbs) Date: Wed, 28 Dec 2016 02:40:00 +0000 Subject: [New-bugs-announce] [issue29090] python34.dll crash Message-ID: <1482892800.26.0.562397151262.issue29090@psf.upfronthosting.co.za> New submission from Mike Hobbs: Only info (Windows event viewer): Faulting application python_cc.exe, version 0.0.0.0, faulting module python34.dll, version 3.4.3150.1013, fault address 0x001059b7 Note: python_cc.exe is renamed python.exe to identify it in task manager. OS is Windows XP SP3 The following script crashes the python executable every few hours (not regular, seemingly random). The exact same script also crashes python 2.7.13. Each version has the latest pyserial module installed for the appropriate python version. When python 2.7 crashes, the reported error is always in _ctypes.dll which is used extensively in the serialwin32.py for reading the serial port, but python 3.4 fails in the main DLL. This same script has been running without a problem for several years on the same hardware (Quad core Shuttle with CurrentCost 128 electricity monitor on COM3, using PL2303 serial/USB chipset (probably clone)). The crashes have only occured since harddisc replacement involving new XP installation and reinstallation of application software. Occasionally, the crash results in a blue screen but usually its just the task crash notification (which I automatically dismiss using AutoIt3 watchdog script). Everything else on the machine id running normally so the serial port handling is the prime suspect. import serial, sys, time, traceback, os import xml.etree.ElementTree as ET correction = 1.074 # 247V when CC128 is designed for 230V path = "E:\\Apache\\htdocs\\energy\\elec_data\\" log = "E:\\Apache\\htdocs\\energy\\log.txt" ser = None amps = [0,0,0,0] def localtime(): y,m,d,h,mn,s,wd,b,c = time.localtime() return '%4d%02d%02d %02d%02d%02d' % (y,m,d,h,mn,s) def dbg(msg): msg = msg.strip() print(msg) if len(msg) <= 2: return global log # avoid huge files if os.path.getsize(log) > 2000000: y,m,d,h,mn,s,wd,b,c = time.localtime() old = 'log_%4d%02d%02d_%02d%02d%02d.txt' % (y,m,d,h,mn,s) os.rename(log, old) f = open(log, 'a') t = localtime() f.write('%s %s\n' % (t, msg)) f.close() try: ser = serial.Serial(port="COM3", baudrate=57600, bytesize=serial.EIGHTBITS, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, timeout=3) dbg("Connected to CurrentCost meter") except serial.SerialException: dbg("Failed to connect to CurrentCost meter") sys.exit(1) err_count = 0 while True: try: line = ser.readline().strip() # should be something every 6 seconds if line: watts = '' try: msg = ET.fromstring(line) watts = msg.findtext('ch1/watts') watts = float(watts) err_count = 0 except: watts = '' err_count += 1 finally: try: del exc_info except: pass if watts: # _ _ _ _ # _ or __ regarded as bogus amps[0] = amps[1]; amps[1] = amps[2]; amps[2] = amps[3] amps[3] = float(watts)*.00405 # 247 volts bogus = False if amps[1]>0 and amps[1] < amps[0]/2: if amps[1] < amps[2]/2: bogus = True if amps[1] < amps[3]/2 and amps[2] < amps[3]/2: bogus = True #dbg('%s %s %s %s %s' % (amps[0],amps[1],amps[2],amps[3],bogus)) if not bogus and amps[2]>0 and amps[3]>0: y,m,d,h,mn,s,a,b,c = time.localtime() try: line = '%f,%f' % (float(h)+float(mn)/60+float(s)/3600, amps[1]) f = open('%s\\%4d%02d%02d.csv' % (path,y,m,d), 'a') f.write('%s\n' % line) f.close() except: exc_info = sys.exc_info() dbg('CC EXCEPTION %s ' % traceback.format_exception(*exc_info)) finally: try: del exc_info # force garbage collection except: pass else: if err_count > 100: dbg("100 consecutive errors detected") break except serial.SerialException: exc_info = sys.exc_info() dbg('CC EXCEPTION %s ' % traceback.format_exception(*exc_info)) ser.close() sys.exit(1) except KeyboardInterrupt: ser.close() sys.exit(0) except: exc_info = sys.exc_info() dbg('CC EXCEPTION %s ' % traceback.format_exception(*exc_info)) finally: try: del exc_info # force garbage collection except: pass ser.close() sys.exit(1) ---------- components: Windows messages: 284148 nosy: MikeH, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: python34.dll crash type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 28 02:23:21 2016 From: report at bugs.python.org (Seth Michael Larson) Date: Wed, 28 Dec 2016 07:23:21 +0000 Subject: [New-bugs-announce] [issue29091] Python 3.5+ socket.socketpair fallback incorrectly implemented Message-ID: <1482909801.54.0.391034460781.issue29091@psf.upfronthosting.co.za> New submission from Seth Michael Larson: The socket.socketpair() fallback for Python 3.5+ is incorrectly implemented from the original source. The fallback doesn't provide a backlog argument to the lsock.listen() function call. When running the function it gives the following error: `TypeError: listen() takes exactly one argument (0 given)` Issue can be seen here on line 514: https://hg.python.org/cpython/file/3.6/Lib/socket.py Should add 1 as the argument to listen() to bring the implementation in line with the source implementation at: https://gist.github.com/geertj/4325783 ---------- components: Library (Lib) messages: 284158 nosy: SethMichaelLarson priority: normal severity: normal status: open title: Python 3.5+ socket.socketpair fallback incorrectly implemented type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 28 03:42:25 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 28 Dec 2016 08:42:25 +0000 Subject: [New-bugs-announce] [issue29092] Sync os.stat's doc and doc string Message-ID: <1482914545.99.0.849195642081.issue29092@psf.upfronthosting.co.za> New submission from Xiang Zhang: The accepted types of parameter *path* are different between os.stat's doc and doc string. In doc, it mentions Pathlike, string and file descriptor. In doc string, it mentions string, bytes and file descriptor. (3.5 only lack bytes in doc). ---------- assignee: docs at python components: Documentation files: doc-os-stat.patch keywords: patch messages: 284167 nosy: docs at python, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Sync os.stat's doc and doc string versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46061/doc-os-stat.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 28 07:48:17 2016 From: report at bugs.python.org (Evan) Date: Wed, 28 Dec 2016 12:48:17 +0000 Subject: [New-bugs-announce] [issue29093] Windows launcher breaks history in Git Bash Message-ID: <1482929297.98.0.0622229530904.issue29093@psf.upfronthosting.co.za> New submission from Evan: When I launch *any* version of Python using py.exe from Git Bash, the up and down arrows clear the line buffer instead of navigating history. The following things all work as intended: * py.exe in cmd.exe * py.exe in Git Bash using winpty * Python 2.7, 3.5, 3.6 when run directly The only thing that appears to trigger this bug is using the launcher in Git Bash without winpty. Tested with the following versions of Git Bash: * GNU bash, version 4.3.42(2)-release (x86_64-pc-msys) * GNU bash, version 4.3.46(2)-release (x86_64-pc-msys) Unfortunately I can't point to exactly which version of the launcher introduced this bug. Initially I was certain this only happened when I upgraded from 3.5.2 to 3.6.0, but now I've checked another machine with 3.5.2 and 3.4.4, and the bug appears there too. ---------- components: Windows messages: 284171 nosy: evan_, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows launcher breaks history in Git Bash versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 28 08:26:31 2016 From: report at bugs.python.org (Peter Ebden) Date: Wed, 28 Dec 2016 13:26:31 +0000 Subject: [New-bugs-announce] [issue29094] Regression in zipfile writing in 2.7.13 Message-ID: <1482931591.96.0.8795611166.issue29094@psf.upfronthosting.co.za> New submission from Peter Ebden: In Python 2.7.13, using zipfile.ZipFile to write into a file with some initial preamble produces a zip file that cannot be read again by some zip implementations. Our use case is using pex (https://github.com/pantsbuild/pex) which writes a zip that begins with a shebang, and later attempting to manipulate that using Go's standard archive/zip package. In 2.7.12 that works OK, but in 2.7.13 the .pex file is rejected on reading. Linux's command-line unzip tool will read the archive, but issues a warning ("4 extra bytes at beginning or within zipfile") which wasn't present previously. zipfile.ZipFile does read the files OK. I assume this is related to https://bugs.python.org/issue26293 since that's the most obvious zipfile change in 2.7.13. It's pretty easy to reproduce using the example in that issue: from zipfile import ZipFile with open('a.zip', 'wb') as base: base.write(b'old\n') with ZipFile(base, 'a') as myzip: myzip.write('eggs.txt') unzip -t a.zip Archive: a.zip warning [a.zip]: 4 extra bytes at beginning or within zipfile (attempting to process anyway) ... ---------- components: Library (Lib) messages: 284172 nosy: Peter Ebden priority: normal severity: normal status: open title: Regression in zipfile writing in 2.7.13 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 28 15:02:42 2016 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Wed, 28 Dec 2016 20:02:42 +0000 Subject: [New-bugs-announce] [issue29095] Compiling Python 3.6 from source on MacOS X Sierra Message-ID: <1482955362.45.0.530145158959.issue29095@psf.upfronthosting.co.za> New submission from Walter D?rwald: I'm trying to compile Python 3.6 from source on MacOS X Sierra. However it seems that the _ssl module doesn't get built. Attached is the complete output. Note that I have openssl installed via homebrew: ~/ ? brew list openssl /usr/local/Cellar/openssl/1.0.2j/bin/c_rehash /usr/local/Cellar/openssl/1.0.2j/bin/openssl /usr/local/Cellar/openssl/1.0.2j/include/openssl/ (75 files) /usr/local/Cellar/openssl/1.0.2j/lib/libcrypto.1.0.0.dylib /usr/local/Cellar/openssl/1.0.2j/lib/libssl.1.0.0.dylib /usr/local/Cellar/openssl/1.0.2j/lib/engines/ (12 files) /usr/local/Cellar/openssl/1.0.2j/lib/pkgconfig/ (3 files) /usr/local/Cellar/openssl/1.0.2j/lib/ (4 other files) /usr/local/Cellar/openssl/1.0.2j/share/man/ (1592 files) but if I understood Mac/BuildScript/resources/ReadMe.rtf correctly, this should be irrelevant. Anyway the resulting pip seems to be unusable: ~/ ? python -mpip install cx_Oracle pip is configured with locations that require TLS/SSL, however the ssl module in Python is not available. Collecting cx_Oracle Could not fetch URL https://pypi.python.org/simple/cx-oracle/: There was a problem confirming the ssl certificate: Can't connect to HTTPS URL because the SSL module is not available. - skipping ---------- components: Build files: Python3.6-build.log messages: 284193 nosy: doerwalter priority: normal severity: normal status: open title: Compiling Python 3.6 from source on MacOS X Sierra versions: Python 3.6 Added file: http://bugs.python.org/file46065/Python3.6-build.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 28 15:38:35 2016 From: report at bugs.python.org (Ted Meyer) Date: Wed, 28 Dec 2016 20:38:35 +0000 Subject: [New-bugs-announce] [issue29096] Signal Handlers reliably cause UnboundLocalErrors Message-ID: <1482957515.7.0.441178310139.issue29096@psf.upfronthosting.co.za> New submission from Ted Meyer: Using this simple snippit of code: import signal import signal def sig_hdlr(signum, frame): raise ValueError() def faulty(): local_var = "" signal.signal(signal.SIGALRM, sig_hdlr) signal.alarm(1) try: while True: local_var += "!" except ValueError: print (local_val) faulty() I can reliably get a crash: tmathmeyer at tmathmeyer-linuxstation:~$ python --version Python 2.7.6 tmathmeyer at tmathmeyer-linuxstation:~$ python pybug.py Traceback (most recent call last): File "pybug.py", line 16, in faulty() File "pybug.py", line 14, in faulty print local_val NameError: global name 'local_val' is not defined tmathmeyer at tmathmeyer-linuxstation:~$ python3.4 pybug.py Traceback (most recent call last): File "pybug.py", line 12, in faulty local_var += "!" File "pybug.py", line 4, in sig_hdlr raise ValueError() ValueError During handling of the above exception, another exception occurred: Traceback (most recent call last): File "pybug.py", line 16, in faulty() File "pybug.py", line 14, in faulty print (local_val) NameError: name 'local_val' is not defined I can repro this on 2.7.6 and 3.4, but do not have other versions to test on. ---------- messages: 284196 nosy: Ted Meyer priority: normal severity: normal status: open title: Signal Handlers reliably cause UnboundLocalErrors versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 28 15:49:20 2016 From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=) Date: Wed, 28 Dec 2016 20:49:20 +0000 Subject: [New-bugs-announce] [issue29097] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6 Message-ID: <1482958160.11.0.32337159902.issue29097@psf.upfronthosting.co.za> New submission from Pekka Kl?rck: For example: E:\>py -3.6 -c "import datetime; datetime.datetime.fromtimestamp(42)" Traceback (most recent call last): File "", line 1, in OSError: [Errno 22] Invalid argument Works fine at least with Python 2.6-2.7 and 3.3-3.5. Only tested on Windows (missing deadsnakes for easy Linux testing). I was also surprised to get OSError in general, but apparently fromtimestamp uses that instead of ValueError nowadays in some error situations. ---------- messages: 284199 nosy: pekka.klarck priority: normal severity: normal status: open title: datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6 versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 28 17:08:50 2016 From: report at bugs.python.org (Carl George) Date: Wed, 28 Dec 2016 22:08:50 +0000 Subject: [New-bugs-announce] [issue29098] document minimum sqlite version Message-ID: <1482962930.74.0.760741820297.issue29098@psf.upfronthosting.co.za> New submission from Carl George: While attempting to build a Python 3.6 RPM for RHEL/CentOS 6, I noticed the following warning. *** WARNING: renaming "_sqlite3" since importing it failed: build/lib.linux-i686-3.6-pydebug/_sqlite3.cpython-36dm-i386-linux-gnu.so: undefined symbol: sqlite3_stmt_readonly I was able to locate changeset 284676cf2ac8 (#10740) which introduced the usage of the sqlite3_stmt_readonly interface. That interface wasn't added to sqlite until 3.7.4 (http://www.sqlite.org/releaselog/3_7_4.html). My RPM build failed because RHEL/CentOS 6 only has sqlite 3.6.20. I understand that Python can't support old libraries forever, but can this minimum sqlite version be noted somewhere in the documentation? ---------- assignee: docs at python components: Documentation messages: 284202 nosy: carlwgeorge, docs at python priority: normal severity: normal status: open title: document minimum sqlite version versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 28 18:04:29 2016 From: report at bugs.python.org (Bozo Kopic) Date: Wed, 28 Dec 2016 23:04:29 +0000 Subject: [New-bugs-announce] [issue29099] sqlite3 timestamp converter ValueError Message-ID: <1482966269.67.0.620298847284.issue29099@psf.upfronthosting.co.za> New submission from Bozo Kopic: Current convert_timestamp function raises exception when parsing timestamps that contain timezone information and have microsecond set to zero. Patch for this behavior is included. Example script that demonstrates this problem: import sys import datetime import sqlite3 import traceback import contextlib def main(): db = sqlite3.connect('test.db', detect_types=sqlite3.PARSE_DECLTYPES) db.executescript(""" CREATE TABLE IF NOT EXISTS test ( timestamp TIMESTAMP) """) t = datetime.datetime.now(tz=datetime.timezone.utc) t = t.replace(microsecond=0) db.executemany("INSERT INTO test VALUES (:timestamp)", [{'timestamp': t}]) db.commit() with contextlib.closing(db.cursor()) as c: try: c.execute('SELECT * FROM test') c.fetchall() print('original implementation success') except Exception as e: print('original implementation failed') traceback.print_exc() c.close() sqlite3.register_converter("timestamp", _sqlite_convert_timestamp) with contextlib.closing(db.cursor()) as c: try: c.execute('SELECT * FROM test') c.fetchall() print('patched implementation success') except Exception as e: print('patched implementation failed') traceback.print_exc() c.close() def _sqlite_convert_timestamp(val): datepart, timepart = val.split(b" ") # this is the patch timepart = timepart.split(b'+', 1)[0].split(b'-', 1)[0] year, month, day = map(int, datepart.split(b"-")) timepart_full = timepart.split(b".") hours, minutes, seconds = map(int, timepart_full[0].split(b":")) if len(timepart_full) == 2: microseconds = int('{:0<6.6}'.format(timepart_full[1].decode())) else: microseconds = 0 val = datetime.datetime(year, month, day, hours, minutes, seconds, microseconds) return val if __name__ == '__main__': sys.exit(main()) ---------- components: Library (Lib) files: sqlite3.patch keywords: patch messages: 284205 nosy: bozo.kopic priority: normal severity: normal status: open title: sqlite3 timestamp converter ValueError type: crash versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46067/sqlite3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 28 19:50:47 2016 From: report at bugs.python.org (Jordon Phillips) Date: Thu, 29 Dec 2016 00:50:47 +0000 Subject: [New-bugs-announce] [issue29100] Core dump / OverflowError for datetime.fromtimestamp with overly large timestamp in Ubuntu 12.04 Message-ID: <1482972647.78.0.524140289263.issue29100@psf.upfronthosting.co.za> New submission from Jordon Phillips: In Python 3.6.0 if you give datetime.fromtimestamp a very bad value you either get a core dump or an OverflowError. The core dump occurs when no tzinfo is provided, the OverflowError occurs when a tzinfo is provided (such as tzlocal from dateutil). Attached is a minimal script to reproduce the error. Note that this behavior only occurs on certain systems. It does not happen on OSX 10.11.6, but it does happen on Ubuntu 12.04. I imagine it happens on other systems as well, but I haven't tested beyond those two. Here are the specific errors I get on Ubuntu 12.04. When no tzinfo is provided: python: /tmp/python-build.20161228223921.28011/Python-3.6.0/Modules/_datetimemodule.c:251: days_before_year: Assertion `year >= 1' failed. Aborted (core dumped) When a tzinfo is provided: Traceback (most recent call last): File "test1.py", line 11, in datetime.fromtimestamp(bad_st_mtime, local_time_zone) File "~/.pyenv/versions/venv36d/lib/python3.6/site-packages/dateutil/tz/_common.py", line 210, in fromutc dt_wall = self._fromutc(dt) File "~/.pyenv/versions/venv36d/lib/python3.6/site-packages/dateutil/tz/_common.py", line 195, in _fromutc return dt + dtdst OverflowError: date value out of range I imagine this is related to the fold changes. ---------- components: Library (Lib) files: test.py messages: 284218 nosy: Jordon Phillips priority: normal severity: normal status: open title: Core dump / OverflowError for datetime.fromtimestamp with overly large timestamp in Ubuntu 12.04 type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46068/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 28 22:58:24 2016 From: report at bugs.python.org (Victor Liu) Date: Thu, 29 Dec 2016 03:58:24 +0000 Subject: [New-bugs-announce] [issue29101] Nested lambdas in setattr() lose context in Python 2.7 Message-ID: <1482983904.15.0.0148999643172.issue29101@psf.upfronthosting.co.za> New submission from Victor Liu: I would expect bug.py to output: foo bar baz but instead we observe: baz baz baz Replicated on Windows 10 Home Edition, Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:42:59) [MSC v.1500 32 bit (Intel)] ---------- files: bug.py messages: 284224 nosy: Victor Liu priority: normal severity: normal status: open title: Nested lambdas in setattr() lose context in Python 2.7 type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file46069/bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 29 01:53:42 2016 From: report at bugs.python.org (Eric Snow) Date: Thu, 29 Dec 2016 06:53:42 +0000 Subject: [New-bugs-announce] [issue29102] Add an id field to PyInterpreterState. Message-ID: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za> New submission from Eric Snow: Currently there isn't any way to uniquely identify an interpreter. This patch adds a new "id" field to the PyInterpreterState struct. The ID for every new interpreter is set to the value of an increasing global counter. That means that the ID is unique within the process. IIRC, the availability of unique ID would help tools that make use of subinterpreters, like mod_wsgi. It is also necessary for any effort to expose interpreters in Python-level code (which is the subject of other ongoing work). The patch also adds: unsigned long PyInterpreterState_GetID(PyInterpreterState *interp) Note that, without a Python-level interpreters module, testing this change is limited to extending the existing test code in test_capi. ---------- assignee: eric.snow components: Interpreter Core files: interpreter-id.diff keywords: patch messages: 284229 nosy: brett.cannon, eric.snow, grahamd, ncoghlan, steve.dower priority: normal severity: normal stage: patch review status: open title: Add an id field to PyInterpreterState. type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file46070/interpreter-id.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 29 02:37:30 2016 From: report at bugs.python.org (Jean-Sebastien Bevilacqua) Date: Thu, 29 Dec 2016 07:37:30 +0000 Subject: [New-bugs-announce] [issue29103] Make enum.py pep8 compliant Message-ID: <1482997050.71.0.505456771635.issue29103@psf.upfronthosting.co.za> New submission from Jean-Sebastien Bevilacqua: Hello, This is my first patch on CPython, so please tell me if I do something wrong. When executing flake8 on Lib/enum.py, there are lot of warning. This patch remove all these warnings. ---------- components: Library (Lib) files: enum_format.patch keywords: patch messages: 284234 nosy: barry, eli.bendersky, ethan.furman, realitix priority: normal severity: normal status: open title: Make enum.py pep8 compliant type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file46071/enum_format.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 29 06:56:25 2016 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Thu, 29 Dec 2016 11:56:25 +0000 Subject: [New-bugs-announce] [issue29104] Left bracket remains in format string result when '\' preceeds it Message-ID: <1483012585.51.0.342717701316.issue29104@psf.upfronthosting.co.za> New submission from Jim Fasarakis-Hilliard: In short: >>> f"\{10}" yields: "\\{10" This is reproducible only when `\` precedes the opening bracket, that is: >>> f"\ {10}" results in: "\\ 10" ---------- components: Interpreter Core messages: 284249 nosy: Jim Fasarakis-Hilliard priority: normal severity: normal status: open title: Left bracket remains in format string result when '\' preceeds it versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 29 11:29:54 2016 From: report at bugs.python.org (iMath) Date: Thu, 29 Dec 2016 16:29:54 +0000 Subject: [New-bugs-announce] [issue29105] code or doc improvement for logging.handlers.RotatingFileHandler Message-ID: <1483028994.58.0.687650973528.issue29105@psf.upfronthosting.co.za> New submission from iMath: For class logging.handlers.RotatingFileHandler(filename, mode='a', maxBytes=0, backupCount=0, encoding=None, delay=0) if backupCount is zero and maxBytes is non-zero, the log file size could exceed maxBytes, i.e. we are not able to restrict the log file size using RotatingFileHandler at this case . I suggest add the above description to the doc https://docs.python.org/3.6/library/logging.handlers.html#logging.handlers.RotatingFileHandler If possible , set backupCount=1 by default to avoid this pitfall as much as possible. The doc right now just says "if either of maxBytes or backupCount is zero, rollover never occurs.", it is too difficult to understand the meaning of 'Rollover' to aviod the pitfall . ---------- assignee: docs at python components: Documentation messages: 284277 nosy: docs at python, redstone-cold priority: normal severity: normal status: open title: code or doc improvement for logging.handlers.RotatingFileHandler type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 29 11:52:42 2016 From: report at bugs.python.org (Szabolcs Dombi) Date: Thu, 29 Dec 2016 16:52:42 +0000 Subject: [New-bugs-announce] [issue29106] get-pip.py fails with Python 3.6 embed Windows Message-ID: <1483030362.55.0.53701112975.issue29106@psf.upfronthosting.co.za> New submission from Szabolcs Dombi: Downloaded python 3.6 embedable zip file (windows 32 bit) Downloaded get-pip.py from the following URL: https://pip.pypa.io/en/stable/installing/ This is the traceback: Traceback (most recent call last): File "get-pip.py", line 20061, in main() File "get-pip.py", line 194, in main bootstrap(tmpdir=tmpdir) File "get-pip.py", line 82, in bootstrap import pip File "", line 961, in _find_and_load File "", line 950, in _find_and_load_unlocked File "", line 646, in _load_unlocked File "", line 616, in _load_backward_compatible File "C:\Users\User\AppData\Local\Temp\tmpinoq60hn\pip.zip\pip\__init__.py", line 26, in File "", line 961, in _find_and_load File "", line 950, in _find_and_load_unlocked File "", line 646, in _load_unlocked File "", line 616, in _load_backward_compatible File "C:\Users\User\AppData\Local\Temp\tmpinoq60hn\pip.zip\pip\utils\__init__.py", line 23, in File "", line 961, in _find_and_load File "", line 950, in _find_and_load_unlocked File "", line 646, in _load_unlocked File "", line 616, in _load_backward_compatible File "C:\Users\User\AppData\Local\Temp\tmpinoq60hn\pip.zip\pip\locations.py", line 88, in File "ntpath.py", line 75, in join TypeError: expected str, bytes or os.PathLike object, not NoneType ---------- messages: 284279 nosy: Szabolcs Dombi priority: normal severity: normal status: open title: get-pip.py fails with Python 3.6 embed Windows type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 29 13:23:48 2016 From: report at bugs.python.org (Naftali Harris) Date: Thu, 29 Dec 2016 18:23:48 +0000 Subject: [New-bugs-announce] [issue29107] traceback module incorrectly formats args-less syntax errors Message-ID: <1483035828.75.0.241561980745.issue29107@psf.upfronthosting.co.za> New submission from Naftali Harris: The traceback documentation states that it "exactly mimics the behavior of the Python interpreter when it prints a stack trace." Here's a small case where it doesn't, on 2.7.13: ~/repos/Python-2.7.13$ cat example.py def f(x): global x ~/repos/Python-2.7.13$ ./python.exe Python 2.7.13 (default, Dec 29 2016, 09:54:42) [GCC 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import traceback >>> import example Traceback (most recent call last): File "", line 1, in File "example.py", line 1 def f(x): SyntaxError: name 'x' is local and global >>> try: ... import example ... except: ... traceback.print_exc() ... Traceback (most recent call last): File "", line 2, in SyntaxError: name 'x' is local and global (example.py, line 1) >>> I believe Kurt fixed this for Python 3000 with https://mail.python.org/pipermail/python-3000-checkins/2007-July/001259.html ---------- components: Library (Lib) messages: 284287 nosy: Naftali.Harris, benjamin.peterson, kbk priority: normal severity: normal status: open title: traceback module incorrectly formats args-less syntax errors type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 29 16:57:31 2016 From: report at bugs.python.org (Jose Miguel Colella) Date: Thu, 29 Dec 2016 21:57:31 +0000 Subject: [New-bugs-announce] [issue29108] Python 3.6.0 multiprocessing map_async callback Message-ID: <1483048651.39.0.165070292977.issue29108@psf.upfronthosting.co.za> New submission from Jose Miguel Colella: Hello I am trying to use the callback for the map_async method for Pool, but have found a bug. In the below code, only the print statement is carried out, the return is completely ignored. Is this working as designed or is this a bug? from multiprocessing import Pool def f(x): return x * x def s(x): print(f'Here: {x}') return type(x) if __name__ == '__main__': with Pool(5) as p: result = p.map_async(f, [1, 2, 3], callback=s) q = result.get() print(q) ---------- components: Library (Lib) files: main2.py messages: 284295 nosy: Jose Miguel Colella priority: normal severity: normal status: open title: Python 3.6.0 multiprocessing map_async callback type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46084/main2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 29 18:39:06 2016 From: report at bugs.python.org (Loic Pefferkorn) Date: Thu, 29 Dec 2016 23:39:06 +0000 Subject: [New-bugs-announce] [issue29109] Small doc improvements for tracemalloc Message-ID: <1483054746.95.0.549035293258.issue29109@psf.upfronthosting.co.za> New submission from Loic Pefferkorn: Hello, I believe that some improvements can be made to the Python 3.4 documentation of the tracemalloc module: * Wrong parameter name, 'group_by' instead of 'key_type' (checked in tracemalloc.py) * Don't round up numbers when explaining the examples. If they exactly match what can be read in the script output, it is to easier to understand (4.8 MiB vs 4855 KiB) * Fix incorrect method link that was pointing to another module I will wait for some feedback before checking the 3.5, 3.6 versions, hopefully I did not forget something :) Cheers, Loic ---------- assignee: docs at python components: Documentation files: doc_3.4_tracemalloc.diff keywords: patch messages: 284298 nosy: docs at python, haypo, loicp priority: normal severity: normal status: open title: Small doc improvements for tracemalloc type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file46086/doc_3.4_tracemalloc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 29 19:55:17 2016 From: report at bugs.python.org (Anthony Zhang) Date: Fri, 30 Dec 2016 00:55:17 +0000 Subject: [New-bugs-announce] [issue29110] [patch] Fix file object leak in `aifc.open` when given invalid AIFF file. Message-ID: <1483059317.41.0.849254662988.issue29110@psf.upfronthosting.co.za> New submission from Anthony Zhang: Summary ------- This shows up as two closely-related issues: * ``aifc.open`` leaks file object when invalid AIFF file encountered. This is probably a bug. * ``aifc.close`` closes file object even when it didn't open the file object to begin with. While this is technically documented behaviour [1], it's inconsistent with how similar modules like ``wave`` work [2]. I have confirmed the issue is present in all the selected Python versions. Steps to reproduce ------------------ For the first issue, run this code: #!/usr/bin/env python3 # to simplify this example, use this script itself as a random non-AIFF file (though any non-AIFF file will work fine) FILE = __file__ # print warnings on stderr import warnings warnings.resetwarnings() # try to open the non-AIFF file as an AIFF file, which should fail, but shouldn't give any ResourceWarnings import aifc try: aifc.open(FILE, "rb") except: pass For the second issue, run this code: #!/usr/bin/env python3 from os import path FILE = path.expanduser("~/cpython/Lib/test/audiodata/pluck-pcm8.aiff") # open the file as a file-like object, then open it again with ``aifc.open`` import aifc with open(FILE, "rb") as f: assert not f.closed, "Before opening with AIFC" with aifc.open(f, "rb"): pass assert not f.closed, "After opening with AIFC" Expected result --------------- For the first code sample, code should give no output - ``aifc.open`` should throw an exception due to the passed filename being an invalid AIFF file, but that exception should be caught and suppressed. by the ``try``/``except`` statements. For the second code sample, all assertions should pass - the file should be opened with ``open``, "opened" again with ``aifc.open``, and should not be closed when the inner context manager exits. Actual result ------------- For the first code sample: $ python3 test.py /home/anthony/Desktop/test.py:13: ResourceWarning: unclosed file <_io.BufferedReader name='/home/anthony/Desktop/test.py'> except: pass In other words, code executes as described in "Expected result", but also prints a warning to stderr about the file object not being closed. For the second code sample: $ python3 "/home/anthony/Desktop/test.py" Traceback (most recent call last): File "/home/anthony/Desktop/test.py", line 11, in assert not f.closed, "After opening with AIFC" AssertionError: After opening with AIFC In other words, code runs normally until the inner context manager exits, and the file object gets closed, even though the file object wasn't opened by ``aifc``. Solution -------- Attached are patches that fix each issue separately - the first patch fixes the first mentioned issue, while the second patch fixes both at once. Backwards compatibility: * The first patch, "fix_aifc_leak.patch", makes no functionality changes, so there shouldn't be any backwards compatibility concerns. * The second patch, "fix_aifc_leak_and_file_object_close.patch", slightly changes the behaviour of `aifc_instance.close()` so that it closes in only a subset of cases it would originally. While it is possible for this to lead to leaks in certain cases (example below), the impact shoul be low, as existing codebases seem to use context managers and similar constructs that clean everything up properly. #!/usr/bin/env python3 from os import path FILE = path.expanduser("~/cpython/Lib/test/audiodata/pluck-pcm8.aiff") import aifc f = open(FILE, "rb") with aifc.open(f, "rb"): pass # with the patch applied, `f` is not closed at this point anymore [1]: https://docs.python.org/3/library/aifc.html#aifc.aifc.close [2]: https://docs.python.org/3/library/wave.html#wave.Wave_read.close ---------- components: Library (Lib) files: fix_aifc_leak.patch keywords: patch messages: 284299 nosy: azhang priority: normal severity: normal status: open title: [patch] Fix file object leak in `aifc.open` when given invalid AIFF file. type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46087/fix_aifc_leak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 29 20:59:53 2016 From: report at bugs.python.org (Antony Lee) Date: Fri, 30 Dec 2016 01:59:53 +0000 Subject: [New-bugs-announce] [issue29111] Strange signature for memoryview constructor Message-ID: <1483063193.08.0.841678787602.issue29111@psf.upfronthosting.co.za> New submission from Antony Lee: The return value of `inspect.signature(memoryview)` is rather strange: Python 3.5.2 (default, Nov 7 2016, 11:31:36) [GCC 6.2.1 20160830] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import inspect; inspect.signature(memoryview) ---------- components: Library (Lib) messages: 284302 nosy: Antony.Lee priority: normal severity: normal status: open title: Strange signature for memoryview constructor versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 29 21:04:27 2016 From: report at bugs.python.org (Jesse Hall) Date: Fri, 30 Dec 2016 02:04:27 +0000 Subject: [New-bugs-announce] [issue29112] questionable wording in sequences documentation Message-ID: <1483063467.95.0.432250545704.issue29112@psf.upfronthosting.co.za> New submission from Jesse Hall: In note 3 of 4.6.1, the word "string" should be replaced with "sequence", because the note is describing a general example where this concept is not specifically used with a string type sequence, it is discussing the general use of negative indexes which can be used on any type of sequence. ---------- assignee: docs at python components: Documentation messages: 284303 nosy: Jesse Hall, docs at python priority: normal severity: normal status: open title: questionable wording in sequences documentation versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 29 21:16:05 2016 From: report at bugs.python.org (Adam Williamson) Date: Fri, 30 Dec 2016 02:16:05 +0000 Subject: [New-bugs-announce] [issue29113] modulefinder no longer finds all required modules for Python itself, due to use of __import__ in sysconfig Message-ID: <1483064165.82.0.932079190988.issue29113@psf.upfronthosting.co.za> New submission from Adam Williamson: I'm not sure if this is really considered a bug or just an unavoidable limitation, but as it involves part of the stdlib operating on Python itself, I figured it was at least worth reporting. In Fedora we have a fairly simple little script called python-deps: https://github.com/rhinstaller/anaconda/blob/master/dracut/python-deps which is used to figure out the dependencies of a couple of Python scripts used in the installer's initramfs environment, so the necessary bits of Python (but not the rest of it) can be included in the installer's initramfs. Unfortunately, with Python 3.6, this seems to be broken for the core of Python itself, because of this change: https://github.com/python/cpython/commit/a6431f2c8cf4783c2fd522b2f6ee04c3c204237f which changed sysconfig.py from doing "from _sysconfigdata import build_time_vars" to using __import__ . I *think* that modulefinder can't cope with this use of __import__ and so misses that sysconfig requires "_sysconfigdata_m_linux_x86_64-linux-gnu" (or whatever the actual name is on your particular platform and arch). This results in us not including the platform-specific module in the installer initramfs, so Python blows up on startup when the 'site' module tries to import the 'sysconfig' module. We could work around this one way or another in the python-deps script, but I figured the issue was at least worth an upstream report to see if it's considered a significant issue or not. You can reproduce the problem quite trivially by writing a test script which just does, e.g., "import site", and then running the example code from the ModuleFinder docs on it: from modulefinder import ModuleFinder finder = ModuleFinder() finder.run_script('test.py') print('Loaded modules:') for name, mod in finder.modules.items(): print('%s: ' % name, end='') print(','.join(list(mod.globalnames.keys())[:3])) if you examine the output, you'll see that the 'sysconfig' module is included, but the site-specific module is not. ---------- components: Library (Lib) messages: 284304 nosy: adamwill priority: normal severity: normal status: open title: modulefinder no longer finds all required modules for Python itself, due to use of __import__ in sysconfig versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 30 00:53:38 2016 From: report at bugs.python.org (lanf0n) Date: Fri, 30 Dec 2016 05:53:38 +0000 Subject: [New-bugs-announce] [issue29114] __class__ not exists in the method which bounded by types.MethodType. Message-ID: <1483077218.4.0.672977492114.issue29114@psf.upfronthosting.co.za> New submission from lanf0n: test code below: ```python >>> from types import MethodType >>> class A: ... def f(self): ... print(__class__) ... >>> a = A() >>> a.fn = MethodType(lambda s: print(__class__), a) >>> >>> a.f() >>> a.fn() Traceback (most recent call last): File "", line 1, in File "", line 1, in NameError: name '__class__' is not defined ``` this behavior affect `super()` not work in patched function scope, of course we can use old super as super(self.__class__, self) to make it work as expected, but I think it should work as original method if we already bounded the function to instance(class). ---------- components: Library (Lib) messages: 284313 nosy: lanfon72 priority: normal severity: normal status: open title: __class__ not exists in the method which bounded by types.MethodType. type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 30 03:37:44 2016 From: report at bugs.python.org (Decorater) Date: Fri, 30 Dec 2016 08:37:44 +0000 Subject: [New-bugs-announce] [issue29115] distutils.core.setup does not let people set 'bugtrack_url'. Message-ID: <1483087064.15.0.921977916672.issue29115@psf.upfronthosting.co.za> New submission from Decorater: So, I could have an example setup.py which sets a bugtrack url however using sdist and bdist_wheel on them produces this warning: H:\Python\Python360\lib\distutils\dist.py:261: UserWarning: Unknown distribution option: 'bugtrack_url' warnings.warn(msg) The issue with this is wanting to set or change the bug track url's for the particular packages using setup.py to generate a PKG-INFO file which explicitly sets the value. Currently there is no way to modify the fields online anymore since probably like 3~4 months ago I before was able to do it for a little while without having to upload a PKG-INFO file. Example setup.py that does this: from setuptools import setup import re requirements = [] try: with open('requirements.txt') as f: requirements = f.read().splitlines() except Exception as ex: with open('sasync.egg-info\requires.txt') as f: requirements = f.read().splitlines() version = '0.0.1' if not version: raise RuntimeError('version is not set') with open('README') as f: readme = f.read() setup(name='examplepackage', author='Decorater', author_email='seandhunt_7 at yahoo.com', url='https://github.com/AraHaan/examplepackage', bugtrack_url='https://github.com/AraHaan/examplepackage/issues', version=version, packages=['sasync'], license='MIT', description=('example package package demonstrating that bugtrack_url is not recognized by distutils.'), long_description=readme, maintainer_email='seandhunt_7 at yahoo.com', download_url='https://github.com/AraHaan/examplepackage', include_package_data=True, install_requires=requirements, platforms='Any', classifiers=[ 'Development Status :: 4 - Beta', 'Environment :: Console', 'Intended Audience :: Developers', 'Intended Audience :: Other Audience', 'Intended Audience :: Science/Research', 'License :: OSI Approved :: MIT License', 'Natural Language :: English', 'Operating System :: OS Independent', 'Programming Language :: Python :: 3.4', 'Programming Language :: Python :: 3.5', 'Programming Language :: Python :: 3.6', 'Topic :: Software Development :: Libraries :: Python Modules', ] ) ---------- components: Distutils, Library (Lib) messages: 284323 nosy: Decorater, dstufft, eric.araujo priority: normal severity: normal status: open title: distutils.core.setup does not let people set 'bugtrack_url'. versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 30 13:56:51 2016 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Fri, 30 Dec 2016 18:56:51 +0000 Subject: [New-bugs-announce] [issue29116] Make str and bytes error messages on concatenation conform with other sequences Message-ID: <1483124211.75.0.715869443236.issue29116@psf.upfronthosting.co.za> New submission from Jim Fasarakis-Hilliard: Specifically, bytes (always, from what I could find) had this error message: >>> b'' + '' TypeError: can't concat bytes to str while str, after a change in issue26057, was made to: >>> '' + b'' TypeError: must be str, not bytes from the previous form of "TypeError: Can't convert 'bytes' object to str implicitly". I think these could be changed to conform with what the other sequences generate and fall in line with the error messages produced for other operations. Specifically changing them to: >>> b'' + '' TypeError: can only concatenate bytes (not 'str') to bytes and similarly for str. If this idea makes sense, I can attach a patch that addresses it. ---------- components: Interpreter Core messages: 284340 nosy: Jim Fasarakis-Hilliard priority: normal severity: normal status: open title: Make str and bytes error messages on concatenation conform with other sequences type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 30 16:51:10 2016 From: report at bugs.python.org (Antony Lee) Date: Fri, 30 Dec 2016 21:51:10 +0000 Subject: [New-bugs-announce] [issue29117] dir() should include dunder attributes of the unbound method Message-ID: <1483134670.11.0.964598948516.issue29117@psf.upfronthosting.co.za> New submission from Antony Lee: ``` Python 3.5.2 (default, Nov 7 2016, 11:31:36) [GCC 6.2.1 20160830] on linux Type "help", "copyright", "credits" or "license" for more information. >>> class C: ... def f(self): pass ... >>> C.f.attr = 42 >>> print(dir(C.f)) ['__annotations__', '__call__', '__class__', '__closure__', '__code__', '__defaults__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__get__', '__getattribute__', '__globals__', '__gt__', '__hash__', '__init__', '__kwdefaults__', '__le__', '__lt__', '__module__', '__name__', '__ne__', '__new__', '__qualname__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'attr'] >>> print(dir(C().f)) ['__call__', '__class__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', '__func__', '__ge__', '__get__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__self__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'attr'] >>> ``` Note that `dir(C().f)` does include the custom `attr` attribute, but is missing some of the dunder attributes (e.g. `__annotations__`), which are actually accessible directly from the boun method. ---------- components: Interpreter Core messages: 284347 nosy: Antony.Lee priority: normal severity: normal status: open title: dir() should include dunder attributes of the unbound method versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 30 22:45:01 2016 From: report at bugs.python.org (Spacemage 33) Date: Sat, 31 Dec 2016 03:45:01 +0000 Subject: [New-bugs-announce] [issue29118] Randit Message-ID: <1483155901.64.0.660907130999.issue29118@psf.upfronthosting.co.za> New submission from Spacemage 33: I have a book with i can learn phyton but in the first Little game there is "from random import randit" and the book is for Phyton3 now it do not work im realy said about this please fix that ---------- assignee: terry.reedy components: IDLE files: Screenshot_4.png messages: 284358 nosy: Spacemage 33, terry.reedy priority: normal severity: normal status: open title: Randit versions: Python 3.6 Added file: http://bugs.python.org/file46096/Screenshot_4.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 31 01:11:43 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 31 Dec 2016 06:11:43 +0000 Subject: [New-bugs-announce] [issue29119] Unintentional hard reference assignment in Python version of OrderedDict.move_to_end Message-ID: <1483164703.14.0.0947290095452.issue29119@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The root.prev and first.prev assignments should use weak references rather than hard references. Spotted by Andra Bogildea. ---------- components: Library (Lib) files: od_proxy.diff keywords: patch messages: 284367 nosy: rhettinger priority: normal severity: normal status: open title: Unintentional hard reference assignment in Python version of OrderedDict.move_to_end type: resource usage versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46097/od_proxy.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 31 06:36:34 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 31 Dec 2016 11:36:34 +0000 Subject: [New-bugs-announce] [issue29120] Rename Python/random.c to Python/bootstrap_hash.c Message-ID: <1483184194.47.0.551318865872.issue29120@psf.upfronthosting.co.za> New submission from Nick Coghlan: This is the last major structural refactoring proposal to come out of the prep work on the PEP 432 modular bootstrapping feature development branch: * rename Python/random.c -> Python/hash_randomization.c * rename _PyRandom_Init -> __Py_HashRandomization_Init * rename _PyRandom_Fini -> __Py_HashRandomization_Fini The current naming is confusing when working on the interpreter startup sequence as the file and API naming looks like it relates to initialising the random module, when it has nothing to do with that. ---------- assignee: ncoghlan messages: 284383 nosy: brett.cannon, christian.heimes, eric.snow, ncoghlan, steve.dower priority: normal severity: normal stage: needs patch status: open title: Rename Python/random.c to Python/bootstrap_hash.c type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 31 11:04:55 2016 From: report at bugs.python.org (Aviv Palivoda) Date: Sat, 31 Dec 2016 16:04:55 +0000 Subject: [New-bugs-announce] [issue29121] sqlite3 Controlling Transactions documentation not updated Message-ID: <1483200295.1.0.801871810477.issue29121@psf.upfronthosting.co.za> New submission from Aviv Palivoda: commit 284676cf2ac8 changed the sqlite3 module so it will no longer implicitly commit an open transaction before DDL statements. The docs have been updated but there is still an incorrect paragraph that has not been removed. Attached is a patch that remove the old paragraph. ---------- files: sqlite-transaction-doc.patch keywords: patch messages: 284396 nosy: berker.peksag, ghaering, palaviv, serhiy.storchaka priority: normal severity: normal status: open title: sqlite3 Controlling Transactions documentation not updated versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46101/sqlite-transaction-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 31 12:33:48 2016 From: report at bugs.python.org (styg) Date: Sat, 31 Dec 2016 17:33:48 +0000 Subject: [New-bugs-announce] [issue29122] set() bug Message-ID: <1483205628.15.0.98024774147.issue29122@psf.upfronthosting.co.za> New submission from styg: set() method leads to this error: a=[1,2,3,3] b=set(a) print b >> set([1,2,3]) # should be [1,2,3] ---------- messages: 284402 nosy: styg priority: normal severity: normal status: open title: set() bug type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 31 12:41:47 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 31 Dec 2016 17:41:47 +0000 Subject: [New-bugs-announce] [issue29123] CheckSqlTimestamp is fragile Message-ID: <1483206107.71.0.541035804461.issue29123@psf.upfronthosting.co.za> New submission from Berker Peksag: ====================================================================== FAIL: CheckSqlTimestamp (sqlite3.test.types.DateTimeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/root/buildarea/3.6.angelico-debian-amd64/build/Lib/sqlite3/test/types.py", line 391, in CheckSqlTimestamp self.assertEqual(ts.year, now.year) AssertionError: 2016 != 2017 ---------------------------------------------------------------------- See http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.6/builds/93/steps/test/logs/stdio for details. In Lib/sqlite3/test/types.py, there is a comment saying # SQLite's current_timestamp uses UTC time, while datetime.datetime.now() uses local time. Unless I'm missing something, there is no reason not to use datetime.utcnow(). That would make the test more robust. ---------- components: Tests messages: 284404 nosy: berker.peksag priority: normal severity: normal stage: needs patch status: open title: CheckSqlTimestamp is fragile type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 31 12:51:05 2016 From: report at bugs.python.org (Liran Ringel) Date: Sat, 31 Dec 2016 17:51:05 +0000 Subject: [New-bugs-announce] [issue29124] Freeze fails to compile on windows Message-ID: <1483206665.88.0.0421614971405.issue29124@psf.upfronthosting.co.za> New submission from Liran Ringel: The patch fixes 3 bugs: 1. Include Python.h in frozen_dllmain.c - needed for Py_ARRAY_LENGTH symbol 2. DL_IMPORT is used in checkextensions_win32.py, but it's deprecated and not defined anymore. Replaced it with __declspec(dllimport) 3. Fix python lib path in winmakemakefile.py There is one more thing left to do to make it work, but it already has an open issue: http://bugs.python.org/issue28068 ---------- components: Demos and Tools, Windows files: fix-freeze-on-windows.patch keywords: patch messages: 284405 nosy: Liran Ringel, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Freeze fails to compile on windows type: compile error versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46104/fix-freeze-on-windows.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 31 14:00:30 2016 From: report at bugs.python.org (symphorien) Date: Sat, 31 Dec 2016 19:00:30 +0000 Subject: [New-bugs-announce] [issue29125] Shell injection via TIX_LIBRARY when using tkinter.tix Message-ID: <1483210830.52.0.920210756798.issue29125@psf.upfronthosting.co.za> New submission from symphorien: The tkinter.tix module looks for a Tix installation in the directory specified by the TIX_LIBRARY environment variable, but blindly trusts that it is a path in the filesystem. This enables a shell injection : TIX_LIBRARY='/dev/null}; exec gsimplecal;' python2 -c "from Tix import Tk; Tk()" or TIX_LIBRARY='/dev/null}; exec gsimplecal;' python3 -c "from tkinter.tix import Tk; Tk()" Python execs gsimplecal, waits on its completion and then raises a tkinter.TclError. The offending code is here : https://github.com/python/cpython/blob/master/Lib/tkinter/tix.py#L204-L208 ---------- components: Tkinter messages: 284408 nosy: symphorien priority: normal severity: normal status: open title: Shell injection via TIX_LIBRARY when using tkinter.tix type: security versions: Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 31 18:25:17 2016 From: report at bugs.python.org (Jim Nasby) Date: Sat, 31 Dec 2016 23:25:17 +0000 Subject: [New-bugs-announce] [issue29126] Fix comments about _PyThreadState_Current Message-ID: <1483226717.62.0.229510209962.issue29126@psf.upfronthosting.co.za> New submission from Jim Nasby: Attached patch fixes two comments in dictobject.c referring to no longer exposed _PyThreadState_Current variable. I also tweaked the grammar for that issue in NEWS, since it came up in my search. Apologies if that's considered gratuitous noise. ---------- components: Interpreter Core files: _PyThreadState_Current_comments.diff keywords: patch messages: 284415 nosy: Jim Nasby priority: normal severity: normal status: open title: Fix comments about _PyThreadState_Current type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file46106/_PyThreadState_Current_comments.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 31 21:44:14 2016 From: report at bugs.python.org (Eric Ahn) Date: Sun, 01 Jan 2017 02:44:14 +0000 Subject: [New-bugs-announce] [issue29127] Incorrect reference names in asyncio.subprocess documentation Message-ID: <1483238654.05.0.408550900872.issue29127@psf.upfronthosting.co.za> New submission from Eric Ahn: On this page of the documentation https://docs.python.org/3/library/asyncio-subprocess.html it seems that some of the reference names are incorrect. Namely, asyncio.subprocess.PIPE is referred to as asyncio.asyncio.subprocess.PIPE (along with STDOUT and DEVNULL), plus asyncio.subprocess.Process is referred to as asyncio.asyncio.subprocess.Process. This is reflected in the permalinks as well as when one tries to reference these via intersphinx (which is how I discovered it; I was trying to link to this page and was failing). ---------- assignee: docs at python components: Documentation messages: 284418 nosy: Eric Ahn, docs at python priority: normal severity: normal status: open title: Incorrect reference names in asyncio.subprocess documentation versions: Python 3.6 _______________________________________ Python tracker _______________________________________