From report at bugs.python.org Fri Dec 1 00:22:05 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 01 Dec 2017 05:22:05 +0000 Subject: [issue32190] Separate out legacy introspection APIs in the inspect docs Message-ID: <1512105725.63.0.213398074469.issue32190@psf.upfronthosting.co.za> New submission from Nick Coghlan : (Follow up to https://bugs.python.org/issue27172) The deprecation notice on inspect.getfullargspec has been removed, since we want folks porting from Python 2 to rely on it as part of the porting process, rather than feeling they need to upgrade to using inspect.signature() immediately. At the same time, we really don't want folks relying on it for *new* code, since it has some inherent limitations (like failing to distinguish positional-only args from positional-and-keyword ones), and some odd historical quirks (like reporting the bound arg as part of the signature for already bound methods). The subprocess modules clearly separates out the "Older high-level API" https://docs.python.org/3/library/subprocess.html#older-high-level-api to help make it clear that new code should use "subprocess.run" instead. We could potentially add a similar final section to the inspect documentation for "Legacy introspection APIs". That would also be useful if https://bugs.python.org/issue31230 is eventually implemented - the current generator and coroutine specific APIs could be moved down to the legacy section for backwards compatibility maintenance, with the type independent API being preferred for new code. ---------- assignee: docs at python components: Documentation messages: 307362 nosy: brett.cannon, docs at python, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Separate out legacy introspection APIs in the inspect docs type: enhancement versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 00:23:21 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 01 Dec 2017 05:23:21 +0000 Subject: [issue27172] Undeprecate inspect.getfullargspec() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1512105801.03.0.213398074469.issue27172@psf.upfronthosting.co.za> Nick Coghlan added the comment: Independently of what we eventually decide to do for 4.0, there are some changes we could make at the documentation level to more clearly indicate "Even though this isn't deprecated, you still shouldn't use it for new code": https://bugs.python.org/issue32190 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 00:34:07 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 01 Dec 2017 05:34:07 +0000 Subject: [issue32145] Wrong ExitStack Callback recipe In-Reply-To: <1511771653.67.0.213398074469.issue32145@psf.upfronthosting.co.za> Message-ID: <1512106447.81.0.213398074469.issue32145@psf.upfronthosting.co.za> Nick Coghlan added the comment: Hmm, I think that may actually qualify as a bug in the `pop_all()` implementation: https://docs.python.org/3/library/contextlib.html#contextlib.ExitStack.pop_all states that it returns an ExitStack instance, not an instance of the current type. For 3.6 (and hence the online docs), we can fix the recipe to allow for `callback=None` (with the expectation that the callback will be added afterwards). Barry, I'd be interested in your thoughts on what to do for 3.7+ - we can either leave the current behaviour alone, and amend the documentation, or else change the code to call ExitStack directly, rather than type(self). I'm leaning towards only changing the docs as being lower risk - folks may be relying on the current behaviour, so changing it may break their code, whereas changing the docs doesn't risk breaking anything. ---------- nosy: +barry versions: +Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 01:25:21 2017 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 01 Dec 2017 06:25:21 +0000 Subject: [issue25683] __context__ for yields inside except clause In-Reply-To: <1448036986.79.0.682793402944.issue25683@psf.upfronthosting.co.za> Message-ID: <1512109521.63.0.213398074469.issue25683@psf.upfronthosting.co.za> Change by Chris Jerdonek : ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 01:26:34 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Dec 2017 06:26:34 +0000 Subject: [issue32186] io.FileIO hang all threads if fstat blocks on inaccessible NFS server In-Reply-To: <1512066205.79.0.213398074469.issue32186@psf.upfronthosting.co.za> Message-ID: <1512109593.98.0.213398074469.issue32186@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 8bcd41040a5f1f9b48a86d0e21f196e4b1f90e4b by Victor Stinner (Miss Islington (bot)) in branch '3.6': bpo-32186: Release the GIL during lseek and fstat (GH-4652) (#4661) https://github.com/python/cpython/commit/8bcd41040a5f1f9b48a86d0e21f196e4b1f90e4b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 01:26:50 2017 From: report at bugs.python.org (Chris Jerdonek) Date: Fri, 01 Dec 2017 06:26:50 +0000 Subject: [issue25612] nested try..excepts don't work correctly for generators In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za> Message-ID: <1512109610.13.0.213398074469.issue25612@psf.upfronthosting.co.za> Change by Chris Jerdonek : ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 01:52:51 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Dec 2017 06:52:51 +0000 Subject: [issue32189] SyntaxError for yield expressions inside comprehensions & genexps In-Reply-To: <1512104258.87.0.213398074469.issue32189@psf.upfronthosting.co.za> Message-ID: <1512111171.88.0.213398074469.issue32189@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- components: +Interpreter Core keywords: +patch nosy: +serhiy.storchaka pull_requests: +4572 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 01:54:15 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Dec 2017 06:54:15 +0000 Subject: [issue32176] Zero argument super is broken in 3.6 for methods with a hacked __class__ cell In-Reply-To: <1512027575.04.0.213398074469.issue32176@psf.upfronthosting.co.za> Message-ID: <1512111255.84.0.213398074469.issue32176@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 02:08:51 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 01 Dec 2017 07:08:51 +0000 Subject: [issue28668] instanciation of multiprocessing.Queue raises ImportError in test_logging In-Reply-To: <1478879280.84.0.810360820826.issue28668@psf.upfronthosting.co.za> Message-ID: <1512112131.58.0.213398074469.issue28668@psf.upfronthosting.co.za> Xavier de Gaye added the comment: New changeset bf2b65e413ca5ec705c7e2f463d0d75e947588a4 by xdegaye in branch 'master': bpo-28668: test.support.requires_multiprocessing_queue is removed (GH-4560) https://github.com/python/cpython/commit/bf2b65e413ca5ec705c7e2f463d0d75e947588a4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 02:09:37 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 01 Dec 2017 07:09:37 +0000 Subject: [issue28668] instanciation of multiprocessing.Queue raises ImportError in test_logging In-Reply-To: <1478879280.84.0.810360820826.issue28668@psf.upfronthosting.co.za> Message-ID: <1512112177.9.0.213398074469.issue28668@psf.upfronthosting.co.za> Change by Xavier de Gaye : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 02:18:25 2017 From: report at bugs.python.org (Kyeongpil) Date: Fri, 01 Dec 2017 07:18:25 +0000 Subject: [issue32191] TypeError does not work when function with type hint Message-ID: <1512112705.37.0.213398074469.issue32191@psf.upfronthosting.co.za> New submission from Kyeongpil : TypeError does not work when I input float variable into function that I give type hint. example code is like this: def a(b: int) -> int: return b+1 a(1.1) and the result is 1.1. However, I think it should throw TypeError Exception because type of input is float, not int. ---------- components: ctypes messages: 307367 nosy: Kang priority: normal severity: normal status: open title: TypeError does not work when function with type hint type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 02:21:00 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Dec 2017 07:21:00 +0000 Subject: [issue32147] improve performance of binascii.unhexlify() by using conversion table In-Reply-To: <1511784869.56.0.213398074469.issue32147@psf.upfronthosting.co.za> Message-ID: <1512112860.96.0.213398074469.issue32147@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I can't reproduce the performance difference. ---------- nosy: +serhiy.storchaka versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 02:36:11 2017 From: report at bugs.python.org (Kyeongpil) Date: Fri, 01 Dec 2017 07:36:11 +0000 Subject: [issue32191] TypeError does not work when function with type hint In-Reply-To: <1512112705.37.0.213398074469.issue32191@psf.upfronthosting.co.za> Message-ID: <1512113771.13.0.213398074469.issue32191@psf.upfronthosting.co.za> Kyeongpil added the comment: Oh, I confused the syntax of type hint. Sorry ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 03:50:41 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 01 Dec 2017 08:50:41 +0000 Subject: [issue32192] Provide importlib.util.lazy_import helper function Message-ID: <1512118241.83.0.213398074469.issue32192@psf.upfronthosting.co.za> New submission from Nick Coghlan : While importlib provides all the *pieces* to implement lazy imports, we don't actually provide a clear way of chaining them together into a lazy import operation. Without any error checking, that looks like: import sys import importlib.util def lazy_import(name): spec = importlib.util.find_spec(name) loader = importlib.util.LazyLoader(spec.loader) spec.loader = loader module = importlib.util.module_from_spec(spec) sys.modules[name] = module loader.exec_module(module) return module >>> lazy_typing = lazy_import("typing") >>> lazy_typing.TYPE_CHECKING False I'm thinking it may make sense to just provide a robust implementation of that, and accept that it may lead to some bug reports that are closed with "You need to fix the module you're loading to be compatible with lazy imports" ---------- messages: 307370 nosy: ncoghlan priority: normal severity: normal status: open title: Provide importlib.util.lazy_import helper function _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 03:51:04 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 01 Dec 2017 08:51:04 +0000 Subject: [issue32192] Provide importlib.util.lazy_import helper function In-Reply-To: <1512118241.83.0.213398074469.issue32192@psf.upfronthosting.co.za> Message-ID: <1512118264.13.0.213398074469.issue32192@psf.upfronthosting.co.za> Change by Nick Coghlan : ---------- nosy: +brett.cannon, eric.snow stage: -> needs patch type: -> enhancement versions: +Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 04:22:50 2017 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 01 Dec 2017 09:22:50 +0000 Subject: [issue32151] -mvenv vs minor python version updates In-Reply-To: <1511804779.33.0.213398074469.issue32151@psf.upfronthosting.co.za> Message-ID: <1512120170.33.0.213398074469.issue32151@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The virtualenv (both using venv and using the third party library virtualenv) still relies on most of the python installation outside of the virtualenv, in particular the stdlib extensions. Those are not guartanteed to be binary compatible between feature releases (3.5 -> 3.6), but should be compatible with bug fix releases (3.6.1 -> 3.6.2). Micro updates should work without breaking virtual environments, the venv doesn't include links to 3th party libraries by default (including openssl and the like). Doing larger upgrades of dependencies in micro updates can still break stuff though, but there's not much that the CPython team can do about that (unless we're doing incompatible updates of dependencies in the python.org installers). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 04:25:34 2017 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 Dec 2017 09:25:34 +0000 Subject: [issue16487] Allow ssl certificates to be specified from memory rather than files. In-Reply-To: <1353078615.85.0.973290481578.issue16487@psf.upfronthosting.co.za> Message-ID: <1512120334.7.0.213398074469.issue16487@psf.upfronthosting.co.za> Christian Heimes added the comment: Correct, PEP 543 won't land in Python 3.7 because neither me nor Cory have the resources to land it. However I want all changes and new additions to the SSL module to follow PEP 543 so I can provide a PEP 543-compatible interface in the near future (3.8 or 3.9). We need a proper certificate class anyway to address other issues and feature requests. I don't want to have three ways to load certificates, especially when it involves more C code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 04:40:50 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 01 Dec 2017 09:40:50 +0000 Subject: [issue16487] Allow ssl certificates to be specified from memory rather than files. In-Reply-To: <1512120334.7.0.213398074469.issue16487@psf.upfronthosting.co.za> Message-ID: <52c269d0-2418-24e5-36d1-90a69a208bcf@free.fr> Antoine Pitrou added the comment: Is it possible to have a single C function that loads the certificates from memory, or would that make the file-loading case less secure? Le 01/12/2017 ? 10:25, Christian Heimes a ?crit?: > > Christian Heimes added the comment: > > Correct, PEP 543 won't land in Python 3.7 because neither me nor Cory have the resources to land it. However I want all changes and new additions to the SSL module to follow PEP 543 so I can provide a PEP 543-compatible interface in the near future (3.8 or 3.9). We need a proper certificate class anyway to address other issues and feature requests. I don't want to have three ways to load certificates, especially when it involves more C code. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 04:43:34 2017 From: report at bugs.python.org (robbuckley) Date: Fri, 01 Dec 2017 09:43:34 +0000 Subject: [issue30581] os.cpu_count() returns wrong number of processors on system with > 64 logical processors In-Reply-To: <1496753379.54.0.823104830335.issue30581@psf.upfronthosting.co.za> Message-ID: <1512121414.31.0.213398074469.issue30581@psf.upfronthosting.co.za> robbuckley added the comment: hi, as the reporter i just want to say this is working for me with 3.6.3. Regarding https://bugs.python.org/issue30581#msg301150, I take your point that a lot of multiprocessing using the standard libraries may not benefit, as processes may be restricted to the processor group of the parent process (python). For my use case it works well: I launch a queue of blocking jobs, using a thread pool. Each thread launches 1 jobsubprocess.subprocess.run(), where the thread pool size is equal to number of processors reported by os.cpu_count(). Since the OS controls the scheduling in this case, it works perfectly well with 2 processor groups. thanks :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 04:44:32 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 01 Dec 2017 09:44:32 +0000 Subject: [issue32193] Convert asyncio to async/await Message-ID: <1512121472.71.0.213398074469.issue32193@psf.upfronthosting.co.za> New submission from Andrew Svetlov : As discussed several times before we need to convert `@coroutine` / `yield from` to async/await. All existing functionality should keep working (like yielding from new style coroutine and `with (yield from lock)`. We could deprecate the later though. The change should be huge but there is no alternative, keeping `yield from` in stdlib looks uglier and uglier every year. Unittests should be changed as well (keeping several `yield from` for checking backward compatibility is Ok). Opinions? ---------- assignee: asvetlov components: Library (Lib), asyncio messages: 307375 nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Convert asyncio to async/await versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 04:44:48 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 01 Dec 2017 09:44:48 +0000 Subject: [issue32193] Convert asyncio to async/await In-Reply-To: <1512121472.71.0.213398074469.issue32193@psf.upfronthosting.co.za> Message-ID: <1512121488.46.0.213398074469.issue32193@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- nosy: +gvanrossum, vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 04:45:09 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 01 Dec 2017 09:45:09 +0000 Subject: [issue32193] Convert asyncio to async/await In-Reply-To: <1512121472.71.0.213398074469.issue32193@psf.upfronthosting.co.za> Message-ID: <1512121509.87.0.213398074469.issue32193@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 04:45:38 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 01 Dec 2017 09:45:38 +0000 Subject: [issue30581] os.cpu_count() returns wrong number of processors on system with > 64 logical processors In-Reply-To: <1496753379.54.0.823104830335.issue30581@psf.upfronthosting.co.za> Message-ID: <1512121538.01.0.213398074469.issue30581@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the heads up Rob! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 04:47:19 2017 From: report at bugs.python.org (Christian Heimes) Date: Fri, 01 Dec 2017 09:47:19 +0000 Subject: [issue16487] Allow ssl certificates to be specified from memory rather than files. In-Reply-To: <1353078615.85.0.973290481578.issue16487@psf.upfronthosting.co.za> Message-ID: <1512121639.4.0.213398074469.issue16487@psf.upfronthosting.co.za> Christian Heimes added the comment: It doesn't matter for certificates. I guess you also want to load the key from a memory buffer, don't you? That's going to be less secure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 05:06:23 2017 From: report at bugs.python.org (Sergey Fedoseev) Date: Fri, 01 Dec 2017 10:06:23 +0000 Subject: [issue32147] improve performance of binascii.unhexlify() by using conversion table In-Reply-To: <1511784869.56.0.213398074469.issue32147@psf.upfronthosting.co.za> Message-ID: <1512122783.41.0.213398074469.issue32147@psf.upfronthosting.co.za> Sergey Fedoseev added the comment: Serhiy, did you use the same benchmark as mentioned here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 05:13:02 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Dec 2017 10:13:02 +0000 Subject: [issue32147] improve performance of binascii.unhexlify() by using conversion table In-Reply-To: <1511784869.56.0.213398074469.issue32147@psf.upfronthosting.co.za> Message-ID: <1512123182.76.0.213398074469.issue32147@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes. And I can't reproduce a slowdown with a simplified a2b_qp(). Maybe this depends on the compiler and on the CPU. What are your OS, compiler and CPU? Do you build 32- or 64-bit Python? Do you build in a debug or release mode? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 05:33:12 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 01 Dec 2017 10:33:12 +0000 Subject: [issue16487] Allow ssl certificates to be specified from memory rather than files. In-Reply-To: <1512121639.4.0.213398074469.issue16487@psf.upfronthosting.co.za> Message-ID: <2cef75cd-c4c6-8429-2f2f-53a34b4bfcaa@free.fr> Antoine Pitrou added the comment: Le 01/12/2017 ? 10:47, Christian Heimes a ?crit?: > > It doesn't matter for certificates. I guess you also want to load the key from a memory buffer, don't you? That's going to be less secure. Yes, that's what I meant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 05:37:12 2017 From: report at bugs.python.org (Sergey Fedoseev) Date: Fri, 01 Dec 2017 10:37:12 +0000 Subject: [issue32147] improve performance of binascii.unhexlify() by using conversion table In-Reply-To: <1511784869.56.0.213398074469.issue32147@psf.upfronthosting.co.za> Message-ID: <1512124632.62.0.213398074469.issue32147@psf.upfronthosting.co.za> Sergey Fedoseev added the comment: > OS x86_64 GNU/Linux > compiler gcc version 7.2.0 (Debian 7.2.0-16) > CPU Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 2 Core(s) per socket: 2 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 58 Model name: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz Stepping: 9 CPU MHz: 2494.521 CPU max MHz: 3100,0000 CPU min MHz: 1200,0000 BogoMIPS: 4989.04 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 3072K NUMA node0 CPU(s): 0-3 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx f16c rdrand lahf_lm cpuid_fault epb tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts > Do you build 32- or 64-bit Python? I'm not sure about that, I guess 64 is default on 64 OS? > Do you build in a debug or release mode? I tried with --enable-optimizations, --with-pydebug and without any flags. Numbers are different, but magnitude of a change is the same. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 06:05:58 2017 From: report at bugs.python.org (=?utf-8?q?Joona_M=C3=B6rsky?=) Date: Fri, 01 Dec 2017 11:05:58 +0000 Subject: [issue32194] When creating list of dictionaries and updating datetime objects one by one, all values are set to last one of the list. Message-ID: <1512126358.41.0.213398074469.issue32194@psf.upfronthosting.co.za> New submission from Joona M?rsky : When creating list of dictionaries and updating datetime objects one by one, all values are set to last one of the list. Ubuntu Linux 4.10.0-40-generic #44~16.04.1-Ubuntu SMP Thu Nov 9 15:37:44 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Python 3.5.2 >>>import datetime >>>b = datetime.datetime.utcnow() >>>b = b.replace(hour=0,minute=0,second=0,microsecond=0,tzinfo=datetime.timezone.utc) >>>a = [{}] * 3 >>>for inx in range(3): ... a[inx]['time'] = b + datetime.timedelta(minutes=inx*10) [{'time': datetime.datetime(2017, 12, 1, 0, 20, tzinfo=datetime.timezone.utc)}, {'time': datetime.datetime(2017, 12, 1, 0, 20, tzinfo=datetime.timezone.utc)}, {'time': datetime.datetime(2017, 12, 1, 0, 20, tzinfo=datetime.timezone.utc)}] >>>import datetime >>>b = datetime.datetime.utcnow() >>>b = b.replace(hour=0,minute=0,second=0,microsecond=0,tzinfo=datetime.timezone.utc) >>>a = [ ] >>>for inx in range(3): ... a.append({"time": b + datetime.timedelta(minutes=inx*10)}) [{'time': datetime.datetime(2017, 12, 1, 0, 0, tzinfo=datetime.timezone.utc)}, {'time': datetime.datetime(2017, 12, 1, 0, 10, tzinfo=datetime.timezone.utc)}, {'time': datetime.datetime(2017, 12, 1, 0, 20, tzinfo=datetime.timezone.utc)}] ---------- components: Interpreter Core messages: 307382 nosy: Joona M?rsky priority: normal severity: normal status: open title: When creating list of dictionaries and updating datetime objects one by one, all values are set to last one of the list. type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 06:59:33 2017 From: report at bugs.python.org (Dmitry Kazakov) Date: Fri, 01 Dec 2017 11:59:33 +0000 Subject: [issue32194] When creating list of dictionaries and updating datetime objects one by one, all values are set to last one of the list. In-Reply-To: <1512126358.41.0.213398074469.issue32194@psf.upfronthosting.co.za> Message-ID: <1512129573.59.0.213398074469.issue32194@psf.upfronthosting.co.za> Dmitry Kazakov added the comment: This is not a bug in Python. Refer to this page for the explanation: https://stackoverflow.com/questions/240178/list-of-lists-changes-reflected-across-sublists-unexpectedly Basically, [{}]*3 creates a list with three references to the same dictionary. ---------- nosy: +vaultah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 07:04:37 2017 From: report at bugs.python.org (Gareth Rees) Date: Fri, 01 Dec 2017 12:04:37 +0000 Subject: [issue32194] When creating list of dictionaries and updating datetime objects one by one, all values are set to last one of the list. In-Reply-To: <1512126358.41.0.213398074469.issue32194@psf.upfronthosting.co.za> Message-ID: <1512129877.94.0.213398074469.issue32194@psf.upfronthosting.co.za> Gareth Rees added the comment: The behaviour of the * operator (and the associated gotcha) is documented under "Common sequence operations" [1]: Note that items in the sequence s are not copied; they are referenced multiple times. This often haunts new Python programmers ... There is also an entry in the FAQ [2]: replicating a list with * doesn?t create copies, it only creates references to the existing objects [1] https://docs.python.org/3/library/stdtypes.html#sequence-types-list-tuple-range [2] https://docs.python.org/3/faq/programming.html#faq-multidimensional-list ---------- nosy: +gdr at garethrees.org resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 07:13:25 2017 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 01 Dec 2017 12:13:25 +0000 Subject: [issue32191] TypeError does not work when function with type hint In-Reply-To: <1512112705.37.0.213398074469.issue32191@psf.upfronthosting.co.za> Message-ID: <1512130405.7.0.213398074469.issue32191@psf.upfronthosting.co.za> Change by Eric V. Smith : ---------- resolution: fixed -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 07:45:07 2017 From: report at bugs.python.org (Henk-Jaap Wagenaar) Date: Fri, 01 Dec 2017 12:45:07 +0000 Subject: [issue32188] ImpImporter.find_modules removes symlinks in paths In-Reply-To: <1512087050.24.0.213398074469.issue32188@psf.upfronthosting.co.za> Message-ID: <1512132307.76.0.213398074469.issue32188@psf.upfronthosting.co.za> Henk-Jaap Wagenaar added the comment: Ignoring testing code, there is minimal use of os.path.realpath in the stdlib (https://github.com/python/cpython/search?utf8=%E2%9C%93&q=%22os.path.realpath%22&type=): - Lib/platform.py: used before opening a file (works around a cygwin bug) - Lib/unittest/loader.py: used to compare two paths for equality - Lib/pkgutil.py: as outlined in this issue - Lib/pydoc.py: used to determine the directory - Lib/inspect.py: path and realpath added to caching dictionary So the question that remains is whether __import__ does this on the hood? I get not due to the difference noted in the OP betweein importing and using pkgutil. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 07:52:27 2017 From: report at bugs.python.org (Silla Rizzoli) Date: Fri, 01 Dec 2017 12:52:27 +0000 Subject: [issue32182] Infinite recursion in email.message.as_string() In-Reply-To: <1512058767.09.0.213398074469.issue32182@psf.upfronthosting.co.za> Message-ID: Silla Rizzoli added the comment: Ok, thanks! I'm writing a program to convert Outlook for Mac backup files (.olm) into plain mbox files as a way to teach myself Python (and at the same time regain control of my email), so I have tens of thousand of emails to test your new code on, if you feel you need some fedback before releasing it. Best regards, Silla On Thu, Nov 30, 2017 at 5:19 PM, R. David Murray wrote: > > R. David Murray added the comment: > > This is almost certainly either a duplicate or will be fixed by a PR I > have pending, that I don't have time to look for right now, that rewrites > the folder. I'll try to get to merging that PR soonish, but it might not > happen before the holidays ;) > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 08:45:45 2017 From: report at bugs.python.org (Tzu-ping Chung) Date: Fri, 01 Dec 2017 13:45:45 +0000 Subject: [issue32151] -mvenv vs minor python version updates In-Reply-To: <1511804779.33.0.213398074469.issue32151@psf.upfronthosting.co.za> Message-ID: <1512135945.52.0.213398074469.issue32151@psf.upfronthosting.co.za> Tzu-ping Chung added the comment: Hmm, I?m quite sure I have experience that a virtual environment breaks after a micro version upgrade on macOS, getting an ?image not found? or something similar. I?m not using the official released Python, but via Homebrew, so maybe this does not happen with the official distribution? I vaguely remember getting into a similar problem on Windows as well though? I don?t have a handy environment set up for reproduction right now. I will try to report any problem if I run into this again in the future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 09:21:59 2017 From: report at bugs.python.org (Nikhil Hegde) Date: Fri, 01 Dec 2017 14:21:59 +0000 Subject: [issue32152] Add pid to .cover filename in lib/trace.py In-Reply-To: <1511858704.48.0.213398074469.issue32152@psf.upfronthosting.co.za> Message-ID: <1512138119.67.0.213398074469.issue32152@psf.upfronthosting.co.za> Nikhil Hegde added the comment: This is also necessary in a case where two tests (say, a and b) are running in parallel. Both tests access the same fileX.py The coverage for fileX.py will not be accurate to reflect the usage by tests a and b ---------- versions: +Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 09:39:29 2017 From: report at bugs.python.org (Dave Challis) Date: Fri, 01 Dec 2017 14:39:29 +0000 Subject: [issue32195] datetime.strftime with %Y no longer outputs leading zeros Message-ID: <1512139169.39.0.213398074469.issue32195@psf.upfronthosting.co.za> New submission from Dave Challis : Tested in python 3.6.2: >>> import datetime >>> datetime.datetime.min.strftime('%Y') '1' Expected output: '0001' This means that strftime and strptime aren't necessarily symmetric, e.g.: >>> datetime.datetime.strptime(datetime.datetime.min.strftime('%Y'), '%Y') ValueError: time data '1' does not match format '%Y' ---------- components: Library (Lib) messages: 307389 nosy: davechallis priority: normal severity: normal status: open title: datetime.strftime with %Y no longer outputs leading zeros type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 09:44:44 2017 From: report at bugs.python.org (Ric Anderson) Date: Fri, 01 Dec 2017 14:44:44 +0000 Subject: [issue32151] -mvenv vs minor python version updates In-Reply-To: <1511804779.33.0.213398074469.issue32151@psf.upfronthosting.co.za> Message-ID: <1512139484.7.0.213398074469.issue32151@psf.upfronthosting.co.za> Ric Anderson added the comment: well then, I guess y'all can close this ticket ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 10:07:16 2017 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 01 Dec 2017 15:07:16 +0000 Subject: [issue32151] -mvenv vs minor python version updates In-Reply-To: <1511804779.33.0.213398074469.issue32151@psf.upfronthosting.co.za> Message-ID: <1512140836.46.0.213398074469.issue32151@psf.upfronthosting.co.za> Change by Ronald Oussoren : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 10:28:44 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 01 Dec 2017 15:28:44 +0000 Subject: [issue32192] Provide importlib.util.lazy_import helper function In-Reply-To: <1512118241.83.0.213398074469.issue32192@psf.upfronthosting.co.za> Message-ID: <1512142124.27.0.213398074469.issue32192@psf.upfronthosting.co.za> Change by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 11:25:33 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Dec 2017 16:25:33 +0000 Subject: [issue32182] Infinite recursion in email.message.as_string() In-Reply-To: Message-ID: <20171201162530.46DC01310019@webabinitio.net> R. David Murray added the comment: It is gh-3488 if you want to try it out. Feedback welcome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 11:38:31 2017 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 01 Dec 2017 16:38:31 +0000 Subject: [issue32193] Convert asyncio to async/await In-Reply-To: <1512121472.71.0.213398074469.issue32193@psf.upfronthosting.co.za> Message-ID: <1512146311.05.0.213398074469.issue32193@psf.upfronthosting.co.za> Guido van Rossum added the comment: Yeah, I am in favor of this. How will we guarantee that clients using the old `@coroutine`/`yield from` idiom still work? We need to have separate tests for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 11:48:57 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 01 Dec 2017 16:48:57 +0000 Subject: [issue32193] Convert asyncio to async/await In-Reply-To: <1512121472.71.0.213398074469.issue32193@psf.upfronthosting.co.za> Message-ID: <1512146937.79.0.213398074469.issue32193@psf.upfronthosting.co.za> Yury Selivanov added the comment: > How will we guarantee that clients using the old `@coroutine`/`yield from` idiom still work? They are fully supported now, but we can add a few tests to ensure we won't break it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 11:50:47 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 01 Dec 2017 16:50:47 +0000 Subject: [issue32193] Convert asyncio to async/await In-Reply-To: <1512121472.71.0.213398074469.issue32193@psf.upfronthosting.co.za> Message-ID: <1512147047.96.0.213398074469.issue32193@psf.upfronthosting.co.za> Yury Selivanov added the comment: Andrew, would it be OK if I make a PR? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 12:01:52 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Dec 2017 17:01:52 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512147712.57.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4573 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 12:27:11 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Dec 2017 17:27:11 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512149231.73.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset b64de46aae148cfab0980e0ad478da7aafc44900 by Victor Stinner in branch 'master': bpo-32030: Cleanup "path config" code (#4663) https://github.com/python/cpython/commit/b64de46aae148cfab0980e0ad478da7aafc44900 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 12:32:29 2017 From: report at bugs.python.org (Brett Cannon) Date: Fri, 01 Dec 2017 17:32:29 +0000 Subject: [issue32192] Provide importlib.util.lazy_import helper function In-Reply-To: <1512118241.83.0.213398074469.issue32192@psf.upfronthosting.co.za> Message-ID: <1512149549.18.0.213398074469.issue32192@psf.upfronthosting.co.za> Brett Cannon added the comment: Already planning this as a PyPI package (at least to start). See https://notebooks.azure.com/Brett/libraries/di2Btqj7zSI/html/Lazy%20importing.ipynb for the design. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 12:33:16 2017 From: report at bugs.python.org (Pierre Denis) Date: Fri, 01 Dec 2017 17:33:16 +0000 Subject: [issue32171] Inconsistent results for fractional power of -infinity In-Reply-To: <1511990992.11.0.213398074469.issue32171@psf.upfronthosting.co.za> Message-ID: <1512149596.97.0.213398074469.issue32171@psf.upfronthosting.co.za> Pierre Denis added the comment: > So this justifies things like `sqrt(-0.0)` giving a zero result (rather than being considered invalid) Well, I didn?t noticed that the wolf was already in the henhouse! This choice seems disputable for me because it is precisely a case where f(-0.0) should NOT behave as f(+0.0). The treatment of functions like atan2 and 1/x lets me think that the standards tend to follow the results of one-sided limits. So, I?m surprised that pow and sqrt functions in IEEE754/C99 standards are treated in this unfettered way. That being said, I?m not involved at all in IEEE/C99 standards; that?s probably why I look at this from a pristine point of view. Provided that I accept the "axioms" of these standards, the explanations you both give are very convincing. I understand well that self-consistency is utmost important, maybe even above consistency with mathematical rules. Also, I concede that the standards are well-established and considerable efforts have been made to validate their different implementations (including Python). BTW, congratulations to you guys that made the effort to understand the standards and rigorously implementing them in Python! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 12:46:33 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Dec 2017 17:46:33 +0000 Subject: [issue32195] datetime.strftime with %Y no longer outputs leading zeros In-Reply-To: <1512139169.39.0.213398074469.issue32195@psf.upfronthosting.co.za> Message-ID: <1512150393.69.0.213398074469.issue32195@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In what version datetime.strftime with %Y did output leading zeros? ---------- nosy: +belopolsky, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 12:54:59 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Dec 2017 17:54:59 +0000 Subject: [issue32193] Convert asyncio to async/await In-Reply-To: <1512121472.71.0.213398074469.issue32193@psf.upfronthosting.co.za> Message-ID: <1512150899.75.0.213398074469.issue32193@psf.upfronthosting.co.za> Change by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 12:59:39 2017 From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=) Date: Fri, 01 Dec 2017 17:59:39 +0000 Subject: [issue30657] [security] CVE-2017-1000158: Unsafe arithmetic in PyString_DecodeEscape In-Reply-To: <1497368129.36.0.20181989843.issue30657@psf.upfronthosting.co.za> Message-ID: <1512151179.27.0.213398074469.issue30657@psf.upfronthosting.co.za> Change by Miro Hron?ok : ---------- keywords: +patch pull_requests: +4574 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 13:07:10 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Dec 2017 18:07:10 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512151630.1.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4575 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 13:30:45 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Dec 2017 18:30:45 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512153045.8.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 9ac3d8882712c9675c3d2f9f84af6b5729575cde by Victor Stinner in branch 'master': bpo-32030: Fix Py_GetPath(): init program_name (#4665) https://github.com/python/cpython/commit/9ac3d8882712c9675c3d2f9f84af6b5729575cde ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 13:49:56 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Dec 2017 18:49:56 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512154196.1.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4576 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 13:54:36 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Dec 2017 18:54:36 +0000 Subject: [issue25054] Capturing start of line '^' In-Reply-To: <1441887596.73.0.766811958538.issue25054@psf.upfronthosting.co.za> Message-ID: <1512154476.57.0.213398074469.issue25054@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could anybody please make review at least of the documentation part? I want to merge this before 3.7.0a3 be released. Initially I was going to backport the part that relates findall(), finditer() and sub(). It changes the behavior only in corner cases and I didn't expect it can break a real code. But since it broke a pattern in the doctest module, I afraid it can break a third-party code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 14:05:42 2017 From: report at bugs.python.org (Dave Challis) Date: Fri, 01 Dec 2017 19:05:42 +0000 Subject: [issue32195] datetime.strftime with %Y no longer outputs leading zeros In-Reply-To: <1512139169.39.0.213398074469.issue32195@psf.upfronthosting.co.za> Message-ID: <1512155142.84.0.213398074469.issue32195@psf.upfronthosting.co.za> Dave Challis added the comment: My mistake, it appears to be related to the OS it's running on rather than the version (I just happened to test with different versions on different OSes). On Mac OS X (with 3.6.2): >>> import datetime >>> datetime.datetime.min.strftime('%Y') '0001' On Linux (with 3.6.2 again): >>> import datetime >>> datetime.datetime.min.strftime('%Y') '1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 14:09:57 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Dec 2017 19:09:57 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512155397.47.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset ebac19dad6263141d5db0a2c923efe049dba99d2 by Victor Stinner in branch 'master': bpo-32030: Don't call _PyPathConfig_Fini() in Py_FinalizeEx() (#4667) https://github.com/python/cpython/commit/ebac19dad6263141d5db0a2c923efe049dba99d2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 14:13:39 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Dec 2017 19:13:39 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512155619.32.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4577 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 14:15:47 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 01 Dec 2017 19:15:47 +0000 Subject: [issue32193] Convert asyncio to async/await In-Reply-To: <1512121472.71.0.213398074469.issue32193@psf.upfronthosting.co.za> Message-ID: <1512155747.76.0.213398074469.issue32193@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Yuri please do ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 14:28:36 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Dec 2017 19:28:36 +0000 Subject: [issue32196] Rewrite plistlib with functional style Message-ID: <1512156516.89.0.213398074469.issue32196@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : The proposed PR rewrites the plistlib module using a functional style. This speeds up loading and saving plist files at least by 10%. Saving plist files in XML format have sped up almost twice. $ ./python -m timeit -s 'import plistlib; a = list(range(100))' -- 'plistlib.dumps(a, fmt=plistlib.FMT_XML)' Unpatched: 1000 loops, best of 5: 228 usec per loop Patched: 1000 loops, best of 5: 204 usec per loop $ ./python -m timeit -s 'import plistlib; a = list(range(100))' -- 'plistlib.dumps(a, fmt=plistlib.FMT_BINARY)' Unpatched: 1000 loops, best of 5: 234 usec per loop Patched: 1000 loops, best of 5: 203 usec per loop $ ./python -m timeit -s 'import plistlib; a = list(range(100)); p = plistlib.dumps(a, fmt=plistlib.FMT_XML)' -- 'plistlib.loads(p)' Unpatched: 1000 loops, best of 5: 308 usec per loop Patched: 2000 loops, best of 5: 155 usec per loop $ ./python -m timeit -s 'import plistlib; a = list(range(100)); p = plistlib.dumps(a, fmt=plistlib.FMT_BINARY)' -- 'plistlib.loads(p)' Unpatched: 2000 loops, best of 5: 116 usec per loop Patched: 5000 loops, best of 5: 94.6 usec per loop $ ./python -m timeit -s 'import plistlib; a = {"a%d" % i: i for i in range(100)}' -- 'plistlib.dumps(a, fmt=plistlib.FMT_XML)' Unpatched: 500 loops, best of 5: 433 usec per loop Patched: 1000 loops, best of 5: 384 usec per loop $ ./python -m timeit -s 'import plistlib; a = {"a%d" % i: i for i in range(100)}' -- 'plistlib.dumps(a, fmt=plistlib.FMT_BINARY)' Unpatched: 500 loops, best of 5: 616 usec per loop Patched: 500 loops, best of 5: 560 usec per loop $ ./python -m timeit -s 'import plistlib; a = {"a%d" % i: i for i in range(100)}; p = plistlib.dumps(a, fmt=plistlib.FMT_XML)' -- 'plistlib.loads(p)' Unpatched: 500 loops, best of 5: 578 usec per loop Patched: 1000 loops, best of 5: 308 usec per loop $ ./python -m timeit -s 'import plistlib; a = {"a%d" % i: i for i in range(100)}; p = plistlib.dumps(a, fmt=plistlib.FMT_BINARY)' -- 'plistlib.loads(p)' Unpatched: 1000 loops, best of 5: 257 usec per loop Patched: 1000 loops, best of 5: 208 usec per loop ---------- components: Library (Lib) messages: 307404 nosy: ronaldoussoren, serhiy.storchaka priority: normal severity: normal status: open title: Rewrite plistlib with functional style type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 14:31:50 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Dec 2017 19:31:50 +0000 Subject: [issue32195] datetime.strftime with %Y no longer outputs leading zeros In-Reply-To: <1512139169.39.0.213398074469.issue32195@psf.upfronthosting.co.za> Message-ID: <1512156710.54.0.213398074469.issue32195@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- nosy: +ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 14:45:56 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 01 Dec 2017 19:45:56 +0000 Subject: [issue32180] bool() vs len() > 0 on lists In-Reply-To: <1512041507.48.0.213398074469.issue32180@psf.upfronthosting.co.za> Message-ID: <1512157556.26.0.213398074469.issue32180@psf.upfronthosting.co.za> Raymond Hettinger added the comment: ISTM that there isn't a real issue here and the discussions of proper timing technique and micro-optimizations are more suitable for StackOverflow. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 14:46:54 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 01 Dec 2017 19:46:54 +0000 Subject: [issue32173] linecache.py add lazycache to __all__ and use dict.clear to clear the cache Message-ID: <1512157614.6.0.213398074469.issue32173@psf.upfronthosting.co.za> New submission from Raymond Hettinger : These seems to be reasonable suggestions. Lisa, would you care to review the patch? ---------- assignee: -> lisroach nosy: +lisroach, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 14:48:59 2017 From: report at bugs.python.org (SilentGhost) Date: Fri, 01 Dec 2017 19:48:59 +0000 Subject: [issue32170] Contrary to documentation, ZipFile.extract does not extract timestamps or other metadata In-Reply-To: <1511985115.6.0.213398074469.issue32170@psf.upfronthosting.co.za> Message-ID: <1512157739.52.0.213398074469.issue32170@psf.upfronthosting.co.za> Change by SilentGhost : ---------- nosy: +alanmcintyre, serhiy.storchaka, twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 14:51:01 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Dec 2017 19:51:01 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512157861.91.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 0ea395ae964c9cd0f499e2ef0d0030c971201220 by Victor Stinner in branch 'master': bpo-32030: Add Python/pathconfig.c (#4668) https://github.com/python/cpython/commit/0ea395ae964c9cd0f499e2ef0d0030c971201220 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 14:55:33 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Dec 2017 19:55:33 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512158133.07.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4578 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 15:00:08 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Dec 2017 20:00:08 +0000 Subject: [issue32180] bool() vs len() > 0 on lists In-Reply-To: <1512041507.48.0.213398074469.issue32180@psf.upfronthosting.co.za> Message-ID: <1512158408.89.0.213398074469.issue32180@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm sure adding list.__bool__() will not affect the performance. The real source of the difference is explained on the StackOverflow link. PEP 8 contains a rule for testing the emptiness of a container. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 15:04:51 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Dec 2017 20:04:51 +0000 Subject: [issue32173] linecache.py add lazycache to __all__ and use dict.clear to clear the cache In-Reply-To: <1512157614.6.0.213398074469.issue32173@psf.upfronthosting.co.za> Message-ID: <1512158691.66.0.213398074469.issue32173@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please explain your suggestion ganziqim? The patch looks like a collection of unrelated changes mostly changing the formatting of the code. Usually we don't do such changes. If there is a semantical change, it is hidden in a source churn. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 15:19:51 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 01 Dec 2017 20:19:51 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512159591.13.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset e23c06e2b03452c9aaf0dae52296c85e572f9bcd by Victor Stinner in branch 'master': bpo-32030: Fix config_get_program_name() on macOS (#4669) https://github.com/python/cpython/commit/e23c06e2b03452c9aaf0dae52296c85e572f9bcd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 15:52:39 2017 From: report at bugs.python.org (Brett Cannon) Date: Fri, 01 Dec 2017 20:52:39 +0000 Subject: [issue32188] ImpImporter.find_modules removes symlinks in paths In-Reply-To: <1512087050.24.0.213398074469.issue32188@psf.upfronthosting.co.za> Message-ID: <1512161559.46.0.213398074469.issue32188@psf.upfronthosting.co.za> Brett Cannon added the comment: Import itself I don't believe calls os.path.realpath(), so this is probably just something pkgutil happens to do. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 15:56:44 2017 From: report at bugs.python.org (Brett Cannon) Date: Fri, 01 Dec 2017 20:56:44 +0000 Subject: [issue32177] spammers mine emails from bugs.python.org In-Reply-To: <1512028817.25.0.213398074469.issue32177@psf.upfronthosting.co.za> Message-ID: <1512161804.86.0.213398074469.issue32177@psf.upfronthosting.co.za> Brett Cannon added the comment: We don't sell any information to anyone. If you would like to file a bug to have email addresses obfuscated more then the correct place to file that is http://psf.upfronthosting.co.za/roundup/meta . Obviously any help in updating the code would be appreciated as the issue tracker predates e.g. bitcoin and this is entirely volunteer-run. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 16:18:51 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Dec 2017 21:18:51 +0000 Subject: [issue32196] Rewrite plistlib with functional style In-Reply-To: <1512156516.89.0.213398074469.issue32196@psf.upfronthosting.co.za> Message-ID: <1512163131.66.0.213398074469.issue32196@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +4579 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 17:23:06 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Fri, 01 Dec 2017 22:23:06 +0000 Subject: [issue32162] typing.Generic breaks __init_subclass__ In-Reply-To: <1511908063.67.0.213398074469.issue32162@psf.upfronthosting.co.za> Message-ID: <1512166986.54.0.213398074469.issue32162@psf.upfronthosting.co.za> Change by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 17:40:26 2017 From: report at bugs.python.org (Ned Deily) Date: Fri, 01 Dec 2017 22:40:26 +0000 Subject: [issue32195] datetime.strftime with %Y no longer outputs leading zeros In-Reply-To: <1512139169.39.0.213398074469.issue32195@psf.upfronthosting.co.za> Message-ID: <1512168026.67.0.213398074469.issue32195@psf.upfronthosting.co.za> Ned Deily added the comment: As documented in the Python Library Reference: "The full set of format codes supported varies across platforms, because Python calls the platform C library?s strftime() function, and platform variations are common. To see the full set of format codes supported on your platform, consult the strftime(3) documentation." And this appears to be one of those differences, presumably another GNU libc vs BSD one, as I see the same behavior as macOS on the FreeBSD system I have available. The Open Group 2008 documentation for the strftime C interface discusses this problem a bit here (http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html): "The %Y conversion specification to strftime() was frequently assumed to be a four-digit year, but the ISO C standard does not specify that %Y is restricted to any subset of allowed values from the tm_year field. Similarly, the %C conversion specification was assumed to be a two-digit field and the first part of the output from the %F conversion specification was assumed to be a four-digit field. With tm_year being a signed 32 or more-bit int and with many current implementations supporting 64-bit time_t types in one or more programming environments, these assumptions are clearly wrong. POSIX.1-2008 now allows the format specifications %0xC, %0xF, %0xG, and %0xY (where 'x' is a string of decimal digits used to specify printing and scanning of a string of x decimal digits) with leading zero fill characters. Allowing applications to set the field width enables them to agree on the number of digits to be printed and scanned in the ISO 8601:2000 standard expanded representation of a year (for %F, %G, and %Y ) or all but the last two digits of the year (for %C ). This is based on a feature in some versions of GNU libc's strftime(). The GNU version allows specifying space, zero, or no-fill characters in strftime() format strings, but does not allow any flags to be specified in strptime() format strings. These implementations also allow these flags to be specified for any numeric field. POSIX.1-2008 only requires the zero fill flag ( '0' ) and only requires that it be recognized when processing %C, %F, %G, and %Y specifications when a minimum field width is also specified. The '0' flag is the only flag needed to produce and scan the ISO 8601:2000 standard year fields using the extended format forms. POSIX.1-2008 also allows applications to specify the same flag and field width specifiers to be used in both strftime() and strptime() format strings for symmetry. Systems may provide other flag characters and may accept flags in conjunction with conversion specifiers other than %C, %F, %G, and %Y; but portable applications cannot depend on such extensions." Experimenting a bit, it seems that the current Linux glibc implementation supports the %0xY extension while the current macOS (and other BSD?) do not. Python 3.6.3 (default, Oct 3 2017, 21:16:13) [GCC 7.2.0] on linux >>> datetime.datetime.min.strftime('%Y') '1' >>> datetime.datetime.min.strftime('%02Y') '01' >>> datetime.datetime.min.strftime('%04Y') '0001' Python 3.6.3 (v3.6.3:2c5fed86e0, Oct 3 2017, 00:32:08) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin >>> datetime.datetime.min.strftime('%Y') '0001' >>> datetime.datetime.min.strftime('%02Y') '2Y' >>> datetime.datetime.min.strftime('%04Y') '4Y' So I'm afraid there's not much we can do about that without changing Python's policy about using the platform's native implementations of date and time functions. Alexander, do you agree? ---------- resolution: -> not a bug status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 17:45:59 2017 From: report at bugs.python.org (Dan Snider) Date: Fri, 01 Dec 2017 22:45:59 +0000 Subject: [issue32176] Zero argument super is broken in 3.6 for methods with a hacked __class__ cell In-Reply-To: <1512027575.04.0.213398074469.issue32176@psf.upfronthosting.co.za> Message-ID: <1512168359.46.0.213398074469.issue32176@psf.upfronthosting.co.za> Dan Snider added the comment: So while CO_NOFREE is set in all versions with the example code, it appears only python 3.6 recognizes that flag and disallows the accessing of the __class__ cell. In this case the error message is bad because it implies that the __class__ cell is the wrong type. Disabling the flag when creating the code objects allows the above code to work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 17:56:43 2017 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 01 Dec 2017 22:56:43 +0000 Subject: [issue32195] datetime.strftime with %Y no longer outputs leading zeros In-Reply-To: <1512139169.39.0.213398074469.issue32195@psf.upfronthosting.co.za> Message-ID: <1512169003.1.0.213398074469.issue32195@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Isn't this a duplicate of issue 13305? ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 18:01:16 2017 From: report at bugs.python.org (Ned Deily) Date: Fri, 01 Dec 2017 23:01:16 +0000 Subject: [issue32195] datetime.strftime with %Y no longer outputs leading zeros In-Reply-To: <1512139169.39.0.213398074469.issue32195@psf.upfronthosting.co.za> Message-ID: <1512169276.42.0.213398074469.issue32195@psf.upfronthosting.co.za> Ned Deily added the comment: > Isn't this a duplicate of issue 13305? Looks like it, thanks, though I think the analysis still applies. Closing as duplicate. ---------- resolution: not a bug -> duplicate stage: -> resolved status: open -> closed superseder: -> datetime.strftime("%Y") not consistent for years < 1000 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 18:02:32 2017 From: report at bugs.python.org (Ned Deily) Date: Fri, 01 Dec 2017 23:02:32 +0000 Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000 In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za> Message-ID: <1512169352.94.0.213398074469.issue13305@psf.upfronthosting.co.za> Ned Deily added the comment: (See also msg307413 in duplicate Issue32195 for more discussion.) ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 18:18:47 2017 From: report at bugs.python.org (Henk-Jaap Wagenaar) Date: Fri, 01 Dec 2017 23:18:47 +0000 Subject: [issue32188] ImpImporter.find_modules removes symlinks in paths In-Reply-To: <1512087050.24.0.213398074469.issue32188@psf.upfronthosting.co.za> Message-ID: <1512170327.21.0.213398074469.issue32188@psf.upfronthosting.co.za> Change by Henk-Jaap Wagenaar : ---------- keywords: +patch pull_requests: +4580 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 19:56:07 2017 From: report at bugs.python.org (Martin Panter) Date: Sat, 02 Dec 2017 00:56:07 +0000 Subject: [issue32085] [Security] A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages! In-Reply-To: <1511187317.56.0.213398074469.issue32085@psf.upfronthosting.co.za> Message-ID: <1512176167.82.0.213398074469.issue32085@psf.upfronthosting.co.za> Martin Panter added the comment: Issue 32185 proposes to stop sending IP addresses in the TLS SNI protocol. Maybe this will help; it depends if it will catch IP address strings with with whitespace or if there are other ways to inject invalid hostnames. ---------- dependencies: +SSLContext.wrap_socket sends SNI Extension when server_hostname is IP _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 20:39:37 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 02 Dec 2017 01:39:37 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512178777.16.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4581 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 21:45:54 2017 From: report at bugs.python.org (Lisa Roach) Date: Sat, 02 Dec 2017 02:45:54 +0000 Subject: [issue32173] linecache.py add lazycache to __all__ and use dict.clear to clear the cache In-Reply-To: <1512157614.6.0.213398074469.issue32173@psf.upfronthosting.co.za> Message-ID: <1512182754.82.0.213398074469.issue32173@psf.upfronthosting.co.za> Lisa Roach added the comment: I think these changes look good, ganziqim has real code improvements (in the form of adding lazycache to __all__ and using clear() in clearchache), as well as improving the code formatting for readability. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 1 23:16:57 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 02 Dec 2017 04:16:57 +0000 Subject: [issue32176] Zero argument super is broken in 3.6 for methods with a hacked __class__ cell In-Reply-To: <1512027575.04.0.213398074469.issue32176@psf.upfronthosting.co.za> Message-ID: <1512188217.18.0.213398074469.issue32176@psf.upfronthosting.co.za> Nick Coghlan added the comment: Given that, I'd say the way to cleanest way to fix this would be to remove these lines from "compute_code_flags" in compile.c: if (!PyDict_GET_SIZE(c->u->u_freevars) && !PyDict_GET_SIZE(c->u->u_cellvars)) { flags |= CO_NOFREE; } and replace them with a check like the following in PyCode_New just after we ensure the Unicode string for the filename is ready: if (!PyTuple_GET_SIZE(freevars) && !PyTuple_GET_SIZE(cellvars)) { flags |= CO_NOFREE; } That way CO_NOFREE will be set only when appropriate regardless of how the code object is created, rather than relying on the caller to set it correctly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 00:01:37 2017 From: report at bugs.python.org (Martin Panter) Date: Sat, 02 Dec 2017 05:01:37 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1512190897.01.0.213398074469.issue26439@psf.upfronthosting.co.za> Martin Panter added the comment: Michael Felt: if you still want the code compatible with Python 2 and 3 (and others are happy with that), I suggest documenting that in a code comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 03:22:53 2017 From: report at bugs.python.org (Allen Li) Date: Sat, 02 Dec 2017 08:22:53 +0000 Subject: [issue9924] sqlite3 SELECT does not BEGIN a transaction, but should according to spec In-Reply-To: <1285214166.49.0.269440190097.issue9924@psf.upfronthosting.co.za> Message-ID: <1512202973.77.0.213398074469.issue9924@psf.upfronthosting.co.za> Change by Allen Li : ---------- nosy: +Allen Li _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 04:11:39 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 02 Dec 2017 09:11:39 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512205899.16.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset af5a895073c24637c094772b27526b94a12ec897 by Victor Stinner in branch 'master': bpo-32030: _PyPathConfig_Init() sets home and program_name (#4673) https://github.com/python/cpython/commit/af5a895073c24637c094772b27526b94a12ec897 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 05:21:38 2017 From: report at bugs.python.org (patrila) Date: Sat, 02 Dec 2017 10:21:38 +0000 Subject: [issue29151] test_asyncore.TestAPI_UseIPv4Select / test_asyncore.TestAPI_UseIPv6Select fails test_handle_close_after_conn_broken In-Reply-To: <1483532525.73.0.454850752566.issue29151@psf.upfronthosting.co.za> Message-ID: <1512210098.97.0.213398074469.issue29151@psf.upfronthosting.co.za> patrila added the comment: Adding a 'time.sleep(0.01)' before the 'send()' statement in test.test_asyncore.BaseTestAPI.test_handle_close_after_conn_broken.TestClient.handle_write works around this problem. Unsure if this a fix or just a workaround. Patch attached. ---------- keywords: +patch Added file: https://bugs.python.org/file47311/python-3.6.3-Fix_test_asyncore_test_handle_close_after_conn_broken.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 05:50:48 2017 From: report at bugs.python.org (Martin Panter) Date: Sat, 02 Dec 2017 10:50:48 +0000 Subject: [issue25054] Capturing start of line '^' In-Reply-To: <1441887596.73.0.766811958538.issue25054@psf.upfronthosting.co.za> Message-ID: <1512211848.04.0.213398074469.issue25054@psf.upfronthosting.co.za> Martin Panter added the comment: The new ?finditer? behaviour seems to contradict the documentation about excluding empty matches if they touch the start of another match. >>> list(re.finditer(r"\b|:+", "a::bc")) [, , , , ] An empty match at (1, 1) is included, despite it touching the beginning of the match at (1, 3). My best guess is that when an empty match is found, searching continues at the same position for the first non-empty match. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 06:08:32 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 02 Dec 2017 11:08:32 +0000 Subject: [issue32107] Improve MAC address calculation and fix test_uuid.py In-Reply-To: <1511284223.14.0.213398074469.issue32107@psf.upfronthosting.co.za> Message-ID: <1512212912.31.0.213398074469.issue32107@psf.upfronthosting.co.za> Xavier de Gaye added the comment: test_uuid fails now on android-24-armv7 on the master branch: ====================================================================== FAIL: test_getnode (test.test_uuid.TestUUIDWithoutExtModule) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sdcard/org.python/lib/python3.7/test/test_uuid.py", line 312, in test_getnode self.assertEqual(node1, node2, '%012x != %012x' % (node1, node2)) AssertionError: 237015144408656 != 105397654869517 : d790637d2650 != 5fdbcdc7560d Some context: * There is no _uuid extension module. * All the getters in uuid.getnode() fail: _ip_getnode() fails because the 'ip link list' command fails on Android while 'ip link' would have succeeded (and would have hidden the above bug), 'ifconfig' does not print MAC addresses and the commands of the other getters do not exist. The following patch fixes the problem: diff --git a/Lib/uuid.py b/Lib/uuid.py index cb2bc092bd..be06a6eff3 100644 --- a/Lib/uuid.py +++ b/Lib/uuid.py @@ -674,14 +674,14 @@ def getnode(): getters = [_unix_getnode, _ifconfig_getnode, _ip_getnode, _arp_getnode, _lanscan_getnode, _netstat_getnode] - for getter in getters: + for getter in getters + [_random_getnode]: try: _node = getter() except: continue if _node is not None: return _node - return _random_getnode() + assert False, '_random_getnode() returned None' ---------- nosy: +xdegaye resolution: fixed -> stage: resolved -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 06:38:07 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sat, 02 Dec 2017 11:38:07 +0000 Subject: [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1512214687.58.0.213398074469.issue25910@psf.upfronthosting.co.za> Change by Sanyam Khurana : ---------- pull_requests: +4582 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 06:40:05 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 02 Dec 2017 11:40:05 +0000 Subject: [issue32176] Zero argument super is broken in 3.6 for methods with a hacked __class__ cell In-Reply-To: <1512027575.04.0.213398074469.issue32176@psf.upfronthosting.co.za> Message-ID: <1512214805.74.0.213398074469.issue32176@psf.upfronthosting.co.za> Change by Nick Coghlan : ---------- keywords: +patch pull_requests: +4583 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 06:58:08 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 11:58:08 +0000 Subject: [issue10544] yield expression inside generator expression does nothing In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za> Message-ID: <1512215888.36.0.213398074469.issue10544@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4584 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 07:14:01 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 12:14:01 +0000 Subject: [issue10544] yield expression inside generator expression does nothing In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za> Message-ID: <1512216841.85.0.213398074469.issue10544@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PR 4676 backports warnings to 2.7 in Py3k mode. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 07:47:18 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 12:47:18 +0000 Subject: [issue32107] Improve MAC address calculation and fix test_uuid.py In-Reply-To: <1511284223.14.0.213398074469.issue32107@psf.upfronthosting.co.za> Message-ID: <1512218838.28.0.213398074469.issue32107@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4585 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 07:50:00 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sat, 02 Dec 2017 12:50:00 +0000 Subject: [issue32197] Compiling against master branch fails; error: expected expression SET_DECODE_ERROR Message-ID: <1512219000.84.0.213398074469.issue32197@psf.upfronthosting.co.za> New submission from Sanyam Khurana : The current master branch at commit af5a895073c24637c094772b27526b94a12ec897 fails while building the interpreter. The following is the traceback while running `make` after `./configure --with-pydebug` gcc -c -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -I. -I./Include -DPy_BUILD_CORE -o Modules/main.o Modules/main.c Modules/main.c:904:20: error: expected expression return SET_DECODE_ERROR("PYTHONEXECUTABLE environment " ^ Modules/main.c:46:5: note: expanded from macro 'SET_DECODE_ERROR' do { \ ^ 1 error generated. make: *** [Modules/main.o] Error 1 ---------- messages: 307427 nosy: CuriousLearner priority: normal severity: normal status: open title: Compiling against master branch fails; error: expected expression SET_DECODE_ERROR type: crash versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 07:50:08 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 12:50:08 +0000 Subject: [issue32107] Improve MAC address calculation and fix test_uuid.py In-Reply-To: <1511284223.14.0.213398074469.issue32107@psf.upfronthosting.co.za> Message-ID: <1512219008.18.0.213398074469.issue32107@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't know how the proposed change can help. PR 4677 makes the test more lenient. ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 07:55:30 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 12:55:30 +0000 Subject: [issue32197] Compiling against master branch fails; error: expected expression SET_DECODE_ERROR In-Reply-To: <1512219000.84.0.213398074469.issue32197@psf.upfronthosting.co.za> Message-ID: <1512219330.31.0.213398074469.issue32197@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- nosy: +vstinner type: crash -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 08:14:17 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sat, 02 Dec 2017 13:14:17 +0000 Subject: [issue32197] Compiling against master branch fails; error: expected expression SET_DECODE_ERROR In-Reply-To: <1512219000.84.0.213398074469.issue32197@psf.upfronthosting.co.za> Message-ID: <1512220457.17.0.213398074469.issue32197@psf.upfronthosting.co.za> Sanyam Khurana added the comment: I used git bisect to track down the commit that broke the build. Seems like this is the SHA: ebac19dad6263141d5db0a2c923efe049dba99d2 ebac19dad6263141d5db0a2c923efe049dba99d2 is the first bad commit commit ebac19dad6263141d5db0a2c923efe049dba99d2 Author: Victor Stinner Date: Fri Dec 1 20:09:52 2017 +0100 bpo-32030: Don't call _PyPathConfig_Fini() in Py_FinalizeEx() (#4667) Changes: * _PyPathConfig_Fini() cannot be called in Py_FinalizeEx(). Py_Initialize() and Py_Finalize() can be called multiple times, but it must not "forget" parameters set by Py_SetProgramName(), Py_SetPath() or Py_SetPythonHome(), whereas _PyPathConfig_Fini() clear all these parameters. * config_get_program_name() and calculate_program_full_path() now also decode paths using Py_DecodeLocale() to use the surrogateescape error handler, rather than decoding using mbstowcs() which is strict. * Change _Py_CheckPython3() prototype: () => (void) * Truncate a few lines which were too long :040000 040000 de4ec929ff3fcd3c6455d8dae4d16e47fdd32ad5 8b289341f1b5e68757ac3b111a7f11808f5de1ec M Include :040000 040000 ecddc93b37f74818d85f6d8e8ab0e0c57e893c03 c51971a3af2b6f163e625505265277410bb9eedd M Modules :040000 040000 b92d30ac6375b7dde865a878e701684dd400e742 7d5d8810407060f32c9cbce20dcfc6f9d425524f M PC :040000 040000 537f9e0e6a27b41178fe7b828a8da99c63cc2d9b b14940c66180023a3704ad3949367db3e82ca832 M Python ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 08:28:09 2017 From: report at bugs.python.org (Shriramana Sharma) Date: Sat, 02 Dec 2017 13:28:09 +0000 Subject: [issue32198] \b reports false-positives in Indic strings involving combining marks Message-ID: <1512221289.58.0.213398074469.issue32198@psf.upfronthosting.co.za> New submission from Shriramana Sharma : Code: import re cons_taml = "[??????????????????]" print(re.findall("\\b" + cons_taml + "?|?", "???? ????? ??? ?????? ????? ????")) cons_deva = "[?????????????????????????????????]" print(re.findall("\\b" + cons_deva + "?|?", "???? ????? ??? ????? ????? ????")) Specs: Kubuntu Xenial 64 bit Python 3.5.2 (default, Nov 23 2017, 16:37:01) [GCC 5.4.0 20160609] on linux Actual Output: ['?', '??', '??', '??', '?'] ['?', '??', '??', '??', '?'] Expected Output: ['?', '??'] ['?', '??'] Rationale: The formulated RE desires to identify words *starting* with the vowel /ai/ (\u0BC8 ? in Tamil script and \u0948 ? in Devanagari as vowel sign or \u0B90 ? \u0910 ? as independent vowel). ???? ????? and ???? ????? are the only words fitting this criterion. \b is defined to mark a word boundary and is here applied at the beginning of the RE. Observation: There seems to be some assumption that only GC=Lo characters constitute words. Hence the false positives at ? ? ? ? (? ?) and ? ? ? (? ?) where the ? and ? are vowel signs, and ? ? ? (? ?) and ? ? ? (? ?) where the ? and ? are virama characters or vowel cancelling signs. In Indic, such GC=Mc and GC=Mn characters are inalienable parts of words. They should be properly identified as parts of words and no word boundary answering to \b should be generated at their positions. ---------- components: Regular Expressions messages: 307430 nosy: ezio.melotti, jamadagni, mrabarnett priority: normal severity: normal status: open title: \b reports false-positives in Indic strings involving combining marks type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 08:54:38 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 02 Dec 2017 13:54:38 +0000 Subject: [issue32107] Improve MAC address calculation and fix test_uuid.py In-Reply-To: <1511284223.14.0.213398074469.issue32107@psf.upfronthosting.co.za> Message-ID: <1512222878.18.0.213398074469.issue32107@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > I don't know how the proposed change can help. It helps by fixing the regression introduced by a change made in 23df2d1304ece169d7e0dfc843dfb8026b413d9f in this issue, a change that has been made only in the master branch. Before that change, successive calls to getnode() returned the same value on Android. The proposed PR 4677 does not fix that regression and hides that regression instead in the test suite. The fact that getnode() should always return the same value or should not, must be discussed in another issue in the case where that point needs to be raised. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 09:29:39 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 02 Dec 2017 14:29:39 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android Message-ID: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> New submission from Xavier de Gaye : Currently uuid.getnode() returns a random 48-bit number and so the UUIDs are not persistent across time. The reason is that on Android the 'ip link list' command fails. uuid._ip_getnode() should invoke the 'ip link' command instead. ---------- components: Library (Lib) messages: 307432 nosy: xdegaye priority: normal severity: normal stage: needs patch status: open title: uuid.getnode() should return the MAC address on Android type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 10:25:56 2017 From: report at bugs.python.org (Carol Willing) Date: Sat, 02 Dec 2017 15:25:56 +0000 Subject: [issue32200] Download of 3.7.0a2 docs giving a 404 error Message-ID: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za> New submission from Carol Willing : Currently, the 3.7.0a2 doc links are giving 404 errors. 3.6 docs are working just fine. https://docs.python.org/3.7/archives/python-3.7.0a2-docs-pdf-letter.tar.bz2 results in a 404. I wasn't sure if I should report here or in python.org issue tracker. ---------- assignee: docs at python components: Documentation messages: 307433 nosy: docs at python, willingc priority: normal severity: normal status: open title: Download of 3.7.0a2 docs giving a 404 error type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 10:27:07 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 02 Dec 2017 15:27:07 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512228427.05.0.213398074469.issue32030@psf.upfronthosting.co.za> Ned Deily added the comment: main.c now has compile errors on macOS: ../../source/Modules/main.c:904:20: error: expected expression return SET_DECODE_ERROR("PYTHONEXECUTABLE environment " ^ ../../source/Modules/main.c:46:5: note: expanded from macro 'SET_DECODE_ERROR' do { \ ^ ../../source/Modules/main.c:919:24: error: expected expression return SET_DECODE_ERROR("__PYVENV_LAUNCHER__ environment " ^ ../../source/Modules/main.c:46:5: note: expanded from macro 'SET_DECODE_ERROR' do { \ ^ 2 errors generated. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 10:44:11 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 02 Dec 2017 15:44:11 +0000 Subject: [issue32201] Python uuids may not be persistent across time Message-ID: <1512229451.68.0.213398074469.issue32201@psf.upfronthosting.co.za> New submission from Xavier de Gaye : UUIDs are unique and persistent across time and space. UUIDs generated using the getnode() function of the uuid module on a plaform where getnode() cannot use the MAC address are based on a random number created for that purpose and are therefore transient and only valid during the life time of the python process. This seems to be a bug. My understanding of RFC 4122 is that in that case, the random number is generated only once, otherwise the usefulness of this method is not obvious. In any case the user should be made aware of the transientness of the result of getnode() since persistency is a key feature of UUIDs. ---------- components: Library (Lib) messages: 307435 nosy: barry, ned.deily, serhiy.storchaka, vstinner, xdegaye priority: normal severity: normal status: open title: Python uuids may not be persistent across time type: behavior versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 10:44:19 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 02 Dec 2017 15:44:19 +0000 Subject: [issue32200] Full docs build of 3.6 and 3.7 failing since 2017-10-15 In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za> Message-ID: <1512229459.71.0.213398074469.issue32200@psf.upfronthosting.co.za> Ned Deily added the comment: It looks like the 3.6 and 3.7 full doc build has been failing since 2017-10-15. Seen in /var/log/docsbuild/python37-en.log: [...] [3] [4] [5] [6] [7] (/usr/share/texlive/texmf-dist/tex/latex/ucs/data/uni-1.def ) (/usr/share/texlive/texmf-dist/tex/latex/ucs/data/uninames.dat) (/usr/share/texlive/texmf-dist/tex/latex/ucs/data/uni-1.def) ! Package ucs Error: Unknown Unicode character 383 = U+017F, (ucs) possibly declared in uni-1.def. (ucs) Type H to see if it is available with options. See the ucs package documentation for explanation. Type H for immediate help. ... l.781 Latin small letter dotless i), ?? ? (U+017F, Latin small letter lo... ? ! Emergency stop. ... l.781 Latin small letter dotless i), ?? ? (U+017F, Latin small letter lo... ! ==> Fatal error occurred, no output PDF file produced! Transcript written on howto-regex.log. Latexmk: Index file 'howto-regex.idx' was written Collected error summary (may duplicate other messages): pdflatex: Command for 'pdflatex' gave return code 256 Latexmk: Use the -f option to force complete processing, unless error was exceeding maximum runs of latex/pdflatex. Latexmk: Errors, so I did not complete making targets make[2]: *** [howto-regex.pdf] Error 12 make[2]: Leaving directory `/srv/docsbuild/python37/Doc/build/latex' make[1]: *** [dist] Error 2 make[1]: Leaving directory `/srv/docsbuild/python37/Doc' make: *** [autobuild-dev] Error 2 Julien, can you take a look please? ---------- nosy: +mdk, ned.deily title: Download of 3.7.0a2 docs giving a 404 error -> Full docs build of 3.6 and 3.7 failing since 2017-10-15 versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 11:02:05 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 02 Dec 2017 16:02:05 +0000 Subject: [issue32201] Python uuids may not be persistent across time In-Reply-To: <1512229451.68.0.213398074469.issue32201@psf.upfronthosting.co.za> Message-ID: <1512230525.27.0.213398074469.issue32201@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Hum, I misunderstood the meaning of persistency in this context. It is the uniqueness that is persistent. Sorry for the noise, closing now. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 11:37:37 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 02 Dec 2017 16:37:37 +0000 Subject: [issue32174] nonASCII punctuation characters can not display in python363.chm. In-Reply-To: <1512013530.29.0.213398074469.issue32174@psf.upfronthosting.co.za> Message-ID: <1512232657.68.0.213398074469.issue32174@psf.upfronthosting.co.za> Steve Dower added the comment: I'm not sure there will be any good fix for this. We might be able to coerce proper utf-8 output from Sphinx, and if it also adds the encoding tags required by whatever ancient version of Internet Explorer is used then it should be fine It's likely just best to avoid special punctuation in doc source files though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 12:09:53 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 02 Dec 2017 17:09:53 +0000 Subject: [issue32202] [ctypes] all long double tests fail on android-24-x86_64 Message-ID: <1512234593.69.0.213398074469.issue32202@psf.upfronthosting.co.za> New submission from Xavier de Gaye : These tests are ok on Android API 24 on the armv7, x86 and arm64 architectures. ====================================================================== FAIL: test_longdouble (ctypes.test.test_callbacks.Callbacks) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sdcard/org.python/lib/python3.7/ctypes/test/test_callbacks.py", line 83, in test_longdouble self.check_type(c_longdouble, 3.14) File "/sdcard/org.python/lib/python3.7/ctypes/test/test_callbacks.py", line 25, in check_type self.assertEqual(result, arg) AssertionError: 0.0 != 3.14 ====================================================================== FAIL: test_longdouble (ctypes.test.test_cfuncs.CFunctions) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sdcard/org.python/lib/python3.7/ctypes/test/test_cfuncs.py", line 165, in test_longdouble self.assertEqual(self._dll.tf_D(42.), 14.) AssertionError: 0.0 != 14.0 ====================================================================== FAIL: test_longdouble_plus (ctypes.test.test_cfuncs.CFunctions) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sdcard/org.python/lib/python3.7/ctypes/test/test_cfuncs.py", line 171, in test_longdouble_p lus self.assertEqual(self._dll.tf_bD(0, 42.), 14.) AssertionError: 0.0 != 14.0 ====================================================================== FAIL: test_longdoubleresult (ctypes.test.test_functions.FunctionTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sdcard/org.python/lib/python3.7/ctypes/test/test_functions.py", line 146, in test_longdoubl eresult self.assertEqual(result, 21) AssertionError: 0.0 != 21 ---------------------------------------------------------------------- Ran 468 tests in 1.815s FAILED (failures=4, skipped=92) test test_ctypes failed test_ctypes failed 1 test failed: test_ctypes ---------- components: Extension Modules, Tests messages: 307439 nosy: xdegaye priority: normal severity: normal stage: needs patch status: open title: [ctypes] all long double tests fail on android-24-x86_64 type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 12:26:14 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 02 Dec 2017 17:26:14 +0000 Subject: [issue32203] [ctypes] test_struct_by_value fails on android-24-arm64 Message-ID: <1512235574.32.0.213398074469.issue32203@psf.upfronthosting.co.za> New submission from Xavier de Gaye : test_struct_by_value is ok on Android API 24 on the armv7, x86 and x86_64 architectures. ====================================================================== FAIL: test_struct_by_value (ctypes.test.test_win32.Structures) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sdcard/org.python/lib/python3.7/ctypes/test/test_win32.py", line 137, in test_struct_by_value self.assertEqual(ret.left, left.value) AssertionError: -200 != 10 ---------------------------------------------------------------------- Ran 1 test in 0.204s ---------- components: Extension Modules, Tests messages: 307440 nosy: xdegaye priority: normal severity: normal stage: needs patch status: open title: [ctypes] test_struct_by_value fails on android-24-arm64 type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 12:32:36 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 17:32:36 +0000 Subject: [issue25054] Capturing start of line '^' In-Reply-To: <1441887596.73.0.766811958538.issue25054@psf.upfronthosting.co.za> Message-ID: <1512235956.86.0.213398074469.issue25054@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4586 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 12:32:36 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 17:32:36 +0000 Subject: [issue1647489] zero-length match confuses re.finditer() Message-ID: <1512235956.97.0.00913614298617.issue1647489@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4587 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 12:32:37 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 17:32:37 +0000 Subject: [issue852532] ^$ won't split on empty line Message-ID: <1512235957.1.0.0136706687182.issue852532@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4588 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 12:32:37 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 17:32:37 +0000 Subject: [issue3262] re.split doesn't split with zero-width regex In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za> Message-ID: <1512235957.18.0.16826775903.issue3262@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4589 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 12:35:52 2017 From: report at bugs.python.org (Julien Palard) Date: Sat, 02 Dec 2017 17:35:52 +0000 Subject: [issue32200] Full docs build of 3.6 and 3.7 failing since 2017-10-15 In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za> Message-ID: <1512236152.05.0.213398074469.issue32200@psf.upfronthosting.co.za> Change by Julien Palard : ---------- nosy: +jfbu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 12:37:24 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 17:37:24 +0000 Subject: [issue25054] Capturing start of line '^' In-Reply-To: <1441887596.73.0.766811958538.issue25054@psf.upfronthosting.co.za> Message-ID: <1512236244.88.0.213398074469.issue25054@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Good point. Neither old nor new (which matches regex) behaviors conform the documentation: "Empty matches are included in the result unless they touch the beginning of another match." It is easy to exclude empty matches that touch the *ending* of another match. This would be consistent with the new behavior of split() and sub(). But this would break a one existing test for issue817234. Though that issue shouldn't rely on this detail. The test should just test that iterating doesn't hang. And this would break a regular expression in pprint. PR 4678 implements this version. I don't know what version is better. >>> list(re.finditer(r"\b|:+", "a::bc")) [, , , ] >>> re.sub(r"(\b|:+)", r"[\1]", "a::bc") '[]a[][::]bc[]' With PR 4471 the result of re.sub() is the same, but the result of re.finditer() is as in msg307424. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 12:46:15 2017 From: report at bugs.python.org (Julien Palard) Date: Sat, 02 Dec 2017 17:46:15 +0000 Subject: [issue32200] Full docs build of 3.6 and 3.7 failing since 2017-10-15 In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za> Message-ID: <1512236775.62.0.213398074469.issue32200@psf.upfronthosting.co.za> Julien Palard added the comment: Yes, it's related to: - https://github.com/python/cpython/pull/3940 - https://github.com/python/cpython/pull/4069 Idea is: Unicode characters are not well supported by pdflatex which what's we're using to build our PDF files. There's two solutions: - Use xelatex which just works but does not use the same fonts, and the output style is slightly different - Use hard handcrafted latex macros to make pdflatex work I'm personally in favor of the xelatex solution (The simple one: the patch even remove some lines from the sphinx conf). But the handcrafted latex macro have some advantages: they only "whitelist" the actually used characters, so typos are easily spotted, by the cost of adding a new macro each time we use a new out of the recognized set unicode character. My point of view is: Documentation people should not have to care about Latex, they should not even know we're using latex in the background to build PDFs, so the xelatex looks the right solution to me. I'm currently running a test build of an un-to-date Python 3.6 with PR 3940 applied to check if it succeed as expected. (I'm personally unable to type the macro to allow "Latin small letter dotless i" to work, so I won't test PR 31589). It it succeed, I'll also provide screenshot showing the differences between the current PDF (pdflatex) and the xelatex one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 12:49:42 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sat, 02 Dec 2017 17:49:42 +0000 Subject: [issue32197] Compiling against master branch fails; error: expected expression SET_DECODE_ERROR In-Reply-To: <1512219000.84.0.213398074469.issue32197@psf.upfronthosting.co.za> Message-ID: <1512236982.8.0.213398074469.issue32197@psf.upfronthosting.co.za> Sanyam Khurana added the comment: I tried to resolve the issue by trying to figure out the syntax for the SET_DECODE_ERROR macro. I tried to call a function from the macro, and eventually do the checking in that function. Second way I tried was to replace statement for macro instead of using do-while for placing the if-else clause. I was stuck at the issue that at the point when the compiler tries to replace the macro with actual code, `pymain` wasn't defined. If someone could provide a pointer on this, it would be really helpful and I'll try to work on a patch. One simplest possible solution would be not use macro and simply use the code at the 3 places where it is being used. But I'll defer this anti-DRY approach if we can have a better solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 12:58:53 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sat, 02 Dec 2017 17:58:53 +0000 Subject: [issue32197] Compiling against master branch fails; error: expected expression SET_DECODE_ERROR In-Reply-To: <1512219000.84.0.213398074469.issue32197@psf.upfronthosting.co.za> Message-ID: <1512237533.89.0.213398074469.issue32197@psf.upfronthosting.co.za> Sanyam Khurana added the comment: Even a simple use of ternary operator instead of using if-else inside do-while to handle the macro like: #define SET_DECODE_ERROR(NAME, LEN) \ pymain->err = ((LEN) == (size_t)-2) \ ? _Py_INIT_USER_ERR("cannot decode " #NAME) \ : _Py_INIT_NO_MEMORY() , throws the error `undeclared identifier pymain`: gcc -c -Wno-unused-result -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -I. -I./Include -DPy_BUILD_CORE -o Modules/main.o Modules/main.c Modules/main.c:899:20: error: use of undeclared identifier 'pymain' return SET_DECODE_ERROR("PYTHONEXECUTABLE environment " ^ Modules/main.c:46:5: note: expanded from macro 'SET_DECODE_ERROR' pymain->err = ((LEN) == (size_t)-2) \ ^ 1 error generated. make: *** [Modules/main.o] Error 1 I'm still trying to figure out a solution for this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 13:15:13 2017 From: report at bugs.python.org (Julien Palard) Date: Sat, 02 Dec 2017 18:15:13 +0000 Subject: [issue32200] Full docs build of 3.6 and 3.7 failing since 2017-10-15 In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za> Message-ID: <1512238513.67.0.213398074469.issue32200@psf.upfronthosting.co.za> Julien Palard added the comment: It works with xelatex (https://github.com/python/cpython/pull/3940), here's the difference: https://screenshots.firefox.com/wSn4a8WyFMNzXgKm/null https://screenshots.firefox.com/WmUNljwcO8mImchP/null The "bold" one is the xelatex one. In case we want this to be merged, xelatex have already been installed on the build server (https://github.com/python/psf-salt/pull/122). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 13:18:43 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 18:18:43 +0000 Subject: [issue32197] Compiling against master branch fails; error: expected expression SET_DECODE_ERROR In-Reply-To: <1512219000.84.0.213398074469.issue32197@psf.upfronthosting.co.za> Message-ID: <1512238723.21.0.213398074469.issue32197@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +4590 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 13:18:43 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 18:18:43 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512238723.31.0.00913614298617.issue32030@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4591 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 13:28:37 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 18:28:37 +0000 Subject: [issue32198] \b reports false-positives in Indic strings involving combining marks In-Reply-To: <1512221289.58.0.213398074469.issue32198@psf.upfronthosting.co.za> Message-ID: <1512239317.28.0.213398074469.issue32198@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is a known issue. See also issue1693050, issue12731, issue25743. I hope it will be solved in 3.7 and maybe the solution will be backported to 2.7 and 3.6 (but not to 3.5, 3.5 takes only security fixes). As a workaround I suggest you to use the third-party regex module. This is a mature module mostly compatible with re, but with better support of Unicode and additional features. ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka versions: +Python 2.7, Python 3.6, Python 3.7 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 13:30:55 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 18:30:55 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512239455.23.0.213398074469.issue32199@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +easy nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 13:39:01 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 18:39:01 +0000 Subject: [issue32107] Improve MAC address calculation and fix test_uuid.py In-Reply-To: <1511284223.14.0.213398074469.issue32107@psf.upfronthosting.co.za> Message-ID: <1512239941.03.0.213398074469.issue32107@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, but I can't understand how 23df2d1304ece169d7e0dfc843dfb8026b413d9f could break getnode() on Android and how your changes can fix this. The only effect of this change is that an error in _random_getnode() no longer silenced. But this is not the case, because if _random_getnode() raises an exception you can't get two different results (you can't get even the single result) for comparison. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 13:49:07 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 02 Dec 2017 18:49:07 +0000 Subject: [issue32107] Improve MAC address calculation and fix test_uuid.py In-Reply-To: <1512239941.03.0.213398074469.issue32107@psf.upfronthosting.co.za> Message-ID: <46A996BD-8239-4382-8B34-C69516F2EE44@python.org> Barry A. Warsaw added the comment: > Sorry, but I can't understand how 23df2d1304ece169d7e0dfc843dfb8026b413d9f could break getnode() on Android and how your changes can fix this. The only effect of this change is that an error in _random_getnode() no longer silenced. But this is not the case, because if _random_getnode() raises an exception you can't get two different results (you can't get even the single result) for comparison. I concur. Your test appears to be failing because it wants two successive calls to getnode() to return the same value. But the proposed change doesn?t change the fact that if you fall back to _random_getnode() you?re going to get a different random value every time. I think you need to look into the problem more deeply. (It doesn?t help that the code swallows all exceptions from the other getters - I pointed that out in my previous PRs. I?ll bet the clue to your problem is being hidden by that bare except.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 13:50:57 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 18:50:57 +0000 Subject: [issue32197] Compiling against master branch fails; error: expected expression SET_DECODE_ERROR In-Reply-To: <1512219000.84.0.213398074469.issue32197@psf.upfronthosting.co.za> Message-ID: <1512240657.77.0.213398074469.issue32197@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4592 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 13:50:57 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 18:50:57 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512240657.86.0.00913614298617.issue32030@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4593 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 14:00:11 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 19:00:11 +0000 Subject: [issue10544] yield expression inside generator expression does nothing In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za> Message-ID: <1512241211.68.0.213398074469.issue10544@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 65d1887170fb278c10a836e9e4319cae4707f524 by Serhiy Storchaka in branch '2.7': [2.7] bpo-10544: Deprecate "yield" in comprehensions and generator expressions in Py3k mode. (GH-4579) (#4676) https://github.com/python/cpython/commit/65d1887170fb278c10a836e9e4319cae4707f524 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 14:01:38 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 19:01:38 +0000 Subject: [issue10544] yield expression inside generator expression does nothing In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za> Message-ID: <1512241298.85.0.213398074469.issue10544@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 14:34:17 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Sat, 02 Dec 2017 19:34:17 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512243257.44.0.213398074469.issue19610@psf.upfronthosting.co.za> Neil Schemenauer added the comment: I don't see a good reason to add this check. I would guess there could be lots of 3rd party packages that are no uninstallable on Python 3.7. E.g. python3 -m pip install exifread ... TypeError: 'classifiers' should be a 'list', not 'tuple' If people are determined to add extra type checking, make it a warning for 3.7 so setup.py files can be fixed. ---------- nosy: +nascheme resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 14:35:19 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 02 Dec 2017 19:35:19 +0000 Subject: [issue32200] Full docs build of 3.6 and 3.7 failing since 2017-10-15 In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za> Message-ID: <1512243319.83.0.213398074469.issue32200@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks, Julien. To be clear, are you recommending applying just PR 3940 or also the unique part of PR 4069? At this point, I am not concerned about the apparent minor difference in appearance; I would just like the downloadable docs to build and be usable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 14:36:02 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 19:36:02 +0000 Subject: [issue32197] Compiling against master branch fails; error: expected expression SET_DECODE_ERROR In-Reply-To: <1512219000.84.0.213398074469.issue32197@psf.upfronthosting.co.za> Message-ID: <1512243362.8.0.213398074469.issue32197@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 13badcbc60cdbfae1dba1683fd2fae9d70717143 by Serhiy Storchaka in branch 'master': bpo-32197: Try to fix a compiler error on OS X introduced in bpo-32030. (#4681) https://github.com/python/cpython/commit/13badcbc60cdbfae1dba1683fd2fae9d70717143 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 14:36:02 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 19:36:02 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512243362.89.0.912454111764.issue32030@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 13badcbc60cdbfae1dba1683fd2fae9d70717143 by Serhiy Storchaka in branch 'master': bpo-32197: Try to fix a compiler error on OS X introduced in bpo-32030. (#4681) https://github.com/python/cpython/commit/13badcbc60cdbfae1dba1683fd2fae9d70717143 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 15:11:22 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 20:11:22 +0000 Subject: [issue25054] Capturing start of line '^' In-Reply-To: <1441887596.73.0.766811958538.issue25054@psf.upfronthosting.co.za> Message-ID: <1512245482.78.0.213398074469.issue25054@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The clause "Empty matches are included in the result unless they touch the beginning of another match" was added in 2f3e5483a3324b44fa5dbbb98859dc0ac42b6070 (issue732120) and I suppose it never was correct. So we can ignore it in the context of this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 15:34:02 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Sat, 02 Dec 2017 20:34:02 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512246842.65.0.213398074469.issue19610@psf.upfronthosting.co.za> Neil Schemenauer added the comment: I tried building the top packages from python3wos.appspot.com. Only simplejson-3.13.2.tar.gz fails to build due to this change. However, given that it is the top downloaded module, I think think making a change to Python that makes it uninstallable by "pip" is a bad idea. There needs to be a transition process. I'm setting priority to "release blocker". People can downgrade if they disagree with me. I tried changing the TypeError raises with Deprecation warnings. That doesn't have any effect because DeprecationWarning is filtered by default. Enabling it still has no effect because apparently pip filters it out. So, I think some other way to warn people would need to be implemented. E.g. have distutils print to stderr. Change pip to warn as well. ---------- nosy: +ned.deily priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 15:51:06 2017 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Dec 2017 20:51:06 +0000 Subject: [issue32168] Mutable instance variables don't get new references with args. In-Reply-To: <1511954104.7.0.213398074469.issue32168@psf.upfronthosting.co.za> Message-ID: <1512247866.4.0.213398074469.issue32168@psf.upfronthosting.co.za> R. David Murray added the comment: For the record: https://docs.python.org/3/faq/programming.html#id13 ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 15:55:55 2017 From: report at bugs.python.org (Berker Peksag) Date: Sat, 02 Dec 2017 20:55:55 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512248155.77.0.213398074469.issue19610@psf.upfronthosting.co.za> Berker Peksag added the comment: Classifiers were always documented as lists (msg214915) and passing a non-list type was raised a cryptic exception message as already reported in my first message, https://github.com/pypa/setuptools/issues/1163 and https://reinbach.com/blog/setuptools-classifiers-upload-python3-5/ Any usage of classifiers=(...,) is already broken in Python 3 in some way (see the setup.py I attached or https://reinbach.com/blog/setuptools-classifiers-upload-python3-5/ for a quick reproducer) since they can't upload a new release. Also, this is only an issue when sdist is the only way to install the project. exifread only provides a wheel for Python 2. I cloned it and add [wheel] universal = 1 then I created a universal wheel and tried to install it in Python 3.7.0a2+: Processing /home/berker/projects/test/exif-py/dist/ExifRead-2.1.2-py2.py3-none-any.whl Installing collected packages: ExifRead Successfully installed ExifRead-2.1.2 ---------- nosy: -ned.deily priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 15:57:00 2017 From: report at bugs.python.org (Berker Peksag) Date: Sat, 02 Dec 2017 20:57:00 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512248220.67.0.213398074469.issue19610@psf.upfronthosting.co.za> Berker Peksag added the comment: (Sorry, I messed up fields in the issue.) ---------- nosy: +ned.deily priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 16:09:12 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 02 Dec 2017 21:09:12 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512248952.77.0.213398074469.issue19610@psf.upfronthosting.co.za> Change by Ned Deily : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 16:18:24 2017 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Dec 2017 21:18:24 +0000 Subject: [issue32172] Add length counter for iterables In-Reply-To: <1511996453.35.0.213398074469.issue32172@psf.upfronthosting.co.za> Message-ID: <1512249504.51.0.213398074469.issue32172@psf.upfronthosting.co.za> R. David Murray added the comment: Guido specifically rejected __len__ for iterators when the iteration protocol was designed. This has become a FREQ in recent times (Frequently Rejected Enhancement Request :) The rationale, as I understand it, is that an iterator object should always evaluate to True in a boolean context, but I don't know why. There is also a consistency argument: since not all iterators *can* have a len, then none should, because if some did and some didn't you couldn't use iterators interchangeably in code the way you can now. In other words, you can't make __len__ part of the iterator protocol, so iterators don't have a __len__. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 16:26:00 2017 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Dec 2017 21:26:00 +0000 Subject: [issue32174] nonASCII punctuation characters can not display in python363.chm. In-Reply-To: <1512013530.29.0.213398074469.issue32174@psf.upfronthosting.co.za> Message-ID: <1512249960.66.0.213398074469.issue32174@psf.upfronthosting.co.za> R. David Murray added the comment: The doc source files do not contain smart quotes, and as far as I know, sphinx does produce correct utf-8. Recently there was a bug where incorrect smart quotes were leaking out of the internationalization of the docs, so this might be a problem that is already fixed. On the other hand, there might be something broken about the chm production process. I have no idea who would be the right person to investigate that, since I think Steve just spins the wheel on existing tools to get them generated :) On the gripping hand, could there be something broken about your local charset configuration? Does anyone else see this problem? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 16:29:18 2017 From: report at bugs.python.org (Matthew Barnett) Date: Sat, 02 Dec 2017 21:29:18 +0000 Subject: [issue25054] Capturing start of line '^' In-Reply-To: <1441887596.73.0.766811958538.issue25054@psf.upfronthosting.co.za> Message-ID: <1512250158.59.0.213398074469.issue25054@psf.upfronthosting.co.za> Matthew Barnett added the comment: The pattern: \b|:+ will match a word boundary (zero-width) before colons, so if there's a word followed by colons, finditer will find the boundary and then the colons. You _can_ get a zero-width match (ZWM) joined to the start of a nonzero-width match (NWM). That's not really surprising. If you wanted to avoid a ZWM joined to either end of a NWM, you'd need to keep looking for another match at a position even after you'd already found a match if what you'd found was zero-width. That would also affect re.search and re.match. For regex on Python 3.7, I'm going with avoiding a ZWM joined to the end of a NWM, unless re's going a different way, in which case I have more work to do to remain compatible! The change I did for Python 3.7+ was trivial. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 16:31:29 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 02 Dec 2017 21:31:29 +0000 Subject: [issue32174] nonASCII punctuation characters can not display in python363.chm. In-Reply-To: <1512013530.29.0.213398074469.issue32174@psf.upfronthosting.co.za> Message-ID: <1512250289.68.0.213398074469.issue32174@psf.upfronthosting.co.za> Change by Ned Deily : ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 16:36:30 2017 From: report at bugs.python.org (Julien Palard) Date: Sat, 02 Dec 2017 21:36:30 +0000 Subject: [issue32200] Full docs build of 3.6 and 3.7 failing since 2017-10-15 In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za> Message-ID: <1512250590.21.0.213398074469.issue32200@psf.upfronthosting.co.za> Julien Palard added the comment: I recommand PR 3940, as it's simple, and as I'm still unable to fix issue32200 with PR 4069 (I still don't understand how to write those latex macros). I'm open to follow the discussion about PR 4069, if one find a nice documentable reproductible protocol to update the list of latex macros to allow for a new character to be added. Please not the french and japanese documentation may still fail (French should succeed with xelatex, japanese will still fail), which is expected, it's the origigin of PR 3940 and PR 4069, I'm still working on it, also see: https://github.com/python/docsbuild-scripts/pull/34. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 16:37:19 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 21:37:19 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512250639.46.0.213398074469.issue19610@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In simplejson classifiers is a result of filter(). This is a list in Python 2 and an iterator in Python 3. It can be uploaded using Python 2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 16:46:31 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 21:46:31 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512251191.65.0.213398074469.issue19610@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Filed a bug https://github.com/simplejson/simplejson/issues/198 for simplejson. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 16:47:09 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Sat, 02 Dec 2017 21:47:09 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512251229.15.0.213398074469.issue19610@psf.upfronthosting.co.za> Neil Schemenauer added the comment: > Classifiers were always documented as lists (msg214915) and passing a non-list type was raised a cryptic exception message as already reported in my first message That doesn't matter. You can't break a bunch of packages in a 3.x release with no warning just because people are doing something against what the documentation says. That's not how we develop Python. How is a user of a 3rd party package going to fix this? They have to ask the 3rd party package author to fix their setup.py code. Until then, they cannot use Python 3.7. This patch needs to be reverted and reworked, IMHO. I trying installing the top packages listed on https://pythonwheels.com . A number of them fail because of this change, see attached text file. ---------- Added file: https://bugs.python.org/file47312/pip-errors.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 16:48:39 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 21:48:39 +0000 Subject: [issue462270] sub-tle difference between pre and sre Message-ID: <1512251319.48.0.213398074469.issue462270@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For history, this was fixed by 21009b9c6fc40b25fcb30ee60d6108f235733e40. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 17:01:15 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Dec 2017 22:01:15 +0000 Subject: [issue25054] Capturing start of line '^' In-Reply-To: <1441887596.73.0.766811958538.issue25054@psf.upfronthosting.co.za> Message-ID: <1512252075.37.0.213398074469.issue25054@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Avoiding ZWM after a NWM in re.sub() is explicitly documented (and the documentation is correct in this case). This follows the behavior in the ancient RE implementation. Once it was broken in sre, but then fixed (see 21009b9c6fc40b25fcb30ee60d6108f235733e40, issue462270). Changing this behavior doesn't break anything in the stdlib except the specially purposed test. I think it is better to keep this behavior, but maybe discuss its changing (for making matching the behavior of other RE engines) in the separate issue. I don't know how the behavior of findall() and finditer() is related to this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 17:07:46 2017 From: report at bugs.python.org (Berker Peksag) Date: Sat, 02 Dec 2017 22:07:46 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512252466.52.0.213398074469.issue19610@psf.upfronthosting.co.za> Berker Peksag added the comment: > Filed a bug https://github.com/simplejson/simplejson/issues/198 for > simplejson. I've opened https://github.com/simplejson/simplejson/pull/197 to make CLASSIFIERS a list. I've also opened https://github.com/ianare/exif-py/pull/80 to create a universal wheel for exifread. > That's not how we develop Python. Thank you, but I don't need a lecture from you. Feel free to propose your solution in the form of pull request instead of acting like a project manager and telling people what to do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 17:16:49 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Sat, 02 Dec 2017 22:16:49 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1512253009.84.0.213398074469.issue17611@psf.upfronthosting.co.za> Change by Neil Schemenauer : ---------- pull_requests: +4594 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 17:24:41 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 02 Dec 2017 22:24:41 +0000 Subject: [issue31589] Links for French documentation PDF is broken: LaTeX issue with non-ASCII characters? In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za> Message-ID: <1512253481.3.0.213398074469.issue31589@psf.upfronthosting.co.za> Ned Deily added the comment: New changeset 7324b5ce8e7c031a0a3832a6a8d7c639111ae0ff by Ned Deily (Julien Palard) in branch 'master': bpo-31589 : Build PDF using xelatex for better UTF8 support. (#3940) https://github.com/python/cpython/commit/7324b5ce8e7c031a0a3832a6a8d7c639111ae0ff ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 17:24:41 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 02 Dec 2017 22:24:41 +0000 Subject: [issue32200] Full docs build of 3.6 and 3.7 failing since 2017-10-15 In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za> Message-ID: <1512253481.46.0.912454111764.issue32200@psf.upfronthosting.co.za> Ned Deily added the comment: New changeset 7324b5ce8e7c031a0a3832a6a8d7c639111ae0ff by Ned Deily (Julien Palard) in branch 'master': bpo-31589 : Build PDF using xelatex for better UTF8 support. (#3940) https://github.com/python/cpython/commit/7324b5ce8e7c031a0a3832a6a8d7c639111ae0ff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 17:24:55 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 Dec 2017 22:24:55 +0000 Subject: [issue31589] Links for French documentation PDF is broken: LaTeX issue with non-ASCII characters? In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za> Message-ID: <1512253495.33.0.213398074469.issue31589@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4595 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 17:24:55 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 Dec 2017 22:24:55 +0000 Subject: [issue32200] Full docs build of 3.6 and 3.7 failing since 2017-10-15 In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za> Message-ID: <1512253495.46.0.00913614298617.issue32200@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +4596 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 17:26:01 2017 From: report at bugs.python.org (Martin Panter) Date: Sat, 02 Dec 2017 22:26:01 +0000 Subject: [issue29710] Incorrect representation caveat on bitwise operation docs In-Reply-To: <1488551919.31.0.20533072889.issue29710@psf.upfronthosting.co.za> Message-ID: <1512253561.17.0.213398074469.issue29710@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW I find Mark?s suggestion pretty good: ?Each bitwise operation has the same result as though carried out in two's complement using a bit-width that's large enough to represent the inputs.? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 17:35:10 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 02 Dec 2017 22:35:10 +0000 Subject: [issue31589] Links for French documentation PDF is broken: LaTeX issue with non-ASCII characters? In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za> Message-ID: <1512254110.96.0.213398074469.issue31589@psf.upfronthosting.co.za> Ned Deily added the comment: New changeset 2ad350a713360e89ae6d264924cd28f519b8b22c by Ned Deily (Miss Islington (bot)) in branch '3.6': [3.6] bpo-31589 : Build PDF using xelatex for better UTF8 support. (GH-3940) (#4683) https://github.com/python/cpython/commit/2ad350a713360e89ae6d264924cd28f519b8b22c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 17:35:11 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 02 Dec 2017 22:35:11 +0000 Subject: [issue32200] Full docs build of 3.6 and 3.7 failing since 2017-10-15 In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za> Message-ID: <1512254111.09.0.912454111764.issue32200@psf.upfronthosting.co.za> Ned Deily added the comment: New changeset 2ad350a713360e89ae6d264924cd28f519b8b22c by Ned Deily (Miss Islington (bot)) in branch '3.6': [3.6] bpo-31589 : Build PDF using xelatex for better UTF8 support. (GH-3940) (#4683) https://github.com/python/cpython/commit/2ad350a713360e89ae6d264924cd28f519b8b22c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 17:39:26 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 02 Dec 2017 22:39:26 +0000 Subject: [issue32200] Full docs build of 3.6 and 3.7 failing since 2017-10-15 In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za> Message-ID: <1512254366.53.0.213398074469.issue32200@psf.upfronthosting.co.za> Ned Deily added the comment: OK, thanks. I've pushed PR 3940 to master and backported it to 3.6. I'll keep this open until we've seen the next full doc build complete successfully. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 17:48:15 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Sat, 02 Dec 2017 22:48:15 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512254895.08.0.213398074469.issue19610@psf.upfronthosting.co.za> Neil Schemenauer added the comment: > Thank you, but I don't need a lecture from you. Feel free to propose our solution in the form of pull request instead of acting like a project manager and telling people what to do. I'm sorry you are offended. My pull request would consist of the patch being reverted. It is not ready to go in. If a change breaks a significant amount of previously working Python code, it needs very careful consideration and should be introduced in a way to minimize breakage and allow people time to fix their code. Repeatably pointing to the documentation and saying that existing code is broken because it doesn't respect documented requirements is not okay. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 17:48:58 2017 From: report at bugs.python.org (Matthew Barnett) Date: Sat, 02 Dec 2017 22:48:58 +0000 Subject: [issue25054] Capturing start of line '^' In-Reply-To: <1441887596.73.0.766811958538.issue25054@psf.upfronthosting.co.za> Message-ID: <1512254938.12.0.213398074469.issue25054@psf.upfronthosting.co.za> Matthew Barnett added the comment: findall() and finditer() consist of multiple uses of search(), basically, as do sub() and split(), so we want the same rule to apply to them all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 19:39:57 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 03 Dec 2017 00:39:57 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1512261597.91.0.213398074469.issue17611@psf.upfronthosting.co.za> Nick Coghlan added the comment: I like this change, and think we should go ahead with it, but just wanted to note that I suspect it may make the "Badly timed signals may lead to __exit__ being skipped even after __enter__ succeeded" problem slightly easier to hit: https://bugs.python.org/issue29988 That's not a new problem though, and this change should make it easier to apply the conventional solutions (i.e. only checking for signals when execution jumps backwards within a function, as well as in function pre-or-post-ambles) ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 19:49:28 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 03 Dec 2017 00:49:28 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1512262168.58.0.213398074469.issue17611@psf.upfronthosting.co.za> Raymond Hettinger added the comment: At this point in the release cycle, it would be nice to get this PR applied soon so that there is more time see if there are any minor follow-on issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 19:50:37 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 03 Dec 2017 00:50:37 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1512262237.36.0.213398074469.issue17611@psf.upfronthosting.co.za> Nick Coghlan added the comment: While there are some good comments in line in the PR, I think it would be helpful if these changes were accompanied by some additions to https://devguide.python.org/compiler/ that explain how the various pieces of the solution work together to manage the execution stack. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 20:12:22 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 03 Dec 2017 01:12:22 +0000 Subject: [issue32176] Zero argument super is broken in 3.6 for methods with a hacked __class__ cell In-Reply-To: <1512027575.04.0.213398074469.issue32176@psf.upfronthosting.co.za> Message-ID: <1512263542.57.0.213398074469.issue32176@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset 078f1814f1a4413a2a0fdb8cf4490ee0fc98ef34 by Nick Coghlan in branch 'master': bpo-32176: Set CO_NOFREE in the code object constructor (GH-4675) https://github.com/python/cpython/commit/078f1814f1a4413a2a0fdb8cf4490ee0fc98ef34 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 20:22:07 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 03 Dec 2017 01:22:07 +0000 Subject: [issue32176] Zero argument super is broken in 3.6 for methods with a hacked __class__ cell In-Reply-To: <1512027575.04.0.213398074469.issue32176@psf.upfronthosting.co.za> Message-ID: <1512264127.1.0.213398074469.issue32176@psf.upfronthosting.co.za> Change by Nick Coghlan : ---------- pull_requests: +4597 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 20:29:02 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 03 Dec 2017 01:29:02 +0000 Subject: [issue32192] Provide importlib.util.lazy_import helper function In-Reply-To: <1512118241.83.0.213398074469.issue32192@psf.upfronthosting.co.za> Message-ID: <1512264542.65.0.213398074469.issue32192@psf.upfronthosting.co.za> Nick Coghlan added the comment: Maintaining the actual implementation as a third party module seems like a good idea to me, so I'm marking this as a documentation issue instead. The idea would be to add this as an example of a very basic lazy importer under https://docs.python.org/3/library/importlib.html#examples ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 20:39:30 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 03 Dec 2017 01:39:30 +0000 Subject: [issue29710] Incorrect representation caveat on bitwise operation docs In-Reply-To: <1488551919.31.0.20533072889.issue29710@psf.upfronthosting.co.za> Message-ID: <1512265170.5.0.213398074469.issue29710@psf.upfronthosting.co.za> Nick Coghlan added the comment: I like Mark's phrasing as well. For precision, I'd still like to give an exact algorithmic formulation of what "large enough" means in this context, though. Something like: Each bitwise operation has the same result as though carried out in two's complement using a bit-width that's large enough to represent the inputs. ("Large enough" for this purpose is ``1 + max(x.bit_length(), y .bit_length()``, with the extra bit being needed to handle sign extension appropriately) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 21:20:55 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 03 Dec 2017 02:20:55 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512267655.44.0.213398074469.issue19610@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'd prefer to see this change go in the other direction: instead of enforcing eager type checks, we should be unconditionally wrapping the given values in a "list(arg)" call, such that more typical iterable duck-typing behaviour applies. That will transparently fix any code that isn't already passing a list, will ensure that internal code can safely assume that the instance *attributes* are always lists (no matter what the caller passes in), and means that even when the caller is passing in a list, the instance will have its own copy (rather than retaining a reference to the caller's copy). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 22:21:15 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 03 Dec 2017 03:21:15 +0000 Subject: [issue32200] Full docs build of 3.6 and 3.7 failing since 2017-10-15 In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za> Message-ID: <1512271275.88.0.213398074469.issue32200@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: I verified that the download links for Python 3.7.0a2 (English) are now working. The French and Japanese docs downloads are still 404. ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 22:43:41 2017 From: report at bugs.python.org (Tim Peters) Date: Sun, 03 Dec 2017 03:43:41 +0000 Subject: [issue29710] Incorrect representation caveat on bitwise operation docs In-Reply-To: <1488551919.31.0.20533072889.issue29710@psf.upfronthosting.co.za> Message-ID: <1512272621.6.0.213398074469.issue29710@psf.upfronthosting.co.za> Tim Peters added the comment: To answer the old accusation ;-), no, this isn't my wording. I _always_ explain that Python's integer bit operations act as if the integers were stored in 2's-complement representation but with an infinite number of sign bits. That's all. That provides insight. For example, then it's dead obvious that `-1 == ~0` (both an infinite solid string of 1 bits); that for any integer `i`, `-1 ^ i == ~i" (both flip each bit in `i`); and that for any positive integers `i` and `j` it's necessarily the case that `-i ^ -j` is positive (because the infinite strings of sign bits cancel out). The reference manual is under no obligation to explain how to _implement_ this illusion, and I don't think it's helpful to try. People here are struggling to explain how to pick a number of bits "big enough" to make it all work out on a case by case basis, but the single answer "infinity" is big enough to apply in all cases ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 23:55:06 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Sun, 03 Dec 2017 04:55:06 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512276906.72.0.213398074469.issue19610@psf.upfronthosting.co.za> Change by Neil Schemenauer : ---------- pull_requests: +4598 stage: resolved -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 2 23:57:58 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Sun, 03 Dec 2017 04:57:58 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512277078.06.0.213398074469.issue19610@psf.upfronthosting.co.za> Neil Schemenauer added the comment: I like Nick's idea of calling list() to fix the argument. I've created a PR that implements it. I also generate a RuntimeWarning since if we document them as needing to be lists, we should at least warn for invalid types. The RuntimeWarning will be seen if you call setup.py directly which should have the effect of eventually pushing package authors to fix their code. ---------- keywords: +needs review -patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 01:28:50 2017 From: report at bugs.python.org (Warwick Chapman) Date: Sun, 03 Dec 2017 06:28:50 +0000 Subject: [issue29519] weakref spewing exceptions during finalization when combined with multiprocessing In-Reply-To: <1486701306.85.0.363188055849.issue29519@psf.upfronthosting.co.za> Message-ID: <1512282530.84.0.213398074469.issue29519@psf.upfronthosting.co.za> Warwick Chapman added the comment: Will this be released in 2.x as suggested by inada.naoki? ---------- nosy: +Warwick Chapman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 01:31:13 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Dec 2017 06:31:13 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512282673.49.0.213398074469.issue19610@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Perhaps it is worth to backport warnings to 2.7 in Py3k mode. This could help to detect some issues earlier. In 3.6 fields could be converted to lists silently, without warnings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 03:28:03 2017 From: report at bugs.python.org (Julien Palard) Date: Sun, 03 Dec 2017 08:28:03 +0000 Subject: [issue32200] Full docs build of 3.6 and 3.7 failing since 2017-10-15 In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za> Message-ID: <1512289683.27.0.213398074469.issue32200@psf.upfronthosting.co.za> Julien Palard added the comment: Japanese is failing expectedly (may work with platex but not xelatex), but I hoped french to build. But the build server is giving: ! Improper discretionary list. } l.359 ...{PyObject} \PYG{o}{*}\PYG{n}{t}\PYG{p}{;} ? ! Emergency stop. I suspect it's because we're using an old version of xetex (2013.20140215-1ubuntu0.1) and I tested with a recent one (2017.20171128-1). I'm trying to reproduce the issue locally, and to understand the message. In any cases, issue 32200 was about build failing since the introduction of the dotless i, which is now fixed, french and japanese problems are tracked here: https://bugs.python.org/issue31589. I'd close issue 32200. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 03:41:19 2017 From: report at bugs.python.org (Julien Palard) Date: Sun, 03 Dec 2017 08:41:19 +0000 Subject: [issue31589] Links for French documentation PDF is broken: LaTeX issue with non-ASCII characters? In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za> Message-ID: <1512290479.53.0.213398074469.issue31589@psf.upfronthosting.co.za> Julien Palard added the comment: Due to issue 32200, we switched on xelatex, it however did **not** fixed the french builds as expected, maybe because we're using an old version of xelatex. The issue: ! Improper discretionary list. } l.359 ...{PyObject} \PYG{o}{*}\PYG{n}{t}\PYG{p}{;} ? ! Emergency stop. The version of texlive-xetex on the build server: 2013.20140215-1ubuntu0.1 The version I tried: 2017.20171128-1 I'm not having the 2013 version on Debian. I'm trying now with 2014.20141024-2+deb8u1, and I'm trying to understand the error message too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 03:53:21 2017 From: report at bugs.python.org (jfbu) Date: Sun, 03 Dec 2017 08:53:21 +0000 Subject: [issue32200] Full docs build of 3.6 and 3.7 failing since 2017-10-15 In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za> Message-ID: <1512291201.66.0.213398074469.issue32200@psf.upfronthosting.co.za> jfbu added the comment: For info, the xetex problem "Improper discretionary list" is presumably the one seen at https://github.com/sphinx-doc/sphinx/issues/3546. I asked on xetex mailing list at http://tug.org/pipermail/xetex/2017-March/027056.html to which xetex bug it was related but it appears I got no reply. Hence I don't know the precise xetex release which fixed it, but it is ok with `XeTeX 0.99996`. No action was taken on Sphinx side as this appeared to be a XeTeX bug only. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 04:09:09 2017 From: report at bugs.python.org (Liran Nuna) Date: Sun, 03 Dec 2017 09:09:09 +0000 Subject: [issue32204] async/await performance is very low Message-ID: <1512292149.52.0.213398074469.issue32204@psf.upfronthosting.co.za> New submission from Liran Nuna : The performance of async/await is very low when compared to similar code that implements similar functionality via iterators, such as Quora's asynq library (https://github.com/quora/asynq/tree/master/asynq). Based on my benchmarks, asynq is almost twice as fast as async/await. I have found some performance hanging fruit when benchmarking (See attached GitHub PR). $ time python batch_asyncio.py real 0m5.851s user 0m5.760s sys 0m0.088s $ time python batch_asynq.py real 0m2.999s user 0m2.900s sys 0m0.076s ---------- components: asyncio files: batch_asyncio.py messages: 307492 nosy: Liran Nuna, yselivanov priority: normal pull_requests: 4599 severity: normal status: open title: async/await performance is very low type: performance versions: Python 3.6 Added file: https://bugs.python.org/file47313/batch_asyncio.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 04:09:20 2017 From: report at bugs.python.org (jfbu) Date: Sun, 03 Dec 2017 09:09:20 +0000 Subject: [issue31589] Links for French documentation PDF is broken: LaTeX issue with non-ASCII characters? In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za> Message-ID: <1512292160.29.0.213398074469.issue31589@psf.upfronthosting.co.za> jfbu added the comment: I can confirm the "Improper discretionary list" error from xetex build is a xetex bug which is present at XeTeX 0.99992 and absent at XeTeX 0.99996 and presumably all more recent releases. It was seen at https://github.com/sphinx-doc/sphinx/issues/3546 and reported to XeTeX mailing list at http://tug.org/pipermail/xetex/2017-March/027056.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 04:09:48 2017 From: report at bugs.python.org (Liran Nuna) Date: Sun, 03 Dec 2017 09:09:48 +0000 Subject: [issue32204] async/await performance is very low In-Reply-To: <1512292149.52.0.213398074469.issue32204@psf.upfronthosting.co.za> Message-ID: <1512292188.15.0.213398074469.issue32204@psf.upfronthosting.co.za> Liran Nuna added the comment: Added comparable benchmark in asynq ---------- Added file: https://bugs.python.org/file47314/batch_asynq.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 04:27:21 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 03 Dec 2017 09:27:21 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1512277078.06.0.213398074469.issue19610@psf.upfronthosting.co.za> Message-ID: <2d59d853-1319-50ef-1029-cba4667c85fc@free.fr> Antoine Pitrou added the comment: Le 03/12/2017 ? 05:57, Neil Schemenauer a ?crit?: > > I like Nick's idea of calling list() to fix the argument. I don't think that's a good idea. Suppose someone is passing a string by mistake: setup(..., classifiers='Programming Language :: Python :: 3 :: Only', ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 04:50:07 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Dec 2017 09:50:07 +0000 Subject: [issue32204] async/await performance is very low In-Reply-To: <1512292149.52.0.213398074469.issue32204@psf.upfronthosting.co.za> Message-ID: <1512294607.57.0.213398074469.issue32204@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't see any difference after applying PR 4186. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 04:50:24 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Dec 2017 09:50:24 +0000 Subject: [issue32204] async/await performance is very low In-Reply-To: <1512292149.52.0.213398074469.issue32204@psf.upfronthosting.co.za> Message-ID: <1512294624.53.0.213398074469.issue32204@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 04:53:28 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 03 Dec 2017 09:53:28 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1512294808.39.0.213398074469.issue17611@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I would point out that Serhiy posted some comments in the followup PR which aren't addressed by Neil's followup PR. They relate to tracing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 05:11:03 2017 From: report at bugs.python.org (Liran Nuna) Date: Sun, 03 Dec 2017 10:11:03 +0000 Subject: [issue32204] async/await performance is very low In-Reply-To: <1512292149.52.0.213398074469.issue32204@psf.upfronthosting.co.za> Message-ID: <1512295863.52.0.213398074469.issue32204@psf.upfronthosting.co.za> Liran Nuna added the comment: The PR is merely a finding I ran into while benchmarking. In my executions I saw a consistent ~3-5% performance increase. At my company we are attempting to migrate from asynq to asyncio but performance suffers (our servers response times nearly double). I personally ran profiles and benchmarks and noticed this tiny bottleneck which I knew how to fix, so I submitted a PR to the python project in hopes it helps. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 05:12:18 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 03 Dec 2017 10:12:18 +0000 Subject: [issue32107] Improve MAC address calculation and fix test_uuid.py In-Reply-To: <1511284223.14.0.213398074469.issue32107@psf.upfronthosting.co.za> Message-ID: <1512295938.8.0.213398074469.issue32107@psf.upfronthosting.co.za> Xavier de Gaye added the comment: 1. Before the regression made by 23df2d1304ece169d7e0dfc843dfb8026b413d9f, on the first invocation of getnode(), the returned value is cached in '_node' (a global variable) and getnode() is idempotent. 2. After 23df2d1304ece169d7e0dfc843dfb8026b413d9f, the returned value is not cached in '_node' when it is obtained through _random_getnode() and getnode() returns different values each time in that case. Not sure how you can miss that point :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 05:15:55 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Dec 2017 10:15:55 +0000 Subject: [issue32107] Improve MAC address calculation and fix test_uuid.py In-Reply-To: <1511284223.14.0.213398074469.issue32107@psf.upfronthosting.co.za> Message-ID: <1512296155.11.0.213398074469.issue32107@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, good catch! I missed this. Do you mind to create a PR Xavier? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 05:21:41 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Dec 2017 10:21:41 +0000 Subject: [issue32204] async/await performance is very low In-Reply-To: <1512292149.52.0.213398074469.issue32204@psf.upfronthosting.co.za> Message-ID: <1512296501.64.0.213398074469.issue32204@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: ~3-5% difference is a random variance. Add 1/0 in this method and repeat the benchmark. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 05:43:10 2017 From: report at bugs.python.org (Julien Palard) Date: Sun, 03 Dec 2017 10:43:10 +0000 Subject: [issue31589] Links for French documentation PDF is broken: LaTeX issue with non-ASCII characters? In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za> Message-ID: <1512297790.85.0.213398074469.issue31589@psf.upfronthosting.co.za> Julien Palard added the comment: XeTeX 0.99996 was released in march 2016, so it's not even in Ubuntu 16.04 Xenial Xerus. On docs.iad1.psf.io we're having Ubuntu 14.04 (an LTS ending around february 2019). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 05:51:13 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 03 Dec 2017 10:51:13 +0000 Subject: [issue32107] Improve MAC address calculation and fix test_uuid.py In-Reply-To: <1511284223.14.0.213398074469.issue32107@psf.upfronthosting.co.za> Message-ID: <1512298273.92.0.213398074469.issue32107@psf.upfronthosting.co.za> Xavier de Gaye added the comment: When I am the author of a regression (as I have been too many times unfortunately), I prefer to be the one that reverts the changes and I would not like someone else to do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 06:04:35 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 03 Dec 2017 11:04:35 +0000 Subject: [issue32147] improve performance of binascii.unhexlify() by using conversion table In-Reply-To: <1511784869.56.0.213398074469.issue32147@psf.upfronthosting.co.za> Message-ID: <1512299075.25.0.213398074469.issue32147@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here are the results here: - Before: $ ./python -m timeit -s "from binascii import unhexlify; b = b'aa'*2**20" "unhexlify(b)" 50 loops, best of 5: 4.37 msec per loop - After: $ ./python -m timeit -s "from binascii import unhexlify; b = b'aa'*2**20" "unhexlify(b)" 200 loops, best of 5: 1.16 msec per loop ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 06:05:09 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 03 Dec 2017 11:05:09 +0000 Subject: [issue32147] improve performance of binascii.unhexlify() by using conversion table In-Reply-To: <1511784869.56.0.213398074469.issue32147@psf.upfronthosting.co.za> Message-ID: <1512299109.32.0.213398074469.issue32147@psf.upfronthosting.co.za> Antoine Pitrou added the comment: (platform is Ubuntu 16.04, 64-bit, on a Core i5-2500K CPU) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 06:27:17 2017 From: report at bugs.python.org (jfbu) Date: Sun, 03 Dec 2017 11:27:17 +0000 Subject: [issue31589] Links for French documentation PDF is broken: LaTeX issue with non-ASCII characters? In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za> Message-ID: <1512300437.8.0.213398074469.issue31589@psf.upfronthosting.co.za> jfbu added the comment: On-going discussion at http://tug.org/pipermail/xetex/2017-December/027212.html has brought new element that polyglossia's French module is broken with xetex since TeXLive2016. We had only one problem, we now have two on our hands. Possibly Sphinx could be default use babel + French, not polyglossia + French, as the former is maintained but apparently less so the latter. I tested that TeXLive 2015 (fully updated) and test document showing the https://github.com/sphinx-doc/sphinx/issues/3546 problem now compiles fine if using latex_elements = { 'babel': r'\usepackage{babel}', } in conf.py file, to override polyglossia which is default for Sphinx with xelatex. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 06:42:15 2017 From: report at bugs.python.org (Julien Palard) Date: Sun, 03 Dec 2017 11:42:15 +0000 Subject: [issue31589] Links for French documentation PDF is broken: LaTeX issue with non-ASCII characters? In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za> Message-ID: <1512301335.9.0.213398074469.issue31589@psf.upfronthosting.co.za> Julien Palard added the comment: For me, french compile correctly with current state of cpython's conf.py and texlive-xetex 2017.20171128-1, if it helps. I tried (not enough) and fail to test locally with a texlive-xetex from 2013 (I should try with a VM maybe, Debian won't let me install packages from 2013 on my sid...). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 06:44:06 2017 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 03 Dec 2017 11:44:06 +0000 Subject: [issue32196] Rewrite plistlib with functional style In-Reply-To: <1512156516.89.0.213398074469.issue32196@psf.upfronthosting.co.za> Message-ID: <1512301446.0.0.213398074469.issue32196@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I don't have time to perform a review right now, I'm trying to get PEP 447 through review and that takes most of my available time at the moment. I'm not convinced that the speedup of plistlib is relevant for real-world code, plist files are intended as simple configuration files and tend to contain little data and should be read/written only sporadically. That said some people appear to abuse plistlib to process other files which are probably NSKeyedArchiver archives, and those can be a lot larger. But I'm opposed to explicitly supporting that use case, because the format of NSKeyedArchiver files is completely undocumented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 07:57:35 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 03 Dec 2017 12:57:35 +0000 Subject: [issue32107] Improve MAC address calculation and fix test_uuid.py In-Reply-To: <1511284223.14.0.213398074469.issue32107@psf.upfronthosting.co.za> Message-ID: <1512305855.08.0.213398074469.issue32107@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I missed it too. Serhiy, do you want to add that fix to your already open PR 4677? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 08:28:10 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 03 Dec 2017 13:28:10 +0000 Subject: [issue32205] test.pythoninfo does not print the cross-built sysconfig data Message-ID: <1512307690.33.0.213398074469.issue32205@psf.upfronthosting.co.za> New submission from Xavier de Gaye : When cross-compiling the only useful information printed by pythoninfo is the cross-built sysconfig data since everything else is related to the native python process used during the cross-build. Currently pythoninfo prints the native sysconfig data instead. ---------- components: Cross-Build messages: 307510 nosy: Alex.Willmer, vstinner, xdegaye priority: normal severity: normal stage: needs patch status: open title: test.pythoninfo does not print the cross-built sysconfig data type: behavior versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 08:33:00 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 03 Dec 2017 13:33:00 +0000 Subject: [issue32176] Zero argument super is broken in 3.6 for methods with a hacked __class__ cell In-Reply-To: <1512027575.04.0.213398074469.issue32176@psf.upfronthosting.co.za> Message-ID: <1512307980.23.0.213398074469.issue32176@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset c8f32aae0aa173e122cf4c0592caec620d0d1de9 by Nick Coghlan in branch '3.6': [3.6] bpo-32176: Set CO_NOFREE in the code object constructor (GH-4684) https://github.com/python/cpython/commit/c8f32aae0aa173e122cf4c0592caec620d0d1de9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 08:36:10 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 03 Dec 2017 13:36:10 +0000 Subject: [issue32176] Zero argument super is broken in 3.6 for methods with a hacked __class__ cell In-Reply-To: <1512027575.04.0.213398074469.issue32176@psf.upfronthosting.co.za> Message-ID: <1512308170.14.0.213398074469.issue32176@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks for the issue report! The fix will be released in 3.6.4 and 3.7.0a3 (both of which are expected to be later this month). ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 08:36:41 2017 From: report at bugs.python.org (Mario Corchero) Date: Sun, 03 Dec 2017 13:36:41 +0000 Subject: [issue32206] Run modules with pdb Message-ID: <1512308200.99.0.213398074469.issue32206@psf.upfronthosting.co.za> New submission from Mario Corchero : Since PEP 338 we can run python modules as a script via `python -m module_name` but there is no way to run pdb on those (AFAIK). The proposal is to add a new argument "-m" to the pdb module to allow users to run `python -m pdb -m my_module_name` This is especially useful when working on cli tools that use entrypoints in setup.py, as there is no other way to run them. I have a WIP here: https://github.com/mariocj89/cpython/commit/f47d1b779333657d7d87b21db841d5d3ad6cfa5c Haven't sent the PR as I am still polishing some issues. If it sounds like a good idea I'll clean it up and open the PR. ---------- components: Library (Lib) messages: 307513 nosy: mariocj89 priority: normal severity: normal status: open title: Run modules with pdb versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 08:38:42 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 03 Dec 2017 13:38:42 +0000 Subject: [issue32205] test.pythoninfo does not print the cross-built sysconfig data In-Reply-To: <1512307690.33.0.213398074469.issue32205@psf.upfronthosting.co.za> Message-ID: <1512308322.47.0.213398074469.issue32205@psf.upfronthosting.co.za> Change by Xavier de Gaye : ---------- keywords: +patch pull_requests: +4600 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 08:40:49 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 03 Dec 2017 13:40:49 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512308449.59.0.213398074469.issue19610@psf.upfronthosting.co.za> Nick Coghlan added the comment: Prohibiting strings and bytes on the grounds of "Yes they're iterable, but are more likely intended as atomic here, so treat them as ambiguous and refuse to guess" would be fine. (Although I'll also note the classifier case will already fail on upload, since they won't be valid classifiers) The only part I'm not OK with is upgrading a historically unenforced type restriction that only sometimes causes problems into an eagerly enforced one that breaks currently working code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 09:24:32 2017 From: report at bugs.python.org (jfbu) Date: Sun, 03 Dec 2017 14:24:32 +0000 Subject: [issue31589] Links for French documentation PDF is broken: LaTeX issue with non-ASCII characters? In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za> Message-ID: <1512311072.72.0.213398074469.issue31589@psf.upfronthosting.co.za> jfbu added the comment: Related https://github.com/sphinx-doc/sphinx/issues/4272 It is stated there that using babel-french in place of polyglossia-french avoids the "Improper discretionary list" xetex problem starting with xetex 0.99992 (i.e. TeXLive 2015) whereas with polyglossia-french the earliest xetex version I could test with success is 0.99996 (TL2016). But starting with TL2016, polyglossia-french as the issue https://github.com/sphinx-doc/sphinx/issues/4272 With TeXLive 2014, using babel-french does not avoid the "Improper discretionary list" xetex problem. I don't know how this maps to Debian packaging. One needs xetex 0.99992 at minimum. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 09:53:06 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 03 Dec 2017 14:53:06 +0000 Subject: [issue29519] weakref spewing exceptions during finalization when combined with multiprocessing In-Reply-To: <1486701306.85.0.363188055849.issue29519@psf.upfronthosting.co.za> Message-ID: <1512312786.42.0.213398074469.issue29519@psf.upfronthosting.co.za> INADA Naoki added the comment: It seems it is merged in 2.7.14. But I can't find this in changelog of 2.7.14. https://raw.githubusercontent.com/python/cpython/c707893f9cee870bba8364b3a06eb9cfa3b80e58/Misc/NEWS ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 10:18:02 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 03 Dec 2017 15:18:02 +0000 Subject: [issue32204] async/await performance is very low In-Reply-To: <1512292149.52.0.213398074469.issue32204@psf.upfronthosting.co.za> Message-ID: <1512314282.6.0.213398074469.issue32204@psf.upfronthosting.co.za> Yury Selivanov added the comment: In general, implementing coroutines using 'yield' expressions (not 'yield from'!) is slower than async/await, because the former approach needs a trampoline to manage the stack, whereas CPython itself handles that for 'yield from' and 'await'. I suspect that any difference in performance is not related to 'async/await' vs 'yield' performance. The attached benchmarks compare two completely different frameworks: asyncio and asynq. Both have different implementations of Task and Future and event loops primitives. Perhaps both of them schedule IO events and callbacks differently as well. asyncio could be slower because all tasks' callbacks must be scheduled through the event loop, whereas some frameworks like Twisted schedule them right away, which makes them faster in some specific micro-benchmarks. Or there might be an issue with 'asyncio.gather()', which is stressed heavily in the attached benchmarks. What I can say for sure, is that Python implementation of async/await has nothing to do with the results you observe. I suggest to take a look at 'asyncio.gather', maybe we can make it faster. Please open a new issue if you find any ways to make it faster. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 11:18:39 2017 From: report at bugs.python.org (Warwick Chapman) Date: Sun, 03 Dec 2017 16:18:39 +0000 Subject: [issue29519] weakref spewing exceptions during finalization when combined with multiprocessing In-Reply-To: <1512312786.42.0.213398074469.issue29519@psf.upfronthosting.co.za> Message-ID: Warwick Chapman added the comment: Ditto. On Sun, 03 Dec 2017 at 16:53, INADA Naoki wrote: > > INADA Naoki added the comment: > > It seems it is merged in 2.7.14. > But I can't find this in changelog of 2.7.14. > > > https://raw.githubusercontent.com/python/cpython/c707893f9cee870bba8364b3a06eb9cfa3b80e58/Misc/NEWS > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > -- -- Warwick Bruce Chapman | 083 7797 094 | http://wa.rwick.com ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 12:01:55 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sun, 03 Dec 2017 17:01:55 +0000 Subject: [issue32028] Syntactically wrong suggestions by the new custom print statement error message In-Reply-To: <1510681370.22.0.213398074469.issue32028@psf.upfronthosting.co.za> Message-ID: <1512320515.73.0.213398074469.issue32028@psf.upfronthosting.co.za> Change by Sanyam Khurana : ---------- keywords: +patch pull_requests: +4601 stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 12:20:13 2017 From: report at bugs.python.org (Eric N. Vander Weele) Date: Sun, 03 Dec 2017 17:20:13 +0000 Subject: [issue32206] Run modules with pdb In-Reply-To: <1512308200.99.0.213398074469.issue32206@psf.upfronthosting.co.za> Message-ID: <1512321613.38.0.213398074469.issue32206@psf.upfronthosting.co.za> Change by Eric N. Vander Weele : ---------- nosy: +ericvw _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 13:13:32 2017 From: report at bugs.python.org (Ned Deily) Date: Sun, 03 Dec 2017 18:13:32 +0000 Subject: [issue31392] Upgrade installers to OpenSSL 1.1.0g and 1.0.2m In-Reply-To: <1504839169.11.0.433103507115.issue31392@psf.upfronthosting.co.za> Message-ID: <1512324812.26.0.213398074469.issue31392@psf.upfronthosting.co.za> Ned Deily added the comment: 1.1.0g and 1.0.2m are out as of 2017-11-02 so both Windows and Mac installer builds for 3.7 and 3.6 should be updated. (I'll take care of the Mac ones.) ---------- assignee: ned.deily -> stage: patch review -> needs patch title: Upgrade installers to OpenSSL 1.1.0f -> Upgrade installers to OpenSSL 1.1.0g and 1.0.2m versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 13:18:27 2017 From: report at bugs.python.org (Ned Deily) Date: Sun, 03 Dec 2017 18:18:27 +0000 Subject: [issue32200] Full docs build of 3.6 and 3.7 failing since 2017-10-15 In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za> Message-ID: <1512325107.87.0.213398074469.issue32200@psf.upfronthosting.co.za> Ned Deily added the comment: OK, I'm going to close this. We can discuss further steps elsewhere. Thanks for reporting the problem, Carol, and thanks for the quick response, Julien! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: behavior -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 14:28:53 2017 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 03 Dec 2017 19:28:53 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512329333.51.0.213398074469.issue19610@psf.upfronthosting.co.za> ?ric Araujo added the comment: I am sorry this snowballed. The intent in my messages here and in my PR review was to exchange a late, unfriendly traceback with a clear, early message, but only for package authors. I forgot that a Python 3.7 could execute an invalid setup.py from an existing tarball, as Neil pointed with the pip install exifread example. Even if these packages get PRs to build wheels, it?s still bad to break existing sdists. +1 to reverting the patch, +1 to reverting the breakage and also fixing the original problem with a warning and explicit conversion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 15:12:15 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Dec 2017 20:12:15 +0000 Subject: [issue32137] Stack overflow in repr of deeply nested dicts In-Reply-To: <1511686410.56.0.213398074469.issue32137@psf.upfronthosting.co.za> Message-ID: <1512331935.45.0.213398074469.issue32137@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 1fb72d2ad243c965d4432b4e93884064001a2607 by Serhiy Storchaka in branch 'master': bpo-32137: The repr of deeply nested dict now raises a RecursionError (#4570) https://github.com/python/cpython/commit/1fb72d2ad243c965d4432b4e93884064001a2607 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 15:12:24 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Dec 2017 20:12:24 +0000 Subject: [issue32137] Stack overflow in repr of deeply nested dicts In-Reply-To: <1511686410.56.0.213398074469.issue32137@psf.upfronthosting.co.za> Message-ID: <1512331944.32.0.213398074469.issue32137@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4602 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 15:16:23 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Dec 2017 20:16:23 +0000 Subject: [issue31619] Strange error when convert hexadecimal with underscores to int In-Reply-To: <1506608047.28.0.466225441844.issue31619@psf.upfronthosting.co.za> Message-ID: <1512332183.56.0.213398074469.issue31619@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 29ba688034fc4eef0693b86002cf7bee55d692af by Serhiy Storchaka in branch 'master': bpo-31619: Fixed integer overflow in converting huge strings to int. (#3884) https://github.com/python/cpython/commit/29ba688034fc4eef0693b86002cf7bee55d692af ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 15:17:33 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Dec 2017 20:17:33 +0000 Subject: [issue31619] Strange error when convert hexadecimal with underscores to int In-Reply-To: <1506608047.28.0.466225441844.issue31619@psf.upfronthosting.co.za> Message-ID: <1512332253.16.0.213398074469.issue31619@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4603 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 15:57:06 2017 From: report at bugs.python.org (Decorater) Date: Sun, 03 Dec 2017 20:57:06 +0000 Subject: [issue25711] Rewrite zipimport from scratch In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za> Message-ID: <1512334626.93.0.213398074469.issue25711@psf.upfronthosting.co.za> Decorater added the comment: Alright, just wanted to make sure because I did not want to have something break when loading up the entire standard library from an zip file with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 16:16:33 2017 From: report at bugs.python.org (Ed Schouten) Date: Sun, 03 Dec 2017 21:16:33 +0000 Subject: [issue28503] [Patch] '_crypt' module: fix implicit declaration of crypt(), use crypt_r() where available In-Reply-To: <1477122775.81.0.204871394378.issue28503@psf.upfronthosting.co.za> Message-ID: <1512335793.19.0.213398074469.issue28503@psf.upfronthosting.co.za> Ed Schouten added the comment: Ah, you folks switched to Git + Github in the mean time. Nice! I've just sent this pull request: https://github.com/python/cpython/pull/4691 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 16:17:32 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Dec 2017 21:17:32 +0000 Subject: [issue28503] [Patch] '_crypt' module: fix implicit declaration of crypt(), use crypt_r() where available In-Reply-To: <1477122775.81.0.204871394378.issue28503@psf.upfronthosting.co.za> Message-ID: <1512335852.82.0.213398074469.issue28503@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4604 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 16:27:23 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Dec 2017 21:27:23 +0000 Subject: [issue31619] Strange error when convert hexadecimal with underscores to int In-Reply-To: <1506608047.28.0.466225441844.issue31619@psf.upfronthosting.co.za> Message-ID: <1512336443.6.0.213398074469.issue31619@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 30a6bc842945e3e9c9c7db887ab495c428ec7074 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6': bpo-31619: Fixed integer overflow in converting huge strings to int. (GH-3884) (#4690) https://github.com/python/cpython/commit/30a6bc842945e3e9c9c7db887ab495c428ec7074 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 16:28:05 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 03 Dec 2017 21:28:05 +0000 Subject: [issue31619] Strange error when convert hexadecimal with underscores to int In-Reply-To: <1506608047.28.0.466225441844.issue31619@psf.upfronthosting.co.za> Message-ID: <1512336485.2.0.213398074469.issue31619@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 17:51:59 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 03 Dec 2017 22:51:59 +0000 Subject: [issue32146] multiprocessing freeze_support needed outside win32 In-Reply-To: <1511778835.66.0.213398074469.issue32146@psf.upfronthosting.co.za> Message-ID: <1512341519.95.0.213398074469.issue32146@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you for reporting this. Would you like to submit a PR? ---------- nosy: +davin, pitrou stage: -> needs patch versions: -Python 2.7, Python 3.4, Python 3.5, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 18:51:43 2017 From: report at bugs.python.org (R. David Murray) Date: Sun, 03 Dec 2017 23:51:43 +0000 Subject: [issue27240] 'UnstructuredTokenList' object has no attribute '_fold_as_ew' In-Reply-To: <1465208759.2.0.0752415166741.issue27240@psf.upfronthosting.co.za> Message-ID: <1512345103.29.0.213398074469.issue27240@psf.upfronthosting.co.za> R. David Murray added the comment: New changeset 85d5c18c9d83a1d54eecc4c2ad4dce63194107c6 by R. David Murray in branch 'master': bpo-27240 Rewrite the email header folding algorithm. (#3488) https://github.com/python/cpython/commit/85d5c18c9d83a1d54eecc4c2ad4dce63194107c6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 18:53:07 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Dec 2017 23:53:07 +0000 Subject: [issue27240] 'UnstructuredTokenList' object has no attribute '_fold_as_ew' In-Reply-To: <1465208759.2.0.0752415166741.issue27240@psf.upfronthosting.co.za> Message-ID: <1512345187.61.0.213398074469.issue27240@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4605 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 19:25:16 2017 From: report at bugs.python.org (BoppreH) Date: Mon, 04 Dec 2017 00:25:16 +0000 Subject: [issue30213] ZipFile from 'a'ppend-mode file generates invalid zip In-Reply-To: <1493515995.55.0.223691905377.issue30213@psf.upfronthosting.co.za> Message-ID: <1512347116.02.0.213398074469.issue30213@psf.upfronthosting.co.za> BoppreH added the comment: I'm not sure this is a duplicate of issue29094. That issue includes random data at the start of the file, while this issue uses the 'ab' mode solely for a creating the file if it doesn't exist (and thus is either empty or already a valid zip file). It's not clear to me why 'wb' should work but not 'ab' if the file was empty/missing to begin with. [Windows 10, Python 3.6.3, 64 bit] still has the same problem. Here's a more complete test case, starting with no existing files: from zipfile import ZipFile # Append mode: v with open('file.zip', 'ab') as f: with ZipFile(f, 'a') as zip: zip.writestr('file.txt', 'contents') with open('file.zip', 'rb') as f: with ZipFile(f, 'r') as zip: print(zip.read('file.txt')) # Fails with "zipfile.BadZipFile: Bad magic number for file header" # Write mode: v with open('file.zip', 'wb') as f: with ZipFile(f, 'a') as zip: zip.writestr('file.txt', 'contents') with open('file.zip', 'rb') as f: with ZipFile(f, 'r') as zip: print(zip.read('file.txt')) # Works. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 19:46:25 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Dec 2017 00:46:25 +0000 Subject: [issue27240] 'UnstructuredTokenList' object has no attribute '_fold_as_ew' In-Reply-To: <1465208759.2.0.0752415166741.issue27240@psf.upfronthosting.co.za> Message-ID: <1512348385.63.0.213398074469.issue27240@psf.upfronthosting.co.za> R. David Murray added the comment: New changeset a87ba60fe56ae2ebe80ab9ada6d280a6a1f3d552 by R. David Murray (Miss Islington (bot)) in branch '3.6': bpo-27240 Rewrite the email header folding algorithm. (GH-3488) (#4693) https://github.com/python/cpython/commit/a87ba60fe56ae2ebe80ab9ada6d280a6a1f3d552 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 19:50:36 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Dec 2017 00:50:36 +0000 Subject: [issue30788] email.policy.SMTP.fold() issue for long filenames with spaces In-Reply-To: <1498593521.18.0.236128551176.issue30788@psf.upfronthosting.co.za> Message-ID: <1512348636.67.0.213398074469.issue30788@psf.upfronthosting.co.za> R. David Murray added the comment: The PR has been committed. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 19:51:27 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Dec 2017 00:51:27 +0000 Subject: =?utf-8?q?=5Bissue31831=5D_EmailMessage=2Eadd=5Fattachment=28filename=3D?= =?utf-8?q?=22long_or_sp=C3=A9cial=22=29_crashes_or_produces_invalid_outpu?= =?utf-8?q?t?= In-Reply-To: <1508538176.94.0.213398074469.issue31831@psf.upfronthosting.co.za> Message-ID: <1512348687.81.0.213398074469.issue31831@psf.upfronthosting.co.za> R. David Murray added the comment: The PR has been committed. ---------- resolution: -> fixed stage: -> resolved status: open -> closed type: crash -> behavior versions: -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 19:53:35 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Dec 2017 00:53:35 +0000 Subject: [issue32182] Infinite recursion in email.message.as_string() In-Reply-To: <1512053940.47.0.213398074469.issue32182@psf.upfronthosting.co.za> Message-ID: <1512348815.55.0.213398074469.issue32182@psf.upfronthosting.co.za> R. David Murray added the comment: I checked, and your example works correctly with the patch applied. I've committed the PR. Let me know if you find any other issues (there are several open issues with exactly how headers are wrapped, but I don't think there are any open where serialization fails completely.) ---------- resolution: -> fixed stage: -> resolved status: open -> closed type: crash -> behavior versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 20:47:10 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Dec 2017 01:47:10 +0000 Subject: [issue32207] IDLE: run's tk update adds extra traceback on callback error Message-ID: <1512352029.95.0.213398074469.issue32207@psf.upfronthosting.co.za> New submission from Terry J. Reedy : import tkinter as tk root = tk.Tk() def bad(): print(a, 'bad') def good(): print('good') root.after(1000, bad) root.after(1500, good) root.mainloop() # Correctly gives this traceback and output: Exception in Tkinter callback Traceback (most recent call last): File "C:\Programs\Python37\lib\tkinter\__init__.py", line 1699, in __call__ return self.func(*args) File "C:\Programs\Python37\lib\tkinter\__init__.py", line 745, in callit func(*args) File "F:\Python\a\tem2.py", line 13, in bad def bad(): print(a, 'bad') NameError: name 'a' is not defined good >>> ==================================== Remove or comment-out the blocking 'root.mainloop()' call and run the result from an IDLE editor. The callbacks are still called because after user code is run, run.py calls tcl.update in a loop nominally 20 x per second. This allows developers to interact with a 'live' gui by entering statements in the shell at '>>>' prompts. The result is this. ------------- >>> Exception in Tkinter callback Traceback (most recent call last): File "C:\Programs\Python37\lib\idlelib\run.py", line 137, in main seq, request = rpc.request_queue.get(block=True, timeout=0.05) File "C:\Programs\Python37\lib\queue.py", line 169, in get raise Empty queue.Empty During handling of the above exception, another exception occurred: Traceback (most recent call last): -------------- The relevant code in run.py was written before callback chaining. try: seq, request = rpc.request_queue.get(block=True, timeout=0.05) except queue.Empty: handle_tk_events() continue Experiments with normal exceptions in a shell suggest that wrapping handle_tk_events in try:except and re-raising any exception 'from None' should work. try: handle_tk_events() except BaseException as e: raise e from None However, it appears that callback errors resulting from handle_tk_events() are not being caught here. (print('message') and 1/0 before 'raise' have no visible effect.) I will investigate more later. ---------- assignee: terry.reedy components: IDLE messages: 307534 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: IDLE: run's tk update adds extra traceback on callback error type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 20:47:39 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Dec 2017 01:47:39 +0000 Subject: [issue32207] IDLE: run's tk update adds context traceback on callback error In-Reply-To: <1512352029.95.0.213398074469.issue32207@psf.upfronthosting.co.za> Message-ID: <1512352059.17.0.213398074469.issue32207@psf.upfronthosting.co.za> Change by Terry J. Reedy : ---------- title: IDLE: run's tk update adds extra traceback on callback error -> IDLE: run's tk update adds context traceback on callback error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 22:11:49 2017 From: report at bugs.python.org (TaoQingyun) Date: Mon, 04 Dec 2017 03:11:49 +0000 Subject: [issue30862] parent logger should also check the level In-Reply-To: <1499303463.12.0.427912984431.issue30862@psf.upfronthosting.co.za> Message-ID: <1512357109.9.0.213398074469.issue30862@psf.upfronthosting.co.za> TaoQingyun <845767657 at qq.com> added the comment: Maybe I misunderstand. At least the basicConfig should also set the level of the handler that it created. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 22:18:00 2017 From: report at bugs.python.org (Garrett Berg) Date: Mon, 04 Dec 2017 03:18:00 +0000 Subject: [issue32208] Improve semaphore docmentation Message-ID: <1512357480.91.0.213398074469.issue32208@psf.upfronthosting.co.za> New submission from Garrett Berg : The definition of threading.Semaphore is confusing (for all versions of python docs) https://docs.python.org/2/library/threading.html#semaphore-objects acquire([blocking]) It currently states the following: > When invoked without arguments: if the internal counter is larger than zero on entry, decrement it by one and return immediately. If it is zero on entry, block, waiting until some other thread has called release() to make it larger than zero. This is done with proper interlocking so that if multiple acquire() calls are blocked, release() will wake exactly one of them up. The implementation may pick one at random, so the order in which blocked threads are awakened should not be relied on. There is no return value in this case. However, after testing it myself I found that is missing a crutial detail. Let's step through the docs: > If the internal counter is larger than zero on entry, decrement it by one and return immediately. This is exactly accurate and should stay the same > If it is zero on entry, block, waiting until some other thread has called release() to make it larger than zero. This is done with proper interlocking so that if multiple acquire() calls are blocked, release() will wake exactly one of them up. The implementation may pick one at random, so the order in which blocked threads are awakened should not be relied on. There is no return value in this case. This is extremely confusing and I would like to rewrite it as follows: > If it is zero on entry block until awoken by a call to ``release()``. Once awoken, decrement the counter by 1. Exactly one thread will be awoken by a call to ``release()``. The order in which threads are awoken should not be relied on. ``None`` is returned in this case. The major thing that was missing was that the **counter is decremented after the thread is awoken**. For instance, this code *generally* passes assertions: ``` #!/usr/bin/python2 import time from threading import Thread, Semaphore s = Semaphore(1) def doit(): s.acquire() print("did it") th1 = Thread(target=doit) th1.start() th2 = Thread(target=doit) th2.start() time.sleep(0.2) assert not th1.is_alive() assert th2.is_alive() s.release() assert s._value == 1, "The value is increased to 1 MOMENTARILY" start = time.time() while sum([th2.is_alive(), th3.is_alive()]) > 1: assert time.time() - start < 0.5 time.sleep(0.1) assert s._value == 0, "when an aquire is awoken, THEN _value is decremented" ``` Obviously this behavior should not be relied on, but it gives a picture of what seems to be happening under the hood. I came across this while trying to work through "The Little Book of Semaphores". After reading these docs I mistakingly thought that they didn't match Djestra's original semaphore since the values could not be negative. I now realize that while they may not match that implementation under the hood, they match it perfectly in practice since if you (for instance) ``acquire()`` 5 times and then ``release()`` 5 times the value of Semaphore._value will be the same when all is said and done. ---------- components: Library (Lib) messages: 307536 nosy: Garrett Berg priority: normal severity: normal status: open title: Improve semaphore docmentation type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 22:20:46 2017 From: report at bugs.python.org (Garrett Berg) Date: Mon, 04 Dec 2017 03:20:46 +0000 Subject: [issue32208] Improve semaphore docmentation In-Reply-To: <1512357480.91.0.213398074469.issue32208@psf.upfronthosting.co.za> Message-ID: <1512357646.07.0.213398074469.issue32208@psf.upfronthosting.co.za> Garrett Berg added the comment: Also, is "The order in which threads are awoken should not be relied on" actually true? Would it not be up to the OS specific scheduler? For instance, wouldn't the POSIX scheduler use a priority queue of some kind? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 22:23:24 2017 From: report at bugs.python.org (Garrett Berg) Date: Mon, 04 Dec 2017 03:23:24 +0000 Subject: [issue32208] Improve semaphore docmentation In-Reply-To: <1512357480.91.0.213398074469.issue32208@psf.upfronthosting.co.za> Message-ID: <1512357804.18.0.213398074469.issue32208@psf.upfronthosting.co.za> Garrett Berg added the comment: It may be desirable to change: > Once awoken, decrement the counter by 1. to > Once awoke, decrement the counter (which is guaranteed to be positive) by 1. Although this could be considered obvious since the counter can never go below zero. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 22:37:11 2017 From: report at bugs.python.org (Connor W Fitzgerald) Date: Mon, 04 Dec 2017 03:37:11 +0000 Subject: [issue32209] Crash in set_traverse Within the Garbage Collector's collect_generations() Message-ID: <1512358631.67.0.213398074469.issue32209@psf.upfronthosting.co.za> New submission from Connor W Fitzgerald : This is my first time submitting a bug report, so forgive me if I miss on important information. I am writing code that makes heavy use of sets (8GB+ of them). It segfaults semi-randomly during the processing of them. I've used versions 3.5.3, 3.6.3, and 3.7.0rc2. I debugged the process and came across the error in object/setobject.c:742. I don't really know what information to provide here but this is the best I can do. Error: Unhandled exception thrown: read access violation. entry->**key** was 0x8000. Stack Trace: python37.dll!set_traverse(PySetObject * so, int(*)(_object *, void *) visit, void * arg) Line 742 python37.dll!subtract_refs(_gc_head * containers) Line 295 python37.dll!collect(int generation, __int64 * n_collected, __int64 * n_uncollectable, int nofail) Line 862 python37.dll!collect_with_callback(int generation) Line 1027 python37.dll!collect_generations() Line 1049 python37.dll!PyType_GenericAlloc(_typeobject * type, __int64 nitems) Line 969 [Inline Frame] python37.dll!make_new_set(_typeobject *) Line 1055 python37.dll!set_new(_typeobject * type, _object * args, _object * kwds) Line 1127 python37.dll!type_call(_typeobject * type, _object * args, _object * kwds) Line 928 python37.dll!_PyObject_FastCallKeywords(_object * callable, _object * * stack, __int64 nargs, _object * kwnames) Line 199 python37.dll!call_function(_object * * * pp_stack, __int64 oparg, _object * kwnames) Line 4705 python37.dll!_PyEval_EvalFrameDefault(_frame * f, int throwflag) Line 3182 [Inline Frame] python37.dll!PyEval_EvalFrameEx(_frame *) Line 549 python37.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, __int64 argcount, _object * * kwnames, _object * * kwargs, __int64 kwcount, int kwstep, _object * * defs, __int64 defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4011 python37.dll!_PyFunction_FastCallDict(_object * func, _object * * args, __int64 nargs, _object * kwargs) Line 376 [Inline Frame] python37.dll!PyEval_CallObjectWithKeywords(_object *) Line 819 python37.dll!defdict_missing(defdictobject * dd, _object * key) Line 1993 python37.dll!_PyMethodDef_RawFastCallDict(PyMethodDef * method, _object * self, _object * * args, __int64 nargs, _object * kwargs) Line 496 [Inline Frame] python37.dll!_PyCFunction_FastCallDict(_object *) Line 580 python37.dll!_PyObject_FastCallDict(_object * callable, _object * * args, __int64 nargs, _object * kwargs) Line 101 [Inline Frame] python37.dll!object_vacall(_object * callable, char *) Line 1194 python37.dll!PyObject_CallFunctionObjArgs(_object * callable, ...) Line 1259 python37.dll!dict_subscript(PyDictObject * mp, _object * key) Line 1984 python37.dll!_PyEval_EvalFrameDefault(_frame * f, int throwflag) Line 1316 [Inline Frame] python37.dll!PyEval_EvalFrameEx(_frame *) Line 549 python37.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, __int64 argcount, _object * * kwnames, _object * * kwargs, __int64 kwcount, int kwstep, _object * * defs, __int64 defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4011 [Inline Frame] python37.dll!_PyFunction_FastCallKeywords(_object * stack, _object * *) Line 433 python37.dll!call_function(_object * * * pp_stack, __int64 oparg, _object * kwnames) Line 4703 python37.dll!_PyEval_EvalFrameDefault(_frame * f, int throwflag) Line 3182 [Inline Frame] python37.dll!PyEval_EvalFrameEx(_frame *) Line 549 python37.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, __int64 argcount, _object * * kwnames, _object * * kwargs, __int64 kwcount, int kwstep, _object * * defs, __int64 defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4011 python37.dll!PyEval_EvalCodeEx(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure) Line 4045 python37.dll!PyEval_EvalCode(_object * co, _object * globals, _object * locals) Line 532 python37.dll!run_mod(_mod * mod, _object * filename, _object * globals, _object * locals, PyCompilerFlags * flags, _arena * arena) Line 987 python37.dll!PyRun_FileExFlags(_iobuf * fp, const char * filename_str, int start, _object * globals, _object * locals, int closeit, PyCompilerFlags * flags) Line 939 python37.dll!PyRun_SimpleFileExFlags(_iobuf * fp, const char * filename, int closeit, PyCompilerFlags * flags) Line 402 python37.dll!PyRun_AnyFileExFlags(_iobuf * fp, const char * filename, int closeit, PyCompilerFlags * flags) Line 84 python37.dll!run_file(_iobuf * fp, const wchar_t * filename, PyCompilerFlags * p_cf) Line 340 python37.dll!Py_Main(int argc, wchar_t * * argv) Line 894 [Inline Frame] python.exe!invoke_main() Line 79 python.exe!__scrt_common_main_seh() Line 253 kernel32.dll!0000000077a959cd() ntdll.dll!0000000077bca561() I'm not sure what I can do to reproduce this because I don't even know what line of code my program was running before it segfaulted. I'm using sqlite3, json, and pickle as my main extensions. Nothing outside of what is provided in the standard library is used. If you need any more information, I'll gladly provide it. ---------- components: Interpreter Core messages: 307539 nosy: connorwfitzgerald priority: normal severity: normal status: open title: Crash in set_traverse Within the Garbage Collector's collect_generations() type: crash versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 3 22:43:40 2017 From: report at bugs.python.org (ppperry) Date: Mon, 04 Dec 2017 03:43:40 +0000 Subject: [issue32140] IDLE debugger fails with non-trivial __new__ super call In-Reply-To: <1511696773.06.0.213398074469.issue32140@psf.upfronthosting.co.za> Message-ID: <1512359020.25.0.213398074469.issue32140@psf.upfronthosting.co.za> ppperry added the comment: Simplified reproducer for same bug without any imports: class BadRepr: def __repr__(self): 1/0 def broken(): x=BadRepr() x=x #filler line for debugger In this case, the problematic BadRepr object in the "broken" function explictly has a broken __repr__, but the uninitialized Fraction object in the "__new__" function of the Fraction class has a similarly broken __repr__ ---------- nosy: +ppperry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 01:07:52 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Dec 2017 06:07:52 +0000 Subject: [issue32208] Improve semaphore documentation In-Reply-To: <1512357480.91.0.213398074469.issue32208@psf.upfronthosting.co.za> Message-ID: <1512367672.01.0.213398074469.issue32208@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- title: Improve semaphore docmentation -> Improve semaphore documentation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 01:17:05 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Dec 2017 06:17:05 +0000 Subject: [issue32207] IDLE: run's tk update adds context traceback on callback error In-Reply-To: <1512352029.95.0.213398074469.issue32207@psf.upfronthosting.co.za> Message-ID: <1512368225.66.0.213398074469.issue32207@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: try: seq, request = rpc.request_queue.get(block=True, timeout=0.05) except queue.Empty: request = None if request is None: handle_tk_events() continue ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 02:29:43 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Dec 2017 07:29:43 +0000 Subject: [issue30213] ZipFile from 'a'ppend-mode file generates invalid zip In-Reply-To: <1493515995.55.0.223691905377.issue30213@psf.upfronthosting.co.za> Message-ID: <1512372583.44.0.213398074469.issue30213@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The problem is that seek() doesn't work properly with files opened in append mode. with open('file', 'ab') as f: f.write(b'abcd') f.seek(0) f.write(b'efgh') f.flush() with open('file', 'rb') as f: print(f.read()) The result is b'abcdefgh' instead of expected b'efgh'. ---------- resolution: duplicate -> stage: resolved -> status: closed -> open superseder: Regression in zipfile writing in 2.7.13 -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 02:33:52 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Dec 2017 07:33:52 +0000 Subject: [issue30213] ZipFile from 'a'ppend-mode file generates invalid zip In-Reply-To: <1493515995.55.0.223691905377.issue30213@psf.upfronthosting.co.za> Message-ID: <1512372832.34.0.213398074469.issue30213@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This may be related to issue18876 or issue20082. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 04:39:35 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 04 Dec 2017 09:39:35 +0000 Subject: [issue32210] Add the versions of the Android SDK and NDK to test.pythoninfo Message-ID: <1512380375.09.0.213398074469.issue32210@psf.upfronthosting.co.za> New submission from Xavier de Gaye : * The NDK version can be obtained by parsing the file $ANDROID_NDK_ROOT/source.properties. * The versions of the SDK build-tools, emulator and platform-tools packages as well as those of the system images can be obtained by parsing the output of "$ANDROID_SDK_ROOT/tools/bin/sdkmanager --list". ---------- components: Cross-Build messages: 307544 nosy: Alex.Willmer, vstinner, xdegaye priority: normal severity: normal stage: needs patch status: open title: Add the versions of the Android SDK and NDK to test.pythoninfo type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 04:40:10 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Dec 2017 09:40:10 +0000 Subject: [issue32197] Compiling against master branch fails; error: expected expression SET_DECODE_ERROR In-Reply-To: <1512219000.84.0.213398074469.issue32197@psf.upfronthosting.co.za> Message-ID: <1512380410.43.0.213398074469.issue32197@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4606 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 04:40:10 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Dec 2017 09:40:10 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512380410.54.0.00913614298617.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4607 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 04:51:59 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Dec 2017 09:51:59 +0000 Subject: [issue32107] Improve MAC address calculation and fix test_uuid.py In-Reply-To: <1511284223.14.0.213398074469.issue32107@psf.upfronthosting.co.za> Message-ID: <1512381119.33.0.213398074469.issue32107@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset e69fbb6a560a02d0587b9075afd338a1e9073af0 by Serhiy Storchaka in branch 'master': Fix a regression in uuid added in bpo-32107. (#4677) https://github.com/python/cpython/commit/e69fbb6a560a02d0587b9075afd338a1e9073af0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 05:08:06 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Dec 2017 10:08:06 +0000 Subject: [issue32211] Document the bug in re.findall() and re.finditer() in 2.7 and 3.6 Message-ID: <1512382086.34.0.213398074469.issue32211@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : >>> re.findall(r'^|\w+', 'two words') ['', 'wo', 'words'] Seems the current behavior was documented incorrectly in issue732120. It will be fixed in 3.7 (see issue1647489, issue25054), but I hesitate to backport the fix to 3.6 and 2.7 because this can break the user code. For example: In Python 3.6: >>> list(re.finditer(r'(?m)^\s*?$', 'foo\n\n\nbar')) [<_sre.SRE_Match object; span=(4, 4), match=''>, <_sre.SRE_Match object; span=(5, 5), match=''>] In Python 3.7: >>> list(re.finditer(r'(?m)^\s*?$', 'foo\n\n\nbar')) [, , ] (This is a real pattern used in the docstring module, but with re.sub()). The proposed PR documents the current weird behavior in 2.7 and 3.6. ---------- assignee: docs at python components: Documentation, Regular Expressions messages: 307546 nosy: docs at python, ezio.melotti, mrabarnett, rhettinger, serhiy.storchaka priority: normal severity: normal status: open title: Document the bug in re.findall() and re.finditer() in 2.7 and 3.6 type: enhancement versions: Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 05:12:27 2017 From: report at bugs.python.org (Michal Plichta) Date: Mon, 04 Dec 2017 10:12:27 +0000 Subject: [issue32212] few discrepancy between source and docs in logging Message-ID: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za> New submission from Michal Plichta : my code: logger = logging.getLogger(name) logger.setLevel(level=logging.DEBUG) ... stream_handler = logging.StreamHandler(stream=stdout) stream_handler.setLevel(logging_level) stream_handler.setFormatter(fmt=formatter) and mypy-0.550 complains about fmt vs. form parameter in setFormatter method and level vs. lvl in setLevel method. ta_cc/cc_logger.py: note: In function "_get_stream_handler": ta_cc/cc_logger.py:34: error: Unexpected keyword argument "fmt" for "setFormatter" of "Handler" /usr/local/lib/mypy/typeshed/stdlib/2and3/logging/__init__.pyi:147: note: "setFormatter" of "Handler" defined here ta_cc/cc_logger.py:109: error: Unexpected keyword argument "level" for "setLevel" of "Logger" /usr/local/lib/mypy/typeshed/stdlib/2and3/logging/__init__.pyi:46: note: "setLevel" of "Logger" defined here I see in online documentation that indeed there are lvl and form parameters for all 2.7, 3.5 and 3.6 python version. However my Pycharm suggest level and fmt for all my installed python interpreters. I use: Pycharm-2017.3 Python 2.7.12 Python 3.5.2 Python 3.6.3 This is copy of my issue of: https://github.com/python/typeshed/issues/1619 ---------- assignee: docs at python components: Documentation messages: 307547 nosy: Michal Plichta, docs at python priority: normal severity: normal status: open title: few discrepancy between source and docs in logging versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 05:12:51 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Dec 2017 10:12:51 +0000 Subject: [issue32211] Document the bug in re.findall() and re.finditer() in 2.7 and 3.6 In-Reply-To: <1512382086.34.0.213398074469.issue32211@psf.upfronthosting.co.za> Message-ID: <1512382371.69.0.213398074469.issue32211@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +4608 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 06:27:10 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 04 Dec 2017 11:27:10 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512386830.97.0.213398074469.issue32199@psf.upfronthosting.co.za> Change by Xavier de Gaye : ---------- keywords: +patch pull_requests: +4609 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 06:46:34 2017 From: report at bugs.python.org (Mark Shannon) Date: Mon, 04 Dec 2017 11:46:34 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1512387994.23.0.213398074469.issue17611@psf.upfronthosting.co.za> Mark Shannon added the comment: I plan to resurrect my original design over the Christmas break. The reason that I want to get back to the original design is its consistency and relative simplicity. Duplicating the finally block for every exit from the try body might sound expensive, but it only increases the size of the bytecode by an estimated 0.4%. Using statement counts as a proxy for bytecodes, I ran the code query https://lgtm.com/query/1505907426052/ over a range of open stack and other large projects. The size increase is in the range 0.26% to 0.44% (Note that the statement counts include dependencies) I plan to start from https://github.com/python/cpython/pull/2827/commits/693b9398b5fd202fa5864f9cc76fa1bc7f84f62e as that adheres to the original design, but cleans up the code. Antoine that is on your branch, are you OK with me appropriating it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 06:50:46 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 04 Dec 2017 11:50:46 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1512387994.23.0.213398074469.issue17611@psf.upfronthosting.co.za> Message-ID: <2cfa7124-e65a-70fe-955f-c557657f556c@free.fr> Antoine Pitrou added the comment: Le 04/12/2017 ? 12:46, Mark Shannon a ?crit?: > > I plan to start from > https://github.com/python/cpython/pull/2827/commits/693b9398b5fd202fa5864f9cc76fa1bc7f84f62e > as that adheres to the original design, but cleans up the code. > Antoine that is on your branch, are you OK with me appropriating it? Definitely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 06:51:47 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Dec 2017 11:51:47 +0000 Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za> Message-ID: <1512388307.32.0.213398074469.issue20891@psf.upfronthosting.co.za> STINNER Victor added the comment: "./Program/_testembed.exe bpo20891" fails randomly on macOS: --- macbook:master haypo$ while true; do ./Programs/_testembed bpo20891 ||break; date; done Lun 4 d?c 2017 12:46:34 CET Lun 4 d?c 2017 12:46:34 CET Lun 4 d?c 2017 12:46:34 CET Fatal Python error: PyEval_SaveThread: NULL tstate Current thread 0x00007fffa5dff3c0 (most recent call first): Abort trap: 6 --- In test_bpo20891() of Program/_testembed.c, Py_BEGIN_ALLOW_THREADS calls PyEval_SaveThread() which fails with a fatal error: PyThreadState *tstate = PyThreadState_Swap(NULL); if (tstate == NULL) Py_FatalError("PyEval_SaveThread: NULL tstate"); <~~~ HERE I'm not sure that it's safe to create the GIL in PyGILState_Ensure() in a "non-Python" thread, while the main thread (which is a Python thread) "is running". I found a working fix: call PyEval_InitThreads() in PyThread_start_new_thread(). So the GIL is created as soon as a second thread is spawned. The GIL cannot be created anymore while two threads are running. At least, with the "python" binary. It doesn't fix the issue if a thread is not spawned by Python, but this thread calls PyGILState_Ensure(). Maybe we need to better document how threads have to be initialized to prevent this race condition / bug? ---------- nosy: +eric.snow, ncoghlan resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 06:52:38 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 04 Dec 2017 11:52:38 +0000 Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za> Message-ID: <1512388358.52.0.213398074469.issue20891@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Why not *always* call PyEval_InitThreads() at interpreter initialization? Are there any downsides? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 06:59:07 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Dec 2017 11:59:07 +0000 Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za> Message-ID: <1512388747.52.0.213398074469.issue20891@psf.upfronthosting.co.za> STINNER Victor added the comment: > Why not *always* call PyEval_InitThreads() at interpreter initialization? Are there any downsides? The code is quite old: commit 1984f1e1c6306d4e8073c28d2395638f80ea509b Author: Guido van Rossum Date: Tue Aug 4 12:41:02 1992 +0000 * Makefile adapted to changes below. * split pythonmain.c in two: most stuff goes to pythonrun.c, in the library. * new optional built-in threadmodule.c, build upon Sjoerd's thread.{c,h}. * new module from Sjoerd: mmmodule.c (dynamically loaded). * new module from Sjoerd: sv (svgen.py, svmodule.c.proto). * new files thread.{c,h} (from Sjoerd). * new xxmodule.c (example only). * myselect.h: bzero -> memset * select.c: bzero -> memset; removed global variable (...) +void +init_save_thread() +{ +#ifdef USE_THREAD + if (interpreter_lock) + fatal("2nd call to init_save_thread"); + interpreter_lock = allocate_lock(); + acquire_lock(interpreter_lock, 1); +#endif +} +#endif Current version of the code: void PyEval_InitThreads(void) { if (gil_created()) return; create_gil(); take_gil(PyThreadState_GET()); _PyRuntime.ceval.pending.main_thread = PyThread_get_thread_ident(); if (!_PyRuntime.ceval.pending.lock) _PyRuntime.ceval.pending.lock = PyThread_allocate_lock(); } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 07:05:04 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Dec 2017 12:05:04 +0000 Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za> Message-ID: <1512389104.24.0.213398074469.issue20891@psf.upfronthosting.co.za> STINNER Victor added the comment: The "if (gil_created())" check can be found in the Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS macros which call PyEval_SaveThread() / PyEval_RestoreThread(): PyThreadState * PyEval_SaveThread(void) { PyThreadState *tstate = PyThreadState_Swap(NULL); if (tstate == NULL) Py_FatalError("PyEval_SaveThread: NULL tstate"); if (gil_created()) <~~~~ HERE drop_gil(tstate); return tstate; } void PyEval_RestoreThread(PyThreadState *tstate) { if (tstate == NULL) Py_FatalError("PyEval_RestoreThread: NULL tstate"); if (gil_created()) { <~~~~ HERE int err = errno; take_gil(tstate); /* _Py_Finalizing is protected by the GIL */ if (_Py_IsFinalizing() && !_Py_CURRENTLY_FINALIZING(tstate)) { drop_gil(tstate); PyThread_exit_thread(); Py_UNREACHABLE(); } errno = err; } PyThreadState_Swap(tstate); } I guess that the intent of dynamically created GIL is to reduce the "overhead" of the GIL when 100% of the code is run in single thread. I understand that this potential overhead must be measured to decide if it's ok to always create the GIL. This bug was reported once in 2014, then Marcin Kasperski asked for an update last month: 3 years later. It's not a common bug impacting many users. So if there is an overhead, I'm not sure that it's a good idea to change Python to fix this rare use case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 07:14:31 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 04 Dec 2017 12:14:31 +0000 Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za> Message-ID: <1512389671.82.0.213398074469.issue20891@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I guess that the intent of dynamically created GIL is to reduce the "overhead" of the GIL when 100% of the code is run in single thread. I'm not sure it is ok to guess here. The original code was written in 1992, when system threading APIs were buggy and not always available. Also the original GIL logic released the lock every N opcodes, which is a fragile heuristic. The current GIL shouldn't have any visible performance cost in single-threaded mode, and in even in multi-threaded mode it's been a long time since anyone complained about a real-world performance degradation due to the GIL's overhead. Perhaps Guido remembers the original rationale? > This bug was reported once in 2014, then Marcin Kasperski asked for an update last month: 3 years later. It's not a common bug impacting many users. >From a maintenance POV, initializing the GIL eagerly also makes maintenance easier for us, instead of making all those dynamic checks. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 07:25:34 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Dec 2017 12:25:34 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1512390334.97.0.213398074469.issue17611@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I started on Antoine's PR and work on different approach (https://github.com/serhiy-storchaka/cpython/pull/1) which don't duplicate the code for continue/break/return. Instead it uses some kind of subroutines. END_FINALLY expects the one of three cases: 1. NULL (or None). Normal execution thread in try/finally. Continue from the instruction following END_FINALLY. 2. An integer. This is an address of returning. Continue from the specified address. 3. An exception (6 items). Raises the specified exception. WITH_CLEANUP_FINISH behaves similarly. The statements continue/break/return insert the instruction CALL_FINALLY which pushes the address of the following instruction on the stack and jumps to the start of the finally (or with cleanup) block. There can be several CALL_FINALLY instructions if you need to execute several finally blocks. At the jump instruction is inserted for continue and break, and RETURN_VALUE for return. Currently I'm trying to simplify the code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 07:29:09 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Dec 2017 12:29:09 +0000 Subject: [issue1647489] zero-length match confuses re.finditer() Message-ID: <1512390549.37.0.213398074469.issue1647489@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 70d56fb52582d9d3f7c00860d6e90570c6259371 by Serhiy Storchaka in branch 'master': bpo-25054, bpo-1647489: Added support of splitting on zerowidth patterns. (#4471) https://github.com/python/cpython/commit/70d56fb52582d9d3f7c00860d6e90570c6259371 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 07:29:09 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Dec 2017 12:29:09 +0000 Subject: [issue25054] Capturing start of line '^' In-Reply-To: <1441887596.73.0.766811958538.issue25054@psf.upfronthosting.co.za> Message-ID: <1512390549.75.0.912454111764.issue25054@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 70d56fb52582d9d3f7c00860d6e90570c6259371 by Serhiy Storchaka in branch 'master': bpo-25054, bpo-1647489: Added support of splitting on zerowidth patterns. (#4471) https://github.com/python/cpython/commit/70d56fb52582d9d3f7c00860d6e90570c6259371 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 07:33:36 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 04 Dec 2017 12:33:36 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1512390334.97.0.213398074469.issue17611@psf.upfronthosting.co.za> Message-ID: Antoine Pitrou added the comment: Le 04/12/2017 ? 13:25, Serhiy Storchaka a ?crit?: > > I started on Antoine's PR and work on different approach (https://github.com/serhiy-storchaka/cpython/pull/1) which don't duplicate the code for continue/break/return. Instead it uses some kind of subroutines. END_FINALLY expects the one of three cases: > > 1. NULL (or None). Normal execution thread in try/finally. Continue from the instruction following END_FINALLY. > > 2. An integer. This is an address of returning. Continue from the specified address. > > 3. An exception (6 items). Raises the specified exception. The problem is that makes the stack consumption of END_FINALLY variable. How about always consuming 6 items, even when most of them are unused padding? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 07:39:17 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Dec 2017 12:39:17 +0000 Subject: [issue32197] Compiling against master branch fails; error: expected expression SET_DECODE_ERROR In-Reply-To: <1512219000.84.0.213398074469.issue32197@psf.upfronthosting.co.za> Message-ID: <1512391157.61.0.213398074469.issue32197@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 31a8393cf6a74c870c3484dd68500619f6232c6d by Victor Stinner in branch 'master': Revert "bpo-32197: Try to fix a compiler error on OS X introduced in bpo-32030. (#4681)" (#4694) https://github.com/python/cpython/commit/31a8393cf6a74c870c3484dd68500619f6232c6d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 07:39:17 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Dec 2017 12:39:17 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512391157.74.0.912454111764.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 31a8393cf6a74c870c3484dd68500619f6232c6d by Victor Stinner in branch 'master': Revert "bpo-32197: Try to fix a compiler error on OS X introduced in bpo-32030. (#4681)" (#4694) https://github.com/python/cpython/commit/31a8393cf6a74c870c3484dd68500619f6232c6d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 07:54:29 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Dec 2017 12:54:29 +0000 Subject: [issue32212] few discrepancy between source and docs in logging In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za> Message-ID: <1512392069.17.0.213398074469.issue32212@psf.upfronthosting.co.za> R. David Murray added the comment: I don't understand what the bug is that you are reporting here. Can you clarify? mypy isn't part of the stdlib, so an explanation in terms of what's in the stdlib would be helpful. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 08:06:01 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Dec 2017 13:06:01 +0000 Subject: [issue32197] Compiling against master branch fails; error: expected expression SET_DECODE_ERROR In-Reply-To: <1512219000.84.0.213398074469.issue32197@psf.upfronthosting.co.za> Message-ID: <1512392761.1.0.213398074469.issue32197@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh sorry, I missed the macOS failure and I wasn't available last week-end for quickly fix it. So thanks Serhiy for the revert ;-) I reapplied my changes with the following fix. test_embed randomly failed, but it's unrelated (I was able to reproduce the bug on master, with the revert): https://bugs.python.org/issue20891#msg307550 The fix: diff --git a/Modules/main.c b/Modules/main.c index 84706e1e290..4095259b88c 100644 --- a/Modules/main.c +++ b/Modules/main.c @@ -901,8 +901,8 @@ config_get_program_name(_PyMainInterpreterConfig *config) size_t len; wchar_t* program_name = Py_DecodeLocale(p, &len); if (program_name == NULL) { - return SET_DECODE_ERROR("PYTHONEXECUTABLE environment " - "variable", len); + return DECODE_LOCALE_ERR("PYTHONEXECUTABLE environment " + "variable", (Py_ssize_t)len); } config->program_name = program_name; } @@ -916,8 +916,8 @@ config_get_program_name(_PyMainInterpreterConfig *config) size_t len; wchar_t* program_name = Py_DecodeLocale(pyvenv_launcher, &len); if (program_name == NULL) { - return SET_DECODE_ERROR("__PYVENV_LAUNCHER__ environment " - "variable", len); + return DECODE_LOCALE_ERR("__PYVENV_LAUNCHER__ environment " + "variable", (Py_ssize_t)len); } config->program_name = program_name; } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 08:06:28 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Dec 2017 13:06:28 +0000 Subject: [issue32197] Compiling against master branch fails; error: expected expression SET_DECODE_ERROR In-Reply-To: <1512219000.84.0.213398074469.issue32197@psf.upfronthosting.co.za> Message-ID: <1512392788.54.0.213398074469.issue32197@psf.upfronthosting.co.za> STINNER Victor added the comment: I tested manually that compilation and tests succeed on macOS. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 08:16:14 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Dec 2017 13:16:14 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: Message-ID: <7488811.rCEn5LsdNE@saraksh> Serhiy Storchaka added the comment: > The problem is that makes the stack consumption of END_FINALLY variable. > How about always consuming 6 items, even when most of them are unused > padding? Right. Though the value of the stack increment makes sense only for the case 1, because in other cases the next executed instruction is not the one following END_FINALLY, but we need to reserve the stack for the case 3, and counting additional "virtual" items in PUSH_NO_EXCEPT and END_FINALLY will help to calculate the maximal stack consumption, even when in runtime they push/pop only one item. This is yet one argument for special purposed opcode PUSH_NO_EXCEPT (maybe I'll rename it to START_FINALLY or BEGIN_FINALLY). Other reason -- this will help to determine bounds of finally blocks in the frame.f_lineno setter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 08:29:07 2017 From: report at bugs.python.org (Michal Plichta) Date: Mon, 04 Dec 2017 13:29:07 +0000 Subject: [issue32212] few discrepancy between source and docs in logging In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za> Message-ID: <1512394147.84.0.213398074469.issue32212@psf.upfronthosting.co.za> Michal Plichta added the comment: see at typeshed: https://github.com/python/typeshed/blob/master/stdlib/2and3/logging/__init__.pyi#L147 def setLevel(self, lvl: Union[int, str]) -> None: ... def setFormatter(self, form: 'Formatter') -> None: ... this match python documentation: Handler.setLevel(lvl) Handler.setFormatter(form) but is source code (logging/__init__.py): def setFormatter(self, fmt): self.formatter = f def setLevel(self, level): self.level = _checkLevel(level) This is not big deal but keyworded arguments have different names fmt, form and level, lvl. Some tools which perform static code verification are base of *.pyi from typeshed repo and some form source code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 08:43:34 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Mon, 04 Dec 2017 13:43:34 +0000 Subject: [issue32197] Compiling against master branch fails; error: expected expression SET_DECODE_ERROR In-Reply-To: <1512219000.84.0.213398074469.issue32197@psf.upfronthosting.co.za> Message-ID: <1512395014.06.0.213398074469.issue32197@psf.upfronthosting.co.za> Sanyam Khurana added the comment: Hey Victor, thanks for the update. I was confused about how the macro was replaced in the previous version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 08:48:55 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Dec 2017 13:48:55 +0000 Subject: [issue32212] few discrepancy between source and docs in logging In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za> Message-ID: <1512395335.41.0.213398074469.issue32212@psf.upfronthosting.co.za> R. David Murray added the comment: Ah. I'm guessing Vinay will probably want to fix the docs, then, since that's less disruptive backward compatibility wise. ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 08:50:26 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Dec 2017 13:50:26 +0000 Subject: [issue32212] few discrepancy between source and docs in logging In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za> Message-ID: <1512395426.82.0.213398074469.issue32212@psf.upfronthosting.co.za> Change by R. David Murray : ---------- stage: -> needs patch versions: +Python 3.7 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 08:54:46 2017 From: report at bugs.python.org (Chirag Rathod) Date: Mon, 04 Dec 2017 13:54:46 +0000 Subject: [issue32035] Documentation of zipfile.ZipFile().writestr() fails to mention that 'data' may also be bytes In-Reply-To: <1510757660.91.0.213398074469.issue32035@psf.upfronthosting.co.za> Message-ID: <1512395686.71.0.213398074469.issue32035@psf.upfronthosting.co.za> Change by Chirag Rathod : ---------- keywords: +patch pull_requests: +4610 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 09:28:26 2017 From: report at bugs.python.org (Michal Plichta) Date: Mon, 04 Dec 2017 14:28:26 +0000 Subject: [issue32212] few discrepancy between source and docs in logging In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za> Message-ID: <1512397706.29.0.213398074469.issue32212@psf.upfronthosting.co.za> Michal Plichta added the comment: Nice, btw maybe other parameters in logging's docs needs to be corrected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 09:44:28 2017 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 04 Dec 2017 14:44:28 +0000 Subject: [issue32213] assertRaises and subTest context managers cannot be nested Message-ID: <1512398668.79.0.213398074469.issue32213@psf.upfronthosting.co.za> New submission from Paul Ganssle : The TestCase.assertRaises and TestCase.subTest macros apparently don't interact with each other well. To demonstrate, consider the following code: from unittest import TestCase class SubTestRaisesTest(TestCase): def test_assert_outer(self): for to_raise in [True, False]: with self.assertRaises(Exception): with self.subTest(to_raise=to_raise): if to_raise: raise Exception() def test_assert_inner(self): for to_raise in [True, False]: with self.subTest(to_raise=to_raise): with self.assertRaises(Exception): if to_raise: raise Exception() This actually fails in two different ways. For test_assert_outer: -with subtest `to_raise=True`, the test (correctly) passes. -with subtest `to_raise=False`, the test (correctly) fails, but the subtest is not actually assigned (no indication of which subtest it was that failed): ====================================================================== FAIL: test_assert_outer (test_bug.SubTestRaisesTest) ---------------------------------------------------------------------- Traceback (most recent call last): File ".../assert_demo/test_bug.py", line 9, in test_assert_outer raise Exception() AssertionError: Exception not raised For test_assert_inner: - with subtest `to_raise=False`, the test (corrrectly) fails, *and* the subtest is set correctly: ====================================================================== FAIL: test_assert_inner (test_bug.SubTestRaisesTest) (to_raise=False) ---------------------------------------------------------------------- Traceback (most recent call last): File "..../assert_demo/test_bug.py", line 16, in test_assert_inner raise Exception() AssertionError: Exception not raised - with subtest `to_raise=False` the test (incorrectly) fails as an error, because the exception is never caught: ====================================================================== ERROR: test_assert_outer (test_bug.SubTestRaisesTest) (to_raise=True) ---------------------------------------------------------------------- Traceback (most recent call last): File "..../assert_demo/test_bug.py", line 9, in test_assert_outer raise Exception() Exception So, to sum up, the behavior that needs to be fixed: 1. When assertRaises is the outer context, the subtest value needs to be set for the failing tests. 2. When assertRaises is the *inner* context, the exception needs to be caught properly and cleared on exit from the assertRaises context. ---------- components: Tests messages: 307569 nosy: p-ganssle priority: normal severity: normal status: open title: assertRaises and subTest context managers cannot be nested versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 10:21:48 2017 From: report at bugs.python.org (Mark Shannon) Date: Mon, 04 Dec 2017 15:21:48 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1512400908.08.0.213398074469.issue17611@psf.upfronthosting.co.za> Mark Shannon added the comment: Serhiy, I assume that you plan to use something like the JVM's JSR/RET instruction pair. https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-6.html Is that right? My reasons for preferring the finally-block duplication approach is that it keeps the interpreter simpler and minimises the amount work done when no exception is raised. As demonstrated, the increase in the static size of the bytecode is negligible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 10:38:00 2017 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 04 Dec 2017 15:38:00 +0000 Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error In-Reply-To: <1512389671.82.0.213398074469.issue20891@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Yeah, the original reasoning was that threads were something esoteric and not used by most code, and at the time we definitely felt that always using the GIL would cause a (tiny) slowdown and increase the risk of crashes due to bugs in the GIL code. I'd be happy to learn that we no longer need to worry about this and can just always initialize it. (Note: I haven't read the entire thread, just the first and last message.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 10:49:17 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 04 Dec 2017 15:49:17 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1512400908.08.0.213398074469.issue17611@psf.upfronthosting.co.za> Message-ID: <87ca1904-a2cf-15da-47e9-bed56639f52e@free.fr> Antoine Pitrou added the comment: Le 04/12/2017 ? 16:21, Mark Shannon a ?crit?: > > My reasons for preferring the finally-block duplication approach is that it keeps the interpreter simpler and minimises the amount work done when no exception is raised. As demonstrated, the increase in the static size of the bytecode is negligible. Whichever approach wins at the end, I would like it to reuse the tests I wrote to check that no stack size explosion happens when combining or juxtaposing several control flow constructs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 10:50:07 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Dec 2017 15:50:07 +0000 Subject: [issue32205] test.pythoninfo does not print the cross-built sysconfig data In-Reply-To: <1512307690.33.0.213398074469.issue32205@psf.upfronthosting.co.za> Message-ID: <1512402607.03.0.213398074469.issue32205@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm not sure of the purpose of this change. You can please elaborate on you use case? You use cross-compilation, ok. But why do you want to run test.pythoninfo on the computer building Python, rather than the computer running tests? The purpose of test.pythoninfo is to dump informations on tests run by "./python -m test". I wrote it for buildbots. If your use case is to have an Android buildbot worker, test.pythoninfo would be run on Android, no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 10:52:34 2017 From: report at bugs.python.org (Marcel Plch) Date: Mon, 04 Dec 2017 15:52:34 +0000 Subject: [issue31901] atexit callbacks should be run at subinterpreter shutdown In-Reply-To: <1509378283.18.0.213398074469.issue31901@psf.upfronthosting.co.za> Message-ID: <1512402754.79.0.213398074469.issue31901@psf.upfronthosting.co.za> Marcel Plch added the comment: I created a PR with fix on this issue - https://github.com/python/cpython/pull/4611 This makes Py_EndInterpreter() call atexit callbacks for the subinterpreter it is destroying. It doesn't make Py_Finalize() end all subinterpreters, as the current implementation of subinterpreters makes it hard to do so. This is the same as the current behaviour: you need to end all subinterpreters before calling Py_Finalize(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 11:08:15 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Dec 2017 16:08:15 +0000 Subject: [issue32213] assertRaises and subTest context managers cannot be nested In-Reply-To: <1512398668.79.0.213398074469.issue32213@psf.upfronthosting.co.za> Message-ID: <1512403695.75.0.213398074469.issue32213@psf.upfronthosting.co.za> R. David Murray added the comment: To be pedantic, are not macros, they are context managers :) Your first case is not something I would have thought of coding. In the to_raise=True case, the subTest is failing because an exception is raised inside its scope. In the to_raise=False case, the subTest scope has already ended before the assertRaises scope completes and raises its error because no exception was raised. That is, there is no subTest in effect to be reported when that failure occurs. In your second case, when to_raise is False, no exception is raised, so the assertRaises correctly fails, and the subtest reports that to_raise is False. When to_raise is true, the exception is raised, the assertRaises passes and so does the subtest. In other words, I can't reproduce the problem you cite for the second case. Looking at what you pasted, it looks like you confused a test_assert_outer report with a test_report_inner report. So, as far as I can see, there's nothing broken here, everything is working according to the documentation :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 11:34:11 2017 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 04 Dec 2017 16:34:11 +0000 Subject: [issue32213] assertRaises and subTest context managers cannot be nested In-Reply-To: <1512398668.79.0.213398074469.issue32213@psf.upfronthosting.co.za> Message-ID: <1512405251.17.0.213398074469.issue32213@psf.upfronthosting.co.za> Paul Ganssle added the comment: @r.david.murray So it is, my mistake. I think I was conflating issues when this first came up, and then I didn't notice that the order the test cases printed in was different than I expected. ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 11:56:25 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 04 Dec 2017 16:56:25 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1512400908.08.0.213398074469.issue17611@psf.upfronthosting.co.za> Message-ID: <1567354.66TbBMzbGb@saraksh> Serhiy Storchaka added the comment: Right, this is similar to how the JSR/RET pair was used in for calling the finally block. It seems the main drawback of duplicating of the finally code is not increasing the code size (which can be exponential in degenerate cases), but the problem with determining the boundaries of the finally block. The main purpose of this issue (getting rid of "pseudo exceptions" in the interpreter) will be achieved in any case. This is the first step. In the second step I'm going to get rid of dynamic PyTryBlock and instructions like SETUP_EXCEPT and POP_BLOCK. I think all necessary information can be determined at compile time and saved in an auxiliary structure, similarly as line numbers are saved in the packed co_lnotab array instead of be set by SET_LINENO instructions. Boundaries of finally block could be stored in the same structure. This will make try/except/ finally virtually zero-overhead. In the third step we could generate duplicates of finally blocks. This will be easier if other changes already applied and tested. Currently there is other problem with Antoine's PR (I didn't know about them when made a review). There is a gap between calling the __enter__ method and the SETUP_FINALLY instruction. If the exception is raised in the gap, the __exit__ method will be never called. For example: a = [] with CM() as a[0]: # IndexError ... I still haven't fixed this problem. Maybe the simplest solution would be to return the SETUP_WITH instruction which calls __enter__ and creates the finally block prior to saving the result of __enter__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 11:58:28 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Dec 2017 16:58:28 +0000 Subject: [issue32205] test.pythoninfo does not print the cross-built sysconfig data In-Reply-To: <1512307690.33.0.213398074469.issue32205@psf.upfronthosting.co.za> Message-ID: <1512406708.7.0.213398074469.issue32205@psf.upfronthosting.co.za> STINNER Victor added the comment: "make pythoninfo" is an alias for ./python -m test.pythoninfo. I added to support Python compiled in shared mode (./configure --enable-shared) and macOS which requires ./python.exe. Obviously, for a specific buildbot or specific script, you are free to run directly ./python -m test.pythoninfo, rather than running "make pythoninfo" ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 11:58:44 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Dec 2017 16:58:44 +0000 Subject: [issue32205] test.pythoninfo does not print the cross-built sysconfig data In-Reply-To: <1512307690.33.0.213398074469.issue32205@psf.upfronthosting.co.za> Message-ID: <1512406724.31.0.213398074469.issue32205@psf.upfronthosting.co.za> STINNER Victor added the comment: See also bpo-32210: Add the versions of the Android SDK and NDK to test.pythoninfo. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 11:58:46 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Dec 2017 16:58:46 +0000 Subject: [issue32213] assertRaises and subTest context managers cannot be nested In-Reply-To: <1512398668.79.0.213398074469.issue32213@psf.upfronthosting.co.za> Message-ID: <1512406726.69.0.213398074469.issue32213@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, that's an easy mistake to make. I avoided it by only running one of the tests cases at a time, and I'll admit I had to think about it for a while to understand what was going on in your first case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 11:58:54 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 04 Dec 2017 16:58:54 +0000 Subject: [issue32213] assertRaises and subTest context managers cannot be nested In-Reply-To: <1512398668.79.0.213398074469.issue32213@psf.upfronthosting.co.za> Message-ID: <1512406734.54.0.213398074469.issue32213@psf.upfronthosting.co.za> Change by R. David Murray : ---------- resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 11:59:14 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Dec 2017 16:59:14 +0000 Subject: [issue32210] Add the versions of the Android SDK and NDK to test.pythoninfo In-Reply-To: <1512380375.09.0.213398074469.issue32210@psf.upfronthosting.co.za> Message-ID: <1512406754.68.0.213398074469.issue32210@psf.upfronthosting.co.za> STINNER Victor added the comment: Maybe add a collect_android() function which would exit early if sys.getandroidapilevel() doesn't exist? > * The NDK version can be obtained by parsing the file $ANDROID_NDK_ROOT/source.properties. > * The versions of the SDK build-tools, emulator and platform-tools packages as well as those of the system images can be obtained by parsing the output of "$ANDROID_SDK_ROOT/tools/bin/sdkmanager --list". You are free to add whatever you want/need, but just try to handle properly errors to collect other info even if these data cannot be read. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 12:07:08 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Dec 2017 17:07:08 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512407228.05.0.213398074469.issue19610@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 12:19:48 2017 From: report at bugs.python.org (Mark Shannon) Date: Mon, 04 Dec 2017 17:19:48 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1567354.66TbBMzbGb@saraksh> Message-ID: Mark Shannon added the comment: On 04/12/17 16:56, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > Right, this is similar to how the JSR/RET pair was used in for calling the > finally block. > > It seems the main drawback of duplicating of the finally code is not increasing > the code size (which can be exponential in degenerate cases), but the problem > with determining the boundaries of the finally block. What exactly is the problem? Why do you need to determine the boundaries of finally blocks? ... > > This is the first step. In the second step I'm going to get rid of dynamic > PyTryBlock and instructions like SETUP_EXCEPT and POP_BLOCK. I think all > necessary information can be determined at compile time and saved in an > auxiliary structure, similarly as line numbers are saved in the packed > co_lnotab array instead of be set by SET_LINENO instructions. Boundaries of > finally block could be stored in the same structure. This will make try/except/ > finally virtually zero-overhead. Fine, but it isn't necessary for this issue. The overhead of try/except is already quite low. > > Currently there is other problem with Antoine's PR (I didn't know about them > when made a review). There is a gap between calling the __enter__ method and > the SETUP_FINALLY instruction. That wasn't a problem with the original patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 12:34:35 2017 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 04 Dec 2017 17:34:35 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1512408875.8.0.213398074469.issue15873@psf.upfronthosting.co.za> Change by Paul Ganssle : ---------- pull_requests: +4611 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 12:35:43 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Dec 2017 17:35:43 +0000 Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za> Message-ID: <1512408943.3.0.213398074469.issue20891@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4612 stage: resolved -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 12:36:29 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Dec 2017 17:36:29 +0000 Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za> Message-ID: <1512408989.61.0.213398074469.issue20891@psf.upfronthosting.co.za> STINNER Victor added the comment: I wrote the PR 4700 to create the GIL in Py_Initialize(). Would you be ok to backport this fix to Python 2.7 and 3.6 as well? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 12:41:52 2017 From: report at bugs.python.org (Mark Shannon) Date: Mon, 04 Dec 2017 17:41:52 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1512409312.72.0.213398074469.issue17611@psf.upfronthosting.co.za> Mark Shannon added the comment: Actually looking back at the original patch, the gap between __enter__ and SETUP_FINALLY *was* in the original patch. My mistake. The fix would to be restore SETUP_WITH. The complexity we really want to get rid of is at the end of the with statement not the start. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 12:53:08 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Mon, 04 Dec 2017 17:53:08 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1512409988.04.0.213398074469.issue17611@psf.upfronthosting.co.za> Neil Schemenauer added the comment: After studying the patch and doing some reading, I prefer the finally-block duplication approach as well. Java does it that way as well and it works for them. It would be be interesting to compile a large body of packages and see what the increase in bytecode size actually is with the duplication. My gut feeling is that it will not be a big deal. There is a bug with the PR regarding the final bodies. Exits from the final body cause the whole fblock stack to unwind, not just the blocks enclosing the final body. Unwind looks at 'c' to get the fblock stack. I think we need to allocate fblockinfo on the C stack and then use a back pointer to enclosing block. When you get into a final body that creates its own fblockinfo (e.g. a try/except inside the finally), the current code doesn't work. The fact that the whole test suite passes with these issues tells me that the amount of stuff happening in final bodies must be pretty simple in most code. I spent a good part of Sunday trying to understand how the PR works. It seems to me that the ceval/bytecode changes are pretty solid. The compiler needs some bug fixes. Further optimisations could be done at a later time. I'm curious to see Serhiy's approach though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 12:53:15 2017 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 04 Dec 2017 17:53:15 +0000 Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error In-Reply-To: <1512408989.61.0.213398074469.issue20891@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: For 2.7 I hesitate to OK this, who knows what skeletons are still in that closet. It doesn't sound like a security fix to me. For 3.6 I'm fine with it as a bugfix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 12:56:06 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 04 Dec 2017 17:56:06 +0000 Subject: [issue32205] test.pythoninfo does not print the cross-built sysconfig data In-Reply-To: <1512307690.33.0.213398074469.issue32205@psf.upfronthosting.co.za> Message-ID: <1512410166.32.0.213398074469.issue32205@psf.upfronthosting.co.za> Xavier de Gaye added the comment: I may have misunderstood the scope of pythoninfo. On Android the readline or sqlite versions are known at build time since they have to be built at that time, but much more useful information can be obtained (or will be obtained) from python running on the device or the emulator. For the NDK and SDK versions (issue 32210), these can be printed by the 'all' target for the NDK and by one of the emulator targets for the SDK. This means that both this issue and #32210 may be closed as wont fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 13:14:16 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Mon, 04 Dec 2017 18:14:16 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512411256.54.0.213398074469.issue19610@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Don't be sorry. We are all passionate about making Python better. distutils will be better once we gets this sorted out. Berker deserves credit for seeing an issue and developing on a fix for it. The collaboration between all the core developers is making the final fix better than what any one of us could make. The process is working quite well IMHO. I had a small patch a few days ago that I was considering just committing without reviews. I went through the review process though and the patch was better as a result of the review feedback I got. The documentation says that the argument needs to be a list of strings or a string. So, unless we change the documentation, a string must be accepted without warnings or errors. The current PR works pretty well. Figuring out how to best warn is the trickiest bit. Sometimes it seems like DepreciationWarning doesn't work as we would like, since it often gets suppressed. It seems pip is especially "good" at hiding it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 14:23:41 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Dec 2017 19:23:41 +0000 Subject: [issue30928] Copy modified blurbs to idlelib/NEWS.txt In-Reply-To: <1500004288.4.0.547702885246.issue30928@psf.upfronthosting.co.za> Message-ID: <1512415421.17.0.213398074469.issue30928@psf.upfronthosting.co.za> Change by Terry J. Reedy : ---------- pull_requests: +4613 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 14:37:22 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 04 Dec 2017 19:37:22 +0000 Subject: [issue32208] Improve semaphore documentation In-Reply-To: <1512357480.91.0.213398074469.issue32208@psf.upfronthosting.co.za> Message-ID: <1512416242.84.0.213398074469.issue32208@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The changes you are proposing sound reasonable to me. Would you like to submit a pull request for them? ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, pitrou stage: -> needs patch versions: -Python 3.4, Python 3.5, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 14:39:53 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 04 Dec 2017 19:39:53 +0000 Subject: [issue32175] Add hash auto-randomization In-Reply-To: <1512020355.45.0.213398074469.issue32175@psf.upfronthosting.co.za> Message-ID: <1512416393.97.0.213398074469.issue32175@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Agreed this is not desirable at this point. Let's leave 2.7 like it is. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 14:47:12 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Dec 2017 19:47:12 +0000 Subject: [issue21621] Add note to 3.x What's New re Idle changes in bugfix releases In-Reply-To: <1401566588.31.0.436459410689.issue21621@psf.upfronthosting.co.za> Message-ID: <1512416832.91.0.213398074469.issue21621@psf.upfronthosting.co.za> Terry J. Reedy added the comment: #21961 ends with the entry I added for 3.4 and 3.5. 3.7 (and checking 3.6) will be a new issue. ---------- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> Add What's New for Idle. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 14:48:28 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Dec 2017 19:48:28 +0000 Subject: [issue30928] Copy modified blurbs to idlelib/NEWS.txt In-Reply-To: <1500004288.4.0.547702885246.issue30928@psf.upfronthosting.co.za> Message-ID: <1512416908.19.0.213398074469.issue30928@psf.upfronthosting.co.za> Terry J. Reedy added the comment: New changeset 21255fc3932a60c064f85c0fe68f2840f390ebe4 by Terry Jan Reedy in branch 'master': bpo-30928: Update idlelib/NEWS.txt to 2017 Dec 3. (#4701) https://github.com/python/cpython/commit/21255fc3932a60c064f85c0fe68f2840f390ebe4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 14:49:38 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 04 Dec 2017 19:49:38 +0000 Subject: [issue30928] Copy modified blurbs to idlelib/NEWS.txt In-Reply-To: <1500004288.4.0.547702885246.issue30928@psf.upfronthosting.co.za> Message-ID: <1512416978.26.0.213398074469.issue30928@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4614 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 15:03:38 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 04 Dec 2017 20:03:38 +0000 Subject: [issue32175] Add hash auto-randomization In-Reply-To: <1512020355.45.0.213398074469.issue32175@psf.upfronthosting.co.za> Message-ID: <1512417818.69.0.213398074469.issue32175@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Marking as closed for the reasons listed by the other respondents. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 15:07:31 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Dec 2017 20:07:31 +0000 Subject: [issue32207] IDLE: run's tk update adds context traceback on callback error In-Reply-To: <1512352029.95.0.213398074469.issue32207@psf.upfronthosting.co.za> Message-ID: <1512418051.98.0.213398074469.issue32207@psf.upfronthosting.co.za> Change by Terry J. Reedy : ---------- keywords: +patch pull_requests: +4615 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 15:12:32 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Dec 2017 20:12:32 +0000 Subject: [issue32207] IDLE: run's tk update adds context traceback on callback error In-Reply-To: <1512352029.95.0.213398074469.issue32207@psf.upfronthosting.co.za> Message-ID: <1512418352.67.0.213398074469.issue32207@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thanks. I am still puzzled why the nested within nested try-except did not work as I expected, but I care more about fixing this. The result based on your suggestion is better (to read, I think) than extra nesting that did work. ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 15:23:21 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Dec 2017 20:23:21 +0000 Subject: [issue30928] Copy modified blurbs to idlelib/NEWS.txt In-Reply-To: <1500004288.4.0.547702885246.issue30928@psf.upfronthosting.co.za> Message-ID: <1512419001.58.0.213398074469.issue30928@psf.upfronthosting.co.za> Terry J. Reedy added the comment: New changeset 6e687948b0025a1ab0d0773efe62ce64f0c745fc by Terry Jan Reedy (Miss Islington (bot)) in branch '3.6': bpo-30928: Update idlelib/NEWS.txt to 2017 Dec 3. (GH-4701) (#4702) https://github.com/python/cpython/commit/6e687948b0025a1ab0d0773efe62ce64f0c745fc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 15:24:49 2017 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 04 Dec 2017 20:24:49 +0000 Subject: [issue32214] Implement PEP 557: Data Classes Message-ID: <1512419089.03.0.213398074469.issue32214@psf.upfronthosting.co.za> New submission from Eric V. Smith : PR to follow. Development was at https://github.com/ericvsmith/dataclasses ---------- assignee: eric.smith components: Library (Lib) messages: 307596 nosy: eric.smith, ned.deily priority: normal severity: normal status: open title: Implement PEP 557: Data Classes type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 15:34:02 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Dec 2017 20:34:02 +0000 Subject: [issue32207] IDLE: run's tk update adds context traceback on callback error In-Reply-To: <1512352029.95.0.213398074469.issue32207@psf.upfronthosting.co.za> Message-ID: <1512419642.04.0.213398074469.issue32207@psf.upfronthosting.co.za> Change by Terry J. Reedy : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 15:56:59 2017 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 04 Dec 2017 20:56:59 +0000 Subject: [issue32214] Implement PEP 557: Data Classes In-Reply-To: <1512419089.03.0.213398074469.issue32214@psf.upfronthosting.co.za> Message-ID: <1512421019.48.0.213398074469.issue32214@psf.upfronthosting.co.za> Change by Eric V. Smith : ---------- keywords: +patch pull_requests: +4616 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 16:16:20 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Dec 2017 21:16:20 +0000 Subject: [issue32207] IDLE: run's tk update adds context traceback on callback error In-Reply-To: <1512352029.95.0.213398074469.issue32207@psf.upfronthosting.co.za> Message-ID: <1512422180.25.0.213398074469.issue32207@psf.upfronthosting.co.za> Terry J. Reedy added the comment: New changeset 1e2fcac4972530aa2c963d7e4011021df5ba866e by Terry Jan Reedy in branch 'master': bpo-32207: Improve tk event exception tracebacks in IDLE. (#4703) https://github.com/python/cpython/commit/1e2fcac4972530aa2c963d7e4011021df5ba866e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 16:17:27 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 04 Dec 2017 21:17:27 +0000 Subject: [issue32207] IDLE: run's tk update adds context traceback on callback error In-Reply-To: <1512352029.95.0.213398074469.issue32207@psf.upfronthosting.co.za> Message-ID: <1512422246.99.0.213398074469.issue32207@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4617 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 16:28:48 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Dec 2017 21:28:48 +0000 Subject: [issue30928] Copy modified blurbs to idlelib/NEWS.txt In-Reply-To: <1500004288.4.0.547702885246.issue30928@psf.upfronthosting.co.za> Message-ID: <1512422928.65.0.213398074469.issue30928@psf.upfronthosting.co.za> Change by Terry J. Reedy : ---------- pull_requests: +4618 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 16:58:58 2017 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 04 Dec 2017 21:58:58 +0000 Subject: [issue32214] Implement PEP 557: Data Classes In-Reply-To: <1512419089.03.0.213398074469.issue32214@psf.upfronthosting.co.za> Message-ID: <1512424738.33.0.213398074469.issue32214@psf.upfronthosting.co.za> Eric V. Smith added the comment: New changeset f0db54a0a1823534606ed5ce5a772365ba694c41 by Eric V. Smith in branch 'master': bpo-32214: Implement PEP 557: Data Classes (#4704) https://github.com/python/cpython/commit/f0db54a0a1823534606ed5ce5a772365ba694c41 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 17:02:34 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Dec 2017 22:02:34 +0000 Subject: [issue32207] IDLE: run's tk update adds context traceback on callback error In-Reply-To: <1512352029.95.0.213398074469.issue32207@psf.upfronthosting.co.za> Message-ID: <1512424954.72.0.213398074469.issue32207@psf.upfronthosting.co.za> Terry J. Reedy added the comment: New changeset 9da33c82124f27eb58ba4cf145675fe7a1035744 by Terry Jan Reedy (Miss Islington (bot)) in branch '3.6': bpo-32207: Improve tk event exception tracebacks in IDLE. (GH-4703) (#4705) https://github.com/python/cpython/commit/9da33c82124f27eb58ba4cf145675fe7a1035744 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 17:04:00 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Dec 2017 22:04:00 +0000 Subject: [issue32207] IDLE: run's tk update adds context traceback on callback error In-Reply-To: <1512352029.95.0.213398074469.issue32207@psf.upfronthosting.co.za> Message-ID: <1512425040.16.0.213398074469.issue32207@psf.upfronthosting.co.za> Change by Terry J. Reedy : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 17:04:12 2017 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 04 Dec 2017 22:04:12 +0000 Subject: [issue32214] Implement PEP 557: Data Classes In-Reply-To: <1512419089.03.0.213398074469.issue32214@psf.upfronthosting.co.za> Message-ID: <1512425052.38.0.213398074469.issue32214@psf.upfronthosting.co.za> Change by Eric V. Smith : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 17:04:17 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 04 Dec 2017 22:04:17 +0000 Subject: [issue30928] Copy modified blurbs to idlelib/NEWS.txt In-Reply-To: <1500004288.4.0.547702885246.issue30928@psf.upfronthosting.co.za> Message-ID: <1512425057.5.0.213398074469.issue30928@psf.upfronthosting.co.za> Terry J. Reedy added the comment: New changeset 2c0c68d927bfa557f98bac26644f5b64c4b135a7 by Terry Jan Reedy in branch 'master': bpo-30928: update idlelib/NEWS.txt. (#4706) https://github.com/python/cpython/commit/2c0c68d927bfa557f98bac26644f5b64c4b135a7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 17:05:28 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 04 Dec 2017 22:05:28 +0000 Subject: [issue30928] Copy modified blurbs to idlelib/NEWS.txt In-Reply-To: <1500004288.4.0.547702885246.issue30928@psf.upfronthosting.co.za> Message-ID: <1512425128.12.0.213398074469.issue30928@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4619 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 17:22:50 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Dec 2017 22:22:50 +0000 Subject: [issue32175] Add hash auto-randomization In-Reply-To: <1512020355.45.0.213398074469.issue32175@psf.upfronthosting.co.za> Message-ID: <1512426170.78.0.213398074469.issue32175@psf.upfronthosting.co.za> STINNER Victor added the comment: By the way, for a few other reasons, Python 3 is more secure than Python 2.7. If you care of security, please upgrade! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 17:25:20 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 04 Dec 2017 22:25:20 +0000 Subject: [issue32210] Add the versions of the Android SDK and NDK to test.pythoninfo In-Reply-To: <1512380375.09.0.213398074469.issue32210@psf.upfronthosting.co.za> Message-ID: <1512426320.3.0.213398074469.issue32210@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I forgot that pythoninfo already has: call_func(info_add, 'sys.androidapilevel', sys, 'getandroidapilevel') Well, that's the *build time* API level, not the most useful one, but still useful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 17:39:51 2017 From: report at bugs.python.org (Martin Panter) Date: Mon, 04 Dec 2017 22:39:51 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1512427190.99.0.213398074469.issue15873@psf.upfronthosting.co.za> Martin Panter added the comment: P-ganssle seems to be proposing to limit parsing to exactly what ?datetime.isoformat? produces; i.e. whole number of seconds, milliseconds or microseconds. Personally I would prefer it without this limitation, like in Mathieu?s patches. But P-ganssle has done some documentation, so perhaps we can combine the work of each? ---------- nosy: +p-ganssle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 17:41:30 2017 From: report at bugs.python.org (Martin Panter) Date: Mon, 04 Dec 2017 22:41:30 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1512427290.28.0.213398074469.issue15873@psf.upfronthosting.co.za> Martin Panter added the comment: The other difference is Mattieu guarantees ValueError for invalid input strings, which I think is good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 17:45:18 2017 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 04 Dec 2017 22:45:18 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1512427518.77.0.213398074469.issue15873@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: The better is the enemy of the good here. Given the history of this issue, I would rather accept a well documented restrictive parser than wait for a more general code to be written. Note that we can always relax the parsing rules in the future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 17:47:51 2017 From: report at bugs.python.org (Mathieu Dupuy) Date: Mon, 04 Dec 2017 22:47:51 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1512427518.77.0.213398074469.issue15873@psf.upfronthosting.co.za> Message-ID: Mathieu Dupuy added the comment: I'm right now available again to work on this issue. I'll submit a pull request within a week with all issues addressed Le 4 d?c. 2017 11:45 PM, "Alexander Belopolsky" a ?crit : > > Alexander Belopolsky added the comment: > > The better is the enemy of the good here. Given the history of this > issue, I would rather accept a well documented restrictive parser than wait > for a more general code to be written. Note that we can always relax the > parsing rules in the future. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 19:33:52 2017 From: report at bugs.python.org (Paul Ganssle) Date: Tue, 05 Dec 2017 00:33:52 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1512434032.49.0.213398074469.issue15873@psf.upfronthosting.co.za> Paul Ganssle added the comment: > The better is the enemy of the good here. Given the history of this issue, I would rather accept a well documented restrictive parser than wait for a more general code to be written. Note that we can always relax the parsing rules in the future. This is in fact the exact reason why I wrote the isoformat parser like I did, because ISO 8601 is actually a quite expansive standard, and this is the least controversial subset of the features. In fact, I spent quite a bit of time on adapting the general purpose ISO8601 parser I wrote for dateutil *into* one that only accepts the output of isoformat() because it places a minimum burden on ongoing support, so it's not really a matter of waiting for a more general parser to be written. I suggest that for Python 3.7 we *only* support output of isoformat(). Many general iso8601 parsers exist, including the one I have already implemented for python-dateutil (which will be part of the dateutil 2.7.0 release). We can have further discussion later about what exactly should be supported in Python 3.8, but even in the pre-release discussions I'm already seeing pushback about some of the more unusual 8601 formats, and it's a *lot* easier to explain (in documentation) that `fromisoformat()` is intended to be the inverse of `isoformat()` than it is to explain which variations of ISO 8601 are and are not supported (fractional minutes? if you're following the standard, the separator has to be a T, so what other variations of the standard are allowed?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 19:38:49 2017 From: report at bugs.python.org (Garrett Berg) Date: Tue, 05 Dec 2017 00:38:49 +0000 Subject: [issue32208] Improve semaphore documentation In-Reply-To: <1512357480.91.0.213398074469.issue32208@psf.upfronthosting.co.za> Message-ID: <1512434329.95.0.213398074469.issue32208@psf.upfronthosting.co.za> Garrett Berg added the comment: Gave it a shot! ---------- keywords: +patch pull_requests: +4620 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 19:40:53 2017 From: report at bugs.python.org (Brian Forst) Date: Tue, 05 Dec 2017 00:40:53 +0000 Subject: [issue32215] sqlite3 400x-600x slower depending on formatting of an UPDATE statement in a string Message-ID: <1512434453.0.0.213398074469.issue32215@psf.upfronthosting.co.za> New submission from Brian Forst : We're moving some code from Python 2.7 to 3.6 and found a weird performance issue using SQLite in-memory and on-disk DBs with the built-in sqlite3 library. In Python 2.7, the two update statements below (excerpted from the attached file) run in the same amount of time. In Python 3.6 the update statement with the table name on a separate line runs 400x-600x slower with the example data provided in the file. """ UPDATE tbl SET col2 = NULL WHERE col1 = ? """ """ UPDATE tbl SET col2 = NULL WHERE col1 = ? """ We have verified this using Python installs from python.org on macOS Sierra and Windows 7 for Python 2.7 and 3.6. We have tried formatting the SQL strings in different ways and it appears that the speed change only occurs when the table name is on a different line than the "UPDATE". This also appears to be hitting some type of quadratic behaviour as with 10x less records, it only takes 10-15x as long. With the demo in the file we are seeing it take 1.6s on the fast string and ~1000s on the slow string. ---------- components: Interpreter Core, Library (Lib) files: sqlite3_27_36_performance_bug.py messages: 307609 nosy: bforst priority: normal severity: normal status: open title: sqlite3 400x-600x slower depending on formatting of an UPDATE statement in a string type: performance versions: Python 2.7, Python 3.6 Added file: https://bugs.python.org/file47315/sqlite3_27_36_performance_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 19:41:30 2017 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 05 Dec 2017 00:41:30 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1512434490.86.0.213398074469.issue15873@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: +1 on what Paul said. Mathieu, the goal for 3.7 will be to get Paul's PR merged. It will be great if you could help in reviewing it. We can return to the features in your PR during the 3.8 development cycle. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 20:07:38 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Tue, 05 Dec 2017 01:07:38 +0000 Subject: [issue28556] typing.py upgrades In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za> Message-ID: <1512436058.52.0.213398074469.issue28556@psf.upfronthosting.co.za> Change by Ivan Levkivskyi : ---------- pull_requests: +4621 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 20:11:56 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 Dec 2017 01:11:56 +0000 Subject: [issue32215] sqlite3 400x-600x slower depending on formatting of an UPDATE statement in a string In-Reply-To: <1512434453.0.0.213398074469.issue32215@psf.upfronthosting.co.za> Message-ID: <1512436316.39.0.213398074469.issue32215@psf.upfronthosting.co.za> R. David Murray added the comment: I can confirm that there is a difference on linux as well, using the sqlite version for both 2.7 and 3.7: rdmurray at pydev:~/python/p27[2.7]>./python sqlite3_27_36_performance_bug.py First step: 3.22849011421 Second step: 3.2167429924 rdmurray at pydev:~/python/p37[master]>./python ../p27/sqlite3_27_36_performance_bug.py First step: 3.2722721099853516 Second step: 4.094221353530884 (I changed time.clock() to time.time()). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 20:12:42 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 Dec 2017 01:12:42 +0000 Subject: [issue32215] sqlite3 400x-600x slower depending on formatting of an UPDATE statement in a string In-Reply-To: <1512434453.0.0.213398074469.issue32215@psf.upfronthosting.co.za> Message-ID: <1512436362.8.0.213398074469.issue32215@psf.upfronthosting.co.za> R. David Murray added the comment: ...using the *same* sqlite version... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 20:12:58 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 Dec 2017 01:12:58 +0000 Subject: [issue32215] sqlite3 400x-600x slower depending on formatting of an UPDATE statement in a string In-Reply-To: <1512434453.0.0.213398074469.issue32215@psf.upfronthosting.co.za> Message-ID: <1512436378.76.0.213398074469.issue32215@psf.upfronthosting.co.za> Change by R. David Murray : ---------- versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 21:04:52 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Dec 2017 02:04:52 +0000 Subject: [issue28791] update sqlite to latest version before beta 1 In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1512439492.03.0.213398074469.issue28791@psf.upfronthosting.co.za> Ned Deily added the comment: New changeset ca7562a7fea61646c1b40ace04deecf9903d34a1 by Ned Deily (Mariatta) in branch 'master': bpo-28791: Update macOS installer to use SQLite 3.21.0. (#4245) https://github.com/python/cpython/commit/ca7562a7fea61646c1b40ace04deecf9903d34a1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 21:05:11 2017 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 05 Dec 2017 02:05:11 +0000 Subject: [issue32216] Document PEP 557 Data Classes Message-ID: <1512439511.23.0.213398074469.issue32216@psf.upfronthosting.co.za> New submission from Eric V. Smith : The documentation needs to be added. ---------- assignee: docs at python components: Documentation messages: 307614 nosy: docs at python, eric.smith priority: high severity: normal status: open title: Document PEP 557 Data Classes versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 21:13:47 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Dec 2017 02:13:47 +0000 Subject: [issue28791] update sqlite to latest version before beta 1 In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1512440027.37.0.213398074469.issue28791@psf.upfronthosting.co.za> Change by Ned Deily : ---------- pull_requests: +4622 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 21:15:01 2017 From: report at bugs.python.org (Decorater) Date: Tue, 05 Dec 2017 02:15:01 +0000 Subject: [issue32217] freeze.py fails to work. Message-ID: <1512440101.88.0.213398074469.issue32217@psf.upfronthosting.co.za> New submission from Decorater : It seems on my system installed python 3.6.0 when invoking python 3.6.3's freeze.py it seems to fail with this traceback: python ..\externals\cpython\Tools\freeze\freeze.py pyeimport.py Traceback (most recent call last): File "..\externals\cpython\Tools\freeze\freeze.py", line 491, in main() File "..\externals\cpython\Tools\freeze\freeze.py", line 220, in main flagged_version = version + sys.abiflags AttributeError: module 'sys' has no attribute 'abiflags' ---------- components: Demos and Tools, Windows messages: 307615 nosy: Decorater, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: freeze.py fails to work. versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 21:17:04 2017 From: report at bugs.python.org (Paul Ganssle) Date: Tue, 05 Dec 2017 02:17:04 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1512440224.08.0.213398074469.issue15873@psf.upfronthosting.co.za> Paul Ganssle added the comment: > The other difference is Mattieu guarantees ValueError for invalid input strings, which I think is good. I forgot to address this - but I don't think this is a difference in approaches. If you pass `None` or an int or something, the problem is with the type, not the value, so at a minimum you're looking at TypeError and ValueError - and those are the only exceptions raised in my patch. (I'll note that my patch does not accept bytes, though this is something of an artificial limitation, since the patch makes use of the fact that all valid isoformat() strings will contain at most exactly 1 non-ascii character in position 10, so we could easily work around this, but I think the trend for CPython is to avoid blurring the lines between bytes and str rather than encouraging their interchangeable use.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 21:29:32 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Dec 2017 02:29:32 +0000 Subject: [issue28791] update sqlite to latest version before beta 1 In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1512440972.93.0.213398074469.issue28791@psf.upfronthosting.co.za> Ned Deily added the comment: New changeset a72e7bf563d5a9fb706a1775f5ae883a91b8a99f by Ned Deily in branch '3.6': [3.6] bpo-28791: Update macOS installer to use SQLite 3.21.0. (#4245) (#4711) https://github.com/python/cpython/commit/a72e7bf563d5a9fb706a1775f5ae883a91b8a99f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 21:37:29 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Dec 2017 02:37:29 +0000 Subject: [issue28791] update SQLite libraries for Windows and macOS installers In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1512441449.84.0.213398074469.issue28791@psf.upfronthosting.co.za> Ned Deily added the comment: I've updated the macOS installer for 3.7.0 and for 3.6.4. I'll leave this open for possible updating the Windows installer for 3.6.x (OK by me) and for possible updates for 2.7.x. ---------- stage: patch review -> needs patch title: update sqlite to latest version before beta 1 -> update SQLite libraries for Windows and macOS installers versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 21:39:04 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Dec 2017 02:39:04 +0000 Subject: [issue28791] update SQLite libraries for Windows and macOS installers In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1512441544.67.0.213398074469.issue28791@psf.upfronthosting.co.za> Ned Deily added the comment: > Should we mark issue 30952 'deferred blocker' too? No, that's a different matter. AFAICT, there is no standard option for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 21:39:47 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 Dec 2017 02:39:47 +0000 Subject: [issue32217] freeze.py fails to work. In-Reply-To: <1512440101.88.0.213398074469.issue32217@psf.upfronthosting.co.za> Message-ID: <1512441587.82.0.213398074469.issue32217@psf.upfronthosting.co.za> R. David Murray added the comment: Does the 3.6.0 freeze fail under 3.6.0, or the 3.6.3 freeze fail under 3.6.3? If not, there's no bug to report. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 21:44:00 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Dec 2017 02:44:00 +0000 Subject: [issue28556] typing.py upgrades In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za> Message-ID: <1512441840.13.0.213398074469.issue28556@psf.upfronthosting.co.za> Ned Deily added the comment: New changeset 29bc19321018ec6e58f9f4da9c18c42e9a9c580e by Ned Deily (Ivan Levkivskyi) in branch 'master': [bpo-28556] Minor fixes for typing module (#4710) https://github.com/python/cpython/commit/29bc19321018ec6e58f9f4da9c18c42e9a9c580e ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 21:44:19 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 05 Dec 2017 02:44:19 +0000 Subject: [issue28556] typing.py upgrades In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za> Message-ID: <1512441859.31.0.213398074469.issue28556@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4623 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 21:47:51 2017 From: report at bugs.python.org (Jeff VanOss) Date: Tue, 05 Dec 2017 02:47:51 +0000 Subject: [issue12851] ctypes: getbuffer() never provides strides In-Reply-To: <1314611923.07.0.681765586879.issue12851@psf.upfronthosting.co.za> Message-ID: <1512442071.77.0.213398074469.issue12851@psf.upfronthosting.co.za> Change by Jeff VanOss : ---------- keywords: +patch pull_requests: +4624 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 21:58:15 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 05 Dec 2017 02:58:15 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512442695.66.0.213398074469.issue19610@psf.upfronthosting.co.za> Neil Schemenauer added the comment: New changeset 8837dd092fe5ad5184889104e8036811ed839f98 by Neil Schemenauer in branch 'master': bpo-19610: Warn if distutils is provided something other than a list to some fields (#4685) https://github.com/python/cpython/commit/8837dd092fe5ad5184889104e8036811ed839f98 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 22:02:01 2017 From: report at bugs.python.org (Decorater) Date: Tue, 05 Dec 2017 03:02:01 +0000 Subject: [issue32217] freeze.py fails to work. In-Reply-To: <1512440101.88.0.213398074469.issue32217@psf.upfronthosting.co.za> Message-ID: <1512442921.83.0.213398074469.issue32217@psf.upfronthosting.co.za> Decorater added the comment: It seems to also give the same traceback when using the build from the latest commit on branch 3.6 as well as 3.6.0 when using the freeze.py from the clone as well (The way I tested it was manually patching the binaries in my my 3.6 install). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 22:02:04 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Dec 2017 03:02:04 +0000 Subject: [issue28556] typing.py upgrades In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za> Message-ID: <1512442924.6.0.213398074469.issue28556@psf.upfronthosting.co.za> Ned Deily added the comment: New changeset b0576278b2d44472c73696f6dea4855f7ffb7ff1 by Ned Deily (Miss Islington (bot)) in branch '3.6': [bpo-28556] Minor fixes for typing module (GH-4710) (#4713) https://github.com/python/cpython/commit/b0576278b2d44472c73696f6dea4855f7ffb7ff1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 22:06:24 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 05 Dec 2017 03:06:24 +0000 Subject: [issue28791] update SQLite libraries for Windows and macOS installers In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1512443184.09.0.213398074469.issue28791@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Tried to get miss-islington to backport Windows installer change to 3.6, did not work. I'll work on the backport PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 22:10:15 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Dec 2017 03:10:15 +0000 Subject: [issue31392] Upgrade installers to OpenSSL 1.1.0g and 1.0.2m In-Reply-To: <1504839169.11.0.433103507115.issue31392@psf.upfronthosting.co.za> Message-ID: <1512443415.75.0.213398074469.issue31392@psf.upfronthosting.co.za> Change by Ned Deily : ---------- pull_requests: +4625 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 22:12:27 2017 From: report at bugs.python.org (Liran Nuna) Date: Tue, 05 Dec 2017 03:12:27 +0000 Subject: [issue32204] async/await performance is very low In-Reply-To: <1512292149.52.0.213398074469.issue32204@psf.upfronthosting.co.za> Message-ID: <1512443547.97.0.213398074469.issue32204@psf.upfronthosting.co.za> Liran Nuna added the comment: > which makes them faster in some specific micro-benchmarks I'm not talking about micro-benchmarks, we are actively using asynq in production. Recent efforts to migrate to async/await have hit a major performance hit - our response times nearly doubled. I agree that the PR I offers little (or no) improvement but I implore you to explore performance bottlenecks in async/await. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 22:24:43 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Dec 2017 03:24:43 +0000 Subject: [issue31392] Upgrade installers to OpenSSL 1.1.0g and 1.0.2m In-Reply-To: <1504839169.11.0.433103507115.issue31392@psf.upfronthosting.co.za> Message-ID: <1512444283.42.0.213398074469.issue31392@psf.upfronthosting.co.za> Ned Deily added the comment: New changeset 24e046987b8e34bb4f1f3fd9bd31f1d605e347dc by Ned Deily in branch 'master': bpo-31392: Update macOS installer to use OpenSSL 1.0.2m (#4715) https://github.com/python/cpython/commit/24e046987b8e34bb4f1f3fd9bd31f1d605e347dc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 22:25:48 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 05 Dec 2017 03:25:48 +0000 Subject: [issue31392] Upgrade installers to OpenSSL 1.1.0g and 1.0.2m In-Reply-To: <1504839169.11.0.433103507115.issue31392@psf.upfronthosting.co.za> Message-ID: <1512444348.62.0.213398074469.issue31392@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4626 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 22:29:18 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 05 Dec 2017 03:29:18 +0000 Subject: [issue28791] update SQLite libraries for Windows and macOS installers In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1512444558.75.0.213398074469.issue28791@psf.upfronthosting.co.za> Change by Mariatta Wijaya : ---------- pull_requests: +4627 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 22:39:53 2017 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 05 Dec 2017 03:39:53 +0000 Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za> Message-ID: <1512445193.16.0.213398074469.issue20891@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 for making this change 3.6+ only. Victor, could you run your patch through the performance benchmarks? While I suspect Antoine is right that our current GIL management heuristics will mean we don't need the lazy initialisation optimisation any more, it's still preferable to have the specific numbers before merging it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 22:44:12 2017 From: report at bugs.python.org (Guy Gangemi) Date: Tue, 05 Dec 2017 03:44:12 +0000 Subject: [issue32218] add __iter__ to enum.Flag members Message-ID: <1512445452.31.0.213398074469.issue32218@psf.upfronthosting.co.za> New submission from Guy Gangemi : I'm proposing to extend enum.Flag member functionality so it is iterable in a manner similar to enum.Flag subclasses. from enum import Flag, auto class FlagIter(Flag): def __iter__(self): for memeber in self._member_map_.values(): if member in self: yield member class Colour(FlagIter): RED = auto() GREEN = auto() BLUE = auto() YELLOW = RED | GREEN cyan = Colour.GREEN | Colour.Blue print(*Colour) # Colour.RED Colour.GREEN Colour.BLUE Colour.YELLOW # Without the enhancement, 'not iterable' is thrown for these print(*cyan) # Colour.GREEN Colour.BLUE print(*Colour.YELLOW) # Colour.RED Colour.GREEN Colour.YELLOW print(*~Colour.RED) # Colour.GREEN Colour.BLUE ---------- messages: 307629 nosy: Guy Gangemi priority: normal severity: normal status: open title: add __iter__ to enum.Flag members type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 22:47:26 2017 From: report at bugs.python.org (Decorater) Date: Tue, 05 Dec 2017 03:47:26 +0000 Subject: [issue32217] freeze.py fails to work. In-Reply-To: <1512440101.88.0.213398074469.issue32217@psf.upfronthosting.co.za> Message-ID: <1512445646.91.0.213398074469.issue32217@psf.upfronthosting.co.za> Decorater added the comment: Seems that freeze.py was not updated since 3.6.0b2 and also fails like this in master as well. (specifically commit 10108a7b9affa61719a1dc1863edb2bdb3402fd1) was last edit to the file in both the 3.6 and the master branch. Could it be that ``sys.abiflags`` was removed from the sys module and so freeze stopped working due to that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 22:47:48 2017 From: report at bugs.python.org (Decorater) Date: Tue, 05 Dec 2017 03:47:48 +0000 Subject: [issue32217] freeze.py fails to work. In-Reply-To: <1512440101.88.0.213398074469.issue32217@psf.upfronthosting.co.za> Message-ID: <1512445668.72.0.213398074469.issue32217@psf.upfronthosting.co.za> Change by Decorater : ---------- versions: +Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 22:47:50 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 05 Dec 2017 03:47:50 +0000 Subject: [issue32204] async/await performance is very low In-Reply-To: <1512292149.52.0.213398074469.issue32204@psf.upfronthosting.co.za> Message-ID: <1512445670.86.0.213398074469.issue32204@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I agree that the PR I offers little (or no) improvement but I implore you to explore performance bottlenecks in async/await. And I'm saying that there are no "performance bottlenecks in async/await". async/await is *not* asyncio. async/await and yield are language constructs that use generator objects. Your benchmark *does not* test async/await vs yield. It compares asyncio.gather to batches in asynq. Now, maybe asyncio.gather can be optimized, but we should open a separate issue for that if we can have a better implementation of it. Your benchmark doesn't test the performance of IO -- that's the thing we actually optimize in asyncio and that we usually benchmark. asyncio.gather is a niche thing, and usually network applications don't have it as a bottleneck. Closing this issue. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 22:53:51 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 05 Dec 2017 03:53:51 +0000 Subject: [issue32204] async/await performance is very low In-Reply-To: <1512292149.52.0.213398074469.issue32204@psf.upfronthosting.co.za> Message-ID: <1512446031.73.0.213398074469.issue32204@psf.upfronthosting.co.za> Yury Selivanov added the comment: Also I suggest you to try uvloop. If your production code is still slower that with asynq, I suggest you to profile it and post real profiles here. I just don't think that asyncio.gather can be the main bottleneck you have, it must be something else. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 22:54:47 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Dec 2017 03:54:47 +0000 Subject: [issue31392] Upgrade installers to OpenSSL 1.1.0g and 1.0.2m In-Reply-To: <1504839169.11.0.433103507115.issue31392@psf.upfronthosting.co.za> Message-ID: <1512446086.99.0.213398074469.issue31392@psf.upfronthosting.co.za> Ned Deily added the comment: New changeset 0bec5e147a6c0f62517df8e7033a38087451d5d4 by Ned Deily (Miss Islington (bot)) in branch '3.6': [3.6] bpo-31392: Update macOS installer to use OpenSSL 1.0.2m (GH-4715) (#4716) https://github.com/python/cpython/commit/0bec5e147a6c0f62517df8e7033a38087451d5d4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 23:01:08 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Tue, 05 Dec 2017 04:01:08 +0000 Subject: [issue32219] SSLWantWriteError being raised by blocking SSL socket Message-ID: <1512446468.03.0.213398074469.issue32219@psf.upfronthosting.co.za> New submission from Nathaniel Smith : I have a test case that sets up a blocking SSLSocket, and eventually calls unwrap() to do a proper SSL shutdown. Every once in a while, the test blows up, because unwrap() unexpectedly raises SSLWantWriteError. This is very unexpected for a blocking socket. Unfortunately, since this is intermittent, I don't have a reliable reproducer. Both of the times I've seen this so far, it was on MacOS with CPython 3.6 (the official python.org build, so whichever openssl it uses), and it was specifically in unwrap(): https://travis-ci.org/python-trio/trio/jobs/298164123 https://travis-ci.org/python-trio/trio/jobs/311618077 Here's the code that fails -- as you can see it's just a straightforward blocking echo server using SSLContext.wrap_socket: https://github.com/python-trio/trio/blob/3e62bf64946b1dcbf42c2d03e39435d4b1ba00ac/trio/tests/test_ssl.py#L92 ---------- assignee: christian.heimes components: SSL messages: 307634 nosy: alex, christian.heimes, dstufft, janssen, njs priority: normal severity: normal status: open title: SSLWantWriteError being raised by blocking SSL socket versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 23:02:20 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Dec 2017 04:02:20 +0000 Subject: [issue31392] Upgrade installers to OpenSSL 1.1.0g and 1.0.2m In-Reply-To: <1504839169.11.0.433103507115.issue31392@psf.upfronthosting.co.za> Message-ID: <1512446540.64.0.213398074469.issue31392@psf.upfronthosting.co.za> Ned Deily added the comment: Updated the 3.7.0a3 and 3.6.4 macOS installer builds to 1.0.2m; I'll get 3.7.x to 1.1.0 before 3.7.0a4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 23:05:42 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Tue, 05 Dec 2017 04:05:42 +0000 Subject: [issue32219] SSLWantWriteError being raised by blocking SSL socket In-Reply-To: <1512446468.03.0.213398074469.issue32219@psf.upfronthosting.co.za> Message-ID: <1512446742.49.0.213398074469.issue32219@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Oh darn, I restarted the 311618077 build on Travis and apparently that makes it delete the log. Well, it was the same traceback as the one that's left, but triggered by a different test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 23:10:00 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 05 Dec 2017 04:10:00 +0000 Subject: [issue28791] update SQLite libraries for Windows and macOS installers In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1512447000.07.0.213398074469.issue28791@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset e2ba5523192a9cff125fce2ce530bec574353f7b by Mariatta in branch '3.6': bpo-28791: Update Windows builds to use SQLite 3.21.0. (GH-4246). (GH-4717) https://github.com/python/cpython/commit/e2ba5523192a9cff125fce2ce530bec574353f7b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 23:15:09 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 05 Dec 2017 04:15:09 +0000 Subject: [issue28791] update SQLite libraries for Windows and macOS installers In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1512447309.85.0.213398074469.issue28791@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Backport to 3.6 is done. But I personally won't be bothering with 2.7 :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 23:15:58 2017 From: report at bugs.python.org (Decorater) Date: Tue, 05 Dec 2017 04:15:58 +0000 Subject: [issue32217] freeze.py fails to work. In-Reply-To: <1512440101.88.0.213398074469.issue32217@psf.upfronthosting.co.za> Message-ID: <1512447358.05.0.213398074469.issue32217@psf.upfronthosting.co.za> Change by Decorater : ---------- keywords: +patch pull_requests: +4628 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 23:16:25 2017 From: report at bugs.python.org (Decorater) Date: Tue, 05 Dec 2017 04:16:25 +0000 Subject: [issue32217] freeze.py fails to work. In-Reply-To: <1512440101.88.0.213398074469.issue32217@psf.upfronthosting.co.za> Message-ID: <1512447385.94.0.213398074469.issue32217@psf.upfronthosting.co.za> Decorater added the comment: I have found an temporary fix for now after reading that abiflags is posix only. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 23:25:25 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Dec 2017 04:25:25 +0000 Subject: [issue31380] test_undecodable_filename() in Lib/test/test_httpservers.py broken on APFS In-Reply-To: <1504778309.6.0.433500701634.issue31380@psf.upfronthosting.co.za> Message-ID: <1512447925.51.0.213398074469.issue31380@psf.upfronthosting.co.za> Change by Ned Deily : ---------- keywords: +patch pull_requests: +4629 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 23:26:31 2017 From: report at bugs.python.org (Liran Nuna) Date: Tue, 05 Dec 2017 04:26:31 +0000 Subject: [issue32204] async/await performance is very low In-Reply-To: <1512292149.52.0.213398074469.issue32204@psf.upfronthosting.co.za> Message-ID: <1512447991.21.0.213398074469.issue32204@psf.upfronthosting.co.za> Liran Nuna added the comment: > Also I suggest you to try uvloop Sadly, uvloop does not offer any noticeable improvement in performance for us. Our usage is very similar to the "benchmarks" I posted - we don't do any actual async I/O because asynq does not offer that. > I suggest you to profile it and post real profiles here Gladly! Would you like profiles of python within itself (as in, made with `cProfile`) or gmon.out profiles? the latter would be a little more difficult to run since we run a web server which needs to accept traffic, but I do have plenty of `cProfile` profiles I could share with you. > I just don't think that asyncio.gather can be the main bottleneck you have, it must be something else I think my PR and the examples I have provided set a different mindset to this issue - the issue in question is that the "sync" performance of async/await is very poor when used to execute things in "sync". The benchmarks provided are an example of what a request life time looks like - there's a lot of scatter-gather to batch database queries that happen in sync (for the time being) which in the benchmark being simulated as simple math operations. To reiterate, I do not think `asyncio.gather` is the main performance bottleneck. I do not know how to better identify it with my limited knowledge about cpython. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 23:42:05 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Dec 2017 04:42:05 +0000 Subject: [issue31380] test_undecodable_filename() in Lib/test/test_httpservers.py broken on APFS In-Reply-To: <1504778309.6.0.433500701634.issue31380@psf.upfronthosting.co.za> Message-ID: <1512448924.99.0.213398074469.issue31380@psf.upfronthosting.co.za> Ned Deily added the comment: New changeset b3edde8dd44c878e9f039a2165d00ff075157d4b by Ned Deily in branch 'master': bpo-31380: Skip test_httpservers test_undecodable_file on macOS. (#4720) https://github.com/python/cpython/commit/b3edde8dd44c878e9f039a2165d00ff075157d4b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 23:43:12 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 05 Dec 2017 04:43:12 +0000 Subject: [issue31380] test_undecodable_filename() in Lib/test/test_httpservers.py broken on APFS In-Reply-To: <1504778309.6.0.433500701634.issue31380@psf.upfronthosting.co.za> Message-ID: <1512448992.06.0.213398074469.issue31380@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4630 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 4 23:43:58 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 05 Dec 2017 04:43:58 +0000 Subject: [issue27240] 'UnstructuredTokenList' object has no attribute '_fold_as_ew' In-Reply-To: <1465208759.2.0.0752415166741.issue27240@psf.upfronthosting.co.za> Message-ID: <1512449038.32.0.213398074469.issue27240@psf.upfronthosting.co.za> Berker Peksag added the comment: All three examples in test2.py correctly folded (doesn't hit the ``except Exception as e:`` branch anymore) in current master. Can this issue be closed now? ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 00:03:31 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Dec 2017 05:03:31 +0000 Subject: [issue31380] test_undecodable_filename() in Lib/test/test_httpservers.py broken on APFS In-Reply-To: <1504778309.6.0.433500701634.issue31380@psf.upfronthosting.co.za> Message-ID: <1512450211.7.0.213398074469.issue31380@psf.upfronthosting.co.za> Ned Deily added the comment: New changeset d9cadc5f597e5966132c9249f6c7ff0ed1eba0cb by Ned Deily (Miss Islington (bot)) in branch '3.6': [3.6] bpo-31380: Skip test_httpservers test_undecodable_file on macOS. (GH-4720) (#4721) https://github.com/python/cpython/commit/d9cadc5f597e5966132c9249f6c7ff0ed1eba0cb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 00:05:41 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 05 Dec 2017 05:05:41 +0000 Subject: [issue32218] add __iter__ to enum.Flag members In-Reply-To: <1512445452.31.0.213398074469.issue32218@psf.upfronthosting.co.za> Message-ID: <1512450341.94.0.213398074469.issue32218@psf.upfronthosting.co.za> Change by Berker Peksag : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 00:09:03 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 05 Dec 2017 05:09:03 +0000 Subject: [issue31380] test_undecodable_filename() in Lib/test/test_httpservers.py broken on APFS In-Reply-To: <1504778309.6.0.433500701634.issue31380@psf.upfronthosting.co.za> Message-ID: <1512450543.93.0.213398074469.issue31380@psf.upfronthosting.co.za> Ned Deily added the comment: I've chosen to unconditionally skip test_undecodable_filename on macOS; it was already skipped for older macOS systems and I think it would be a mistake to test for a specific error code that could change in later releases. As Ronald points out, testing on Linux should be sufficient. Thanks everyone for your input. Fixed in 3.6.4 and 3.7.0. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 00:44:21 2017 From: report at bugs.python.org (Berker Peksag) Date: Tue, 05 Dec 2017 05:44:21 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512452661.93.0.213398074469.issue19610@psf.upfronthosting.co.za> Berker Peksag added the comment: Thank you for fixing this, Neil. Can we close this issue now? ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 02:08:15 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 05 Dec 2017 07:08:15 +0000 Subject: [issue31145] PriorityQueue.put() fails with TypeError if priority_number in tuples of (priority_number, data) are the same. In-Reply-To: <1502201353.41.0.0622825133632.issue31145@psf.upfronthosting.co.za> Message-ID: <1512457695.6.0.213398074469.issue31145@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, the new dataclasses module makes it really easy to create a wrapper: from dataclasses import dataclass, field from typing import Any @dataclass(order=True) class KeyedItem: key: int item: Any=field(compare=False) def f(): pass def g(): pass print(sorted([KeyedItem(10, f), KeyedItem(5, g)])) I'm thinking of just making an example in the docs and closing this out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 03:19:18 2017 From: report at bugs.python.org (Lele Gaifax) Date: Tue, 05 Dec 2017 08:19:18 +0000 Subject: [issue27645] Supporting native backup facility of SQLite In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za> Message-ID: <1512461958.77.0.213398074469.issue27645@psf.upfronthosting.co.za> Lele Gaifax added the comment: Just to keep the door open, I'm willing to to whatever is needed to see this accepted and merged. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 03:44:11 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 05 Dec 2017 08:44:11 +0000 Subject: [issue32219] SSLWantWriteError being raised by blocking SSL socket In-Reply-To: <1512446468.03.0.213398074469.issue32219@psf.upfronthosting.co.za> Message-ID: <1512463451.01.0.213398074469.issue32219@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You might want to add debugging code in _ssl__SSLSocket_shutdown_impl() (Modules/_ssl.c) and see what happens exactly. Does your socket have a timeout? If not, you may want to ask the OpenSSL mailing-list whether it's possible for SSL_shutdown to return SSL_ERROR_WANT_WRITE on a blocking socket... PS: it seems the _ssl module doesn't retry I/O routines on EINTR. See also https://stackoverflow.com/questions/24188013/openssl-and-signals ---------- components: +Library (Lib) nosy: +pitrou type: -> behavior versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 03:56:06 2017 From: report at bugs.python.org (Nate) Date: Tue, 05 Dec 2017 08:56:06 +0000 Subject: [issue32220] multiprocessing: passing file descriptor using reduction breaks duplex pipes on darwin Message-ID: <1512464166.7.0.213398074469.issue32220@psf.upfronthosting.co.za> New submission from Nate : In multiprocessing/reduction.py, there is a hack workaround in the sendfds() and recvfds() methods for darwin, as determined by the "ACKNOWLEDGE" constant. There is a reference to issue #14669 in the code related to why this was added in the first place. This bug exists in both 3.6.3 and the latest 3.7.0a2. When a file descriptor is received, this workaround/hack sends an acknowledgement message to the sender. The problem is that this completely breaks Duplex pipes depending on the timing of the acknowledgement messages, as your "sock.send(b'A')" and "sock.recv(1) != b'A'" calls are being interwoven with my own messages. Specifically, I have a parent process with child processes. I send socket file descriptors from the parent to the children, and am also duplexing messages from the child processes to the parent. If I am in the process of sending/receiving a message around the same time as your workaround is performing this acknowledge step, then your workaround corrupts the pipe. In a multi-process program, each end of a pipe must only be read or written to by a single process, but this workaround breaks this requirement. A different workaround must be found for the original bug that prompted this "acknowledge" step to be added, because library code must not be interfering with the duplex pipe. ---------- components: Library (Lib) messages: 307649 nosy: frickenate priority: normal severity: normal status: open title: multiprocessing: passing file descriptor using reduction breaks duplex pipes on darwin type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 04:20:06 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 05 Dec 2017 09:20:06 +0000 Subject: [issue32220] multiprocessing: passing file descriptor using reduction breaks duplex pipes on darwin In-Reply-To: <1512464166.7.0.213398074469.issue32220@psf.upfronthosting.co.za> Message-ID: <1512465606.52.0.213398074469.issue32220@psf.upfronthosting.co.za> Antoine Pitrou added the comment: See https://bugs.python.org/issue6560 for the original issue delineating the problems we had with fd passing on macOS. I don't know whether Apple finally fixed the underlying issue. If that was the case, I assume we might be seeing "unexpected successes" in test_socket? Ned, Ronald, is that right? Nate, if you want to investigate the underlying issue and see whether the workaround is still needed and/or another workaround is possible, your help is welcome. ---------- components: +macOS nosy: +ned.deily, pitrou, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 04:20:16 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 05 Dec 2017 09:20:16 +0000 Subject: [issue32220] multiprocessing: passing file descriptor using reduction breaks duplex pipes on darwin In-Reply-To: <1512464166.7.0.213398074469.issue32220@psf.upfronthosting.co.za> Message-ID: <1512465616.65.0.213398074469.issue32220@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 04:54:54 2017 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 05 Dec 2017 09:54:54 +0000 Subject: [issue32221] Converting ipv6 address to string representation using getnameinfo() is wrong. Message-ID: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za> New submission from ???? ????????? : https://github.com/python/cpython/pull/4724 `recvfrom` from multicast socket is painfull slow. In fact, it returns sender address in form: `('fe80::941f:f6ff:fe04:c560%qwe', 42133, 0, 78)` which is superfluous, since interface-name part (`%qwe`) is not actually used. Actually, scopeid (`78`) signify interface/scope/zone_id. This tuple can be used for `.sendto()` either with this interface-name-part or without. The problem is in the performance. For each `recvrfom()`, `getnameinfo()` internally converts interface index to interface name using three syscalls, i.e. `socket(), getsockopt()?, close()` , which slows down receiving (I have not measured result, but see additional syscalls in `strace`). In order to convert from tuple to string-based full address one may use `getnameinfo()`: As you can see, initial interface is ignored (but without my patch it is also validated uselessly): ``` In[1]: socket.getnameinfo(('fe80::941f:f6ff:fe04:c560%qwe', 42133, 0, 78), socket.NI_NUMERICHOST) Out[1]: ('fe80::941f:f6ff:fe04:c560%qwe', '42133') In[2]: socket.getnameinfo(('fe80::941f:f6ff:fe04:c560', 42133, 0, 78), socket.NI_NUMERICHOST) Out[2]: ('fe80::941f:f6ff:fe04:c560%qwe', '42133') ``` ---------- components: Library (Lib) messages: 307651 nosy: socketpair priority: normal severity: normal status: open title: Converting ipv6 address to string representation using getnameinfo() is wrong. type: performance versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 04:55:04 2017 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 05 Dec 2017 09:55:04 +0000 Subject: [issue32221] Converting ipv6 address to string representation using getnameinfo() is wrong. In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za> Message-ID: <1512467704.72.0.213398074469.issue32221@psf.upfronthosting.co.za> Change by ???? ????????? : ---------- keywords: +patch pull_requests: +4631 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 05:36:15 2017 From: report at bugs.python.org (Toby Harradine) Date: Tue, 05 Dec 2017 10:36:15 +0000 Subject: [issue32222] pygettext doesn't extract docstrings for functions with type annotated params Message-ID: <1512470175.69.0.213398074469.issue32222@psf.upfronthosting.co.za> New submission from Toby Harradine : ### Expected Behaviour When running pygettext with the -D CLI flag, all module, class, method and function docstrings should be extracted and outputted to the .pot file. ### Actual Behaviour In the case of functions whose parameters have PEP 484 type annotations, their docstrings are not being extracted. I have attached two files, one .py file and its corresponding .pot file, as examples of this behaviour. ---------- components: Demos and Tools files: test_typehinted_funcs.py messages: 307652 nosy: Toby Harradine priority: normal severity: normal status: open title: pygettext doesn't extract docstrings for functions with type annotated params type: behavior versions: Python 3.5, Python 3.6 Added file: https://bugs.python.org/file47316/test_typehinted_funcs.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 05:37:30 2017 From: report at bugs.python.org (Toby Harradine) Date: Tue, 05 Dec 2017 10:37:30 +0000 Subject: [issue32222] pygettext doesn't extract docstrings for functions with type annotated params In-Reply-To: <1512470175.69.0.213398074469.issue32222@psf.upfronthosting.co.za> Message-ID: <1512470250.49.0.213398074469.issue32222@psf.upfronthosting.co.za> Change by Toby Harradine : Added file: https://bugs.python.org/file47317/pygettext_output.pot _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 05:40:21 2017 From: report at bugs.python.org (Jonathan Watt) Date: Tue, 05 Dec 2017 10:40:21 +0000 Subject: [issue22589] mimetypes uses image/x-ms-bmp as the type for bmp files In-Reply-To: <1412881216.57.0.175210358842.issue22589@psf.upfronthosting.co.za> Message-ID: <1512470421.06.0.213398074469.issue22589@psf.upfronthosting.co.za> Jonathan Watt added the comment: Using image/x-ms-bmp because that's all that IE7 supports makes no sense. Chrome doesn't support image/x-ms-bmp (it only supports the official IANA type image/bmp), so if the concern is over browser support then it's clear that Chrome (the browser with the most market share) should trump IE7 (a browser that stopped getting support/security updates at the beginning of 2016, and has virtually no browser share). ---------- nosy: +jwatt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 05:47:39 2017 From: report at bugs.python.org (Toby Harradine) Date: Tue, 05 Dec 2017 10:47:39 +0000 Subject: [issue32222] pygettext doesn't extract docstrings for functions with type annotated params In-Reply-To: <1512470175.69.0.213398074469.issue32222@psf.upfronthosting.co.za> Message-ID: <1512470859.18.0.213398074469.issue32222@psf.upfronthosting.co.za> Toby Harradine added the comment: Correction for above: the type annotation syntax is actually from PEP 3107, not PEP 484. I should also point out that this behaviour is occurring for annotated return types of functions and methods as well. This is occurring on both Windows and Linux. ---------- Added file: https://bugs.python.org/file47318/test_returntypehinted_funcs.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 05:52:33 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 05 Dec 2017 10:52:33 +0000 Subject: [issue32205] test.pythoninfo does not print the cross-built sysconfig data In-Reply-To: <1512307690.33.0.213398074469.issue32205@psf.upfronthosting.co.za> Message-ID: <1512471153.65.0.213398074469.issue32205@psf.upfronthosting.co.za> Change by Xavier de Gaye : ---------- resolution: -> wont fix stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 06:10:00 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Tue, 05 Dec 2017 11:10:00 +0000 Subject: [issue32219] SSLWantWriteError being raised by blocking SSL socket In-Reply-To: <1512446468.03.0.213398074469.issue32219@psf.upfronthosting.co.za> Message-ID: <1512472200.15.0.213398074469.issue32219@psf.upfronthosting.co.za> Nathaniel Smith added the comment: There's no timeout. The man page claims SSL_ERROR_WANT_WRITE can't happen on a blocking socket, but who knows... Re: EINTR, this is all happening in a child thread. On Linux, this would mean that it almost certainly isn't receiving any signals. I'm not sure about MacOS, though. (POSIX allows signals to be delivered to any thread, but most Unixes are much more conservative in practice.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 06:11:58 2017 From: report at bugs.python.org (Mark Shannon) Date: Tue, 05 Dec 2017 11:11:58 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1512409988.04.0.213398074469.issue17611@psf.upfronthosting.co.za> Message-ID: Mark Shannon added the comment: On 04/12/17 17:53, Neil Schemenauer wrote: > There is a bug with the PR regarding the final bodies. Exits from the final body cause the whole fblock stack to unwind, not just the blocks enclosing the final body. Unwind looks at 'c' to get the fblock stack. I think we need to allocate fblockinfo on the C stack and then use a back pointer to enclosing block. When you get into a final body that creates its own fblockinfo (e.g. a try/except inside the finally), the current code doesn't work. I don't really follow you. Could you provide a code example that will expose this error? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 06:15:03 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 05 Dec 2017 11:15:03 +0000 Subject: [issue32210] Add the versions of the Android SDK and NDK to test.pythoninfo In-Reply-To: <1512380375.09.0.213398074469.issue32210@psf.upfronthosting.co.za> Message-ID: <1512472503.01.0.213398074469.issue32210@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The NDK version may be printed by the pythoninfo make target before test.pythoninfo is run on Android. platform.android_ver() (not yet implemented, see issue 26855) must be added to collect_sys() in test.pythoninfo. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 06:23:04 2017 From: report at bugs.python.org (Jonathan Watt) Date: Tue, 05 Dec 2017 11:23:04 +0000 Subject: [issue22589] mimetypes uses image/x-ms-bmp as the type for bmp files In-Reply-To: <1412881216.57.0.175210358842.issue22589@psf.upfronthosting.co.za> Message-ID: <1512472984.3.0.213398074469.issue22589@psf.upfronthosting.co.za> Jonathan Watt added the comment: I should note that while Chrome will refuse to open an image/x-ms-bmp file directly, when loaded as an image embedded in a document (e.g. via HTML's ) then Chrome doesn't care what MIME type it has. It will sniff the image stream and detect from its contents that it is a BMP image and correctly render it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 07:21:29 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 Dec 2017 12:21:29 +0000 Subject: [issue27240] 'UnstructuredTokenList' object has no attribute '_fold_as_ew' In-Reply-To: <1465208759.2.0.0752415166741.issue27240@psf.upfronthosting.co.za> Message-ID: <1512476489.88.0.213398074469.issue27240@psf.upfronthosting.co.za> R. David Murray added the comment: Huh, I thought I had closed it. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 07:34:26 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 Dec 2017 12:34:26 +0000 Subject: [issue22589] mimetypes uses image/x-ms-bmp as the type for bmp files In-Reply-To: <1412881216.57.0.175210358842.issue22589@psf.upfronthosting.co.za> Message-ID: <1512477266.95.0.213398074469.issue22589@psf.upfronthosting.co.za> R. David Murray added the comment: If image/bmp is now[*] the official IANA type, mimetypes should use that. However, because this is a change with possible backward compatibility issues, it should probably only go into 3.7, but I'm open to arguments about that. [*] The mimetypes module is very old and nobody specifically maintains it; we depend on user reports for updates to it, and obviously this one was overlooked. Care to prepare a PR? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 08:18:57 2017 From: report at bugs.python.org (Jonathan Watt) Date: Tue, 05 Dec 2017 13:18:57 +0000 Subject: [issue22589] mimetypes uses image/x-ms-bmp as the type for bmp files In-Reply-To: <1412881216.57.0.175210358842.issue22589@psf.upfronthosting.co.za> Message-ID: <1512479936.99.0.213398074469.issue22589@psf.upfronthosting.co.za> Jonathan Watt added the comment: > If image/bmp is now[*] the official IANA type You can find image/bmp here: https://www.iana.org/assignments/media-types/media-types.xhtml#image ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 08:19:50 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 05 Dec 2017 13:19:50 +0000 Subject: [issue26855] android: add platform.android_ver() In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za> Message-ID: <1512479990.98.0.213398074469.issue26855@psf.upfronthosting.co.za> STINNER Victor added the comment: Chromium still uses the private __system_property_get() function: https://chromium.googlesource.com/chromium/+/trunk/base/sys_info_android.cc I would prefer a C function call rather than spawning a subprocess, just to get a value. But the function seems private, and I see discussion about removal of the function... ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 08:22:12 2017 From: report at bugs.python.org (Jonathan Watt) Date: Tue, 05 Dec 2017 13:22:12 +0000 Subject: [issue22589] mimetypes uses image/x-ms-bmp as the type for bmp files In-Reply-To: <1412881216.57.0.175210358842.issue22589@psf.upfronthosting.co.za> Message-ID: <1512480132.79.0.213398074469.issue22589@psf.upfronthosting.co.za> Jonathan Watt added the comment: I'm unfamiliar with the Python contribution procedures. If it's simply a case of cloning from github.com and putting up a PR then I can do that. I'm overloaded currently though, so if it's more involved than that it may take me a while to figure things out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 08:44:29 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 05 Dec 2017 13:44:29 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512481469.32.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4632 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 08:52:40 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 Dec 2017 13:52:40 +0000 Subject: [issue22589] mimetypes uses image/x-ms-bmp as the type for bmp files In-Reply-To: <1412881216.57.0.175210358842.issue22589@psf.upfronthosting.co.za> Message-ID: <1512481960.77.0.213398074469.issue22589@psf.upfronthosting.co.za> R. David Murray added the comment: That's the basis, but its a bit more complicated than that (NEWS item, putting bpo-22589 in the issue title, the question of signing a CLA, though a CLA doesn't really matter for this kind of change IMO). If you can't do it one of our core-mentorship volunteers will take care of it, I'm sure. ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 09:12:47 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 05 Dec 2017 14:12:47 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512483167.47.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 33c377ed9b6cb3b9493005314c4e0cfa7517ea65 by Victor Stinner in branch 'master': bpo-32030: Simplify _PyCoreConfig_INIT macro (#4728) https://github.com/python/cpython/commit/33c377ed9b6cb3b9493005314c4e0cfa7517ea65 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 10:36:47 2017 From: report at bugs.python.org (Decorater) Date: Tue, 05 Dec 2017 15:36:47 +0000 Subject: [issue32217] freeze.py fails to work. In-Reply-To: <1512440101.88.0.213398074469.issue32217@psf.upfronthosting.co.za> Message-ID: <1512488207.67.0.213398074469.issue32217@psf.upfronthosting.co.za> Decorater added the comment: python ..\externals\cpython\Tools\freeze\freeze.py pyeimport.py Error: needed directory E:\python360\lib\python3.6\config-3.6 not found Use ``..\externals\cpython\Tools\freeze\freeze.py -h'' for help Seems like freeze works now with no traceback. However on Windows I need to figure out how to make it actually work without ``make install`` because lack of ``make install`` on Windows. :thinking: how can it know on Windows what the config to python could be? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 10:46:51 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 05 Dec 2017 15:46:51 +0000 Subject: [issue26855] android: add platform.android_ver() In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za> Message-ID: <1512488811.27.0.213398074469.issue26855@psf.upfronthosting.co.za> Xavier de Gaye added the comment: I cannot find a reference to the "build.prop" file in the Android documentation but google answers at the question ' what is "build.prop"': The ?build.prop? file is a system file that exists on every Android device. The file contains build information and other system properties which are used throughout the operating system. and stackoverflow is thriving with questions on how to edit this file. The file contains part of the information returned by the getprop command and all the information we are needing here. Here is its content and access rights on an android-24-x86_64 emulator: generic_x86_64:/data/local/tmp/python $ ls -al /system/build.prop -rw-r--r-- 1 root root 2083 2017-07-12 22:01 /system/build.prop generic_x86_64:/data/local/tmp/python $ cat /system/build.prop # begin build properties # autogenerated by buildinfo.sh ro.build.id=NYC ro.build.display.id=sdk_phone_x86_64-userdebug 7.0 NYC 4174735 test-keys ro.build.version.incremental=4174735 ro.build.version.sdk=24 ro.build.version.preview_sdk=0 ro.build.version.codename=REL ro.build.version.all_codenames=REL ro.build.version.release=7.0 ro.build.version.security_patch=2017-06-05 ro.build.version.base_os= ro.build.date=Wed Jul 12 19:46:52 UTC 2017 ro.build.date.utc=1499888812 ro.build.type=userdebug ro.build.user=android-build ro.build.host=wphl5.hot.corp.google.com ro.build.tags=test-keys ro.build.flavor=sdk_phone_x86_64-userdebug ro.product.model=Android SDK built for x86_64 ro.product.brand=Android ro.product.name=sdk_phone_x86_64 ro.product.device=generic_x86_64 ro.product.board= # ro.product.cpu.abi and ro.product.cpu.abi2 are obsolete, # use ro.product.cpu.abilist instead. ro.product.cpu.abi=x86_64 ro.product.cpu.abilist=x86_64,x86 ro.product.cpu.abilist32=x86 ro.product.cpu.abilist64=x86_64 ro.product.manufacturer=unknown ro.product.locale=en-US ro.wifi.channels= ro.board.platform= # ro.build.product is obsolete; use ro.product.device ro.build.product=generic_x86_64 ro.product.cpu.abilist=x86_64,x86 ro.product.cpu.abilist32=x86 ro.product.cpu.abilist64=x86_64 ro.product.manufacturer=unknown ro.product.locale=en-US ro.wifi.channels= ro.board.platform= # ro.build.product is obsolete; use ro.product.device ro.build.product=generic_x86_64 # Do not try to parse description, fingerprint, or thumbprint ro.build.description=sdk_phone_x86_64-userdebug 7.0 NYC 4174735 test-keys ro.build.fingerprint=Android/sdk_phone_x86_64/generic_x86_64:7.0/NYC/4174735:userdebug/test-keys ro.build.characteristics=emulator # end build properties # # from build/target/board/generic_x86_64/system.prop # # # system.prop for generic sdk # rild.libpath=/system/lib/libreference-ril.so rild.libargs=-d /dev/ttyS0 # # ADDITIONAL_BUILD_PROPERTIES # ro.config.notification_sound=OnTheHunt.ogg ro.config.alarm_alert=Alarm_Classic.ogg persist.sys.dalvik.vm.lib.2=libart.so dalvik.vm.isa.x86_64.variant=x86_64 dalvik.vm.isa.x86_64.features=default dalvik.vm.isa.x86.variant=x86 dalvik.vm.isa.x86.features=default dalvik.vm.lockprof.threshold=500 xmpp.auto-presence=true ro.config.nocheckin=yes net.bt.name=Android dalvik.vm.stack-trace-file=/data/anr/traces.txt ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 11:34:30 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 05 Dec 2017 16:34:30 +0000 Subject: [issue32210] Add platform.android_ver() to test.pythoninfo for Android platforms In-Reply-To: <1512380375.09.0.213398074469.issue32210@psf.upfronthosting.co.za> Message-ID: <1512491670.83.0.213398074469.issue32210@psf.upfronthosting.co.za> Change by Xavier de Gaye : ---------- dependencies: +android: add platform.android_ver() title: Add the versions of the Android SDK and NDK to test.pythoninfo -> Add platform.android_ver() to test.pythoninfo for Android platforms _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 11:46:26 2017 From: report at bugs.python.org (Dan) Date: Tue, 05 Dec 2017 16:46:26 +0000 Subject: [issue32223] distutils doesn't correctly read UTF-8 content from config files Message-ID: <1512492386.04.0.213398074469.issue32223@psf.upfronthosting.co.za> New submission from Dan : On Windows, distutils doesn't correctly read UTF-8 content from config files (setup.cfg). Seems like the issue is located on the line reading the files via the ConfigParser; simply adding 'encoding="UTF-8"' as argument fixes the problem for me: https://github.com/python/cpython/pull/4727 On Linux it seems to be working fine. ---------- components: Distutils, Library (Lib), Windows messages: 307668 nosy: delivrance, dstufft, eric.araujo, paul.moore, steve.dower, tim.golden, zach.ware priority: normal pull_requests: 4633 severity: normal status: open title: distutils doesn't correctly read UTF-8 content from config files type: behavior versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 11:57:32 2017 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 05 Dec 2017 16:57:32 +0000 Subject: [issue32223] distutils doesn't correctly read UTF-8 content from config files In-Reply-To: <1512492386.04.0.213398074469.issue32223@psf.upfronthosting.co.za> Message-ID: <1512493052.31.0.213398074469.issue32223@psf.upfronthosting.co.za> ?ric Araujo added the comment: Can you give an example setup.cfg file, setup.py command and the full error message? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 11:57:45 2017 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 05 Dec 2017 16:57:45 +0000 Subject: [issue32223] distutils doesn't correctly read UTF-8 content from config files In-Reply-To: <1512492386.04.0.213398074469.issue32223@psf.upfronthosting.co.za> Message-ID: <1512493065.09.0.213398074469.issue32223@psf.upfronthosting.co.za> Change by ?ric Araujo : ---------- versions: -Python 3.4, Python 3.5, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 12:10:52 2017 From: report at bugs.python.org (Dan) Date: Tue, 05 Dec 2017 17:10:52 +0000 Subject: [issue32223] distutils doesn't correctly read UTF-8 content from config files In-Reply-To: <1512492386.04.0.213398074469.issue32223@psf.upfronthosting.co.za> Message-ID: <1512493852.4.0.213398074469.issue32223@psf.upfronthosting.co.za> Change by Dan : Added file: https://bugs.python.org/file47319/setup.cfg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 12:10:58 2017 From: report at bugs.python.org (Dan) Date: Tue, 05 Dec 2017 17:10:58 +0000 Subject: [issue32223] distutils doesn't correctly read UTF-8 content from config files In-Reply-To: <1512492386.04.0.213398074469.issue32223@psf.upfronthosting.co.za> Message-ID: <1512493858.39.0.213398074469.issue32223@psf.upfronthosting.co.za> Change by Dan : Added file: https://bugs.python.org/file47320/setup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 12:13:50 2017 From: report at bugs.python.org (Dan) Date: Tue, 05 Dec 2017 17:13:50 +0000 Subject: [issue32223] distutils doesn't correctly read UTF-8 content from config files In-Reply-To: <1512492386.04.0.213398074469.issue32223@psf.upfronthosting.co.za> Message-ID: <1512494030.67.0.213398074469.issue32223@psf.upfronthosting.co.za> Dan added the comment: I've attached the files. Run using 'python setup.py sdist'. The resulting PKG-INFO will contain incorrect data: Summary: d??livrance Author: Dan T??s The expected output is: Summary: d?livrance Author: Dan T?s ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 12:21:11 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 05 Dec 2017 17:21:11 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1512494471.85.0.213398074469.issue17611@psf.upfronthosting.co.za> Neil Schemenauer added the comment: There is some more explanation in the PR and sample code. We unwind, if we hit a finally fblock, we emit code of the body of it. If inside the block, there is another return statement, we unwind again. That causes an infinite loop in the compiler. The commit 0610860 is a fix, I think. I have a cleaner version but haven't pushed it yet. There are still some remaining bugs though, caused by "return" in the finally body. The problem as I see it is that "unwind_exception" in ceval pushes a EXCEPT_HANDLER fblock if we are inside a SETUP_EXCEPT or SETUP_FINALLY block. If there is a return in the finally body, the compiler doesn't know if it should POP_BLOCK or not. At least, that is my understanding now. I think the best way forward is to split this patch into multiple parts. I have a simple patch that changes fblockinfo to be a singly linked list (like blockinfo). Next, I think we could change the exception opcodes to have a fixed stack effect (don't think that requires unwind to be done by compiler). Rather than pushing three values for an exception, could we just build a tuple and push that? Seems simpler to me vs having ROT_FOUR. Finally, we can tackle the compiler based unwind. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 12:27:01 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 05 Dec 2017 17:27:01 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1512494821.32.0.213398074469.issue19610@psf.upfronthosting.co.za> Change by Neil Schemenauer : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 12:53:16 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 05 Dec 2017 17:53:16 +0000 Subject: [issue26855] android: add platform.android_ver() In-Reply-To: <1512488811.27.0.213398074469.issue26855@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: "-rw-r--r-- 1 root root 2083 2017-07-12 22:01 /system/build.prop" so anyone can *read* the file. Maybe we can write a cheap parser for it, instead of spawning a subprocess or relying on a private function which may be removed in the near future? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 13:44:11 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 05 Dec 2017 18:44:11 +0000 Subject: [issue30928] Copy modified blurbs to idlelib/NEWS.txt In-Reply-To: <1500004288.4.0.547702885246.issue30928@psf.upfronthosting.co.za> Message-ID: <1512499451.62.0.213398074469.issue30928@psf.upfronthosting.co.za> Terry J. Reedy added the comment: New changeset 7a6f28f2802db3da79b3c2bd5d75e40eb0709744 by Terry Jan Reedy (Miss Islington (bot)) in branch '3.6': bpo-30928: update idlelib/NEWS.txt. (GH-4706) (#4707) https://github.com/python/cpython/commit/7a6f28f2802db3da79b3c2bd5d75e40eb0709744 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 13:44:36 2017 From: report at bugs.python.org (Matthew Stoltenberg) Date: Tue, 05 Dec 2017 18:44:36 +0000 Subject: [issue32224] socket.creaet_connection needs to support full IPv6 argument Message-ID: <1512499476.97.0.213398074469.issue32224@psf.upfronthosting.co.za> New submission from Matthew Stoltenberg : The following causes a ValueError in the create_connection convenience function import socket sock1 = socket.create_connection(('::1', '80')) sock2 = socket.create_connection(sock1.getpeername()) ---------- components: Library (Lib) messages: 307674 nosy: Matthew Stoltenberg priority: normal severity: normal status: open title: socket.creaet_connection needs to support full IPv6 argument type: behavior versions: Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 13:44:54 2017 From: report at bugs.python.org (Matthew Stoltenberg) Date: Tue, 05 Dec 2017 18:44:54 +0000 Subject: [issue32224] socket.create_connection needs to support full IPv6 argument In-Reply-To: <1512499476.97.0.213398074469.issue32224@psf.upfronthosting.co.za> Message-ID: <1512499494.35.0.213398074469.issue32224@psf.upfronthosting.co.za> Change by Matthew Stoltenberg : ---------- title: socket.creaet_connection needs to support full IPv6 argument -> socket.create_connection needs to support full IPv6 argument _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 14:22:08 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 05 Dec 2017 19:22:08 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512501728.45.0.213398074469.issue32199@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Over in the PR I suggested: Here's another thought: what if you just added another getter that calls ip link list and placed that after one that calls ip link. Wouldn't that accomplish both goals? Then if ip link fails, we fall back to the old behavior, so nothing changes. It's uglier, but it doesn't special case for the Android platform, and eventually we can decide to remove ip link list altogether. ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 14:25:42 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Tue, 05 Dec 2017 19:25:42 +0000 Subject: [issue31506] Improve the error message logic for object_new & object_init In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za> Message-ID: <1512501942.95.0.213398074469.issue31506@psf.upfronthosting.co.za> Sanyam Khurana added the comment: I'll work on a fix for this and issue a PR. ---------- nosy: +CuriousLearner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 14:26:48 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Dec 2017 19:26:48 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512502008.36.0.213398074469.issue32199@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why the 'ip link list' command fails on Android at first place? Does Android use its own independent implementation? Or its version is based on the fork of very old version of iproute2 that didn't supported the list command (if there was such version)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 14:33:57 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 05 Dec 2017 19:33:57 +0000 Subject: [issue31506] Improve the error message logic for object_new & object_init In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za> Message-ID: <1512502437.85.0.213398074469.issue31506@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think the main problem is not with coding, but with design. And from this point of view this may be not so easy issue. Let wait until Nick has a time to work on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 14:40:41 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Tue, 05 Dec 2017 19:40:41 +0000 Subject: [issue31506] Improve the error message logic for object_new & object_init In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za> Message-ID: <1512502841.48.0.213398074469.issue31506@psf.upfronthosting.co.za> Sanyam Khurana added the comment: Nick, I think the error messages are incorrect. We expect error message to be `takes no argument` rather than `takes exactly one argument`. Can you please confirm that? I think for the class without any method overrides, the functionality should be something like this: >>> class C: ... pass ... >>> C(42) Traceback (most recent call last): File "", line 1, in TypeError: C() takes no arguments >>> C.__new__(C, 42) Traceback (most recent call last): File "", line 1, in TypeError: C() takes no arguments >>> C().__init__(42) Traceback (most recent call last): File "", line 1, in TypeError: C().__init__() takes no arguments >>> object.__new__(C, 42) Traceback (most recent call last): File "", line 1, in TypeError: C() takes no arguments >>> object.__init__(C(), 42) Traceback (most recent call last): File "", line 1, in TypeError: C().__init__() takes no arguments Is that correct? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 15:16:25 2017 From: report at bugs.python.org (Mark Shannon) Date: Tue, 05 Dec 2017 20:16:25 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1512504985.57.0.213398074469.issue17611@psf.upfronthosting.co.za> Mark Shannon added the comment: 0610860 doesn't include any tests. What is it fixing? 3794016 passes the same set of tests. Do have an actual code example that produces erroneous behaviour? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 15:17:11 2017 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 05 Dec 2017 20:17:11 +0000 Subject: [issue16487] Allow ssl certificates to be specified from memory rather than files. In-Reply-To: <1353078615.85.0.973290481578.issue16487@psf.upfronthosting.co.za> Message-ID: <1512505031.5.0.213398074469.issue16487@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Hi Cristian, > I don't want to have three ways to load certificates, especially when it involves more C code. I think this (more C code) is the primary and the *only* negative point against the current patch. And that seems necessary for the feature specific to OpenSSL. Not sure if you looked at the latest version (https://github.com/python/cpython/pull/2449/files) recently. The current patch does not deviate in-principle from the PEP 543. It maintains the same API arguments ` SSLContext.load_cert_chain(certfile, keyfile=None, password=None)` * We expect the migration of ssl module to newer ABC of PEP-543 not be one-to-one. We could foresee this API living. (And we haven't deprecated this API). * The patch provides the feature along with plenty of tests that PEP-543 talks about (Loading of certs from memory). * Has an implementation refactorable for OpenSSL-specific TLS backend (as one of the provider), that again will be useful to PEP-543 implementation. These are the benefits in my opinion. PEP-543 is important and seems like a *major effort*. The current patch might still be valuable and perhaps might be useful towards PEP-543 implementation. It deals only with certificates only. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 15:30:14 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Tue, 05 Dec 2017 20:30:14 +0000 Subject: [issue32225] Implement PEP 562: module __getattr__ and __dir__ Message-ID: <1512505814.96.0.213398074469.issue32225@psf.upfronthosting.co.za> Change by Ivan Levkivskyi : ---------- assignee: levkivskyi components: Interpreter Core nosy: levkivskyi priority: normal severity: normal stage: patch review status: open title: Implement PEP 562: module __getattr__ and __dir__ type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 15:31:15 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Tue, 05 Dec 2017 20:31:15 +0000 Subject: [issue32225] Implement PEP 562: module __getattr__ and __dir__ Message-ID: <1512505875.19.0.213398074469.issue32225@psf.upfronthosting.co.za> Change by Ivan Levkivskyi : ---------- keywords: +patch pull_requests: +4634 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 15:36:48 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Tue, 05 Dec 2017 20:36:48 +0000 Subject: [issue32226] Implement PEP 560: Core support for typing module and generic types Message-ID: <1512506208.45.0.213398074469.issue32226@psf.upfronthosting.co.za> Change by Ivan Levkivskyi : ---------- assignee: levkivskyi components: Interpreter Core, Library (Lib) nosy: levkivskyi priority: normal severity: normal stage: needs patch status: open title: Implement PEP 560: Core support for typing module and generic types type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 15:38:12 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Tue, 05 Dec 2017 20:38:12 +0000 Subject: [issue32226] Implement PEP 560: Core support for typing module and generic types Message-ID: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za> New submission from Ivan Levkivskyi : As discussed before, there will be two PRs. One for the core components, and the second one (large) for typing updates. I will open the first PR shortly. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 15:48:27 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Tue, 05 Dec 2017 20:48:27 +0000 Subject: [issue32226] Implement PEP 560: Core support for typing module and generic types In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za> Message-ID: <1512506907.7.0.213398074469.issue32226@psf.upfronthosting.co.za> Change by Ivan Levkivskyi : ---------- keywords: +patch pull_requests: +4635 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 15:57:02 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 05 Dec 2017 20:57:02 +0000 Subject: [issue32215] sqlite3 400x-600x slower depending on formatting of an UPDATE statement in a string In-Reply-To: <1512434453.0.0.213398074469.issue32215@psf.upfronthosting.co.za> Message-ID: <1512507422.24.0.213398074469.issue32215@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Brian, does the speed difference disappear when you add a space character just after "UPDATE"? We may be hitting this path: https://github.com/python/cpython/blob/master/Modules/_sqlite/statement.c#L76-L93 ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 16:02:38 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 05 Dec 2017 21:02:38 +0000 Subject: [issue9924] sqlite3 SELECT does not BEGIN a transaction, but should according to spec In-Reply-To: <1285214166.49.0.269440190097.issue9924@psf.upfronthosting.co.za> Message-ID: <1512507758.48.0.213398074469.issue9924@psf.upfronthosting.co.za> Antoine Pitrou added the comment: See https://bugs.python.org/issue32215 for what seems to be a related bug. Also note that pysqlite now seems to be using a different logic: https://github.com/ghaering/pysqlite/blob/master/src/cursor.c#L537-L548 Also this changeset: https://github.com/ghaering/pysqlite/commit/94eae5002967a51782f36ce9b7b81bba5b4379db As a sidenote, this seems to mean that the stdlib sqlite module doesn't receive updates anymore from its author...? ---------- nosy: +pitrou, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 16:06:41 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 05 Dec 2017 21:06:41 +0000 Subject: [issue9924] sqlite3 SELECT does not BEGIN a transaction, but should according to spec In-Reply-To: <1285214166.49.0.269440190097.issue9924@psf.upfronthosting.co.za> Message-ID: <1512508001.08.0.213398074469.issue9924@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 16:06:56 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 05 Dec 2017 21:06:56 +0000 Subject: [issue9924] sqlite3 SELECT does not BEGIN a transaction, but should according to spec In-Reply-To: <1285214166.49.0.269440190097.issue9924@psf.upfronthosting.co.za> Message-ID: <1512508016.26.0.213398074469.issue9924@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- assignee: ghaering -> versions: +Python 3.7 -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 16:10:30 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 05 Dec 2017 21:10:30 +0000 Subject: [issue26855] android: add platform.android_ver() In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za> Message-ID: <1512508230.22.0.213398074469.issue26855@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Yes, and fall back to spawning getprop if that fails. In the following link Robin Gawenda is reporting that /system/build.prop is world readable on all the devices he checked: https://stackoverflow.com/questions/9937099/how-to-get-the-build-prop-values ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 16:24:12 2017 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Tue, 05 Dec 2017 21:24:12 +0000 Subject: [issue32227] singledispatch support for type annotations Message-ID: <1512509052.55.0.213398074469.issue32227@psf.upfronthosting.co.za> New submission from ?ukasz Langa : With the patch attached to this issue, @singledispatch gains support for passing the type in @register via annotations. This looks more natural and enables more thorough type checking without repeating yourself: @singledispatch def generic(arg): ... @generic.register def _(arg: str): ... @generic.register def _(arg: int): ... The previous API is still available for backwards compatibility, as well as stacking, and use with classes (sic, I was surprised to learn it's used that way, too). The patch should be uncontroversial, maybe except for the fact that it's importing the `typing` module if annotations are used. This is necessary because of forward references, usage of None as a type, and so on. More importantly, with PEP 563 it's mandatory. ---------- assignee: lukasz.langa components: Library (Lib) messages: 307686 nosy: lukasz.langa, rhettinger, yselivanov priority: normal severity: normal status: open title: singledispatch support for type annotations type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 16:24:42 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 05 Dec 2017 21:24:42 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1512509082.72.0.213398074469.issue17611@psf.upfronthosting.co.za> Neil Schemenauer added the comment: def func(): try: try: raise RuntimeError except: return 1 finally: return 3 func() Sorry, I've been collecting a whole slew of code snippets that cause issues with the "unwind_stack" branch. I haven't organized them and made unit tests out of them though. Two packages I found hairy try/except/finally code are "tox" and "gevent". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 16:26:44 2017 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Tue, 05 Dec 2017 21:26:44 +0000 Subject: [issue32227] singledispatch support for type annotations In-Reply-To: <1512509052.55.0.213398074469.issue32227@psf.upfronthosting.co.za> Message-ID: <1512509204.66.0.213398074469.issue32227@psf.upfronthosting.co.za> Change by ?ukasz Langa : ---------- keywords: +patch pull_requests: +4636 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 16:28:23 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 05 Dec 2017 21:28:23 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512509302.99.0.213398074469.issue32199@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The result of various 'ip' commands on Android, the last 'ip link list' command is run as root and succeeds (did not think about trying that before): generic_x86_64:/data/local/tmp/python $ ip link list request send failed: Permission denied 1|generic_x86_64:/data/local/tmp/python $ ip link help request send failed: Permission denied 1|generic_x86_64:/data/local/tmp/python $ ip link 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 3: wlan0: mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000 link/ether 02:00:00:44:55:66 brd ff:ff:ff:ff:ff:ff 5: hwsim0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default link/ieee802.11/radiotap 12:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 6: sit0: mtu 1480 qdisc noop state DOWN mode DEFAULT group default link/sit 0.0.0.0 brd 0.0.0.0 8: radio0: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 22:d5:92:86:1a:d8 brd ff:ff:ff:ff:ff:ff generic_x86_64:/data/local/tmp/python # ip link list 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 3: wlan0: mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000 link/ether 02:00:00:44:55:66 brd ff:ff:ff:ff:ff:ff 5: hwsim0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default link/ieee802.11/radiotap 12:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 6: sit0: mtu 1480 qdisc noop state DOWN mode DEFAULT group default link/sit 0.0.0.0 brd 0.0.0.0 8: radio0: mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000 link/ether 22:d5:92:86:1a:d8 brd ff:ff:ff:ff:ff:ff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 16:29:13 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 05 Dec 2017 21:29:13 +0000 Subject: [issue32215] sqlite3 400x-600x slower depending on formatting of an UPDATE statement in a string In-Reply-To: <1512434453.0.0.213398074469.issue32215@psf.upfronthosting.co.za> Message-ID: <1512509353.16.0.213398074469.issue32215@psf.upfronthosting.co.za> R. David Murray added the comment: It disappears for me running it on linux with the blank added. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 16:40:04 2017 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Tue, 05 Dec 2017 21:40:04 +0000 Subject: [issue32227] singledispatch support for type annotations In-Reply-To: <1512509052.55.0.213398074469.issue32227@psf.upfronthosting.co.za> Message-ID: <1512510004.95.0.213398074469.issue32227@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Guido, I know that you have a lot on your plate right now. Adding you because of PEP 443 and PEP 484. ---------- nosy: +gvanrossum stage: patch review -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 16:42:42 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Tue, 05 Dec 2017 21:42:42 +0000 Subject: [issue32227] singledispatch support for type annotations In-Reply-To: <1512509052.55.0.213398074469.issue32227@psf.upfronthosting.co.za> Message-ID: <1512510162.04.0.213398074469.issue32227@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Idea looks interesting (like a basic runtime @overload). My expectation is that some changes are necessary in mypy for this to work properly. Another (minor) problem is that this creates a circular dependency functools <-> typing. ---------- nosy: +levkivskyi -gvanrossum stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 16:43:57 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Tue, 05 Dec 2017 21:43:57 +0000 Subject: [issue32227] singledispatch support for type annotations In-Reply-To: <1512509052.55.0.213398074469.issue32227@psf.upfronthosting.co.za> Message-ID: <1512510237.62.0.213398074469.issue32227@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Oops something wrong happened. ---------- nosy: +gvanrossum stage: patch review -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 16:58:51 2017 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Tue, 05 Dec 2017 21:58:51 +0000 Subject: [issue32227] singledispatch support for type annotations In-Reply-To: <1512509052.55.0.213398074469.issue32227@psf.upfronthosting.co.za> Message-ID: <1512511131.58.0.213398074469.issue32227@psf.upfronthosting.co.za> ?ukasz Langa added the comment: > this creates a circular dependency functools <-> typing Well, it doesn't since I explicitly import typing inside singledispatch. By the time this import happens, functools is fully imported. This would only be a problem if functools itself tried to use singledispatch with annotations. Not impossible but super unlikely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 17:11:45 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 05 Dec 2017 22:11:45 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1512511905.03.0.213398074469.issue29240@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- title: [WIP] Implementation of the PEP 540: Add a new UTF-8 mode -> PEP 540: Add a new UTF-8 mode _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 17:12:00 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 05 Dec 2017 22:12:00 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1512511920.19.0.213398074469.issue29240@psf.upfronthosting.co.za> STINNER Victor added the comment: I rebased my PR on master. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 17:12:11 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 05 Dec 2017 22:12:11 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1512511931.39.0.213398074469.issue29240@psf.upfronthosting.co.za> Change by STINNER Victor : Removed file: https://bugs.python.org/file46270/pep540-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 17:12:12 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 05 Dec 2017 22:12:12 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1512511932.38.0.213398074469.issue29240@psf.upfronthosting.co.za> Change by STINNER Victor : Removed file: https://bugs.python.org/file46263/pep540-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 17:12:13 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 05 Dec 2017 22:12:13 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1512511933.14.0.213398074469.issue29240@psf.upfronthosting.co.za> Change by STINNER Victor : Removed file: https://bugs.python.org/file46262/pep540-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 17:12:14 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 05 Dec 2017 22:12:14 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1512511934.03.0.213398074469.issue29240@psf.upfronthosting.co.za> Change by STINNER Victor : Removed file: https://bugs.python.org/file46258/pep540.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 17:12:14 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 05 Dec 2017 22:12:14 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1512511934.95.0.213398074469.issue29240@psf.upfronthosting.co.za> Change by STINNER Victor : Removed file: https://bugs.python.org/file46257/pep540_cli.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 17:12:31 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 05 Dec 2017 22:12:31 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1512511951.14.0.213398074469.issue29240@psf.upfronthosting.co.za> Change by STINNER Victor : Removed file: https://bugs.python.org/file46274/encodings.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 17:12:54 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 05 Dec 2017 22:12:54 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1512511974.19.0.213398074469.issue29240@psf.upfronthosting.co.za> STINNER Victor added the comment: I removed old patches in favor of the now up to date PR 855. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 17:35:54 2017 From: report at bugs.python.org (Brian Forst) Date: Tue, 05 Dec 2017 22:35:54 +0000 Subject: [issue32215] sqlite3 400x-600x slower depending on formatting of an UPDATE statement in a string In-Reply-To: <1512434453.0.0.213398074469.issue32215@psf.upfronthosting.co.za> Message-ID: <1512513354.17.0.213398074469.issue32215@psf.upfronthosting.co.za> Brian Forst added the comment: Hi Antoine, yup, adding a space after the UPDATE makes the speed difference disappear on macOS Sierra and Windows 7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 17:52:19 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 05 Dec 2017 22:52:19 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512509302.99.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: Barry A. Warsaw added the comment: On Dec 5, 2017, at 16:28, Xavier de Gaye wrote: > > The result of various 'ip' commands on Android, the last 'ip link list' command is run as root and succeeds (did not think about trying that before): > > generic_x86_64:/data/local/tmp/python $ ip link list > request send failed: Permission denied > > 1|generic_x86_64:/data/local/tmp/python $ ip link help > request send failed: Permission denied > > 1|generic_x86_64:/data/local/tmp/python $ ip link ?[output]? Well, that?s weird! -B ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 18:19:14 2017 From: report at bugs.python.org (andreymal) Date: Tue, 05 Dec 2017 23:19:14 +0000 Subject: [issue32228] truncate() changes tell() result Message-ID: <1512515954.76.0.213398074469.issue32228@psf.upfronthosting.co.za> New submission from andreymal : See attached file. As documentation about "truncate" says, "The current stream position isn?t changed." This is true for most cases. But this is not true for "wtf1.py" example. If you run it with Linux (Tested Debian 8 and Arch; Windows was not tested by me) and Python 3.3+ (or with Python 2.7 using backported "io" module), then these lines: print('tell:', fp.tell()) print('truncate:', fp.truncate()) print('tell again:', fp.tell()) prints this: tell: 4098 truncate: 4098 tell again: 4 As you can see, "tell" before truncate and "tell" after truncate are different. Looks like bug. This bug will not reproduce with Python 2.7 and builtin "open" function; it affects only "io.open". ---------- components: IO files: wtf1.py messages: 307698 nosy: andreymal priority: normal severity: normal status: open title: truncate() changes tell() result versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: https://bugs.python.org/file47321/wtf1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 18:21:27 2017 From: report at bugs.python.org (andreymal) Date: Tue, 05 Dec 2017 23:21:27 +0000 Subject: [issue32228] truncate() changes current stream position In-Reply-To: <1512515954.76.0.213398074469.issue32228@psf.upfronthosting.co.za> Message-ID: <1512516087.6.0.213398074469.issue32228@psf.upfronthosting.co.za> Change by andreymal : ---------- title: truncate() changes tell() result -> truncate() changes current stream position _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 18:30:42 2017 From: report at bugs.python.org (andreymal) Date: Tue, 05 Dec 2017 23:30:42 +0000 Subject: [issue32228] truncate() changes current stream position In-Reply-To: <1512515954.76.0.213398074469.issue32228@psf.upfronthosting.co.za> Message-ID: <1512516642.71.0.213398074469.issue32228@psf.upfronthosting.co.za> Change by andreymal : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 22:43:27 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Dec 2017 03:43:27 +0000 Subject: [issue31506] Improve the error message logic for object_new & object_init In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za> Message-ID: <1512531807.12.0.213398074469.issue31506@psf.upfronthosting.co.za> Nick Coghlan added the comment: Aye, I think Sanyam's proposed messages look good, and the "C().__init__() takes no arguments" wording is easier to follow than my suggested "C.__init__() takes exactly one argument" wording (as interpreting the latter currently requires noticing that it's referring to the *unbound* method taking one argument: the instance). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 23:08:14 2017 From: report at bugs.python.org (Nate) Date: Wed, 06 Dec 2017 04:08:14 +0000 Subject: [issue32220] multiprocessing: passing file descriptor using reduction breaks duplex pipes on darwin In-Reply-To: <1512464166.7.0.213398074469.issue32220@psf.upfronthosting.co.za> Message-ID: <1512533294.1.0.213398074469.issue32220@psf.upfronthosting.co.za> Nate added the comment: According to https://developer.apple.com/library/content/qa/qa1541/_index.html some bugs were fixed in 10.5. Not sure if the original attempt to patch the problem was happening on < 10.5, or if this was still a problem in 10.5+. I can't for the life of me find it again, but I had found another source that claimed the true fixes for OS X came out with 10.7. In any case, because this code is specifically part of the multiprocessing package, whereby it should be *expected* for multiple processes to be accessing the pipe, it's disastrous for this code to be reading/writing an acknowledge packet in this manner. This is a hard case to test for, as timing matters. The duplex pipe doesn't get confused/corrupted unless one process is sending/receiving a message over the pipe at the same moment that another process is executing your acknowledge logic. It's reproducible, but not 100%. Personally, I've restructured to using one pipe exclusively for file descriptor passing, and using a separate Queue (or Pipe pair) for custom message passing. If a better fix cannot be established, at a minimum the documentation for multiprocessing and the Pipe class should be updated with a big red warning about passing file descriptors on OS X/macOS/darwin. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 5 23:33:06 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Dec 2017 04:33:06 +0000 Subject: [issue32229] Simplify hiding developer warnings in user facing applications Message-ID: <1512534786.28.0.213398074469.issue32229@psf.upfronthosting.co.za> New submission from Nick Coghlan : One of the observations coming out of the PEP 565 discussions is that it's surprisingly tricky to opt-in to getting all warnings from a particular package and its subpackages, while opting out of warnings in general. The simplest approximation is to do the following: if not sys.warnoptions: warnings.simplefilter("ignore") warnings.filterwarnings("default", module="app_pkg.*") That shows warnings for any module or package starting with `app_pkg`. A stricter filter that avoided warnings from top-level packages that merely shared the prefix would look like: if not sys.warnoptions: warnings.simplefilter("ignore") warnings.filterwarnings("default", module="^app_pkg(\..*)?$") It could be helpful to encapsulate that logic in a more declarative utility API, such that applications could do the following: import warnings. warnings.hide_warnings() Or: import warnings. warnings.hide_warnings(override_warnoptions=True) Or: import warnings. warnings.hide_warnings(show=["app_pkg"]) Proposed API: def hide_warnings(*, show=(), override_warnoptions=False): if override_warnoptions or not sys.warnoptions: simplefilter("ignore") for pkg_name in show: pkg_filter = _make_regex_for_pkg(pkg_name) filterwarnings("default", module=pkg_filter) ---------- messages: 307701 nosy: ncoghlan priority: normal severity: normal stage: needs patch status: open title: Simplify hiding developer warnings in user facing applications type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 00:00:46 2017 From: report at bugs.python.org (Berker Peksag) Date: Wed, 06 Dec 2017 05:00:46 +0000 Subject: [issue32215] sqlite3 400x-600x slower depending on formatting of an UPDATE statement in a string In-Reply-To: <1512434453.0.0.213398074469.issue32215@psf.upfronthosting.co.za> Message-ID: <1512536446.2.0.213398074469.issue32215@psf.upfronthosting.co.za> Change by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 01:30:22 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Dec 2017 06:30:22 +0000 Subject: [issue6531] atexit_callfuncs() crashing within Py_Finalize() when using multiple interpreters. In-Reply-To: <1248175169.79.0.15962102552.issue6531@psf.upfronthosting.co.za> Message-ID: <1512541822.63.0.213398074469.issue6531@psf.upfronthosting.co.za> Nick Coghlan added the comment: See also https://bugs.python.org/issue31901, which reached a similar conclusion to this discussion (i.e. atexit functions should be run when the subinterpreter goes away). ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 02:02:33 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Dec 2017 07:02:33 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512543753.51.0.213398074469.issue32199@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What if "ip link list" was intentionally prohibited "for security reasons", and "ip link" works just due to oversight? Xavier, could you please inspect the sources of the ip command on Android? Is it the standard iproute2 with additional patches prohibiting the part of the functionality? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 02:06:23 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 06 Dec 2017 07:06:23 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512543983.31.0.213398074469.issue32199@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Whatever the change made to fix this issue, it is not possible to add a test case for this change. So following the suggestion made by Barry in PR 4696, we can add (in another issue) a new keyword parameter to getnode() named 'methods' whose value may be None (the default, meaning try all the known methods) or a tuple containing a subset of the following methods ('unix', 'ifconfig', 'ip', 'arp', 'lanscan', 'netstat', 'random') that would raise an exception if the value cannot be obtained using one of the requested method tried in the requested order. This would also improve the documentation on the methods getnode() is using. Then if we decide to make the change for 'ip link' in the current issue, one can add a test case that would first test for the avaibility of the ip command and if the command exists would fail if getnode(methods=('ip',)) raises an exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 03:04:34 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 06 Dec 2017 08:04:34 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512547474.49.0.213398074469.issue32199@psf.upfronthosting.co.za> Xavier de Gaye added the comment: You may be right Serhiy. Those tests have been run on the emulator at API 24 (Android 7.0 Nougat, the first API version where SELinux is run in enforced mode) where 'ip link list' fails, but on my device (a Samsung API 21, Android 5.1 Lollipop) running the 'ip link list' (using the termux package installed from google PlayStore) the command is ok. The Android source of iproute2 can be: * browsed at: https://android.googlesource.com/platform/external/iproute2/+/master * cloned from: https://android.googlesource.com/platform/external/iproute2/ They are using iproute2-3.4.0 released in 2012, see README.version. I checked that the ip/ subdirectory on the Android master branch is unchanged from upstream 3.4.0 at https://www.kernel.org/pub/linux/utils/net/iproute2/. The Android SELinux policies are at: https://android.googlesource.com/platform/system/sepolicy/ Does someone know how to read them ? Maybe we should just close this issue as 'wont fix' then. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 03:21:07 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 06 Dec 2017 08:21:07 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512548467.54.0.213398074469.issue32199@psf.upfronthosting.co.za> Xavier de Gaye added the comment: 'adb logcat' is a tool that monitors many kind of events on Android. Both ip commands prints a SElinux record on logcat: Upon the successfull 'ip link' command, logcat prints: 12-06 09:17:24.119 2460 2460 W ip : type=1400 audit(0.0:8): avc: denied { search } for name="net" dev="vdc" ino=91 scontext=u:r:shell:s0 tcontext=u:object_r:net_data_file:s0 tclass=dir permissive=0 Upon the failed 'ip link' command, logcat prints: 12-06 09:17:42.109 2461 2461 W ip : type=1400 audit(0.0:9): avc: denied { nlmsg_write } for scontext=u:r:shell:s0 tcontext=u:r:shell:s0 tclass=netlink_route_socket permissive=0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 03:24:02 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 06 Dec 2017 08:24:02 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512548642.47.0.213398074469.issue32199@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Oops, the second failed command is 'ip link list' of course. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 03:37:10 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 06 Dec 2017 08:37:10 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512549430.46.0.213398074469.issue32199@psf.upfronthosting.co.za> Xavier de Gaye added the comment: It is also possible that rather than an oversight in Android, it is a side effect of SELinux on the implementation of iproute2 if the 'ip link list' command does a little bit more than the 'ip link' command and if this 'little bit more' is prohibited by a SELinux policy. I guess this means diving into the source of iproute2 to confirm that :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 03:41:00 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Dec 2017 08:41:00 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions Message-ID: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> New submission from Nick Coghlan : The `-X dev` option is currently integrated directly with the warnings module, rather than working indirectly through `sys.warnoptions`. This means that any third party code that currently checks sys.warnoptions will need to be updated to check sys.flags.dev_mode as well. Rather than doing that, I propose that we instead change the way dev mode works to *literally* be equivalent to `-Wdefault`, and remove the direct integration with the warnings machinery. (PR for that coming shortly) ---------- assignee: ncoghlan messages: 307709 nosy: ncoghlan, vstinner priority: normal severity: normal stage: test needed status: open title: -X dev doesn't set sys.warnoptions type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 04:07:03 2017 From: report at bugs.python.org (Vincas Dargis) Date: Wed, 06 Dec 2017 09:07:03 +0000 Subject: [issue18943] argparse: default args in mutually exclusive groups In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za> Message-ID: <1512551223.65.0.213398074469.issue18943@psf.upfronthosting.co.za> Vincas Dargis added the comment: Any progress with this? I believe it would fix my use case: ``` import argparse import pprint parser = argparse.ArgumentParser() group = parser.add_mutually_exclusive_group(required=True) group.add_argument('--device-get-capabilities', action='store_true', help='Execute GetCapabilities action from ONVIF devicemgmt.wsdl') group.add_argument('--ptz-absolute-move', nargs=3, metavar=('x', 'y', 'z'), help='Execute AbsoluteMove action from ONVIF ptz.wsdl') group.add_argument('--ptz-get-status', metavar='MEDIA_PROFILE', default='MediaProfile000', help='Execute GetSatus action from ONVIF ptz.wsdl for a media profile (default=%(default)s)') pprint.pprint(parser.parse_args(['--ptz-get-status'])) ``` Outputs (using 3.6.3): ``` python3 ./test-ex-group-with-defult.py usage: test-ex-group-with-defult.py [-h] (--device-get-capabilities | --ptz-absolute-move x y z | --ptz-get-status MEDIA_PROFILE) test-ex-group-with-defult.py: error: argument --ptz-get-status: expected one argument ``` Are there know workarounds for this? ---------- nosy: +talkless _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 04:31:37 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 09:31:37 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions In-Reply-To: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I did it on purpose. -Wdefault adds the filter at the start, whereas -Xdev adds the filter at the end to respect BytesWarning. See tests in test_cmd_line and bpo-32089. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 04:49:48 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Dec 2017 09:49:48 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions In-Reply-To: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> Message-ID: <1512553788.08.0.213398074469.issue32230@psf.upfronthosting.co.za> Nick Coghlan added the comment: Note that this change will make "-X dev" effectively treat "-bb" and "-b" as equivalent, the same way "-Wd" already does. I figure that's OK, since it means the runtime behaviour will match the documentation (which says that "-X dev" implies "-Wd". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 04:56:25 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 09:56:25 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions In-Reply-To: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> Message-ID: <1512554185.43.0.213398074469.issue32230@psf.upfronthosting.co.za> STINNER Victor added the comment: I was explicitly asked to not change the behaviour of BytesWarning with -X dev. -X dev documentation doesn't menton -Wd/-Wdefault anymore: https://docs.python.org/dev/using/cmdline.html#id5 "Warning filters: add a filter to display all warnings ("default" action), except of BytesWarning which still depends on the -b option, and use "always" action for ResourceWarning warnings. For example, display DeprecationWarning warnings." Another implementation issue is subprocess._args_from_interpreter_flags() which was unable to properly "rebuild" the -X dev option from sys.warnoptions. I mean that it's now simpler and safer with sys.flags.dev_mode. But I agree that the fact that -X dev doesn't touch sys.warnoptions is surprising and can cause issues. IMHO sys.warnoptions shouldn't exist in the first place. It looks like a hack to pass options from the C main() function to the warnings initilization code. But it's not like we can remove it right now :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 05:13:30 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 06 Dec 2017 10:13:30 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512555210.97.0.213398074469.issue32199@psf.upfronthosting.co.za> Change by Xavier de Gaye : Added file: https://bugs.python.org/file47322/ip_link.strace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 05:17:53 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Dec 2017 10:17:53 +0000 Subject: [issue32220] multiprocessing: passing file descriptor using reduction breaks duplex pipes on darwin In-Reply-To: <1512533294.1.0.213398074469.issue32220@psf.upfronthosting.co.za> Message-ID: Antoine Pitrou added the comment: Le 06/12/2017 ? 05:08, Nate a ?crit?: > > This is a hard case to test for, as timing matters. The duplex pipe doesn't get confused/corrupted unless one process is sending/receiving a message over the pipe at the same moment that another process is executing your acknowledge logic. It's reproducible, but not 100%. Our test runner has support for running a test in a loop until it fails. For example `./python -m test -m "*FDPass*" -F -v test_socket` Combined with perhaps a new test case, this could help you diagnose if indeed the workaround is obsolete. (perhaps our resident macOS experts can help too :-)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 05:26:59 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 06 Dec 2017 10:26:59 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512556019.18.0.213398074469.issue32199@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Attached ip_link.strace and ip_link_list.strace, the output of strace for the 'ip link' and 'ip link list' commands. At the end of the process, both commands create an PF_NETLINK socket to receive from the kernel link information through the NETLINK_ROUTE group. The sendto() function fails with EACCES for 'ip link list' and its SELinux avc record relates to this event (the netlink prefix used throughout the documentation [1] is 'nlmsg' and the resource denied in the avc record is 'nlmsg_write'). The SELinux avc record for 'ip link' relates to a failed attempt to open "/data/misc/net/group" (it does not exist). [1] http://man7.org/linux/man-pages/man7/netlink.7.html ---------- Added file: https://bugs.python.org/file47323/ip_link_list.strace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 05:27:57 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Dec 2017 10:27:57 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions In-Reply-To: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> Message-ID: <1512556077.42.0.213398074469.issue32230@psf.upfronthosting.co.za> Change by Nick Coghlan : ---------- keywords: +patch pull_requests: +4637 stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 05:37:12 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Dec 2017 10:37:12 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions In-Reply-To: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> Message-ID: <1512556632.15.0.213398074469.issue32230@psf.upfronthosting.co.za> Nick Coghlan added the comment: It isn't good to have "-X dev" do magical things that can't already be replicated with other options. If we want "-bb" to take precedence over the passed in "-W" settings (which I agree would be a reasonable change), we should make that change universally, not restrict it to "-X dev". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 05:43:15 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Dec 2017 10:43:15 +0000 Subject: [issue32231] -bb option should override -W options Message-ID: <1512556995.36.0.213398074469.issue32231@psf.upfronthosting.co.za> New submission from Nick Coghlan : When implementing the "-X dev" mode, Victor was asked to make it behave differently from "-Wd", such that "python -bb -X dev" would still raise errors for bytes comparisons. I don't think making "-X dev" and "-Wd" inconsistent with each other is the right way to address that request. Instead, I think we should find a way to make "-bb" *always* take precedence over any supplied "-W" options. One way to do that would be to adopt an approach similar to what I've proposed for "-X dev" in https://bugs.python.org/issue32230: instead of making the warnings module aware of the "-bb" setting, we'd instead adjust the initialisation code to inject "error::BytesWarning" into sys.warnoptions *after* all of the entries from environment variables and the command line. ---------- messages: 307717 nosy: ncoghlan, vstinner priority: normal severity: normal stage: needs patch status: open title: -bb option should override -W options type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 05:46:56 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 10:46:56 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions In-Reply-To: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> Message-ID: <1512557216.1.0.213398074469.issue32230@psf.upfronthosting.co.za> STINNER Victor added the comment: > If we want "-bb" to take precedence over the passed in "-W" settings It's not only that. Without -b nor -bb, the default::Warning filter should still come after ignore::BytesWarning, since these warnings must be ignored by default. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 05:47:48 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Dec 2017 10:47:48 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions In-Reply-To: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> Message-ID: <1512557268.94.0.213398074469.issue32230@psf.upfronthosting.co.za> Nick Coghlan added the comment: I filed https://bugs.python.org/issue32231 to cover having -bb always override other warnings settings when it comes to handling BytesWarning. Writing that issue made me realise another quirk with `-X dev` though: as a command line option, it should really take precedence over PYTHONWARNINGS, while remain subordinate to other explicit -W options. I've adjusted the PR to implement that change, but haven't added a test case that ensures the behaviour persists. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 05:49:05 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 10:49:05 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions In-Reply-To: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> Message-ID: <1512557345.39.0.213398074469.issue32230@psf.upfronthosting.co.za> STINNER Victor added the comment: First I proposed that -X dev behaves as -Wd -b, but Antoine Pitrou and Serhiy Storchaka asked to remove -b: https://mail.python.org/pipermail/python-dev/2017-November/150517.html https://mail.python.org/pipermail/python-dev/2017-November/150519.html https://mail.python.org/pipermail/python-dev/2017-November/150520.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 05:50:06 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Dec 2017 10:50:06 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions In-Reply-To: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> Message-ID: <1512557406.67.0.213398074469.issue32230@psf.upfronthosting.co.za> Nick Coghlan added the comment: No, we don't need to worry about BytesWarning if neither -b nor -bb are set, as the interpreter doesn't even emit the warning in that case. The only thing the warnings machinery gets used for is to print the messages and/or raise the exceptions (so it would arguably be clearer to omit the filter entirely in the case where the flag isn't set at all). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 05:52:25 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Dec 2017 10:52:25 +0000 Subject: [issue32231] -bb option should override -W options In-Reply-To: <1512556995.36.0.213398074469.issue32231@psf.upfronthosting.co.za> Message-ID: <1512557545.88.0.213398074469.issue32231@psf.upfronthosting.co.za> Nick Coghlan added the comment: (From the discussion at https://bugs.python.org/issue32230#msg307721) Another benefit we'd gain from this approach is that we could easily omit the filter entirely in the case where neither -b nor -bb is set: in those situations, BytesWarning won't be emitted at all, so we don't really need to define a filter for it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 05:54:44 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Dec 2017 10:54:44 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions In-Reply-To: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> Message-ID: <1512557684.51.0.213398074469.issue32230@psf.upfronthosting.co.za> Nick Coghlan added the comment: In relation to the utility of sys.warnoptions: it also lets other modules (like the unittest module) inspect the warnings that have been specified on the command line. If it wasn't for that use case, I wouldn't be concerned about the fact that `-X dev` doesn't currently set it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 05:56:40 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 10:56:40 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions In-Reply-To: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> Message-ID: <1512557800.78.0.213398074469.issue32230@psf.upfronthosting.co.za> STINNER Victor added the comment: > It isn't good to have "-X dev" do magical things that can't already be replicated with other options. While it might be nice to be able to replicate -X dev "manually", I didn't try to implement that. The current implementation of this option is more complex than what I expected, especially for warnings. > Writing that issue made me realise another quirk with `-X dev` though: as a command line option, it should really take precedence over PYTHONWARNINGS, while remain subordinate to other explicit -W options. IMHO -X dev should change the default, but let the developer overrides options set by -X dev. For example, -X dev -bb works as expected: raise BytesWarning, and this is a test for that. There is also a test for -X dev -W error: -W error has the priority over -X dev, I did that on purpose. When I started to implement -X dev, I didn't expect so many corner cases. The problem is that the code reading the "configuration" (command line arguments, environment variables, a few configuration files, etc.) was spreaded around CPython code. You know that very well, since you wrote the PEP 432 :-) Fix the implementation of -X dev was my first motivation to work on the implementation of the PEP 432: bpo-32030. For PYTHONWARNINGS vs -X dev, I'm not sure. It's rare to use PYTHONWARNINGS. I put PYTHONWARNINGS and -W options at the same level. If someone uses PYTHONWARNINGS, warnings are likely already well understood. Overriding PYTHONWARNINGS with -X dev can be seen as a bug. Sometimes, you cannot set command line options, only environment variable. There is -X dev, but there is also PYTHONDEVMODE=1 ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 06:04:32 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 11:04:32 +0000 Subject: [issue32231] -bb option should override -W options In-Reply-To: <1512556995.36.0.213398074469.issue32231@psf.upfronthosting.co.za> Message-ID: <1512558272.88.0.213398074469.issue32231@psf.upfronthosting.co.za> STINNER Victor added the comment: IMHO the root issue is that there are different options which set warnings filters: - PYTHONWARNINGS/-W will fill sys.warnoptions - sys.flags.bytes_warning (-b, -bb) and sys.flags.dev_mode (-X dev, PYTHONDEVMODE=1) which change the default filters vstinner at apu$ ./python -W default -b -c 'import pprint, sys, warnings; pprint.pprint(warnings.filters); pprint.pprint(sys.warnoptions)' [('default', None, , None, 0), ('default', None, , None, 0), ('default', None, , None, 0)] ['default'] Why default::BytesWarning isn't in sys.warnoptions? I suggest to experiment to create all filters at once in a single list, rather than having sys.warnoptions on one side and init_filters() (Python/_warnings.c) on another side. It was on my TODO list for the PEP 432 :-) Currently, when Python is embedded, it's not easy to control filters created by init_filters() which can be an issue. I expect a feature like Py_SetPath() to override *all* warnings filters, not only "add" filters on top on existing filters, for the specific case of embedded Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 06:12:24 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Dec 2017 11:12:24 +0000 Subject: [issue32231] -bb option should override -W options In-Reply-To: <1512556995.36.0.213398074469.issue32231@psf.upfronthosting.co.za> Message-ID: <1512558744.84.0.213398074469.issue32231@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'm hesitant to put the *true* default filters in sys.warnoptions, as folks use "bool(sys.warnoptions)" as a check for "Were any warning options set via the environment or the command line?", and we don't want to invalidate that use case. However, I'm definitely a fan of having the warnings module *only* look at sys.warnoptions, and requiring *all* command line options to route their filter settings through that channel. https://bugs.python.org/issue32230 adjusts "-X dev" to work that way, and I'm suggesting we do the same here for "-b". That way, we can fully define the relative ordering of PYTHONWARNINGS, "-X dev", "-W", and "-b" inside pymain_add_warnings_options (and only the true default filters will be appended by the warnings module itself). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 06:28:32 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Dec 2017 11:28:32 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions In-Reply-To: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> Message-ID: <1512559712.53.0.213398074469.issue32230@psf.upfronthosting.co.za> Nick Coghlan added the comment: Right, I hit some of those corner cases myself before I realised that pymain_add_warnings_options was the right place to inject "default" into sys.warnoptions after your refactoring improvements. It provides a nice pivot point where the command line machinery can decide relative priority and turn things into a neatly ordered list. That gives the following priority order in my PR: - first we add the filters from PYTHONWARNINGS - then we optionally add an extra "default" entry based on core_config->dev_mode (which may be from either PYTHONDEVMODE or from "-X dev") - then we add the filters from "-W" command line options The "last added, first applied" behaviour of "warnings.simplefilter" then means that later entries in that list take precedence over earlier entries. If we go on to also implement https://bugs.python.org/issue32231, then we'd add a 4th step to inject a "default::BytesWarning" or "error::BytesWarning" filter at the end based on cmdline->bytes_warning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 06:37:14 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Dec 2017 11:37:14 +0000 Subject: [issue32231] -bb option should override -W options In-Reply-To: <1512556995.36.0.213398074469.issue32231@psf.upfronthosting.co.za> Message-ID: <1512560234.42.0.213398074469.issue32231@psf.upfronthosting.co.za> Nick Coghlan added the comment: One potential complication here is that embedding applications would inherit the requirement to do both: Py_BytesWarningFlag = 2; and PySys_AddWarnOption(L"error::BytesWarning"); to request errors. That's probably OK though, since we're getting into pretty esoteric configuration behaviour at that point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 06:47:47 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Dec 2017 11:47:47 +0000 Subject: [issue32231] -bb option should override -W options In-Reply-To: <1512556995.36.0.213398074469.issue32231@psf.upfronthosting.co.za> Message-ID: <1512560867.08.0.213398074469.issue32231@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This looks like a duplicate of issue20361. ---------- nosy: +serhiy.storchaka resolution: -> duplicate superseder: -> -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 06:48:33 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 11:48:33 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions In-Reply-To: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> Message-ID: <1512560913.5.0.213398074469.issue32230@psf.upfronthosting.co.za> STINNER Victor added the comment: I prefer to not talk about sys.warnoptions since, as you wrote, the order is reversed. IMHO the priority should be (high priority > low priority): -W options > PYTHONWARNINGS > BytesWarning > -X dev > default filters With: * BytesWarning: "ignore" by default, "default" for -b, "error" for -bb. * default filters: 4 filters added in release mode [('ignore', None, , None, 0), ('ignore', None, , None, 0), ('ignore', None, , None, 0), ('ignore', None, , None, 0)] or 1 filter for pydebug build: [('default', None, , None, 0)] Currently, only "-W options > PYTHONWARNINGS" goes into sys.warnoptions, whereas "BytesWarning > -X dev > default filters" is added by the warnings module ("init_filters()"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 06:58:33 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 11:58:33 +0000 Subject: [issue20361] -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options In-Reply-To: <1390468789.64.0.236388970509.issue20361@psf.upfronthosting.co.za> Message-ID: <1512561513.05.0.213398074469.issue20361@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- nosy: +ncoghlan, vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 07:01:24 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Dec 2017 12:01:24 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions In-Reply-To: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> Message-ID: <1512561684.22.0.213398074469.issue32230@psf.upfronthosting.co.za> Nick Coghlan added the comment: If we wanted to go that way, then I'd go back to my original code order for - putting the '-X dev' setting first in sys.warnoptions, so both PYTHONWARNINGS and -W options override it. Then https://bugs.python.org/issue32231 would determine the relative precedence of the BytesWarning filter. (I still think the interaction between "-Wd" and "-bb" is weird, but we can argue about that on the other issue). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 07:02:56 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 12:02:56 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions In-Reply-To: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> Message-ID: <1512561776.65.0.213398074469.issue32230@psf.upfronthosting.co.za> STINNER Victor added the comment: "-W options > PYTHONWARNINGS > BytesWarning > -X dev > default filters" Hum, sorry, according to bpo-20361 (and bpo-32231 which has been marked as a duplicate of bpo-20361), -b and -bb options must have the priority over -W/PYTHONWARNINGS. So it gives something closer to: -b and -bb > -W > PYTHONWARNINGS > ignore::BytesWarning > -X dev > default filters where ignore::BytesWarning is only not added if -b or -bb is used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 07:06:38 2017 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 06 Dec 2017 12:06:38 +0000 Subject: [issue32220] multiprocessing: passing file descriptor using reduction breaks duplex pipes on darwin In-Reply-To: <1512464166.7.0.213398074469.issue32220@psf.upfronthosting.co.za> Message-ID: <1512561998.24.0.213398074469.issue32220@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I don't know if the issue has been fixed on macOS, and I'd be surprised if Ned would know this without testing. Anyways, I think it is worthwhile to perform the testing that Antoine mentioned on a recent version of macOS (I'd start on 10.13, than work backward when the issue isn't present there). A big question is how far back we want to support. The binary installers still support macOS 10.6, even though that's long out of support. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 07:43:17 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 Dec 2017 12:43:17 +0000 Subject: [issue32229] Simplify hiding developer warnings in user facing applications In-Reply-To: <1512534786.28.0.213398074469.issue32229@psf.upfronthosting.co.za> Message-ID: <1512564197.81.0.213398074469.issue32229@psf.upfronthosting.co.za> R. David Murray added the comment: I haven't been following that discussion, and isolated from that that discussion the title of this issue and this proposal make no sense to me. Warnings are off by default, so you don't need to hide them. In what context does this get used? If this is going to be used to implement turning warnings on for the main application, why isn't it named "show_warnings"? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 08:03:40 2017 From: report at bugs.python.org (Matthias Klose) Date: Wed, 06 Dec 2017 13:03:40 +0000 Subject: [issue32232] building extensions as builtins is broken in 3.7 Message-ID: <1512565420.17.0.213398074469.issue32232@psf.upfronthosting.co.za> New submission from Matthias Klose : building extensions statically in linking these into the python binary is currently broken on 3.7. I'm attaching the change that worked for me in 3.7alpha2, but doesn't work anymore with alpha3. Currently investigating. When building extensions as builtins, these should benefit from the knowledge about the core interpreter. x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -g -fdebug-prefix-map=/home/packages/python/3.7/python3.7-3.7.0~a3=. -fstack-protector-strong -Wformat -Werror=format-security -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -IObjects -IInclude -IPython -I. -I../Include -Wdate-time -D_FORTIFY_SOURCE=2 -DPy_BUILD_CORE -c ../Modules/_elementtree.c -o Modules/_elementtree.o In file included from ../Include/pyatomic.h:10:0, from ../Include/Python.h:53, from ../Modules/_elementtree.c:16: ../Modules/_elementtree.c: In function 'element_dealloc': ../Include/pystate.h:314:34: error: '_PyRuntime' undeclared (first use in this function); did you mean 'PyRun_File'? # define _PyThreadState_Current _PyRuntime.gilstate.tstate_current ^ ../Include/pyatomic.h:533:5: note: in expansion of macro '_Py_atomic_load_explicit' _Py_atomic_load_explicit(ATOMIC_VAL, _Py_memory_order_relaxed) ^~~~~~~~~~~~~~~~~~~~~~~~ ../Include/pystate.h:316:31: note: in expansion of macro '_Py_atomic_load_relaxed' ((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current)) ^~~~~~~~~~~~~~~~~~~~~~~ ../Include/pystate.h:316:56: note: in expansion of macro '_PyThreadState_Current' ((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current)) ^~~~~~~~~~~~~~~~~~~~~~ ../Include/object.h:1069:34: note: in expansion of macro 'PyThreadState_GET' PyThreadState *_tstate = PyThreadState_GET(); \ ^~~~~~~~~~~~~~~~~ ../Modules/_elementtree.c:634:5: note: in expansion of macro 'Py_TRASHCAN_SAFE_BEGIN' Py_TRASHCAN_SAFE_BEGIN(self) ^~~~~~~~~~~~~~~~~~~~~~ ../Include/pystate.h:314:34: note: each undeclared identifier is reported only once for each function it appears in # define _PyThreadState_Current _PyRuntime.gilstate.tstate_current ^ ../Include/pyatomic.h:533:5: note: in expansion of macro '_Py_atomic_load_explicit' _Py_atomic_load_explicit(ATOMIC_VAL, _Py_memory_order_relaxed) ^~~~~~~~~~~~~~~~~~~~~~~~ ../Include/pystate.h:316:31: note: in expansion of macro '_Py_atomic_load_relaxed' ((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current)) ^~~~~~~~~~~~~~~~~~~~~~~ ../Include/pystate.h:316:56: note: in expansion of macro '_PyThreadState_Current' ((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current)) ^~~~~~~~~~~~~~~~~~~~~~ ../Include/object.h:1069:34: note: in expansion of macro 'PyThreadState_GET' PyThreadState *_tstate = PyThreadState_GET(); \ ^~~~~~~~~~~~~~~~~ ../Modules/_elementtree.c:634:5: note: in expansion of macro 'Py_TRASHCAN_SAFE_BEGIN' Py_TRASHCAN_SAFE_BEGIN(self) ^~~~~~~~~~~~~~~~~~~~~~ ../Include/pyatomic.h:56:5: error: '__atomic_load_ptr' undeclared (first use in this function); did you mean '__atomic_load_n'? atomic_load_explicit(&(ATOMIC_VAL)->_value, ORDER) ^ ../Include/pyatomic.h:533:5: note: in expansion of macro '_Py_atomic_load_explicit' _Py_atomic_load_explicit(ATOMIC_VAL, _Py_memory_order_relaxed) ^~~~~~~~~~~~~~~~~~~~~~~~ ../Include/pystate.h:316:31: note: in expansion of macro '_Py_atomic_load_relaxed' ((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current)) ^~~~~~~~~~~~~~~~~~~~~~~ ---------- components: Build messages: 307735 nosy: doko priority: normal severity: normal status: open title: building extensions as builtins is broken in 3.7 versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 08:07:28 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 13:07:28 +0000 Subject: [issue32232] building extensions as builtins is broken in 3.7 In-Reply-To: <1512565420.17.0.213398074469.issue32232@psf.upfronthosting.co.za> Message-ID: <1512565648.15.0.213398074469.issue32232@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- nosy: +eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 08:21:07 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Dec 2017 13:21:07 +0000 Subject: [issue32229] Simplify hiding developer warnings in user facing applications In-Reply-To: <1512534786.28.0.213398074469.issue32229@psf.upfronthosting.co.za> Message-ID: <1512566467.0.0.213398074469.issue32229@psf.upfronthosting.co.za> Nick Coghlan added the comment: Warnings aren't off by default in general - we just add implicit "ignore" filters for a few specific types. So the primary functionality is to opt in to hiding *all* warnings, but to do it in a way that can be overridden by PYTHONWARNINGS, the interpreter's "-W" switch and the new "-X dev" mode. For that, the usage looks like: import warnings warnings.hide_warnings() Essentially, it flips the default behaviour over to "ignore everything", but reverts to the regular default if there are any config settings supplied. The odd structure of my opening message arises from the fact that *given* such a modified default, it's then surprisingly tricky to say "hide warnings, except for those from modules I'm responsible for". That latter complication then becomes the rationale for the design of the proposed "show" parameter to carve out exceptions to the overall "hide everything" filter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 08:23:50 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 06 Dec 2017 13:23:50 +0000 Subject: [issue32229] Simplify hiding developer warnings in user facing applications In-Reply-To: <1512534786.28.0.213398074469.issue32229@psf.upfronthosting.co.za> Message-ID: <1512566630.16.0.213398074469.issue32229@psf.upfronthosting.co.za> Nick Coghlan added the comment: Note: for consistency with the underlying action names, the API should probably be called "warnings.ignore_warnings". I'd still keep the proposed parameter name as "show" though (and we may want to consider introducing that as a more semantically meaningful alias for "default"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 08:50:32 2017 From: report at bugs.python.org (Matthias Klose) Date: Wed, 06 Dec 2017 13:50:32 +0000 Subject: [issue32233] [3.7 Regression] build with --with-system-libmpdec is broken Message-ID: <1512568232.66.0.213398074469.issue32233@psf.upfronthosting.co.za> New submission from Matthias Klose : in setup.py, for the _decimal module the libararies are now set exclusively to ['m'], without checking if this is really needed, and overriding the external mpdec library, breaking the build. Is there any reason to override that? ---------- components: Build messages: 307738 nosy: doko priority: normal severity: normal status: open title: [3.7 Regression] build with --with-system-libmpdec is broken versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 08:51:42 2017 From: report at bugs.python.org (Matthias Klose) Date: Wed, 06 Dec 2017 13:51:42 +0000 Subject: [issue32233] [3.7 Regression] build with --with-system-libmpdec is broken In-Reply-To: <1512568232.66.0.213398074469.issue32233@psf.upfronthosting.co.za> Message-ID: <1512568302.48.0.213398074469.issue32233@psf.upfronthosting.co.za> Matthias Klose added the comment: proposed patch, however I don't know the rationale for that change compared to 3.7alpha2. ---------- keywords: +patch Added file: https://bugs.python.org/file47324/issue32233.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 08:58:33 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 13:58:33 +0000 Subject: [issue32233] [3.7 Regression] build with --with-system-libmpdec is broken In-Reply-To: <1512568232.66.0.213398074469.issue32233@psf.upfronthosting.co.za> Message-ID: <1512568713.89.0.213398074469.issue32233@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 09:32:30 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 Dec 2017 14:32:30 +0000 Subject: [issue32229] Simplify hiding developer warnings in user facing applications In-Reply-To: <1512534786.28.0.213398074469.issue32229@psf.upfronthosting.co.za> Message-ID: <1512570750.92.0.213398074469.issue32229@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, OK, that makes more sense. I don't run into warnings other than DeprecationWarnings in practice, so I tend to forget about them :) I think specifying warnings filters is pretty inscrutable, in general. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 09:53:01 2017 From: report at bugs.python.org (Matthias Klose) Date: Wed, 06 Dec 2017 14:53:01 +0000 Subject: [issue32232] building extensions as builtins is broken in 3.7 In-Reply-To: <1512565420.17.0.213398074469.issue32232@psf.upfronthosting.co.za> Message-ID: <1512571981.16.0.213398074469.issue32232@psf.upfronthosting.co.za> Matthias Klose added the comment: that patch lets the build succeed. two additional includes and a little bit of shuffling ---------- keywords: +patch Added file: https://bugs.python.org/file47325/ext-as-builtins.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 10:11:56 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 06 Dec 2017 15:11:56 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512543983.31.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <36BF5C9A-9A96-47D0-BDA1-082FFCBE7858@python.org> Barry A. Warsaw added the comment: On Dec 6, 2017, at 02:06, Xavier de Gaye wrote: > > Whatever the change made to fix this issue, it is not possible to add a test case for this change. Even with say, exception raising mocks for the getters? > So following the suggestion made by Barry in PR 4696, we can add (in another issue) a new keyword parameter to getnode() named 'methods' whose value may be None (the default, meaning try all the known methods) or a tuple containing a subset of the following methods ('unix', 'ifconfig', 'ip', 'arp', 'lanscan', 'netstat', 'random') that would raise an exception if the value cannot be obtained using one of the requested method tried in the requested order. This would also improve the documentation on the methods getnode() is using. Then if we decide to make the change for 'ip link' in the current issue, one can add a test case that would first test for the avaibility of the ip command and if the command exists would fail if getnode(methods=('ip',)) raises an exception. I am thinking about this slightly differently. What if getnode() accepted a `handler` argument and the code was changed to something like this: 1 file changed, 4 insertions(+), 2 deletions(-) Lib/uuid.py | 6 ++++-- modified Lib/uuid.py @@ -656,7 +656,7 @@ def _random_getnode(): _node = None -def getnode(): +def getnode(handler=None): """Get the hardware address as a 48-bit positive integer. The first time this runs, it may launch a separate program, which could @@ -677,7 +677,9 @@ def getnode(): for getter in getters + [_random_getnode]: try: _node = getter() - except: + except Exception as error: + if handler is not None: + handler(getter, error) continue if _node is not None: return _node `handler` could log some diagnostics, reraise the exception, raise StopIteration, etc. Then we could use that in the test suite too, because we could mock a getter to raise an exception and then pass in a handler that verified the exception was raised with the expected getter. (Maybe we spell `handler` as `error_handler`.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 10:15:44 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 06 Dec 2017 15:15:44 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512547474.49.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <6FE2C25F-8219-4F14-9338-8FC9E54FE646@python.org> Barry A. Warsaw added the comment: > Maybe we should just close this issue as 'wont fix' then. I would be okay with any of these resolutions: * Close as `wont fix` * Just call `ip link` (without list) * Add a new getter such that both `ip link` and `ip link list` are called. How to handle exceptions in the getters should be addressed in a new issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 10:28:26 2017 From: report at bugs.python.org (sblondon) Date: Wed, 06 Dec 2017 15:28:26 +0000 Subject: [issue32234] Add context management to mailbox.Mailbox Message-ID: <1512574106.47.0.213398074469.issue32234@psf.upfronthosting.co.za> New submission from sblondon : mailbox.Mailbox has a .close() method that should be called at the end of Mailbox use. I think it would be nice to use Mailbox instances with a 'with' statement so .close() will be called it automatically. So there is no need to check for which format it's required (yes for mbox, no for Maildir, etc.) So the source code: mbox = mailbox.mbox("/path/to/mbox") ... mbox.close() could become: with mailbox.mbox("/path/to/mbox") as mbox: ... ---------- components: Library (Lib) messages: 307744 nosy: sblondon priority: normal severity: normal status: open title: Add context management to mailbox.Mailbox type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 10:43:25 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 15:43:25 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512575005.23.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4638 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 10:45:38 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 06 Dec 2017 15:45:38 +0000 Subject: [issue32234] Add context management to mailbox.Mailbox In-Reply-To: <1512574106.47.0.213398074469.issue32234@psf.upfronthosting.co.za> Message-ID: <1512575138.45.0.213398074469.issue32234@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Yes, I think this is a good idea. Would you like to submit a PR for it? FWIW, we have this code in Mailman 3: class Mailbox(MMDF): """A mailbox that interoperates with the 'with' statement.""" def __enter__(self): self.lock() return self def __exit__(self, *exc): self.flush() self.unlock() # Don't suppress the exception. return False ---------- nosy: +barry versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 10:54:01 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 15:54:01 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512575641.64.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4639 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 10:54:01 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 15:54:01 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1512575641.84.0.00913614298617.issue13959@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4640 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 11:21:18 2017 From: report at bugs.python.org (Ned Deily) Date: Wed, 06 Dec 2017 16:21:18 +0000 Subject: [issue32232] building extensions as builtins is broken in 3.7 In-Reply-To: <1512565420.17.0.213398074469.issue32232@psf.upfronthosting.co.za> Message-ID: <1512577278.63.0.213398074469.issue32232@psf.upfronthosting.co.za> Change by Ned Deily : ---------- nosy: +ned.deily priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 11:25:13 2017 From: report at bugs.python.org (Ned Deily) Date: Wed, 06 Dec 2017 16:25:13 +0000 Subject: [issue32233] [3.7 Regression] build with --with-system-libmpdec is broken In-Reply-To: <1512568232.66.0.213398074469.issue32233@psf.upfronthosting.co.za> Message-ID: <1512577513.26.0.213398074469.issue32233@psf.upfronthosting.co.za> Change by Ned Deily : ---------- nosy: +ned.deily priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 11:25:57 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 16:25:57 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512577557.48.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 672b6baa71010f236ee8c8ce912e98cb542385c6 by Victor Stinner in branch 'master': bpo-32030: pass interp to _PyImport_Init() (#4736) https://github.com/python/cpython/commit/672b6baa71010f236ee8c8ce912e98cb542385c6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 11:25:57 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 16:25:57 +0000 Subject: [issue13959] Re-implement parts of imp in pure Python In-Reply-To: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za> Message-ID: <1512577557.63.0.912454111764.issue13959@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 672b6baa71010f236ee8c8ce912e98cb542385c6 by Victor Stinner in branch 'master': bpo-32030: pass interp to _PyImport_Init() (#4736) https://github.com/python/cpython/commit/672b6baa71010f236ee8c8ce912e98cb542385c6 ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 11:26:12 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 16:26:12 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512577572.67.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 6bf992a1ac6f3f4d0f83ead9c6403a76afdbe6eb by Victor Stinner in branch 'master': bpo-32030: Add pymain_get_global_config() (#4735) https://github.com/python/cpython/commit/6bf992a1ac6f3f4d0f83ead9c6403a76afdbe6eb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 11:27:26 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 16:27:26 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512577646.44.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4641 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 11:37:53 2017 From: report at bugs.python.org (Matthias Klose) Date: Wed, 06 Dec 2017 16:37:53 +0000 Subject: [issue32235] [2.7 regression] test_xml_etree test_xml_etree_c failures with 2.7 and 3.6 branches 20171205 Message-ID: <1512578273.44.0.213398074469.issue32235@psf.upfronthosting.co.za> New submission from Matthias Klose : Seen with recent Debian and Ubuntu builds, builds configured with --with-system-expat, expat version 2.2.3. ====================================================================== ERROR: test_expat224_utf8_bug (test.test_xml_etree.BugsTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/test/test_xml_etree.py", line 1513, in test_expat224_utf8_bug self.check_expat224_utf8_bug(text) File "/usr/lib/python2.7/test/test_xml_etree.py", line 1500, in check_expat224_utf8_bug root = ET.XML(xml) File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1311, in XML parser.feed(text) File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1657, in feed self._parser.Parse(data, 0) UnicodeDecodeError: 'utf8' codec can't decode byte 0xc3 in position 2047: unexpected end of data ====================================================================== ERROR: test_expat224_utf8_bug_file (test.test_xml_etree.BugsTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/test/test_xml_etree.py", line 1518, in test_expat224_utf8_bug_file root = ET.fromstring(raw) File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1311, in XML parser.feed(text) File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1657, in feed self._parser.Parse(data, 0) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1020-1021: unexpected end of data ---------- messages: 307749 nosy: doko priority: normal severity: normal status: open title: [2.7 regression] test_xml_etree test_xml_etree_c failures with 2.7 and 3.6 branches 20171205 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 11:39:36 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 16:39:36 +0000 Subject: [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1512578376.63.0.213398074469.issue25910@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 1b4587a2462fc05a14be87123083322103a1f55b by Victor Stinner (Sanyam Khurana) in branch 'master': bpo-25910: Fixes redirection from http to https (#4674) https://github.com/python/cpython/commit/1b4587a2462fc05a14be87123083322103a1f55b ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 11:42:47 2017 From: report at bugs.python.org (Stefan Krah) Date: Wed, 06 Dec 2017 16:42:47 +0000 Subject: [issue32233] [3.7 Regression] build with --with-system-libmpdec is broken In-Reply-To: <1512568232.66.0.213398074469.issue32233@psf.upfronthosting.co.za> Message-ID: <1512578567.38.0.213398074469.issue32233@psf.upfronthosting.co.za> Stefan Krah added the comment: At some point linking explicitly against libm was added. The build still worked until 8acaa31eec removed detect_math_libs(). ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 11:48:07 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Dec 2017 16:48:07 +0000 Subject: [issue32234] Add context management to mailbox.Mailbox In-Reply-To: <1512574106.47.0.213398074469.issue32234@psf.upfronthosting.co.za> Message-ID: <1512578887.23.0.213398074469.issue32234@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is an ambiguity. What should the context manager do? Should it call a close() on exit (as the OP implies)? Or call lock() on enter and unlock() on exit as in Barry's example? Both behaviors look reasonable. "In the face of ambiguity, refuse the temptation to guess" and "Explicit is better than implicit". This is perhaps the reason why this feature is not implemented yet. Perhaps there were discussions about this in the past. contextlib.closing() can be used for explicit requesting the first behavior. Maybe it's a time to add contextlib.locked() or something like. ---------- nosy: +ncoghlan, r.david.murray, serhiy.storchaka, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 11:49:31 2017 From: report at bugs.python.org (Stefan Krah) Date: Wed, 06 Dec 2017 16:49:31 +0000 Subject: [issue32233] [3.7 Regression] build with --with-system-libmpdec is broken In-Reply-To: <1512568232.66.0.213398074469.issue32233@psf.upfronthosting.co.za> Message-ID: <1512578971.13.0.213398074469.issue32233@psf.upfronthosting.co.za> Stefan Krah added the comment: I suggest to restore the logic from 75c0d4f6bb97e723adc3a03c0ff6aaaee0c6981a . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 11:52:12 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Dec 2017 16:52:12 +0000 Subject: [issue32235] [2.7 regression] test_xml_etree test_xml_etree_c failures with 2.7 and 3.6 branches 20171205 In-Reply-To: <1512578273.44.0.213398074469.issue32235@psf.upfronthosting.co.za> Message-ID: <1512579132.91.0.213398074469.issue32235@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This means that you need to update the expat library. Expat version 2.2.3 contains a bug, it affects not only Python, but all depending applications. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 11:52:26 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Dec 2017 16:52:26 +0000 Subject: [issue32235] [2.7 regression] test_xml_etree test_xml_etree_c failures with 2.7 and 3.6 branches 20171205 In-Reply-To: <1512578273.44.0.213398074469.issue32235@psf.upfronthosting.co.za> Message-ID: <1512579146.25.0.213398074469.issue32235@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- resolution: -> third party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 11:56:13 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 16:56:13 +0000 Subject: [issue32235] [2.7 regression] test_xml_etree test_xml_etree_c failures with 2.7 and 3.6 branches 20171205 In-Reply-To: <1512578273.44.0.213398074469.issue32235@psf.upfronthosting.co.za> Message-ID: <1512579373.53.0.213398074469.issue32235@psf.upfronthosting.co.za> STINNER Victor added the comment: See bpo-31170 for expat 2.2.3 bug (and maybe also bpo-30947). ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 12:09:58 2017 From: report at bugs.python.org (Stefan Krah) Date: Wed, 06 Dec 2017 17:09:58 +0000 Subject: [issue32233] [3.7 Regression] build with --with-system-libmpdec is broken In-Reply-To: <1512568232.66.0.213398074469.issue32233@psf.upfronthosting.co.za> Message-ID: <1512580198.23.0.213398074469.issue32233@psf.upfronthosting.co.za> Change by Stefan Krah : ---------- pull_requests: +4642 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 12:10:53 2017 From: report at bugs.python.org (Jim Fulton) Date: Wed, 06 Dec 2017 17:10:53 +0000 Subject: [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1512580253.87.0.213398074469.issue25910@psf.upfronthosting.co.za> Change by Jim Fulton : ---------- nosy: -j1m _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 12:13:01 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 17:13:01 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1512580381.69.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 92a3c6f493ad411e4cf0acdf305ef4876aa90669 by Victor Stinner in branch 'master': bpo-32030: Add _PyImport_Fini2() (#4737) https://github.com/python/cpython/commit/92a3c6f493ad411e4cf0acdf305ef4876aa90669 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 12:24:23 2017 From: report at bugs.python.org (Stefan Krah) Date: Wed, 06 Dec 2017 17:24:23 +0000 Subject: [issue32233] [3.7 Regression] build with --with-system-libmpdec is broken In-Reply-To: <1512568232.66.0.213398074469.issue32233@psf.upfronthosting.co.za> Message-ID: <1512581063.02.0.213398074469.issue32233@psf.upfronthosting.co.za> Stefan Krah added the comment: New changeset bd4ed77f73d37df325fc8f1e193b3ce6bc08094d by Stefan Krah in branch 'master': bpo-32233: Fix build with --with-system-libmpdec. (#4739) https://github.com/python/cpython/commit/bd4ed77f73d37df325fc8f1e193b3ce6bc08094d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 12:28:18 2017 From: report at bugs.python.org (Stefan Krah) Date: Wed, 06 Dec 2017 17:28:18 +0000 Subject: [issue32233] [3.7 Regression] build with --with-system-libmpdec is broken In-Reply-To: <1512568232.66.0.213398074469.issue32233@psf.upfronthosting.co.za> Message-ID: <1512581298.86.0.213398074469.issue32233@psf.upfronthosting.co.za> Change by Stefan Krah : ---------- assignee: -> skrah resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 12:43:10 2017 From: report at bugs.python.org (paul j3) Date: Wed, 06 Dec 2017 17:43:10 +0000 Subject: [issue18943] argparse: default args in mutually exclusive groups In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za> Message-ID: <1512582190.63.0.213398074469.issue18943@psf.upfronthosting.co.za> paul j3 added the comment: Did you copy the output right? Testing your parser: Without any arguments, I get the exclusive group error - the group is required: 0930:~/mypy/argdev$ python3 issue18943.py usage: issue18943.py [-h] (--device-get-capabilities | --ptz-absolute-move x y z | --ptz-get-status MEDIA_PROFILE) issue18943.py: error: one of the arguments --device-get-capabilities --ptz-absolute-move --ptz-get-status is required 0931:~/mypy/argdev$ python3 --version Python 3.5.2 With one flag but not its argument, I get the error that you display. That has nothing to do with the grouping. 0932:~/mypy/argdev$ python3 issue18943.py --ptz-get-status usage: issue18943.py [-h] (--device-get-capabilities | --ptz-absolute-move x y z | --ptz-get-status MEDIA_PROFILE) issue18943.py: error: argument --ptz-get-status: expected one argument ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 12:57:04 2017 From: report at bugs.python.org (sblondon) Date: Wed, 06 Dec 2017 17:57:04 +0000 Subject: [issue32234] Add context management to mailbox.Mailbox In-Reply-To: <1512578887.23.0.213398074469.issue32234@psf.upfronthosting.co.za> Message-ID: sblondon added the comment: Currently, the implementation of .close() methods call flush() and unlock() if it's needed. About the ambiguity for the enter call, I think the context manager should provide access to Mailbox, not a lock. If a lock is needed, we could imagine another context manager: with mailbox.Mailbox as mbox: #read messages, ... with mbox.lock(): #actions that need lock Do you think it's better? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 12:58:07 2017 From: report at bugs.python.org (Vincas Dargis) Date: Wed, 06 Dec 2017 17:58:07 +0000 Subject: [issue18943] argparse: default args in mutually exclusive groups In-Reply-To: <1512582190.63.0.213398074469.issue18943@psf.upfronthosting.co.za> Message-ID: Vincas Dargis added the comment: On 2017-12-06 19:43, paul j3 wrote: > With one flag but not its argument, I get the error that you display. That has nothing to do with the grouping. > > 0932:~/mypy/argdev$ python3 issue18943.py --ptz-get-status > usage: issue18943.py [-h] > (--device-get-capabilities | --ptz-absolute-move x y z | --ptz-get-status MEDIA_PROFILE) > issue18943.py: error: argument --ptz-get-status: expected one argument In my example I pasted, I had hardcoded arguments: ``` pprint.pprint(parser.parse_args(['--ptz-get-status'])) `` I expected `python myscript.py --ptz-get-status` to work, because default value is set. I do not compute that "With one flag but not its argument", sorry. It has default argument set, shoudn't that work? Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 13:21:38 2017 From: report at bugs.python.org (paul j3) Date: Wed, 06 Dec 2017 18:21:38 +0000 Subject: [issue32123] Make the API of argparse.HelpFormatter public In-Reply-To: <1511517203.18.0.213398074469.issue32123@psf.upfronthosting.co.za> Message-ID: <1512584498.0.0.213398074469.issue32123@psf.upfronthosting.co.za> paul j3 added the comment: A difficulty with writing a public API is that useful changes can occur at almost any level of the class. The existing subclasses modify small, but deep methods, ones that handle things like line wrapping. On the other hand, most of the issues you cite deal with higher level issues, either the top most method of the formatter, or alternatives to parser.format_help or parser._get_formatter (which create and populate a formatter object). I've also responded to issues dealing with intermediate levels things, like the need for a more robust usage formatting, and changing how help lines are constructed. The argparse documentation is a mix of how-to and formal API. Mostly it describes how to perform common parsing tasks. Even though argparse consists of classes, the documentation does not formally describe the classes, and their subclassing and all methods. It's not a reference API. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 13:28:18 2017 From: report at bugs.python.org (paul j3) Date: Wed, 06 Dec 2017 18:28:18 +0000 Subject: [issue18943] argparse: default args in mutually exclusive groups In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za> Message-ID: <1512584898.53.0.213398074469.issue18943@psf.upfronthosting.co.za> paul j3 added the comment: That's not how flagged (optionals) arguments work. The default value is used if the flag is not provided at all. One of your arguments is a 'store_true'. Its default value if False, which is changed to True if the '--device-get-capabilities' flag is provided. "nargs='?'" provides a third option, assigning the 'const' value if the flag is used without an argument. In any case your problem isn't with a required mutually exclusive group (defaults or not). It has to do with understanding optionals and their defaults. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 13:33:11 2017 From: report at bugs.python.org (Alexey Izbyshev) Date: Wed, 06 Dec 2017 18:33:11 +0000 Subject: [issue13322] buffered read() and write() does not raise BlockingIOError In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za> Message-ID: <1512585191.29.0.213398074469.issue13322@psf.upfronthosting.co.za> Alexey Izbyshev added the comment: For added fun: at least one part of the standard library doesn't expect None returns from read() in the buffering layer. >>> import os >>> r, w = os.pipe2(os.O_NONBLOCK) >>> f = os.fdopen(r, 'r') >>> f.read() Traceback (most recent call last): File "", line 1, in File "/home/izbyshev/workspace/cpython/Lib/codecs.py", line 321, in decode data = self.buffer + input TypeError: can't concat NoneType to bytes Note that nonblock-none.patch doesn't seem to address that. ---------- nosy: +izbyshev versions: +Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 13:38:07 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Wed, 06 Dec 2017 18:38:07 +0000 Subject: [issue31506] Improve the error message logic for object_new & object_init In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za> Message-ID: <1512585487.72.0.213398074469.issue31506@psf.upfronthosting.co.za> Change by Sanyam Khurana : ---------- pull_requests: +4643 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 13:57:04 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Dec 2017 18:57:04 +0000 Subject: [issue13322] buffered read() and write() does not raise BlockingIOError In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za> Message-ID: <1512586624.32.0.213398074469.issue13322@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Generally I doubt anyone is using the non-blocking semantics of the Python 3 I/O stack. People doing non-blocking I/O generally do it with sockets instead, which tend to reproduce quite literally the POSIX behaviour and error codes. ---------- versions: -Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 14:30:01 2017 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 06 Dec 2017 19:30:01 +0000 Subject: [issue30862] parent logger should also check the level In-Reply-To: <1499303463.12.0.427912984431.issue30862@psf.upfronthosting.co.za> Message-ID: <1512588601.82.0.213398074469.issue30862@psf.upfronthosting.co.za> Vinay Sajip added the comment: > Maybe I misunderstand. I think you do misunderstand. The level of the handler created by basicConfig doesn't have any level set, so it will process any message it is asked to handle. This is working as designed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 15:22:26 2017 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 06 Dec 2017 20:22:26 +0000 Subject: [issue32212] few discrepancy between source and docs in logging In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za> Message-ID: <1512591746.92.0.213398074469.issue32212@psf.upfronthosting.co.za> Vinay Sajip added the comment: I don't have a problem with tweaking the documentation where discrepancies are found between source and doc for keyword arguments, but in both the examples you give, the arguments are positional, not keyword. Therefore in my opinion your code should be e.g. logger.setLevel(logging.DEBUG) and stream_handler.setFormatter(formatter) without using keyword arguments. For positionals, as I see it, the name shouldn't matter, nor should any minor discrepancy between doc and source. ---------- resolution: -> not a bug status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 16:07:55 2017 From: report at bugs.python.org (Zachary Ware) Date: Wed, 06 Dec 2017 21:07:55 +0000 Subject: [issue31430] [Windows][2.7] Python 2.7 compilation fails on mt.exe crashing with error code C0000005 In-Reply-To: <1505231752.16.0.130246189595.issue31430@psf.upfronthosting.co.za> Message-ID: <1512594475.09.0.213398074469.issue31430@psf.upfronthosting.co.za> Zachary Ware added the comment: The worker is happy, closing the issue. ---------- keywords: +buildbot resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 16:12:41 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 21:12:41 +0000 Subject: [issue31430] [Windows][2.7] Python 2.7 compilation fails on mt.exe crashing with error code C0000005 In-Reply-To: <1512594475.09.0.213398074469.issue31430@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Thank you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 16:14:23 2017 From: report at bugs.python.org (Zachary Ware) Date: Wed, 06 Dec 2017 21:14:23 +0000 Subject: [issue30450] Pull Windows dependencies from GitHub rather than svn.python.org In-Reply-To: <1495589626.97.0.920797927041.issue30450@psf.upfronthosting.co.za> Message-ID: <1512594863.76.0.213398074469.issue30450@psf.upfronthosting.co.za> Zachary Ware added the comment: This has been backported and working for nearly 3 months now; closing. As for whether to continue operating svn.python.org now that we're officially away from it: that can be determined elsewhere, probably by the box dying and deciding for us :) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 16:14:40 2017 From: report at bugs.python.org (Alexey Izbyshev) Date: Wed, 06 Dec 2017 21:14:40 +0000 Subject: [issue13322] buffered read() and write() does not raise BlockingIOError In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za> Message-ID: <1512594880.0.0.213398074469.issue13322@psf.upfronthosting.co.za> Alexey Izbyshev added the comment: Yes, your claim is confirmed by the fact that there have been little interest in this issue since 2011. Still, non-blocking behavior is incorrectly specified in the docs and is inconsistent (as investigated by Martin). And obscure errors like in my example or in Issue 13858 show that I/O stack is confused too. To prevent people from tripping on it, would you consider recommending against usage of I/O stack for non-blocking operations in io module docs? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 17:17:42 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Dec 2017 22:17:42 +0000 Subject: [issue32224] socket.create_connection needs to support full IPv6 argument In-Reply-To: <1512499476.97.0.213398074469.issue32224@psf.upfronthosting.co.za> Message-ID: <1512598662.38.0.213398074469.issue32224@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Also note that a regular socket.connect() call supports the full form address: >>> sock = socket.socket(socket.AF_INET6, socket.SOCK_STREAM) >>> sock.connect(('::1', 12345, 0, 0)) Matthew, are you interested in submitting a Github PR for this issue? ---------- nosy: +gregory.p.smith, pitrou stage: -> needs patch versions: +Python 2.7, Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 17:28:17 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 06 Dec 2017 22:28:17 +0000 Subject: [issue30450] Pull Windows dependencies from GitHub rather than svn.python.org In-Reply-To: <1495589626.97.0.920797927041.issue30450@psf.upfronthosting.co.za> Message-ID: <1512599297.75.0.213398074469.issue30450@psf.upfronthosting.co.za> STINNER Victor added the comment: Noooo! I loved Subversion so much! ... just kidding. Thanks for getting rid of Subversion. It became much easier to build CPython on Windows nowadays! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 18:12:36 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Dec 2017 23:12:36 +0000 Subject: [issue13322] buffered read() and write() does not raise BlockingIOError In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za> Message-ID: <1512601956.01.0.213398074469.issue13322@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes, I think adding a note in the docs is reasonable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 18:41:43 2017 From: report at bugs.python.org (Matthew Stoltenberg) Date: Wed, 06 Dec 2017 23:41:43 +0000 Subject: [issue32224] socket.create_connection needs to support full IPv6 argument In-Reply-To: <1512499476.97.0.213398074469.issue32224@psf.upfronthosting.co.za> Message-ID: <1512603703.9.0.213398074469.issue32224@psf.upfronthosting.co.za> Matthew Stoltenberg added the comment: The naive change is to have the host, port tuple assignment use only the first two values from address. I can open a PR with that change (and update the docstring for the function) if that's the right change. For reference, the python socketpair implementation (if _socket is missing it) ignores flow_info and scope_id, but I'm not sure that's the right thing to do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 18:46:49 2017 From: report at bugs.python.org (Alexey Izbyshev) Date: Wed, 06 Dec 2017 23:46:49 +0000 Subject: [issue32236] open() shouldn't silently ignore buffering=1 in binary mode Message-ID: <1512604009.3.0.213398074469.issue32236@psf.upfronthosting.co.za> New submission from Alexey Izbyshev : The fact that "buffering=1" is usable only in text mode is documented for open(). In binary mode, setting buffering to 1 is silently ignored and equivalent to using default buffer size. I argue that such behavior is: 1. Inconsistent For example, attempts to use buffering=0 in text mode or to specify encoding in binary mode raise ValueError. 2. Dangerous Consider the following code fragment running on *nix (inspired by real-world code): with open("fifo", "wb", buffering=1) as out: for line in lines: out.write(line) "fifo" refers to a FIFO (named pipe). For each line, len(line) <= PIPE_BUF. Because of line buffering, such code must be able to safely assume that each write() is atomic, so that even in case of multiple writers no line read by a FIFO reader will ever get intermixed with another line. And it's so in Python 2. After migration to Python 3 (assuming that line is now bytes), this code still works on Linux because of two factors: a) PIPE_BUF is 4096, and so is the default IO buffer size (usually) b) When a write() is going to overflow the buffer, BufferedWriter first flushes and then processes the new write() (based on my experiment). So, each OS write() is called with complete lines only and is atomic per (a). But PIPE_BUF is 512 on Mac OS X (I don't know about default buffer size). So, we are likely to have a subtle 2-to-3 migration issue. I suggest to raise a ValueError if buffering=1 is used for binary mode. Note that issue 10344 (msg244354) and issue 21332 would have been uncovered earlier if it was done from the beginning. ---------- components: IO messages: 307775 nosy: izbyshev, pitrou priority: normal severity: normal status: open title: open() shouldn't silently ignore buffering=1 in binary mode type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 18:54:27 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 06 Dec 2017 23:54:27 +0000 Subject: [issue32224] socket.create_connection needs to support full IPv6 argument In-Reply-To: <1512603703.9.0.213398074469.issue32224@psf.upfronthosting.co.za> Message-ID: Antoine Pitrou added the comment: I think we still want the full tuple passed to connect(). We may want to truncate the tuple when used for other purposes. Le 07/12/2017 ? 00:41, Matthew Stoltenberg a ?crit?: > > Matthew Stoltenberg added the comment: > > The naive change is to have the host, port tuple assignment use only the first two values from address. I can open a PR with that change (and update the docstring for the function) if that's the right change. For reference, the python socketpair implementation (if _socket is missing it) ignores flow_info and scope_id, but I'm not sure that's the right thing to do. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 19:02:30 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 07 Dec 2017 00:02:30 +0000 Subject: [issue32237] test_xml_etree leaked [1, 1, 1] references, sum=3 Message-ID: <1512604950.09.0.213398074469.issue32237@psf.upfronthosting.co.za> New submission from STINNER Victor : The commit eea3cc1ef0dec0af193eedb4c1164263fbdfd8cc introduced the following regression: vstinner at apu$ make && ./python -m test -R 3:3 test_xml_etree (...) test_xml_etree leaked [1, 1, 1] references, sum=3 ---------- messages: 307777 nosy: nascheme, vstinner priority: normal severity: normal status: open title: test_xml_etree leaked [1, 1, 1] references, sum=3 versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 19:04:41 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 07 Dec 2017 00:04:41 +0000 Subject: [issue32237] test_xml_etree leaked [1, 1, 1] references, sum=3 In-Reply-To: <1512604950.09.0.213398074469.issue32237@psf.upfronthosting.co.za> Message-ID: <1512605081.93.0.213398074469.issue32237@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, more tests are failing: test_ensurepip leaked [1, 1, 1] references, sum=3 test_hashlib leaked [1, 1, 1] references, sum=3 test_importlib leaked [5, 5, 5] references, sum=15 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 19:13:20 2017 From: report at bugs.python.org (Alexey Izbyshev) Date: Thu, 07 Dec 2017 00:13:20 +0000 Subject: [issue30718] open builtin function: specifying the size of buffer has no effect for text files In-Reply-To: <1497989929.05.0.713607879185.issue30718@psf.upfronthosting.co.za> Message-ID: <1512605600.58.0.213398074469.issue30718@psf.upfronthosting.co.za> Alexey Izbyshev added the comment: Yes, clarifying buffering for text mode in open() would be nice. @direprobs: just in case you didn't know, you can achieve what you want with something like the following in pre-3.7: with open("/dev/null", "wb", buffering=10) as outb, \ io.TextIOWrapper(outb, write_through=True) as out: out.write("x" * 20) Sadly, write_through can't be passed to open(), but it can be changed on existing TextIOWrapper since 3.7 (via new reconfigure() method). ---------- nosy: +izbyshev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 19:17:36 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 07 Dec 2017 00:17:36 +0000 Subject: [issue32234] Add context management to mailbox.Mailbox In-Reply-To: <1512574106.47.0.213398074469.issue32234@psf.upfronthosting.co.za> Message-ID: <1512605856.17.0.213398074469.issue32234@psf.upfronthosting.co.za> Nick Coghlan added the comment: I don't know the mailbox API particularly well, but the fact the object offers all three of lock(), unlock() and close() as methods does imply a fair bit of inherent ambiguity. One option would be to offer a module level "mailbox.locked()" API to handle the lock/unlock case, and then have native context management on the mailbox itself that was akin to "contextlib.closing". (Note regarding contextlib.locked(): the reason we don't currently have that is because there's no consistent protocol for locking method names. acquire()/release() and lock()/unlock() would be the most popular pairings, so we could technically offer both "contextlib.acquired()" and "contextlib.locked()", but the duplication still seems a bit dubious to me) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 19:28:35 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 07 Dec 2017 00:28:35 +0000 Subject: [issue32238] Handle "POSIX" in the legacy locale detection Message-ID: <1512606515.62.0.213398074469.issue32238@psf.upfronthosting.co.za> New submission from Nick Coghlan : Right now, the legacy locale detection introduced in PEP 538 doesn't trigger for "LANG=POSIX" and "LC_CTYPE=POSIX" on macOS and other *BSD systems. This is because we're looking specifically for "C" as the response from "setlocale(LC_CTYPE, NULL)", which works on Linux (where glibc reports "C" if you configured "POSIX"), but not on *BSD systems (where POSIX and C behave the same way, but are still reported as distinct locales). As per Jakub Wilk's comments at https://mail.python.org/pipermail/python-dev/2017-December/151105.html, this isn't right: we should allow either string to be returned from setlocale, and consider both of them as indicating a legacy locale to be coerced to an explicitly UTF-8 based one if possible. ---------- components: FreeBSD, Interpreter Core, Unicode, macOS messages: 307781 nosy: ezio.melotti, koobs, ncoghlan, ned.deily, ronaldoussoren, vstinner priority: normal severity: normal stage: test needed status: open title: Handle "POSIX" in the legacy locale detection type: behavior versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 19:39:10 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 07 Dec 2017 00:39:10 +0000 Subject: [issue32238] Handle "POSIX" in the legacy locale detection In-Reply-To: <1512606515.62.0.213398074469.issue32238@psf.upfronthosting.co.za> Message-ID: <1512607150.0.0.213398074469.issue32238@psf.upfronthosting.co.za> Nick Coghlan added the comment: Added a dependency on https://bugs.python.org/issue32002, as we should finish the test case refactoring proposed there before adjusting the `POSIX` locale handling on macOS and other *BSD systems. ---------- dependencies: +test_c_locale_coercion fails when the default LC_CTYPE != "C" _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 19:42:10 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 07 Dec 2017 00:42:10 +0000 Subject: [issue32238] Handle "POSIX" in the legacy locale detection In-Reply-To: <1512606515.62.0.213398074469.issue32238@psf.upfronthosting.co.za> Message-ID: <1512607330.32.0.213398074469.issue32238@psf.upfronthosting.co.za> Nick Coghlan added the comment: Oops, I forgot I already had an open issue for this discrepancy - I just hadn't decided how to resolve it yet. Marking as a duplicate of https://bugs.python.org/issue30672 ---------- superseder: -> PEP 538: Unexpected locale behaviour on *BSD (including Mac OS X) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 19:45:21 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 07 Dec 2017 00:45:21 +0000 Subject: [issue30672] PEP 538: Unexpected locale behaviour on *BSD (including Mac OS X) In-Reply-To: <1497518633.36.0.998856107706.issue30672@psf.upfronthosting.co.za> Message-ID: <1512607521.91.0.213398074469.issue30672@psf.upfronthosting.co.za> Nick Coghlan added the comment: As discussed in https://bugs.python.org/issue32238 and https://mail.python.org/pipermail/python-dev/2017-December/151105.html, I now think the right answer for the POSIX case is to ensure the legacy locale detection logic always treats that the same way as it does the C locale. LANG=UTF-8 I'm still not sure about - as I understand it, that's a partial locale that only defines LC_CTYPE, which may be why the libc implementation ignores it if you try to set it as a general category default. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 19:47:36 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 07 Dec 2017 00:47:36 +0000 Subject: [issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C" In-Reply-To: <1510310872.23.0.213398074469.issue32002@psf.upfronthosting.co.za> Message-ID: <1512607656.73.0.213398074469.issue32002@psf.upfronthosting.co.za> Nick Coghlan added the comment: For the POSIX case, we're going to fix the implementation to always handle that the same way as it does the "C" locale: https://bugs.python.org/issue30672#msg307784 So the main question to address with the refactoring here will be capturing the expected behaviour for the 'locale setting is an empty string' case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 20:04:26 2017 From: report at bugs.python.org (paul j3) Date: Thu, 07 Dec 2017 01:04:26 +0000 Subject: [issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse) In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za> Message-ID: <1512608666.23.0.213398074469.issue9334@psf.upfronthosting.co.za> paul j3 added the comment: In the recently pushed, https://bugs.python.org/issue14191, "argparse doesn't allow optionals within positionals" we added new parsing functionality by defining a new parser method: parse_intermixed_args It added functionality without requiring a new parameter for the parser (no point in confusing users with parameters they don't need or understand). It was also a good fit because it worked on top of the default parser, fidling with the nargs to parse positionals and options in different runs. I would like to see something similar for this problem. Define a parser.parse_opt_args() method that tries, as much as possible to follow the optparse strategy. As I commented previously, the difference in behavior starts at the top. argparse distinguishes between flag (optiona) and argument strings based on the dash(es), and then allocates strings to the Actions based on that pattern and nargs. It also alternates between handling positionals and optionals. optparse passes all the remaining strings to an Action, lets it consume what it wants, and resumes parsing with the remainder. It does not handle positionals; those are just accumulated in an 'extras' list (sort of like parse_known_args without any defined positionals). An unknown in this approach is whether the argparse.Action class(es) can be adapted to this 'consume what you want' strategy. It would be nice if such an alternative parser could be written that doesn't require any changes to the Action. We don't have to go so far as to allow custom Action classes that imitate optparse Options. But I haven't thought about this problem since 2013. I don't sense either, from other bug/issues, or Stackoverflow questions, that this is a pressing need. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 21:05:36 2017 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 07 Dec 2017 02:05:36 +0000 Subject: [issue31972] Inherited docstrings for pathlib classes are confusing In-Reply-To: <1510081543.19.0.213398074469.issue31972@psf.upfronthosting.co.za> Message-ID: <1512612336.52.0.213398074469.issue31972@psf.upfronthosting.co.za> Change by Pablo Galindo Salgado : ---------- keywords: +patch pull_requests: +4644 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 21:37:30 2017 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 07 Dec 2017 02:37:30 +0000 Subject: [issue31972] Inherited docstrings for pathlib classes are confusing In-Reply-To: <1510081543.19.0.213398074469.issue31972@psf.upfronthosting.co.za> Message-ID: <1512614250.55.0.213398074469.issue31972@psf.upfronthosting.co.za> Change by ?ric Araujo : ---------- pull_requests: -4644 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 21:40:30 2017 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 07 Dec 2017 02:40:30 +0000 Subject: [issue31972] Inherited docstrings for pathlib classes are confusing In-Reply-To: <1510081543.19.0.213398074469.issue31972@psf.upfronthosting.co.za> Message-ID: <1512614430.11.0.213398074469.issue31972@psf.upfronthosting.co.za> Change by Pablo Galindo Salgado : ---------- pull_requests: +4645 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 21:40:30 2017 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 07 Dec 2017 02:40:30 +0000 Subject: [issue32098] Hardcoded value in Lib/test/test_os.py:L1324:URandomTests.get_urandom_subprocess() In-Reply-To: <1511222798.09.0.213398074469.issue32098@psf.upfronthosting.co.za> Message-ID: <1512614430.25.0.00913614298617.issue32098@psf.upfronthosting.co.za> Change by Pablo Galindo Salgado : ---------- keywords: +patch pull_requests: +4646 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 22:54:04 2017 From: report at bugs.python.org (TaoQingyun) Date: Thu, 07 Dec 2017 03:54:04 +0000 Subject: [issue30862] parent logger should also check the level In-Reply-To: <1499303463.12.0.427912984431.issue30862@psf.upfronthosting.co.za> Message-ID: <1512618844.22.0.213398074469.issue30862@psf.upfronthosting.co.za> TaoQingyun <845767657 at qq.com> added the comment: Sorry to disturb. When calling `logging.basicConfig(level=logging.ERROR)`? I expect only the ERROR or above level will be logged. so the level argument if set should also pass to the handler. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 6 22:54:39 2017 From: report at bugs.python.org (Joshua Ringer) Date: Thu, 07 Dec 2017 03:54:39 +0000 Subject: [issue32239] decimal module exception args incorrect for c module Message-ID: <1512618879.8.0.213398074469.issue32239@psf.upfronthosting.co.za> New submission from Joshua Ringer : Exception instance args for decimal errors are supposed to be a descriptive string. However, in the c module, they are currently a list of one containing the underlying exception class. The pure python module is correct. See the following interpreter output for further detail: Python 3.6.3 (default, Oct 4 2017, 06:09:15) [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from _pydecimal import Decimal >>> Decimal('badstring') Traceback (most recent call last): File "", line 1, in File "/usr/local/Cellar/python3/3.6.3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/_pydecimal.py", line 597, in __new__ "Invalid literal for Decimal: %r" % value) File "/usr/local/Cellar/python3/3.6.3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/_pydecimal.py", line 4081, in _raise_error raise error(explanation) decimal.InvalidOperation: Invalid literal for Decimal: 'badstring' >>> from _decimal import Decimal >>> Decimal('badstring') Traceback (most recent call last): File "", line 1, in decimal.InvalidOperation: [] ---------- components: Library (Lib) messages: 307788 nosy: joshringer priority: normal severity: normal status: open title: decimal module exception args incorrect for c module type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 00:10:37 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Dec 2017 05:10:37 +0000 Subject: [issue32212] few discrepancy between source and docs in logging In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za> Message-ID: <1512623437.64.0.213398074469.issue32212@psf.upfronthosting.co.za> R. David Murray added the comment: It does matter, though, because in Python you can specify a positional argument as if it were a keyword argument if you use the name from the source rather than the documented name. We have made other doc corrections along these lines. We've even done it for C functions where you can't specify the argument as if it were a keyword argument, though that is considerably more rare. That's a different question from the question of whether typing/linters should care, though. Arguably they should recommend specifying them as positionals. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 01:56:52 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 07 Dec 2017 06:56:52 +0000 Subject: [issue32098] Hardcoded value in Lib/test/test_os.py:L1324:URandomTests.get_urandom_subprocess() In-Reply-To: <1511222798.09.0.213398074469.issue32098@psf.upfronthosting.co.za> Message-ID: <1512629812.82.0.213398074469.issue32098@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 01:57:46 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 07 Dec 2017 06:57:46 +0000 Subject: [issue32098] Hardcoded value in Lib/test/test_os.py:L1324:URandomTests.get_urandom_subprocess() In-Reply-To: <1511222798.09.0.213398074469.issue32098@psf.upfronthosting.co.za> Message-ID: <1512629866.35.0.213398074469.issue32098@psf.upfronthosting.co.za> STINNER Victor added the comment: https://github.com/python/cpython/commit/fb77e0d855e841f42c3fa504efe79eefca9efafb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 02:24:18 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 07 Dec 2017 07:24:18 +0000 Subject: [issue20361] -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options In-Reply-To: <1390468789.64.0.236388970509.issue20361@psf.upfronthosting.co.za> Message-ID: <1512631458.33.0.213398074469.issue20361@psf.upfronthosting.co.za> Change by Nick Coghlan : ---------- pull_requests: +4647 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 02:34:51 2017 From: report at bugs.python.org (Toby Harradine) Date: Thu, 07 Dec 2017 07:34:51 +0000 Subject: [issue32222] pygettext doesn't extract docstrings for functions with type annotated params In-Reply-To: <1512470175.69.0.213398074469.issue32222@psf.upfronthosting.co.za> Message-ID: <1512632091.73.0.213398074469.issue32222@psf.upfronthosting.co.za> Toby Harradine added the comment: Another correction; I said that this is occurring for return type annotations; this is not true. This is only occurring for functions with annotated *arguments*. The cause of this issue is in pygettext's TokenEater.__suiteseen method. This method eats tokens until it sees a colon operator, after which it assumes a function docstring may follow. In the case of a function with annotated arguments, obviously this is incorrect, as colons would appear before the final colon of the 'suite'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 02:37:39 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 07 Dec 2017 07:37:39 +0000 Subject: [issue20361] -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options In-Reply-To: <1390468789.64.0.236388970509.issue20361@psf.upfronthosting.co.za> Message-ID: <1512632259.7.0.213398074469.issue20361@psf.upfronthosting.co.za> Nick Coghlan added the comment: The approach I've taken in my PR is similar to the one that Arfrever proposed (albeit different in the details due to other changes in the startup code since that patch was written). For the embedding case, I've simply noted in the What's New section of the porting guide that embedding applications need to configure a `error::BytesWarning` filter explicitly if they want to treat BytesWarning as errors (in addition to setting the flag to request that the warnings be emitted in the first place). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 03:13:53 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Dec 2017 08:13:53 +0000 Subject: [issue32239] decimal module exception args incorrect for c module In-Reply-To: <1512618879.8.0.213398074469.issue32239@psf.upfronthosting.co.za> Message-ID: <1512634433.96.0.213398074469.issue32239@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 03:18:39 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Dec 2017 08:18:39 +0000 Subject: [issue31972] Inherited docstrings for pathlib classes are confusing In-Reply-To: <1510081543.19.0.213398074469.issue31972@psf.upfronthosting.co.za> Message-ID: <1512634719.68.0.213398074469.issue31972@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: -4645 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 04:31:54 2017 From: report at bugs.python.org (Toby Harradine) Date: Thu, 07 Dec 2017 09:31:54 +0000 Subject: [issue32222] pygettext doesn't extract docstrings for functions with type annotated params In-Reply-To: <1512470175.69.0.213398074469.issue32222@psf.upfronthosting.co.za> Message-ID: <1512639114.06.0.213398074469.issue32222@psf.upfronthosting.co.za> Change by Toby Harradine : ---------- keywords: +patch pull_requests: +4648 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 04:32:19 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 07 Dec 2017 09:32:19 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512639139.85.0.213398074469.issue32199@psf.upfronthosting.co.za> Change by Xavier de Gaye : Added file: https://bugs.python.org/file47326/archlinux-ip_link.strace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 04:35:02 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 07 Dec 2017 09:35:02 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512639302.53.0.213398074469.issue32199@psf.upfronthosting.co.za> Xavier de Gaye added the comment: On archlinux it is easy to know precisely what patches are applied to iproute2 and how it is built (see https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/iproute2). The attached two files, archlinux-ip_link.strace and archlinux-ip_link_list.strace, contain the output of strace run on the commands 'ip link' and 'ip link list' on archlinux. * For 'ip link', the sendto() syscall uses RTM_GETLINK to get information about a specific network interface. * For 'ip link list', this sendto() syscall is preceded by another sendto() syscall using RTM_NEWLINK to *create* information about a specific network interface. Conclusions: 1) Both commands are not equivalent, this seems to be a bug in iproute2 or its documentation (I did not read the whole iproute2 documentation). 2) By using RTM_NEWLINK, 'ip link list' requests a write-like operation that may be denied by SELinux if there is no policy that allows netlink_route_socket (nlmsg_write). I may be wrong but on Android API 26 it seems that only few processes get that permission: dhcp, clatd, logd, netd, rild, ... 3) From Python perspective it is more robust to call 'ip link' to handle platforms where SELinux is run in enforcing mode. I will update the PR to do only that change: s/ip link list/ip link/ ---------- versions: +Python 3.6 Added file: https://bugs.python.org/file47327/archlinux-ip_link_list.strace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 04:45:41 2017 From: report at bugs.python.org (Stefan Krah) Date: Thu, 07 Dec 2017 09:45:41 +0000 Subject: [issue32239] decimal module exception args incorrect for c module In-Reply-To: <1512618879.8.0.213398074469.issue32239@psf.upfronthosting.co.za> Message-ID: <1512639941.27.0.213398074469.issue32239@psf.upfronthosting.co.za> Stefan Krah added the comment: This is known and was deliberate when I wrote the module. The list contains conditions that trigger the exception. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> decimal C module's exceptions don't match the Python version _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 06:21:41 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Dec 2017 11:21:41 +0000 Subject: [issue32240] Add the const qualifier for PyObject* array arguments Message-ID: <1512645701.53.0.213398074469.issue32240@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : The proposed PR replaces argument declarations "PyObject **args" with "PyObject * const *args". In many cases this can be a pointer to the internal array of the tuple object. It is not safe to change it. PyEval_EvalCodeEx() is the only public function affected by this change, but this change is backward compatible. All other affected code is a private C API. ---------- messages: 307795 nosy: serhiy.storchaka, vstinner priority: normal severity: normal status: open title: Add the const qualifier for PyObject* array arguments type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 06:23:50 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Dec 2017 11:23:50 +0000 Subject: [issue32240] Add the const qualifier for PyObject* array arguments In-Reply-To: <1512645701.53.0.213398074469.issue32240@psf.upfronthosting.co.za> Message-ID: <1512645830.04.0.213398074469.issue32240@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +4649 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 06:31:29 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 07 Dec 2017 11:31:29 +0000 Subject: [issue32240] Add the const qualifier for PyObject* array arguments In-Reply-To: <1512645701.53.0.213398074469.issue32240@psf.upfronthosting.co.za> Message-ID: <1512646289.85.0.213398074469.issue32240@psf.upfronthosting.co.za> STINNER Victor added the comment: I hate this "obscure" C syntax "PyObject * const *args". Technically, is it possible to define it as a type with a better name to give more context where the type would be defined? For example, "PyConstObjectArray"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 06:58:32 2017 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 07 Dec 2017 11:58:32 +0000 Subject: [issue32238] Handle "POSIX" in the legacy locale detection In-Reply-To: <1512606515.62.0.213398074469.issue32238@psf.upfronthosting.co.za> Message-ID: <1512647912.52.0.213398074469.issue32238@psf.upfronthosting.co.za> Change by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 06:59:17 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 07 Dec 2017 11:59:17 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512647957.69.0.213398074469.issue32199@psf.upfronthosting.co.za> Xavier de Gaye added the comment: New changeset 961dbe0548e26394b7716d41423c61b1e2e58ef7 by xdegaye in branch 'master': bpo-32199: The getnode() ip getter now uses 'ip link' instead of 'ip link list' (GH-4696) https://github.com/python/cpython/commit/961dbe0548e26394b7716d41423c61b1e2e58ef7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 06:59:42 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Dec 2017 11:59:42 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512647982.31.0.213398074469.issue32199@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4650 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 07:17:15 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Dec 2017 12:17:15 +0000 Subject: [issue32240] Add the const qualifier for PyObject* array arguments In-Reply-To: <1512645701.53.0.213398074469.issue32240@psf.upfronthosting.co.za> Message-ID: <1512649035.8.0.213398074469.issue32240@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't like "PyConstObjectArray" or any other name. I will just obfuscate the C code. "PyObject * const *args" should be clear for every C programmer, but if I see "PyConstObjectArray" I need to search the definition of it in the header files. And it is easy to make a mistake by using "PyConstObjectArray *" instead of "PyConstObjectArray" since complex types usually are passed by pointer in C. If you prefer, "PyObject * const *args" can be written as "PyObject * const args[]". This is an identical syntax, but the latter form is used more rarely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 07:24:50 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Dec 2017 12:24:50 +0000 Subject: [issue32240] Add the const qualifier for PyObject* array arguments In-Reply-To: <1512645701.53.0.213398074469.issue32240@psf.upfronthosting.co.za> Message-ID: <1512649490.22.0.213398074469.issue32240@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This change is inspired by reviewing one PR in which an input array of PyObject* was modified inplace. Even if it was correct in that particular case, it looked unsafe (actually that code was wrong for other causes). Adding the const qualifier allows to distinguish input PyObject* array arguments from pointers to output PyObject* arguments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 07:44:13 2017 From: report at bugs.python.org (Matthias Klose) Date: Thu, 07 Dec 2017 12:44:13 +0000 Subject: [issue32235] [2.7 regression] test_xml_etree test_xml_etree_c failures with 2.7 and 3.6 branches 20171205 In-Reply-To: <1512578273.44.0.213398074469.issue32235@psf.upfronthosting.co.za> Message-ID: <1512650653.87.0.213398074469.issue32235@psf.upfronthosting.co.za> Matthias Klose added the comment: ok, I can confirm that the failures go away with an updated version. Then trying to find documentation about required external dependencies... None. While we have pointers to optimize the build, we don't have anything about requirements in the toplevel README.md. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 07:44:28 2017 From: report at bugs.python.org (Matthias Klose) Date: Thu, 07 Dec 2017 12:44:28 +0000 Subject: [issue32235] test_xml_etree test_xml_etree_c failures with 2.7 and 3.6 branches 20171205 In-Reply-To: <1512578273.44.0.213398074469.issue32235@psf.upfronthosting.co.za> Message-ID: <1512650668.83.0.213398074469.issue32235@psf.upfronthosting.co.za> Change by Matthias Klose : ---------- title: [2.7 regression] test_xml_etree test_xml_etree_c failures with 2.7 and 3.6 branches 20171205 -> test_xml_etree test_xml_etree_c failures with 2.7 and 3.6 branches 20171205 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 07:48:20 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 07 Dec 2017 12:48:20 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512650900.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Xavier de Gaye added the comment: New changeset 03031fbc7d44106d652756462db34eae67de9568 by xdegaye (Miss Islington (bot)) in branch '3.6': bpo-32199: The getnode() ip getter now uses 'ip link' instead of 'ip link list' (GH-4696) (#4747) https://github.com/python/cpython/commit/03031fbc7d44106d652756462db34eae67de9568 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 07:50:06 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 07 Dec 2017 12:50:06 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512651006.51.0.213398074469.issue32199@psf.upfronthosting.co.za> Change by Xavier de Gaye : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 08:54:04 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Dec 2017 13:54:04 +0000 Subject: [issue32241] Add the const qualifier for char and wchar_t pointers to unmodifiable strings Message-ID: <1512654844.82.0.213398074469.issue32241@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : Py_SetProgramName() and Py_SetPythonHome() take a pointer to a string that shouldn't be changed for the duration of the program's execution. But the type of their arguments is "wchar_t *", therefore passing just a pointer to a constant static string will cause a compiler warning. The proposed PR changes the type to "const wchar_t *". This is backward compatible change. The PR also adds the const qualifier to internal pointers that point on to unmodifiable strings. This could help to distinguish them from pointers on modifiable strings and can prevent unintentional modifications. ---------- components: Interpreter Core messages: 307802 nosy: serhiy.storchaka, vstinner priority: normal severity: normal status: open title: Add the const qualifier for char and wchar_t pointers to unmodifiable strings type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 08:58:48 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Dec 2017 13:58:48 +0000 Subject: [issue32241] Add the const qualifier for char and wchar_t pointers to unmodifiable strings In-Reply-To: <1512654844.82.0.213398074469.issue32241@psf.upfronthosting.co.za> Message-ID: <1512655128.85.0.213398074469.issue32241@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +4651 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 09:15:53 2017 From: report at bugs.python.org (Vishu Viswanathan) Date: Thu, 07 Dec 2017 14:15:53 +0000 Subject: [issue32242] loop in loop with with 'zip'ped object misbehaves in py3.6 Message-ID: <1512656153.71.0.213398074469.issue32242@psf.upfronthosting.co.za> New submission from Vishu Viswanathan : The file shows the results by running in Py3.6 and 2.7 In my opinion Py2.7 results matches what I expected. In this bug or the zip function behaviour is changed with some purpose ---------- files: py3.6_vs_py2.7.ipynb messages: 307803 nosy: Vishu Viswanathan priority: normal severity: normal status: open title: loop in loop with with 'zip'ped object misbehaves in py3.6 type: behavior versions: Python 3.6 Added file: https://bugs.python.org/file47328/py3.6_vs_py2.7.ipynb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 09:23:18 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 07 Dec 2017 14:23:18 +0000 Subject: [issue32242] loop in loop with with 'zip'ped object misbehaves in py3.6 In-Reply-To: <1512656153.71.0.213398074469.issue32242@psf.upfronthosting.co.za> Message-ID: <1512656598.77.0.213398074469.issue32242@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I'm sorry, I have no idea how to read an Anaconda notebook file. In the browser it looks like some sort of nested dictionary. I can find the code: j = [1, 2, 3, 4] k = [5, 6, 7, 8] z = zip(j, k) for x, y in z: for m, n in z: print (x, y, m, n) but I'm not sure what result you are getting or what results you expect. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 09:29:48 2017 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 07 Dec 2017 14:29:48 +0000 Subject: [issue32242] loop in loop with with 'zip'ped object misbehaves in py3.6 In-Reply-To: <1512656153.71.0.213398074469.issue32242@psf.upfronthosting.co.za> Message-ID: <1512656988.49.0.213398074469.issue32242@psf.upfronthosting.co.za> Ronald Oussoren added the comment: If the nested loop is the issue the Python 3 version behaves as expected. A difference between python2 and python3 is that the zip() builtin returns a list on python2 and an iterator on python3. This explains the difference in results in running the code on the two versions. To get the same behaviour on Python 2 and Python 3 use "list(zip(j, k))". ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 09:32:28 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 07 Dec 2017 14:32:28 +0000 Subject: [issue32242] loop in loop with with 'zip'ped object misbehaves in py3.6 In-Reply-To: <1512656153.71.0.213398074469.issue32242@psf.upfronthosting.co.za> Message-ID: <1512657148.16.0.213398074469.issue32242@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In Python 2 zip() returns a list. In Python 3 it returns an iterator (like itertools.izip() in Python 2). This is an intentional change. For restoring the Python 2 behavior you should wrap the result of zip() into list(): z = list(zip(j, k)). The 2to3 command can do this for you. ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 09:33:16 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 07 Dec 2017 14:33:16 +0000 Subject: [issue32242] loop in loop with with 'zip'ped object misbehaves in py3.6 In-Reply-To: <1512656153.71.0.213398074469.issue32242@psf.upfronthosting.co.za> Message-ID: <1512657196.66.0.213398074469.issue32242@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I decided to run the code in 3.5 and 2.7, and now that I know what I'm looking for, I can see the results buried in the Anaconda notebook. This is not a bug, zip has been changed in Python 3 to return an iterator instead of a list. To get the same results as Python 2.7, change the line: z = zip(j, k) to: z = list(zip(j, k)) To get the same results in 2.7 as in 3, change it to: z = iter(zip(j, k)) This is documented and is not a bug. https://docs.python.org/3.0/whatsnew/3.0.html#views-and-iterators-instead-of-lists https://docs.python.org/3/library/functions.html#zip ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 09:38:53 2017 From: report at bugs.python.org (Erik Bray) Date: Thu, 07 Dec 2017 14:38:53 +0000 Subject: [issue32243] Tests that set aggressive switch interval hang in Cygwin on a VM Message-ID: <1512657533.84.0.213398074469.issue32243@psf.upfronthosting.co.za> New submission from Erik Bray : This is basically the same as #26939, but rather than Android running in an emulator it is affecting Cygwin running in a slow VM (in this case it's on my university's OpenStack infrastructure--I don't know what hypervisor they're using but probably KVM--either way the point is that it's a Windows VM and relatively slow). With Cygwin on Windows running natively this has never been a problem. FWIW I tried my own version of Victor's patch from #23428 (adapted to the new _PyTime API). This patch would be worth applying regardless and I can attach my version of the patch to that ticket, but alone it did not fix it. On top of that I also added a version of Xavier's patch from #26939 that adjusts the wait interval in PyCOND_TIMEDWAIT to ensure that the deadline is late enough to account for delays. I'm not sure that this is completely fool-proof, but it solved the problem for me. With that patch I was unable to make the system hang again. For some reason in #26939 that more general fix was abandoned in favor of simply setting the switch interval less aggressively for those tests in the particular case of the android emulator. But it seems that the more general fix might still be worthwhile. ---------- components: Tests messages: 307808 nosy: erik.bray priority: normal severity: normal status: open title: Tests that set aggressive switch interval hang in Cygwin on a VM _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 10:09:59 2017 From: report at bugs.python.org (Tom Cook) Date: Thu, 07 Dec 2017 15:09:59 +0000 Subject: [issue32244] Multiprocessing: multiprocessing.connection.Listener.accept() should accept a timeout Message-ID: <1512659399.52.0.213398074469.issue32244@psf.upfronthosting.co.za> New submission from Tom Cook : If nothing connects to it, `multiprocessing.connection.Listener.accept()` will block forever with no good way to interrupt it. Supposing that a thread implements a loop like this: def run(self): l = Listener(socket_path, 'AF_UNIX') while self.running: c = l.accept() while self.running: data = c.recv() self.process(data) There is no obvious way to implement a `stop` method on this thread. Setting `self.running = False` may never result in the thread terminating, as it may be that no client connects to it. The following is a possible way of implementing it: def stop(self): self.running = False try: c = Client(socket_path, 'AF_UNIX') except: pass however it seems fraught with race conditions. Letting `accept()` accept a timeout would be a much cleaner solution to this and many similar problems. ---------- components: Library (Lib) messages: 307809 nosy: Tom Cook priority: normal severity: normal status: open title: Multiprocessing: multiprocessing.connection.Listener.accept() should accept a timeout type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 10:12:45 2017 From: report at bugs.python.org (Tom Cook) Date: Thu, 07 Dec 2017 15:12:45 +0000 Subject: [issue32244] Multiprocessing: multiprocessing.connection.Listener.accept() should accept a timeout In-Reply-To: <1512659399.52.0.213398074469.issue32244@psf.upfronthosting.co.za> Message-ID: <1512659565.91.0.213398074469.issue32244@psf.upfronthosting.co.za> Tom Cook added the comment: The same goes for `Connection.recv()`, as in the sample code another case where the thread will never terminate is when a `Client` is connected to the socket but never sends any messages; in this case, the call to `recv()` will block forever. There is no way at all to interrupt this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 10:21:22 2017 From: report at bugs.python.org (Simon Depiets) Date: Thu, 07 Dec 2017 15:21:22 +0000 Subject: [issue32245] OSError: raw write() returned invalid length on latest Win 10 Consoles Message-ID: <1512660082.17.0.213398074469.issue32245@psf.upfronthosting.co.za> New submission from Simon Depiets : A couple of users have been having issues on console output since the Fall 2017 Creator Update on Windows 10 An OSError is triggered randomly when rewriting data on the console (typically with progress bars, for instance when you install a module with pip), this only happens with the Microsoft Console (within Powershell or cmd.exe). It seems the windows stdout console stream returns a length double what python expects. I don't have the skills to go deeper than the bufferedio.c method _bufferedwriter_raw_write to diagnostic the issue, so I've made a very dirty fix (which I do not recommend) https://github.com/python/cpython/compare/3.5...LlianeFR:patch-1 Different unrelated use cases where an error is triggered : https://stackoverflow.com/questions/47356993/oserror-raw-write-returned-invalid-length-when-using-print-in-python https://github.com/Microsoft/vscode/issues/39149 ---------- components: IO messages: 307811 nosy: Simon Depiets priority: normal severity: normal status: open title: OSError: raw write() returned invalid length on latest Win 10 Consoles type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 10:44:12 2017 From: report at bugs.python.org (Petr Viktorin) Date: Thu, 07 Dec 2017 15:44:12 +0000 Subject: [issue6531] atexit_callfuncs() crashing within Py_Finalize() when using multiple interpreters. In-Reply-To: <1248175169.79.0.15962102552.issue6531@psf.upfronthosting.co.za> Message-ID: <1512661452.8.0.213398074469.issue6531@psf.upfronthosting.co.za> Change by Petr Viktorin : ---------- nosy: +Dormouse759, encukou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 11:01:42 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 07 Dec 2017 16:01:42 +0000 Subject: [issue32246] test_regrtest alters the execution environment on Android Message-ID: <1512662502.3.0.213398074469.issue32246@psf.upfronthosting.co.za> New submission from Xavier de Gaye : Sorry, this is a bit involved :-( BTW all the tests except this one pass (ctypes is disabled on x86_64 and arm64) on Android API 24 for x86, x86_64, armv7 and arm64 :-) Description: ----------- There are two different cases: 1) When buildbottest is tweaked to run only test_regrtest and is run remotely from the build system, the error occurs systematically and is: Warning -- files was modified by test_regrtest Before: [] After: ['test_python_2535/'] Here is the command that is run remotely (through adb), the run_tests.py file is Tools/scripts/run_tests.py from the src tree that has been pushed to the emulator by buildbottest: python /data/local/tmp/python/bin/run_tests.py -j 1 -u all -W --slowest --fail-env-changed --timeout=900 -j2 test_regrtest The command also fails when replacing '-j2' with '-j1'. In that case: * There is no 'test_support_*' directory left over in the TEMP directory, the directory is clean. * The command 'adb logcat' reports a crash ("Fatal signal 11 (SIGSEGV)") during the execution of the command. This sounds familiar :-) 2) When this same command is run on the emulator (i.e. the user is remotely logged in with the command 'adb shell'), the environment is never altered (never == about 20 attempts to raise the problem). In that case: * A 'test_support_*' directory is left in the TEMP directory and it is empty. The fact that the TEMP directory is not clean already happens when running buildbottest natively with the standard Python Makefile (no one has noticed it yet I guess) and the directory contains a core file. This is another bug, related to this one and it provided a much welcome hint to use 'adb logcat' and for a work-around :-) Maybe this last bug is related to issue 26295 ? Work-around ----------- * The problem does not happen when skipping ArgsTestCase.test_crashed for Android in the same manner that tests that raise SIGSEGV are skipped in test_faulthandler. And there is no 'test_support_*' directory left over in the TEMP directory. ---------- components: Tests messages: 307812 nosy: vstinner, xdegaye priority: normal severity: normal stage: needs patch status: open title: test_regrtest alters the execution environment on Android type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 11:07:23 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 07 Dec 2017 16:07:23 +0000 Subject: [issue32246] test_regrtest alters the execution environment on Android In-Reply-To: <1512662502.3.0.213398074469.issue32246@psf.upfronthosting.co.za> Message-ID: <1512662843.66.0.213398074469.issue32246@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > The command 'adb logcat' reports a crash ("Fatal signal 11 (SIGSEGV)") during the execution of the command. This sounds familiar :-) See issue #32138 and #26934. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 11:09:10 2017 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 07 Dec 2017 16:09:10 +0000 Subject: [issue13420] newer() function in dep_util.py discard changes in the same second In-Reply-To: <1321529038.98.0.0841934486822.issue13420@psf.upfronthosting.co.za> Message-ID: <1512662950.3.0.213398074469.issue13420@psf.upfronthosting.co.za> Jakub Wilk added the comment: I don't remember why I needed it. Sorry! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 11:26:36 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 07 Dec 2017 16:26:36 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512663996.35.0.213398074469.issue32199@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: LGTM, and thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 11:37:29 2017 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 07 Dec 2017 16:37:29 +0000 Subject: [issue26414] os.defpath too permissive In-Reply-To: <1456181417.61.0.91952600054.issue26414@psf.upfronthosting.co.za> Message-ID: <1512664649.16.0.213398074469.issue26414@psf.upfronthosting.co.za> Jakub Wilk added the comment: Linux man page for execvp(3) says: > The default search path (used when the environment does not contain > the variable PATH) shows some variation across systems. It generally > includes /bin and /usr/bin (in that order) and may also include the > current working directory. On some other systems, the current > working is included after /bin and /usr/bin, as an anti-Trojan-horse > measure. The glibc implementation long followed the traditional > default where the current working directory is included at the start > of the search path. However, some code refactoring during the > development of glibc 2.24 caused the current working directory to be > dropped altogether from the default search path. This accidental > behavior change is considered mildly beneficial, and won't be > reverted. So while having cwd is os.defpath has some historical justification, now that glibc dropped it from its default PATH, it would be prudent for Python to follow the suit. ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 11:39:39 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 07 Dec 2017 16:39:39 +0000 Subject: [issue32199] uuid.getnode() should return the MAC address on Android In-Reply-To: <1512224979.48.0.213398074469.issue32199@psf.upfronthosting.co.za> Message-ID: <1512664779.47.0.213398074469.issue32199@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Thanks Serhiy and Barry for your comments and reviews :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 11:41:19 2017 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 07 Dec 2017 16:41:19 +0000 Subject: [issue30862] parent logger should also check the level In-Reply-To: <1499303463.12.0.427912984431.issue30862@psf.upfronthosting.co.za> Message-ID: <1512664879.58.0.213398074469.issue30862@psf.upfronthosting.co.za> Vinay Sajip added the comment: basicConfig() provides default behaviour for simple cases. If you don't like the defaults it provides, you can choose your own configuration code to do exactly what you want. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 12:35:10 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Thu, 07 Dec 2017 17:35:10 +0000 Subject: [issue32237] test_xml_etree leaked [1, 1, 1] references, sum=3 In-Reply-To: <1512604950.09.0.213398074469.issue32237@psf.upfronthosting.co.za> Message-ID: <1512668110.53.0.213398074469.issue32237@psf.upfronthosting.co.za> Change by Neil Schemenauer : ---------- keywords: +patch pull_requests: +4652 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 13:04:30 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 07 Dec 2017 18:04:30 +0000 Subject: [issue32208] Improve semaphore documentation In-Reply-To: <1512357480.91.0.213398074469.issue32208@psf.upfronthosting.co.za> Message-ID: <1512669870.18.0.213398074469.issue32208@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset a0374dd34aa25f0895195d388b5ceff43b121b00 by Andrew Svetlov (Garrett Berg) in branch 'master': bpo-32208: update threading.Semaphore docs and add unit test (#4709) https://github.com/python/cpython/commit/a0374dd34aa25f0895195d388b5ceff43b121b00 ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 13:04:35 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Dec 2017 18:04:35 +0000 Subject: [issue32208] Improve semaphore documentation In-Reply-To: <1512357480.91.0.213398074469.issue32208@psf.upfronthosting.co.za> Message-ID: <1512669875.89.0.213398074469.issue32208@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4653 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 13:48:37 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 07 Dec 2017 18:48:37 +0000 Subject: [issue32208] Improve semaphore documentation In-Reply-To: <1512357480.91.0.213398074469.issue32208@psf.upfronthosting.co.za> Message-ID: <1512672517.71.0.213398074469.issue32208@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset a04ca12e12b522850e7e9244c250754d3cd36f0a by Andrew Svetlov (Miss Islington (bot)) in branch '3.6': bpo-32208: update threading.Semaphore docs and add unit test (GH-4709) (#4750) https://github.com/python/cpython/commit/a04ca12e12b522850e7e9244c250754d3cd36f0a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 15:25:10 2017 From: report at bugs.python.org (Mario Corchero) Date: Thu, 07 Dec 2017 20:25:10 +0000 Subject: [issue32206] Run modules with pdb In-Reply-To: <1512308200.99.0.213398074469.issue32206@psf.upfronthosting.co.za> Message-ID: <1512678310.99.0.213398074469.issue32206@psf.upfronthosting.co.za> Change by Mario Corchero : ---------- keywords: +patch pull_requests: +4654 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 15:25:41 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 07 Dec 2017 20:25:41 +0000 Subject: [issue32186] io.FileIO hang all threads if fstat blocks on inaccessible NFS server In-Reply-To: <1512066205.79.0.213398074469.issue32186@psf.upfronthosting.co.za> Message-ID: <1512678341.44.0.213398074469.issue32186@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 830daae1c82ed33deef0086b7b6323e5be0b0cc8 by Victor Stinner (Nir Soffer) in branch '2.7': [2.7] bpo-32186: Release the GIL during fstat and lseek calls (#4651) https://github.com/python/cpython/commit/830daae1c82ed33deef0086b7b6323e5be0b0cc8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 15:27:00 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 07 Dec 2017 20:27:00 +0000 Subject: [issue32186] io.FileIO hang all threads if fstat blocks on inaccessible NFS server In-Reply-To: <1512066205.79.0.213398074469.issue32186@psf.upfronthosting.co.za> Message-ID: <1512678420.53.0.213398074469.issue32186@psf.upfronthosting.co.za> STINNER Victor added the comment: The bug has been fixed in Python 2.7, 3.6 and the master branch. Thank you Nir Soffer for the bug report and the fix! ---------- versions: -Python 3.5, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 15:56:56 2017 From: report at bugs.python.org (Radostin) Date: Thu, 07 Dec 2017 20:56:56 +0000 Subject: [issue32247] shutil-copytree: Create dst folder only if it doesn't exist Message-ID: <1512680216.59.0.213398074469.issue32247@psf.upfronthosting.co.za> New submission from Radostin : shutil.copytree method always tries to create the destination directory which raises the error message "OSError: [Errno 17] File exists". This issue has been discussed here: https://stackoverflow.com/questions/1868714/how-do-i-copy-an-entire-directory-of-files-into-an-existing-directory-using-pyth ---------- messages: 307823 nosy: rst0py priority: normal pull_requests: 4655 severity: normal status: open title: shutil-copytree: Create dst folder only if it doesn't exist type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 16:12:39 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 07 Dec 2017 21:12:39 +0000 Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7 Message-ID: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za> New submission from Barry A. Warsaw : We intend to port importlib_resources to Python 3.7 as importlib.resources, with a provisional API. There's also a ResourceReader ABC to include, along with documentation and tests. Nosying Brett and assigning to myself, but if Brett *wants* to do the work, I won't stand in his way. :) ---------- assignee: barry components: Library (Lib) messages: 307824 nosy: barry, brett.cannon priority: normal severity: normal status: open title: Port importlib_resources (module and ABC) to Python 3.7 versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 17:13:20 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 07 Dec 2017 22:13:20 +0000 Subject: [issue32193] Convert asyncio to async/await In-Reply-To: <1512121472.71.0.213398074469.issue32193@psf.upfronthosting.co.za> Message-ID: <1512684800.29.0.213398074469.issue32193@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- keywords: +patch pull_requests: +4656 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 17:47:25 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 07 Dec 2017 22:47:25 +0000 Subject: [issue32249] Document handler.cancelled() Message-ID: <1512686845.02.0.213398074469.issue32249@psf.upfronthosting.co.za> New submission from Andrew Svetlov : Method was added by https://bugs.python.org/issue31943 ---------- components: asyncio messages: 307825 nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Document handler.cancelled() versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 18:04:02 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 07 Dec 2017 23:04:02 +0000 Subject: [issue32250] Add loop.current_task() and loop.all_tasks() methods Message-ID: <1512687842.07.0.213398074469.issue32250@psf.upfronthosting.co.za> New submission from Andrew Svetlov : Existing `Task.current_task()` and `Task.all_tasks()` class methods are not overridable by custom event loop implementation. The proposal is adding new optional loop methods and using them by existing task methods. ---------- components: asyncio messages: 307826 nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Add loop.current_task() and loop.all_tasks() methods versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 18:04:31 2017 From: report at bugs.python.org (Mark Shannon) Date: Thu, 07 Dec 2017 23:04:31 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1512687871.94.0.213398074469.issue17611@psf.upfronthosting.co.za> Mark Shannon added the comment: Thanks, that example shows the essence of the problem. I understand you perfectly now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 18:07:24 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 07 Dec 2017 23:07:24 +0000 Subject: [issue32193] Convert asyncio to async/await In-Reply-To: <1512121472.71.0.213398074469.issue32193@psf.upfronthosting.co.za> Message-ID: <1512688044.97.0.213398074469.issue32193@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 18:12:45 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 07 Dec 2017 23:12:45 +0000 Subject: [issue32246] test_regrtest alters the execution environment on Android In-Reply-To: <1512662502.3.0.213398074469.issue32246@psf.upfronthosting.co.za> Message-ID: <1512688365.66.0.213398074469.issue32246@psf.upfronthosting.co.za> STINNER Victor added the comment: > The command 'adb logcat' reports a crash ("Fatal signal 11 (SIGSEGV)") during the execution of the command. This sounds familiar :-) test_crashed() does crash on SIGGEV on purpose. It tests how regrtest behaves when a worker does crash. The exacty signal doesn't matter. This function uses faulthandler._sigsegv() which is supposed to "suppress crash report": see faulthandler_suppress_crash_report() in Modules/faulthandler.c, but also SuppressCrashReport in test/support/__init__.py. Maybe we need to disable the Android crash reporter as well? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 18:20:32 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 07 Dec 2017 23:20:32 +0000 Subject: [issue32246] test_regrtest alters the execution environment on Android In-Reply-To: <1512662502.3.0.213398074469.issue32246@psf.upfronthosting.co.za> Message-ID: <1512688832.79.0.213398074469.issue32246@psf.upfronthosting.co.za> STINNER Victor added the comment: > The fact that the TEMP directory is not clean already happens when running buildbottest natively with the standard Python Makefile (no one has noticed it yet I guess) and the directory contains a core file. The root issue is likely the core file. I got a similar issue on FreeBSD when an unit test crashed on purpose but forgot to suppress crash report. You should either find a way to disable the creation of core file when using faulthandler_suppress_crash_report() and/or SuppressCrashReport, or skip the test on Android. I'm fine with skipped the test on Android, since the test currently uses faulthandler._sigsegv() which is already skipped on Android in test_faulthandler: def skip_segfault_on_android(test): # Issue #32138: Raising SIGSEGV on Android may not cause a crash. return unittest.skipIf(is_android, 'raising SIGSEGV on Android is unreliable')(test) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 20:25:20 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 08 Dec 2017 01:25:20 +0000 Subject: [issue8722] Documentation for __getattr__ In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za> Message-ID: <1512696320.17.0.213398074469.issue8722@psf.upfronthosting.co.za> Change by Cheryl Sabella : ---------- pull_requests: +4657 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 20:27:13 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 08 Dec 2017 01:27:13 +0000 Subject: [issue8722] Documentation for __getattr__ In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za> Message-ID: <1512696433.88.0.213398074469.issue8722@psf.upfronthosting.co.za> Change by Cheryl Sabella : ---------- keywords: +needs review -patch versions: +Python 3.6, Python 3.7 -Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 21:04:18 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 08 Dec 2017 02:04:18 +0000 Subject: [issue32251] Add asyncio.BufferedProtocol Message-ID: <1512698658.84.0.213398074469.issue32251@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- assignee: yselivanov components: asyncio nosy: asvetlov, gvanrossum, pitrou, yselivanov priority: normal severity: normal status: open title: Add asyncio.BufferedProtocol versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 21:10:39 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 08 Dec 2017 02:10:39 +0000 Subject: [issue32251] Add asyncio.BufferedProtocol Message-ID: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za> New submission from Yury Selivanov : A couple emails from async-sig for the context: 1. https://mail.python.org/pipermail/async-sig/2017-October/000392.html 2. https://mail.python.org/pipermail/async-sig/2017-December/000423.html I propose to add another Protocol base class to asyncio: BufferedProtocol. ?It will have 'get_buffer()' and 'buffer_updated(nbytes)' methods instead of 'data_received()': ? ? class asyncio.BufferedProtocol: ? ? ? ? def get_buffer(self) -> memoryview: ? ? ? ? ? ? pass ? ? ? ? def buffer_updated(self, nbytes: int): ? ? ? ? ? ? pass When the protocol's transport is ready to receive data, it will call `protocol.get_buffer()`. ?The latter must return an object that implements the buffer protocol. ?The transport will request a writable buffer over the returned object and receive data *into* that buffer. When the `sock.recv_into(buffer)` call is done, `protocol.buffer_updated(nbytes)` method will be called. ?The number of bytes received into the buffer will be passed as a first argument. I've implemented the proposed design in uvloop (branch 'get_buffer', [1]) and adjusted your benchmark [2] to use it. ?Here are benchmark results from my machine (macOS): vanilla asyncio: 120-135 Mb/s uvloop: 320-330 Mb/s uvloop/get_buffer: 600-650 Mb/s. [1]?https://github.com/MagicStack/uvloop/tree/get_buffer [2]?https://gist.github.com/1st1/1c606e5b83ef0e9c41faf21564d75ad7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 21:12:48 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Dec 2017 02:12:48 +0000 Subject: [issue8722] Documentation for __getattr__ In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za> Message-ID: <1512699168.88.0.213398074469.issue8722@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Cheryl, thank you for reviving this, as it is still needed. A slightly revised example better illustrates the claim in the doc revision about when __getattr__ is called. class Foo(object): def __init__(self): self.foo = 1 self.data = {"bing": 4} def __getattr__(self, name): print(f'Getting {name}') return self.data.get(name) @property def bar(self): return 3 @property def bing(self): raise AttributeError("blarg") f = Foo() print('foo', f.foo) print('__str__', f.__str__) print('bar', f.bar) print('bing', f.bing) f.__getattribute__('bing') # prints foo 1 __str__ bar 3 Getting bing bing 4 Traceback (most recent call last): File "F:\Python\a\tem2.py", line 24, in f.__getattribute__('bing') File "F:\Python\a\tem2.py", line 17, in bing raise AttributeError("blarg") AttributeError: blarg ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 21:25:23 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 08 Dec 2017 02:25:23 +0000 Subject: [issue32251] Add asyncio.BufferedProtocol In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za> Message-ID: <1512699923.17.0.213398074469.issue32251@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4658 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 21:48:22 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 08 Dec 2017 02:48:22 +0000 Subject: [issue32251] Add asyncio.BufferedProtocol In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za> Message-ID: <1512701302.49.0.213398074469.issue32251@psf.upfronthosting.co.za> Yury Selivanov added the comment: I've made a PR that implements the change for selector_events.py. With the change: vanilla asyncio: 120-135 Mb/s vanilla asyncio/get_buffer: 220-230 Mb/s uvloop: 320-330 Mb/s uvloop/get_buffer: 600-650 Mb/s If we decide to go forward with the proposed design, I'll update the PR with support for proactor_events ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 22:59:12 2017 From: report at bugs.python.org (Nitish) Date: Fri, 08 Dec 2017 03:59:12 +0000 Subject: [issue28197] Add start and stop parameters to the range.index() ABC method In-Reply-To: <1474231832.91.0.157673750963.issue28197@psf.upfronthosting.co.za> Message-ID: <1512705552.77.0.213398074469.issue28197@psf.upfronthosting.co.za> Nitish added the comment: Any comments on the PR? ---------- nosy: +nitishch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 22:59:27 2017 From: report at bugs.python.org (Nitish) Date: Fri, 08 Dec 2017 03:59:27 +0000 Subject: [issue31942] Document that support of start and stop parameters in the Sequence's index() is optional In-Reply-To: <1509786601.53.0.213398074469.issue31942@psf.upfronthosting.co.za> Message-ID: <1512705567.16.0.213398074469.issue31942@psf.upfronthosting.co.za> Nitish added the comment: Any comments on the PR? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 7 23:41:14 2017 From: report at bugs.python.org (iMath) Date: Fri, 08 Dec 2017 04:41:14 +0000 Subject: [issue30904] Python 3 logging HTTPHandler sends duplicate Host header In-Reply-To: <1499782260.84.0.538162652134.issue30904@psf.upfronthosting.co.za> Message-ID: <1512708074.26.0.213398074469.issue30904@psf.upfronthosting.co.za> iMath added the comment: Yes, I met with the same bug, see the post for description and bug investigation https://stackoverflow.com/questions/43185804/using-httphandler-cause-django-server-side-shows-http-400-and-invalid-http-host/47434323#47434323 ---------- nosy: +redstone-cold _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 01:04:49 2017 From: report at bugs.python.org (Vishu Viswanathan) Date: Fri, 08 Dec 2017 06:04:49 +0000 Subject: [issue32242] loop in loop with with 'zip'ped object misbehaves in py3.6 In-Reply-To: <1512657196.66.0.213398074469.issue32242@psf.upfronthosting.co.za> Message-ID: Vishu Viswanathan added the comment: Thanks for the fast response and clarification. Now I can run my code made for py2.7 also run in py3.6 I should search and read documentation before reporting. Thanks On Thu, Dec 7, 2017 at 8:03 PM, Steven D'Aprano wrote: > > Steven D'Aprano added the comment: > > I decided to run the code in 3.5 and 2.7, and now that I know what I'm > looking for, I can see the results buried in the Anaconda notebook. > > This is not a bug, zip has been changed in Python 3 to return an iterator > instead of a list. To get the same results as Python 2.7, change the line: > > z = zip(j, k) > > to: > > z = list(zip(j, k)) > > To get the same results in 2.7 as in 3, change it to: > > z = iter(zip(j, k)) > > This is documented and is not a bug. > > https://docs.python.org/3.0/whatsnew/3.0.html#views-and- > iterators-instead-of-lists > > https://docs.python.org/3/library/functions.html#zip > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 03:49:13 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 08 Dec 2017 08:49:13 +0000 Subject: [issue32252] test_regrtest leaves a test_python_* directory in TEMPDIR Message-ID: <1512722953.36.0.213398074469.issue32252@psf.upfronthosting.co.za> New submission from Xavier de Gaye : After running test_regrtest in the source tree on linux, the build/ subdirectory (i.e. test.libregrtest.main.TEMPDIR) contains a new test_python_* directory that contains a core file when the core file size is unlimited. I did not test on 3.6. ---------- components: Tests messages: 307837 nosy: vstinner, xdegaye priority: normal severity: normal stage: needs patch status: open title: test_regrtest leaves a test_python_* directory in TEMPDIR type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 03:53:56 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 08 Dec 2017 08:53:56 +0000 Subject: [issue32246] test_regrtest alters the execution environment on Android In-Reply-To: <1512662502.3.0.213398074469.issue32246@psf.upfronthosting.co.za> Message-ID: <1512723236.33.0.213398074469.issue32246@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > The fact that the TEMP directory is not clean already happens when running buildbottest natively with the standard Python Makefile (no one has noticed it yet I guess) and the directory contains a core file. I should have written "happens on linux" instead of "happens when running buildbottest natively with the standard Python Makefile". I have now created issue 32252 for that distinct problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 03:59:40 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 08 Dec 2017 08:59:40 +0000 Subject: [issue32253] Deprecate old-style locking in asyncio/locks.py Message-ID: <1512723580.6.0.213398074469.issue32253@psf.upfronthosting.co.za> New submission from Andrew Svetlov : Now constructions like await lock # "yield from lock" can be used as well try: ... finally: lock.release() and with (yield from lock): ... are supported. Let's deprecate them in favor of async with lock: ... ---------- components: asyncio messages: 307839 nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Deprecate old-style locking in asyncio/locks.py versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 04:00:55 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 08 Dec 2017 09:00:55 +0000 Subject: [issue32253] Deprecate old-style locking in asyncio/locks.py In-Reply-To: <1512723580.6.0.213398074469.issue32253@psf.upfronthosting.co.za> Message-ID: <1512723655.75.0.213398074469.issue32253@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- components: +Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 04:03:44 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 08 Dec 2017 09:03:44 +0000 Subject: [issue27645] Supporting native backup facility of SQLite In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za> Message-ID: <1512723824.65.0.213398074469.issue27645@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It seems to me that the code could be much simpler (and more bugfree) if support only a Connection instance as a target. It is easy to create a Connection instance in Python: with sqlite3.connect(filename) as dest: source.backup(dest) But this would save around 50 lines of complex C code. And I'm not sure this code is correct. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 04:34:26 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 08 Dec 2017 09:34:26 +0000 Subject: [issue32251] Add asyncio.BufferedProtocol In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za> Message-ID: <1512725666.32.0.213398074469.issue32251@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Numbers are great! Couple questions. 1. What happens if size of read data is greater than pre-allocated buffer? 2. Is flow control logic changed or not? If I understand correctly pause_reading() / resume_reading() continue to work as earlier. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 04:41:48 2017 From: report at bugs.python.org (Matthias Klose) Date: Fri, 08 Dec 2017 09:41:48 +0000 Subject: [issue32254] documentation builds (even local ones) refer to https://docs.python.org/ Message-ID: <1512726108.41.0.213398074469.issue32254@psf.upfronthosting.co.za> New submission from Matthias Klose : lintian (the Debian packaging checker) recently started flagging so-called "privacy-breach" issues: https://lintian.debian.org/maintainer/doko at debian.org.html#python2.7 python2.7-doc W privacy-breach-generic usr/share/doc/python2.7/html/about.html (https://docs.python.org/2/about.html) usr/share/doc/python2.7/html/bugs.html (https://docs.python.org/2/bugs.html) usr/share/doc/python2.7/html/c-api/abstract.html (https://docs.python.org/2/c-api/abstract.html) [...] and 500 more. that's because Doc/tools/templates/layout.html hardcodes an absolute URL and there is no configure way to change it. I don't think that local builds should point to the same single-point-of-failure URL, but use local references instead. ---------- components: Build messages: 307842 nosy: doko priority: normal severity: normal status: open title: documentation builds (even local ones) refer to https://docs.python.org/ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 04:42:16 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 08 Dec 2017 09:42:16 +0000 Subject: [issue32246] test_regrtest alters the execution environment on Android In-Reply-To: <1512662502.3.0.213398074469.issue32246@psf.upfronthosting.co.za> Message-ID: <1512726136.75.0.213398074469.issue32246@psf.upfronthosting.co.za> Xavier de Gaye added the comment: I agree that test_crashed() should be skipped on Android anyway and I will create a PR to skip the test. If I understand correctly, there may be another nasty bug that is revealed when test_regrstest fails with the environment altered: How is it possible that the new file that alters the environment be a test_python_* directory (see my initial post) when all the tests are run inside a TEMPDIR/test_python_* directory. The 'files' environment is checked within a TEMPDIR/test_python_* and not within TEMPDIR, no ? I found a new point that may help understand this problem: * On Android TEMPDIR is built from tempfile.gettempdir() that uses the TMPDIR environment variable which is set by Android to /data/local/tmp. The tests are run in /data/local/tmp/python [1], this is also the value of $SYS_EXEC_PREFIX and thus where are installed Python machine-specific binaries. * When TMPDIR is set to /data/local/tmp/python/tmp, which makes more sense here, test_regrstest is ok and does not change the environment. [1] This is the only location where a shell user may have both write and exec permissions, the Android applications have those permissions here too and in their own dedicated locations on /data/data. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 04:48:35 2017 From: report at bugs.python.org (Matthias Klose) Date: Fri, 08 Dec 2017 09:48:35 +0000 Subject: [issue32254] documentation builds (even local ones) refer to https://docs.python.org/ In-Reply-To: <1512726108.41.0.213398074469.issue32254@psf.upfronthosting.co.za> Message-ID: <1512726515.27.0.213398074469.issue32254@psf.upfronthosting.co.za> Matthias Klose added the comment: should *not* point to the same single-point-of-failure URL ---------- versions: +Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 05:01:27 2017 From: report at bugs.python.org (Nitish) Date: Fri, 08 Dec 2017 10:01:27 +0000 Subject: [issue22589] mimetypes uses image/x-ms-bmp as the type for bmp files In-Reply-To: <1412881216.57.0.175210358842.issue22589@psf.upfronthosting.co.za> Message-ID: <1512727287.34.0.213398074469.issue22589@psf.upfronthosting.co.za> Change by Nitish : ---------- keywords: +patch pull_requests: +4659 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 05:01:53 2017 From: report at bugs.python.org (Nitish) Date: Fri, 08 Dec 2017 10:01:53 +0000 Subject: [issue22589] mimetypes uses image/x-ms-bmp as the type for bmp files In-Reply-To: <1412881216.57.0.175210358842.issue22589@psf.upfronthosting.co.za> Message-ID: <1512727313.67.0.213398074469.issue22589@psf.upfronthosting.co.za> Change by Nitish : ---------- nosy: +nitishch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 05:46:27 2017 From: report at bugs.python.org (Thomas Kluyver) Date: Fri, 08 Dec 2017 10:46:27 +0000 Subject: [issue32247] shutil-copytree: Create dst folder only if it doesn't exist In-Reply-To: <1512680216.59.0.213398074469.issue32247@psf.upfronthosting.co.za> Message-ID: <1512729987.61.0.213398074469.issue32247@psf.upfronthosting.co.za> Thomas Kluyver added the comment: This is documented: > The destination directory, named by dst, must not already exist https://docs.python.org/3/library/shutil.html#shutil.copytree I guess that avoids complications that might arise from merging a directory. ---------- nosy: +takluyver _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 05:51:19 2017 From: report at bugs.python.org (Radostin) Date: Fri, 08 Dec 2017 10:51:19 +0000 Subject: [issue32247] shutil-copytree: Create dst folder only if it doesn't exist In-Reply-To: <1512680216.59.0.213398074469.issue32247@psf.upfronthosting.co.za> Message-ID: <1512730279.07.0.213398074469.issue32247@psf.upfronthosting.co.za> Change by Radostin : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 05:51:32 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 08 Dec 2017 10:51:32 +0000 Subject: [issue32251] Add asyncio.BufferedProtocol In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za> Message-ID: <1512730292.3.0.213398074469.issue32251@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I have another question: what happens if there is a partial read? For example, let's says I return a 1024-bytes buffer in get_buffer(), but recv_into() receives data in 512 chunks. Is it: 1. getbuffer() is called, returns 1024 bytes buffer 2. recv_into() receives 512 bytes, writes them in buf[0:512] 3. recv_into() receives another 512 bytes, writes them in buf[512:1024] or is it: 1. getbuffer() is called, returns 1024 bytes buffer 2. recv_into() receives 512 bytes, writes them in buf[0:512] 3. getbuffer() is called, returns another 1024 bytes buffer 4. recv_into() receives 512 bytes, writes them in newbuf[0:512] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 06:41:44 2017 From: report at bugs.python.org (Chirag Rathod) Date: Fri, 08 Dec 2017 11:41:44 +0000 Subject: [issue32035] Documentation of zipfile.ZipFile().writestr() fails to mention that 'data' may also be bytes In-Reply-To: <1510757660.91.0.213398074469.issue32035@psf.upfronthosting.co.za> Message-ID: <1512733304.74.0.213398074469.issue32035@psf.upfronthosting.co.za> Change by Chirag Rathod : ---------- pull_requests: +4660 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 07:42:23 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 08 Dec 2017 12:42:23 +0000 Subject: [issue29247] Document return value of epoll.poll In-Reply-To: <1484195034.62.0.718564451527.issue29247@psf.upfronthosting.co.za> Message-ID: <1512736943.59.0.213398074469.issue29247@psf.upfronthosting.co.za> Cheryl Sabella added the comment: Hi Berker, Are you interested in making a pull request for this patch? Thanks! ---------- nosy: +csabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 07:48:49 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 08 Dec 2017 12:48:49 +0000 Subject: [issue22589] mimetypes uses image/x-ms-bmp as the type for bmp files In-Reply-To: <1412881216.57.0.175210358842.issue22589@psf.upfronthosting.co.za> Message-ID: <1512737329.09.0.213398074469.issue22589@psf.upfronthosting.co.za> R. David Murray added the comment: New changeset ede157331b4f9e550334900b3b4de1c8590688de by R. David Murray (Nitish Chandra) in branch 'master': bpo-22589 Changed MIME type of .bmp to "image/bmp" (#4756) https://github.com/python/cpython/commit/ede157331b4f9e550334900b3b4de1c8590688de ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 07:51:43 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 08 Dec 2017 12:51:43 +0000 Subject: [issue22589] mimetypes uses image/x-ms-bmp as the type for bmp files In-Reply-To: <1412881216.57.0.175210358842.issue22589@psf.upfronthosting.co.za> Message-ID: <1512737503.87.0.213398074469.issue22589@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, nitishch. As I said, I'm not going to backport this unless someone advances an argument in favor that discusses the possible backward compatibility issue. (I'm not sure there are any significant ones, but someone needs to research it and present the results.) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 09:24:24 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 08 Dec 2017 14:24:24 +0000 Subject: [issue32249] Document handler.cancelled() In-Reply-To: <1512686845.02.0.213398074469.issue32249@psf.upfronthosting.co.za> Message-ID: <1512743064.41.0.213398074469.issue32249@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Fixed in master, sorry ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 09:43:54 2017 From: report at bugs.python.org (Licht Takeuchi) Date: Fri, 08 Dec 2017 14:43:54 +0000 Subject: [issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n' Message-ID: <1512744234.4.0.213398074469.issue32255@psf.upfronthosting.co.za> New submission from Licht Takeuchi : Inconsistent behavior while reading a single column CSV. I have the patch and waiting for the CLA response. # Case 1 ## Input ``` import csv fp = open('test.csv', 'w') w = csv.writer(fp) w.writerow(['']) w.writerow(['1']) fp.close() ``` ## Output ``` "" 1 ``` # Case 2 ## Input ``` import csv fp = open('test.csv', 'w') w = csv.writer(fp) w.writerow(['1']) w.writerow(['']) fp.close() ``` ## Output ``` 1 ``` ---------- components: IO messages: 307851 nosy: licht-t priority: normal severity: normal status: open title: csv.writer converts None to '""\n' when it is first line, otherwise '\n' type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 11:14:58 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 08 Dec 2017 16:14:58 +0000 Subject: [issue32205] test.pythoninfo does not print the cross-built sysconfig data In-Reply-To: <1512307690.33.0.213398074469.issue32205@psf.upfronthosting.co.za> Message-ID: <1512749698.02.0.213398074469.issue32205@psf.upfronthosting.co.za> Change by Xavier de Gaye : ---------- resolution: wont fix -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 11:20:17 2017 From: report at bugs.python.org (Vincas Dargis) Date: Fri, 08 Dec 2017 16:20:17 +0000 Subject: [issue18943] argparse: default args in mutually exclusive groups In-Reply-To: <1512584898.53.0.213398074469.issue18943@psf.upfronthosting.co.za> Message-ID: <6961dc72-81a4-a1f0-2dd0-0f2398be3c7a@gmail.com> Vincas Dargis added the comment: On 2017-12-06 20:28, paul j3 wrote: > The default value is used *if the flag is not provided at all.* > > "nargs='?'" provides a third option, assigning the 'const' value *if the flag is used without an argument*. This did a "click" in my head. It works now with `nargs='?'` and `const='MediaProfile000'` as expected, thanks! I am really sorry for the noise, due to misunderstanding while reading (skipping-throuhg?) Python documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 11:32:03 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 08 Dec 2017 16:32:03 +0000 Subject: [issue8722] Documentation for __getattr__ In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za> Message-ID: <1512750723.97.0.213398074469.issue8722@psf.upfronthosting.co.za> Cheryl Sabella added the comment: Terry, Thanks for clarifying with this example. I hadn't tried this when I was playing with the other example. I guess __getattribute__ might be defined by a class, but generally wouldn't be called directly, so the use of __getattr__ and __getattribute__ and the raising of AttributeError is more for an `attributeref` (https://docs.python.org/3/reference/expressions.html#attribute-references) usage? ---------- nosy: +csabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 11:52:14 2017 From: report at bugs.python.org (Dustin Spicuzza) Date: Fri, 08 Dec 2017 16:52:14 +0000 Subject: [issue29249] Pathlib glob ** bug In-Reply-To: <1484216394.04.0.57434547579.issue29249@psf.upfronthosting.co.za> Message-ID: <1512751934.31.0.213398074469.issue29249@psf.upfronthosting.co.za> Dustin Spicuzza added the comment: I just ran into this also. It seems like a very strange omission that match and glob don't support the same patterns (and I'm surprised that they don't share more code). ---------- nosy: +virtuald _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 11:54:37 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 08 Dec 2017 16:54:37 +0000 Subject: [issue32252] test_regrtest leaves a test_python_* directory in TEMPDIR In-Reply-To: <1512722953.36.0.213398074469.issue32252@psf.upfronthosting.co.za> Message-ID: <1512752077.42.0.213398074469.issue32252@psf.upfronthosting.co.za> STINNER Victor added the comment: > After running test_regrtest in the source tree on linux, the build/ subdirectory (i.e. test.libregrtest.main.TEMPDIR) contains a new test_python_* directory that contains a core file when the core file size is unlimited. Can you please explain how to reproduce the bug? (Which commands should I type?) What is your /proc/sys/kernel/core_pattern? On my Fedora 27, /proc/sys/kernel/core_pattern is "|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 12:26:04 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 08 Dec 2017 17:26:04 +0000 Subject: [issue32251] Add asyncio.BufferedProtocol In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za> Message-ID: <1512753964.2.0.213398074469.issue32251@psf.upfronthosting.co.za> Yury Selivanov added the comment: > 1. What happens if size of read data is greater than pre-allocated buffer? Let's say we have 2Kb of data in the socket's network buffer, and we only preallocated 0.5Kb in our buffer. We will the receive 0.5Kb in our buffer, 'Protocol.buffer_updated()' will be called with nbytes=512, and 1.5Kb of data will be left in the network buffer. So the loop will call get_buffer()/buffer_updated() again, and the cycle will continue until there's no data left. > 2. Is flow control logic changed or not? If I understand correctly pause_reading() / resume_reading() continue to work as earlier. Flow control will continue working absolutely the same for BufferedProtocols. > I have another question: what happens if there is a partial read? > For example, let's says I return a 1024-bytes buffer in get_buffer(), but recv_into() receives data in 512 chunks. Is it: It will be as follows: 1. Protocol.get_buffer() is called, returns 1024 bytes buffer 2. recv_into() receives 512 bytes, writes them in buf[0:512] 3. Protocol.buffer_updated() is called with nbytes=512 Now it's the responsibility of the Protocol to return a correct view over buffer the next time `get_buffer()` is called. The general idea is to: 1. allocate a big buffer 2. keep track of how much data we have in that buffer, let's say we have a 'length' integer for that. 3. when get_buffer() is called, return 'memoryview(big_buffer)[length:]' 4. when buffer_updated(nbytes) is called, do 'length += nbytes; parse_buffer_if_possible()' I've implemented precisely this approach here: https://gist.github.com/1st1/1c606e5b83ef0e9c41faf21564d75ad7#file-get_buffer_bench-py-L27-L43 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 12:31:28 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 08 Dec 2017 17:31:28 +0000 Subject: [issue32251] Add asyncio.BufferedProtocol In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za> Message-ID: <1512754288.68.0.213398074469.issue32251@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Do you think it's possible to fold BufferedProtocol into Protocol? i.e., either `get_buffer()` returns None (the default) and `data_received()` is called with a bytes object, or `get_buffer()` returns a writable buffer and `buffer_updated()` is called with the number of bytes received into the buffer. This would allow StreamReader to implement readinto(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 12:32:00 2017 From: report at bugs.python.org (jarb) Date: Fri, 08 Dec 2017 17:32:00 +0000 Subject: [issue26340] modal dialog with transient method; parent window fails to iconify In-Reply-To: <1455210342.9.0.230352859774.issue26340@psf.upfronthosting.co.za> Message-ID: <1512754320.16.0.213398074469.issue26340@psf.upfronthosting.co.za> jarb added the comment: I am having the exactly same issue. Was this issue resolved for Windows 10? This does not happen in Linux. Any workaround for Windows 10? ---------- nosy: +jarb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 12:34:45 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 08 Dec 2017 17:34:45 +0000 Subject: [issue32251] Add asyncio.BufferedProtocol In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za> Message-ID: <1512754485.52.0.213398074469.issue32251@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Do you think it's possible to fold BufferedProtocol into Protocol? It would be a backwards incompatible change :( Coincidentally, there might be protocols that already implement 'get_buffer()' and 'buffer_updated()' methods that do something completely different. > This would allow StreamReader to implement readinto(). We can easily refactor StreamReader to use 'BufferedProtocol'. Methods like 'readexactly()' would benefit from that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 12:45:26 2017 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 08 Dec 2017 17:45:26 +0000 Subject: [issue32212] few discrepancy between source and docs in logging In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za> Message-ID: <1512755126.14.0.213398074469.issue32212@psf.upfronthosting.co.za> Change by ?ric Araujo : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 12:53:48 2017 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 08 Dec 2017 17:53:48 +0000 Subject: [issue32223] distutils doesn't correctly read UTF-8 content from config files In-Reply-To: <1512492386.04.0.213398074469.issue32223@psf.upfronthosting.co.za> Message-ID: <1512755628.37.0.213398074469.issue32223@psf.upfronthosting.co.za> ?ric Araujo added the comment: `metadata` in setup.cfg is not supported directly by distutils. Can you provide a setup.py script that shows the problem without setuptools? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 12:57:44 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 08 Dec 2017 17:57:44 +0000 Subject: [issue32251] Add asyncio.BufferedProtocol In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za> Message-ID: <1512755864.34.0.213398074469.issue32251@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New protocol may speed up not only `reader.readexactly()`. Every `reader.feed_data()` appends a new chunk to existing buffer. We can try to read into unused tail of the buffer instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 13:05:20 2017 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 08 Dec 2017 18:05:20 +0000 Subject: [issue32251] Add asyncio.BufferedProtocol In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za> Message-ID: <1512756320.91.0.213398074469.issue32251@psf.upfronthosting.co.za> Change by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 13:17:21 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Fri, 08 Dec 2017 18:17:21 +0000 Subject: [issue32216] Document PEP 557 Data Classes In-Reply-To: <1512439511.23.0.213398074469.issue32216@psf.upfronthosting.co.za> Message-ID: <1512757041.85.0.213398074469.issue32216@psf.upfronthosting.co.za> Change by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 13:23:45 2017 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 08 Dec 2017 18:23:45 +0000 Subject: [issue32251] Add asyncio.BufferedProtocol In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za> Message-ID: <1512757425.61.0.213398074469.issue32251@psf.upfronthosting.co.za> ?ukasz Langa added the comment: +1 on the idea, I would use this. ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 13:50:14 2017 From: report at bugs.python.org (Nitish) Date: Fri, 08 Dec 2017 18:50:14 +0000 Subject: [issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n' In-Reply-To: <1512744234.4.0.213398074469.issue32255@psf.upfronthosting.co.za> Message-ID: <1512759014.1.0.213398074469.issue32255@psf.upfronthosting.co.za> Change by Nitish : ---------- nosy: +nitishch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 13:55:53 2017 From: report at bugs.python.org (Nitish) Date: Fri, 08 Dec 2017 18:55:53 +0000 Subject: [issue26414] os.defpath too permissive In-Reply-To: <1456181417.61.0.91952600054.issue26414@psf.upfronthosting.co.za> Message-ID: <1512759353.07.0.213398074469.issue26414@psf.upfronthosting.co.za> Change by Nitish : ---------- nosy: +nitishch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 13:56:47 2017 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 08 Dec 2017 18:56:47 +0000 Subject: [issue26414] os.defpath too permissive In-Reply-To: <1456181417.61.0.91952600054.issue26414@psf.upfronthosting.co.za> Message-ID: <1512759407.19.0.213398074469.issue26414@psf.upfronthosting.co.za> Change by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 14:05:37 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Fri, 08 Dec 2017 19:05:37 +0000 Subject: [issue15045] Make textwrap.dedent() consistent with str.splitlines(True) and str.strip() In-Reply-To: <1339421358.2.0.611530152115.issue15045@psf.upfronthosting.co.za> Message-ID: <1512759937.01.0.213398074469.issue15045@psf.upfronthosting.co.za> Sanyam Khurana added the comment: Ezra, can you please convert your patch to a Pull Request on Github? ---------- nosy: +CuriousLearner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 14:23:12 2017 From: report at bugs.python.org (=?utf-8?q?Micha=C5=82?=) Date: Fri, 08 Dec 2017 19:23:12 +0000 Subject: [issue16516] argparse types (and actions) must be hashable In-Reply-To: <1353468507.9.0.0965555550975.issue16516@psf.upfronthosting.co.za> Message-ID: <1512760992.89.0.213398074469.issue16516@psf.upfronthosting.co.za> Micha? added the comment: I've got confused with the "TypeError: unhashable type: 'dict'" error creating a choose-from-dictionary argument in Python 3.6. I used lambda as a workaround, but IMO it would be great to have this patch merged. ---------- nosy: +krassowski versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 14:25:24 2017 From: report at bugs.python.org (Jason R. Coombs) Date: Fri, 08 Dec 2017 19:25:24 +0000 Subject: [issue11594] 2to3 does not preserve line endings In-Reply-To: <1300465648.02.0.83291128633.issue11594@psf.upfronthosting.co.za> Message-ID: <1512761124.13.0.213398074469.issue11594@psf.upfronthosting.co.za> Jason R. Coombs added the comment: This issue affected me today. I'm editing a codebase that has mixed line endings in different files. I'd like to patch for Python 3 support without changing line endings. Even invoking a single fixer (print), the line endings mutate. Since I'm running on macOS, the files with CRLF get LF line endings. Answers [in this question](https://stackoverflow.com/questions/39028517/2to3-how-to-keep-newline-characters-from-input-file) suggest the mutation can be suppressed by altering the _to_system_newlines function, but the proposed fix has no effect on the Python 3.6 version of this routine. I thought I'd encountered this issue before, but I realized after searching that I was thinking of issue10639, which may present a model for retaining the newlines when refactoring the code. I found I was able to work around the issue by putting lib2to3-clean.py in my current directory: import lib2to3.refactor import runpy import functools if __name__ == '__main__': lib2to3.refactor._open_with_encoding = functools.partial(open, newline='') runpy.run_module('lib2to3') And invoking `python -m lib2to3-clean` instead of `-m lib2to3`. The addition of newline='' follows the [guidance in the docs](https://docs.python.org/release/3.2/library/functions.html#open) on how to avoid mutating newlines. I've released this functionality in [jaraco.develop 4.0](https://pypi.org/project/jaraco.develop) so others can readily invoke it with `rwt jaraco.develop -- -m jaraco.develop.lib2to3`. ---------- nosy: +jason.coombs versions: +Python 3.6 -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 14:40:12 2017 From: report at bugs.python.org (Dustin Spicuzza) Date: Fri, 08 Dec 2017 19:40:12 +0000 Subject: [issue29249] Pathlib glob ** bug In-Reply-To: <1484216394.04.0.57434547579.issue29249@psf.upfronthosting.co.za> Message-ID: <1512762012.08.0.213398074469.issue29249@psf.upfronthosting.co.za> Dustin Spicuzza added the comment: Because of backwards compatibility (despite a statement saying it's not guaranteed for pathlib), I think the best approach would be to create a 'globmatch' function for PurePath instead of modifying the match function, and document that the match function does a different kind of matching. This isn't a patch for cpython per se (ironically, don't have time for that this month...), but here's a MIT-licensed gist that patches pathlib2 and adds a globmatch function to it, plus associated tests extracted from pathlib2 and my own ** related tests. Works for me, feel free to do with it as you wish. https://gist.github.com/virtuald/dd0373bf3f26ec0730adf1da0fb929bb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 14:40:42 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 08 Dec 2017 19:40:42 +0000 Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7 In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za> Message-ID: <1512762042.86.0.213398074469.issue32248@psf.upfronthosting.co.za> Change by Gregory P. Smith : ---------- nosy: +gregory.p.smith, twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 15:09:36 2017 From: report at bugs.python.org (Alberto Galera) Date: Fri, 08 Dec 2017 20:09:36 +0000 Subject: [issue28718] '*' matches entire path in fnmatch In-Reply-To: <1479327127.15.0.931047394142.issue28718@psf.upfronthosting.co.za> Message-ID: <1512763776.44.0.213398074469.issue28718@psf.upfronthosting.co.za> Alberto Galera added the comment: I see that they have commented on the lib that I made a few years ago (python-wildcard). The reason for the creation of that little fork started in this issue: https://bugs.python.org/issue25734 ---------- nosy: +Alberto Galera _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 15:33:27 2017 From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=) Date: Fri, 08 Dec 2017 20:33:27 +0000 Subject: [issue30657] [security] CVE-2017-1000158: Unsafe arithmetic in PyString_DecodeEscape In-Reply-To: <1497368129.36.0.20181989843.issue30657@psf.upfronthosting.co.za> Message-ID: <1512765207.74.0.213398074469.issue30657@psf.upfronthosting.co.za> Change by Miro Hron?ok : ---------- pull_requests: +4661 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 16:23:14 2017 From: report at bugs.python.org (Jakub Wilk) Date: Fri, 08 Dec 2017 21:23:14 +0000 Subject: [issue13420] newer() function in dep_util.py discard changes in the same second In-Reply-To: <1321529038.98.0.0841934486822.issue13420@psf.upfronthosting.co.za> Message-ID: <1512768194.31.0.213398074469.issue13420@psf.upfronthosting.co.za> Change by Jakub Wilk : ---------- nosy: -jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 16:34:19 2017 From: report at bugs.python.org (Larry Hastings) Date: Fri, 08 Dec 2017 21:34:19 +0000 Subject: [issue30657] [security] CVE-2017-1000158: Unsafe arithmetic in PyString_DecodeEscape In-Reply-To: <1497368129.36.0.20181989843.issue30657@psf.upfronthosting.co.za> Message-ID: <1512768859.94.0.213398074469.issue30657@psf.upfronthosting.co.za> Larry Hastings added the comment: New changeset fd8614c5c5466a14a945db5b059c10c0fb8f76d9 by larryhastings (Miro Hron?ok) in branch '3.5': bpo-30657: Fix CVE-2017-1000158 (#4664) https://github.com/python/cpython/commit/fd8614c5c5466a14a945db5b059c10c0fb8f76d9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 16:34:46 2017 From: report at bugs.python.org (Larry Hastings) Date: Fri, 08 Dec 2017 21:34:46 +0000 Subject: [issue30657] [security] CVE-2017-1000158: Unsafe arithmetic in PyString_DecodeEscape In-Reply-To: <1497368129.36.0.20181989843.issue30657@psf.upfronthosting.co.za> Message-ID: <1512768886.97.0.213398074469.issue30657@psf.upfronthosting.co.za> Larry Hastings added the comment: New changeset 6c004b40f9d51872d848981ef1a18bb08c2dfc42 by larryhastings (Miro Hron?ok) in branch '3.4': bpo-30657: Fix CVE-2017-1000158 (#4758) https://github.com/python/cpython/commit/6c004b40f9d51872d848981ef1a18bb08c2dfc42 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 16:36:52 2017 From: report at bugs.python.org (Larry Hastings) Date: Fri, 08 Dec 2017 21:36:52 +0000 Subject: [issue30657] [security] CVE-2017-1000158: Unsafe arithmetic in PyString_DecodeEscape In-Reply-To: <1497368129.36.0.20181989843.issue30657@psf.upfronthosting.co.za> Message-ID: <1512769012.04.0.213398074469.issue30657@psf.upfronthosting.co.za> Larry Hastings added the comment: Merged into 3.4 and 3.5. Thanks for the patches! Since I see 2.7 has already had the fix committed, and these are the only three versions affected, I'm marking as closed / resolved / fixed. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 16:46:31 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 08 Dec 2017 21:46:31 +0000 Subject: [issue32209] Crash in set_traverse Within the Garbage Collector's collect_generations() In-Reply-To: <1512358631.67.0.213398074469.issue32209@psf.upfronthosting.co.za> Message-ID: <1512769591.37.0.213398074469.issue32209@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I'm not sure what I can do to reproduce this because I don't even know what line of code my program was running before it segfaulted. To do that you could enable the faulthandler module: https://docs.python.org/3/library/faulthandler.html Also, it would be nice if you had a simple reproducer to share with us, though it may be difficult given the description you gave of your workload. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 17:14:22 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 08 Dec 2017 22:14:22 +0000 Subject: [issue29883] asyncio: Windows Proactor Event Loop UDP Support In-Reply-To: <1490210881.18.0.553215827239.issue29883@psf.upfronthosting.co.za> Message-ID: <1512771262.22.0.213398074469.issue29883@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 17:23:52 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 08 Dec 2017 22:23:52 +0000 Subject: [issue32193] Convert asyncio to async/await In-Reply-To: <1512121472.71.0.213398074469.issue32193@psf.upfronthosting.co.za> Message-ID: <1512771832.36.0.213398074469.issue32193@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset 5f841b553814969220b096a2b4f959b7f6fcbaf6 by Andrew Svetlov in branch 'master': bpo-32193: Convert asyncio to async/await usage (#4753) https://github.com/python/cpython/commit/5f841b553814969220b096a2b4f959b7f6fcbaf6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 17:25:13 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 08 Dec 2017 22:25:13 +0000 Subject: [issue32193] Convert asyncio to async/await In-Reply-To: <1512121472.71.0.213398074469.issue32193@psf.upfronthosting.co.za> Message-ID: <1512771913.92.0.213398074469.issue32193@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 17:48:39 2017 From: report at bugs.python.org (Larry Hastings) Date: Fri, 08 Dec 2017 22:48:39 +0000 Subject: [issue29572] Upgrade installers to OpenSSL 1.0.2k In-Reply-To: <1487181972.09.0.437715679754.issue29572@psf.upfronthosting.co.za> Message-ID: <1512773319.82.0.213398074469.issue29572@psf.upfronthosting.co.za> Larry Hastings added the comment: New changeset 092db6c3cb049052fbfca15efc85ad68093676e7 by larryhastings (Victor Stinner) in branch '3.4': bpo-29572: Update Windows build to OpenSSL 1.0.2k (GH-443) (#3445) https://github.com/python/cpython/commit/092db6c3cb049052fbfca15efc85ad68093676e7 ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 20:25:20 2017 From: report at bugs.python.org (Vladimir Semenenko) Date: Sat, 09 Dec 2017 01:25:20 +0000 Subject: [issue26340] modal dialog with transient method; parent window fails to iconify In-Reply-To: <1512754320.16.0.213398074469.issue26340@psf.upfronthosting.co.za> Message-ID: Vladimir Semenenko added the comment: After they marked the issue as "resolved" earlier this year I tested a subsequent 3.x release in Windows 7 and Vista (I don't have 10). The issue was still there. I don't have a workaround. I am forced to stay with 2.7.3. On Dec 8, 2017 9:32 AM, "jarb" wrote: jarb added the comment: I am having the exactly same issue. Was this issue resolved for Windows 10? This does not happen in Linux. Any workaround for Windows 10? ---------- nosy: +jarb _______________________________________ Python tracker _______________________________________ ---------- nosy: +Vladimir Semenenko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 20:34:05 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 09 Dec 2017 01:34:05 +0000 Subject: [issue20285] Improve object.__doc__ and help(object) output In-Reply-To: <1389920351.63.0.12805701843.issue20285@psf.upfronthosting.co.za> Message-ID: <1512783245.39.0.213398074469.issue20285@psf.upfronthosting.co.za> Change by Cheryl Sabella : ---------- keywords: +patch pull_requests: +4662 stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 20:35:14 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 09 Dec 2017 01:35:14 +0000 Subject: [issue20285] Improve object.__doc__ and help(object) output In-Reply-To: <1389920351.63.0.12805701843.issue20285@psf.upfronthosting.co.za> Message-ID: <1512783314.09.0.213398074469.issue20285@psf.upfronthosting.co.za> Change by Cheryl Sabella : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python versions: +Python 3.7 -Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 20:35:58 2017 From: report at bugs.python.org (Alexey Izbyshev) Date: Sat, 09 Dec 2017 01:35:58 +0000 Subject: [issue32256] Make patchcheck.py work for out-of-tree builds Message-ID: <1512783358.62.0.213398074469.issue32256@psf.upfronthosting.co.za> New submission from Alexey Izbyshev : Despite some steps made in issue 9860 make patchcheck still doesn't work for out-of-tree builds because it runs git and hg in the current directory instead of the source directory (msg169465). ---------- messages: 307875 nosy: izbyshev priority: normal severity: normal status: open title: Make patchcheck.py work for out-of-tree builds type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 20:49:59 2017 From: report at bugs.python.org (Alexey Izbyshev) Date: Sat, 09 Dec 2017 01:49:59 +0000 Subject: [issue32256] Make patchcheck.py work for out-of-tree builds In-Reply-To: <1512783358.62.0.213398074469.issue32256@psf.upfronthosting.co.za> Message-ID: <1512784199.24.0.213398074469.issue32256@psf.upfronthosting.co.za> Change by Alexey Izbyshev : ---------- keywords: +patch pull_requests: +4663 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 21:27:28 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Dec 2017 02:27:28 +0000 Subject: [issue8722] Documentation for __getattr__ In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za> Message-ID: <1512786448.95.0.213398074469.issue8722@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Before testing, let alone documenting, the status quo, I would like to be sure that suppressing the exception is truly the intended behavior. Is there a way to get an annotated listing from git (given which patch, and therefore which person, is responsible for each line)? I will try asking on pydev. Calling __getattr__ on property failure is a behavior of __getattribute__, not of the property, and I would expect object.__getattribute__ to be tested wherever object is, but I have not found such tests. If we do add a test, the best model in test_desc.py looks like `def test_module_subclasses(self):`. The test class would only need __getattr__ and the faulty property. class Foo(object): def __getattr__(self, name): print(f'Getattr {name}') return True @property def bing(self): print('Property bing') raise AttributeError("blarg") f = Foo() print(f.bing) #prints (which would be the log list in a test) Property bing Getattr bing True ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 21:29:44 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Dec 2017 02:29:44 +0000 Subject: [issue8722] Documentation for __getattr__ In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za> Message-ID: <1512786584.6.0.213398074469.issue8722@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The behavior and doc for __setattr__ and __delattr__ should also be checked. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 22:11:24 2017 From: report at bugs.python.org (Martin Panter) Date: Sat, 09 Dec 2017 03:11:24 +0000 Subject: [issue28185] Tabs in C source code In-Reply-To: <1474076341.84.0.766307725903.issue28185@psf.upfronthosting.co.za> Message-ID: <1512789084.39.0.213398074469.issue28185@psf.upfronthosting.co.za> Martin Panter added the comment: Similar changes were made in Issue 32150 and PR 3892 (tabs) and Mercurial revision 98d1788c905c (trailing space and indentation). All the other tabs in these patches appear to have been removed with other work: #29524, #31891, #30747, #31373, PR 4275, #25658, #27867, #30406, #31370, #30070, #29585, #31338, PR 1723, #30279. ---------- resolution: -> out of date stage: -> resolved status: open -> closed superseder: -> Expand tabs to spaces in C files _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 8 22:47:52 2017 From: report at bugs.python.org (Martin Panter) Date: Sat, 09 Dec 2017 03:47:52 +0000 Subject: [issue32247] shutil-copytree: Create dst folder only if it doesn't exist In-Reply-To: <1512680216.59.0.213398074469.issue32247@psf.upfronthosting.co.za> Message-ID: <1512791272.44.0.213398074469.issue32247@psf.upfronthosting.co.za> Change by Martin Panter : ---------- superseder: -> add exist_ok to shutil.copytree _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 01:38:23 2017 From: report at bugs.python.org (Qichao Chu) Date: Sat, 09 Dec 2017 06:38:23 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext Message-ID: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> New submission from Qichao Chu : Adding a new method in SSLContext so that we can disable renegotiation easier. This resolves CVE-2009-3555 and attack demoed by thc-ssl-dos ---------- assignee: christian.heimes components: SSL messages: 307879 nosy: christian.heimes, chuq priority: normal severity: normal status: open title: Support Disabling Renegotiation for SSLContext type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 01:57:57 2017 From: report at bugs.python.org (Berker Peksag) Date: Sat, 09 Dec 2017 06:57:57 +0000 Subject: [issue32237] test_xml_etree leaked [1, 1, 1] references, sum=3 In-Reply-To: <1512604950.09.0.213398074469.issue32237@psf.upfronthosting.co.za> Message-ID: <1512802677.76.0.213398074469.issue32237@psf.upfronthosting.co.za> Berker Peksag added the comment: I can confirm that Neil's PR (11cc289490b7b275fc0a033e2b376a8d4c780d9b) fixed the regression: $ ./python -m test -R 3:3 test_xml_etree Run tests sequentially 0:00:00 load avg: 0.66 [1/1] test_xml_etree beginning 6 repetitions 123456 ...... 1 test OK. Total duration: 4 sec Tests result: SUCCESS test_ensurepip, test_hashlib and test_importlib passed too. Closing this one as fixed. Thanks! ---------- components: +Tests nosy: +berker.peksag resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 02:02:12 2017 From: report at bugs.python.org (Qichao Chu) Date: Sat, 09 Dec 2017 07:02:12 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512802932.01.0.213398074469.issue32257@psf.upfronthosting.co.za> Change by Qichao Chu : ---------- keywords: +patch pull_requests: +4664 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 02:07:35 2017 From: report at bugs.python.org (Berker Peksag) Date: Sat, 09 Dec 2017 07:07:35 +0000 Subject: [issue32245] OSError: raw write() returned invalid length on latest Win 10 Consoles In-Reply-To: <1512660082.17.0.213398074469.issue32245@psf.upfronthosting.co.za> Message-ID: <1512803255.45.0.213398074469.issue32245@psf.upfronthosting.co.za> Change by Berker Peksag : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 02:13:48 2017 From: report at bugs.python.org (Berker Peksag) Date: Sat, 09 Dec 2017 07:13:48 +0000 Subject: [issue32208] Improve semaphore documentation In-Reply-To: <1512357480.91.0.213398074469.issue32208@psf.upfronthosting.co.za> Message-ID: <1512803628.65.0.213398074469.issue32208@psf.upfronthosting.co.za> Berker Peksag added the comment: According to the discussion at https://github.com/python/cpython/pull/4709#issuecomment-350055732 it was decided to not backport this to 2.7. Closing this as 'fixed'. Thank you, all! ---------- nosy: +berker.peksag resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 02:16:29 2017 From: report at bugs.python.org (Qichao Chu) Date: Sat, 09 Dec 2017 07:16:29 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512803789.61.0.213398074469.issue32257@psf.upfronthosting.co.za> Change by Qichao Chu : ---------- pull_requests: +4665 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 02:16:34 2017 From: report at bugs.python.org (Berker Peksag) Date: Sat, 09 Dec 2017 07:16:34 +0000 Subject: [issue32186] io.FileIO hang all threads if fstat blocks on inaccessible NFS server In-Reply-To: <1512066205.79.0.213398074469.issue32186@psf.upfronthosting.co.za> Message-ID: <1512803794.91.0.213398074469.issue32186@psf.upfronthosting.co.za> Berker Peksag added the comment: This has been fixed in all active branches (2.7, 3.6 and master) so I think we can close it as 'fixed'. Thanks, Nir! ---------- nosy: +berker.peksag resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 02:24:21 2017 From: report at bugs.python.org (Qichao Chu) Date: Sat, 09 Dec 2017 07:24:21 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512804261.25.0.213398074469.issue32257@psf.upfronthosting.co.za> Change by Qichao Chu : ---------- pull_requests: +4666 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 02:25:27 2017 From: report at bugs.python.org (Qichao Chu) Date: Sat, 09 Dec 2017 07:25:27 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512804327.83.0.213398074469.issue32257@psf.upfronthosting.co.za> Change by Qichao Chu : ---------- pull_requests: -4664 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 02:25:43 2017 From: report at bugs.python.org (Qichao Chu) Date: Sat, 09 Dec 2017 07:25:43 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512804343.14.0.213398074469.issue32257@psf.upfronthosting.co.za> Change by Qichao Chu : ---------- pull_requests: -4665 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 03:27:30 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 09 Dec 2017 08:27:30 +0000 Subject: [issue32186] io.FileIO hang all threads if fstat blocks on inaccessible NFS server In-Reply-To: <1512803794.91.0.213398074469.issue32186@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: (Oops, closing was my intent of my previous comment, but I forgot it, thanks Berker.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 04:06:59 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 09 Dec 2017 09:06:59 +0000 Subject: [issue31650] implement PEP 552 In-Reply-To: <1506801596.1.0.213398074469.issue31650@psf.upfronthosting.co.za> Message-ID: <1512810419.66.0.213398074469.issue31650@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: While we are here, can other changes be made? 1. Increase the size of the constant part of the signature. Currently it is only 2 bytes (3rd and 4th bytes are b'\r\n') and it is hard to use them in tools like `file`. 2. Split the magic number on two parts. The first part encodes backward-incompatible changes and can be updated only in new feature releases. The second part encodes backward compatible changes and can be changed in bugfix releases. 3. Maybe even include the minimal Python version? This would simplify the launcher which needs to map a magic number to Python version. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 04:07:59 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 09 Dec 2017 09:07:59 +0000 Subject: [issue32252] test_regrtest leaves a test_python_* directory in TEMPDIR In-Reply-To: <1512722953.36.0.213398074469.issue32252@psf.upfronthosting.co.za> Message-ID: <1512810479.69.0.213398074469.issue32252@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > Can you please explain how to reproduce the bug? (Which commands should I type?) ./python -m test test_regrtest > What is your /proc/sys/kernel/core_pattern? $ cat /proc/sys/kernel/core_pattern core-%e.%s $ ulimit -c unlimited FWIW on archlinux (my platform) coredumps are handled by systemd and to enable coredumps the file /etc/sysctl.d/50-coredump.conf has to be updated to contain: kernel.core_pattern=core-%e.%s ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 04:14:32 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 09 Dec 2017 09:14:32 +0000 Subject: [issue32253] Deprecate old-style locking in asyncio/locks.py In-Reply-To: <1512723580.6.0.213398074469.issue32253@psf.upfronthosting.co.za> Message-ID: <1512810872.71.0.213398074469.issue32253@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- keywords: +patch pull_requests: +4667 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 04:30:13 2017 From: report at bugs.python.org (Berker Peksag) Date: Sat, 09 Dec 2017 09:30:13 +0000 Subject: [issue8722] Documentation for __getattr__ In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za> Message-ID: <1512811813.74.0.213398074469.issue8722@psf.upfronthosting.co.za> Change by Berker Peksag : ---------- keywords: +patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 04:30:52 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 09 Dec 2017 09:30:52 +0000 Subject: [issue32252] test_regrtest leaves a test_python_* directory in TEMPDIR In-Reply-To: <1512722953.36.0.213398074469.issue32252@psf.upfronthosting.co.za> Message-ID: <1512811852.35.0.213398074469.issue32252@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Oh it seems your Fedora 27 also uses systemd and uses the same configuration as archlinux, see https://wiki.archlinux.org/index.php/Core_dump. In that case according to this wiki your core dumps go to /var/lib/systemd/coredump and this may explain the different behaviors between your system and mine. My setup (updating the file /etc/sysctl.d/50-coredump.conf) was the documented archlinux practice 4 years ago when systemd used to store the coredumps in log files (very annoying). This setup is still working although it is not documented in this wiki (maybe somewhere else). FWIW I have kept the notes made when configuring archlinux at that time, they are: disable core dumps managed by systemd-coredumpctl(1) - see also man pages for sysctl.d and sysctl /etc/sysctl.d/50-coredump.conf # same file name as in /usr/lib/sysctl.d/ kernel.core_pattern=core-%e.%s echo "core-%e.%s" > /proc/sys/kernel/core_pattern # or reboot # per user ulimit -c unlimited ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 04:37:24 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 09 Dec 2017 09:37:24 +0000 Subject: [issue32253] Deprecate old-style locking in asyncio/locks.py In-Reply-To: <1512723580.6.0.213398074469.issue32253@psf.upfronthosting.co.za> Message-ID: <1512812244.51.0.213398074469.issue32253@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This can make harder writing portable code that works in 2.7, 3.4 and 3.7. What is the benefit of the deprecation? Are there inevitable design or implementation errors in these constructions? Or getting rid of them can significantly simplify the implementation? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 04:48:55 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 09 Dec 2017 09:48:55 +0000 Subject: [issue32253] Deprecate old-style locking in asyncio/locks.py In-Reply-To: <1512723580.6.0.213398074469.issue32253@psf.upfronthosting.co.za> Message-ID: <1512812935.73.0.213398074469.issue32253@psf.upfronthosting.co.za> Andrew Svetlov added the comment: 1. asyncio is not supported by 2.7 anyway 2. with (yield from lock) is based on very non-obvious tricks: a) lock.__enter__ is forbidden and raises RuntimeError b) actually lock.__iter__ is called for lock acquiring *before* calling `with` c) the object returned from __iter__ is a context manager with __enter__/__exit__ methods 3. asyncio is converted to async/await syntax by https://bugs.python.org/issue32193 (old `yield from` style is fully supported still). 4. the deprecation was proposed by Yury Selivanov in https://github.com/python/cpython/pull/4753#discussion_r155658200 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 05:06:15 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 09 Dec 2017 10:06:15 +0000 Subject: [issue32258] Rewrite ayncio docs to use async/await syntax Message-ID: <1512813975.64.0.213398074469.issue32258@psf.upfronthosting.co.za> New submission from Andrew Svetlov : https://bugs.python.org/issue32193 switched asyncio implementation to async/await syntax. We need to update documentation as well. ---------- assignee: docs at python components: Documentation, asyncio messages: 307889 nosy: asvetlov, docs at python, yselivanov priority: normal severity: normal status: open title: Rewrite ayncio docs to use async/await syntax versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 05:30:26 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 09 Dec 2017 10:30:26 +0000 Subject: [issue32258] Rewrite asyncio docs to use async/await syntax In-Reply-To: <1512813975.64.0.213398074469.issue32258@psf.upfronthosting.co.za> Message-ID: <1512815426.33.0.213398074469.issue32258@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- title: Rewrite ayncio docs to use async/await syntax -> Rewrite asyncio docs to use async/await syntax _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 05:54:31 2017 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 09 Dec 2017 10:54:31 +0000 Subject: [issue32212] few discrepancy between source and docs in logging In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za> Message-ID: <1512816871.92.0.213398074469.issue32212@psf.upfronthosting.co.za> Change by Vinay Sajip : ---------- keywords: +patch pull_requests: +4668 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 06:07:28 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 09 Dec 2017 11:07:28 +0000 Subject: [issue32250] Add loop.current_task() and loop.all_tasks() methods In-Reply-To: <1512687842.07.0.213398074469.issue32250@psf.upfronthosting.co.za> Message-ID: <1512817648.92.0.213398074469.issue32250@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- keywords: +patch pull_requests: +4669 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 06:09:06 2017 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 09 Dec 2017 11:09:06 +0000 Subject: [issue32212] few discrepancy between source and docs in logging In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za> Message-ID: <1512817746.93.0.213398074469.issue32212@psf.upfronthosting.co.za> Vinay Sajip added the comment: New changeset a9f8df646aac7fc94ced0aefd1ed2c8566d14d10 by Vinay Sajip in branch 'master': bpo-32212: Updated logging documentation to make parameter names more consistent with source. (GH-4765) https://github.com/python/cpython/commit/a9f8df646aac7fc94ced0aefd1ed2c8566d14d10 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 06:57:28 2017 From: report at bugs.python.org (Christian Heimes) Date: Sat, 09 Dec 2017 11:57:28 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512820648.75.0.213398074469.issue32257@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks for your patch, a few comments We generally don't have special functions to set flags. SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS is an OpenSSL < 1.1.0 option. OpenSSL 1.1.0 still defines the flag but no longer uses it. With your patch, the Python function would fail with a NameError. I don't think that self.options is the right way to set that flag. The option attribute manipulates SSL_CTX->options, which affects SSL->options. The flag has to be set on SSL->s3->flags. Your patch is missing documentation update and tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 07:06:11 2017 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 09 Dec 2017 12:06:11 +0000 Subject: [issue32212] few discrepancy between source and docs in logging In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za> Message-ID: <1512821171.24.0.213398074469.issue32212@psf.upfronthosting.co.za> Change by Vinay Sajip : ---------- pull_requests: +4670 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 07:10:32 2017 From: report at bugs.python.org (Camion) Date: Sat, 09 Dec 2017 12:10:32 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected Message-ID: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> New submission from Camion : I'm new with Python and I've been blocked for day on a "TypeError: 'Fraction' object is not iterable" error message, while the problem turned out to be completely different. I don't even know to what programming case this message would have been the right interpretation, but in this situation, it was completely wrong and I believe it can cause much loss of time for inexperienced python programmer (at least, I believe it should document alternative causes) Here is a sample code to show how misleading it can be (It's a program to compute pi with fractions) from fractions import Fraction def order(x): r, old_r, n, old_n = 2, 1, 1, 0 while (x>=r): r, old_r, n, old_n = r*r, r, 2*n, n return order(x >> old_n) + old_n if old_n > 0 else 0 def terms(m, n, i): return Fraction(4 * m, n**(2*i+1) * (2*i+1)) def terms_generator(exp_prec): ws = [ [terms(parm[1], parm[2], 0), 0] + list(parm) for parm in ((1, 44, 57), (1, 7, 239), (-1, 12, 682), (1, 24, 12943))] digits = 0 while digits _______________________________________ From report at bugs.python.org Sat Dec 9 07:20:46 2017 From: report at bugs.python.org (Christian Heimes) Date: Sat, 09 Dec 2017 12:20:46 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512822046.54.0.213398074469.issue32257@psf.upfronthosting.co.za> Christian Heimes added the comment: I don't think your PR is required. The issue has been addressed in OpenSSL 0.9.8m over 7 years ago, https://access.redhat.com/security/cve/cve-2009-3555. >From https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html > OpenSSL always attempts to use secure renegotiation as described in RFC5746. This counters the prefix attack described in CVE-2009-3555 and elsewhere. OpenSSL changelog Changes between 0.9.8l and 0.9.8m [25 Feb 2010] *) Implement RFC5746. Re-enable renegotiation but require the extension as needed. Unfortunately, SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION turns out to be a bad idea. It has been replaced by SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION which can be set with SSL_CTX_set_options(). This is really not recommended unless you know what you are doing. [Eric Rescorla , Ben Laurie, Steve Henson] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 07:25:16 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 09 Dec 2017 12:25:16 +0000 Subject: [issue8722] Documentation for __getattr__ In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za> Message-ID: <1512822316.32.0.213398074469.issue8722@psf.upfronthosting.co.za> Cheryl Sabella added the comment: >> Is there a way to get an annotated listing from git (given which patch, and therefore which person, is responsible for each line)? Which source did you want to look at? In github, if you go into any source, you can click on a line and it gives an option for 'git blame'. That shows the last commit change for each line. You can then click an icon to see a previous commit, etc. For the .rst sources, it's a little different and there is a Blame button at the top of the source that will bring up the same view (commit annotations to the left of the source) as right-clicking. I had posted about git blame a few months ago on core mentorship and Carol Willing mentioned another tool to get all the changes by line. Here was her post: Thanks for passing along the tip for others. You may also find the npm package `git-guilt` useful as it will display all the contributors to a particular line's history. https://www.npmjs.com/package/git-guilt ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 07:26:31 2017 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 09 Dec 2017 12:26:31 +0000 Subject: [issue32212] few discrepancy between source and docs in logging In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za> Message-ID: <1512822391.66.0.213398074469.issue32212@psf.upfronthosting.co.za> Change by Vinay Sajip : ---------- pull_requests: +4671 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 07:28:18 2017 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 09 Dec 2017 12:28:18 +0000 Subject: [issue32212] few discrepancy between source and docs in logging In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za> Message-ID: <1512822498.85.0.213398074469.issue32212@psf.upfronthosting.co.za> Vinay Sajip added the comment: New changeset 63868181a904c844d8d01e3badfdd5b134acc5fa by Vinay Sajip in branch '3.6': bpo-32212: Updated logging documentation to make parameter names more consistent with source. (GH-4765) (GH-4767) https://github.com/python/cpython/commit/63868181a904c844d8d01e3badfdd5b134acc5fa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 07:40:53 2017 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 09 Dec 2017 12:40:53 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512823253.03.0.213398074469.issue32259@psf.upfronthosting.co.za> Eric V. Smith added the comment: The error message is correct, but I'm sorry it's confusing. Here's an equivalent error: a, b = 3 You'll get the error "TypeError: 'int' object is not iterable". That's because Python sees 2 items to the left of the assignment, so it needs to extract 2 items from the right side. To get 2 values from the right side, it iterates over the right side. In this case, 3 cannot be iterated over, thus the error message. Now consider: a, b = 3, 4 Again, to get 2 items from the right side, Python iterates over it. In this case the thing on the right side is a 2 element tuple. It's a little confusing that it's a tuple because it doesn't have parentheses, but the comma between 3 and 4 makes it a tuple. In this case, Python can iterate over the tuple, and the tuple has exactly 2 elements, so the assignment to a and b succeeds with a = 3 and b = 4. I hope that clears it up. ---------- nosy: +eric.smith resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 07:49:14 2017 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 09 Dec 2017 12:49:14 +0000 Subject: [issue32212] few discrepancy between source and docs in logging In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za> Message-ID: <1512823754.37.0.213398074469.issue32212@psf.upfronthosting.co.za> Vinay Sajip added the comment: New changeset 292fce9934280867ca9a65870495f83fca37751e by Vinay Sajip in branch '2.7': bpo-32212: Updated logging documentation to make parameter names more consistent with source. (GH-4765) (GH-4768) https://github.com/python/cpython/commit/292fce9934280867ca9a65870495f83fca37751e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 07:51:16 2017 From: report at bugs.python.org (Vinay Sajip) Date: Sat, 09 Dec 2017 12:51:16 +0000 Subject: [issue32212] few discrepancy between source and docs in logging In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za> Message-ID: <1512823876.66.0.213398074469.issue32212@psf.upfronthosting.co.za> Change by Vinay Sajip : ---------- resolution: not a bug -> fixed stage: patch review -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 08:02:53 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 09 Dec 2017 13:02:53 +0000 Subject: [issue20285] Improve object.__doc__ and help(object) output In-Reply-To: <1389920351.63.0.12805701843.issue20285@psf.upfronthosting.co.za> Message-ID: <1512824573.84.0.213398074469.issue20285@psf.upfronthosting.co.za> Cheryl Sabella added the comment: Hi Terry, I've submitted a PR for this. Thanks! ---------- nosy: +csabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 08:48:13 2017 From: report at bugs.python.org (petros) Date: Sat, 09 Dec 2017 13:48:13 +0000 Subject: [issue2636] Adding a new regex module (compatible with re) In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za> Message-ID: <1512827293.67.0.213398074469.issue2636@psf.upfronthosting.co.za> Change by petros : ---------- nosy: +petros _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 09:34:54 2017 From: report at bugs.python.org (Camion) Date: Sat, 09 Dec 2017 14:34:54 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512830094.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Camion added the comment: Ok, but the other explanation is valid as well. That's why I suggest to modify the error message like this : TypeError: '[TYPE]' object is not iterable - OR - ValueError: not enough values to unpack (expected [N], got 1) ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 10:02:58 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 09 Dec 2017 15:02:58 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512831778.43.0.213398074469.issue32259@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I concur with Eric. The current exception is correct and allows to identify your mistake. Changing the type of the exception will break an existing code, and the message proposed by you is misleading. ---------- nosy: +serhiy.storchaka status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 10:18:18 2017 From: report at bugs.python.org (Licht Takeuchi) Date: Sat, 09 Dec 2017 15:18:18 +0000 Subject: [issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n' In-Reply-To: <1512744234.4.0.213398074469.issue32255@psf.upfronthosting.co.za> Message-ID: <1512832698.35.0.213398074469.issue32255@psf.upfronthosting.co.za> Change by Licht Takeuchi : ---------- keywords: +patch pull_requests: +4672 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 10:38:01 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 09 Dec 2017 15:38:01 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1512833881.53.0.213398074469.issue26865@psf.upfronthosting.co.za> Xavier de Gaye added the comment: issue #32031: Do not use the canonical path in pydoc test_mixed_case_module_names_are_lower_cased issue #32059: detect_modules() in setup.py must also search the sysroot paths issue #32126: [asyncio] test failure when the platform lacks a functional sem_open() issue #32138: android: test_faulthandler fails also on API 24 issue #32139: android: locale is modified by test_strftime issue #32205: test.pythoninfo prints the native sysconfig data when cross-compiling issue #32199: uuid.getnode() now returns the MAC address on Android issue #32246: test_regrtest alters the execution environment on Android issue #32210: Add platform.android_ver() to test.pythoninfo for Android platforms issue #32202: [ctypes] all long double tests fail on android-24-x86_64 issue #32203: [ctypes] test_struct_by_value fails on android-24-arm64 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 10:42:07 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 09 Dec 2017 15:42:07 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1512834127.06.0.213398074469.issue26865@psf.upfronthosting.co.za> Change by Xavier de Gaye : ---------- dependencies: +Add platform.android_ver() to test.pythoninfo for Android platforms, Do not use the canonical path in pydoc test_mixed_case_module_names_are_lower_cased, [asyncio] test failure when the platform lacks a functional sem_open(), [ctypes] all long double tests fail on android-24-x86_64, [ctypes] test_struct_by_value fails on android-24-arm64, android: locale is modified by test_strftime, android: test_faulthandler fails also on API 24, detect_modules() in setup.py must also search the sysroot paths, test.pythoninfo does not print the cross-built sysconfig data, test_regrtest alters the execution environment on Android, uuid.getnode() should return the MAC address on Android _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 10:48:22 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 09 Dec 2017 15:48:22 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1512834502.28.0.213398074469.issue26865@psf.upfronthosting.co.za> Xavier de Gaye added the comment: issue 22724 is fixed for Android. ---------- dependencies: -byte-compile fails for cross-builds _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 11:11:38 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 09 Dec 2017 16:11:38 +0000 Subject: [issue32253] Deprecate old-style locking in asyncio/locks.py In-Reply-To: <1512723580.6.0.213398074469.issue32253@psf.upfronthosting.co.za> Message-ID: <1512835898.15.0.213398074469.issue32253@psf.upfronthosting.co.za> Yury Selivanov added the comment: > This can make harder writing portable code that works in 2.7, 3.4 and 3.7. asyncio for Python 3.4 is fairly outdated. Most of the async packages today require 3.5+, as they usually use async/await syntax. I say this sort of backwards compatibility (showing a warning) isn't really a big concern. A bigger concern for us is new code using 'with await lock' pattern, hence the warning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 11:41:40 2017 From: report at bugs.python.org (sblondon) Date: Sat, 09 Dec 2017 16:41:40 +0000 Subject: [issue32234] Add context management to mailbox.Mailbox In-Reply-To: <1512574106.47.0.213398074469.issue32234@psf.upfronthosting.co.za> Message-ID: <1512837700.96.0.213398074469.issue32234@psf.upfronthosting.co.za> Change by sblondon : ---------- keywords: +patch pull_requests: +4673 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 12:18:57 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 09 Dec 2017 17:18:57 +0000 Subject: [issue32234] Add context management to mailbox.Mailbox In-Reply-To: <1512574106.47.0.213398074469.issue32234@psf.upfronthosting.co.za> Message-ID: <1512839937.24.0.213398074469.issue32234@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- nosy: -yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 12:33:38 2017 From: report at bugs.python.org (Camion) Date: Sat, 09 Dec 2017 17:33:38 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512840818.62.0.213398074469.issue32259@psf.upfronthosting.co.za> Camion added the comment: I'm not talking about changing the type of the exception, Serhiy. but only to make the text message more explicit by adding a lead to a secondary possible cause. I do not understand how this addition would be misleading - more than the case I presented ? (Did you check my example ?) I agree that this message might possibly make my mistake obvious to an senior _python_ programmer, but doesn't the constraint of being _experienced in python_, not go in contradiction with the mantra "Explicit is better than implicit" ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 13:00:07 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 09 Dec 2017 18:00:07 +0000 Subject: [issue32253] Deprecate old-style locking in asyncio/locks.py In-Reply-To: <1512723580.6.0.213398074469.issue32253@psf.upfronthosting.co.za> Message-ID: <1512842407.8.0.213398074469.issue32253@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset 28d8d14013ade0657fed4673f5fa3c08eb2b1944 by Andrew Svetlov in branch 'master': bpo-32253: Deprecate with statement and bare await for asyncio locks (GH-4764) https://github.com/python/cpython/commit/28d8d14013ade0657fed4673f5fa3c08eb2b1944 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 13:00:28 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 09 Dec 2017 18:00:28 +0000 Subject: [issue32253] Deprecate old-style locking in asyncio/locks.py In-Reply-To: <1512723580.6.0.213398074469.issue32253@psf.upfronthosting.co.za> Message-ID: <1512842428.64.0.213398074469.issue32253@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 13:04:12 2017 From: report at bugs.python.org (Qichao Chu) Date: Sat, 09 Dec 2017 18:04:12 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512842652.88.0.213398074469.issue32257@psf.upfronthosting.co.za> Qichao Chu added the comment: Hi Christian, Thank you for review! I have changed the code to directly setting this flag by using s3->flag. Code is copied from nginx repo: https://github.com/nginx/nginx/blob/ed0cc4d52308b75ab217724392994e6828af4fda/src/event/ngx_event_openssl.c. I think this change is still needed. Although OpenSSL claimed it is fixed, THC-SSL-DOS showed it is vulnerable. If this is not the case, then nginx won't need to set the flag. Thanks, Qichao ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 13:12:31 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Dec 2017 18:12:31 +0000 Subject: [issue8722] Documentation for __getattr__ In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za> Message-ID: <1512843151.11.0.213398074469.issue8722@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thanks. I normally look at source in my local clone with an editor. I found 'view blame' and 'view blame prior' on github. ---------- keywords: -patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 13:24:32 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 09 Dec 2017 18:24:32 +0000 Subject: [issue31650] implement PEP 552 In-Reply-To: <1512810419.66.0.213398074469.issue31650@psf.upfronthosting.co.za> Message-ID: <1512843868.713318.1199598712.63F7C749@webmail.messagingengine.com> Benjamin Peterson added the comment: On Sat, Dec 9, 2017, at 01:06, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > While we are here, can other changes be made? All these suggestions seem fine, but they're not in the PEP and the change is already large enough. gps also points out we should expand the timestamp field to 64 bits for 2038 proofing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 13:26:54 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 09 Dec 2017 18:26:54 +0000 Subject: [issue31650] implement PEP 552 In-Reply-To: <1506801596.1.0.213398074469.issue31650@psf.upfronthosting.co.za> Message-ID: <1512844014.42.0.213398074469.issue31650@psf.upfronthosting.co.za> Benjamin Peterson added the comment: New changeset 42aa93b8ff2f7879282b06efc73a31ec7785e602 by Benjamin Peterson in branch 'master': closes bpo-31650: PEP 552 (Deterministic pycs) implementation (#4575) https://github.com/python/cpython/commit/42aa93b8ff2f7879282b06efc73a31ec7785e602 ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 14:02:55 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 09 Dec 2017 19:02:55 +0000 Subject: [issue32260] siphash shouldn't byte swap the keys Message-ID: <1512846175.55.0.213398074469.issue32260@psf.upfronthosting.co.za> New submission from Benjamin Peterson : Reference siphash takes the keys as a bytes, so it makes sense to byte swap when reifying the keys as 64-bit integers. However, Python's modified siphash takes host integers in to start with. ---------- components: Interpreter Core messages: 307910 nosy: benjamin.peterson priority: normal severity: normal status: open title: siphash shouldn't byte swap the keys type: behavior versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 14:05:03 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 09 Dec 2017 19:05:03 +0000 Subject: [issue32260] siphash shouldn't byte swap the keys In-Reply-To: <1512846175.55.0.213398074469.issue32260@psf.upfronthosting.co.za> Message-ID: <1512846303.39.0.213398074469.issue32260@psf.upfronthosting.co.za> Change by Benjamin Peterson : ---------- keywords: +patch pull_requests: +4674 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 14:09:45 2017 From: report at bugs.python.org (Christian Heimes) Date: Sat, 09 Dec 2017 19:09:45 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512846585.13.0.213398074469.issue32257@psf.upfronthosting.co.za> Christian Heimes added the comment: If it's a bug in OpenSSL, please report the bug with OpenSSL and request a fix. Bugs should be patched where they occur. Can you contact OpenSSL development team, please? The flag is not documented and I don't know how it influences OpenSSL. Does the flag only affect SSL 3.0 or also TLS 1.0 and newer? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 14:14:41 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 09 Dec 2017 19:14:41 +0000 Subject: [issue32261] Online doc does not include inspect.classify_class_attrs Message-ID: <1512846881.17.0.213398074469.issue32261@psf.upfronthosting.co.za> New submission from Cheryl Sabella : Documentation for inspect.classify_class_attrs exists in the docstring and, therefore, pydoc, but is not included in the online docs for inspect. ---------- assignee: docs at python components: Documentation keywords: easy messages: 307912 nosy: csabella, docs at python priority: normal severity: normal status: open title: Online doc does not include inspect.classify_class_attrs type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 14:24:20 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 09 Dec 2017 19:24:20 +0000 Subject: [issue32260] siphash shouldn't byte swap the keys In-Reply-To: <1512846175.55.0.213398074469.issue32260@psf.upfronthosting.co.za> Message-ID: <1512847460.93.0.213398074469.issue32260@psf.upfronthosting.co.za> Benjamin Peterson added the comment: New changeset 4e3e156391e70cd23cae18f2629ec323b3b1e7de by Benjamin Peterson in branch 'master': bpo-32260: don't byte swap siphash keys (#4771) https://github.com/python/cpython/commit/4e3e156391e70cd23cae18f2629ec323b3b1e7de ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 14:51:55 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Dec 2017 19:51:55 +0000 Subject: [issue20285] Improve object.__doc__ and help(object) output In-Reply-To: <1389920351.63.0.12805701843.issue20285@psf.upfronthosting.co.za> Message-ID: <1512849115.72.0.213398074469.issue20285@psf.upfronthosting.co.za> Terry J. Reedy added the comment: After looking at https://en.wiktionary.org/wiki/base I can explain better why 'most base class' is wrong, and felt wrong to participants in the python-list thread. 'Base' is actually two words. As a noun (or verb), it comes from Ancient Greek ????? (b?sis), a foundation from which other things extend or derive. As an adjective, it comes from Late Latin bassus (?low?). In computer science and Python, the couplet 'base class' is being used, it seems to me and apparently others, as a noun-noun compound, meaning, 'foundation class', not as an adjective-noun phrase meaning 'low class' (let along 'depraved class'). However, 'most base class' must be parsed as '(most base) class', with 'base' re-interpreted as the adjective meaning 'low' (or worse). The switch in meaning of 'base' is similar in 'baseball' versus 'most base ball'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 15:36:23 2017 From: report at bugs.python.org (Eryk Sun) Date: Sat, 09 Dec 2017 20:36:23 +0000 Subject: [issue32245] OSError: raw write() returned invalid length on latest Win 10 Consoles In-Reply-To: <1512660082.17.0.213398074469.issue32245@psf.upfronthosting.co.za> Message-ID: <1512851783.48.0.213398074469.issue32245@psf.upfronthosting.co.za> Change by Eryk Sun : ---------- components: +Windows nosy: +paul.moore, tim.golden, zach.ware stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 15:50:15 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 09 Dec 2017 20:50:15 +0000 Subject: [issue32260] siphash shouldn't byte swap the keys In-Reply-To: <1512846175.55.0.213398074469.issue32260@psf.upfronthosting.co.za> Message-ID: <1512852615.36.0.213398074469.issue32260@psf.upfronthosting.co.za> Change by Benjamin Peterson : ---------- pull_requests: +4675 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 16:11:41 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 09 Dec 2017 21:11:41 +0000 Subject: [issue32260] siphash shouldn't byte swap the keys In-Reply-To: <1512846175.55.0.213398074469.issue32260@psf.upfronthosting.co.za> Message-ID: <1512853901.78.0.213398074469.issue32260@psf.upfronthosting.co.za> Benjamin Peterson added the comment: New changeset 60ed1308304964e5648d8bfc9b74bd549570fa83 by Benjamin Peterson in branch 'master': byte swap the raw hash secrets (more bpo-32260) (#4773) https://github.com/python/cpython/commit/60ed1308304964e5648d8bfc9b74bd549570fa83 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 16:14:46 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 09 Dec 2017 21:14:46 +0000 Subject: [issue20285] Improve object.__doc__ and help(object) output In-Reply-To: <1389920351.63.0.12805701843.issue20285@psf.upfronthosting.co.za> Message-ID: <1512854086.8.0.213398074469.issue20285@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: "Python class" can be read as a user type defined in Python (usually with the "class" statement). The term "class" in the glossary is used with this meaning in contrary to the term "type" which means also builtin and extension types. In Python 3 "object" is a base class of all types, not only user-defined class. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 16:18:21 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 09 Dec 2017 21:18:21 +0000 Subject: [issue31392] Upgrade installers to OpenSSL 1.1.0g and 1.0.2n In-Reply-To: <1504839169.11.0.433103507115.issue31392@psf.upfronthosting.co.za> Message-ID: <1512854301.93.0.213398074469.issue31392@psf.upfronthosting.co.za> Ned Deily added the comment: And now 1.0.2n is out. I'm not sure how vulnerable Python is to the main problem fixed (see https://www.openssl.org/news/secadv/20171207.txt) which only impacts 1.0.2.x but I'd be willing to pull it into 3.6.4 final for the Windows and macOS installers. ---------- title: Upgrade installers to OpenSSL 1.1.0g and 1.0.2m -> Upgrade installers to OpenSSL 1.1.0g and 1.0.2n _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 16:23:15 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 09 Dec 2017 21:23:15 +0000 Subject: [issue32245] OSError: raw write() returned invalid length on latest Win 10 Consoles In-Reply-To: <1512660082.17.0.213398074469.issue32245@psf.upfronthosting.co.za> Message-ID: <1512854595.7.0.213398074469.issue32245@psf.upfronthosting.co.za> Steve Dower added the comment: Does this only affect Python 3.5? We're highly unlikely to take a fix for that version. This code was rewritten for 3.6, so it wouldn't surprise me if there is no longer an issue. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 16:24:47 2017 From: report at bugs.python.org (Julien Palard) Date: Sat, 09 Dec 2017 21:24:47 +0000 Subject: [issue30737] Update devguide link to the new URL In-Reply-To: <1498151147.34.0.638989883605.issue30737@psf.upfronthosting.co.za> Message-ID: <1512854687.46.0.213398074469.issue30737@psf.upfronthosting.co.za> Julien Palard added the comment: Just spotted the "CORE DEVELOPMENT" link in the bugs.python.org points to the old one too. Redirections should be placed on https://docs.python.org/devguide/ to the new one too. ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 16:30:05 2017 From: report at bugs.python.org (Larry Hastings) Date: Sat, 09 Dec 2017 21:30:05 +0000 Subject: [issue32245] OSError: raw write() returned invalid length on latest Win 10 Consoles In-Reply-To: <1512660082.17.0.213398074469.issue32245@psf.upfronthosting.co.za> Message-ID: <1512855005.56.0.213398074469.issue32245@psf.upfronthosting.co.za> Larry Hastings added the comment: To confirm what Steve said: we no longer accept bug fixes for Python 3.5 (or 3.4). We only accept security fixes for 3.5 (and 3.4). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 16:35:20 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 09 Dec 2017 21:35:20 +0000 Subject: [issue32262] Fix linting errors in asyncio code; use f-strings consistently Message-ID: <1512855320.36.0.213398074469.issue32262@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- components: asyncio nosy: yselivanov priority: normal severity: normal status: open title: Fix linting errors in asyncio code; use f-strings consistently versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 16:35:26 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 09 Dec 2017 21:35:26 +0000 Subject: [issue32262] Fix linting errors in asyncio code; use f-strings consistently Message-ID: <1512855326.19.0.213398074469.issue32262@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 16:35:43 2017 From: report at bugs.python.org (Julien Palard) Date: Sat, 09 Dec 2017 21:35:43 +0000 Subject: [issue30737] Update devguide link to the new URL In-Reply-To: <1498151147.34.0.638989883605.issue30737@psf.upfronthosting.co.za> Message-ID: <1512855343.77.0.213398074469.issue30737@psf.upfronthosting.co.za> Julien Palard added the comment: I opened a PR on psf-salt to fix HTTP redirections https://github.com/python/psf-salt/pull/123 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 16:36:38 2017 From: report at bugs.python.org (Glenn Linderman) Date: Sat, 09 Dec 2017 21:36:38 +0000 Subject: [issue32263] Template string docs refer to "normal %-based substitutions" Message-ID: <1512855398.42.0.213398074469.issue32263@psf.upfronthosting.co.za> New submission from Glenn Linderman : At least as far back as Python 3.1, the description for Template strings (section 6.1.5 in version 3.6.4rc1 docs) starts by differentiating what Template strings do, as: Instead of the normal %-based substitutions, Templates support $-based substitutions, using the following rules: Since this immediately follows a section describing the "Custom String Formatting" and the "Format Specification Mini-Language", which does a type of substitutions that is {} based, rather than % based, it is hard to grasp exactly why %-based substitutions would be considered "normal". Of course, I know why, due to the % operator, but for someone just reading through chapter 6, it is a reference that raises the mental question "Huh? What is normal %-based substitution? Are Templates abnormal, if %-based substitutions are normal? What did I miss? The previous section was about {}-based substitutions? Are they abnormal, too? What are normal %-based substitutions, anyway?" rather than helping to describe what Templates are and do. ---------- assignee: docs at python components: Documentation messages: 307922 nosy: docs at python, v+python priority: normal severity: normal status: open title: Template string docs refer to "normal %-based substitutions" versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 16:41:27 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 09 Dec 2017 21:41:27 +0000 Subject: [issue32262] Fix linting errors in asyncio code; use f-strings consistently Message-ID: <1512855687.52.0.213398074469.issue32262@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4676 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 16:51:11 2017 From: report at bugs.python.org (Julien Palard) Date: Sat, 09 Dec 2017 21:51:11 +0000 Subject: [issue30737] Update devguide link to the new URL In-Reply-To: <1498151147.34.0.638989883605.issue30737@psf.upfronthosting.co.za> Message-ID: <1512856271.13.0.213398074469.issue30737@psf.upfronthosting.co.za> Julien Palard added the comment: Just created http://psf.upfronthosting.co.za/roundup/meta/issue646 to track the "CORE DEVELOPMENT" link of b.p.o. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 16:58:25 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 09 Dec 2017 21:58:25 +0000 Subject: [issue32263] Template string docs refer to "normal %-based substitutions" In-Reply-To: <1512855398.42.0.213398074469.issue32263@psf.upfronthosting.co.za> Message-ID: <1512856705.56.0.213398074469.issue32263@psf.upfronthosting.co.za> Change by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 16:59:16 2017 From: report at bugs.python.org (Qichao Chu) Date: Sat, 09 Dec 2017 21:59:16 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512856756.02.0.213398074469.issue32257@psf.upfronthosting.co.za> Qichao Chu added the comment: I don't think it is a bug in OpenSSL. For various reasons, certain applications must allow renegotiation while this leaves security problem for others. That's why if python can control this flag, applications will be more confident in dealing with DoS attacks aimed at renegotiation. This flag controls not only SSL3 but also TLSv1.1 and TLSv1.2 after testing on Nginx and Gevent. As of OpenSSL 1.0.2h, in file ssl/s3_lib.c int ssl3_renegotiate(SSL *s) { if (s->handshake_func == NULL) return (1); if (s->s3->flags & SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS) return (0); s->s3->renegotiate = 1; return (1); } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 17:06:15 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Sat, 09 Dec 2017 22:06:15 +0000 Subject: [issue30140] Binary arithmetic does not always call subclasses first In-Reply-To: <1492921304.69.0.401017078402.issue30140@psf.upfronthosting.co.za> Message-ID: <1512857175.34.0.213398074469.issue30140@psf.upfronthosting.co.za> Change by Cheryl Sabella : ---------- components: +Interpreter Core keywords: +needs review, patch stage: -> patch review versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 17:06:40 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 09 Dec 2017 22:06:40 +0000 Subject: [issue32260] siphash shouldn't byte swap the keys In-Reply-To: <1512846175.55.0.213398074469.issue32260@psf.upfronthosting.co.za> Message-ID: <1512857200.37.0.213398074469.issue32260@psf.upfronthosting.co.za> Change by Benjamin Peterson : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 17:08:43 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 09 Dec 2017 22:08:43 +0000 Subject: [issue32264] move pygetopt.h into internal/ Message-ID: <1512857323.9.0.213398074469.issue32264@psf.upfronthosting.co.za> New submission from Benjamin Peterson : This header has no public functions. It shouldn't be distributed. ---------- components: Interpreter Core messages: 307925 nosy: benjamin.peterson priority: normal severity: normal status: open title: move pygetopt.h into internal/ type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 17:15:36 2017 From: report at bugs.python.org (Eryk Sun) Date: Sat, 09 Dec 2017 22:15:36 +0000 Subject: [issue32245] OSError: raw write() returned invalid length on latest Win 10 Consoles In-Reply-To: <1512660082.17.0.213398074469.issue32245@psf.upfronthosting.co.za> Message-ID: <1512857736.28.0.213398074469.issue32245@psf.upfronthosting.co.za> Eryk Sun added the comment: We need a test that reproduces this problem on a vanilla installation of Python 3.5. Include the system locale context as well, i.e. the ANSI codepage, OEM codepage, and active console output codepage. A reliable test will help determine whether this problem also affects legacy console I/O in Python 3.6. However, even if the problem affects 3.6, that doesn't mean there's anything we can reasonably do about it if the fault is the console host process (i.e. conhost.exe, running either ConhostV1.dll or the new ConhostV2.dll implementation). A possible workaround in Python 3.5 would be to install and enable the win_unicode_console package. This package uses the console's native Unicode API instead of the legacy codepage API. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 17:46:19 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Dec 2017 22:46:19 +0000 Subject: [issue20285] Improve object.__doc__ and help(object) output In-Reply-To: <1389920351.63.0.12805701843.issue20285@psf.upfronthosting.co.za> Message-ID: <1512859579.46.0.213398074469.issue20285@psf.upfronthosting.co.za> Terry J. Reedy added the comment: How about "The starting base class of all types and classes other than itself." (Object.__bases__ = ().) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 17:54:10 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 09 Dec 2017 22:54:10 +0000 Subject: [issue32265] Correctly classify builtin static and class methods Message-ID: <1512860050.29.0.213398074469.issue32265@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : Currently class and some static methods of builtin types are classified as plain methods. The proposed patch adds types.ClassMethodDescriptorType for unbound class methods of builtin types and makes inspect.classify_class_attrs() correctly classifying static and class methods of builtin types. This results in changing the help() output. All __new__ methods now are classified as static. Examples of class methods are dict.fromkeys and int.from_bytes. ---------- components: Library (Lib) messages: 307928 nosy: serhiy.storchaka, yselivanov priority: normal severity: normal status: open title: Correctly classify builtin static and class methods type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 18:04:18 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 09 Dec 2017 23:04:18 +0000 Subject: [issue32265] Correctly classify builtin static and class methods In-Reply-To: <1512860050.29.0.213398074469.issue32265@psf.upfronthosting.co.za> Message-ID: <1512860658.52.0.213398074469.issue32265@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +4677 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 18:26:09 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 09 Dec 2017 23:26:09 +0000 Subject: [issue32262] Fix linting errors in asyncio code; use f-strings consistently Message-ID: <1512861969.57.0.213398074469.issue32262@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : Usually we don't do such kind of changes. This spoils the output of `git annotate` and `git blame` and makes harder researching the history. ---------- nosy: +pitrou, rhettinger, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 19:02:21 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Sun, 10 Dec 2017 00:02:21 +0000 Subject: [issue27505] Missing documentation for setting module __class__ attribute In-Reply-To: <1468373521.97.0.915242819681.issue27505@psf.upfronthosting.co.za> Message-ID: <1512864141.14.0.213398074469.issue27505@psf.upfronthosting.co.za> Cheryl Sabella added the comment: Hi Nick, I started looking at this issue for documenting #22986 and then found #24912 and #24991. Has anything changed in the code since 2015 that would make these issues (this one and 24991) obsolete? It seems there were a lot of ideas flying around, but I couldn't find other tickets (and the code is still in place for 22986 and 24912). If these haven't been superseded, do you think the discussion on #24991 should be continued or should the documentation mentioned in this issue still be done? Thanks! ---------- nosy: +csabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 19:08:04 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Sun, 10 Dec 2017 00:08:04 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512864484.87.0.213398074469.issue32257@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Another reason to consider making it possible to disable renegotiation is HTTP/2. RFC 7540 says: A deployment of HTTP/2 over TLS 1.2 MUST disable renegotiation. An endpoint MUST treat a TLS renegotiation as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. https://tools.ietf.org/html/rfc7540#section-9.2.1 ---------- nosy: +njs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 19:14:04 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 10 Dec 2017 00:14:04 +0000 Subject: [issue30928] Copy modified blurbs to idlelib/NEWS.txt In-Reply-To: <1500004288.4.0.547702885246.issue30928@psf.upfronthosting.co.za> Message-ID: <1512864844.0.0.213398074469.issue30928@psf.upfronthosting.co.za> Change by Terry J. Reedy : ---------- pull_requests: +4678 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 19:14:25 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 10 Dec 2017 00:14:25 +0000 Subject: [issue31506] Improve the error message logic for object_new & object_init In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za> Message-ID: <1512864865.13.0.213398074469.issue31506@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset 780acc89bccf9999332d334a27887684cc942eb6 by Nick Coghlan (Sanyam Khurana) in branch 'master': bpo-31506: Improve the error message logic for class instantiation (GH-4740) https://github.com/python/cpython/commit/780acc89bccf9999332d334a27887684cc942eb6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 19:17:00 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 10 Dec 2017 00:17:00 +0000 Subject: [issue31506] Improve the error message logic for object_new & object_init In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za> Message-ID: <1512865020.12.0.213398074469.issue31506@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks for the feedback and updates folks! If we decide to make any further changes, I think they will be best handled as a new issue :) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 19:27:44 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 10 Dec 2017 00:27:44 +0000 Subject: [issue24991] Define instance mutability explicitly on type objects? In-Reply-To: <1441260483.41.0.785006760825.issue24991@psf.upfronthosting.co.za> Message-ID: <1512865664.47.0.213398074469.issue24991@psf.upfronthosting.co.za> Nick Coghlan added the comment: I updated some of the issue metadata and added a question mark to the issue title to help make it clearer that this would require a PEP level conceptual enhancement to the language, rather than being about documenting an existing concept. PEP 557's data classes take a step in that direction with their "frozen=True" parameter: https://www.python.org/dev/peps/pep-0557/#frozen-instances ---------- components: +Interpreter Core title: Define instance mutability explicitly on type objects -> Define instance mutability explicitly on type objects? type: -> enhancement versions: +Python 3.8 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 19:31:24 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 10 Dec 2017 00:31:24 +0000 Subject: [issue32225] Implement PEP 562: module __getattr__ and __dir__ Message-ID: <1512865884.25.0.213398074469.issue32225@psf.upfronthosting.co.za> Change by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 19:39:16 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 10 Dec 2017 00:39:16 +0000 Subject: [issue32225] Implement PEP 562: module __getattr__ and __dir__ Message-ID: <1512866356.6.0.213398074469.issue32225@psf.upfronthosting.co.za> New submission from Nick Coghlan : For documentation of this feature, I'd suggest adding a new subsection after https://docs.python.org/3/reference/datamodel.html#customizing-attribute-access (but at the same level), called "Customizing module attribute access". That can then cover defining __getattr__ and __dir__ as module level functions, and also mention setting __class__ (which would be enough to close issue 27505 as well). The new section should explicitly mention that these only affect lookups and modifications made using the attribute access syntax - directly accessing the module globals (whether by code within the module, or via a reference to the module's globals dict) is unaffected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 19:41:24 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 10 Dec 2017 00:41:24 +0000 Subject: [issue27505] Missing documentation for setting module __class__ attribute In-Reply-To: <1468373521.97.0.915242819681.issue27505@psf.upfronthosting.co.za> Message-ID: <1512866484.01.0.213398074469.issue27505@psf.upfronthosting.co.za> Nick Coghlan added the comment: This is still a valid docs issue, although PEP 562's module __getattr__ and __dir__ will provide a simpler alternative for most of the cases that previously required setting the __class__ attribute: https://www.python.org/dev/peps/pep-0562/ So I've added https://bugs.python.org/issue32225 as a dependency for this issue, as it will likely make sense to figure out a good docs structure for those changes first, and then see if there's any work left to do specifically for this issue: https://bugs.python.org/issue32225#msg307935 Issue #24991 is a fairly different topic - I've added an extra comment there that should help clarify the actual question/proposal. ---------- dependencies: +Implement PEP 562: module __getattr__ and __dir__ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 20:31:49 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 10 Dec 2017 01:31:49 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512869509.79.0.213398074469.issue32259@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I agree with Camion that the error message is misleading, and not just for beginners. It threw me for a loop too, when I first read it. Serhiy is right, the exception type cannot and should not be changed, but we can change the error message. I'm re-opening the ticket as an enhancement to improve the message. Here's my suggestion: TypeError: cannot unpack object ('Fraction' is not iterable) There is no stability guarantees on error messages, so we can include it in 3.6 (and possibly older if desired). By the way Camion, as interesting as your program to calculate the digits of pi is, in general it is better to cut the code down to the simplest version that demonstrates the problem. Something like this would demonstrate it equally as well: def gen(): yield 1 for x, y in gen(): pass ---------- nosy: +steven.daprano resolution: not a bug -> stage: resolved -> needs patch status: closed -> open type: behavior -> enhancement versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 20:56:28 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 10 Dec 2017 01:56:28 +0000 Subject: [issue32262] Fix linting errors in asyncio code; use f-strings consistently In-Reply-To: <1512861969.57.0.213398074469.issue32262@psf.upfronthosting.co.za> Message-ID: <1512870988.31.0.213398074469.issue32262@psf.upfronthosting.co.za> Yury Selivanov added the comment: I think it's OK. I want asyncio code to stay modern and up to date. git blame is not a problem here, as only one-two lines are changed per function. Code consistency is more important. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 21:38:07 2017 From: report at bugs.python.org (Martin Panter) Date: Sun, 10 Dec 2017 02:38:07 +0000 Subject: [issue17972] inspect module docs omits many functions In-Reply-To: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za> Message-ID: <1512873487.59.0.213398074469.issue17972@psf.upfronthosting.co.za> Change by Martin Panter : ---------- dependencies: +Online doc does not include inspect.classify_class_attrs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 22:18:20 2017 From: report at bugs.python.org (Nitish) Date: Sun, 10 Dec 2017 03:18:20 +0000 Subject: [issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n' In-Reply-To: <1512744234.4.0.213398074469.issue32255@psf.upfronthosting.co.za> Message-ID: <1512875900.8.0.213398074469.issue32255@psf.upfronthosting.co.za> Nitish added the comment: Which scenario you think is the wrong behaviour in this case? First one or second one? I don't know much about csv module, but I thought it was a deliberate choice made to quote all empty lines and hence considered the second scenario as buggy. But your pull requests seems to fix the first case. Am I missing something here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 9 22:24:34 2017 From: report at bugs.python.org (Larry Hastings) Date: Sun, 10 Dec 2017 03:24:34 +0000 Subject: [issue32245] OSError: raw write() returned invalid length on latest Win 10 Consoles In-Reply-To: <1512660082.17.0.213398074469.issue32245@psf.upfronthosting.co.za> Message-ID: <1512876274.21.0.213398074469.issue32245@psf.upfronthosting.co.za> Change by Larry Hastings : ---------- nosy: -larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 00:06:24 2017 From: report at bugs.python.org (Licht Takeuchi) Date: Sun, 10 Dec 2017 05:06:24 +0000 Subject: [issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n' In-Reply-To: <1512744234.4.0.213398074469.issue32255@psf.upfronthosting.co.za> Message-ID: <1512882384.47.0.213398074469.issue32255@psf.upfronthosting.co.za> Licht Takeuchi added the comment: I think the first one is buggy and there are two reasons. 1. The both are valid CSV. The double quoting is unnecessary. Some other applications, eg. Excel, does not use the double quoting. Also, the current implementation make to quote only if the string is '' and the output is at the first line. 2. '' is not quoted when the two columns case. ## Input: ``` import csv fp = open('test.csv', 'w') w = csv.writer(fp, dialect=None) w.writerow(['', '']) w.writerow(['3', 'a']) fp.close() ``` ## Output: ``` , 3,a ``` These seem inconsistent and the quoting is unnecessary in this case. # References http://www.ietf.org/rfc/rfc4180.txt ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 00:15:33 2017 From: report at bugs.python.org (Licht Takeuchi) Date: Sun, 10 Dec 2017 05:15:33 +0000 Subject: [issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n' In-Reply-To: <1512744234.4.0.213398074469.issue32255@psf.upfronthosting.co.za> Message-ID: <1512882933.87.0.213398074469.issue32255@psf.upfronthosting.co.za> Licht Takeuchi added the comment: The current implementation does not quote in most case. IOW, the patch which makes all '' is quoted is the breaking change (Note that there are some applications does not use quoting). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 00:41:42 2017 From: report at bugs.python.org (Camion) Date: Sun, 10 Dec 2017 05:41:42 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512884502.06.0.213398074469.issue32259@psf.upfronthosting.co.za> Camion added the comment: I wrote it like that on purpose, Steven : My goal was not to show the message itself which (I believe) was sufficiently described in the explanation, but to show how hard it might be to understand the mistake in regard with the error message, even here, with a real life but not outrageously complicated code. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 01:10:05 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 10 Dec 2017 06:10:05 +0000 Subject: [issue30806] netrc.__repr__() is broken for writing to file In-Reply-To: <1498763541.77.0.380552653426.issue30806@psf.upfronthosting.co.za> Message-ID: <1512886205.44.0.213398074469.issue30806@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset 3b9173d33adc2903e1af461214333b0052d7b1e9 by INADA Naoki (Steven Loria) in branch '2.7': bpo-30806: Fix netrc.__repr__() format (GH-2491) https://github.com/python/cpython/commit/3b9173d33adc2903e1af461214333b0052d7b1e9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 01:25:59 2017 From: report at bugs.python.org (Camion) Date: Sun, 10 Dec 2017 06:25:59 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512887159.07.0.213398074469.issue32259@psf.upfronthosting.co.za> Camion added the comment: By the way, I guess if the problem arises like that, it's because it might be hard to distinguish both situations at the interpreter level, but if it was possible, it would be the best solution to have a different error message (even if I understand we should be very careful with the idea of changing the exception type, even in this case). I mean : Eric shown an equivalent error, but both are only equivalent at the present discrimination level of the interpreter & language grammar. I understand that distinguishing both those semantically different situation might be opening the Pandora box and it might be a bad idea... or not. The point is that, if ever both those situations were in some way distinguishable, then... well... we certainly have no idea of how much code confronted with this specific situation AND treated it with exception handling, BUT, we might make the assumption that a frequent confrontation with this case would then already have been raised before, and consequently, it might be relevant, at least to keep it in mind for a future evolution (4.0) of the language. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 03:29:27 2017 From: report at bugs.python.org (Ivan Pozdeev) Date: Sun, 10 Dec 2017 08:29:27 +0000 Subject: [issue32266] test_pathlib fails if current path has junctions Message-ID: <1512894567.77.0.213398074469.issue32266@psf.upfronthosting.co.za> New submission from Ivan Pozdeev : On this machine, C:\Users is a junction to D:\Users . Sample failure: Running Release|x64 interpreter... ....FFF........s...s..s.s.s................s......FF..............ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss.........................................................................................................................................................................FFF........s...s..s.s.s................s......FF........... ====================================================================== FAIL: test_complex_symlinks_absolute (__main__.PathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib\test\test_pathlib.py", line 2027, in test_complex_symlinks_absolute self._check_complex_symlinks(BASE) File "Lib\test\test_pathlib.py", line 1994, in _check_complex_symlinks self.assertEqual(p, P) AssertionError: WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') ====================================================================== FAIL: test_complex_symlinks_relative (__main__.PathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib\test\test_pathlib.py", line 2031, in test_complex_symlinks_relative self._check_complex_symlinks('.') File "Lib\test\test_pathlib.py", line 1994, in _check_complex_symlinks self.assertEqual(p, P) AssertionError: WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') ====================================================================== FAIL: test_complex_symlinks_relative_dot_dot (__main__.PathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib\test\test_pathlib.py", line 2035, in test_complex_symlinks_relative_dot_dot self._check_complex_symlinks(os.path.join('dirA', '..')) File "Lib\test\test_pathlib.py", line 1994, in _check_complex_symlinks self.assertEqual(p, P) AssertionError: WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') ====================================================================== FAIL: test_resolve_common (__main__.PathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib\test\test_pathlib.py", line 1491, in test_resolve_common os.path.join(BASE, 'foo')) AssertionError: 'D:\\Users\\Ivan\\Documents\\cpython_all\\@test_2376_tmp\\foo' != 'C:\\Users\\Ivan\\Documents\\cpython_all\\@test_2376_tmp\\foo' - D:\Users\Ivan\Documents\cpython_all\@test_2376_tmp\foo ? ^ + C:\Users\Ivan\Documents\cpython_all\@test_2376_tmp\foo ? ^ ====================================================================== FAIL: test_resolve_dot (__main__.PathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib\test\test_pathlib.py", line 1550, in test_resolve_dot self.assertEqual(q.resolve(strict=True), p) AssertionError: WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') ====================================================================== FAIL: test_complex_symlinks_absolute (__main__.WindowsPathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib\test\test_pathlib.py", line 2027, in test_complex_symlinks_absolute self._check_complex_symlinks(BASE) File "Lib\test\test_pathlib.py", line 1994, in _check_complex_symlinks self.assertEqual(p, P) AssertionError: WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') ====================================================================== FAIL: test_complex_symlinks_relative (__main__.WindowsPathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib\test\test_pathlib.py", line 2031, in test_complex_symlinks_relative self._check_complex_symlinks('.') File "Lib\test\test_pathlib.py", line 1994, in _check_complex_symlinks self.assertEqual(p, P) AssertionError: WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') ====================================================================== FAIL: test_complex_symlinks_relative_dot_dot (__main__.WindowsPathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib\test\test_pathlib.py", line 2035, in test_complex_symlinks_relative_dot_dot self._check_complex_symlinks(os.path.join('dirA', '..')) File "Lib\test\test_pathlib.py", line 1994, in _check_complex_symlinks self.assertEqual(p, P) AssertionError: WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') ====================================================================== FAIL: test_resolve_common (__main__.WindowsPathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib\test\test_pathlib.py", line 1491, in test_resolve_common os.path.join(BASE, 'foo')) AssertionError: 'D:\\Users\\Ivan\\Documents\\cpython_all\\@test_2376_tmp\\foo' != 'C:\\Users\\Ivan\\Documents\\cpython_all\\@test_2376_tmp\\foo' - D:\Users\Ivan\Documents\cpython_all\@test_2376_tmp\foo ? ^ + C:\Users\Ivan\Documents\cpython_all\@test_2376_tmp\foo ? ^ ====================================================================== FAIL: test_resolve_dot (__main__.WindowsPathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib\test\test_pathlib.py", line 1550, in test_resolve_dot self.assertEqual(q.resolve(strict=True), p) AssertionError: WindowsPath('D:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') != WindowsPath('C:/Users/Ivan/Documents/cpython_all/@test_2376_tmp') ---------------------------------------------------------------------- Ran 394 tests in 2.215s FAILED (failures=10, skipped=112) ---------- components: Tests messages: 307945 nosy: Ivan.Pozdeev priority: normal severity: normal status: open title: test_pathlib fails if current path has junctions type: behavior versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 03:36:50 2017 From: report at bugs.python.org (Ivan Pozdeev) Date: Sun, 10 Dec 2017 08:36:50 +0000 Subject: [issue32266] test_pathlib fails if current path has junctions In-Reply-To: <1512894567.77.0.213398074469.issue32266@psf.upfronthosting.co.za> Message-ID: <1512895010.48.0.213398074469.issue32266@psf.upfronthosting.co.za> Change by Ivan Pozdeev : ---------- keywords: +patch pull_requests: +4679 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 04:03:12 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 10 Dec 2017 09:03:12 +0000 Subject: [issue32258] Rewrite asyncio docs to use async/await syntax In-Reply-To: <1512813975.64.0.213398074469.issue32258@psf.upfronthosting.co.za> Message-ID: <1512896592.94.0.213398074469.issue32258@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- keywords: +patch pull_requests: +4680 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 04:10:37 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Dec 2017 09:10:37 +0000 Subject: [issue30928] Copy modified blurbs to idlelib/NEWS.txt In-Reply-To: <1500004288.4.0.547702885246.issue30928@psf.upfronthosting.co.za> Message-ID: <1512897037.46.0.213398074469.issue30928@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4681 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 04:15:16 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Dec 2017 09:15:16 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512897316.26.0.213398074469.issue32259@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: My point is that the current error message is correct and is not misleading. And this is a standard error message raised in many other cases. There is no a bug. *Maybe* it can be improved in some specific cases. Do you want to provide a patch Steven? Without concrete patch the following discussion doesn't make sense. We even don't know if such patch is possible. ---------- versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 04:27:33 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 10 Dec 2017 09:27:33 +0000 Subject: [issue26858] setting SO_REUSEPORT fails at API 21 In-Reply-To: <1461677842.81.0.574068471289.issue26858@psf.upfronthosting.co.za> Message-ID: <1512898053.07.0.213398074469.issue26858@psf.upfronthosting.co.za> Xavier de Gaye added the comment: This problem does not occur at API 24. ---------- title: setting SO_REUSEPORT fails -> setting SO_REUSEPORT fails at API 21 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 04:30:59 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 10 Dec 2017 09:30:59 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1512898259.42.0.213398074469.issue26865@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Remove depencies that are not specific to Android. ---------- dependencies: -add the '--disable-test-suite' option to configure, add the '--enable-sourceless-distribution' option to configure, cross compilation of third-party extension modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 04:31:57 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 10 Dec 2017 09:31:57 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1512898317.51.0.213398074469.issue26865@psf.upfronthosting.co.za> Change by Xavier de Gaye : ---------- versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 04:35:42 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 10 Dec 2017 09:35:42 +0000 Subject: [issue32262] Fix linting errors in asyncio code; use f-strings consistently In-Reply-To: <1512861969.57.0.213398074469.issue32262@psf.upfronthosting.co.za> Message-ID: <1512898542.81.0.213398074469.issue32262@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Agree with Yury, at lease for asyncio library. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 04:48:37 2017 From: report at bugs.python.org (STINNER Victor) Date: Sun, 10 Dec 2017 09:48:37 +0000 Subject: [issue26858] setting SO_REUSEPORT fails at API 21 In-Reply-To: <1512898053.07.0.213398074469.issue26858@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Do we have a function in Python to get the running Android version? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 05:00:27 2017 From: report at bugs.python.org (Camion) Date: Sun, 10 Dec 2017 10:00:27 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512900027.91.0.213398074469.issue32259@psf.upfronthosting.co.za> Camion added the comment: Serhiy, I think I got a better understanding of what is happening. It is well described by the following example : >>> a, b = 1, Traceback (most recent call last): File "", line 1, in a, b = 1, ValueError: need more than 1 value to unpack >>> a, b = 1 Traceback (most recent call last): File "", line 1, in a, b = 1 TypeError: 'int' object is not iterable Again, the message might be correct, but in this case, the combination between the message and the ambiguous syntax, makes it lack from explicitness. Understanding that, I suggest to simply add "(expected 'tuple')" at the end of the message. ex : TypeError: 'int' object is not iterable (expected 'tuple') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 05:12:00 2017 From: report at bugs.python.org (Mario Corchero) Date: Sun, 10 Dec 2017 10:12:00 +0000 Subject: [issue32267] strptime misparses offsets with microsecond format Message-ID: <1512900720.16.0.213398074469.issue32267@psf.upfronthosting.co.za> New submission from Mario Corchero : At the moment strptime misparses all microsecond specifications that do not have exactly 6 digits as it is just converted into an int and considered microsecond. This bug was introduced with the implementation in bpo-31800 Example: _strptime._strptime("+01:30:30.001", "%z") == _strptime._strptime("+01:30:30.000001", "%z") ---------- components: Library (Lib) messages: 307952 nosy: mariocj89 priority: normal severity: normal status: open title: strptime misparses offsets with microsecond format type: behavior versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 05:14:17 2017 From: report at bugs.python.org (Mario Corchero) Date: Sun, 10 Dec 2017 10:14:17 +0000 Subject: [issue32267] strptime misparses offsets with microsecond format In-Reply-To: <1512900720.16.0.213398074469.issue32267@psf.upfronthosting.co.za> Message-ID: <1512900857.74.0.213398074469.issue32267@psf.upfronthosting.co.za> Change by Mario Corchero : ---------- keywords: +patch pull_requests: +4682 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 05:22:34 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 10 Dec 2017 10:22:34 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512897316.26.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <20171210102224.GF22248@ando.pearwood.info> Steven D'Aprano added the comment: On Sun, Dec 10, 2017 at 09:15:16AM +0000, Serhiy Storchaka wrote: > My point is that the current error message is correct and is not misleading. With respect Serhiy, in this bug report you have TWO PEOPLE who have said that it is misleading in this context -- the person who raised the bug report, and me. It might not be misleading to you, but it mislead us. I've been using Python for over a decade and a half, and when I read the exception it confused me too: why is the for loop trying to iterate over a Fraction? Did the generator accidentally call return instead of yield? I was especially confused because I was expecting a ValueError too many/too few values to unpack. Of course, with a bit more thought I realised that the error isn't generated by the for loop, but the unpacking. 15 years of reading exceptions does count for something :-) If you prefer "lacking sufficient information" over misleading, I won't disagree. Putting aside pointless quibbles over the exact wording of *why* the current error message is suboptimal, I hope that we can all agree that if the error occurs during an unpacking operation, the error message should preferably say that the object cannot be unpacked. Is there any advantage to not giving that information if we can? > And this is a standard error message raised in many other cases. There > is no a bug. I agreed that it isn't a bug, and changed this to an enhancement. Better error messages should be welcomed, not rejected because they aren't fixing a bug. > *Maybe* it can be improved in some specific cases. Do you want to > provide a patch Steven? Without concrete patch the following > discussion doesn't make sense. We even don't know if such patch is > possible. Someone who knows C and the interpreter internals better than me will have to provide a patch. I wouldn't even know where to start looking. But my guess would be the UNPACK_SEQUENCE op-code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 05:28:52 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sun, 10 Dec 2017 10:28:52 +0000 Subject: [issue19678] smtpd.py: channel should be passed to process_message In-Reply-To: <1385031410.17.0.520349427654.issue19678@psf.upfronthosting.co.za> Message-ID: <1512901732.94.0.213398074469.issue19678@psf.upfronthosting.co.za> Sanyam Khurana added the comment: Leslie, would you like to work on a patch for this? ---------- nosy: +CuriousLearner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 05:31:41 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 10 Dec 2017 10:31:41 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512900027.91.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <20171210103129.GG22248@ando.pearwood.info> Steven D'Aprano added the comment: On Sun, Dec 10, 2017 at 10:00:27AM +0000, Camion wrote: > Understanding that, I suggest to simply add "(expected 'tuple')" at the end of the message. > ex : TypeError: 'int' object is not iterable (expected 'tuple') That is incorrect: a tuple is not expected. Any iterable (sequence, iterator, tuple, list, set, frozenset, dict, etc) will do. One thing we should not do is give a misleading, overly-specific message that implies only a tuple will work. We could say TypeError: 'int' object is not iterable (expected iterable) but that's redundants, since the comment in the parentheses is implied by the fact that *not* being iterable is an error. I think the right thing to do here (if possible!) is to distinguish between unpacking and other iteration. E.g. for x in 20: ... => TypeError: 'int' object is not iterable a, b = 20 => TypeError: cannot unpack 'int' object (not iterable) or similar. I'm less concerned about the exact wording than the fact that we give a hint that it was the unpacking operation that failed, rather than iteration in some other context. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 05:37:36 2017 From: report at bugs.python.org (Christian Heimes) Date: Sun, 10 Dec 2017 10:37:36 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512902256.46.0.213398074469.issue32257@psf.upfronthosting.co.za> Christian Heimes added the comment: Sounds about right, but I cannot find a good way to disable renegotiation. * SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS doesn't look right. For one it's an internal, undocumented flag. But more important it is no longer supported in OpenSSL 1.1.0. * The info_callback trick does not work. The info callback cannot return an error indicator. In OpenSSL 1.1.0 the function signature is ``void (*cb) (const SSL *ssl, int type, int val)``, which means it cannot modify the SSL object in order to abort the connection forcefully. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 05:45:53 2017 From: report at bugs.python.org (Alexey Luchko) Date: Sun, 10 Dec 2017 10:45:53 +0000 Subject: [issue32268] quopri.decode(): string argument expected, got 'bytes' Message-ID: <1512902753.61.0.213398074469.issue32268@psf.upfronthosting.co.za> New submission from Alexey Luchko : $ python3 -c 'import io, quopri; quopri.decode(io.StringIO("some initial text data"), io.StringIO())' Traceback (most recent call last): File "", line 1, in File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/quopri.py", line 125, in decode output.write(odata) TypeError: string argument expected, got 'bytes' ---------- components: Library (Lib) messages: 307957 nosy: luch priority: normal severity: normal status: open title: quopri.decode(): string argument expected, got 'bytes' versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 06:13:59 2017 From: report at bugs.python.org (Christian Heimes) Date: Sun, 10 Dec 2017 11:13:59 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512904438.99.0.213398074469.issue32257@psf.upfronthosting.co.za> Christian Heimes added the comment: Apache mod_ssl implements CVE-2009-3555 by carefully tracking renegotiation state through-out the code base and a custom IO layer that refuses IO when the reneg_state becomes invalid. [1] https://github.com/apache/httpd/blob/trunk/modules/ssl/ssl_private.h#L502-L513 [2] https://github.com/apache/httpd/blob/trunk/modules/ssl/ssl_engine_io.c#L202-L250 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 08:41:42 2017 From: report at bugs.python.org (Christoph Reiter) Date: Sun, 10 Dec 2017 13:41:42 +0000 Subject: [issue32268] quopri.decode(): string argument expected, got 'bytes' In-Reply-To: <1512902753.61.0.213398074469.issue32268@psf.upfronthosting.co.za> Message-ID: <1512913302.22.0.213398074469.issue32268@psf.upfronthosting.co.za> Christoph Reiter added the comment: The documentation [0] states: "input and output must be binary file objects" and you are not passing a binary file object. [0] https://docs.python.org/3.6/library/quopri.html#quopri.decode ---------- nosy: +lazka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 09:24:43 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 10 Dec 2017 14:24:43 +0000 Subject: [issue26858] setting SO_REUSEPORT fails at API 21 In-Reply-To: <1461677842.81.0.574068471289.issue26858@psf.upfronthosting.co.za> Message-ID: <1512915883.84.0.213398074469.issue26858@psf.upfronthosting.co.za> Xavier de Gaye added the comment: This is issue 26855. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 12:08:44 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 10 Dec 2017 17:08:44 +0000 Subject: [issue32269] Add `asyncio.get_running_loop()` function Message-ID: <1512925724.74.0.213398074469.issue32269@psf.upfronthosting.co.za> New submission from Yury Selivanov : In many contexts `asyncio._get_running_loop()` is more useful than `asyncio.get_event_loop()`. The former function is predictable and simple, the latter can change its behaviour depending on the current policy and can even create new event loops. Both `asyncio._get_running_loop()` and `asyncio._set_running_loop()` are public asyncio API, although the leading underscore suggests that they are special and shouldn't be used by regular users. That's true for `asyncio._set_running_loop()`, which is intended to be used by event loops exclusively. I propose to remove the leading underscore from `asyncio._get_running_loop()`, making it `asyncio.get_running_loop()`, and thus promoting a safer alternative to `asyncio.get_event_loop()`. `asyncio._get_running_loop()` will be deprecated and removed in Python 3.9. ---------- assignee: yselivanov messages: 307961 nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Add `asyncio.get_running_loop()` function _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 12:08:56 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 10 Dec 2017 17:08:56 +0000 Subject: [issue32269] Add `asyncio.get_running_loop()` function In-Reply-To: <1512925724.74.0.213398074469.issue32269@psf.upfronthosting.co.za> Message-ID: <1512925736.14.0.213398074469.issue32269@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- components: +asyncio type: -> enhancement versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 12:14:06 2017 From: report at bugs.python.org (Alexey Izbyshev) Date: Sun, 10 Dec 2017 17:14:06 +0000 Subject: [issue32270] subprocess closes redirected fds even if they are in pass_fds Message-ID: <1512926046.73.0.213398074469.issue32270@psf.upfronthosting.co.za> New submission from Alexey Izbyshev : Demonstration: $ cat test.py import os import subprocess import sys fd = os.dup(sys.stdout.fileno()) subprocess.call([sys.executable, '-c', 'import sys;' 'print("Hello stdout");' 'print("Hello fd", file=open(int(sys.argv[1]), "w"))', str(fd)], stdout=fd, pass_fds=[fd]) $ python3 test.py Hello stdout Traceback (most recent call last): File "", line 1, in OSError: [Errno 9] Bad file descriptor I see two issues here: 1. The fact that file descriptors specified for redirection are closed (even with close_fds=False) unless in range [0, 2] is not documented and not tested. If I change the corresponding code in _posixsubprocess.c to close them only if they are ends of pipes created by subprocess itself, all tests still pass. Also, shells behave differently: e.g., in command 'echo 3>&1' fd 3 is duplicated but not closed in the child, so subprocess behavior may be not what people expect. 2. pass_fds interaction with (1) should be fixed and documented. We may either raise ValueError if pass_fds contains a redirected fd or don't close such a redirected fd. Please provide your thoughts. ---------- components: Library (Lib) files: test.py messages: 307962 nosy: gregory.p.smith, izbyshev, pitrou, vstinner priority: normal severity: normal status: open title: subprocess closes redirected fds even if they are in pass_fds type: behavior versions: Python 3.6, Python 3.7 Added file: https://bugs.python.org/file47329/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 12:31:15 2017 From: report at bugs.python.org (Qichao Chu) Date: Sun, 10 Dec 2017 17:31:15 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512927075.21.0.213398074469.issue32257@psf.upfronthosting.co.za> Qichao Chu added the comment: Thank you for the investigation. This does seem better than the flag. Shall we go ahead implement this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 12:32:05 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 10 Dec 2017 17:32:05 +0000 Subject: [issue32269] Add `asyncio.get_running_loop()` function In-Reply-To: <1512925724.74.0.213398074469.issue32269@psf.upfronthosting.co.za> Message-ID: <1512927125.4.0.213398074469.issue32269@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4683 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 12:35:01 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 10 Dec 2017 17:35:01 +0000 Subject: [issue32114] The get_event_loop change in bpo28613 did not update the documentation In-Reply-To: <1511375315.05.0.213398074469.issue32114@psf.upfronthosting.co.za> Message-ID: <1512927301.41.0.213398074469.issue32114@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 77106b2c21e59d0466742cc3afa50f9e8345e186 by Yury Selivanov (Pablo Galindo) in branch 'master': bpo-32114: Updated the documentation for get_event_loop to reflect the policy change (#4510) https://github.com/python/cpython/commit/77106b2c21e59d0466742cc3afa50f9e8345e186 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 12:35:19 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 10 Dec 2017 17:35:19 +0000 Subject: [issue32114] The get_event_loop change in bpo28613 did not update the documentation In-Reply-To: <1511375315.05.0.213398074469.issue32114@psf.upfronthosting.co.za> Message-ID: <1512927319.07.0.213398074469.issue32114@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 12:39:10 2017 From: report at bugs.python.org (Christian Heimes) Date: Sun, 10 Dec 2017 17:39:10 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512927549.99.0.213398074469.issue32257@psf.upfronthosting.co.za> Christian Heimes added the comment: There must be a better way than custom BIOs. An implemented based on Apache's approach is probably > 1,000 lines of C code and a massive compliciation of the module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 12:43:42 2017 From: report at bugs.python.org (Qichao Chu) Date: Sun, 10 Dec 2017 17:43:42 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512927822.17.0.213398074469.issue32257@psf.upfronthosting.co.za> Qichao Chu added the comment: How about exposing the internal ssl object? This will allow applications to control the flag. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 13:38:47 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 10 Dec 2017 18:38:47 +0000 Subject: [issue32270] subprocess closes redirected fds even if they are in pass_fds In-Reply-To: <1512926046.73.0.213398074469.issue32270@psf.upfronthosting.co.za> Message-ID: <1512931127.15.0.213398074469.issue32270@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the report and the investigation! > 1. The fact that file descriptors specified for redirection are closed (even with close_fds=False) unless in range [0, 2] is not documented and not tested. That sounds like a bug to me, so we should fix it if decently possible. > 2. pass_fds interaction with (1) should be fixed and documented. We may either raise ValueError if pass_fds contains a redirected fd or don't close such a redirected fd. Same here, it seems like a bug which deserves fixing. Do you want to submit a PR for this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 13:44:01 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 10 Dec 2017 18:44:01 +0000 Subject: [issue32236] open() shouldn't silently ignore buffering=1 in binary mode In-Reply-To: <1512604009.3.0.213398074469.issue32236@psf.upfronthosting.co.za> Message-ID: <1512931441.82.0.213398074469.issue32236@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I suggest to raise a ValueError if buffering=1 is used for binary mode. Either that, or we instead accept buffering=1 as a regular buffer size. But since buffering=1 means something else for text mode, maybe you're right that it's better to raise in binary mode, to avoid any possible confusion. ---------- nosy: +benjamin.peterson, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 13:52:01 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 10 Dec 2017 18:52:01 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512931921.6.0.213398074469.issue32259@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think the current error message should stay as is. The interpreter is in no position to guess what kind of iterable may have been intended. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 13:54:34 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Sun, 10 Dec 2017 18:54:34 +0000 Subject: [issue29302] add contextlib.AsyncExitStack In-Reply-To: <1484693382.32.0.211448130443.issue29302@psf.upfronthosting.co.za> Message-ID: <1512932074.68.0.213398074469.issue29302@psf.upfronthosting.co.za> Cheryl Sabella added the comment: Alexander, Did you want to submit a PR for this? ---------- nosy: +csabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 13:55:22 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Sun, 10 Dec 2017 18:55:22 +0000 Subject: [issue29302] add contextlib.AsyncExitStack In-Reply-To: <1484693382.32.0.211448130443.issue29302@psf.upfronthosting.co.za> Message-ID: <1512932122.32.0.213398074469.issue29302@psf.upfronthosting.co.za> Change by Cheryl Sabella : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 14:08:38 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 10 Dec 2017 19:08:38 +0000 Subject: [issue24991] Define instance mutability explicitly on type objects? In-Reply-To: <1441260483.41.0.785006760825.issue24991@psf.upfronthosting.co.za> Message-ID: <1512932918.91.0.213398074469.issue24991@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think this is a hazardous path that should be avoided. Mutability is an elusive concept that is hard to pin down. Files are immutable when opened in a read-only mode and mutable if opened in a write mode. Tuples are immutable but may contain mutable elements. Tuples are immutable to Python programmers but fully mutable to C programmers. Some objects have some fields than can be mutated and some that can't. Regular Python classes are always mutable in the sense that there is usually some path to changing almost everything even if __setattr__ has been overridden. It is more a matter of convention (public API) than a technical point. I prefer that Python be left as a "consenting adults" language rather than go down this precarious path. For comparison, think about the issue of constants in Python. A constant is just a variable that by convention you don't change. It isn't declared or enforced, yet for the most part this is just fine. ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 14:12:15 2017 From: report at bugs.python.org (Amit Ghadge) Date: Sun, 10 Dec 2017 19:12:15 +0000 Subject: [issue32271] test_ssl test failed on Fedora 27 Message-ID: <1512933135.19.0.213398074469.issue32271@psf.upfronthosting.co.za> New submission from Amit Ghadge : I cloned Python repo on my machine, below command run successfully, $ ./configure --with-pydebug && make -j But When I was run $./python -m test test_ssl failed, 0:08:44 load avg: 4.65 [303/406/1] test_ssl failed Exception in thread Thread-85: Traceback (most recent call last): File "/home/aghadge/my/Open_Source/cpython/Lib/threading.py", line 917, in _bootstrap_inner self.run() File "/home/aghadge/my/Open_Source/cpython/Lib/test/test_ssl.py", line 1936, in run if not self.wrap_conn(): File "/home/aghadge/my/Open_Source/cpython/Lib/test/test_ssl.py", line 1881, in wrap_conn self.sock, server_side=True) File "/home/aghadge/my/Open_Source/cpython/Lib/ssl.py", line 401, in wrap_socket _context=self, _session=session) File "/home/aghadge/my/Open_Source/cpython/Lib/ssl.py", line 808, in __init__ self.do_handshake() File "/home/aghadge/my/Open_Source/cpython/Lib/ssl.py", line 1061, in do_handshake self._sslobj.do_handshake() File "/home/aghadge/my/Open_Source/cpython/Lib/ssl.py", line 683, in do_handshake self._sslobj.do_handshake() OSError: [Errno 0] Error test test_ssl failed -- Traceback (most recent call last): File "/home/aghadge/my/Open_Source/cpython/Lib/test/test_ssl.py", line 3273, in test_alpn_protocols self.assertIsInstance(stats, ssl.SSLError) AssertionError: {'compression': None, 'cipher': ('ECDHE-RSA-AES256-GCM-SHA384', 'TLSv1.2', 256), 'peercert': {}, 'client_alpn_protocol': None, 'client_npn_protocol': None, 'version': 'TLSv1.2', 'session_reused': False, 'session': <_ssl.Session object at 0x7f8acc86d608>, 'server_alpn_protocols': [None], 'server_npn_protocols': [None], 'server_shared_ciphers': [[('ECDHE-ECDSA-AES256-GCM-SHA384', 'TLSv1.2', 256), ('ECDHE-RSA-AES256-GCM-SHA384', 'TLSv1.2', 256), ('ECDHE-ECDSA-AES128-GCM-SHA256', 'TLSv1.2', 128), ('ECDHE-RSA-AES128-GCM-SHA256', 'TLSv1.2', 128), ('ECDHE-ECDSA-CHACHA20-POLY1305', 'TLSv1.2', 256), ('ECDHE-RSA-CHACHA20-POLY1305', 'TLSv1.2', 256), ('DHE-DSS-AES256-GCM-SHA384', 'TLSv1.2', 256), ('DHE-RSA-AES256-GCM-SHA384', 'TLSv1.2', 256), ('DHE-DSS-AES128-GCM-SHA256', 'TLSv1.2', 128), ('DHE-RSA-AES128-GCM-SHA256', 'TLSv1.2', 128), ('DHE-RSA-CHACHA20-POLY1305', 'TLSv1.2', 256), ('ECDHE-ECDSA-AES256-CCM8', 'TLSv1.2', 256), ('ECDHE-ECDSA-AES256-CCM', 'TLSv1.2', 256), ('ECDHE-ECDSA-AES256-SHA384', 'TLSv1.2', 256), ('ECDHE-RSA-AES256-SHA384', 'TLSv1.2', 256), ('ECDHE-ECDSA-AES256-SHA', 'TLSv1.0', 256), ('ECDHE-RSA-AES256-SHA', 'TLSv1.0', 256), ('DHE-RSA-AES256-CCM8', 'TLSv1.2', 256), ('DHE-RSA-AES256-CCM', 'TLSv1.2', 256), ('DHE-RSA-AES256-SHA256', 'TLSv1.2', 256), ('DHE-DSS-AES256-SHA256', 'TLSv1.2', 256), ('DHE-RSA-AES256-SHA', 'SSLv3', 256), ('DHE-DSS-AES256-SHA', 'SSLv3', 256), ('ECDHE-ECDSA-AES128-CCM8', 'TLSv1.2', 128), ('ECDHE-ECDSA-AES128-CCM', 'TLSv1.2', 128), ('ECDHE-ECDSA-AES128-SHA256', 'TLSv1.2', 128), ('ECDHE-RSA-AES128-SHA256', 'TLSv1.2', 128), ('ECDHE-ECDSA-AES128-SHA', 'TLSv1.0', 128), ('ECDHE-RSA-AES128-SHA', 'TLSv1.0', 128), ('DHE-RSA-AES128-CCM8', 'TLSv1.2', 128), ('DHE-RSA-AES128-CCM', 'TLSv1.2', 128), ('DHE-RSA-AES128-SHA256', 'TLSv1.2', 128), ('DHE-DSS-AES128-SHA256', 'TLSv1.2', 128), ('DHE-RSA-AES128-SHA', 'SSLv3', 128), ('DHE-DSS-AES128-SHA', 'SSLv3', 128), ('ECDHE-ECDSA-CAMELLIA256-SHA384', 'TLSv1.2', 256), ('ECDHE-RSA-CAMELLIA256-SHA384', 'TLSv1.2', 256), ('ECDHE-ECDSA-CAMELLIA128-SHA256', 'TLSv1.2', 128), ('ECDHE-RSA-CAMELLIA128-SHA256', 'TLSv1.2', 128), ('DHE-RSA-CAMELLIA256-SHA256', 'TLSv1.2', 256), ('DHE-DSS-CAMELLIA256-SHA256', 'TLSv1.2', 256), ('DHE-RSA-CAMELLIA128-SHA256', 'TLSv1.2', 128), ('DHE-DSS-CAMELLIA128-SHA256', 'TLSv1.2', 128), ('DHE-RSA-CAMELLIA256-SHA', 'SSLv3', 256), ('DHE-DSS-CAMELLIA256-SHA', 'SSLv3', 256), ('DHE-RSA-CAMELLIA128-SHA', 'SSLv3', 128), ('DHE-DSS-CAMELLIA128-SHA', 'SSLv3', 128), ('AES256-GCM-SHA384', 'TLSv1.2', 256), ('AES128-GCM-SHA256', 'TLSv1.2', 128), ('AES256-CCM8', 'TLSv1.2', 256), ('AES256-CCM', 'TLSv1.2', 256), ('AES128-CCM8', 'TLSv1.2', 128), ('AES128-CCM', 'TLSv1.2', 128), ('AES256-SHA256', 'TLSv1.2', 256), ('AES128-SHA256', 'TLSv1.2', 128), ('AES256-SHA', 'SSLv3', 256), ('AES128-SHA', 'SSLv3', 128), ('CAMELLIA256-SHA256', 'TLSv1.2', 256), ('CAMELLIA128-SHA256', 'TLSv1.2', 128), ('CAMELLIA256-SHA', 'SSLv3', 256), ('CAMELLIA128-SHA', 'SSLv3', 128)]]} is not an instance of ---------- assignee: christian.heimes components: SSL messages: 307972 nosy: amitg-b14, christian.heimes priority: normal severity: normal status: open title: test_ssl test failed on Fedora 27 versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 14:18:20 2017 From: report at bugs.python.org (Christian Heimes) Date: Sun, 10 Dec 2017 19:18:20 +0000 Subject: [issue32271] test_ssl test failed on Fedora 27 In-Reply-To: <1512933135.19.0.213398074469.issue32271@psf.upfronthosting.co.za> Message-ID: <1512933500.0.0.213398074469.issue32271@psf.upfronthosting.co.za> Christian Heimes added the comment: All ssl tests are passing for me on Fedora 27 with openssl-1.1.0g-1.fc27.x86_64 and latest HEAD of master. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 14:32:22 2017 From: report at bugs.python.org (Amit Ghadge) Date: Sun, 10 Dec 2017 19:32:22 +0000 Subject: [issue32271] test_ssl test failed on Fedora 27 In-Reply-To: <1512933135.19.0.213398074469.issue32271@psf.upfronthosting.co.za> Message-ID: <1512934342.61.0.213398074469.issue32271@psf.upfronthosting.co.za> Amit Ghadge added the comment: My Openssl version is, OpenSSL 1.1.0g-fips 2 Nov 2017 So, that need to be upgrade Openssl?. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 14:36:04 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 10 Dec 2017 19:36:04 +0000 Subject: [issue32263] Template string docs refer to "normal %-based substitutions" In-Reply-To: <1512855398.42.0.213398074469.issue32263@psf.upfronthosting.co.za> Message-ID: <1512934564.08.0.213398074469.issue32263@psf.upfronthosting.co.za> Raymond Hettinger added the comment: We can remove the word "normal" but otherwise the docs read fairly well. FWIW, when there docs were written, the {} new-style string formatting didn't exist, so the wording was reasonable at the time. ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 14:36:54 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Dec 2017 19:36:54 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512934614.18.0.213398074469.issue32259@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: My objections were about the original report. The title of this issue still implies there is a bug that is not true. You proposition Steve may make sense, but we need a concrete code for discussing the advantages and the drawbacks of this change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 14:37:07 2017 From: report at bugs.python.org (Anthony Sottile) Date: Sun, 10 Dec 2017 19:37:07 +0000 Subject: [issue31940] copystat on symlinks fails for alpine -- faulty lchmod implementation? In-Reply-To: <1509753073.77.0.213398074469.issue31940@psf.upfronthosting.co.za> Message-ID: <1512934627.0.0.213398074469.issue31940@psf.upfronthosting.co.za> Change by Anthony Sottile : ---------- pull_requests: +4684 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 14:37:10 2017 From: report at bugs.python.org (Christian Heimes) Date: Sun, 10 Dec 2017 19:37:10 +0000 Subject: [issue32271] test_ssl test failed on Fedora 27 In-Reply-To: <1512933135.19.0.213398074469.issue32271@psf.upfronthosting.co.za> Message-ID: <1512934630.78.0.213398074469.issue32271@psf.upfronthosting.co.za> Christian Heimes added the comment: What's your package version? Please post the output of 'rpm -qa openssl'. Please also try to build and compile from scratch: $ make clean $ ./configure --with-pydebug $ make $ ./python -m test -v test_ssl ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 14:39:04 2017 From: report at bugs.python.org (Amit Ghadge) Date: Sun, 10 Dec 2017 19:39:04 +0000 Subject: [issue32271] test_ssl test failed on Fedora 27 In-Reply-To: <1512933135.19.0.213398074469.issue32271@psf.upfronthosting.co.za> Message-ID: <1512934744.55.0.213398074469.issue32271@psf.upfronthosting.co.za> Amit Ghadge added the comment: $ rpm -qa openssl openssl-1.1.0g-1.fc27.x86_64 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 14:42:23 2017 From: report at bugs.python.org (Christian Heimes) Date: Sun, 10 Dec 2017 19:42:23 +0000 Subject: [issue32271] test_ssl test failed on Fedora 27 In-Reply-To: <1512933135.19.0.213398074469.issue32271@psf.upfronthosting.co.za> Message-ID: <1512934943.49.0.213398074469.issue32271@psf.upfronthosting.co.za> Christian Heimes added the comment: Same for me, are you on latest HEAD of master? The latest commit is: $ git log -1 commit c4d9df5fd719ad08e68e0950ce22a80f43e4f35d (HEAD -> master, upstream/master, upstream/HEAD) Author: Yury Selivanov Date: Sun Dec 10 12:40:19 2017 -0500 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 14:46:53 2017 From: report at bugs.python.org (Amit Ghadge) Date: Sun, 10 Dec 2017 19:46:53 +0000 Subject: [issue32271] test_ssl test failed on Fedora 27 In-Reply-To: <1512933135.19.0.213398074469.issue32271@psf.upfronthosting.co.za> Message-ID: <1512935213.16.0.213398074469.issue32271@psf.upfronthosting.co.za> Amit Ghadge added the comment: Recompile source but this test failed again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 14:54:27 2017 From: report at bugs.python.org (Amit Ghadge) Date: Sun, 10 Dec 2017 19:54:27 +0000 Subject: [issue32271] test_ssl test failed on Fedora 27 In-Reply-To: <1512933135.19.0.213398074469.issue32271@psf.upfronthosting.co.za> Message-ID: <1512935667.66.0.213398074469.issue32271@psf.upfronthosting.co.za> Amit Ghadge added the comment: No, I'm not on latest commit, $ git log -1 commit 3b0f620c1a2a21272a9e2aeca6ca1d1ac10f8162 (HEAD -> master, origin/master, origin/HEAD) Author: Louie Lu Date: Thu Aug 10 08:58:13 2017 +0800 bpo-19903: IDLE: Calltips changed to use inspect.signature (#2822) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 15:00:05 2017 From: report at bugs.python.org (Christian Heimes) Date: Sun, 10 Dec 2017 20:00:05 +0000 Subject: [issue32271] test_ssl test failed on Fedora 27 In-Reply-To: <1512933135.19.0.213398074469.issue32271@psf.upfronthosting.co.za> Message-ID: <1512936005.91.0.213398074469.issue32271@psf.upfronthosting.co.za> Christian Heimes added the comment: Please update. The problem was fixed in 7b40cb7293cb14e5c7c8ed123efaf9acb33edae2. ---------- resolution: -> out of date stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 15:21:26 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Sun, 10 Dec 2017 20:21:26 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512937286.84.0.213398074469.issue32257@psf.upfronthosting.co.za> Nathaniel Smith added the comment: It looks like openssl master has SSL_OP_NO_RENEGOTIATION: https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html Before that, I guess one could use SSL_CTX_sess_{connect,accept}_renegotiate to detect when a renegotiation has occurred and then error out? Admittedly this is more effective in nonblocking or memorybio mode. Or you could do something similar with the info callback: allow the current operation to succeed, but mark the connection as "poisoned". (Heck, in socket bio mode you could flat out close the socket. That'll shut things down.) For bonus annoyance, note that RFC 7240 does allow implementations to support renegotiation that happens before any data is exchanged, to allow for the encrypted client cert hack. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 15:29:10 2017 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Dec 2017 20:29:10 +0000 Subject: [issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n' In-Reply-To: <1512744234.4.0.213398074469.issue32255@psf.upfronthosting.co.za> Message-ID: <1512937750.2.0.213398074469.issue32255@psf.upfronthosting.co.za> R. David Murray added the comment: The second case is indeed the bug, as can be seen by running the examples against python2.7. It looks like this was probably broken by 7901b48a1f89 from issue 23171. ---------- components: +Library (Lib) -IO nosy: +r.david.murray stage: patch review -> needs patch versions: -Python 2.7, Python 3.4, Python 3.5, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 15:30:56 2017 From: report at bugs.python.org (Amit Ghadge) Date: Sun, 10 Dec 2017 20:30:56 +0000 Subject: [issue32271] test_ssl test failed on Fedora 27 In-Reply-To: <1512933135.19.0.213398074469.issue32271@psf.upfronthosting.co.za> Message-ID: <1512937856.05.0.213398074469.issue32271@psf.upfronthosting.co.za> Amit Ghadge added the comment: I get the latest changes but now facing with different issue. ---------- resolution: out of date -> status: closed -> open type: behavior -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 15:31:03 2017 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Dec 2017 20:31:03 +0000 Subject: [issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n' In-Reply-To: <1512744234.4.0.213398074469.issue32255@psf.upfronthosting.co.za> Message-ID: <1512937863.3.0.213398074469.issue32255@psf.upfronthosting.co.za> R. David Murray added the comment: Serhiy, since it was your patch that probably introduced this bug, can you take a look? Obviously it isn't a very high priority bug, since no one has reported a problem (even this issue isn't reporting the change in behavior as a *problem* :) ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 15:37:19 2017 From: report at bugs.python.org (Camion) Date: Sun, 10 Dec 2017 20:37:19 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512938239.88.0.213398074469.issue32259@psf.upfronthosting.co.za> Camion added the comment: @Serhiy : I asked you to explain by what mean you supported the affirmation that our feeling (that the current message can be misleading in the specific situation) is wrong, but you didn't give us any element to understand your position. Steven and I did it: I gave you a sample code showing how and why a situation could be misinterpreted in regard of the current message, and Steven explained that as an experience python programmer, he experienced the same misunderstanding (I'm also an experienced programmer: started in the eighties, I'm new in Python only). May be, if you gave us some sound argument element, we could also better understand the reason why you affirm that our feeling is wrong. Because in the current situation, you only declared your own feeling, but didn't give it any support, and all we can conclude is that you are a very experienced python programmer who can understand what was beyond the text of the message, but it seems in contradiction with the principle of making things clear. -------------------- @Raymond : I do not understand how you make the link between both your affirmations. The initial problem is related with the fact that in some situation, the error message lead to think that there is a problem with the loop/generator/iterator, where the problem is in reality with a simple type which cannot be unpacked or iterated. Let's assume that the interpreter could never make the difference. In what way, does it support the fact that the message shouldn't in any way, hint the programmer on the fact that the problem is not with the generator/iterator/loop, but with the returned type ? -------------------- @Steven (& everybody), How about : "[TYPE] object is not iterable/unpackable" ? -------------------- About patching the sources in c, the message "object is not iterable" appears in four places in the version 3.6.3 : in ./Objects/object.c:1023, twice in ./Objects/typeobject.c (lines 6329 & 6344), and in ./Objects/abstract.c:3135. I have patched them to make them recognizable from one another, and it appear that all observed messages have been generated from abstract.c:3135 (in 3.6.3) and not from the other lines. This poses problem, because not even the regression test show a case where those other 3 parts of the code are used, and I haven't figured out (yet?) what condition makes them occur. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 15:51:54 2017 From: report at bugs.python.org (Christian Heimes) Date: Sun, 10 Dec 2017 20:51:54 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512939114.45.0.213398074469.issue32257@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks for checking! I had only checked 1.0.2 and 1.1.0 branch... I can easily expose the info cb in Python -- but there is no simple way to bubble up an exception from a callback to Python. The server name callback ignores exception and just prints them with PyErr_WriteUnraisable(). Since OpenSSL 1.1.1 will have SSL_OP_NO_RENEGOTIATION, I'm leaning towards not making the code more complicated. Either we have to wait for 1.1.1 or ask OpenSSL to backport the feature to 1.0.2 and 1.1.0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 15:59:18 2017 From: report at bugs.python.org (Christian Heimes) Date: Sun, 10 Dec 2017 20:59:18 +0000 Subject: [issue32271] test_ssl test failed on Fedora 27 In-Reply-To: <1512933135.19.0.213398074469.issue32271@psf.upfronthosting.co.za> Message-ID: <1512939558.24.0.213398074469.issue32271@psf.upfronthosting.co.za> Christian Heimes added the comment: This is a bug tracker, not a support forum. If you are having trouble compiling and testing CPython, please use the Python users mailing list or IRC (#python on freenode). ---------- assignee: christian.heimes -> resolution: -> out of date status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 16:04:22 2017 From: report at bugs.python.org (Amit Ghadge) Date: Sun, 10 Dec 2017 21:04:22 +0000 Subject: [issue32271] test_ssl test failed on Fedora 27 In-Reply-To: <1512933135.19.0.213398074469.issue32271@psf.upfronthosting.co.za> Message-ID: <1512939862.5.0.213398074469.issue32271@psf.upfronthosting.co.za> Amit Ghadge added the comment: Thanks, Christian for your help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 16:15:55 2017 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Dec 2017 21:15:55 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512940555.89.0.213398074469.issue32259@psf.upfronthosting.co.za> R. David Murray added the comment: > How about "[TYPE] object is not iterable/unpackable" I just grepped the docs, and the term 'unpackable' does not appear anywhere in them. I don't think this would be an improvement. As for the earlier suggestion of adding "expected tuple" does not work, because it is not a tuple being expected, it is an iterable, and saying "expected iterable" would be redundant with saying "is not iterable". What about "TypeError: expected iterable but found "? That's parallel to some other type error messages we already generate. Would that be any clearer? (I'm not sure it would be, it says the same thing.) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 16:19:12 2017 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Dec 2017 21:19:12 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512940752.65.0.213398074469.issue32259@psf.upfronthosting.co.za> R. David Murray added the comment: I shouldn't have searched the docs for 'unpackable', I should have searched for 'unpack'. Doing that reveals that the term 'unpack' is used for other concepts, whereas the term 'iterable' is precise. So I think it would unacceptably lower the precision of the error message to add that word. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 16:27:16 2017 From: report at bugs.python.org (Fipaddict) Date: Sun, 10 Dec 2017 21:27:16 +0000 Subject: [issue1410680] Add 'surgical editing' to ConfigParser Message-ID: <1512941236.7.0.213398074469.issue1410680@psf.upfronthosting.co.za> Change by Fipaddict : ---------- nosy: +fipaddict _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 16:30:04 2017 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Dec 2017 21:30:04 +0000 Subject: [issue32267] strptime misparses offsets with microsecond format In-Reply-To: <1512900720.16.0.213398074469.issue32267@psf.upfronthosting.co.za> Message-ID: <1512941404.96.0.213398074469.issue32267@psf.upfronthosting.co.za> Change by R. David Murray : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 16:35:05 2017 From: report at bugs.python.org (Nitish) Date: Sun, 10 Dec 2017 21:35:05 +0000 Subject: [issue32270] subprocess closes redirected fds even if they are in pass_fds In-Reply-To: <1512926046.73.0.213398074469.issue32270@psf.upfronthosting.co.za> Message-ID: <1512941705.15.0.213398074469.issue32270@psf.upfronthosting.co.za> Change by Nitish : ---------- nosy: +nitishch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 16:40:18 2017 From: report at bugs.python.org (R. David Murray) Date: Sun, 10 Dec 2017 21:40:18 +0000 Subject: [issue32268] quopri.decode(): string argument expected, got 'bytes' In-Reply-To: <1512902753.61.0.213398074469.issue32268@psf.upfronthosting.co.za> Message-ID: <1512942018.23.0.213398074469.issue32268@psf.upfronthosting.co.za> R. David Murray added the comment: Right, this is not a bug, it is working as documented. You could submit an enhancement request, but I'm surprised to find that anyone is actually using that module :) We unfortunately have multiple implementations of quoted printable handling in the stdlib. You might be interested in the functions in the binascii module, which do accept unicode input when doing decoding. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 16:47:16 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 10 Dec 2017 21:47:16 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512942436.98.0.213398074469.issue32259@psf.upfronthosting.co.za> Raymond Hettinger added the comment: @Camion, please adopt a less insistent tone. We've devoting time and thought to your concerns but are under no obligation to make a change just because you are demanding it. Part of learning any programming language is learning to reason from error message to root cause. Good error messages help, but they don't eliminate the underlying not always comfortable path of learning the world-view of the language and its mechanisms. That is partly why the devguide includes this passage, "Be careful accepting requests for documentation changes from the rare but vocal category of reader who is looking for vindication for one of their programming errors". A instructor for several thousand engineers, I've not encountered a single case where the current message has been problematic, nor have we had tracker issue arise over Python's 27 year history. And so far all the proposed wording changes make the message less accurate in other contexts where the message might arise. Based on that and on the comments by the other respondents, it would reasonable to close this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 17:03:36 2017 From: report at bugs.python.org (Alexey Izbyshev) Date: Sun, 10 Dec 2017 22:03:36 +0000 Subject: [issue32270] subprocess closes redirected fds even if they are in pass_fds In-Reply-To: <1512926046.73.0.213398074469.issue32270@psf.upfronthosting.co.za> Message-ID: <1512943416.02.0.213398074469.issue32270@psf.upfronthosting.co.za> Alexey Izbyshev added the comment: Regarding fixing (1), I'm worrying about backward compatibility a bit. Some people who discovered that behavior might rely on such "move" semantics and expect that the redirected descriptor is not leaked into the child. OTOH, since descriptors are non-inheritable by default since 3.4, it might be less of an issue now. What do you think? Otherwise, yes, I'd like to fix this, but fixing is a bit trickier than it may seem because sometimes descriptors are duplicated in _posixsubprocess.c (in case of low fds), so we need to track the ownership properly. I've already performed some work and discovered another issue: in a corner case involving closed standard fds, pipes created by subprocess may leak into the child and/or an incorrect redirection may occur. Since I can't completely fix this issue without affecting a discovered one, I think I'll do the opposite: file a new issue, fix it, and then go back to this one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 17:10:57 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 10 Dec 2017 22:10:57 +0000 Subject: [issue32263] Template string docs refer to "normal %-based substitutions" In-Reply-To: <1512934564.08.0.213398074469.issue32263@psf.upfronthosting.co.za> Message-ID: <49289BD8-F53F-474D-9C3A-B2757B4BC6C6@python.org> Barry A. Warsaw added the comment: On Dec 10, 2017, at 14:36, Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > > We can remove the word "normal" but otherwise the docs read fairly well. +1 > FWIW, when there docs were written, the {} new-style string formatting didn't exist, so the wording was reasonable at the time. Exactly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 17:25:42 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Dec 2017 22:25:42 +0000 Subject: [issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n' In-Reply-To: <1512744234.4.0.213398074469.issue32255@psf.upfronthosting.co.za> Message-ID: <1512944742.26.0.213398074469.issue32255@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For restoring the 3.4 behavior the single empty field must be quoted. This allows to distinguish a 1-element row with the single empty field from an empty row. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 17:31:44 2017 From: report at bugs.python.org (Decorater) Date: Sun, 10 Dec 2017 22:31:44 +0000 Subject: [issue32217] freeze.py fails to work. In-Reply-To: <1512440101.88.0.213398074469.issue32217@psf.upfronthosting.co.za> Message-ID: <1512945104.9.0.213398074469.issue32217@psf.upfronthosting.co.za> Decorater added the comment: After thinking about this, maybe a better aproach is to somehow make freeze when used on windows somehow read pyconfig.h ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 17:54:01 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Dec 2017 22:54:01 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512946441.67.0.213398074469.issue32259@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Camion, the problem is not in the error message. The problem is in the complex expression that produces an error. If you have a complex expression you always have a change to misidentify the source of error. In your case the expression contains two implicit iter() invocations. I have looked at the code. It is possible to make the error message in this case more specific. There are precedences of this when pass wrong type as var-positional or var-keyword arguments: >>> print(*1) Traceback (most recent call last): File "", line 1, in TypeError: print() argument after * must be an iterable, not int >>> print(**1) Traceback (most recent call last): File "", line 1, in TypeError: print() argument after ** must be a mapping, not int In the following cases the error message is general. It is possible to make it more specific. >>> a, b = 1 Traceback (most recent call last): File "", line 1, in TypeError: 'int' object is not iterable >>> [*1] Traceback (most recent call last): File "", line 1, in TypeError: 'int' object is not iterable >>> {*1} Traceback (most recent call last): File "", line 1, in TypeError: 'int' object is not iterable >>> {**1} Traceback (most recent call last): File "", line 1, in TypeError: 'int' object is not a mapping But PyObject_GetIter() is called in 88 places in CPython core and extensions. In all these cases we can make error messages more specific. But I have large doubts that it is worth to do. And I'm not sure even about the above examples. If somebody provide a patch we could discuss it (I'm not sure it will be accepted at end). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 18:01:09 2017 From: report at bugs.python.org (Alexey Izbyshev) Date: Sun, 10 Dec 2017 23:01:09 +0000 Subject: [issue32236] open() shouldn't silently ignore buffering=1 in binary mode In-Reply-To: <1512604009.3.0.213398074469.issue32236@psf.upfronthosting.co.za> Message-ID: <1512946869.24.0.213398074469.issue32236@psf.upfronthosting.co.za> Alexey Izbyshev added the comment: I'm in favor of raising an exception because it'll expose existing code with incorrect assumptions. I'll check whether it breaks any tests and submit a PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 18:11:59 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 10 Dec 2017 23:11:59 +0000 Subject: [issue32234] Add context management to mailbox.Mailbox In-Reply-To: <1512574106.47.0.213398074469.issue32234@psf.upfronthosting.co.za> Message-ID: <1512947519.97.0.213398074469.issue32234@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: It's possible that the Mailman example can just assume that the mailbox will be flushed and unlocked on __exit__(), so it could just call .close(). Then the question is whether entering the CM should lock the mailbox. The two cases are: 1. It doesn't, so you'd have to do: with mbox(...) as mb: mb.lock() # ... 2. It does, so if for some reason you didn't want the lock, you'd have to: with mbox(...) as mb: mb.unlock() We *could* add a `lock` argument to the constructor to take the ambiguity away. But I would claim that it doesn't make much sense to acquire an mbox in a CM and *not* lock it. The idiom says to me "I want to do things to the mbox, exclusively, and if that requires locking it, JFDI". So I would argue that the __enter__() should acquire the lock by default if the underlying mailbox supports it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 18:14:39 2017 From: report at bugs.python.org (Camion) Date: Sun, 10 Dec 2017 23:14:39 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512947679.37.0.213398074469.issue32259@psf.upfronthosting.co.za> Camion added the comment: @Raymond: I know that you have no obligation to make changes just because I'm demanding them and that's why I'm just trying to convince people of the validity of my observations, here. I apologize if my tone may seem "insistent", but please take in account than English is not my mother tongue. I agree with the fact that part of learning a language is learning to reason from error message to root cause but I cannot ignore that Python's Zen asks for explicitness, and Steven agreed with that this situation was tricky to interpret. It would be sly to suggest I'm be looking for vindication for one of my own programming errors. I'm experienced enough in trouble-shooting to have solved it by myself. It's just that I do not believe normal that this situation took me so much time and energy to solve from the error message **in regard with other similar situations**. -------------------- @David : What other contexts are you talking about ? Instead of looking in the documentation which also talks about e.g.:unpacking archive files, You should probably grep the source code for strings containing the word unpack and it will show you that the word unpack is used in contexts fully related with the error in my example. (SEARCH='".*unpack.*"'; find -name '*.c' -print0 | xargs -0 grep -li "$SEARCH" | while read F; do echo "$F" | sed 'p;s/./-/g'; grep -niC 5 "$SEARCH" "$F"; done) | less -------------------- I don't know about what would be the right error message, but since I experimented on in and Serhiy asked for it, I made a sample patch on version 3.6.3 which contains all the change which I believe, would be required. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 18:20:43 2017 From: report at bugs.python.org (Camion) Date: Sun, 10 Dec 2017 23:20:43 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512948043.0.0.213398074469.issue32259@psf.upfronthosting.co.za> Camion added the comment: Well I submitted a patch, but I don't see it anywhere on this page.. Is this normal ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 18:32:05 2017 From: report at bugs.python.org (Camion) Date: Sun, 10 Dec 2017 23:32:05 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1512948725.82.0.213398074469.issue32259@psf.upfronthosting.co.za> Camion added the comment: Woops, my mistake... I fumbled this one : the file was empty ---------- keywords: +patch Added file: https://bugs.python.org/file47330/issue-32259-iterable-unpackable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 18:36:14 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 10 Dec 2017 23:36:14 +0000 Subject: [issue32262] Fix linting errors in asyncio code; use f-strings consistently In-Reply-To: <1512861969.57.0.213398074469.issue32262@psf.upfronthosting.co.za> Message-ID: <1512948974.38.0.213398074469.issue32262@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 6370f345e1d5829e1fba59cd695c8b82c5a8c620 by Yury Selivanov in branch 'master': bpo-32262: Fix codestyle; use f-strings formatting where necessary. (#4775) https://github.com/python/cpython/commit/6370f345e1d5829e1fba59cd695c8b82c5a8c620 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 18:36:37 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 10 Dec 2017 23:36:37 +0000 Subject: [issue32262] Fix linting errors in asyncio code; use f-strings consistently In-Reply-To: <1512861969.57.0.213398074469.issue32262@psf.upfronthosting.co.za> Message-ID: <1512948997.11.0.213398074469.issue32262@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 18:57:08 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 10 Dec 2017 23:57:08 +0000 Subject: [issue32272] Remove asyncio.async function Message-ID: <1512950228.3.0.213398074469.issue32272@psf.upfronthosting.co.za> New submission from Yury Selivanov : asyncio.async() is a deprecated alias for asyncio.ensure_future(). Since Python 3.7, async and await are proper keywords, and it is no longer possible to use the function. I.e. both 'from asyncio import async' and 'asyncio.async(...)' are a SyntaxError. ---------- components: asyncio messages: 308006 nosy: yselivanov priority: normal severity: normal status: open title: Remove asyncio.async function type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 18:57:22 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 10 Dec 2017 23:57:22 +0000 Subject: [issue32272] Remove asyncio.async function In-Reply-To: <1512950228.3.0.213398074469.issue32272@psf.upfronthosting.co.za> Message-ID: <1512950242.2.0.213398074469.issue32272@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 18:57:47 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 10 Dec 2017 23:57:47 +0000 Subject: [issue32272] Remove asyncio.async function In-Reply-To: <1512950228.3.0.213398074469.issue32272@psf.upfronthosting.co.za> Message-ID: <1512950267.88.0.213398074469.issue32272@psf.upfronthosting.co.za> Yury Selivanov added the comment: The function has been deprecated since Python 3.4.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 19:00:47 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Dec 2017 00:00:47 +0000 Subject: [issue32272] Remove asyncio.async function In-Reply-To: <1512950228.3.0.213398074469.issue32272@psf.upfronthosting.co.za> Message-ID: <1512950447.68.0.213398074469.issue32272@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4685 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 19:12:27 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Dec 2017 00:12:27 +0000 Subject: [issue32273] Remove asyncio.test_utils Message-ID: <1512951147.51.0.213398074469.issue32273@psf.upfronthosting.co.za> New submission from Yury Selivanov : asyncio.test_utils was never part of asyncio API and was never even documented. It's purely due to historical reasons that test_utils.py is in the Lib/asyncio directory. ---------- components: asyncio messages: 308008 nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Remove asyncio.test_utils type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 19:14:02 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Dec 2017 00:14:02 +0000 Subject: [issue32273] Remove asyncio.test_utils In-Reply-To: <1512951147.51.0.213398074469.issue32273@psf.upfronthosting.co.za> Message-ID: <1512951242.17.0.213398074469.issue32273@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4686 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 19:15:57 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Mon, 11 Dec 2017 00:15:57 +0000 Subject: [issue13553] Tkinter Tk args and Gnome Shell application name In-Reply-To: <1323306729.26.0.368335158355.issue13553@psf.upfronthosting.co.za> Message-ID: <1512951357.62.0.213398074469.issue13553@psf.upfronthosting.co.za> Change by Cheryl Sabella : ---------- keywords: +patch pull_requests: +4687 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 19:16:47 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Mon, 11 Dec 2017 00:16:47 +0000 Subject: [issue13553] Tkinter Tk args and Gnome Shell application name In-Reply-To: <1323306729.26.0.368335158355.issue13553@psf.upfronthosting.co.za> Message-ID: <1512951407.83.0.213398074469.issue13553@psf.upfronthosting.co.za> Change by Cheryl Sabella : ---------- versions: +Python 3.7 -Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 19:20:24 2017 From: report at bugs.python.org (Licht Takeuchi) Date: Mon, 11 Dec 2017 00:20:24 +0000 Subject: [issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n' In-Reply-To: <1512744234.4.0.213398074469.issue32255@psf.upfronthosting.co.za> Message-ID: <1512951624.5.0.213398074469.issue32255@psf.upfronthosting.co.za> Licht Takeuchi added the comment: Thanks for your investigation! Would you mind if I create a new patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 19:34:19 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Dec 2017 00:34:19 +0000 Subject: [issue32262] Fix linting errors in asyncio code; use f-strings consistently In-Reply-To: <1512861969.57.0.213398074469.issue32262@psf.upfronthosting.co.za> Message-ID: <1512952459.96.0.213398074469.issue32262@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- pull_requests: +4688 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 19:52:55 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Dec 2017 00:52:55 +0000 Subject: [issue32262] Fix linting errors in asyncio code; use f-strings consistently In-Reply-To: <1512861969.57.0.213398074469.issue32262@psf.upfronthosting.co.za> Message-ID: <1512953575.19.0.213398074469.issue32262@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 19d0d5480931117d9e0bf396a0234707bbdaa494 by Yury Selivanov in branch 'master': bpo-32262: Fix f-string (#4787) https://github.com/python/cpython/commit/19d0d5480931117d9e0bf396a0234707bbdaa494 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 19:54:15 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 11 Dec 2017 00:54:15 +0000 Subject: [issue32145] Wrong ExitStack Callback recipe In-Reply-To: <1511771653.67.0.213398074469.issue32145@psf.upfronthosting.co.za> Message-ID: <1512953655.85.0.213398074469.issue32145@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I wasn't even aware that pop_all() tries to create the concrete subtype. I wonder how common subclassing ExitStack is in practice. (Of course, the answer is that we'll never know.) For 3.7, we should probably delegate instance creation to a new non-private method, e.g. new_stack = self._make_instance() so *if* you subclass, you can create the new ExitStack subclass instances any way you want. I would then change the default implementation to make an ExitStack() explicitly, as per the current documentation. +1 for fixing the recipe and not changing the code for 3.6. You might want to add a note describing the current behavior for <= 3.6 and indicating that this will change for 3.7+ Finally, while you're at it, is there any reason not to change the recipe to use: super().__init__() instead? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 22:37:31 2017 From: report at bugs.python.org (Simon Depiets) Date: Mon, 11 Dec 2017 03:37:31 +0000 Subject: [issue32245] OSError: raw write() returned invalid length on latest Win 10 Consoles In-Reply-To: <1512660082.17.0.213398074469.issue32245@psf.upfronthosting.co.za> Message-ID: <1512963451.98.0.213398074469.issue32245@psf.upfronthosting.co.za> Simon Depiets added the comment: The issue doesn't seem to happen on either 3.6 (with the new stdio mode) or with win_unicode_console enabled. I was able to reproduce it on 3.6 with the PYTHONLEGACYWINDOWSSTDIO flag enabled, it's easier to trigger when using directional keys or mouse clicks within the console. chcp : Active code page : 437 System locale : en-us ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 23:25:53 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 11 Dec 2017 04:25:53 +0000 Subject: [issue32263] Template string docs refer to "normal %-based substitutions" In-Reply-To: <1512855398.42.0.213398074469.issue32263@psf.upfronthosting.co.za> Message-ID: <1512966353.61.0.213398074469.issue32263@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, this was already fixed in the 3.7 docs. I don't feel any real need to backport it. ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 23:26:05 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 11 Dec 2017 04:26:05 +0000 Subject: [issue32263] Template string docs refer to "normal %-based substitutions" In-Reply-To: <1512855398.42.0.213398074469.issue32263@psf.upfronthosting.co.za> Message-ID: <1512966365.64.0.213398074469.issue32263@psf.upfronthosting.co.za> Change by Raymond Hettinger : ---------- versions: -Python 3.4, Python 3.5, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 10 23:26:50 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 11 Dec 2017 04:26:50 +0000 Subject: [issue24991] Define instance mutability explicitly on type objects? In-Reply-To: <1441260483.41.0.785006760825.issue24991@psf.upfronthosting.co.za> Message-ID: <1512966410.09.0.213398074469.issue24991@psf.upfronthosting.co.za> Change by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 00:22:18 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Mon, 11 Dec 2017 05:22:18 +0000 Subject: [issue29137] Fix fpectl-induced ABI breakage In-Reply-To: <1483402510.43.0.646850547969.issue29137@psf.upfronthosting.co.za> Message-ID: <1512969738.48.0.213398074469.issue29137@psf.upfronthosting.co.za> Change by Nathaniel Smith : ---------- keywords: +patch pull_requests: +4689 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 00:50:27 2017 From: report at bugs.python.org (Ilya Kulakov) Date: Mon, 11 Dec 2017 05:50:27 +0000 Subject: [issue29302] add contextlib.AsyncExitStack In-Reply-To: <1484693382.32.0.211448130443.issue29302@psf.upfronthosting.co.za> Message-ID: <1512971427.24.0.213398074469.issue29302@psf.upfronthosting.co.za> Change by Ilya Kulakov : ---------- keywords: +patch pull_requests: +4690 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 01:00:17 2017 From: report at bugs.python.org (Ilya Kulakov) Date: Mon, 11 Dec 2017 06:00:17 +0000 Subject: [issue29302] add contextlib.AsyncExitStack In-Reply-To: <1484693382.32.0.211448130443.issue29302@psf.upfronthosting.co.za> Message-ID: <1512972017.66.0.213398074469.issue29302@psf.upfronthosting.co.za> Ilya Kulakov added the comment: Charyl, I made the PR. Where is the AbstractAsyncContextManager? I see that typing.py references it, but there is no actual implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 01:33:57 2017 From: report at bugs.python.org (Christian Heimes) Date: Mon, 11 Dec 2017 06:33:57 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512974037.27.0.213398074469.issue32257@psf.upfronthosting.co.za> Christian Heimes added the comment: I took Guido's keys to the time machine: https://github.com/openssl/openssl/issues/4739 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 01:40:41 2017 From: report at bugs.python.org (Qichao Chu) Date: Mon, 11 Dec 2017 06:40:41 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512974441.77.0.213398074469.issue32257@psf.upfronthosting.co.za> Qichao Chu added the comment: Thanks Christian! Let's wait for OpenSSL then. I will close this bug for now and reopen when OpenSSL releases 1.1.1 with the new flag. ---------- resolution: -> later stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 01:45:05 2017 From: report at bugs.python.org (Christian Heimes) Date: Mon, 11 Dec 2017 06:45:05 +0000 Subject: [issue32257] Support Disabling Renegotiation for SSLContext In-Reply-To: <1512801503.1.0.213398074469.issue32257@psf.upfronthosting.co.za> Message-ID: <1512974705.89.0.213398074469.issue32257@psf.upfronthosting.co.za> Christian Heimes added the comment: We don't work that way. Closed means closed forever. Please leave the bug open. ---------- priority: normal -> high resolution: later -> stage: resolved -> status: closed -> open type: enhancement -> security versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 02:08:13 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Dec 2017 07:08:13 +0000 Subject: [issue31506] Improve the error message logic for object_new & object_init In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za> Message-ID: <1512976093.05.0.213398074469.issue31506@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 780acc89bccf9999332d334a27887684cc942eb6 reintroduced the part of the original bug fixed in a6c0c0695614177c8b6e1840465375eefcfee586. object.__new__() and object.__init__() require an argument (cls and self correspondingly). ---------- resolution: fixed -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 02:49:38 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Mon, 11 Dec 2017 07:49:38 +0000 Subject: [issue30050] Please provide a way to disable the warning printed if the signal module's wakeup fd overflows In-Reply-To: <1491987273.45.0.570112423464.issue30050@psf.upfronthosting.co.za> Message-ID: <1512978578.77.0.213398074469.issue30050@psf.upfronthosting.co.za> Change by Nathaniel Smith : ---------- keywords: +patch pull_requests: +4691 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 03:19:01 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 11 Dec 2017 08:19:01 +0000 Subject: [issue32251] Add asyncio.BufferedProtocol In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za> Message-ID: <1512980341.26.0.213398074469.issue32251@psf.upfronthosting.co.za> INADA Naoki added the comment: Looks nice. Can it speed up aiohttp too? ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 03:46:34 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 11 Dec 2017 08:46:34 +0000 Subject: [issue32251] Add asyncio.BufferedProtocol In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za> Message-ID: <1512981994.63.0.213398074469.issue32251@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Yes. aiohttp uses own streams but public API and internal implementation are pretty close to asyncio streams. Moreover C accelerated HTTP parser should work with proposed BufferedProtocol seamlessly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 04:27:07 2017 From: report at bugs.python.org (Nitish) Date: Mon, 11 Dec 2017 09:27:07 +0000 Subject: [issue30718] open builtin function: specifying the size of buffer has no effect for text files In-Reply-To: <1497989929.05.0.713607879185.issue30718@psf.upfronthosting.co.za> Message-ID: <1512984427.04.0.213398074469.issue30718@psf.upfronthosting.co.za> Change by Nitish : ---------- nosy: +nitishch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 04:37:10 2017 From: report at bugs.python.org (Nitish) Date: Mon, 11 Dec 2017 09:37:10 +0000 Subject: [issue32228] truncate() changes current stream position In-Reply-To: <1512515954.76.0.213398074469.issue32228@psf.upfronthosting.co.za> Message-ID: <1512985030.73.0.213398074469.issue32228@psf.upfronthosting.co.za> Change by Nitish : ---------- nosy: +nitishch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 04:41:13 2017 From: report at bugs.python.org (Lele Gaifax) Date: Mon, 11 Dec 2017 09:41:13 +0000 Subject: [issue32274] Potential leak in pysqlite_connection_init() Message-ID: <1512985273.03.0.213398074469.issue32274@psf.upfronthosting.co.za> New submission from Lele Gaifax : The function calls ``sqlite3_open()`` that, if I understand its documentation correctly[#], returns a new connection object in all cases (that is, even on errors) with the only exception of "out of memory" (in which case it sets the second parameter to ``NULL``). I think that the new connection object should be immediately released in case of errors, passing it to ``sqlite3_close()``. .. [#] http://sqlite.org/c3ref/open.html ---------- messages: 308021 nosy: lelit priority: normal severity: normal status: open title: Potential leak in pysqlite_connection_init() type: resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 04:47:21 2017 From: report at bugs.python.org (Lele Gaifax) Date: Mon, 11 Dec 2017 09:47:21 +0000 Subject: [issue27645] Supporting native backup facility of SQLite In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za> Message-ID: <1512985641.67.0.213398074469.issue27645@psf.upfronthosting.co.za> Lele Gaifax added the comment: I need advice on Serhiy's proposal of dropping support to plain file name (see also https://github.com/python/cpython/pull/4238#discussion_r155725986). Wrt the other point I filed issue #32274. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 05:10:00 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Mon, 11 Dec 2017 10:10:00 +0000 Subject: [issue30579] Allow traceback objects to be instantiated/mutated/annotated In-Reply-To: <1496720513.53.0.619437315354.issue30579@psf.upfronthosting.co.za> Message-ID: <1512987000.33.0.213398074469.issue30579@psf.upfronthosting.co.za> Change by Nathaniel Smith : ---------- keywords: +patch pull_requests: +4692 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 05:10:34 2017 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 11 Dec 2017 10:10:34 +0000 Subject: [issue30579] Allow traceback objects to be instantiated/mutated/annotated In-Reply-To: <1496720513.53.0.619437315354.issue30579@psf.upfronthosting.co.za> Message-ID: <1512987034.31.0.213398074469.issue30579@psf.upfronthosting.co.za> Change by Giampaolo Rodola' : ---------- nosy: -giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 05:28:46 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Mon, 11 Dec 2017 10:28:46 +0000 Subject: [issue30579] Allow traceback objects to be instantiated/mutated/annotated In-Reply-To: <1496720513.53.0.619437315354.issue30579@psf.upfronthosting.co.za> Message-ID: <1512988126.71.0.213398074469.issue30579@psf.upfronthosting.co.za> Nathaniel Smith added the comment: PR 4793 provides everything that Jinja2 and Trio actually need right now. It doesn't provide any way to annotate tracebacks with extra data, but I'm not entirely sure if that's necessary or what it would look like, so I figured I'd at least get this part in for 3.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 05:35:31 2017 From: report at bugs.python.org (Julien Palard) Date: Mon, 11 Dec 2017 10:35:31 +0000 Subject: [issue32274] Potential leak in pysqlite_connection_init() In-Reply-To: <1512985273.03.0.213398074469.issue32274@psf.upfronthosting.co.za> Message-ID: <1512988531.36.0.213398074469.issue32274@psf.upfronthosting.co.za> Julien Palard added the comment: I don't see a leak here: as long as nobody keep a reference to each connection objects, pysqlite_connection_dealloc will be called and will call the sqlite3_close. In other words the sqlite3_close is called when the connection is destroyed, which happen when no reference are kept on the connection, indifferently of a success or a failure of the connection. It's in Modules/_sqlite/connection.c ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 05:43:28 2017 From: report at bugs.python.org (Lele Gaifax) Date: Mon, 11 Dec 2017 10:43:28 +0000 Subject: [issue32274] Potential leak in pysqlite_connection_init() In-Reply-To: <1512985273.03.0.213398074469.issue32274@psf.upfronthosting.co.za> Message-ID: <1512989008.53.0.213398074469.issue32274@psf.upfronthosting.co.za> Lele Gaifax added the comment: You are right, thank you. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 05:45:05 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 11 Dec 2017 10:45:05 +0000 Subject: [issue32275] SSL socket methods don't retry on EINTR? Message-ID: <1512989105.2.0.213398074469.issue32275@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Some time ago, PEP 475 was accepted in order to automatically retry system calls on EINTR, but the _ssl module wasn't touched. However, it seems that OpenSSL socket calls can fail with EINTR: https://stackoverflow.com/questions/24188013/openssl-and-signals ---------- messages: 308026 nosy: alex, christian.heimes, dstufft, janssen, njs, pitrou, vstinner priority: normal severity: normal status: open title: SSL socket methods don't retry on EINTR? type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 05:47:14 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 11 Dec 2017 10:47:14 +0000 Subject: [issue32251] Add asyncio.BufferedProtocol In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za> Message-ID: <1512989234.11.0.213398074469.issue32251@psf.upfronthosting.co.za> Antoine Pitrou added the comment: See https://eklitzke.org/goroutines-nonblocking-io-and-memory-usage for an interesting discussion of the drawbacks of some buffer handling idioms. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 06:12:26 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 11:12:26 +0000 Subject: [issue32275] SSL socket methods don't retry on EINTR? In-Reply-To: <1512989105.2.0.213398074469.issue32275@psf.upfronthosting.co.za> Message-ID: <1512990746.17.0.213398074469.issue32275@psf.upfronthosting.co.za> STINNER Victor added the comment: "it seems that OpenSSL socket calls can fail with EINTR: ..." You are easily test by raising a signal: see Lib/test/test_eintr.py which stress Python functions by sending a signal every 100 ms while Python is blocked in a syscall. If there is a bug, sure, it must be fixed ;-) It was very tricky to handle EINTR properly in the socket module. While most Python functions are thin wrapper to syscalls with no timeout, almost every socket functions have a timeout. So I wrote sock_call() to factorize the code. This function calls select() internally to check if the socket is "ready", but also updates the timeout, etc. A few other Python are retried on EINTR and update a timeout, like select.select(), time.sleep(), threading.Lock.acquire() and signal.sigtimedwait(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 06:14:08 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 11:14:08 +0000 Subject: [issue32275] SSL socket methods don't retry on EINTR? In-Reply-To: <1512989105.2.0.213398074469.issue32275@psf.upfronthosting.co.za> Message-ID: <1512990848.13.0.213398074469.issue32275@psf.upfronthosting.co.za> STINNER Victor added the comment: See bpo-23618 for handling EINTR in socket and bpo-23834 for sock_call(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 06:14:31 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 11 Dec 2017 11:14:31 +0000 Subject: [issue32246] test_regrtest alters the execution environment on Android In-Reply-To: <1512662502.3.0.213398074469.issue32246@psf.upfronthosting.co.za> Message-ID: <1512990871.06.0.213398074469.issue32246@psf.upfronthosting.co.za> Xavier de Gaye added the comment: To debug and reproduce the problem on Android, one must checkout from the bpo-30386 branch https://github.com/python/cpython/pull/1629/commits/c0ca089220cd39851d7625b55510be63b340e188. faulthandler._sigsegv() does crash the crasher in test_crashed, so test_crashed must not be disabled. > How is it possible that the new file that alters the environment be a test_python_* directory (see my initial post) when all the tests are run inside a TEMPDIR/test_python_* directory. Both test_crashed tests are run in nested tests directories (i.e. in $TEMPDIR/test_python_*/test_python_*) on Android. As a consequence the test_python_* directory that is not removed by the crasher because it crashed, is reported by test_crashed as altering the environment. This also explains the other points raised previously. A remote interactive shell is run by the 'adb shell' command and the TMPDIR environment variable is set in that shell. A command may be run remotely with the command 'adb shell /path/to/command' and the TMPDIR variable is *not set* (but most if not all the other shell environment variables are set) and since on Android /tmp does not exist, then tempfile.gettempdir() uses the current directory. This explains why the test directories are doubly nested. On the commit that is the child of commit c0ca089220cd39... which we are using here, TMPDIR has been made to be set in the script that runs Tools/script/run_tests.py and so it does fix inadvertently the issue for the reason explained in the previous paragraph. This bug can only exist on platforms where tempfile.gettempdir() falls back to using the current directory because '/tmp', '/var/tmp' and '/usr/tmp' do not exist and where none of the 'TMPDIR', 'TEMP', 'TMP' variables is set. Therefore we can either close this issue as not a bug or use the following patch that fixes the problem, it is similar to the fix made in issue 15300: diff --git a/Lib/test/test_regrtest.py b/Lib/test/test_regrtest.py index 8364767b3a..3a213e12c4 100644 --- a/Lib/test/test_regrtest.py +++ b/Lib/test/test_regrtest.py @@ -468,10 +468,13 @@ class BaseTestCase(unittest.TestCase): input = '' if 'stderr' not in kw: kw['stderr'] = subprocess.PIPE + savedcwd = (support.SAVEDCWD if + any(x.startswith('-j') for x in args) else None) proc = subprocess.run(args, universal_newlines=True, input=input, stdout=subprocess.PIPE, + cwd=savedcwd, **kw) if proc.returncode != exitcode: msg = ("Command %s failed with exit code %s\n" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 06:17:30 2017 From: report at bugs.python.org (Christian Heimes) Date: Mon, 11 Dec 2017 11:17:30 +0000 Subject: [issue32275] SSL socket methods don't retry on EINTR? In-Reply-To: <1512989105.2.0.213398074469.issue32275@psf.upfronthosting.co.za> Message-ID: <1512991050.83.0.213398074469.issue32275@psf.upfronthosting.co.za> Change by Christian Heimes : ---------- assignee: -> christian.heimes components: +SSL stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 06:17:36 2017 From: report at bugs.python.org (Christian Heimes) Date: Mon, 11 Dec 2017 11:17:36 +0000 Subject: [issue32275] SSL socket methods don't retry on EINTR? In-Reply-To: <1512989105.2.0.213398074469.issue32275@psf.upfronthosting.co.za> Message-ID: <1512991056.01.0.213398074469.issue32275@psf.upfronthosting.co.za> Change by Christian Heimes : ---------- assignee: christian.heimes -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 06:28:00 2017 From: report at bugs.python.org (Julien Palard) Date: Mon, 11 Dec 2017 11:28:00 +0000 Subject: [issue32275] SSL socket methods don't retry on EINTR? In-Reply-To: <1512989105.2.0.213398074469.issue32275@psf.upfronthosting.co.za> Message-ID: <1512991680.12.0.213398074469.issue32275@psf.upfronthosting.co.za> Julien Palard added the comment: Looks like this behavior is documented in the bio_should_retry(3) man page. Basically bio_should_retry() tells if the error was non-fatal: int BIO_fd_should_retry(int i) { int err; if ((i == 0) || (i == -1)) { err = get_last_sys_error(); return BIO_fd_non_fatal_error(err); } return 0; } ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 07:05:40 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 12:05:40 +0000 Subject: [issue32252] test_regrtest leaves a test_python_* directory in TEMPDIR In-Reply-To: <1512722953.36.0.213398074469.issue32252@psf.upfronthosting.co.za> Message-ID: <1512993940.67.0.213398074469.issue32252@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm unable to reproduce the issue on Fedora 27: vstinner at apu$ cat /proc/sys/kernel/core_pattern core-%e.%s vstinner at apu$ ulimit -c unlimited vstinner at apu$ ./python -m test test_regrtest Run tests sequentially 0:00:00 load avg: 0.70 [1/1] test_regrtest 1 test OK. Total duration: 14 sec Tests result: SUCCESS While core dump works as expected: vstinner at apu$ ./python >>> import faulthandler >>> faulthandler._sigsegv() Segmentation fault (core dumped) vstinner at apu$ ls core* core-python.11.32456 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 07:14:09 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 12:14:09 +0000 Subject: [issue32252] test_regrtest leaves a test_python_* directory in TEMPDIR In-Reply-To: <1512722953.36.0.213398074469.issue32252@psf.upfronthosting.co.za> Message-ID: <1512994449.11.0.213398074469.issue32252@psf.upfronthosting.co.za> STINNER Victor added the comment: Ah! I misunderstood the bug report. I was looking for a ENV_FAILED failure, but no, regrtest fails to remove its temporary directory but no warning is emitted in this case. vstinner at apu$ ls -d build/test_python_*; ./python -m test test_regrtest -m test.test_regrtest.ArgsTestCase.test_crashed; ls -d build/test_python_* ls: impossible d'acc?der ? 'build/test_python_*': No such file or directory Run tests sequentially 0:00:00 load avg: 0.42 [1/1] test_regrtest 1 test OK. Total duration: 537 ms Tests result: SUCCESS build/test_python_816 So running test_regrtest creates build/test_python_816/ but fails to remove it because it contains a core dump: core-python.11.816. * No core dump must be written, Python is supposed to disable that * regrtest must emit a warning if it fails to remove the temporary directory, maybe also fail with an error? (non-zero exit code) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 07:19:41 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 11 Dec 2017 12:19:41 +0000 Subject: [issue32252] test_regrtest leaves a test_python_* directory in TEMPDIR In-Reply-To: <1512722953.36.0.213398074469.issue32252@psf.upfronthosting.co.za> Message-ID: <1512994781.1.0.213398074469.issue32252@psf.upfronthosting.co.za> Xavier de Gaye added the comment: What is now the content of the 'build/' subdirectory of the source tree ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 07:22:02 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 11 Dec 2017 12:22:02 +0000 Subject: [issue32252] test_regrtest leaves a test_python_* directory in TEMPDIR In-Reply-To: <1512722953.36.0.213398074469.issue32252@psf.upfronthosting.co.za> Message-ID: <1512994922.97.0.213398074469.issue32252@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > Ah! I misunderstood the bug report. I was looking for a ENV_FAILED failure, but no, regrtest fails to remove its temporary directory but no warning is emitted in this case. Yes :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 07:25:49 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 11 Dec 2017 12:25:49 +0000 Subject: [issue32252] test_regrtest leaves a test_python_* directory in TEMPDIR In-Reply-To: <1512722953.36.0.213398074469.issue32252@psf.upfronthosting.co.za> Message-ID: <1512995148.99.0.213398074469.issue32252@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > So running test_regrtest creates build/test_python_816/ but fails to remove it because it contains a core dump: core-python.11.816. Not sure that it is because it contains a core file. Maybe it just does not remove it because the test crashed ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 07:32:14 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 12:32:14 +0000 Subject: [issue32252] test_regrtest leaves a test_python_* directory in TEMPDIR In-Reply-To: <1512722953.36.0.213398074469.issue32252@psf.upfronthosting.co.za> Message-ID: <1512995534.28.0.213398074469.issue32252@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- keywords: +patch pull_requests: +4693 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 07:36:36 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 12:36:36 +0000 Subject: [issue32252] test_regrtest leaves a test_python_* directory in TEMPDIR In-Reply-To: <1512722953.36.0.213398074469.issue32252@psf.upfronthosting.co.za> Message-ID: <1512995796.62.0.213398074469.issue32252@psf.upfronthosting.co.za> STINNER Victor added the comment: > Maybe it just does not remove it because the test crashed ? Ah, you're right :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 07:37:47 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 12:37:47 +0000 Subject: [issue32252] test_regrtest leaves a test_python_* directory in TEMPDIR In-Reply-To: <1512722953.36.0.213398074469.issue32252@psf.upfronthosting.co.za> Message-ID: <1512995867.51.0.213398074469.issue32252@psf.upfronthosting.co.za> STINNER Victor added the comment: > * No core dump must be written, Python is supposed to disable that My bad. It's an obvious bug that was missed before because regrtest creates a temporary directory to run tests and then remove it. I wrote the PR 4794 to fix faulthandler. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 07:57:15 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 12:57:15 +0000 Subject: [issue32252] test_regrtest leaves a test_python_* directory in TEMPDIR In-Reply-To: <1512722953.36.0.213398074469.issue32252@psf.upfronthosting.co.za> Message-ID: <1512997035.28.0.213398074469.issue32252@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 48d4dd974f0c8d47c54990eedd322b96b19c60ec by Victor Stinner in branch 'master': bpo-32252: Fix faulthandler_suppress_crash_report() (#4794) https://github.com/python/cpython/commit/48d4dd974f0c8d47c54990eedd322b96b19c60ec ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 07:57:35 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Dec 2017 12:57:35 +0000 Subject: [issue32252] test_regrtest leaves a test_python_* directory in TEMPDIR In-Reply-To: <1512722953.36.0.213398074469.issue32252@psf.upfronthosting.co.za> Message-ID: <1512997055.73.0.213398074469.issue32252@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4694 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 07:58:10 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 12:58:10 +0000 Subject: [issue30579] Allow traceback objects to be instantiated/mutated/annotated In-Reply-To: <1496720513.53.0.619437315354.issue30579@psf.upfronthosting.co.za> Message-ID: <1512997090.49.0.213398074469.issue30579@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 08:00:12 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 13:00:12 +0000 Subject: [issue26855] android: add platform.android_ver() In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za> Message-ID: <1512997212.24.0.213398074469.issue26855@psf.upfronthosting.co.za> STINNER Victor added the comment: > Yes, and fall back to spawning getprop if that fails. I suggest to start simple. Parsing a text file is simple, spawning a subprocess can have annoying side effects :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 08:17:09 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 13:17:09 +0000 Subject: [issue32252] test_regrtest leaves a test_python_* directory in TEMPDIR In-Reply-To: <1512722953.36.0.213398074469.issue32252@psf.upfronthosting.co.za> Message-ID: <1512998229.6.0.213398074469.issue32252@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 71d8f36eb450cdbc4b5397e25f6f3f5d676aca79 by Victor Stinner (Miss Islington (bot)) in branch '3.6': bpo-32252: Fix faulthandler_suppress_crash_report() (GH-4794) (#4795) https://github.com/python/cpython/commit/71d8f36eb450cdbc4b5397e25f6f3f5d676aca79 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 08:42:16 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 13:42:16 +0000 Subject: [issue22671] Typo in class io.BufferedIOBase docs In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za> Message-ID: <1512999736.11.0.213398074469.issue22671@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 1b74f9b77a6fa1d7828986cb79d5b10942ff9141 by Victor Stinner (Sanyam Khurana) in branch 'master': bpo-22671: Clarify and test default read method implementations (#4568) https://github.com/python/cpython/commit/1b74f9b77a6fa1d7828986cb79d5b10942ff9141 ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 08:44:02 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Dec 2017 13:44:02 +0000 Subject: [issue22671] Typo in class io.BufferedIOBase docs In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za> Message-ID: <1512999842.74.0.213398074469.issue22671@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4695 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 09:25:27 2017 From: report at bugs.python.org (Yaroslav Halchenko) Date: Mon, 11 Dec 2017 14:25:27 +0000 Subject: [issue32276] there is no way to make tempfile reproducible (i.e. seed the used RNG) Message-ID: <1513002327.33.0.213398074469.issue32276@psf.upfronthosting.co.za> New submission from Yaroslav Halchenko : It is quite often desired to reproduce the same failure identically. In many cases sufficient to seed the shared random._inst (via random.seed). tempfile creates new instance(s) for its own operation and does not provide API to seed it. I do not think it would be easy (unless I miss some pattern) to make it deterministic/reproducible for multi-process apps, but I wondered why initially (for the main process) tempfile module doesn't just reuse the random._inst while only creating a new _Random in children processes? Another alternative solution would be to allow to specify seed for all those mkstemp/mkdtemp/... and pass it all way to _RandomNameSequence which would initialize _Random with it. This way, developers who need to seed it, could do so ---------- messages: 308043 nosy: Yaroslav.Halchenko priority: normal severity: normal status: open title: there is no way to make tempfile reproducible (i.e. seed the used RNG) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 09:27:32 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 14:27:32 +0000 Subject: [issue22671] Typo in class io.BufferedIOBase docs In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za> Message-ID: <1513002452.12.0.213398074469.issue22671@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 0aa2a1d003b476b954ecdcb7e966bf7f0b75a06b by Victor Stinner (Miss Islington (bot)) in branch '3.6': bpo-22671: Clarify and test default read method implementations (GH-4568) (#4796) https://github.com/python/cpython/commit/0aa2a1d003b476b954ecdcb7e966bf7f0b75a06b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 09:28:11 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 14:28:11 +0000 Subject: [issue22671] Typo in class io.BufferedIOBase docs In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za> Message-ID: <1513002491.09.0.213398074469.issue22671@psf.upfronthosting.co.za> STINNER Victor added the comment: Thank you Martin Panter and Sanyam Khurana for the fix. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 09:48:58 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Mon, 11 Dec 2017 14:48:58 +0000 Subject: [issue29302] add contextlib.AsyncExitStack In-Reply-To: <1484693382.32.0.211448130443.issue29302@psf.upfronthosting.co.za> Message-ID: <1513003738.54.0.213398074469.issue29302@psf.upfronthosting.co.za> Cheryl Sabella added the comment: Looks like AbstractAsyncContextManager is defined in issue #30241. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 09:52:44 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 14:52:44 +0000 Subject: [issue31650] implement PEP 552 In-Reply-To: <1506801596.1.0.213398074469.issue31650@psf.upfronthosting.co.za> Message-ID: <1513003964.42.0.213398074469.issue31650@psf.upfronthosting.co.za> STINNER Victor added the comment: Failure on Python on s390x RHEL 3.x: http://buildbot.python.org/all/#/builders/21/builds/340 ====================================================================== FAIL: test_source_hash (test.test_imp.ImportTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/test/test_imp.py", line 335, in test_source_hash self.assertEqual(_imp.source_hash(42, b'hi'), b'\xc6\xe7Z\r\x03:}\xab') AssertionError: b'Yb\x91||\x91bY' != b'\xc6\xe7Z\r\x03:}\xab' ---------- nosy: +vstinner resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 10:03:50 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Dec 2017 15:03:50 +0000 Subject: [issue32272] Remove asyncio.async function In-Reply-To: <1512950228.3.0.213398074469.issue32272@psf.upfronthosting.co.za> Message-ID: <1513004630.41.0.213398074469.issue32272@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 9edad3c7011ccab0a66a065933abebf3288cf1a1 by Yury Selivanov in branch 'master': bpo-32272: Remove asyncio.async() function. (#4784) https://github.com/python/cpython/commit/9edad3c7011ccab0a66a065933abebf3288cf1a1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 10:04:05 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Dec 2017 15:04:05 +0000 Subject: [issue32272] Remove asyncio.async function In-Reply-To: <1512950228.3.0.213398074469.issue32272@psf.upfronthosting.co.za> Message-ID: <1513004645.67.0.213398074469.issue32272@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 10:04:43 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Dec 2017 15:04:43 +0000 Subject: [issue32273] Remove asyncio.test_utils In-Reply-To: <1512951147.51.0.213398074469.issue32273@psf.upfronthosting.co.za> Message-ID: <1513004683.07.0.213398074469.issue32273@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 3e9751819ad13a965e8be13c1e5bc5a6811fe6b8 by Yury Selivanov in branch 'master': bpo-32273: Move asyncio.test_utils to test.test_asyncio (#4785) https://github.com/python/cpython/commit/3e9751819ad13a965e8be13c1e5bc5a6811fe6b8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 10:05:00 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Dec 2017 15:05:00 +0000 Subject: [issue32273] Remove asyncio.test_utils In-Reply-To: <1512951147.51.0.213398074469.issue32273@psf.upfronthosting.co.za> Message-ID: <1513004700.84.0.213398074469.issue32273@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 10:05:12 2017 From: report at bugs.python.org (Licht Takeuchi) Date: Mon, 11 Dec 2017 15:05:12 +0000 Subject: [issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n' In-Reply-To: <1512744234.4.0.213398074469.issue32255@psf.upfronthosting.co.za> Message-ID: <1513004712.59.0.213398074469.issue32255@psf.upfronthosting.co.za> Licht Takeuchi added the comment: PR is now fixed so as to follow the behavior on Python 2.7! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 10:08:02 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Dec 2017 15:08:02 +0000 Subject: [issue32269] Add `asyncio.get_running_loop()` function In-Reply-To: <1512925724.74.0.213398074469.issue32269@psf.upfronthosting.co.za> Message-ID: <1513004882.89.0.213398074469.issue32269@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 10:08:52 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Dec 2017 15:08:52 +0000 Subject: [issue32269] Add `asyncio.get_running_loop()` function In-Reply-To: <1512925724.74.0.213398074469.issue32269@psf.upfronthosting.co.za> Message-ID: <1513004932.3.0.213398074469.issue32269@psf.upfronthosting.co.za> Yury Selivanov added the comment: > `asyncio._get_running_loop()` will be deprecated and removed in Python 3.9. _get_running_loop() was left as-is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 10:35:55 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 11 Dec 2017 15:35:55 +0000 Subject: [issue32258] Rewrite asyncio docs to use async/await syntax In-Reply-To: <1512813975.64.0.213398074469.issue32258@psf.upfronthosting.co.za> Message-ID: <1513006555.61.0.213398074469.issue32258@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset 8874342cf332c3aa3d845155cc4b41b00c2d9e9d by Andrew Svetlov in branch 'master': bpo-32258: Replace 'yield from' to 'await' in asyncio docs (#4779) https://github.com/python/cpython/commit/8874342cf332c3aa3d845155cc4b41b00c2d9e9d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 10:44:08 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 15:44:08 +0000 Subject: [issue19431] Document PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError() In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za> Message-ID: <1513007048.1.0.213398074469.issue19431@psf.upfronthosting.co.za> STINNER Victor added the comment: > Should there be a PR for this? Feel free to create a PR from my old (4 years old) patch. Just mention my name in the commit message please. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 10:44:45 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 15:44:45 +0000 Subject: [issue19431] Document PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError() In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za> Message-ID: <1513007085.92.0.213398074469.issue19431@psf.upfronthosting.co.za> STINNER Victor added the comment: > PyFrame_FastToLocals() and PyFrame_LocalsToFast() are not documented and have weird interface. I think the use of them should be discouraged. I suggest to document them, but explain in the documentation that they must not be used :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 10:46:54 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 15:46:54 +0000 Subject: [issue19431] Document PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError() In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za> Message-ID: <1513007214.21.0.213398074469.issue19431@psf.upfronthosting.co.za> STINNER Victor added the comment: Ah, PyFrame_GetLineNumber is now documented at Doc/c-api/reflection.rst. But PyFrame_New() is still not documented. So my patch is not completely useful. @Cheryl: Maybe convert the PR without PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 11:00:46 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 11 Dec 2017 16:00:46 +0000 Subject: [issue32258] Rewrite asyncio docs to use async/await syntax In-Reply-To: <1512813975.64.0.213398074469.issue32258@psf.upfronthosting.co.za> Message-ID: <1513008046.1.0.213398074469.issue32258@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 11:01:57 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 11 Dec 2017 16:01:57 +0000 Subject: [issue32250] Add asyncio.current_task() and asyncio.all_tasks() funcitons In-Reply-To: <1512687842.07.0.213398074469.issue32250@psf.upfronthosting.co.za> Message-ID: <1513008117.58.0.213398074469.issue32250@psf.upfronthosting.co.za> Andrew Svetlov added the comment: In https://github.com/python/cpython/pull/4766 discussion we decided to use module level functions instead of loop methods. ---------- title: Add loop.current_task() and loop.all_tasks() methods -> Add asyncio.current_task() and asyncio.all_tasks() funcitons _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 11:09:05 2017 From: report at bugs.python.org (Marcel Plch) Date: Mon, 11 Dec 2017 16:09:05 +0000 Subject: [issue6531] atexit_callfuncs() crashing within Py_Finalize() when using multiple interpreters. In-Reply-To: <1248175169.79.0.15962102552.issue6531@psf.upfronthosting.co.za> Message-ID: <1513008545.3.0.213398074469.issue6531@psf.upfronthosting.co.za> Marcel Plch added the comment: > At a guess, the problem is because in atexit_callfuncs(): > > module = PyState_FindModule(&atexitmodule); > if (module == NULL) > return; In #31901, I solved this problem by getiing rid of PyState_FindModule in the atexit code, using module state and PEP-489 multiphase initialization. This needed some changes in the pystate and pylifecycle code, so the specific interpreter has a reference to its own atexit module. This way, Py_EndInterpreter() is able to call the callbacks for the given interpreter. See: https://github.com/python/cpython/pull/4611 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 11:43:09 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Mon, 11 Dec 2017 16:43:09 +0000 Subject: [issue11123] problem with packaged dependency extracter script, pdeps In-Reply-To: <1296859283.38.0.970778705728.issue11123@psf.upfronthosting.co.za> Message-ID: <1513010589.04.0.213398074469.issue11123@psf.upfronthosting.co.za> Cheryl Sabella added the comment: This issue was resolved with the patch in #14492. ---------- nosy: +csabella resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> pdeps.py has_key _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 11:46:57 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Dec 2017 16:46:57 +0000 Subject: [issue32251] Add asyncio.BufferedProtocol In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za> Message-ID: <1513010817.71.0.213398074469.issue32251@psf.upfronthosting.co.za> Yury Selivanov added the comment: > See https://eklitzke.org/goroutines-nonblocking-io-and-memory-usage for an interesting discussion of the drawbacks of some buffer handling idioms. Thanks for the link! It does make sense to use a pool of buffers for the proposed BufferedProtocol when you need to keep thousands of long-open connections. The current design makes that easy: when BufferedProtocol.get_buffer() is called you either take a buffer from the pool or allocate a temporary new one. For use-cases like DB connections (asyncpg) a permanently allocated buffer per protocol instance is a good solution too, as usually there's a fairly limited number of open DB connections. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 11:50:18 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 11 Dec 2017 16:50:18 +0000 Subject: [issue32251] Add asyncio.BufferedProtocol In-Reply-To: <1512699039.22.0.213398074469.issue32251@psf.upfronthosting.co.za> Message-ID: <1513011018.08.0.213398074469.issue32251@psf.upfronthosting.co.za> Yury Selivanov added the comment: >> Looks nice. Can it speed up aiohttp too? > Yes. > aiohttp uses own streams but public API and internal implementation are pretty close to asyncio streams. > Moreover C accelerated HTTP parser should work with proposed BufferedProtocol seamlessly. I did some benchmarks, and it looks like BufferedProtocol can make httptools up to 5% faster for relatively small requests < 10Kb. Don't expect big speedups there. For asyncpg, benchmarks that fetch a lot of data (50-100Kb) get faster up to 15%. So we'll definitely use the BufferedProtocol in asyncpg. For applications that need to handle megabytes of data per request (like Antoine's benchmark) the speedup will be up to 2x. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 11:57:52 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 11 Dec 2017 16:57:52 +0000 Subject: [issue31650] implement PEP 552 In-Reply-To: <1506801596.1.0.213398074469.issue31650@psf.upfronthosting.co.za> Message-ID: <1513011472.01.0.213398074469.issue31650@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Looks fine to me now? http://buildbot.python.org/all/#/builders/21 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 12:45:53 2017 From: report at bugs.python.org (Anthony Sottile) Date: Mon, 11 Dec 2017 17:45:53 +0000 Subject: [issue32277] SystemError via chmod(symlink, ..., follow_symlinks=False) Message-ID: <1513014353.51.0.213398074469.issue32277@psf.upfronthosting.co.za> New submission from Anthony Sottile : While investigating https://bugs.python.org/issue31940 I noticed the following is raised as `SystemError` instead of the expected `NotImplementedError` (note: you need a platform with fchmodat but does not support nofollow) ``` touch foo ln -s foo bar python3.6 -c 'import os; os.chmod("bar", 0o666, follow_symlinks=False) ``` Expected: raised `NotImplementedError` Actual: raised `SystemError` ---------- messages: 308062 nosy: Anthony Sottile priority: normal severity: normal status: open title: SystemError via chmod(symlink, ..., follow_symlinks=False) versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 12:54:54 2017 From: report at bugs.python.org (Anthony Sottile) Date: Mon, 11 Dec 2017 17:54:54 +0000 Subject: [issue32277] SystemError via chmod(symlink, ..., follow_symlinks=False) In-Reply-To: <1513014353.51.0.213398074469.issue32277@psf.upfronthosting.co.za> Message-ID: <1513014894.12.0.213398074469.issue32277@psf.upfronthosting.co.za> Change by Anthony Sottile : ---------- keywords: +patch pull_requests: +4696 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 13:05:11 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Mon, 11 Dec 2017 18:05:11 +0000 Subject: [issue31506] Improve the error message logic for object_new & object_init In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za> Message-ID: <1513015511.24.0.213398074469.issue31506@psf.upfronthosting.co.za> Sanyam Khurana added the comment: Serhiy, can you please elaborate on that a bit? I'll try to fix this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 13:18:53 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Dec 2017 18:18:53 +0000 Subject: [issue30050] Please provide a way to disable the warning printed if the signal module's wakeup fd overflows In-Reply-To: <1491987273.45.0.570112423464.issue30050@psf.upfronthosting.co.za> Message-ID: <1513016333.97.0.213398074469.issue30050@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm now well acquainted with with the signal and asyncio modules, but is this the best solution? Wouldn't be better to specify a custom handler? If this is possible. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 13:24:56 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 11 Dec 2017 18:24:56 +0000 Subject: [issue29247] Document return value of epoll.poll In-Reply-To: <1484195034.62.0.718564451527.issue29247@psf.upfronthosting.co.za> Message-ID: <1513016696.54.0.213398074469.issue29247@psf.upfronthosting.co.za> Change by Berker Peksag : ---------- pull_requests: +4697 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 13:25:22 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 11 Dec 2017 18:25:22 +0000 Subject: [issue29247] Document return value of epoll.poll In-Reply-To: <1484195034.62.0.718564451527.issue29247@psf.upfronthosting.co.za> Message-ID: <1513016722.57.0.213398074469.issue29247@psf.upfronthosting.co.za> Change by Berker Peksag : ---------- versions: -Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 13:37:12 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Mon, 11 Dec 2017 18:37:12 +0000 Subject: [issue30050] Please provide a way to disable the warning printed if the signal module's wakeup fd overflows In-Reply-To: <1491987273.45.0.570112423464.issue30050@psf.upfronthosting.co.za> Message-ID: <1513017432.5.0.213398074469.issue30050@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Serhiy: I don't know what "specify a custom handler" means in this context. Can you elaborate? The fd buffer overflow happens in a very delicate context where we definitely cannot call python code or even safely touch PyObject* variables. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 13:38:18 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 11 Dec 2017 18:38:18 +0000 Subject: [issue30050] Please provide a way to disable the warning printed if the signal module's wakeup fd overflows In-Reply-To: <1491987273.45.0.570112423464.issue30050@psf.upfronthosting.co.za> Message-ID: <1513017498.25.0.213398074469.issue30050@psf.upfronthosting.co.za> Antoine Pitrou added the comment: A custom handler would be overkill IMO. set_wakeup_fd() is really useful for a small category of library (most notably event loop frameworks). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 13:42:43 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 11 Dec 2017 18:42:43 +0000 Subject: [issue32250] Add asyncio.current_task() and asyncio.all_tasks() funcitons In-Reply-To: <1512687842.07.0.213398074469.issue32250@psf.upfronthosting.co.za> Message-ID: <1513017763.83.0.213398074469.issue32250@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- pull_requests: +4698 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 13:54:08 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Dec 2017 18:54:08 +0000 Subject: [issue30050] Please provide a way to disable the warning printed if the signal module's wakeup fd overflows In-Reply-To: <1491987273.45.0.570112423464.issue30050@psf.upfronthosting.co.za> Message-ID: <1513018448.19.0.213398074469.issue30050@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I meant a callback that will be called after writing a byte to the wakeup fd is failed. By default it would write a warning to stderr, but the user could specify other callback for silencing a warning or for using other way for logging it. If this is impossible or overkill I have no other questions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 14:33:40 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Dec 2017 19:33:40 +0000 Subject: [issue27645] Supporting native backup facility of SQLite In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za> Message-ID: <1513020820.37.0.213398074469.issue27645@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I prefer to keep Connection.backup() simpler. Additional features can be implemented in pure Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 14:36:53 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Dec 2017 19:36:53 +0000 Subject: [issue30050] Please provide a way to disable the warning printed if the signal module's wakeup fd overflows In-Reply-To: <1513017498.25.0.213398074469.issue30050@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: As I wrote, I never saw this warning, even while debugging signal issues in asyncio on FreeBSD. I don't think that this is an use case for a callback. Nathaniel use case is just to ignore the warning, I consider that it's a reasonable compromise for the issue. If someone wants a more advanced signal handler, it's still possible to use register a custom signal handler at the C level. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 14:46:28 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Dec 2017 19:46:28 +0000 Subject: [issue32277] SystemError via chmod(symlink, ..., follow_symlinks=False) In-Reply-To: <1513014353.51.0.213398074469.issue32277@psf.upfronthosting.co.za> Message-ID: <1513021588.09.0.213398074469.issue32277@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Does any existing test failed on such platform? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 14:46:45 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Dec 2017 19:46:45 +0000 Subject: [issue32277] SystemError via chmod(symlink, ..., follow_symlinks=False) In-Reply-To: <1513014353.51.0.213398074469.issue32277@psf.upfronthosting.co.za> Message-ID: <1513021605.59.0.213398074469.issue32277@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- components: +Extension Modules type: -> behavior versions: -Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 14:47:31 2017 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 11 Dec 2017 19:47:31 +0000 Subject: [issue32278] Allow dataclasses.make_dataclass() to omit type information Message-ID: <1513021651.3.0.213398074469.issue32278@psf.upfronthosting.co.za> New submission from Eric V. Smith : Make the typing information optional. >From Raymond Hettinger: The make_dataclass() factory function in the dataclasses module currently requires type declarations. It would be nice if the type declarations were optional. With typing (currently works): Point = NamedTuple('Point', [('x', float), ('y', float), ('z', float)]) Point = make_dataclass('Point', [('x', float), ('y', float), ('z', float)]) Without typing (only the first currently works): Point = namedtuple('Point', ['x', 'y', 'z']) # underlying store is a tuple Point = make_dataclass('Point', ['x', 'y', 'z']) # underlying store is an instance dict ---------- assignee: eric.smith components: Library (Lib) messages: 308071 nosy: eric.smith, levkivskyi, rhettinger priority: normal severity: normal status: open title: Allow dataclasses.make_dataclass() to omit type information type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 14:51:03 2017 From: report at bugs.python.org (Anthony Sottile) Date: Mon, 11 Dec 2017 19:51:03 +0000 Subject: [issue32277] SystemError via chmod(symlink, ..., follow_symlinks=False) In-Reply-To: <1513014353.51.0.213398074469.issue32277@psf.upfronthosting.co.za> Message-ID: <1513021863.05.0.213398074469.issue32277@psf.upfronthosting.co.za> Anthony Sottile added the comment: I noticed it when I changed the test preconditions in https://github.com/python/cpython/pull/4783 I tried changing a test to trigger this (in this branch) but I found I was just implementing exactly the test in the `skip` condition which to me didn't feel like a very valuable test. >From what I can tell, the current testsuite passes on my machine before and after this change -- only with the small reproduction. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 14:52:44 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Dec 2017 19:52:44 +0000 Subject: [issue31643] test_uuid: test_getnode and test_windll_getnode fail if connected to the Internet via an Android phone In-Reply-To: <1506721038.97.0.213398074469.issue31643@psf.upfronthosting.co.za> Message-ID: <1513021964.72.0.213398074469.issue31643@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- nosy: +barry, serhiy.storchaka, xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 14:56:06 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Dec 2017 19:56:06 +0000 Subject: [issue29137] Fix fpectl-induced ABI breakage In-Reply-To: <1483402510.43.0.646850547969.issue29137@psf.upfronthosting.co.za> Message-ID: <1513022166.63.0.213398074469.issue29137@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- nosy: +rhettinger, stutzbach, twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 14:56:29 2017 From: report at bugs.python.org (Lele Gaifax) Date: Mon, 11 Dec 2017 19:56:29 +0000 Subject: [issue27645] Supporting native backup facility of SQLite In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za> Message-ID: <1513022189.46.0.213398074469.issue27645@psf.upfronthosting.co.za> Lele Gaifax added the comment: Thank you Serhiy, ok: will simplify the method, hopefully tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 14:58:58 2017 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 11 Dec 2017 19:58:58 +0000 Subject: [issue32279] Pass keyword arguments from dataclasses.make_dataclass() to @dataclass. Message-ID: <1513022338.87.0.213398074469.issue32279@psf.upfronthosting.co.za> New submission from Eric V. Smith : make_dataclass() should take optional keyword only arguments and pass them to @dataclass() when it uses it after it creates a new class. The parameters are: init=True, repr=True, eq=True, order=False, hash=None, frozen=False Obviously, these should reflect their default values in @dataclass, should that ever change. ---------- assignee: eric.smith components: Library (Lib) messages: 308074 nosy: eric.smith, levkivskyi, rhettinger priority: normal severity: normal status: open title: Pass keyword arguments from dataclasses.make_dataclass() to @dataclass. versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 15:25:51 2017 From: report at bugs.python.org (kernc) Date: Mon, 11 Dec 2017 20:25:51 +0000 Subject: [issue29620] unittest.TestCase.assertWarns raises RuntimeEror if sys.modules changes size In-Reply-To: <1487780571.93.0.503711972358.issue29620@psf.upfronthosting.co.za> Message-ID: <1513023951.09.0.213398074469.issue29620@psf.upfronthosting.co.za> Change by kernc : ---------- keywords: +patch pull_requests: +4699 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 16:56:33 2017 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 11 Dec 2017 21:56:33 +0000 Subject: [issue32227] singledispatch support for type annotations In-Reply-To: <1512509052.55.0.213398074469.issue32227@psf.upfronthosting.co.za> Message-ID: <1513029393.77.0.213398074469.issue32227@psf.upfronthosting.co.za> ?ukasz Langa added the comment: New changeset e56975351bc2c574c728f738e88effba7116279f by ?ukasz Langa in branch 'master': bpo-32227: functools.singledispatch supports registering via type annotations (#4733) https://github.com/python/cpython/commit/e56975351bc2c574c728f738e88effba7116279f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 17:07:06 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Dec 2017 22:07:06 +0000 Subject: [issue32240] Add the const qualifier for PyObject* array arguments In-Reply-To: <1512645701.53.0.213398074469.issue32240@psf.upfronthosting.co.za> Message-ID: <1513030026.51.0.213398074469.issue32240@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This can affect Cython which uses the "fast call" convention. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 18:12:36 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Mon, 11 Dec 2017 23:12:36 +0000 Subject: [issue19431] Document PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError() In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za> Message-ID: <1513033956.04.0.213398074469.issue19431@psf.upfronthosting.co.za> Cheryl Sabella added the comment: Thanks Victor and Serhiy. >> @Cheryl: Maybe convert the PR without PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError(). If I only convert PyFrame_New() then I would need to add it to as existing page since the patch created a new page for Frame Objects. I think the right place would be under the current PyFrameObject in Doc/c-api/veryhigh.rst? Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 18:24:10 2017 From: report at bugs.python.org (Lior Cohen) Date: Mon, 11 Dec 2017 23:24:10 +0000 Subject: [issue26103] Contradiction in definition of "data descriptor" between (dotted lookup behavior/datamodel documentation) and (inspect lib/descriptor how-to) In-Reply-To: <1452718612.1.0.925403449689.issue26103@psf.upfronthosting.co.za> Message-ID: <1513034650.05.0.213398074469.issue26103@psf.upfronthosting.co.za> Lior Cohen added the comment: Joining @Serhiy Storchaka last question. Is the __get__ method existance is a must be a data descriptor? According to the C implementation in descrobject.h ``` #define PyDescr_IsData(d) (Py_TYPE(d)->tp_descr_set != NULL) #endif ``` the answer is No. Does this C code reflect the true definition? ---------- nosy: +chnlior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 18:24:41 2017 From: report at bugs.python.org (Maxime Belanger) Date: Mon, 11 Dec 2017 23:24:41 +0000 Subject: [issue32280] Expose `_PyRuntime` through a section name Message-ID: <1513034681.19.0.213398074469.issue32280@psf.upfronthosting.co.za> New submission from Maxime Belanger : We've recently been toying with more sophisticated crash reporting machinery for our Desktop Python application (which we deploy on macOS, Windows and Linux). To assist in debugging, we are storing `_PyRuntime` in a predictable location our crash reporter can later look up without needing the symbol table (this can grow complicated across multiple platforms). Taking a page from `crashpad`'s book (https://chromium.googlesource.com/crashpad/crashpad/+/master/client/crashpad_info.cc), we've patched `pylifecycle.c` to store the `_PyRuntime` struct in a section of the same name. Upon a crash, this section is then used by the tool to annotate each report with enough information to reconstruct the Python stack frames in each thread (as applicable). We're contributing our patch here in the hopes this can be helpful to others. ---------- components: Interpreter Core, Windows, macOS messages: 308079 nosy: Maxime Belanger, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Expose `_PyRuntime` through a section name type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 18:26:49 2017 From: report at bugs.python.org (Ben Hyde) Date: Mon, 11 Dec 2017 23:26:49 +0000 Subject: [issue32281] bdist_rpm v.s. the Macintosh Message-ID: <1513034809.77.0.213398074469.issue32281@psf.upfronthosting.co.za> New submission from Ben Hyde : With the fix below is becomes possible to build rpms on the Mac. The developer will need to install rpm tooling. That's easy via "brew install rpm". That, for example, installs /usr/local/bin/rpmbuild. Sadly bdist_rpm.py only supports rpmbuild in two places, see: https://github.com/python/cpython/blob/6f0eb93183519024cb360162bdd81b9faec97ba6/Lib/distutils/command/bdist_rpm.py#L313 Which due to the Mac's fastidious security setup we are very strongly discouraged from working around. So, yeah, let's add a third, like so maybe: if ((os.path.exists('/usr/bin/rpmbuild') or os.path.exists('/bin/rpmbuild') or os.path.exists('/usr/local/bin/rpmbuild'))): rpm_cmd = ['rpmbuild'] And now I can use build_rpm on my mac, oh joy. ---------- components: Distutils messages: 308080 nosy: bhyde, dstufft, eric.araujo priority: normal severity: normal status: open title: bdist_rpm v.s. the Macintosh type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 18:35:16 2017 From: report at bugs.python.org (Steve Dower) Date: Mon, 11 Dec 2017 23:35:16 +0000 Subject: [issue32280] Expose `_PyRuntime` through a section name In-Reply-To: <1513034681.19.0.213398074469.issue32280@psf.upfronthosting.co.za> Message-ID: <1513035316.36.0.213398074469.issue32280@psf.upfronthosting.co.za> Change by Steve Dower : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 18:35:25 2017 From: report at bugs.python.org (Steve Dower) Date: Mon, 11 Dec 2017 23:35:25 +0000 Subject: [issue32280] Expose `_PyRuntime` through a section name In-Reply-To: <1513034681.19.0.213398074469.issue32280@psf.upfronthosting.co.za> Message-ID: <1513035325.82.0.213398074469.issue32280@psf.upfronthosting.co.za> Change by Steve Dower : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 18:40:44 2017 From: report at bugs.python.org (=?utf-8?q?Max_B=C3=A9langer?=) Date: Mon, 11 Dec 2017 23:40:44 +0000 Subject: [issue32280] Expose `_PyRuntime` through a section name In-Reply-To: <1513034681.19.0.213398074469.issue32280@psf.upfronthosting.co.za> Message-ID: <1513035644.92.0.213398074469.issue32280@psf.upfronthosting.co.za> Change by Max B?langer : ---------- keywords: +patch pull_requests: +4700 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 19:00:54 2017 From: report at bugs.python.org (Maxime Belanger) Date: Tue, 12 Dec 2017 00:00:54 +0000 Subject: [issue32282] When using a Windows XP compatible toolset, `socketmodule.c` fails to build Message-ID: <1513036854.54.0.213398074469.issue32282@psf.upfronthosting.co.za> New submission from Maxime Belanger : If Python is built using the Windows XP "variant" of the toolset (e.g. `v140_xp`), build errors can occur in `socketmodule.c`. This is due to the include of `VersionHelpers.h` being gated on `_MSC_VER`, which "lies" if `v140_xp` is in use. We'll be contributing our patch to this issue here. ---------- components: Windows messages: 308081 nosy: Maxime Belanger, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: When using a Windows XP compatible toolset, `socketmodule.c` fails to build versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 19:00:54 2017 From: report at bugs.python.org (Ivan Pozdeev) Date: Tue, 12 Dec 2017 00:00:54 +0000 Subject: [issue31643] test_uuid: test_getnode and test_windll_getnode fail if connected to the Internet via an Android phone In-Reply-To: <1506721038.97.0.213398074469.issue31643@psf.upfronthosting.co.za> Message-ID: <1513036854.77.0.213398074469.issue31643@psf.upfronthosting.co.za> Change by Ivan Pozdeev : ---------- pull_requests: +4701 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 19:04:37 2017 From: report at bugs.python.org (=?utf-8?q?Max_B=C3=A9langer?=) Date: Tue, 12 Dec 2017 00:04:37 +0000 Subject: [issue32282] When using a Windows XP compatible toolset, `socketmodule.c` fails to build In-Reply-To: <1513036854.54.0.213398074469.issue32282@psf.upfronthosting.co.za> Message-ID: <1513037077.02.0.213398074469.issue32282@psf.upfronthosting.co.za> Change by Max B?langer : ---------- keywords: +patch pull_requests: +4702 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 19:20:54 2017 From: report at bugs.python.org (Kevin Lyda) Date: Tue, 12 Dec 2017 00:20:54 +0000 Subject: [issue32283] Cmd.onecmd documentation is misleading Message-ID: <1513038054.93.0.213398074469.issue32283@psf.upfronthosting.co.za> New submission from Kevin Lyda : The documentation for Cmd.onecmd is misleading. It says that "This may be overridden, but should not normally need to be; see the precmd() and postcmd() methods for useful execution hooks." https://github.com/python/cpython/blob/v3.7.0a3/Lib/cmd.py#L193 However a common idiom is to call onecmd directly to process commands coming from sys.argv. This shows up in the Cmd entries the Python MOTW site for instance. https://pymotw.com/3/cmd/#commands-from-sys-argv >From the docs you might think that precmd and postcmd are called when you call onecmd directly this way. However this is not true - they are only called in the cmdloop method. https://github.com/python/cpython/blob/v3.7.0a3/Lib/cmd.py#L137 Moving the precmd and postcmd methods into onecmd would make the onecmd docs make more sense. Then they could be used in lieu of overriding onecmd for all uses of onecmd - inside of cmdloop and on its own. But loads of code depends on current behaviour. So instead something in the docs to indicate that those hooks only work when onecmd is called inside cmdloop would be good. Perhaps like so: """Interpret the argument as though it had been typed in response to the prompt. This may be overridden, but should not normally need to be; see the precmd() and postcmd() methods for useful execution hooks when onecmd() is called from cmdloop(). When onecmd() is called directly, make sure to call precmd() and postcmd() yourself. The return value is a flag indicating whether interpretation of commands by the interpreter should stop. """ ---------- components: Library (Lib) messages: 308082 nosy: lyda priority: normal severity: normal status: open title: Cmd.onecmd documentation is misleading versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 19:34:35 2017 From: report at bugs.python.org (Sebastian Rittau) Date: Tue, 12 Dec 2017 00:34:35 +0000 Subject: [issue32284] typing.TextIO and BinaryIO are not aliases of IO[...] Message-ID: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za> New submission from Sebastian Rittau : See https://github.com/python/typing/issues/518 for context. The typing documentation for 3.6.4rc1 states: > typing.io ... defines the generic type IO[AnyStr] and aliases TextIO and BinaryIO for respectively IO[str] and IO[bytes]. In the current implementation TextIO and BinaryIO are not aliases, but instead derived from IO. This means that values of type IO[...], and especially IO[Any] can not be assigned where TextIO or BinaryIO is expected. ---------- assignee: docs at python components: Documentation messages: 308083 nosy: docs at python, srittau priority: normal severity: normal status: open title: typing.TextIO and BinaryIO are not aliases of IO[...] versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 19:37:33 2017 From: report at bugs.python.org (kyuupichan) Date: Tue, 12 Dec 2017 00:37:33 +0000 Subject: [issue29970] Severe open file leakage running asyncio SSL server In-Reply-To: <1491228615.05.0.224246839796.issue29970@psf.upfronthosting.co.za> Message-ID: <1513039053.62.0.213398074469.issue29970@psf.upfronthosting.co.za> kyuupichan added the comment: I'm not sure what you mean about this being a server-specific problem. It's clearly a bug in the asyncio SSL wrapper as using TCP instead of SSL with otherwise identical code doesn't leak open files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 20:16:10 2017 From: report at bugs.python.org (Maxime Belanger) Date: Tue, 12 Dec 2017 01:16:10 +0000 Subject: [issue32285] In `unicodedata`, it should be possible to check a unistr's normal form without necessarily copying it Message-ID: <1513041370.04.0.213398074469.issue32285@psf.upfronthosting.co.za> New submission from Maxime Belanger : In our deployment of Python 2.7, we've patched `unicodedata` to introduce a new function: `is_normalized` can check whether a unistr is in a given normal form. This currently has to be done by creating a normalized copy, then checking whether it is equal to the source string. This function uses the internal helper (also called `is_normalized`) that can "quick check" normalization, but falls back on creating a normalized copy and comparing (when necessary). We're contributing this change in case this can helpful to others. Feedback is welcome! ---------- components: Unicode messages: 308085 nosy: Maxime Belanger, ezio.melotti, vstinner priority: normal severity: normal status: open title: In `unicodedata`, it should be possible to check a unistr's normal form without necessarily copying it versions: Python 2.7, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 20:19:59 2017 From: report at bugs.python.org (=?utf-8?q?Max_B=C3=A9langer?=) Date: Tue, 12 Dec 2017 01:19:59 +0000 Subject: [issue32285] In `unicodedata`, it should be possible to check a unistr's normal form without necessarily copying it In-Reply-To: <1513041370.04.0.213398074469.issue32285@psf.upfronthosting.co.za> Message-ID: <1513041599.77.0.213398074469.issue32285@psf.upfronthosting.co.za> Change by Max B?langer : ---------- keywords: +patch pull_requests: +4703 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 20:41:34 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Tue, 12 Dec 2017 01:41:34 +0000 Subject: [issue26256] Fast decimalisation and conversion to other bases In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za> Message-ID: <1513042894.17.0.213398074469.issue26256@psf.upfronthosting.co.za> Change by Cheryl Sabella : ---------- keywords: +patch pull_requests: +4704 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 20:43:28 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Tue, 12 Dec 2017 01:43:28 +0000 Subject: [issue26256] Fast decimalisation and conversion to other bases In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za> Message-ID: <1513043008.11.0.213398074469.issue26256@psf.upfronthosting.co.za> Change by Cheryl Sabella : ---------- versions: +Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 20:52:44 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Tue, 12 Dec 2017 01:52:44 +0000 Subject: [issue17013] Allow waiting on a mock In-Reply-To: <1358856947.82.0.71016271567.issue17013@psf.upfronthosting.co.za> Message-ID: <1513043564.13.0.213398074469.issue17013@psf.upfronthosting.co.za> Change by Cheryl Sabella : ---------- stage: -> needs patch versions: +Python 3.8 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 21:00:42 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Tue, 12 Dec 2017 02:00:42 +0000 Subject: [issue18533] Avoid error from repr() of recursive dictview In-Reply-To: <1374531750.42.0.70756948567.issue18533@psf.upfronthosting.co.za> Message-ID: <1513044042.22.0.213398074469.issue18533@psf.upfronthosting.co.za> Cheryl Sabella added the comment: Ben, would you be interested in making a Github pull request against the current master for your patch? It appears there was interest in moving forward with this and it is still occurring on 3.7, although it now raises a RecursionError. >>> d = {} >>> d[1] = d.keys() >>> d {1: dict_keys([1])} >>> d[2] = d.values() >>> d Traceback (most recent call last): File "", line 1, in RecursionError: maximum recursion depth exceeded while getting the repr of an object ---------- nosy: +csabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 21:17:53 2017 From: report at bugs.python.org (Ivan Pozdeev) Date: Tue, 12 Dec 2017 02:17:53 +0000 Subject: [issue31643] test_uuid: test_getnode and test_windll_getnode fail if connected to the Internet via an Android phone In-Reply-To: <1506721038.97.0.213398074469.issue31643@psf.upfronthosting.co.za> Message-ID: <1513045073.42.0.213398074469.issue31643@psf.upfronthosting.co.za> Change by Ivan Pozdeev : Removed file: https://bugs.python.org/file47178/0001-Allow-for-all-zero-MAC-based-node-ID-e.g.-mobile-mod.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 21:57:47 2017 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 12 Dec 2017 02:57:47 +0000 Subject: [issue32284] typing.TextIO and BinaryIO are not aliases of IO[...] In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za> Message-ID: <1513047467.17.0.213398074469.issue32284@psf.upfronthosting.co.za> Guido van Rossum added the comment: This doc bug should be fixed before 3.6.4 final goes out. ---------- nosy: +gvanrossum, ned.deily priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 11 23:29:10 2017 From: report at bugs.python.org (Kevin Chen) Date: Tue, 12 Dec 2017 04:29:10 +0000 Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za> Message-ID: <1513052950.93.0.213398074469.issue20891@psf.upfronthosting.co.za> Change by Kevin Chen : ---------- nosy: +kchen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 00:30:57 2017 From: report at bugs.python.org (Eryk Sun) Date: Tue, 12 Dec 2017 05:30:57 +0000 Subject: [issue32245] OSError: raw write() returned invalid length on latest Win 10 Consoles In-Reply-To: <1512660082.17.0.213398074469.issue32245@psf.upfronthosting.co.za> Message-ID: <1513056657.25.0.213398074469.issue32245@psf.upfronthosting.co.za> Eryk Sun added the comment: I was able to reproduce this problem in 3.6 in Windows 10 (1709), but only for code paths that call WriteFile, i.e. os.write and legacy standard I/O mode. Writing to the console will block if there's an active text selection. The operation completes once the user copies the selection to the clipboard (e.g. by pressing enter). In the case of WriteFile, when the blocked call finally completes, the console mistakenly returns the number of internally written UTF-16 bytes. This bug is not present with WriteConsoleA, which means there's a simple workaround. _Py_write could detect a console handle and call WriteConsoleA instead of _write. The following test executes a write on a separate thread, after a timed delay that allows selecting text beforehand. Text can be selected via Ctrl+A, Shift+Up, or the mouse (the latter requires quick-edit mode or toggling mark mode). import os import sys import ctypes import msvcrt import threading kernel32 = ctypes.WinDLL('kernel32', use_last_error=True) fd_stdout = sys.stdout.fileno() h_stdout = msvcrt.get_osfhandle(fd_stdout) n = ctypes.c_ulong() def test_write(): n.value = os.write(fd_stdout, b'spam\r\n') def test_WriteFile(): kernel32.WriteFile(h_stdout, b'spam\r\n', 6, ctypes.byref(n), None) def test_WriteConsoleA(): kernel32.WriteConsoleA(h_stdout, b'spam\r\n', 6, ctypes.byref(n), None) For example, given manual text selection after starting the timer: >>> threading.Timer(5, test_write).start() >>> spam >>> n c_ulong(12) >>> threading.Timer(5, test_WriteFile).start() >>> spam >>> n c_ulong(12) >>> threading.Timer(5, test_WriteConsoleA).start() >>> spam >>> n c_ulong(6) This test could be completely automated by combining SendInput (to set the session control-key state), GetConsoleWindow, and PostMessageW (WM_KEYDOWN, WM_KEYUP). ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 01:14:49 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Tue, 12 Dec 2017 06:14:49 +0000 Subject: [issue30050] Please provide a way to disable the warning printed if the signal module's wakeup fd overflows In-Reply-To: <1491987273.45.0.570112423464.issue30050@psf.upfronthosting.co.za> Message-ID: <1513059289.16.0.213398074469.issue30050@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Yeah, I agree with Antoine and Victor that a callback would be overkill, and it would be extremely difficult to implement since at the point where the error occurs, we don't have and can't take the GIL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 02:17:05 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 12 Dec 2017 07:17:05 +0000 Subject: [issue31650] implement PEP 552 In-Reply-To: <1506801596.1.0.213398074469.issue31650@psf.upfronthosting.co.za> Message-ID: <1513063025.31.0.213398074469.issue31650@psf.upfronthosting.co.za> Change by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 02:55:54 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Tue, 12 Dec 2017 07:55:54 +0000 Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za> Message-ID: <1513065354.82.0.213398074469.issue30491@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Update! I've been experimenting with this some more, and here's a more detailed proposal, that I'd ideally like to get into 3.7. I don't *think* this is big enough to need a PEP? I dunno, thoughts on that welcome. Motivation: It's easy to accidentally write 'f()' where you meant 'await f()', which is why Python issues a warning whenever an unawaited coroutine is GCed. This helps, and for asyncio proper, it may not be possible to do better than this -- since the problem is detected at GC time, there's very little we can do *except* print a warning. In particular, we can't raise an error. But this warning is still easy to miss, and prone to obscure problems: it's easy to have a test that passes ... because it didn't actually run any code. And then the warning is attached to a different test entirely. But, in some specific cases, we could do better: for example, if pytest-asyncio could check for unawaited coroutines after each test, it could immediately raise a proper and detailed error on the correct test. And if trio could check for unawaited coroutines at selected points like schedule points, it could reliably detect these problems and raise them as errors, right at the source. Specification: We add two new functions, sys.set_unawaited_coroutine_tracking(enabled: bool) -> None and sys.collect_unawaited_coroutines() -> List[Coroutine]. The semantics are: internally, there is a thread-local bool I'll call tracking_enabled that defaults to False. set_unawaited_coroutine_tracking lets you set it. If tracking_enabled == False, everything works like now. If tracking_enabled == True, then the interpreter internally keeps a table of all unawaited coroutine objects: when a coroutine object is created, it's automatically added to the table; when it's awaited, it's automatically removed. When collect_unawaited_coroutines is called, it returns the current contents of the table as a list, and clears it. The table holds a strong reference to the coroutines in it, which makes this is a simple and reliable way to track unawaited coroutines (but also means that we need the enable/disable API instead of leaving it on all the time, because once it's enabled someone needs to call collect_unawaited_coroutines regularly to avoid a memory leak). Implementation: this can be made fast and cheap by storing the table as a thread-specific intrusive double-linked list. Basically each coroutine object would gain two pointer slots (this adds a small amount of memory overhead, but a coroutine object + frame is already >500 bytes, so the relative overhead is low), which are used to link it into a list when it's created (O(1), very cheap), and then unlink it again when it's awaited (also O(1), very cheap). Rejected alternatives: - The original comment above suggested keeping a count of unawaited coroutines instead of tracking the actual objects, but this way is just about as cheap while (a) allowing for much better debugging information when an unawaited coroutine is detected, since you have the actual objects there and (b) avoiding a mess of issues around unawaited coroutines that get GCed before the user checks for them. - What about using the existing coroutine wrapper hook? You could do this, but this proposal has two advantages. First, it's much faster, which is important because Trio wants to run with this enabled by default, and pytest-asyncio doesn't want to slow down everyone's test suites too much. (I should benchmark this properly, but in general the coroutine wrappers add a ton of overhead b/c they're effectively a whole new Python-level object being allocated on every function call.) And second, since the coroutine wrapper hook is such a generic mechanism, it's prone to collisions between different uses. For example, pytest-asyncio's unawaited coroutine detection and asyncio's debug mode seem like they ought to complement each other: pytest-asyncio finds the problematic coroutines, and then asyncio's debug mode gives the details on where they came from. But if they're both trying to use the same coroutine wrapper hook, then they'll end up fighting over it. So this proposal follows Python's general rule that generic hooks are fine when you really need an escape hatch, but if there's a specific use case it's often worth handling it specifically. (Recent example: module __class__ assignment vs. PEP 562.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 02:57:42 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Tue, 12 Dec 2017 07:57:42 +0000 Subject: [issue32284] typing.TextIO and BinaryIO are not aliases of IO[...] In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za> Message-ID: <1513065462.4.0.213398074469.issue32284@psf.upfronthosting.co.za> Change by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 03:20:10 2017 From: report at bugs.python.org (wangtie) Date: Tue, 12 Dec 2017 08:20:10 +0000 Subject: [issue32286] python 2.7 cannot parse '' Message-ID: <1513066810.97.0.213398074469.issue32286@psf.upfronthosting.co.za> New submission from wangtie : I have a txt file,use code UTF-8,and include char ''(ASCII code?), when use f.readlines() to get a list, the program exit without any exception,then I got a list without data after line which include char ''. ---------- components: Unicode files: b.txt messages: 308091 nosy: ezio.melotti, vstinner, wt19880712wt priority: normal severity: normal status: open title: python 2.7 cannot parse '' versions: Python 2.7 Added file: https://bugs.python.org/file47331/b.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 03:21:54 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Dec 2017 08:21:54 +0000 Subject: [issue32226] Implement PEP 560: Core support for typing module and generic types In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za> Message-ID: <1513066914.19.0.213398074469.issue32226@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As for __class_getitem__, why not implement type.__getitem__ instead of hacking PyObject_GetItem()? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 03:22:59 2017 From: report at bugs.python.org (wangtie) Date: Tue, 12 Dec 2017 08:22:59 +0000 Subject: [issue32286] python 2.7 cannot parse '' In-Reply-To: <1513066810.97.0.213398074469.issue32286@psf.upfronthosting.co.za> Message-ID: <1513066979.56.0.213398074469.issue32286@psf.upfronthosting.co.za> wangtie added the comment: My ENV: Python 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:24:40) [MSC v.1500 64 bit ( AMD64)] on win32 ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 03:49:49 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 08:49:49 +0000 Subject: [issue32286] python 2.7 cannot parse '' In-Reply-To: <1513066810.97.0.213398074469.issue32286@psf.upfronthosting.co.za> Message-ID: <1513068589.85.0.213398074469.issue32286@psf.upfronthosting.co.za> STINNER Victor added the comment: Your file is not properly encoded to UTF-8: the Python 2 UTF-8 raises UnicodeDecodeError. Sorry but this is not a bug in Python, but a bug on your side. Please ask such question on the forum to ask Python questions like Stackoverflow or anything else. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 03:51:19 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 08:51:19 +0000 Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za> Message-ID: <1513068679.05.0.213398074469.issue30491@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 03:51:31 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 12 Dec 2017 08:51:31 +0000 Subject: [issue32276] there is no way to make tempfile reproducible (i.e. seed the used RNG) In-Reply-To: <1513002327.33.0.213398074469.issue32276@psf.upfronthosting.co.za> Message-ID: <1513068691.27.0.213398074469.issue32276@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'm suspect this not would be wise thing to do. Have you seen any precedent for this in other languages? ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 03:55:37 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 08:55:37 +0000 Subject: [issue31650] implement PEP 552 In-Reply-To: <1506801596.1.0.213398074469.issue31650@psf.upfronthosting.co.za> Message-ID: <1513068937.45.0.213398074469.issue31650@psf.upfronthosting.co.za> STINNER Victor added the comment: The test failed on s390x RHEL 3.x, PPC64 Fedora 3.x, s390x SLES 3.x, s390x Debian 3.x, s390x RHEL 3.x They are now all green, good! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 04:01:01 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 12 Dec 2017 09:01:01 +0000 Subject: [issue31643] test_uuid: test_getnode and test_windll_getnode fail if connected to the Internet via an Android phone In-Reply-To: <1506721038.97.0.213398074469.issue31643@psf.upfronthosting.co.za> Message-ID: <1513069261.93.0.213398074469.issue31643@psf.upfronthosting.co.za> Xavier de Gaye added the comment: On a Samsung device with Android 5.1 and tethering enabled, only one network device has a MAC address and it is not an all-zero MAC address. Ivan can you please provide more information about this problem: which device, what Android version, what is the output of 'ip link' ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 04:01:07 2017 From: report at bugs.python.org (Julien Palard) Date: Tue, 12 Dec 2017 09:01:07 +0000 Subject: [issue32276] there is no way to make tempfile reproducible (i.e. seed the used RNG) In-Reply-To: <1513002327.33.0.213398074469.issue32276@psf.upfronthosting.co.za> Message-ID: <1513069267.31.0.213398074469.issue32276@psf.upfronthosting.co.za> Julien Palard added the comment: Or is there any issue that would have been easier to fix with reproductible temporary file names? ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 04:05:51 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 09:05:51 +0000 Subject: [issue30050] Please provide a way to disable the warning printed if the signal module's wakeup fd overflows In-Reply-To: <1491987273.45.0.570112423464.issue30050@psf.upfronthosting.co.za> Message-ID: <1513069551.02.0.213398074469.issue30050@psf.upfronthosting.co.za> STINNER Victor added the comment: > it would be extremely difficult to implement since at the point where the error occurs, we don't have and can't take the GIL. The signal handler uses Py_AddPendingCall() which calls a C function "later", but it can be anytime, between two Python instruction. If the callback fails, it can be annoying to get an error "anywhere". It can be even worse if the callback only fails if we are calling a specific function. Handling signals is very tricky, it's hard to "get it right". For example, Py_AddPendingCall() has an hardcoded queue of 32 callbacks. If the queue is full... the callback is lost... Py_AddPendingCall() also tries to acquire a lock... from a signal handler... Probably the worst idea... But that's another idea :-) /* try a few times for the lock. Since this mechanism is used * for signal handling (on the main thread), there is a (slim) * chance that a signal is delivered on the same thread while we * hold the lock during the Py_MakePendingCalls() function. * This avoids a deadlock in that case. * Note that signals can be delivered on any thread. In particular, * on Windows, a SIGINT is delivered on a system-created worker * thread. * We also check for lock being NULL, in the unlikely case that * this function is called before any bytecode evaluation takes place. */ if (lock != NULL) { for (i = 0; i<100; i++) { if (PyThread_acquire_lock(lock, NOWAIT_LOCK)) break; } if (i == 100) return -1; } We may also get a new signal while handling a signal... Currently, the Windows implementation of the signal handler remembers if there is pending call to report_wakeup_send_error(), so it doesn't fill the pending call callback queue. But the Linux implementation doesn't. With Nathaniel's PR, the queue is always filled. I'm not sure that it's ideal, but it's also hard to handle synchronization here so I didn't complain :-) Always calling Py_AddPendingCall() does work for the signal module, but it may prevent other functions to schedule a pending call later. In practice, in CPython, only the signal handler calls Py_AddPendingCall() :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 04:39:32 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Dec 2017 09:39:32 +0000 Subject: [issue31643] test_uuid: test_getnode and test_windll_getnode fail if connected to the Internet via an Android phone In-Reply-To: <1506721038.97.0.213398074469.issue31643@psf.upfronthosting.co.za> Message-ID: <1513071572.97.0.213398074469.issue31643@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm not sure that 000000000000 is better than a random address. Even if an all-zero MAC address is not explicitly prohibited it is used in a multiple independent devices. A random address looks more appropriate fore the purpose of generating a UUID. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 04:49:21 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Dec 2017 09:49:21 +0000 Subject: [issue32226] Implement PEP 560: Core support for typing module and generic types In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za> Message-ID: <1513072161.58.0.213398074469.issue32226@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For reference: PEP 560. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 04:57:09 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Dec 2017 09:57:09 +0000 Subject: [issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n' In-Reply-To: <1512744234.4.0.213398074469.issue32255@psf.upfronthosting.co.za> Message-ID: <1513072629.49.0.213398074469.issue32255@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 2001900b0c02a397d8cf1d776a7cc7fcb2a463e3 by Serhiy Storchaka (Licht Takeuchi) in branch 'master': bpo-32255: Always quote a single empty field when write into a CSV file. (#4769) https://github.com/python/cpython/commit/2001900b0c02a397d8cf1d776a7cc7fcb2a463e3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 04:57:18 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 Dec 2017 09:57:18 +0000 Subject: [issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n' In-Reply-To: <1512744234.4.0.213398074469.issue32255@psf.upfronthosting.co.za> Message-ID: <1513072638.89.0.213398074469.issue32255@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4705 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 04:58:03 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Dec 2017 09:58:03 +0000 Subject: [issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n' In-Reply-To: <1512744234.4.0.213398074469.issue32255@psf.upfronthosting.co.za> Message-ID: <1513072683.45.0.213398074469.issue32255@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution Licht! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 05:21:25 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 12 Dec 2017 10:21:25 +0000 Subject: [issue31643] test_uuid: test_getnode and test_windll_getnode fail if connected to the Internet via an Android phone In-Reply-To: <1506721038.97.0.213398074469.issue31643@psf.upfronthosting.co.za> Message-ID: <1513074085.52.0.213398074469.issue31643@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > I'm not sure that 000000000000 is better than a random address. I agree, getnode() when obtained from a MAC address should not return 0. RFC 4122 states (emphasis on 'uniqueness' is mine): This document specifies three algorithms to generate UUIDs: the first leverages the unique values of 802 MAC addresses to guarantee *uniqueness*, ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 05:22:37 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 10:22:37 +0000 Subject: [issue31942] Document that support of start and stop parameters in the Sequence's index() is optional In-Reply-To: <1509786601.53.0.213398074469.issue31942@psf.upfronthosting.co.za> Message-ID: <1513074157.86.0.213398074469.issue31942@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 5ce0a2a100909104836f53a2c8823006ec46f8ad by Victor Stinner (Nitish Chandra) in branch 'master': bpo-31942: Document optional support of start and stop attributes in Sequence.index method (#4277) https://github.com/python/cpython/commit/5ce0a2a100909104836f53a2c8823006ec46f8ad ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 05:22:40 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 Dec 2017 10:22:40 +0000 Subject: [issue31942] Document that support of start and stop parameters in the Sequence's index() is optional In-Reply-To: <1509786601.53.0.213398074469.issue31942@psf.upfronthosting.co.za> Message-ID: <1513074160.98.0.213398074469.issue31942@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4706 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 05:29:01 2017 From: report at bugs.python.org (Armin Rigo) Date: Tue, 12 Dec 2017 10:29:01 +0000 Subject: [issue1617161] Instance methods compare equal when their self's are equal Message-ID: <1513074541.05.0.213398074469.issue1617161@psf.upfronthosting.co.za> Armin Rigo added the comment: Sorry, I think it is pointless to spend efforts to keep a relatively uncontroversial and small patch up-to-date, when it was not accepted in 9 years. Someone else would need to take it up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 05:33:31 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 10:33:31 +0000 Subject: [issue18533] Avoid error from repr() of recursive dictview In-Reply-To: <1374531750.42.0.70756948567.issue18533@psf.upfronthosting.co.za> Message-ID: <1513074811.86.0.213398074469.issue18533@psf.upfronthosting.co.za> STINNER Victor added the comment: See also bpo-32137. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 05:40:59 2017 From: report at bugs.python.org (Christian Heimes) Date: Tue, 12 Dec 2017 10:40:59 +0000 Subject: [issue32282] When using a Windows XP compatible toolset, `socketmodule.c` fails to build In-Reply-To: <1513036854.54.0.213398074469.issue32282@psf.upfronthosting.co.za> Message-ID: <1513075259.28.0.213398074469.issue32282@psf.upfronthosting.co.za> Christian Heimes added the comment: - 3.5 receives only security updates. - XP is no longer supported. ---------- assignee: -> steve.dower nosy: +christian.heimes versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 05:56:43 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Dec 2017 10:56:43 +0000 Subject: [issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n' In-Reply-To: <1512744234.4.0.213398074469.issue32255@psf.upfronthosting.co.za> Message-ID: <1513076203.73.0.213398074469.issue32255@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset ce5a3cd9b15c9379753aefabd696bff11495cbbb by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6': bpo-32255: Always quote a single empty field when write into a CSV file. (GH-4769) (#4810) https://github.com/python/cpython/commit/ce5a3cd9b15c9379753aefabd696bff11495cbbb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 05:56:58 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Dec 2017 10:56:58 +0000 Subject: [issue32255] csv.writer converts None to '""\n' when it is first line, otherwise '\n' In-Reply-To: <1512744234.4.0.213398074469.issue32255@psf.upfronthosting.co.za> Message-ID: <1513076218.27.0.213398074469.issue32255@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 05:58:28 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 10:58:28 +0000 Subject: [issue31942] Document that support of start and stop parameters in the Sequence's index() is optional In-Reply-To: <1509786601.53.0.213398074469.issue31942@psf.upfronthosting.co.za> Message-ID: <1513076308.81.0.213398074469.issue31942@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 78cd00b799be36a35c9f5cc99ce3bcef31112a5f by Victor Stinner (Miss Islington (bot)) in branch '3.6': bpo-31942: Document optional support of start and stop attributes in Sequence.index method (GH-4277) (#4811) https://github.com/python/cpython/commit/78cd00b799be36a35c9f5cc99ce3bcef31112a5f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 05:58:55 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 10:58:55 +0000 Subject: [issue31942] Document that support of start and stop parameters in the Sequence's index() is optional In-Reply-To: <1509786601.53.0.213398074469.issue31942@psf.upfronthosting.co.za> Message-ID: <1513076335.58.0.213398074469.issue31942@psf.upfronthosting.co.za> STINNER Victor added the comment: Thanks Nitish Chandra for your doc enhancement! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 06:00:04 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 11:00:04 +0000 Subject: [issue29970] Severe open file leakage running asyncio SSL server In-Reply-To: <1491228615.05.0.224246839796.issue29970@psf.upfronthosting.co.za> Message-ID: <1513076404.52.0.213398074469.issue29970@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 06:02:40 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 11:02:40 +0000 Subject: [issue19431] Document PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError() In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za> Message-ID: <1513076560.47.0.213398074469.issue19431@psf.upfronthosting.co.za> STINNER Victor added the comment: > If I only convert PyFrame_New() then I would need to add it to as existing page since the patch created a new page for Frame Objects. I think the right place would be under the current PyFrameObject in Doc/c-api/veryhigh.rst? Not, it's a very high level API, it's a low level API which should be referenced in the concrete.rst page, as I didn in my patch. I think it's ok to have a page with only two functions: PyFrame_New() and PyFrame_GetLineNumber(). Move https://docs.python.org/dev/c-api/reflection.html#c.PyFrame_GetLineNumber into your new doc, but leave something like "See also :c:func:`PyFrame_GetLineNumber`." there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 06:04:51 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 11:04:51 +0000 Subject: [issue19431] Document PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError() In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za> Message-ID: <1513076691.5.0.213398074469.issue19431@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy: how are you supposed to modify local variables of a frame when these variables are stored in "fast locals"? Even if it's a rare useful, I think that it's ok to expose PyFrame_FastToLocalsWithError(), and maybe also PyFrame_FastToLocals(). It is useful you want write a debugger in pure C, and don't want to bother with fast locals special case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 06:10:19 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Dec 2017 11:10:19 +0000 Subject: [issue32137] Stack overflow in repr of deeply nested dicts In-Reply-To: <1511686410.56.0.213398074469.issue32137@psf.upfronthosting.co.za> Message-ID: <1513077019.1.0.213398074469.issue32137@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4707 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 06:11:50 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Dec 2017 11:11:50 +0000 Subject: [issue32137] Stack overflow in repr of deeply nested dicts In-Reply-To: <1511686410.56.0.213398074469.issue32137@psf.upfronthosting.co.za> Message-ID: <1513077110.8.0.213398074469.issue32137@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PR 4812 is an alternate fix for 3.6. It doesn't touch reprs of other types. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 06:14:02 2017 From: report at bugs.python.org (=?utf-8?b?TWF0w7rFoSB2YWxv?=) Date: Tue, 12 Dec 2017 11:14:02 +0000 Subject: [issue32287] Import of _pyio module failed on cygwin Message-ID: <1513077242.25.0.213398074469.issue32287@psf.upfronthosting.co.za> New submission from Mat?? valo : When trying to impor _pyio from python3 in Cygwin, import fails with exception: $ python3 Python 3.6.3 (default, Oct 31 2017, 19:00:36) [GCC 6.4.0] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import _pyio Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.6/_pyio.py", line 17, in from msvcrt import setmode as _setmode ModuleNotFoundError: No module named 'msvcrt' This issue is breaking cherrypy server (cheroot component): https://github.com/cherrypy/cheroot/blob/86c6b246ec7cb704c6f96123556db1a083301634/cheroot/makefile.py#L5 ---------- components: IO, Library (Lib) messages: 308115 nosy: Mat?? valo priority: normal severity: normal status: open title: Import of _pyio module failed on cygwin type: crash versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 06:18:11 2017 From: report at bugs.python.org (=?utf-8?b?TWF0w7rFoSB2YWxv?=) Date: Tue, 12 Dec 2017 11:18:11 +0000 Subject: [issue32287] Import of _pyio module failed on cygwin In-Reply-To: <1513077242.25.0.213398074469.issue32287@psf.upfronthosting.co.za> Message-ID: <1513077491.44.0.213398074469.issue32287@psf.upfronthosting.co.za> Mat?? valo added the comment: Previous import is working in python 2.7: $ python Python 2.7.14 (default, Oct 31 2017, 21:12:13) [GCC 6.4.0] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import _pyio >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 06:28:43 2017 From: report at bugs.python.org (Christian Heimes) Date: Tue, 12 Dec 2017 11:28:43 +0000 Subject: [issue32287] Import of _pyio module failed on cygwin In-Reply-To: <1513077242.25.0.213398074469.issue32287@psf.upfronthosting.co.za> Message-ID: <1513078123.3.0.213398074469.issue32287@psf.upfronthosting.co.za> Christian Heimes added the comment: The msvcrt module is part of the standard library on Windows. Your cygwin installation may be incomplete. By the way, why are you importing a private module? _pyio isn't a public API and shouldn't be used. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 06:53:25 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Dec 2017 11:53:25 +0000 Subject: [issue19431] Document PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError() In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za> Message-ID: <1513079605.59.0.213398074469.issue19431@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: frameobject.h is not included in any header file. Some effort was spent for avoiding including it in ceval.h, genobject.h, pystate.h and traceback.h. The whole content of frameobject.h is not available in the limited API. I'm not sure about the status of this API. This is not a very hight level API, but rather a very low level API. If document it, it should be documented on a separate page or on a page together with other low-level API. > Serhiy: how are you supposed to modify local variables of a frame when these variables are stored in "fast locals"? Currently you should call PyFrame_FastToLocalsWithError(), modify directly f_locals, and call PyFrame_LocalsToFast(). This is very low-level manipulation. It exposes implementation details (at least you need to access PyFrameObject attributes directly). It should be documented that the most of PyFrame_* API is low-level and implementation specific. PyFrame_GetLineNumber() is an exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 06:55:06 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Dec 2017 11:55:06 +0000 Subject: [issue32241] Add the const qualifier for char and wchar_t pointers to unmodifiable strings In-Reply-To: <1512654844.82.0.213398074469.issue32241@psf.upfronthosting.co.za> Message-ID: <1513079706.32.0.213398074469.issue32241@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 4ae06c5337e01bdde28bce57b6b9166ad50947e3 by Serhiy Storchaka in branch 'master': bpo-32241: Add the const qualifire to declarations of umodifiable strings. (#4748) https://github.com/python/cpython/commit/4ae06c5337e01bdde28bce57b6b9166ad50947e3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 06:55:32 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Dec 2017 11:55:32 +0000 Subject: [issue32241] Add the const qualifier for char and wchar_t pointers to unmodifiable strings In-Reply-To: <1512654844.82.0.213398074469.issue32241@psf.upfronthosting.co.za> Message-ID: <1513079732.6.0.213398074469.issue32241@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 06:58:23 2017 From: report at bugs.python.org (Massimiliano Culpo) Date: Tue, 12 Dec 2017 11:58:23 +0000 Subject: [issue32288] Inconsistent behavior with slice assignment? Message-ID: <1513079903.38.0.213398074469.issue32288@psf.upfronthosting.co.za> New submission from Massimiliano Culpo : I am not really sure if what I am reporting is to be considered a bug in the interpreter (slice built-in), a lack in documentation or if it is just me not finding the proper references (in which case feel free to close this and sorry for the noise). Anyhow, while trying to code a class that mimics built-in lists, I noticed a few seemingly inconsistent behaviors in the use of slices to set items. This can be reduced down to this very simple example: ``` Python 3.6.2 (default, Jul 29 2017, 00:00:00) [GCC 4.8.4] on linux # 1. Slice has start and stop, step is defaulted to None >>> a = [1, 2, 3, 4] >>> a[1:3] = [11, 22, 33, 44] >>> a [1, 11, 22, 33, 44, 4] # 2. Same as above setting explicitly step == 1 >>> a = [1, 2, 3, 4] >>> a[1:3:1] = [11, 22, 33, 44] >>> a [1, 11, 22, 33, 44, 4] # 3. Trying to do the same thing with step == -1 # (I naively expected either [1, 44, 33, 22, 11, 4] or 2. to fail like 3.) >>> a = [1, 2, 3, 4] >>> a[3:1:-1] = [11, 22, 33, 44] Traceback (most recent call last): File "", line 1, in ValueError: attempt to assign sequence of size 4 to extended slice of size 2 ``` Now, the first issue: I tried to search what an "extended slice" is exactly, but found nothing in the docs. What is written here https://docs.python.org/3/library/functions.html#slice seems to suggest that an "extended slice" is a slice where `step is not None`, but then I would expect case 2. to behave the same as case 3. So to me it appears as either lack of documentation on the behavior, or a bug in 2. Second issue: in the same page in the docs it's written > slice objects are also generated when extended indexing syntax is used. For example: a[start:stop:step] or a[start:stop, i] I wasn't aware of the second syntax, and tried to use it: ``` >>> a = [1, 2, 3, 4] >>> a[1:3:1] [2, 3] >>> a[1:3, 1] Traceback (most recent call last): File "", line 1, in TypeError: list indices must be integers or slices, not tuple ``` I guess that's not the result one would expect... Third issue: slightly related, but here https://docs.python.org/3/library/stdtypes.html#mutable-sequence-types I see that the documentation of `insert` reads: > inserts x into s at the index given by i (same as s[i:i] = [x]) and from the interpreter: ``` help(list.insert) Help on method_descriptor: insert(...) L.insert(index, object) -- insert object before index ``` Here the fact is that `insert` really behaves like `s[i:i] = [x]`, but in my understanding it doesn't keep the promise to `insert object before index`. ``` # "Out of bounds" on the right >>> a = [1, 2, 3, 4] >>> a.insert(101, 11) >>> a [1, 2, 3, 4, 11] # "Out of bounds" on the left >>> a.insert(-101, 11) >>> a [11, 1, 2, 3, 4] ``` I don't know honestly if docs are not clear here, or if it is just me, but I didn't expect this behavior and thought it was worth reporting. Let me know if you need more information. ---------- assignee: docs at python components: Documentation, Interpreter Core messages: 308120 nosy: Massimiliano Culpo, docs at python priority: normal severity: normal status: open title: Inconsistent behavior with slice assignment? type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 07:23:20 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Tue, 12 Dec 2017 12:23:20 +0000 Subject: [issue32226] Implement PEP 560: Core support for typing module and generic types In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za> Message-ID: <1513081400.52.0.213398074469.issue32226@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: > As for __class_getitem__, why not implement type.__getitem__ instead of hacking PyObject_GetItem()? This question was raised by Mark Shannon on python-dev. Actually, my initial implementation did exactly this, but I didn't like it for two reasons: 1. dir(type) is already very long, I don't want to make it even longer. 2. Some users may be surprised that although ``type.__getitem__`` is defined, ``int[something]`` will rise "TypeError: type object is not subscriptable" Mark however disappeared since then, so I don't know what is his current opinion. I am however not as sure about this now. If there are some arguments for this, then I can revert to the older approach (implementing ``type.__getitem__``). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 07:25:08 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 12 Dec 2017 12:25:08 +0000 Subject: [issue32285] In `unicodedata`, it should be possible to check a unistr's normal form without necessarily copying it In-Reply-To: <1513041370.04.0.213398074469.issue32285@psf.upfronthosting.co.za> Message-ID: <1513081508.61.0.213398074469.issue32285@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Python 2.7 is in feature freeze, so this can only go into 3.7. I would find this useful, and would like this feature. However, I'm concerned by your comment that you fall back on creating a normalized copy and comparing. That could be expensive, and shouldn't be needed. According to here: http://unicode.org/reports/tr15/#Detecting_Normalization_Forms in the worst case, you can incrementally check only the code points in doubt (around the "MAYBE" code points). ---------- nosy: +steven.daprano type: -> enhancement versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 07:39:47 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 12 Dec 2017 12:39:47 +0000 Subject: [issue32288] Inconsistent behavior with slice assignment? In-Reply-To: <1513079903.38.0.213398074469.issue32288@psf.upfronthosting.co.za> Message-ID: <1513082387.35.0.213398074469.issue32288@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Please don't report three issues under one ticket, unless they are so closely related that they cannot be separated. I don't understand what your second issue actually is. You refer to the docs that specify extended syntax as [start:stop:step] but then you tried [start:stop,step] which is correctly an error. (Notice the comma instead of colon.) And again, your third issue to do with list.insert ... what is your actual bug report? Have you found an example where these aren't equivalent? alist.insert(pos, value) alist[pos:pos] = [value] I don't understand your third bug report here... you show two examples where the insert function works as documented. You say you didn't expect the behaviour, but what behaviour did you expect? ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 07:46:19 2017 From: report at bugs.python.org (Stefan Krah) Date: Tue, 12 Dec 2017 12:46:19 +0000 Subject: [issue32288] Inconsistent behavior with slice assignment? In-Reply-To: <1513079903.38.0.213398074469.issue32288@psf.upfronthosting.co.za> Message-ID: <1513082779.44.0.213398074469.issue32288@psf.upfronthosting.co.za> Stefan Krah added the comment: Python lists don't implement extended slices, try numpy arrays: >>> import numpy as np >>> x = array([[1,2,3], [4,5,6]]) >>> x[:, 2] array([3, 6]) >>> >>> lst = [[1,2,3], [4,5,6]] >>> lst[:, 2] Traceback (most recent call last): File "", line 1, in TypeError: list indices must be integers or slices, not tuple >>> Was there any issue apart from the extended slices? ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 08:03:53 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 12 Dec 2017 13:03:53 +0000 Subject: [issue32289] Glossary does not define "extended slicing" Message-ID: <1513083833.6.0.213398074469.issue32289@psf.upfronthosting.co.za> New submission from Steven D'Aprano : Looking at issue 32288, I realised that the glossary doesn't define "extended slicing" or "extended slice", even though they are common terms. Although I thought I know what they meant, on closer reflection I realised I wasn't sure. Does extended slicing refer to slice *objects* with a stride/step, as opposed to slice objects all the way back in Python 1.3 (yes, *one* point 3) that only had start and end? Does it refer specifically to the two-colon form of slice *syntax*? Both? Neither? https://docs.python.org/3/glossary.html#term-slice The only documentation I found is from the 2.3 What's New: https://docs.python.org/2.3/whatsnew/section-slices.html ---------- assignee: docs at python components: Documentation messages: 308125 nosy: Massimiliano Culpo, docs at python, steven.daprano priority: normal severity: normal status: open title: Glossary does not define "extended slicing" type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 08:05:25 2017 From: report at bugs.python.org (Stefan Krah) Date: Tue, 12 Dec 2017 13:05:25 +0000 Subject: [issue32288] Inconsistent behavior with slice assignment? In-Reply-To: <1513079903.38.0.213398074469.issue32288@psf.upfronthosting.co.za> Message-ID: <1513083925.1.0.213398074469.issue32288@psf.upfronthosting.co.za> Stefan Krah added the comment: I see the first issue now and I agree that Python behaves strangely. Numpy ===== >>> x = array([1,2,3]) >>> x[1:2] = [1,2,3,4,5] Traceback (most recent call last): File "", line 1, in ValueError: cannot copy sequence with size 5 to array axis with dimension 1 Python ====== >>> lst = [1,2,3] >>> lst[1:2] = [1,2,3,4,5] >>> lst [1, 1, 2, 3, 4, 5, 3] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 08:10:46 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 13:10:46 +0000 Subject: [issue32285] In `unicodedata`, it should be possible to check a unistr's normal form without necessarily copying it In-Reply-To: <1513041370.04.0.213398074469.issue32285@psf.upfronthosting.co.za> Message-ID: <1513084246.77.0.213398074469.issue32285@psf.upfronthosting.co.za> STINNER Victor added the comment: > However, I'm concerned by your comment that you fall back on creating a normalized copy and comparing. The purpose of the function is to be faster than str == unicodedata.normalize(form, str). So yeah, any optimization is welcome. But I don't bother with MAYBE suboptimal case which is implemented with: str == unicodedata.normalize(form, str). It can be optimized later, if needed. If someone cares of performance, I will require a benchmark, since I only trust numbers :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 08:12:33 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 13:12:33 +0000 Subject: [issue19431] Document PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError() In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za> Message-ID: <1513084353.96.0.213398074469.issue19431@psf.upfronthosting.co.za> STINNER Victor added the comment: > Currently you should call PyFrame_FastToLocalsWithError(), modify directly f_locals, and call PyFrame_LocalsToFast(). When happens if PyFrame_LocalsToFast() isn't called? Does it crash or is it just slower? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 08:37:58 2017 From: report at bugs.python.org (Massimiliano Culpo) Date: Tue, 12 Dec 2017 13:37:58 +0000 Subject: [issue32288] Inconsistent behavior with slice assignment? In-Reply-To: <1513079903.38.0.213398074469.issue32288@psf.upfronthosting.co.za> Message-ID: <1513085877.99.0.213398074469.issue32288@psf.upfronthosting.co.za> Massimiliano Culpo added the comment: Steven and Stefan, thanks for the quick replies, even though they are giving slightly different answers to the same questions :-) @steven.daprano > You refer to the docs that specify extended syntax as [start:stop:step] but then you tried [start:stop,step] which is correctly an error. (Notice the comma instead of colon.) Maybe you missed the quote from the docs: "For example: a[start:stop:step] or a[start:stop, i]" You say that the docs "specify extended syntax as [start:stop:step]". Apparently you're also surprised this syntax exists, and didn't notice that the error is not a SyntaxError, but a TypeError. I argue then that the syntax is there. If I get correctly what @skrah says, he seems to suggest that the syntax is there, but no built-in type is using it. Am I right? > And again, your third issue to do with list.insert ... what is your actual bug report? Have you found an example where these aren't equivalent? I didn't say that. I actually said "`insert` really behaves like `s[i:i] = [x]`". But the docs from the interpreter say: ``` help(list.insert) Help on method_descriptor: insert(...) L.insert(index, object) -- insert object before index ``` What does it mean to insert an object before index 101 or -101 of a 4 items list? I think if the help said "-- same as L[index:index] = [object]" I would have been fine with it. > Please don't report three issues under one ticket, unless they are so closely related that they cannot be separated. Apologies if this was not correct (I see you started an issue with a smaller scope). But I thought they were closely related, because all three might have been fixed by a rewording of a few parts of the docs dealing with slices. @skrah > I see the first issue now and I agree that Python behaves strangely. To be clear, I don't have issues with: ``` >>> lst = [1,2,3] >>> lst[1:2] = [1,2,3,4,5] >>> lst [1, 1, 2, 3, 4, 5, 3] ``` in Python, which probably is a widely used idiom to modify lists. My concerns are with the fact that you get the same behavior when you use `lst[1:2:1]` (which in my understanding is an extended slice), but you get a `ValueError` for any other value of `slice.step`. That might be something worth clarifying as part of issue32289 maybe? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 08:47:31 2017 From: report at bugs.python.org (Stefan Krah) Date: Tue, 12 Dec 2017 13:47:31 +0000 Subject: [issue32288] Inconsistent behavior with slice assignment? In-Reply-To: <1513079903.38.0.213398074469.issue32288@psf.upfronthosting.co.za> Message-ID: <1513086451.82.0.213398074469.issue32288@psf.upfronthosting.co.za> Stefan Krah added the comment: Okay, the different meanings of "extended slicing" seem to be an old problem: https://mail.python.org/pipermail/tutor/2007-July/055838.html I assumed it referred to numpy's tuple indexing syntax, but it is apparently also used for referring to the step value of a single slice object. Somehow I've always used the term for the tuple syntax. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 08:52:35 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 Dec 2017 13:52:35 +0000 Subject: [issue32287] Import of _pyio module failed on cygwin In-Reply-To: <1513077242.25.0.213398074469.issue32287@psf.upfronthosting.co.za> Message-ID: <1513086755.59.0.213398074469.issue32287@psf.upfronthosting.co.za> Change by R. David Murray : ---------- nosy: +erik.bray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 09:10:32 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 Dec 2017 14:10:32 +0000 Subject: [issue32288] Inconsistent behavior with slice assignment? In-Reply-To: <1513079903.38.0.213398074469.issue32288@psf.upfronthosting.co.za> Message-ID: <1513087832.48.0.213398074469.issue32288@psf.upfronthosting.co.za> R. David Murray added the comment: It actually makes sense that a slice assignment with a different length replacement list with a step of 1 works but any other step doesn't. Logically you can see that you can cut out a chunk and replace it with a different sized chunk, but you can't do that if the step is not abs(1). So a doc tweak may be appropriate. And it is surprising that -1 doesn't work (but why would you ever use it? :), so that might be a buglet. For a numpy array, I imagine the rules are different, so an error there on stride 1 is not that surprising either, though *perhaps* there is room for improvement on the numpy side. (In other words, the stride 1 python behavior is "correct" from a python language perspective.) And yes, it would be much easier to discuss these separate issues in separate issues. Now you know for next time :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 09:21:47 2017 From: report at bugs.python.org (Yaroslav Halchenko) Date: Tue, 12 Dec 2017 14:21:47 +0000 Subject: [issue32276] there is no way to make tempfile reproducible (i.e. seed the used RNG) In-Reply-To: <1513002327.33.0.213398074469.issue32276@psf.upfronthosting.co.za> Message-ID: <1513088507.94.0.213398074469.issue32276@psf.upfronthosting.co.za> Yaroslav Halchenko added the comment: I have spent too much time in Python to be able to compare to other languages ;) but anywhere I saw RNG being used, there was a way to seed it or to provide a state. tempfile provides no such API my usecase -- comparison of logs from two runs where I need to troubleshoot the point of divergence in execution . Logs in our case (datalad) contain temporary directory filenames, so they always "diff" and I need to sift through them or to come up with some obscure sed regex to unify them. I found in other projects of ours a really handy to be able to seed RNG globally so two runs result in identical execution path -- allows for easier reproducibility/comparison. But when it got to those temporary filenames -- apparently I could not make it happen and would need to resort to some heavy monkey patching. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 09:34:22 2017 From: report at bugs.python.org (Stefan Krah) Date: Tue, 12 Dec 2017 14:34:22 +0000 Subject: [issue32288] Inconsistent behavior with slice assignment? In-Reply-To: <1513079903.38.0.213398074469.issue32288@psf.upfronthosting.co.za> Message-ID: <1513089262.53.0.213398074469.issue32288@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks, David, you are of course right! -- I've worked so much with fixed arrays in the past year that Python's behavior seemed odd and unfathomable. :-) [Numpy arrays can't adopt that behavior, because growing them would be too expensive.] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 09:41:03 2017 From: report at bugs.python.org (Alexey Luchko) Date: Tue, 12 Dec 2017 14:41:03 +0000 Subject: [issue32268] quopri.decode(): string argument expected, got 'bytes' In-Reply-To: <1512902753.61.0.213398074469.issue32268@psf.upfronthosting.co.za> Message-ID: <1513089663.74.0.213398074469.issue32268@psf.upfronthosting.co.za> Alexey Luchko added the comment: Yes. With io.BytesIO() output, it works. However, this kind of error messages is quite very confusing. It better be possible to distinguish binary and text streams, so one (including quopri module) could tell it won't work in advance %) Thanks for referring to binascii module as well! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 10:10:04 2017 From: report at bugs.python.org (Zachary Ware) Date: Tue, 12 Dec 2017 15:10:04 +0000 Subject: [issue32287] Import of _pyio module failed on cygwin In-Reply-To: <1513077242.25.0.213398074469.issue32287@psf.upfronthosting.co.za> Message-ID: <1513091404.9.0.213398074469.issue32287@psf.upfronthosting.co.za> Zachary Ware added the comment: Presumably this issue does prevent us from testing _pyio on Cygwin, which is not ideal. The outside usage of _pyio is definitely not supported, as Christian said, but this may be worth fixing anyway. ---------- nosy: +masamoto, zach.ware priority: normal -> low stage: -> needs patch type: crash -> behavior versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 10:20:06 2017 From: report at bugs.python.org (=?utf-8?b?TWF0w7rFoSBWYWxv?=) Date: Tue, 12 Dec 2017 15:20:06 +0000 Subject: [issue32287] Import of _pyio module failed on cygwin In-Reply-To: <1513077242.25.0.213398074469.issue32287@psf.upfronthosting.co.za> Message-ID: <1513092006.45.0.213398074469.issue32287@psf.upfronthosting.co.za> Mat?? Valo added the comment: I am using not using _pyio module directly but I am using cherrypy server which is using this module (more precisely its component cheroot): https://github.com/cherrypy/cheroot/blob/86c6b246ec7cb704c6f96123556db1a083301634/cheroot/makefile.py#L5 Regarding installation of cygwin environment, I can check it in other machine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 10:21:53 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 15:21:53 +0000 Subject: [issue30386] Add a build infrastructure for Android In-Reply-To: <1495029473.85.0.224153889861.issue30386@psf.upfronthosting.co.za> Message-ID: <1513092113.92.0.213398074469.issue30386@psf.upfronthosting.co.za> STINNER Victor added the comment: See also https://github.com/python/buildmaster-config/pull/26 : "Add the Android build factory". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 10:24:50 2017 From: report at bugs.python.org (Christian Heimes) Date: Tue, 12 Dec 2017 15:24:50 +0000 Subject: [issue32287] Import of _pyio module failed on cygwin In-Reply-To: <1513077242.25.0.213398074469.issue32287@psf.upfronthosting.co.za> Message-ID: <1513092290.26.0.213398074469.issue32287@psf.upfronthosting.co.za> Christian Heimes added the comment: Could you please file a bug with cherrypy and get it fixed? Cygwin not yet officially supported and stable. Erik is working hard on stable support for 3.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 10:28:39 2017 From: report at bugs.python.org (Zachary Ware) Date: Tue, 12 Dec 2017 15:28:39 +0000 Subject: [issue32287] Import of _pyio module failed on cygwin In-Reply-To: <1513077242.25.0.213398074469.issue32287@psf.upfronthosting.co.za> Message-ID: <1513092519.85.0.213398074469.issue32287@psf.upfronthosting.co.za> Zachary Ware added the comment: Right, so you should raise an issue with cherrypy :). You're more likely to get a fix from them quickly, and their usage of _pyio is not correct anyway. Also, note that Cygwin is not (anymore/yet) a fully-supported platform. We're working towards that status, but aren't there yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 10:29:40 2017 From: report at bugs.python.org (Steve Dower) Date: Tue, 12 Dec 2017 15:29:40 +0000 Subject: [issue32282] When using a Windows XP compatible toolset, `socketmodule.c` fails to build In-Reply-To: <1513036854.54.0.213398074469.issue32282@psf.upfronthosting.co.za> Message-ID: <1513092580.94.0.213398074469.issue32282@psf.upfronthosting.co.za> Steve Dower added the comment: If you can't compile, security fixes aren't worth anything. And while we don't support XP, the v140_xp toolset is in more of a grey area. There are real ways you could be forced into using it besides targeting XP. Max - I'd rather just remove the ifdef checks completely. Fairly sure I added them in the migration from VC10, but they are simply incorrect (the header is from the WinSDK which is not the same as _MSC_VER) and will always be there for the versions of the SDK we allow, even back to 3.5. ---------- nosy: +larry type: -> compile error versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 10:40:45 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 15:40:45 +0000 Subject: [issue32290] bolen-dmg-3.6: compilation failed with OSError: [Errno 23] Too many open files in system Message-ID: <1513093245.22.0.213398074469.issue32290@psf.upfronthosting.co.za> New submission from STINNER Victor : http://buildbot.python.org/all/#/builders/49/builds/67 ... http://buildbot.python.org/all/#/builders/49/builds/67 ... Installing collected packages: sphinxcontrib-websupport, setuptools, snowballstemmer, docutils, imagesize, urllib3, chardet, certifi, idna, requests, pytz, babel, alabaster, MarkupSafe, Jinja2, six, Pygments, Sphinx, blurb Found existing installation: setuptools 28.8.0 Uninstalling setuptools-28.8.0: Successfully uninstalled setuptools-28.8.0 Running setup.py install for MarkupSafe: started Running setup.py install for MarkupSafe: finished with status 'done' Successfully installed Jinja2-2.10 MarkupSafe-1.0 Pygments-2.2.0 Sphinx-1.6.5 alabaster-0.7.10 babel-2.5.1 blurb-1.0.5 certifi-2017.11.5 chardet-3.0.4 docutils-0.14 idna-2.6 imagesize-0.7.1 pytz-2017.3 requests-2.18.4 setuptools-38.2.4 six-1.11.0 snowballstemmer-1.2.1 sphinxcontrib-websupport-1.0.1 urllib3-1.22 The venv has been created in the ./venv directory Exception occurred: File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/util/osutil.py", line 230, in getcwd OSError: [Errno 23] Too many open files in system Traceback (most recent call last): File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/cmdline.py", line 306, in main File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/application.py", line 339, in build File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/builders/__init__.py", line 331, in build_update File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/builders/__init__.py", line 344, in build File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/environment/__init__.py", line 584, in update File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/environment/__init__.py", line 603, in _read_serial File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/environment/__init__.py", line 735, in read_doc File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/application.py", line 489, in emit File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/events.py", line 79, in emit File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/environment/collectors/dependencies.py", line 43, in process_doc File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/util/osutil.py", line 230, in getcwd OSError: [Errno 23] Too many open files in system During handling of the above exception, another exception occurred: Traceback (most recent call last): File "./venv/bin/sphinx-build", line 11, in File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/__init__.py", line 71, in main File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/__init__.py", line 113, in build_main File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/cmdline.py", line 309, in main File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/cmdline.py", line 105, in handle_exception File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Doc/venv/lib/python3.6/site-packages/sphinx/util/__init__.py", line 219, in save_traceback File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/tempfile.py", line 335, in mkstemp File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/tempfile.py", line 130, in _sanitize_params File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/tempfile.py", line 296, in gettempdir File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/tempfile.py", line 231, in _get_default_tempdir FileNotFoundError: [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '.'] make: *** [build] Error 1 Traceback (most recent call last): mkdir -p build Building NEWS from Misc/NEWS.d with blurb PATH=./venv/bin:$PATH sphinx-build -b html -d build/doctrees -D latex_elements.papersize= . build/html Running Sphinx v1.6.5 making output directory... loading pickled environment... not yet created building [mo]: targets for 0 po files that are out of date building [html]: targets for 465 source files that are out of date updating environment: 465 added, 0 changed, 0 removed reading sources... [ 0%] about reading sources... [ 0%] bugs ... main() File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Mac/BuildScript/build-installer.py", line 1620, in main buildPythonDocs() File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Mac/BuildScript/build-installer.py", line 1093, in buildPythonDocs runCommand('make html PYTHON=venv/bin/python') File "/Users/db3l/buildarea.dmg/bolen-dmg-3.6/build/Mac/BuildScript/build-installer.py", line 531, in runCommand raise RuntimeError("command failed: %s"%(commandline,)) RuntimeError: command failed: make html PYTHON=venv/bin/python program finished with exit code 1 elapsedTime=1719.516712 ---------- components: macOS messages: 308141 nosy: ned.deily, ronaldoussoren, vstinner priority: normal severity: normal status: open title: bolen-dmg-3.6: compilation failed with OSError: [Errno 23] Too many open files in system versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 10:42:03 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 15:42:03 +0000 Subject: [issue32290] bolen-dmg-3.6: compilation failed with OSError: [Errno 23] Too many open files in system In-Reply-To: <1513093245.22.0.213398074469.issue32290@psf.upfronthosting.co.za> Message-ID: <1513093323.88.0.213398074469.issue32290@psf.upfronthosting.co.za> STINNER Victor added the comment: A different but maybe related failure on x86 Tiger 3.x: http://buildbot.python.org/all/#/builders/30/builds/323 ====================================================================== ERROR: test_rapid_restart (test.test_multiprocessing_fork.WithThreadsTestManagerRestart) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/_test_multiprocessing.py", line 2706, in test_rapid_restart manager.start() File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/multiprocessing/managers.py", line 533, in start reader, writer = connection.Pipe(duplex=False) File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/multiprocessing/connection.py", line 517, in Pipe fd1, fd2 = os.pipe() OSError: [Errno 23] Too many open files in system ====================================================================== ERROR: test_timeout (test.test_multiprocessing_fork.WithThreadsTestQueue) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/_test_multiprocessing.py", line 1007, in test_timeout q = multiprocessing.Queue() File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/multiprocessing/context.py", line 102, in Queue return Queue(maxsize, ctx=self.get_context()) File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/multiprocessing/queues.py", line 41, in __init__ self._reader, self._writer = connection.Pipe(duplex=False) File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/multiprocessing/connection.py", line 517, in Pipe fd1, fd2 = os.pipe() OSError: [Errno 23] Too many open files in system ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 10:44:46 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 15:44:46 +0000 Subject: [issue30386] Add a build infrastructure for Android In-Reply-To: <1495029473.85.0.224153889861.issue30386@psf.upfronthosting.co.za> Message-ID: <1513093486.09.0.213398074469.issue30386@psf.upfronthosting.co.za> STINNER Victor added the comment: See also the thread on python-dev: [Python-Dev] Support of the Android platform https://mail.python.org/pipermail/python-dev/2017-December/151171.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 12:00:36 2017 From: report at bugs.python.org (Marc Guetg) Date: Tue, 12 Dec 2017 17:00:36 +0000 Subject: [issue32291] Value error for string shared memory in multiprocessing Message-ID: <1513098036.37.0.213398074469.issue32291@psf.upfronthosting.co.za> New submission from Marc Guetg : It seems like sharing a string over processes is not possible. #!/usr/bin/env python3 import multiprocessing import threading import ctypes def fun(share_c, share_s, set_c, set_s, name): print(f'{name}: {share_c.value}; {share_s.value}') share_c.value = set_c share_s.value = set_s print(f'{name}: {share_c.value}; {share_s.value}') if __name__ == '__main__': share_c = multiprocessing.Value(ctypes.c_wchar, 'a') share_s = multiprocessing.Value(ctypes.c_wchar_p, 'aa') print(f'pre_thread: {share_c.value}; {share_s.value}') thread = threading.Thread(target=fun, args=(share_c, share_s, 'b', 'bb', 'thread')) thread.start() thread.join() print(f'post_thread: {share_c.value}; {share_s.value}') process = multiprocessing.Process(target=fun, args=(share_c, share_s, 'c', 'cc', 'process')) process.start() process.join() print(f'post_process: {share_c.value}', end='; ') print(share_s.value) # <--- Blows here produces: pre_thread: a; aa thread: a; aa thread: b; bb post_thread: b; bb process: b; bb process: c; cc post_process: c; Traceback (most recent call last): File "test2.py", line 30, in print(share_s.value) # <--- Blows here File "", line 5, in getvalue ValueError: character U+ff92f210 is not in range [U+0000; U+10ffff] Where the character value in the error message is different every time. To me this seems like a bug as it is working properly with threads as well as single characters. (Maybe relevant question also here: https://stackoverflow.com/questions/47763878/how-to-share-string-between-processes?noredirect=1#comment82492062_47763878) For the case it matters: Python 3.6.1 (Anaconda 4.4.0) on RHEL 6 ---------- components: Library (Lib), Unicode messages: 308144 nosy: ezio.melotti, magu, vstinner priority: normal severity: normal status: open title: Value error for string shared memory in multiprocessing type: crash versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 12:45:37 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 12 Dec 2017 17:45:37 +0000 Subject: [issue32292] Building fails on Windows Message-ID: <1513100737.71.0.213398074469.issue32292@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Sorry if this looks more like a support request. There's probably something wrong in my setup (I do have Visual Studio 2015 installed, though). I am trying to build on Windows using "Tools\buildbot\build.bat -p x64". It worked a few months ago. Now I get: Build FAILED. "c:\t\cpython\PCbuild\pcbuild.proj" (Build target) (1) -> "c:\t\cpython\PCbuild\pythoncore.vcxproj" (Build target) (2) -> (Desktop_PlatformPrepareForBuild target) -> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\x64\P latformToolsets\v140\Toolset.targets(36,5): error MSB8036: The Windows S DK version 10.0.16299.0 was not found. Install the required version of W indows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution". [c:\t\cp ython\PCbuild\pythoncore.vcxproj] 0 Warning(s) 1 Error(s) ---------- components: Windows messages: 308145 nosy: paul.moore, pitrou, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Building fails on Windows versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 12:49:48 2017 From: report at bugs.python.org (Neil Aspinall) Date: Tue, 12 Dec 2017 17:49:48 +0000 Subject: [issue29970] Severe open file leakage running asyncio SSL server In-Reply-To: <1491228615.05.0.224246839796.issue29970@psf.upfronthosting.co.za> Message-ID: <1513100988.91.0.213398074469.issue29970@psf.upfronthosting.co.za> Neil Aspinall added the comment: I think there's been some confusion about what PR 480 was meant to fix - it helps in cases where connections are closed during handshake, but if a server connection is waiting for a handshake but never receives any data at all then it stays in that state forever. As for a fix, how about giving SSLProtocol a method like: def checkHandshakeDone(self): if self._in_handshake == True: self._abort() and then at the end of _start_handshake() adding: self._loop.call_later(10, self.checkHandshakeDone) Then if the handshake is not complete within ten seconds of starting, the connection will be aborted. ---------- nosy: +mocmocamoc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 13:03:00 2017 From: report at bugs.python.org (Lloyd Vancil) Date: Tue, 12 Dec 2017 18:03:00 +0000 Subject: [issue32293] macos pkg fails 10.13.2 Message-ID: <1513101780.7.0.213398074469.issue32293@psf.upfronthosting.co.za> New submission from Lloyd Vancil : the downloadble pkg file fails on attempt to install on 10.13.2 "no software to install" ---------- components: macOS messages: 308147 nosy: Lloyd Vancil, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: macos pkg fails 10.13.2 type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 13:06:30 2017 From: report at bugs.python.org (Lloyd Vancil) Date: Tue, 12 Dec 2017 18:06:30 +0000 Subject: [issue32293] macos pkg fails 10.13.2 In-Reply-To: <1513101780.7.0.213398074469.issue32293@psf.upfronthosting.co.za> Message-ID: <1513101990.27.0.213398074469.issue32293@psf.upfronthosting.co.za> Change by Lloyd Vancil : ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 13:18:22 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Tue, 12 Dec 2017 18:18:22 +0000 Subject: [issue22671] Typo in class io.BufferedIOBase docs In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za> Message-ID: <1513102702.5.0.213398074469.issue22671@psf.upfronthosting.co.za> Change by Sanyam Khurana : ---------- pull_requests: +4708 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 13:22:58 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 12 Dec 2017 18:22:58 +0000 Subject: [issue32268] quopri.decode(): string argument expected, got 'bytes' In-Reply-To: <1512902753.61.0.213398074469.issue32268@psf.upfronthosting.co.za> Message-ID: <1513102978.96.0.213398074469.issue32268@psf.upfronthosting.co.za> R. David Murray added the comment: We generally don't do advance type checking (look before you leap) in Python. This allows a type the programmer hadn't planned for to be used as long as it "quacks like" the expected type (this is called duck typing). So the error was produced exactly where it should be and exactly as it should be: it was produced by the StringIO object you provided, when quopri tried to write the binary output that it produces to the object you handed it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 13:42:09 2017 From: report at bugs.python.org (Eric Snow) Date: Tue, 12 Dec 2017 18:42:09 +0000 Subject: [issue32280] Expose `_PyRuntime` through a section name In-Reply-To: <1513034681.19.0.213398074469.issue32280@psf.upfronthosting.co.za> Message-ID: <1513104129.29.0.213398074469.issue32280@psf.upfronthosting.co.za> Eric Snow added the comment: Note that in the long term we are considering support for embedding multiple runtimes in a single process. So anything that assumes there is only a single runtime in each process is problematic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 15:02:38 2017 From: report at bugs.python.org (Jordan Speicher) Date: Tue, 12 Dec 2017 20:02:38 +0000 Subject: [issue30256] Adding a SyncManager Queue proxy to a SyncManager dict or Namespace proxy raises an exception In-Reply-To: <1493812414.86.0.361870744934.issue30256@psf.upfronthosting.co.za> Message-ID: <1513108958.9.0.213398074469.issue30256@psf.upfronthosting.co.za> Change by Jordan Speicher : ---------- keywords: +patch pull_requests: +4709 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 15:21:42 2017 From: report at bugs.python.org (Steve Dower) Date: Tue, 12 Dec 2017 20:21:42 +0000 Subject: [issue32292] Building fails on Windows In-Reply-To: <1513100737.71.0.213398074469.issue32292@psf.upfronthosting.co.za> Message-ID: <1513110102.43.0.213398074469.issue32292@psf.upfronthosting.co.za> Steve Dower added the comment: I changed the default Windows SDK version at some point, because it was falling back to v8.1 and we really ought to use v10. It auto-detects all the v10 versions, so I'm guessing you haven't got any of them installed right now. The dev guide just says to install VS 2017, which will include it. We should probably have manual install steps listed somewhere as well, though I'm hesitant to make the "getting started" steps too complex. And I've already switched 3.7 to use the v141 toolset, which is in VS 2017 but not VS 2015 (but it's binary compatible with the older v140, so shouldn't matter). For VS 2015, you can get the Windows 10 SDK from https://developer.microsoft.com/windows/downloads/windows-10-sdk (only the headers and libraries option is required). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 16:10:56 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Tue, 12 Dec 2017 21:10:56 +0000 Subject: [issue32226] Implement PEP 560: Core support for typing module and generic types In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za> Message-ID: <1513113056.14.0.213398074469.issue32226@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Guido, what is your preference for the implementation of ``__class_getitem__``: ``PyObject_GetItem`` (current one) or ``type.__getitem__`` (old one)? Can we just go ahead with the version you like and then re-consider if some objections will appear? I am asking because you are going on vacation soon and there is a second part of implementation -- changes in typing (and someone needs to review them :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 16:28:07 2017 From: report at bugs.python.org (Ivan Pozdeev) Date: Tue, 12 Dec 2017 21:28:07 +0000 Subject: [issue31643] test_uuid: test_getnode and test_windll_getnode fail if connected to the Internet via an Android phone In-Reply-To: <1513069261.93.0.213398074469.issue31643@psf.upfronthosting.co.za> Message-ID: Ivan Pozdeev added the comment: > Xavier de Gaye added the comment: > > On a Samsung device with Android 5.1 and tethering enabled, only one network device has a MAC address and it is not an all-zero MAC address. > > Ivan can you please provide more information about this problem: which device, what Android version, what is the output of 'ip link' ? C:\> ipconfig -all <...> Samsung Galaxy S7 - Ethernet ???????: ??????? DNS-??????? ????? ??????????? . . : ??????? ????????? . . . . . . . . . . . . : Android USB Ethernet/RNDIS ??????? ?????????? ?????. . . . . . . . . : 00-00-00-00-00-00 ??????? Dhcp ???????. . . . . . . . . . . : ?? ??????? ????????????? ????????? . . . . . : ?? ??????? IP-?????? . . . . . . . . . . . . : 192.168.42.2 ??????? ????? ??????? . . . . . . . . . . : 255.255.255.0 ??????? ???????? ???? . . . . . . . . . . : 192.168.42.129 ??????? DHCP-?????? . . . . . . . . . . . : 192.168.42.129 ??????? DNS-??????? . . . . . . . . . . . : 192.168.42.129 Device name: Samsung Galaxy S7 Model number: SM-G930F Android version: 6.0.1 Firmware version: G930FXXU1APGJ Baseband version: G930VVRS4APH1 Build number: MMB29M.G930VVRU2APG5 > Serhiy Storchaka added the comment: > > I'm not sure that 000000000000 is better than a random address. Even if an all-zero MAC address is not explicitly prohibited it is used in a multiple independent devices. A random address looks more appropriate fore the purpose of generating a UUID. The question is not whether it's good UUID source material. The question, for the purpose of the test, is whether it's valid getnode() output -- which it is for the current logic. ---------- nosy: +__Vano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 16:40:02 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 21:40:02 +0000 Subject: [issue20361] -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options In-Reply-To: <1390468789.64.0.236388970509.issue20361@psf.upfronthosting.co.za> Message-ID: <1513114802.2.0.00913614298617.issue20361@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4711 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 16:40:02 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 21:40:02 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions In-Reply-To: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> Message-ID: <1513114802.09.0.213398074469.issue32230@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4710 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 16:55:02 2017 From: report at bugs.python.org (Fipaddict) Date: Tue, 12 Dec 2017 21:55:02 +0000 Subject: [issue1410680] Add 'surgical editing' to ConfigParser Message-ID: <1513115702.67.0.213398074469.issue1410680@psf.upfronthosting.co.za> Fipaddict added the comment: I would have liked for configparser to keep comments when my program re-write configuration file too. Thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 16:55:06 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 21:55:06 +0000 Subject: [issue32101] Add PYTHONDEVMODE=1 to enable the developer mode In-Reply-To: <1511233137.85.0.213398074469.issue32101@psf.upfronthosting.co.za> Message-ID: <1513115706.75.0.213398074469.issue32101@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4712 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 16:55:54 2017 From: report at bugs.python.org (Maxime Belanger) Date: Tue, 12 Dec 2017 21:55:54 +0000 Subject: [issue32280] Expose `_PyRuntime` through a section name In-Reply-To: <1513034681.19.0.213398074469.issue32280@psf.upfronthosting.co.za> Message-ID: <1513115754.21.0.213398074469.issue32280@psf.upfronthosting.co.za> Maxime Belanger added the comment: Interesting, would this imply potentially multiple GILs? The major thing we need out of the structure is the (`Py_tss_t`) `autoTSSKey` in order to associate a native thread with its `PyThreadState`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 16:57:59 2017 From: report at bugs.python.org (Maxime Belanger) Date: Tue, 12 Dec 2017 21:57:59 +0000 Subject: [issue32282] When using a Windows XP compatible toolset, `socketmodule.c` fails to build In-Reply-To: <1513036854.54.0.213398074469.issue32282@psf.upfronthosting.co.za> Message-ID: <1513115879.74.0.213398074469.issue32282@psf.upfronthosting.co.za> Maxime Belanger added the comment: Works for me. We no longer rely on the `_xp` toolset so no objections. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 16:58:14 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 21:58:14 +0000 Subject: [issue32280] Expose `_PyRuntime` through a section name In-Reply-To: <1513034681.19.0.213398074469.issue32280@psf.upfronthosting.co.za> Message-ID: <1513115894.0.0.213398074469.issue32280@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 16:59:50 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 21:59:50 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions In-Reply-To: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> Message-ID: <1513115990.6.0.213398074469.issue32230@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 747f48e2e92390c44c72f52a1239959601cde157 by Victor Stinner in branch 'master': bpo-32230: Set sys.warnoptions with -X dev (#4820) https://github.com/python/cpython/commit/747f48e2e92390c44c72f52a1239959601cde157 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 16:59:50 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 21:59:50 +0000 Subject: [issue20361] -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options In-Reply-To: <1390468789.64.0.236388970509.issue20361@psf.upfronthosting.co.za> Message-ID: <1513115990.68.0.912454111764.issue20361@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 747f48e2e92390c44c72f52a1239959601cde157 by Victor Stinner in branch 'master': bpo-32230: Set sys.warnoptions with -X dev (#4820) https://github.com/python/cpython/commit/747f48e2e92390c44c72f52a1239959601cde157 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 17:01:13 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 22:01:13 +0000 Subject: [issue20361] -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options In-Reply-To: <1390468789.64.0.236388970509.issue20361@psf.upfronthosting.co.za> Message-ID: <1513116073.86.0.213398074469.issue20361@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I merged Nick's PR: -b and -bb options now have the highest priority. I close the issue. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 17:04:27 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 22:04:27 +0000 Subject: [issue32230] -X dev doesn't set sys.warnoptions In-Reply-To: <1512549660.05.0.213398074469.issue32230@psf.upfronthosting.co.za> Message-ID: <1513116267.57.0.213398074469.issue32230@psf.upfronthosting.co.za> STINNER Victor added the comment: We found an agreement with Nick :-) I applied Nick's PR. The issue is now fixed: vstinner at apu$ ./python -X dev -c 'import sys; print(sys.warnoptions)' ['default'] This PR also fix bpo-20361: -b and -bb options now have the highest priority. The documentation is maybe not perfect, but Nick stated that he will update the doc with the implementation of his PEP 565. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 17:11:11 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 12 Dec 2017 22:11:11 +0000 Subject: [issue32292] Building fails on Windows In-Reply-To: <1513100737.71.0.213398074469.issue32292@psf.upfronthosting.co.za> Message-ID: <1513116671.24.0.213398074469.issue32292@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you. Though now I get the following issue: "c:\t\cpython\PCbuild\pcbuild.proj" (Build target) (1) -> "c:\t\cpython\PCbuild\pythoncore.vcxproj" (Build target) (2) -> (ResourceCompile target) -> TRACKER : error TRK0005: Failed to locate: "rc.exe". The system cannot find the file specified. [c:\t\cpython\PCbuild\pythoncore.vcxproj] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 17:13:34 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 22:13:34 +0000 Subject: [issue32294] test_semaphore_tracker() of test_multiprocessing_spawn fails with -W error Message-ID: <1513116814.7.0.213398074469.issue32294@psf.upfronthosting.co.za> New submission from STINNER Victor : vstinner at apu$ PYTHONWARNINGS=error ./python -W error -m test test_multiprocessing_spawn -v -m test_semaphore_tracker == CPython 3.7.0a3+ (heads/master:747f48e2e9, Dec 12 2017, 23:12:36) [GCC 7.2.1 20170915 (Red Hat 7.2.1-2)] == Linux-4.13.16-300.fc27.x86_64-x86_64-with-fedora-27-Twenty_Seven little-endian == cwd: /home/vstinner/prog/python/master/build/test_python_29868 == CPU count: 8 == encodings: locale=UTF-8, FS=utf-8 Run tests sequentially 0:00:00 load avg: 0.52 [1/1] test_multiprocessing_spawn test_semaphore_tracker (test.test_multiprocessing_spawn.TestSemaphoreTracker) ... FAIL Exception ignored in: <_io.FileIO name=7 mode='rb' closefd=True> ResourceWarning: unclosed file <_io.BufferedReader name=7> ====================================================================== FAIL: test_semaphore_tracker (test.test_multiprocessing_spawn.TestSemaphoreTracker) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/vstinner/prog/python/master/Lib/test/_test_multiprocessing.py", line 4380, in test_semaphore_tracker _multiprocessing.sem_unlink(name2) AssertionError: OSError not raised ---------------------------------------------------------------------- Ran 1 test in 2.060s FAILED (failures=1) test test_multiprocessing_spawn failed test_multiprocessing_spawn failed 1 test failed: test_multiprocessing_spawn Total duration: 2 sec Tests result: FAILURE ---------- components: Tests messages: 308161 nosy: vstinner priority: normal severity: normal status: open title: test_semaphore_tracker() of test_multiprocessing_spawn fails with -W error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 17:15:02 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 22:15:02 +0000 Subject: [issue32101] Add PYTHONDEVMODE=1 to enable the developer mode In-Reply-To: <1511233137.85.0.213398074469.issue32101@psf.upfronthosting.co.za> Message-ID: <1513116902.12.0.213398074469.issue32101@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 721e25c6535d08bd3d4d891fb2b540472e19f899 by Victor Stinner in branch 'master': bpo-32101: Fix tests for PYTHONDEVMODE=1 (#4821) https://github.com/python/cpython/commit/721e25c6535d08bd3d4d891fb2b540472e19f899 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 17:21:36 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 12 Dec 2017 22:21:36 +0000 Subject: [issue18533] Avoid error from repr() of recursive dictview In-Reply-To: <1374531750.42.0.70756948567.issue18533@psf.upfronthosting.co.za> Message-ID: <1513117296.79.0.213398074469.issue18533@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4713 stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 17:33:39 2017 From: report at bugs.python.org (Ben North) Date: Tue, 12 Dec 2017 22:33:39 +0000 Subject: [issue18533] Avoid error from repr() of recursive dictview In-Reply-To: <1374531750.42.0.70756948567.issue18533@psf.upfronthosting.co.za> Message-ID: <1513118018.98.0.213398074469.issue18533@psf.upfronthosting.co.za> Ben North added the comment: PR4823 created as per msg308086. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 17:34:32 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 12 Dec 2017 22:34:32 +0000 Subject: [issue32292] Building fails on Windows In-Reply-To: <1513100737.71.0.213398074469.issue32292@psf.upfronthosting.co.za> Message-ID: <1513118072.85.0.213398074469.issue32292@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 17:39:54 2017 From: report at bugs.python.org (Ernest W. Durbin III) Date: Tue, 12 Dec 2017 22:39:54 +0000 Subject: [issue32295] User friendly message when invoking bdist_wheel sans wheel package Message-ID: <1513118394.49.0.213398074469.issue32295@psf.upfronthosting.co.za> New submission from Ernest W. Durbin III : Wheels are a well-known part of the Python packaging ecosystem at this point! Many tutorials, gists, and other tools suggest to build wheels using setuptools and distutils, but may not remind users to install the wheel package. In light of Issue 31634 being temporarily suspended and given that this does not interfere with experienced users implementing their own bdist_wheel command, it should be a welcome addition to help guide novice packagers in the right direction. Result for a Python environment without the `wheel` package installed: $ python3 setup.py bdist_wheel usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: invalid command 'bdist_wheel' note: The wheel package provides this command. See https://packaging.python.org/tutorials/distributing-packages/#wheels for information on packaging wheels ---------- components: Distutils messages: 308165 nosy: EWDurbin, dstufft, eric.araujo priority: normal pull_requests: 4715 severity: normal status: open title: User friendly message when invoking bdist_wheel sans wheel package type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 17:40:14 2017 From: report at bugs.python.org (Ben North) Date: Tue, 12 Dec 2017 22:40:14 +0000 Subject: [issue32137] Stack overflow in repr of deeply nested dicts In-Reply-To: <1511686410.56.0.213398074469.issue32137@psf.upfronthosting.co.za> Message-ID: <1513118414.38.0.213398074469.issue32137@psf.upfronthosting.co.za> Change by Ben North : ---------- pull_requests: +4716 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 17:42:12 2017 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 12 Dec 2017 22:42:12 +0000 Subject: [issue32295] User friendly message when invoking bdist_wheel sans wheel package In-Reply-To: <1513118394.49.0.213398074469.issue32295@psf.upfronthosting.co.za> Message-ID: <1513118532.8.0.213398074469.issue32295@psf.upfronthosting.co.za> ?ric Araujo added the comment: I don?t know that bdist_wheel integrates with pure distutils without setuptools. I think this PR should target setuptools (it will also make it propagate to users faster and regardless of Python version). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 17:43:21 2017 From: report at bugs.python.org (Neil Aspinall) Date: Tue, 12 Dec 2017 22:43:21 +0000 Subject: [issue29970] Severe open file leakage running asyncio SSL server In-Reply-To: <1491228615.05.0.224246839796.issue29970@psf.upfronthosting.co.za> Message-ID: <1513118601.6.0.213398074469.issue29970@psf.upfronthosting.co.za> Change by Neil Aspinall : ---------- keywords: +patch pull_requests: +4717 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 17:47:34 2017 From: report at bugs.python.org (Ernest W. Durbin III) Date: Tue, 12 Dec 2017 22:47:34 +0000 Subject: [issue32295] User friendly message when invoking bdist_wheel sans wheel package In-Reply-To: <1513118394.49.0.213398074469.issue32295@psf.upfronthosting.co.za> Message-ID: <1513118854.67.0.213398074469.issue32295@psf.upfronthosting.co.za> Ernest W. Durbin III added the comment: bdist_wheel is implemented as a distutils.core.Command, see https://github.com/pypa/wheel/blob/3a87ecebaba765475392ae2cdfa2a51cb78360e0/wheel/bdist_wheel.py I was unable to find a good place to transparently hook in and catch the missing command class, but I agree that setuptools would be a far faster avenue to get this out to users. Alternatives include: 1) implementing bdist_wheel as a command in setuptools... which would have to get out of the way or call the real command when the wheel package is installed. 2) trying to get wheel merged into setuptools, which would be a much larger project. I'll see what option 1 looks like! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 17:58:15 2017 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 12 Dec 2017 22:58:15 +0000 Subject: [issue32295] User friendly message when invoking bdist_wheel sans wheel package In-Reply-To: <1513118394.49.0.213398074469.issue32295@psf.upfronthosting.co.za> Message-ID: <1513119495.98.0.213398074469.issue32295@psf.upfronthosting.co.za> ?ric Araujo added the comment: The devs probably choose to use distutils.Command as base class for maximum compatibility, but I suspect 99.99% of users use the setuptools integration (entry points https://github.com/pypa/wheel/blob/3a87ecebaba765475392ae2cdfa2a51cb78360e0/setup.py#L53-L54 ) rather that distutils integration (explicit cmd_class setting in setup.py or --command-packages on the command line) I?m inclined to reject the special case in distutils and encourage you to send the patch to setuptools (a similar PR, not option 1 or 2). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 17:59:23 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 12 Dec 2017 22:59:23 +0000 Subject: [issue32296] Implement asyncio._get_running_loop() and get_event_loop() in C Message-ID: <1513119563.35.0.213398074469.issue32296@psf.upfronthosting.co.za> New submission from Yury Selivanov : asyncio.get_event_loop(), and, subsequently asyncio._get_running_loop() are one of the most frequently executed functions in asyncio. They also can't be sped up by third-party event loops like uvloop. When implemented in C they become 4x faster. ---------- assignee: yselivanov components: asyncio messages: 308169 nosy: asvetlov, lukasz.langa, yselivanov priority: normal severity: normal status: open title: Implement asyncio._get_running_loop() and get_event_loop() in C versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 18:01:46 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 12 Dec 2017 23:01:46 +0000 Subject: [issue17852] Built-in module _io can lose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1513119706.84.0.213398074469.issue17852@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- pull_requests: +4718 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 18:01:47 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 12 Dec 2017 23:01:47 +0000 Subject: [issue32296] Implement asyncio._get_running_loop() and get_event_loop() in C In-Reply-To: <1513119563.35.0.213398074469.issue32296@psf.upfronthosting.co.za> Message-ID: <1513119707.11.0.213398074469.issue32296@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4719 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 18:05:06 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 12 Dec 2017 23:05:06 +0000 Subject: [issue17852] Built-in module _io can lose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1513119906.85.0.213398074469.issue17852@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I just discovered that the fix is incorrect. See PR #4826 for reversion and a quick explanation. ---------- resolution: fixed -> stage: resolved -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 18:15:30 2017 From: report at bugs.python.org (Eitan Adler) Date: Tue, 12 Dec 2017 23:15:30 +0000 Subject: [issue27126] Apple-supplied libsqlite3 on OS X is not fork safe; can cause crashes In-Reply-To: <1464217505.87.0.0701340905112.issue27126@psf.upfronthosting.co.za> Message-ID: <1513120530.18.0.213398074469.issue27126@psf.upfronthosting.co.za> Change by Eitan Adler : ---------- nosy: +eadler _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 18:15:50 2017 From: report at bugs.python.org (Eitan Adler) Date: Tue, 12 Dec 2017 23:15:50 +0000 Subject: [issue20353] Hanging bug with multiprocessing + sqlite3 + tkinter (OS X 10.9 only) In-Reply-To: <1390415067.55.0.719190169135.issue20353@psf.upfronthosting.co.za> Message-ID: <1513120550.0.0.213398074469.issue20353@psf.upfronthosting.co.za> Change by Eitan Adler : ---------- nosy: +eadler _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 18:15:58 2017 From: report at bugs.python.org (Eitan Adler) Date: Tue, 12 Dec 2017 23:15:58 +0000 Subject: [issue13829] exception error in _scproxy.so when called after fork In-Reply-To: <1326998522.6.0.790472668429.issue13829@psf.upfronthosting.co.za> Message-ID: <1513120558.61.0.213398074469.issue13829@psf.upfronthosting.co.za> Change by Eitan Adler : ---------- nosy: +eadler _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 18:37:15 2017 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 12 Dec 2017 23:37:15 +0000 Subject: [issue32226] Implement PEP 560: Core support for typing module and generic types In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za> Message-ID: <1513121835.09.0.213398074469.issue32226@psf.upfronthosting.co.za> Guido van Rossum added the comment: I like the current approach (PyObject_GetItem). I agree with both of your reasons to prefer it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 18:37:41 2017 From: report at bugs.python.org (Masayuki Yamamoto) Date: Tue, 12 Dec 2017 23:37:41 +0000 Subject: [issue32287] Import of _pyio module failed on cygwin In-Reply-To: <1513077242.25.0.213398074469.issue32287@psf.upfronthosting.co.za> Message-ID: <1513121861.72.0.213398074469.issue32287@psf.upfronthosting.co.za> Masayuki Yamamoto added the comment: This issue seems to duplicate #28459. #28459 has a patch (implement _setmode() by ctypes on _pyio). I'm not sure _setmode() will be used in other places in the future, but the patch just works at the moment. In addition, I have an idea which implements C extension (imitation msvcrt or just cygwin). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 18:38:30 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 12 Dec 2017 23:38:30 +0000 Subject: [issue32270] subprocess closes redirected fds even if they are in pass_fds In-Reply-To: <1512926046.73.0.213398074469.issue32270@psf.upfronthosting.co.za> Message-ID: <1513121910.25.0.213398074469.issue32270@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Regarding fixing (1), I'm worrying about backward compatibility a bit. Well, people shouldn't rely on bugs. Otherwise we would never be able to fix bugs, lest someone relies on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 19:07:13 2017 From: report at bugs.python.org (Masayuki Yamamoto) Date: Wed, 13 Dec 2017 00:07:13 +0000 Subject: [issue28459] _pyio module broken on Cygwin / setmode not usable In-Reply-To: <1476701892.4.0.598393414511.issue28459@psf.upfronthosting.co.za> Message-ID: <1513123633.21.0.213398074469.issue28459@psf.upfronthosting.co.za> Masayuki Yamamoto added the comment: FYI, cygwin-pyio-setmode.patch includes two extra parts for running on Cygwin. First, fix import error for ctypes (unopened issue). Second, fix building _ctypes module (#4032 - PR 4153). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 19:10:06 2017 From: report at bugs.python.org (Mikhail Afanasev) Date: Wed, 13 Dec 2017 00:10:06 +0000 Subject: [issue32297] Few misspellings found in Python source code comments. Message-ID: <1513123806.73.0.213398074469.issue32297@psf.upfronthosting.co.za> New submission from Mikhail Afanasev : I have noticed few misspellings in Python source code comments while doing some research with the help of spelling and grammatic tools. I double checked all of them and corrected. There is just one docstring affected. All the other changes are in Python source code comments. It also affects 49 different files from all the modules. I made a PR, and I think it's up to file maintainers to decide if they want to merge any of this edits. At this moment maintainer of idlelib package picked and merged changes which affect his pars independently. ---------- messages: 308175 nosy: mehanig priority: normal pull_requests: 4720 severity: normal status: open title: Few misspellings found in Python source code comments. type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 19:14:08 2017 From: report at bugs.python.org (Steve Dower) Date: Wed, 13 Dec 2017 00:14:08 +0000 Subject: [issue32292] Building fails on Windows In-Reply-To: <1513100737.71.0.213398074469.issue32292@psf.upfronthosting.co.za> Message-ID: <1513124048.23.0.213398074469.issue32292@psf.upfronthosting.co.za> Steve Dower added the comment: Strange, that should have been installed. Do you see rc.exe anywhere in "C:\Program Files (x86)\Windows Kits\10"? If not, might need to repair the SDK you just installed. It shouldn't be a separate option from anything else in there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 19:39:30 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 00:39:30 +0000 Subject: [issue17852] Built-in module _io can lose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1513125570.2.0.213398074469.issue17852@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 317def9fdb29893df1ab380d396fcdd2eafe0588 by Victor Stinner (Antoine Pitrou) in branch 'master': bpo-17852: Revert incorrect fix based on misunderstanding of _Py_PyAtExit() semantics (#4826) https://github.com/python/cpython/commit/317def9fdb29893df1ab380d396fcdd2eafe0588 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 19:40:05 2017 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 13 Dec 2017 00:40:05 +0000 Subject: [issue32297] Few misspellings found in Python source code comments. In-Reply-To: <1513123806.73.0.213398074469.issue32297@psf.upfronthosting.co.za> Message-ID: <1513125605.27.0.213398074469.issue32297@psf.upfronthosting.co.za> Change by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 19:54:09 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 13 Dec 2017 00:54:09 +0000 Subject: [issue32292] Building fails on Windows In-Reply-To: <1513124048.23.0.213398074469.issue32292@psf.upfronthosting.co.za> Message-ID: <9fafa193-860e-bc30-4b51-4054c3abcfbb@free.fr> Antoine Pitrou added the comment: Le 13/12/2017 ? 01:14, Steve Dower a ?crit?: > > Strange, that should have been installed. > > Do you see rc.exe anywhere in "C:\Program Files (x86)\Windows Kits\10"? Yes, it's in "C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x64" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 20:05:32 2017 From: report at bugs.python.org (Steve Dower) Date: Wed, 13 Dec 2017 01:05:32 +0000 Subject: [issue32292] Building fails on Windows In-Reply-To: <1513100737.71.0.213398074469.issue32292@psf.upfronthosting.co.za> Message-ID: <1513127132.72.0.213398074469.issue32292@psf.upfronthosting.co.za> Steve Dower added the comment: Is there one in x86 as well? Perhaps it isn't finding x64 tools properly (I've seen this once or twice in the past with VS 2015, but I think it was fixed at some point) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 20:08:00 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 13 Dec 2017 01:08:00 +0000 Subject: [issue32292] Building fails on Windows In-Reply-To: <1513100737.71.0.213398074469.issue32292@psf.upfronthosting.co.za> Message-ID: <1513127280.91.0.213398074469.issue32292@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes, both in x86 and x64. And `tools\buildbot\build.bat` fails regardless of whether I pass `-p x64` or not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 20:17:18 2017 From: report at bugs.python.org (Geoff Kuenning) Date: Wed, 13 Dec 2017 01:17:18 +0000 Subject: [issue32298] Email.quopriprime over-encodes characters Message-ID: <1513127837.95.0.213398074469.issue32298@psf.upfronthosting.co.za> New submission from Geoff Kuenning : Email.quopriprime creates a map of header and body bytes that need no encoding: for c in b'-!*+/' + ascii_letters.encode('ascii') + digits.encode('ascii'): _QUOPRI_HEADER_MAP[c] = chr(c) This map is overly restrictive; in fact only two printable characters need to be omitted: the space and the equals sign. The following revision to the loop creates a correct table: for c in list(range(33, 61)) + list(range(62, 127)): _QUOPRI_HEADER_MAP[c] = chr(c) Why does this matter? Well, first, it's wasteful since it creates messages with larger headers than necessary. But more important, it makes it impossible for other tools to operate on the messages unless they're encoding aware; for example, one can't easily grep for "foo at bar.com" because the at sign is encoded as =40. ---------- components: Library (Lib) messages: 308181 nosy: gkuenning priority: normal severity: normal status: open title: Email.quopriprime over-encodes characters type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 20:21:47 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 01:21:47 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1513128107.45.0.213398074469.issue29240@psf.upfronthosting.co.za> STINNER Victor added the comment: The PEP 538 has two open issues: bpo-30672 and bpo-32238. I recently refactored the Py_Main() code so it should be simpler to implement the PEP 540: see bpo-32030. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 20:25:01 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 01:25:01 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1513128301.84.0.213398074469.issue29240@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, PYTHONCOERCECLOCALE env var is read very early in main() by _Py_CoerceLegacyLocale(), it ignores -E command line option. * Ignoring -E and -I is safe from a security perspective, as we only use * the setting to turn *off* the implicit locale coercion, and anyone with * access to the process environment already has the ability to set * `LC_ALL=C` to override the C level locale settings anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 20:28:07 2017 From: report at bugs.python.org (Geoff Kuenning) Date: Wed, 13 Dec 2017 01:28:07 +0000 Subject: [issue32298] Email.quopriprime over-encodes characters In-Reply-To: <1513127837.95.0.213398074469.issue32298@psf.upfronthosting.co.za> Message-ID: <1513128487.24.0.213398074469.issue32298@psf.upfronthosting.co.za> Geoff Kuenning added the comment: Oops, that loop is a bit too generous. Here's a better one: for c in list(range(33, 61)) + [62] + list(range(64, 95)) + list(range(96,127)): ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 21:06:11 2017 From: report at bugs.python.org (Steve Dower) Date: Wed, 13 Dec 2017 02:06:11 +0000 Subject: [issue32292] Building fails on Windows In-Reply-To: <1513100737.71.0.213398074469.issue32292@psf.upfronthosting.co.za> Message-ID: <1513130771.33.0.213398074469.issue32292@psf.upfronthosting.co.za> Steve Dower added the comment: It shouldn't be any different, but what about PCBuild/build.bat? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 21:08:18 2017 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 13 Dec 2017 02:08:18 +0000 Subject: [issue32267] strptime misparses offsets with microsecond format In-Reply-To: <1512900720.16.0.213398074469.issue32267@psf.upfronthosting.co.za> Message-ID: <1513130898.66.0.213398074469.issue32267@psf.upfronthosting.co.za> Change by Alexander Belopolsky : ---------- nosy: +p-ganssle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 21:13:30 2017 From: report at bugs.python.org (Paul Ganssle) Date: Wed, 13 Dec 2017 02:13:30 +0000 Subject: [issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28) In-Reply-To: <1234845206.93.0.372909555036.issue5288@psf.upfronthosting.co.za> Message-ID: <1513131210.78.0.213398074469.issue5288@psf.upfronthosting.co.za> Change by Paul Ganssle : ---------- pull_requests: +4721 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 21:32:04 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Dec 2017 02:32:04 +0000 Subject: [issue32298] Email.quopriprime over-encodes characters In-Reply-To: <1513127837.95.0.213398074469.issue32298@psf.upfronthosting.co.za> Message-ID: <1513132324.48.0.213398074469.issue32298@psf.upfronthosting.co.za> R. David Murray added the comment: >From RFC 2047: (3) As a replacement for a 'word' entity within a 'phrase', for example, one that precedes an address in a From, To, or Cc header. The ABNF definition for 'phrase' from RFC 822 thus becomes: phrase = 1*( encoded-word / word ) In this case the set of characters that may be used in a "Q"-encoded 'encoded-word' is restricted to: . An 'encoded-word' that appears within a 'phrase' MUST be separated from any adjacent 'word', 'text' or 'special' by 'linear-white-space'. The reason for this is that things like '@' are syntactically significant in headers and so must be encoded. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 21:54:11 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Dec 2017 02:54:11 +0000 Subject: [issue32298] Email.quopriprime over-encodes characters In-Reply-To: <1513127837.95.0.213398074469.issue32298@psf.upfronthosting.co.za> Message-ID: <1513133651.04.0.213398074469.issue32298@psf.upfronthosting.co.za> R. David Murray added the comment: And of course tools can grep for "foo at bar.com": you can't use encoded words in an address, only in the display name. However, it occurs to me that in fact the restriction applies only to phrases, so one could use a less restrictive character set in an unstructured header such as the Subject, and that would indeed be nice. The old header folder (python 2.7 and python 3.x compat32 policy) can't do it, because they don't know anything about the syntax of the headers they fold, they just use a bunch of heuristics. The new policies in python3, however, use a smarter folder from _header_value_parser, and that *does* have access to the full parse tree for the header, and so could make smart decisions about which character set to use for the encoded word encoding. If you'd like to try your hand at a PR implementing this idea, I'll be happy to provide advice and do a review. It's not going to be anywhere near as simple as the one line change you proposed here, though :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 22:54:23 2017 From: report at bugs.python.org (Xavier G. Domingo) Date: Wed, 13 Dec 2017 03:54:23 +0000 Subject: [issue31901] atexit callbacks should be run at subinterpreter shutdown In-Reply-To: <1509378283.18.0.213398074469.issue31901@psf.upfronthosting.co.za> Message-ID: <1513137263.71.0.213398074469.issue31901@psf.upfronthosting.co.za> Change by Xavier G. Domingo : ---------- nosy: +xgdomingo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 22:57:23 2017 From: report at bugs.python.org (Xavier G. Domingo) Date: Wed, 13 Dec 2017 03:57:23 +0000 Subject: [issue32226] Implement PEP 560: Core support for typing module and generic types In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za> Message-ID: <1513137443.0.0.213398074469.issue32226@psf.upfronthosting.co.za> Change by Xavier G. Domingo : ---------- nosy: +xgdomingo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 12 22:59:40 2017 From: report at bugs.python.org (Xavier G. Domingo) Date: Wed, 13 Dec 2017 03:59:40 +0000 Subject: [issue32292] Building fails on Windows In-Reply-To: <1513100737.71.0.213398074469.issue32292@psf.upfronthosting.co.za> Message-ID: <1513137580.02.0.213398074469.issue32292@psf.upfronthosting.co.za> Change by Xavier G. Domingo : ---------- nosy: +xgdomingo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 02:08:20 2017 From: report at bugs.python.org (Allen Li) Date: Wed, 13 Dec 2017 07:08:20 +0000 Subject: [issue32299] unittest.mock.patch.dict.__enter__ should return the dict Message-ID: <1513148900.41.0.213398074469.issue32299@psf.upfronthosting.co.za> New submission from Allen Li : mock.patch.dict.__enter__ should return the patched dict/mapping object. Currently it returns nothing (None). This would make setting up fixtures more convenient: with mock.patch.dict(some.thing): some.thing['foo'] = 'bar' with mock.patch.dict(some.thing) as x: x['foo'] = 'bar' ---------- components: Library (Lib) messages: 308188 nosy: Allen Li priority: normal severity: normal status: open title: unittest.mock.patch.dict.__enter__ should return the dict versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 02:08:31 2017 From: report at bugs.python.org (Allen Li) Date: Wed, 13 Dec 2017 07:08:31 +0000 Subject: [issue32299] unittest.mock.patch.dict.__enter__ should return the dict In-Reply-To: <1513148900.41.0.213398074469.issue32299@psf.upfronthosting.co.za> Message-ID: <1513148911.6.0.213398074469.issue32299@psf.upfronthosting.co.za> Change by Allen Li : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 02:26:24 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 13 Dec 2017 07:26:24 +0000 Subject: [issue32264] move pygetopt.h into internal/ In-Reply-To: <1512857323.9.0.213398074469.issue32264@psf.upfronthosting.co.za> Message-ID: <1513149984.19.0.213398074469.issue32264@psf.upfronthosting.co.za> Change by Benjamin Peterson : ---------- keywords: +patch pull_requests: +4722 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 03:08:58 2017 From: report at bugs.python.org (Sebastian Rittau) Date: Wed, 13 Dec 2017 08:08:58 +0000 Subject: [issue32284] typing.TextIO and BinaryIO are not aliases of IO[...] In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za> Message-ID: <1513152538.23.0.213398074469.issue32284@psf.upfronthosting.co.za> Change by Sebastian Rittau : ---------- keywords: +patch pull_requests: +4723 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 03:37:00 2017 From: report at bugs.python.org (Aaron Meurer) Date: Wed, 13 Dec 2017 08:37:00 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys Message-ID: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> New submission from Aaron Meurer : Take the following scenario which happened to me recently. I am trying to debug an issue on Travis CI involving environment variables. Basically, I am not sure if an environment variable is being set correctly. So in my code, I put print(os.environ.keys()) The reason I put keys() was 1, I didn't care about the values, and 2, I have secure environment variables set on Travis. To my surprise, in the Travis logs, I found something like this KeysView(environ({'TRAVIS_STACK_FEATURES': 'basic cassandra chromium couchdb disabled-ipv6 docker docker-compose elasticsearch firefox go-toolchain google-chrome jdk memcached mongodb mysql neo4j nodejs_interpreter perl_interpreter perlbrew phantomjs postgresql python_interpreter rabbitmq redis riak ruby_interpreter sqlite xserver', 'CI': 'true', ..., 'MANPATH': '/home/travis/.nvm/versions/node/v7.4.0/share/man:/home/travis/.kiex/elixirs/elixir-1.4.5/man:/home/travis/.rvm/rubies/ruby-2.4.1/share/man:/usr/local/man:/usr/local/clang-3.9.0/share/man:/usr/local/share/man:/usr/share/man:/home/travis/.rvm/man'})) So instead of just printing the keys like I asked for, it printed the whole environment, plus "KeysView(environ(". Included here was my secure environment variable. Now, fortunately, Travis hides the contents of secure environment variables in the logs, but it didn't used to (https://blog.travis-ci.com/2017-05-08-security-advisory). Aside from being a potential security issue, it's just annoying that it prints the whole environment. The values are much larger than the keys. With a normal dictionary, print(d.keys()) just prints the keys: >>> print(dict(a=1, b=2).keys()) dict_keys(['a', 'b']) ---------- messages: 308190 nosy: Aaron.Meurer priority: normal severity: normal status: open title: print(os.environ.keys()) should only print the keys versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 03:39:15 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 13 Dec 2017 08:39:15 +0000 Subject: [issue32284] typing.TextIO and BinaryIO are not aliases of IO[...] In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za> Message-ID: <1513154355.88.0.213398074469.issue32284@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 03:40:01 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 13 Dec 2017 08:40:01 +0000 Subject: [issue32284] typing.TextIO and BinaryIO are not aliases of IO[...] In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za> Message-ID: <1513154401.2.0.213398074469.issue32284@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset c3e070f84931c847d1b35e7fb36aa71edd6215f6 by Andrew Svetlov (Sebastian Rittau) in branch 'master': bpo-32284: Fix documentation of BinaryIO and TextIO (#4832) https://github.com/python/cpython/commit/c3e070f84931c847d1b35e7fb36aa71edd6215f6 ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 03:40:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 Dec 2017 08:40:31 +0000 Subject: [issue32284] typing.TextIO and BinaryIO are not aliases of IO[...] In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za> Message-ID: <1513154431.0.0.213398074469.issue32284@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4725 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 03:59:07 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 13 Dec 2017 08:59:07 +0000 Subject: [issue32284] typing.TextIO and BinaryIO are not aliases of IO[...] In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za> Message-ID: <1513155547.33.0.213398074469.issue32284@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset b0358e8784821867ab05b3d890717c37309be849 by Andrew Svetlov (Miss Islington (bot)) in branch '3.6': bpo-32284: Fix documentation of BinaryIO and TextIO (GH-4832) (#4833) https://github.com/python/cpython/commit/b0358e8784821867ab05b3d890717c37309be849 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 03:59:40 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 13 Dec 2017 08:59:40 +0000 Subject: [issue32284] typing.TextIO and BinaryIO are not aliases of IO[...] In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za> Message-ID: <1513155580.31.0.213398074469.issue32284@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 03:59:55 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 13 Dec 2017 08:59:55 +0000 Subject: [issue32284] typing.TextIO and BinaryIO are not aliases of IO[...] In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za> Message-ID: <1513155595.08.0.213398074469.issue32284@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Done ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 04:33:22 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 13 Dec 2017 09:33:22 +0000 Subject: [issue31643] test_uuid: test_getnode and test_windll_getnode fail if connected to the Internet via an Android phone In-Reply-To: <1506721038.97.0.213398074469.issue31643@psf.upfronthosting.co.za> Message-ID: <1513157602.2.0.213398074469.issue31643@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > C:\> ipconfig -all So the all-zero MAC address occurs on a Windows box and that explains the test_windll_getnode failure (this test is skipped on Android). I missed that point in your initial post and knowing what Android device you are using is irrelevant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 04:59:16 2017 From: report at bugs.python.org (Vadim Tsander) Date: Wed, 13 Dec 2017 09:59:16 +0000 Subject: [issue32299] unittest.mock.patch.dict.__enter__ should return the dict In-Reply-To: <1513148900.41.0.213398074469.issue32299@psf.upfronthosting.co.za> Message-ID: <1513159156.54.0.213398074469.issue32299@psf.upfronthosting.co.za> Change by Vadim Tsander : ---------- keywords: +patch pull_requests: +4726 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 05:13:31 2017 From: report at bugs.python.org (Maik Ro) Date: Wed, 13 Dec 2017 10:13:31 +0000 Subject: [issue32301] Typo in array documentation Message-ID: <1513160011.36.0.213398074469.issue32301@psf.upfronthosting.co.za> New submission from Maik Ro : .. class:: array(typecode[, initializer]) should be typecode, [initializer] - comma is in square brackets ---------- assignee: docs at python components: Documentation messages: 308195 nosy: Maik Ro, docs at python priority: normal severity: normal status: open title: Typo in array documentation type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 05:28:28 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 10:28:28 +0000 Subject: [issue29465] Modify _PyObject_FastCall() to reduce stack consumption In-Reply-To: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> Message-ID: <1513160908.02.0.213398074469.issue29465@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: -25 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 05:51:51 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 13 Dec 2017 10:51:51 +0000 Subject: [issue32292] Building fails on Windows In-Reply-To: <1513100737.71.0.213398074469.issue32292@psf.upfronthosting.co.za> Message-ID: <1513162311.13.0.213398074469.issue32292@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > It shouldn't be any different, but what about PCBuild/build.bat? Yes, same thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 06:06:50 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 13 Dec 2017 11:06:50 +0000 Subject: [issue32301] Typo in array documentation In-Reply-To: <1513160011.36.0.213398074469.issue32301@psf.upfronthosting.co.za> Message-ID: <1513163210.2.0.213398074469.issue32301@psf.upfronthosting.co.za> Steven D'Aprano added the comment: The given version is correct: the comma is only required if the initializer is given. Your suggested version typecode, [initializer] implies that the comma is always required whether the initializer is given or not. If we want to be absolutely pedantic, we could write: .. class:: array(typecode[, [initializer]]) as trailing commas are legal in function calls. But I don't think that makes for good documentation. ---------- nosy: +steven.daprano resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 06:29:11 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 11:29:11 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1513164551.3.0.213398074469.issue29240@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 91106cd9ff2f321c0f60fbaa09fd46c80aa5c266 by Victor Stinner in branch 'master': bpo-29240: PEP 540: Add a new UTF-8 Mode (#855) https://github.com/python/cpython/commit/91106cd9ff2f321c0f60fbaa09fd46c80aa5c266 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 08:30:55 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Wed, 13 Dec 2017 13:30:55 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513171855.78.0.213398074469.issue32300@psf.upfronthosting.co.za> Cheryl Sabella added the comment: For your current situation, list(os.environ) or iter(os.environ) both return keys only. It looks like the __repr__ on the class for os.environ is printed for os.environ (which is expected). For os.environ.keys(), the same __repr__ is wrapped as a KeysView, for os.environ.values(), it's wrapped as a ValuesView, and os.environ.items(), as an ItemsView. In 2.7, os.environ.keys() print just keys. ---------- nosy: +csabella versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 08:31:41 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Wed, 13 Dec 2017 13:31:41 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513171901.49.0.213398074469.issue32300@psf.upfronthosting.co.za> Change by Cheryl Sabella : ---------- components: +Library (Lib) type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 08:50:03 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Dec 2017 13:50:03 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513173003.13.0.213398074469.issue32300@psf.upfronthosting.co.za> R. David Murray added the comment: This is a consequence of the repr used by KeysView, which it inherits from MappingView. I agree that the result is surprising, but there may not be a generic fix. It's not entirely clear what KeysView should do here, but presumably we could at least add a repr to environ's use of it that would produce something useful. Note that a workaround when doing something like a travis debug is to print os.environ._data.keys(), which will print the bytes versions of the keys. I wouldn't recommend depending on that continuing to, though ;) ---------- nosy: +r.david.murray, rhettinger, vstinner -csabella type: behavior -> versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 08:50:27 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Dec 2017 13:50:27 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513173027.19.0.213398074469.issue32300@psf.upfronthosting.co.za> Change by R. David Murray : ---------- nosy: +csabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 09:04:28 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 14:04:28 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1513173868.28.0.213398074469.issue29240@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4727 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 09:04:28 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 14:04:28 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513173868.42.0.00913614298617.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4728 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 09:13:52 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 Dec 2017 14:13:52 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513174432.01.0.213398074469.issue32030@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Wow, 28 PRs for a single issue! This is a record. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 09:47:05 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 14:47:05 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513176425.33.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: > Wow, 28 PRs for a single issue! This is a record. You can expect much more :-) One of the goal of the PEP 432 is to put compute sys.path and put it in _PyMainInterpreterConfig. I'm trying to implement that, but we are still far from being able to do it. At least, we are getting closer at each commit. While it might be possible to squash 28 changes into a single change, I wouldn't be able to review it (I review my own changes on GitHub :-)), and it would very annoying if it causes any regression :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 10:26:59 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 13 Dec 2017 15:26:59 +0000 Subject: [issue31554] Warn when __loader__ != __spec__.loader In-Reply-To: <1506105743.55.0.558237436666.issue31554@psf.upfronthosting.co.za> Message-ID: <1513178819.54.0.213398074469.issue31554@psf.upfronthosting.co.za> Change by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 10:28:33 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 13 Dec 2017 15:28:33 +0000 Subject: [issue21762] update the import machinery to only use __spec__ In-Reply-To: <1402781631.86.0.838758150876.issue21762@psf.upfronthosting.co.za> Message-ID: <1513178913.67.0.213398074469.issue21762@psf.upfronthosting.co.za> Change by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 10:35:38 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 15:35:38 +0000 Subject: [issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor Message-ID: <1513179338.41.0.213398074469.issue32302@psf.upfronthosting.co.za> New submission from STINNER Victor : Example: https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.9414 ====================================================================== ERROR: test_get_exe_bytes (distutils.tests.test_bdist_wininst.BuildWinInstTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\projects\cpython\lib\distutils\tests\test_bdist_wininst.py", line 24, in test_get_exe_bytes exe_file = cmd.get_exe_bytes() File "C:\projects\cpython\lib\distutils\command\bdist_wininst.py", line 361, in get_exe_bytes f = open(filename, "rb") FileNotFoundError: [Errno 2] No such file or directory: 'C:\\projects\\cpython\\lib\\distutils\\command\\wininst-14.12.exe' ---------------------------------------------------------------------- ---------- components: Tests messages: 308203 nosy: vstinner priority: normal severity: normal status: open title: test_distutils: test_get_exe_bytes() failure on AppVeyor versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 10:41:43 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 13 Dec 2017 15:41:43 +0000 Subject: [issue32303] Namespace packages have inconsistent __loader__ and __spec__.loader Message-ID: <1513179703.14.0.213398074469.issue32303@psf.upfronthosting.co.za> New submission from Barry A. Warsaw : Let's say I have a namespace package: >>> importlib_resources.tests.data03.namespace This package has a non-None __loader__ but a None __spec__.loader: >>> importlib_resources.tests.data03.namespace.__loader__ <_frozen_importlib_external._NamespaceLoader object at 0x1043c1588> >>> importlib_resources.tests.data03.namespace.__spec__.loader >>> That seems inconsistent and broken. I suspect it's just an oversight that the __spec__.loader for a namespace package isn't getting set. It's probably been this way forever. See also Issue31554 ---------- messages: 308204 nosy: barry priority: normal severity: normal status: open title: Namespace packages have inconsistent __loader__ and __spec__.loader versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 10:48:29 2017 From: report at bugs.python.org (Louis Lecaroz) Date: Wed, 13 Dec 2017 15:48:29 +0000 Subject: [issue32304] Upload failed (400): Digests do not match on .tar.gz ending with x0d binary code Message-ID: <1513180109.43.0.213398074469.issue32304@psf.upfronthosting.co.za> New submission from Louis Lecaroz : Hi, .tar.gz files can end with x0d bytes or whatever you want When running setup.py sdist upload, depending on the project, the .tar.gz file, as said can sometimes end with x0d. When doing the upload, the line https://github.com/python/cpython/blob/master/Lib/distutils/command/upload.py#L162 (if value and value[-1:] == b'\r') will remove the ending char of the .tar.gz generating a 400 response error from the server like: Upload failed (400): Digests do not match, found: 09f23b52764a6802a87dd753009c2d3d, expected: 972b8e9d3dc8cf6ba6b4b1ad5991f013 error: Upload failed (400): Digests do not match, found: 09f23b52764a6802a87dd753009c2d3d, expected: 972b8e9d3dc8cf6ba6b4b1ad5991f013 As this line is generic & run on all key/values, I clearly understand that this check was initially written to eliminate certainly some issues on values in text format. But the mistake here, is that you are also changing the content of the 'content' key which contains the .tar.gz as value, and because you remove the ending 0D, you change the .tar.gz content to be uploaded. As consequence, the server will return a 400 error about a wrong digest/crc. I was able to make the code working with all .tar.gz files by changing this line to: if value and value[-1:] == '\r' and not key=='content': With a such fix, the .tar.gz content will not see its ending \r to be removed & the computed CRC from the server will be the same as computed by md5(content).hexdigest() in upload.py ---------- components: Distutils messages: 308205 nosy: dstufft, eric.araujo, llecaroz priority: normal severity: normal status: open title: Upload failed (400): Digests do not match on .tar.gz ending with x0d binary code type: security versions: Python 2.7, Python 3.5, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 10:48:41 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 13 Dec 2017 15:48:41 +0000 Subject: [issue32305] Namespace packages have inconsistent __file__ and __spec__.origin Message-ID: <1513180121.5.0.213398074469.issue32305@psf.upfronthosting.co.za> New submission from Barry A. Warsaw : Along the lines of Issue32303 there's another inconsistency in namespace package metadata. Let's say I have a namespace package: >>> importlib_resources.tests.data03.namespace The package has no __file__ attribute, and it has a misleading __spec__.origin >>> importlib_resources.tests.data03.namespace.__spec__.origin 'namespace' >>> importlib_resources.tests.data03.namespace.__file__ Traceback (most recent call last): File "", line 1, in AttributeError: module 'importlib_resources.tests.data03.namespace' has no attribute '__file__' This is especially bad because the documentation for __spec__.origin implies a correlation to __file__, and says: "Name of the place from which the module is loaded, e.g. ?builtin? for built-in modules and the filename for modules loaded from source. Normally ?origin? should be set, but it may be None (the default) which indicates it is unspecified." I don't particularly like that its origin is "namespace". That's an odd special case that's unhelpful to test against (what if you import a non-namespace package from the directory "namespace"?) What would break if __spec__.origin were (missing? or) None? ---------- messages: 308206 nosy: barry priority: normal severity: normal status: open title: Namespace packages have inconsistent __file__ and __spec__.origin versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 10:57:06 2017 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 13 Dec 2017 15:57:06 +0000 Subject: [issue32305] Namespace packages have inconsistent __file__ and __spec__.origin In-Reply-To: <1513180121.5.0.213398074469.issue32305@psf.upfronthosting.co.za> Message-ID: <1513180626.86.0.213398074469.issue32305@psf.upfronthosting.co.za> Change by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 10:57:17 2017 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 13 Dec 2017 15:57:17 +0000 Subject: [issue32303] Namespace packages have inconsistent __loader__ and __spec__.loader In-Reply-To: <1513179703.14.0.213398074469.issue32303@psf.upfronthosting.co.za> Message-ID: <1513180637.09.0.213398074469.issue32303@psf.upfronthosting.co.za> Change by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 10:57:43 2017 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 13 Dec 2017 15:57:43 +0000 Subject: [issue31554] Warn when __loader__ != __spec__.loader In-Reply-To: <1506105743.55.0.558237436666.issue31554@psf.upfronthosting.co.za> Message-ID: <1513180663.69.0.213398074469.issue31554@psf.upfronthosting.co.za> Change by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 11:00:34 2017 From: report at bugs.python.org (Zachary Ware) Date: Wed, 13 Dec 2017 16:00:34 +0000 Subject: [issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor In-Reply-To: <1513179338.41.0.213398074469.issue32302@psf.upfronthosting.co.za> Message-ID: <1513180834.91.0.213398074469.issue32302@psf.upfronthosting.co.za> Change by Zachary Ware : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware priority: normal -> high stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 11:24:08 2017 From: report at bugs.python.org (Steve Dower) Date: Wed, 13 Dec 2017 16:24:08 +0000 Subject: [issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor In-Reply-To: <1513179338.41.0.213398074469.issue32302@psf.upfronthosting.co.za> Message-ID: <1513182248.23.0.213398074469.issue32302@psf.upfronthosting.co.za> Steve Dower added the comment: I thought we'd special cased the v14 toolset already. This should be an update to the Python code in distutils that selects the filename based on compiler version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 11:26:34 2017 From: report at bugs.python.org (Steve Dower) Date: Wed, 13 Dec 2017 16:26:34 +0000 Subject: [issue32292] Building fails on Windows In-Reply-To: <1513100737.71.0.213398074469.issue32292@psf.upfronthosting.co.za> Message-ID: <1513182394.21.0.213398074469.issue32292@psf.upfronthosting.co.za> Steve Dower added the comment: Are you using a normal command prompt or the Visual Studio one? Totally clean environment should work fine these days, but I suspect there's an environment variable affecting something. "set" to show everything that is set, remove any personal info and post or just email it to me if you'd like me to check. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 11:29:25 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 13 Dec 2017 16:29:25 +0000 Subject: [issue32292] Building fails on Windows In-Reply-To: <1513100737.71.0.213398074469.issue32292@psf.upfronthosting.co.za> Message-ID: <1513182565.97.0.213398074469.issue32292@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It's a normal command prompt. Here is the output of "set": https://gist.github.com/pitrou/2baf9950b0ab2f68b39b4973355b2e79 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 11:30:00 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 16:30:00 +0000 Subject: [issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor In-Reply-To: <1513179338.41.0.213398074469.issue32302@psf.upfronthosting.co.za> Message-ID: <1513182600.95.0.213398074469.issue32302@psf.upfronthosting.co.za> STINNER Victor added the comment: Extract of pythoninfo of the failed build: os.environ[VS110COMNTOOLS]: C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\ os.environ[VS120COMNTOOLS]: C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\ os.environ[VS140COMNTOOLS]: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\ The build starts with: Using "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe" (found in the PATH) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 11:30:34 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 16:30:34 +0000 Subject: [issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor In-Reply-To: <1513179338.41.0.213398074469.issue32302@psf.upfronthosting.co.za> Message-ID: <1513182634.2.0.213398074469.issue32302@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, and the PATH: os.environ[PATH]: C:\Perl\site\bin;C:\Perl\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\7-Zip;C:\Tools\GitVersion;C:\Tools\NuGet;C:\Program Files\Microsoft\Web Platform Installer\;C:\Tools\PsTools;C:\Program Files\Git LFS;C:\Program Files\Mercurial\;C:\Program Files (x86)\Subversion\bin;C:\Tools\WebDriver;C:\Tools\Coverity\bin;C:\Tools\MSpec;C:\Tools\NUnit\bin;C:\Tools\NUnit3;C:\Tools\xUnit;C:\Program Files\nodejs;C:\Program Files (x86)\iojs;C:\Program Files\iojs;C:\Users\appveyor\AppData\Roaming\npm;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\;C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\;C:\Program Files\Microsoft SQL Server\130\DTS\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\130\Tools\Binn\;C:\Ruby193\bin;C:\go\bin;C:\Program Files\Java\jdk1.8.0\bin;C:\Program Files (x86)\Apache\Maven\bin;C:\Python27;C:\Python27\Scripts;C:\Program Files\erl8.3\bin;C:\Program Files (x86)\CMake\bin;C:\Tools\curl\bin;C:\Program Files\LLVM\bin;C:\Users\appveyor\.dnx\bin;C:\Program Files\Microsoft DNX\Dnvm\;C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin;C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130;C:\Program Files\Amazon\AWSCLI\;C:\Program Files\dotnet\;C:\Tools\vcpkg;C:\Program Files (x86)\dotnet\;C:\Users\appveyor\AppData\Local\Microsoft\WindowsApps;C:\Users\appveyor\AppData\Local\Yarn\bin;C:\Users\appveyor\AppData\Roaming\npm;C:\Program Files\Docker;C:\Program Files\Git\cmd;C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code;C:\Program Files\Microsoft SDKs\Service Fabric\Tools\ServiceFabricLocalClusterManager;C:\Program Files\Git\usr\bin;C:\Program Files (x86)\Yarn\bin;C:\ProgramData\chocolatey\bin;C:\Program Files (x86)\Microsoft SQL Server\140\Tools\Binn\;C:\Program Files\Microsoft SQL Server\140\Tools\Binn\;C:\Program Files\Microsoft SQL Server\140\DTS\Binn\;C:\Program Files (x86)\nodejs\;C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\TestPlatform;C:\Users\appveyor\AppData\Local\Microsoft\WindowsApps;C:\Users\appveyor\AppData\Local\Yarn\bin;C:\Users\appveyor\AppData\Roaming\npm;C:\Program Files\AppVeyor\BuildAgent\ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 11:31:15 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 Dec 2017 16:31:15 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1513182675.98.0.213398074469.issue15873@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4729 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 11:31:18 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 16:31:18 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513182678.54.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset d5dda98fa80405db82e2eb36ac48671b4c8c0983 by Victor Stinner in branch 'master': pymain_set_sys_argv() now copies argv (#4838) https://github.com/python/cpython/commit/d5dda98fa80405db82e2eb36ac48671b4c8c0983 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 11:31:18 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 16:31:18 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1513182678.65.0.912454111764.issue29240@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset d5dda98fa80405db82e2eb36ac48671b4c8c0983 by Victor Stinner in branch 'master': pymain_set_sys_argv() now copies argv (#4838) https://github.com/python/cpython/commit/d5dda98fa80405db82e2eb36ac48671b4c8c0983 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 11:33:05 2017 From: report at bugs.python.org (Alexey Izbyshev) Date: Wed, 13 Dec 2017 16:33:05 +0000 Subject: [issue32236] open() shouldn't silently ignore buffering=1 in binary mode In-Reply-To: <1512604009.3.0.213398074469.issue32236@psf.upfronthosting.co.za> Message-ID: <1513182785.52.0.213398074469.issue32236@psf.upfronthosting.co.za> Change by Alexey Izbyshev : ---------- keywords: +patch pull_requests: +4730 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 11:33:05 2017 From: report at bugs.python.org (Alexey Izbyshev) Date: Wed, 13 Dec 2017 16:33:05 +0000 Subject: [issue10344] codecs.open() buffering doc needs fix In-Reply-To: <1289084418.05.0.231852584468.issue10344@psf.upfronthosting.co.za> Message-ID: <1513182785.66.0.00913614298617.issue10344@psf.upfronthosting.co.za> Change by Alexey Izbyshev : ---------- keywords: +patch pull_requests: +4731 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 11:33:05 2017 From: report at bugs.python.org (Alexey Izbyshev) Date: Wed, 13 Dec 2017 16:33:05 +0000 Subject: [issue21332] subprocess bufsize=1 docs are misleading In-Reply-To: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za> Message-ID: <1513182785.78.0.0136706687182.issue21332@psf.upfronthosting.co.za> Change by Alexey Izbyshev : ---------- pull_requests: +4732 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 11:38:59 2017 From: report at bugs.python.org (Mathieu Dupuy) Date: Wed, 13 Dec 2017 16:38:59 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1513183139.19.0.213398074469.issue15873@psf.upfronthosting.co.za> Mathieu Dupuy added the comment: I finally released my work. It looks like Paul's work is more comprehensive, but if you want to pick one thing or two in mine, feel free. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 11:42:41 2017 From: report at bugs.python.org (Steve Dower) Date: Wed, 13 Dec 2017 16:42:41 +0000 Subject: [issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor In-Reply-To: <1513179338.41.0.213398074469.issue32302@psf.upfronthosting.co.za> Message-ID: <1513183361.68.0.213398074469.issue32302@psf.upfronthosting.co.za> Steve Dower added the comment: This is the bit that needs fixing https://github.com/python/cpython/blob/master/Lib/distutils/command/bdist_wininst.py#L340 bv = '.'.join(CRT_ASSEMBLY_VERSION.split('.', 2)[:2]) if bv == '14.11': # v141 and v140 are binary compatible, # so keep using the 14.0 stub. bv = '14.0' AppVeyor has clearly gotten hold of 14.12, which should also be binary compatible (version numbers here are not strictly SemVer, but the 14 indicates binary compatibility). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 11:44:25 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 Dec 2017 16:44:25 +0000 Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za> Message-ID: <1513183465.74.0.213398074469.issue30491@psf.upfronthosting.co.za> Yury Selivanov added the comment: First, I've no questions about the proposed implementation. It shouldn't have performance impact when unawaited coroutine tracking is off, which is the default. It will cause minimal overhead when the tracking is on, which is fine. Adding two extra pointers to coroutine objects should be OK too. Back to the specification. Few questions: 1. How will trio handle situations like: c = coro() await ... nursery.start_soon(c) ? There's a brief period of time when "c" is not being awaited, and thus it will be in the list that "sys.collect_unawaited_coroutines()" returns. How exactly do you plan to use this new API in Trio? Maybe creating a coroutine and not immediately passing it to 'start_soon' or similar API is an anti-pattern in Trio, but it is an OK thing to do in asyncio/curio/twisted. 2. What if another framework (say asyncio that you want to interoperate with) calls "sys.set_unawaited_coroutine_tracking(False)"? The API you propose has the *same* pitfall that 'sys.set_coroutine_wrapper()' has, when used by several frameworks simultaneously. 3. Given (2), why don't you have a coroutine wrapper like this: def trio_coroutine_wrapper(coro): ref = weakref.ref(coro, trio._untrack_coro) trio._track_coro(ref) return coro This way: - you don't introduce a lot of overhead, because there's no actual wrapper around a coroutine - you can capture the file/lineno at the point where a coroutine was created, which is useful for reporting unawaited coroutines ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 11:46:03 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 16:46:03 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1513183563.59.0.213398074469.issue29240@psf.upfronthosting.co.za> STINNER Victor added the comment: test_readline failed. It seems to be related to my commit: http://buildbot.python.org/all/#/builders/87/builds/360 ====================================================================== FAIL: test_nonascii (test.test_readline.TestReadline) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_readline.py", line 219, in test_nonascii self.assertIn(b"text 't\\xeb'\r\n", output) AssertionError: b"text 't\\xeb'\r\n" not found in bytearray(b"^A^B^B^B^B^B^B^B\t\tx\t\r\n[\\303\\257nserted]|t\x07\x08\x08\x08\x08\x08\x08\x08\x07\x07xrted]|t\x08\x08\x08\x08\x08\x08\x08\x07\r\nresult \'[\\xefnsexrted]|t\'\r\nhistory \'[\\xefnsexrted]|t\'\r\n") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 11:48:30 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 16:48:30 +0000 Subject: [issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor In-Reply-To: <1513179338.41.0.213398074469.issue32302@psf.upfronthosting.co.za> Message-ID: <1513183710.43.0.213398074469.issue32302@psf.upfronthosting.co.za> STINNER Victor added the comment: @Steve: do you want to work on a fix? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 11:59:23 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 16:59:23 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513184363.21.0.213398074469.issue32300@psf.upfronthosting.co.za> STINNER Victor added the comment: Usually, I use print(sorted(os.environ)) since I prefer a sorted list and it prevents such issue :-) David: > I agree that the result is surprising, but there may not be a generic fix. What about something like: vstinner at apu$ ./python -c 'import os; print(os.environ.keys())' vstinner at apu$ git diff diff --git a/Lib/_collections_abc.py b/Lib/_collections_abc.py index a5c7bfcda1..5e524dffbf 100644 --- a/Lib/_collections_abc.py +++ b/Lib/_collections_abc.py @@ -719,6 +719,9 @@ class KeysView(MappingView, Set): def __iter__(self): yield from self._mapping + def __repr__(self): + return '' % list(self) + KeysView.register(dict_keys) list(key_view) is valid. I mimicked dict views implementation: static PyObject * dictview_repr(_PyDictViewObject *dv) { PyObject *seq; PyObject *result; seq = PySequence_List((PyObject *)dv); if (seq == NULL) return NULL; result = PyUnicode_FromFormat("%s(%R)", Py_TYPE(dv)->tp_name, seq); Py_DECREF(seq); return result; } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 12:00:17 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 17:00:17 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513184417.09.0.213398074469.issue32300@psf.upfronthosting.co.za> STINNER Victor added the comment: If we decide to change abc.KeysView.__repr__, IMHO we should also modify abc.ValuesView.__repr__, and maybe also abc.ItemsView.__repr__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 12:15:53 2017 From: report at bugs.python.org (=?utf-8?q?David_Luke=C5=A1?=) Date: Wed, 13 Dec 2017 17:15:53 +0000 Subject: [issue32306] Clarify map API in concurrent.futures Message-ID: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za> New submission from David Luke? : The docstring for `concurrent.futures.Executor.map` starts by stating that it is "Equivalent to map(func, *iterables)". In the case of Python 3, I would argue this is true only superficially: with `map`, the user expects memory-efficient processing, i.e. that the entire resulting collection will not be held in memory at once unless s/he requests so e.g. with `list(map(...))`. (In Python 2, the expectations are different of course.) On the other hand, while `Executor.map` superficially returns a generator, which seems to align with this expectation, what happens behind the scenes is that the call blocks until all results are computed and only then starts yielding them. In other words, they have to be stored in memory all at once at some point. The lower-level multiprocessing module also describes `multiprocessing.pool.Pool.map` as "A parallel equivalent of the map() built-in function", but at least it immediately goes on to add that "It blocks until the result is ready.", which is a clear indication that all of the results will have to be stored somewhere before being yielded. I can think of several ways the situation could be improved, listed here from most conservative to most progressive: 1. Add "It blocks until the result is ready." to the docstring of `Executor.map` as well, preferably somewhere at the beginning. 2. Reword the docstrings of both `Executor.map` and `Pool.map` so that they don't describe the functions as "equivalent" to built-in `map`, which raises the wrong expectations. ("Similar to map(...), but blocks until all results are collected and only then yields them.") 3. I would argue that the function that can be described as semantically equivalent to `map` is actually `Pool.imap`, which yields results as they're being computed. It would be really nice if this could be added to the higher-level `futures` API, along with `Pool.imap_unordered`. `Executor.map` simply doesn't work for very long streams of data. 4. Maybe instead of adding `imap` and `imap_unordered` methods to `Executor`, it would be a good idea to change the signature of `Executor.map(func, *iterables, timeout=None, chunksize=1)` to `Executor.map(func, *iterables, timeout=None, chunksize=1, block=True, ordered=True)`, in order to keep the API simple with good defaults while providing flexibility via keyword arguments. 5. I would go so far as to say that for me personally, the `block` argument to the version of `Executor.map` proposed in #4 above should be `False` by default, because that would make it behave most like built-in `map`, which is the least suprising behavior. But I've observed that for smaller work loads, `imap` tends to be slower than `map`, so I understand it might be a tradeoff between performance and semantics. Still, in a higher-level API meant for non-experts, I think semantics should be emphasized. If the latter options seem much too radical, please consider at least something along the lines of #1 above, I think it would help people correct their expectations when they first encounter the API :) ---------- components: Library (Lib) messages: 308221 nosy: David Luke? priority: normal severity: normal status: open title: Clarify map API in concurrent.futures type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 12:19:43 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Wed, 13 Dec 2017 17:19:43 +0000 Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za> Message-ID: <1513185583.73.0.213398074469.issue30491@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: Your last description is about exactly what https://github.com/python-trio/trio/pull/176 is about (which I need to resurect) There are some issue with weakref some that I don't remember, but one of them is (IIRC): what if a non-awaited coro get collected before being awaited and check by trio ? send_ping() # don't care about result, forgot await # get collected await something_that_will_trigger_check_coros_weakreaf() # oh no ! So if its weak-refd then you can't be sure you are actually preventing non-awaited coros. By default in trio we also would like to enforce immediate coro awaiting, but we of course would provide a convenience function to wrap coroutines you really do not want to await now. (Explicit is better than implicit) So you would write: c = coro() really_not_awaiting_now_leave_me_alone(c) await ... # nursery.start_soon(c) What above PR does is check each time you enter the trio scheduler whether there is unawaited Coros (not marked as really_no_not_awaiting_now), and if so, next time you restart this task (or enter an cancellation point.. but details) raise a NonAwaitedCoroutineError. It does not raise _exactly_ where it was not awaited but narrow down where the non-awaited coro is (between two schedule point). And _if_ you enable tracemalloc the error message give you where the stack trace that created this coro. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 12:21:38 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Dec 2017 17:21:38 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513185698.39.0.213398074469.issue32300@psf.upfronthosting.co.za> R. David Murray added the comment: Agreed about the other classes if we change this. Your solution looks reasonable to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 12:32:04 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 Dec 2017 17:32:04 +0000 Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za> Message-ID: <1513186324.43.0.213398074469.issue30491@psf.upfronthosting.co.za> Yury Selivanov added the comment: > send_ping() # don't care about result, forgot await > # get collected > await something_that_will_trigger_check_coros_weakreaf() # oh no ! I don't understand what you are trying to say with this example. What is "something_that_will_trigger_check_coros_weakreaf" supposed to do? The point of my proposal that you will have a coroutine reported at the "get collected" point in CPython, or sometime later in PyPy. > So if its weak-refd then you can't be sure you are actually preventing non-awaited coros. Sorry, I don't understand this sentence either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 12:43:42 2017 From: report at bugs.python.org (MosesofEgypt) Date: Wed, 13 Dec 2017 17:43:42 +0000 Subject: [issue32004] Allow specifying code packing order in audioop adpcm functions In-Reply-To: <1510357207.47.0.213398074469.issue32004@psf.upfronthosting.co.za> Message-ID: <1513187022.95.0.213398074469.issue32004@psf.upfronthosting.co.za> MosesofEgypt added the comment: Added serhiy.storchaka to nosy list as the issue has been open for over a month without response(not sure if I should have done this in the first place). ---------- nosy: +serhiy.storchaka versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 12:46:34 2017 From: report at bugs.python.org (Natanael Copa) Date: Wed, 13 Dec 2017 17:46:34 +0000 Subject: [issue32307] Bad assumption on thread stack size makes python crash with musl libc Message-ID: <1513187194.31.0.213398074469.issue32307@psf.upfronthosting.co.za> New submission from Natanael Copa : Python assumes that the system default thread stack size is big enough for python, except for OSX and FreeBSD where stack size is explicitly set. With musl libc the system thread stack size is only 80k, which leads to hard crash before `sys.getrecursionlimit()` is hit. See: https://github.com/python/cpython/blob/master/Python/thread_pthread.h#L22 Testcase: import threading import sys def f(n=0): try: print(n) f(n+1) except Exception: print("we hit recursion limit") sys.exit(0) t = threading.Thread(target=f) t.start() This can be pasted into: docker run --rm -it python:2.7-alpine docker run --rm -it python:3.6-alpine ---------- components: Interpreter Core messages: 308226 nosy: Natanael Copa priority: normal severity: normal status: open title: Bad assumption on thread stack size makes python crash with musl libc type: crash versions: Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 12:54:47 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 13 Dec 2017 17:54:47 +0000 Subject: [issue32236] open() shouldn't silently ignore buffering=1 in binary mode In-Reply-To: <1512604009.3.0.213398074469.issue32236@psf.upfronthosting.co.za> Message-ID: <1513187687.22.0.213398074469.issue32236@psf.upfronthosting.co.za> Antoine Pitrou added the comment: After looking at the PR, I think it would be a bit too strong to raise an error. Perhaps emit a warning instead? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 13:12:56 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 13 Dec 2017 18:12:56 +0000 Subject: [issue32307] Bad assumption on thread stack size makes python crash with musl libc In-Reply-To: <1513187194.31.0.213398074469.issue32307@psf.upfronthosting.co.za> Message-ID: <1513188776.48.0.213398074469.issue32307@psf.upfronthosting.co.za> R. David Murray added the comment: Well, from our point of view it isn't a bad assumption, it's that muslc needs to be added to the list of exceptions. (I know almost nothing about this...I assume there is some reason we can't determine the stack size programatically?) Would you care to propose a PR? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 13:18:16 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 18:18:16 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513189096.21.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4733 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 13:28:38 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 Dec 2017 18:28:38 +0000 Subject: [issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub() Message-ID: <1513189718.03.0.213398074469.issue32308@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : Currently re.sub() replaces empty matches only when not adjacent to a previous match. This makes it inconsistent with re.findall() and re.finditer() which finds empty matches adjacent to a previous non-empty match and with other RE engines. Proposed PR makes all functions that makes repeated searching (re.split(), re.sub(), re.findall(), re.finditer()) mutually consistent. The PR change the behavior of re.split() too, but this doesn't matter, since it already is different from the 3.6 behavior. BDFL have approved this change. This change doesn't break any stdlib code. It is expected that it will not break much third-party code, and even if it will break some code, it can be easily rewritten. For example replacing re.sub('(.*)', ...) (which now matches an empty string at the end of the string) with re.sub('(.+)', ...) is an obvious fix. ---------- assignee: serhiy.storchaka components: Library (Lib), Regular Expressions messages: 308229 nosy: ezio.melotti, mrabarnett, serhiy.storchaka priority: normal severity: normal status: open title: Replace empty matches adjacent to a previous non-empty match in re.sub() type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 13:34:24 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 Dec 2017 18:34:24 +0000 Subject: [issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub() In-Reply-To: <1513189718.03.0.213398074469.issue32308@psf.upfronthosting.co.za> Message-ID: <1513190064.76.0.213398074469.issue32308@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +4734 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 14:06:46 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 13 Dec 2017 19:06:46 +0000 Subject: [issue32292] Building fails on Windows In-Reply-To: <1513100737.71.0.213398074469.issue32292@psf.upfronthosting.co.za> Message-ID: <1513192006.49.0.213398074469.issue32292@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, I've decided to bite the bullet. I uninstalled VS 2015 and installed VS 2017 Community Edition. Things seem to work now. Thanks for the help! ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 14:14:36 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Wed, 13 Dec 2017 19:14:36 +0000 Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za> Message-ID: <1513192476.96.0.213398074469.issue30491@psf.upfronthosting.co.za> Matthias Bussonnier added the comment: Let me try to explain better, I'm pretty sure there is just a misunderstanding from some of use in the vocabulary or presupposition we start from. I have the impression that you feel like the API will automatically make coroutine raise when they are not awaited, while I have the impression that in only provide a tool for frameworks to detect unawaited coros and raise As soon as possible in the right place. We have the scheduler/eventloop that advance users tasks. Each time a user task yield to the scheduler directly, or indirectly, the scheduler want to check that since last time it was called in the same task no non-awaited coroutines are pending, that is to say await sleep(0) # yield to scheduler c1 = coro() await c1 c2 = coro() c3 = coro() del c3 gc.collect() await sleep(0) # yield again. We want to make sure that between the two `sleep(0)` no coro is unawaited. Let's assume `await coro()` does not itself yield to the scheduler for simplicity. In above case you can see that c2 is not awaited, so according to Nathaniel proposal, `sys.collect_unawaited_coroutines()` would returns `[c2, c3]`, So the second sleep(0) can raise NonAwaitedCoroutineError, (and if tracemalloc is enabled give more informations). You propose to use weakref.ref(coro, trio._untrack_coro) And I suppose you want us to do def _untrack_coro(self, ref): coro = ref() if inspect.getcoroutinestate(c) == 'CORO_STARTED' .. do what's necessary for unawaited coroutine. else: # just discard from the tracked list. Unfortunately: > the weak reference object will be passed as the only parameter to the > callback; *the referent will no longer be available*. Thus we cannot check the state of the collected coroutine, according to my understanding and experiments (Also we need to keep ref alive, but that's a minor inconvenience). My guess is the referent is not around for users not to suddenly add a ref to it... So such a tracked list could only be use to know if coroutines where GC'd or not. If you are using wekrefs, you may also think about `sys.collect_unawaited_coroutines()` returning weakref list, but that would lead to `WeakRefList[c2]` because c3 was collected :-(. While we still raise because of c2, a user logic only containing c3 would pass the "no unawaited coroutines". To respond to your answer more specifically: > 1. How will trio handle situations like: > c = coro() > await ... > nursery.start_soon(c) It depends what your `...` is, if its yielding to the trio scheduler, then the scheduler will check unawaited coroutines, see that the list is non-empty and raise a NonAwaitedCoroutineError at your `await ...`. In the case your `await ...` does not yield.. then nothing. > Maybe creating a coroutine and not immediately passing it to 'start_soon' or similar API is an anti-pattern in Trio, but it is an OK thing to do in asyncio/curio/twisted. Yes, and the trio/curio/asyncio library is responsible to check `sys.collect_unawaited_coroutines()`, and react appropriately. Trio will likely decide to raise. Asyncio can just forget this option exists. > 2. What if another framework (say asyncio that you want to interoperate with) calls "sys.set_unawaited_coroutine_tracking(False)"? > The API you propose has the *same* pitfall that 'sys.set_coroutine_wrapper()' has, when used by several frameworks simultaneously. As far as I understand you'll need to yield back to the other framework at some point. Then it's IMHO to the author to make sure to save the state of `sys.collect_unawaited_coroutines()`, set `sys.set_unawaited_coroutine_tracking(enabled: bool)` to what the other framework expect, and do the opposite when they get control back. > 3. Given (2), why don't you have a coroutine wrapper like this: > def trio_coroutine_wrapper(coro): > ref = weakref.ref(coro, trio._untrack_coro) > trio._track_coro(ref) > return coro We can't use weakref (cf issue with c3/weakref above). We could track all coroutines, with a normal container, which is exactly what we do here[1], except now everytime you need to check `inspect.getcoroutinestate(coro) == 'CORO_CREATED'` on every item. You can't use weakref callback as you can't check the coro state in this case. The check on all coro everytime does add potentially significant overhead, AND block the GC of awaited couroutines in between checks. While we _do want_ to block GC of coroutine only if `sys.collect_unawaited_coroutines()` is set to true and coroutine is not awaited. Also we like to keep the actual non-awaited coro around for error messages, but I guess we can do without. One alternative would be the ability to add a callback when coros change states... But I though coroutines where one way to avoid callbacks... Now you have way more understanding of core CPython than me, and I may just not figure out what you would write in your `trio._untrack_coro`, or miss something else. I hope that this exposition at least help to clarify the various sue case and attempt. Sorry for the long response. 1: https://github.com/python-trio/trio/pull/176/files#diff-ce66495f4b73d01ba38f06ae87955d3aR54 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 14:15:18 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 13 Dec 2017 19:15:18 +0000 Subject: [issue32104] add method throw() to asyncio.Task In-Reply-To: <1511275452.66.0.213398074469.issue32104@psf.upfronthosting.co.za> Message-ID: <1513192518.03.0.213398074469.issue32104@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I think the ship has sailed. Now too many code is based on assumption that the only way to cancel a task from outer code is `task.cancel()`. Internally it is turned into try: await do_stuff() except asyncio.CancelledError: do_task_cancellation() Raising *any* exception for cancellation breaks all existing code like this. Moreover figuring out if a task was cancelled from outside (by timeout for example) or exception was raised by inner code becomes impossible. I suggest closing the issue with "wont fix" resolution. ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 14:16:20 2017 From: report at bugs.python.org (Steve Dower) Date: Wed, 13 Dec 2017 19:16:20 +0000 Subject: [issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor In-Reply-To: <1513179338.41.0.213398074469.issue32302@psf.upfronthosting.co.za> Message-ID: <1513192580.0.0.213398074469.issue32302@psf.upfronthosting.co.za> Steve Dower added the comment: Happy for someone else to do it. I won't have time this week - too much going on at work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 14:16:34 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 13 Dec 2017 19:16:34 +0000 Subject: [issue31620] asyncio.Queue leaks memory if the queue is empty and consumers poll it frequently In-Reply-To: <1506619669.24.0.466225441844.issue31620@psf.upfronthosting.co.za> Message-ID: <1513192594.02.0.213398074469.issue31620@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Sorry for late closing the issue, PR was merged a month ago. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 14:18:26 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 13 Dec 2017 19:18:26 +0000 Subject: [issue26259] Memleak when repeated calls to asyncio.queue.Queue.get is performed, without push to queue. In-Reply-To: <1454342780.58.0.210365622359.issue26259@psf.upfronthosting.co.za> Message-ID: <1513192706.96.0.213398074469.issue26259@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Duplicate of https://bugs.python.org/issue31620 ---------- nosy: +asvetlov resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> asyncio.Queue leaks memory if the queue is empty and consumers poll it frequently _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 14:22:40 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Wed, 13 Dec 2017 19:22:40 +0000 Subject: [issue17852] Built-in module _io can lose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1513192960.57.0.213398074469.issue17852@psf.upfronthosting.co.za> Change by Neil Schemenauer : ---------- pull_requests: +4735 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 14:30:25 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Wed, 13 Dec 2017 19:30:25 +0000 Subject: [issue17852] Built-in module _io can lose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1513193425.37.0.213398074469.issue17852@psf.upfronthosting.co.za> Neil Schemenauer added the comment: I created a new PR which uses the atexit module instead of using _Py_PyAtExit. I think registering in io.py is okay. I see that atexit is now implemented in C. Rather than registering in io.py, we could create a C API to register callbacks (i.e. atexit_register). That would perhaps be a bit cleaner. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 14:49:44 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 Dec 2017 19:49:44 +0000 Subject: [issue32296] Implement asyncio._get_running_loop() and get_event_loop() in C In-Reply-To: <1513119563.35.0.213398074469.issue32296@psf.upfronthosting.co.za> Message-ID: <1513194584.85.0.213398074469.issue32296@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset a70232f28882d2fecb3ebe06643867701016070f by Yury Selivanov in branch 'master': bpo-32296: Implement asyncio.get_event_loop and _get_running_loop in C. (#4827) https://github.com/python/cpython/commit/a70232f28882d2fecb3ebe06643867701016070f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 14:50:10 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 Dec 2017 19:50:10 +0000 Subject: [issue32296] Implement asyncio._get_running_loop() and get_event_loop() in C In-Reply-To: <1513119563.35.0.213398074469.issue32296@psf.upfronthosting.co.za> Message-ID: <1513194610.32.0.213398074469.issue32296@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 14:54:21 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 13 Dec 2017 19:54:21 +0000 Subject: [issue32309] Implement asyncio.create_task() and asyncio.run_in_executor shortcuts Message-ID: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za> New submission from Andrew Svetlov : loop.create_task() and loop.run_in_executor are present very often in user code. But they are require a loop instance, actual call looks like loop = asyncio.get_running_loop() loop.create_task(coro()) The proposal adds create_task(coro) and run_in_executor(executor, func, *args) shortcuts for this. ---------- assignee: docs at python components: Documentation, asyncio messages: 308238 nosy: asvetlov, docs at python, yselivanov priority: normal severity: normal status: open title: Implement asyncio.create_task() and asyncio.run_in_executor shortcuts versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 14:55:39 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 13 Dec 2017 19:55:39 +0000 Subject: [issue32309] Implement asyncio.create_task() and asyncio.run_in_executor shortcuts In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za> Message-ID: <1513194939.12.0.213398074469.issue32309@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- keywords: +patch pull_requests: +4736 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 15:03:46 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 Dec 2017 20:03:46 +0000 Subject: [issue32309] Implement asyncio.create_task() and asyncio.run_in_executor shortcuts In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za> Message-ID: <1513195426.44.0.213398074469.issue32309@psf.upfronthosting.co.za> Yury Selivanov added the comment: I don't like the low-level API of run_in_executor. "executor" being the first argument, the inability to pass **kwargs, etc. I'd expect to see a more high-level API, perhaps the one that supports 'async with': async with asyncio.ThreadPool() as pool: f1 = pool.run(func1) f2 = pool.run(func2) r3 = await pool.run(func3) r1 = f1.result() r2 = f2.result() print(r1, r2, r3) I mean it's great that we can use 'concurrent.futures' in asyncio, but having native asyncio pools implementation would be way more convenient to the users. In any case, can we focus this issue on the "run_in_executor" API, and open a new one for "create_task"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 15:05:59 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 20:05:59 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513195559.3.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 11a247df88f15b51feff8a3c46005676bb29b96e by Victor Stinner in branch 'master': bpo-32030: Add _PyPathConfig_ComputeArgv0() (#4845) https://github.com/python/cpython/commit/11a247df88f15b51feff8a3c46005676bb29b96e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 15:08:04 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 20:08:04 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513195684.63.0.213398074469.issue32300@psf.upfronthosting.co.za> STINNER Victor added the comment: Cheryl: would you like to work on a PR? If yes, tests are needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 15:25:35 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Wed, 13 Dec 2017 20:25:35 +0000 Subject: [issue32310] Remove _Py_PyAtExit from Python.h Message-ID: <1513196735.39.0.213398074469.issue32310@psf.upfronthosting.co.za> New submission from Neil Schemenauer : _Py_PyAtExit only supports on callback function. Its sole use it to be used by atexit. IMHO, it should be removed from Python.h to prevent misuse. ---------- components: Interpreter Core messages: 308242 nosy: nascheme priority: low severity: normal stage: patch review status: open title: Remove _Py_PyAtExit from Python.h type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 15:27:17 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 13 Dec 2017 20:27:17 +0000 Subject: [issue32309] Implement asyncio.create_task() and asyncio.run_in_executor shortcuts In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za> Message-ID: <1513196837.52.0.213398074469.issue32309@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- assignee: docs at python -> nosy: -docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 15:28:03 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 13 Dec 2017 20:28:03 +0000 Subject: [issue32311] Implement asyncio.create_task() shortcut Message-ID: <1513196883.62.0.213398074469.issue32311@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- components: Library (Lib), asyncio nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Implement asyncio.create_task() shortcut versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 15:28:43 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 13 Dec 2017 20:28:43 +0000 Subject: [issue32309] Implement asyncio.run_in_executor shortcut In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za> Message-ID: <1513196923.95.0.213398074469.issue32309@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Removed create_task() from title ---------- title: Implement asyncio.create_task() and asyncio.run_in_executor shortcuts -> Implement asyncio.run_in_executor shortcut _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 15:29:26 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 Dec 2017 20:29:26 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513196966.21.0.213398074469.issue32300@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Don't make KeysView.__repr__ and ValuesView.__repr__ containing the lists of all keys and values. This will make the repr of the view of a mapping which is a proxy of an external DB containing the full content of that DB, which can be gigabytes. See for example rejected issue21670. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 15:29:27 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 13 Dec 2017 20:29:27 +0000 Subject: [issue32311] Implement asyncio.create_task() shortcut Message-ID: <1513196967.27.0.213398074469.issue32311@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- keywords: +patch pull_requests: +4737 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 15:30:27 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Wed, 13 Dec 2017 20:30:27 +0000 Subject: [issue32310] Remove _Py_PyAtExit from Python.h In-Reply-To: <1513196735.39.0.213398074469.issue32310@psf.upfronthosting.co.za> Message-ID: <1513197027.97.0.213398074469.issue32310@psf.upfronthosting.co.za> Change by Neil Schemenauer : ---------- keywords: +patch pull_requests: +4738 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 15:35:37 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 13 Dec 2017 20:35:37 +0000 Subject: [issue32309] Implement asyncio.run_in_executor shortcut In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za> Message-ID: <1513197337.6.0.213398074469.issue32309@psf.upfronthosting.co.za> Andrew Svetlov added the comment: https://bugs.python.org/issue32311 opened for create_task() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 15:45:20 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Wed, 13 Dec 2017 20:45:20 +0000 Subject: [issue32312] Create Py_AtExitRegister C API Message-ID: <1513197920.45.0.213398074469.issue32312@psf.upfronthosting.co.za> New submission from Neil Schemenauer : It would be handy to have a C API that registered an atexit function, similar to what calling atexit.register does. This API could be used by C extension modules to register atexit functions. I think the implementation would be fairly simple. We need a function that calls atexit_register(). The tricky bit is that we need to make sure the atexit module has been initialized as atexit_register uses the module state. This API is different from Py_AtExit in that atexit.register() calls the function early in the interpreter shutdown whereas Py_AtExit calls functions very late in the shutdown. ---------- messages: 308246 nosy: nascheme priority: low severity: normal stage: needs patch status: open title: Create Py_AtExitRegister C API type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 15:59:07 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 20:59:07 +0000 Subject: [issue32296] Implement asyncio._get_running_loop() and get_event_loop() in C In-Reply-To: <1513119563.35.0.213398074469.issue32296@psf.upfronthosting.co.za> Message-ID: <1513198747.26.0.213398074469.issue32296@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, sometimes it's better to wait for AppVeyor :-) You broke all Windows buildbots! :-) Example: http://buildbot.python.org/all/#/builders/40/builds/278 ====================================================================== ERROR: test_get_event_loop_returns_running_loop (test.test_asyncio.test_events.TestCGetEventLoop) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_asyncio\test_events.py", line 2738, in setUp watcher = asyncio.SafeChildWatcher() AttributeError: module 'asyncio' has no attribute 'SafeChildWatcher' ====================================================================== ERROR: test_get_event_loop_returns_running_loop (test.test_asyncio.test_events.TestPyGetEventLoop) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_asyncio\test_events.py", line 2738, in setUp watcher = asyncio.SafeChildWatcher() AttributeError: module 'asyncio' has no attribute 'SafeChildWatcher' ---------- nosy: +vstinner resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 15:59:48 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 20:59:48 +0000 Subject: [issue32312] Create Py_AtExitRegister C API In-Reply-To: <1513197920.45.0.213398074469.issue32312@psf.upfronthosting.co.za> Message-ID: <1513198788.32.0.213398074469.issue32312@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- nosy: +pitrou, vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 16:00:18 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 21:00:18 +0000 Subject: [issue32312] Create Py_AtExitRegister C API In-Reply-To: <1513197920.45.0.213398074469.issue32312@psf.upfronthosting.co.za> Message-ID: <1513198818.03.0.213398074469.issue32312@psf.upfronthosting.co.za> STINNER Victor added the comment: See also: [Python-Dev] PEP 489: module m_traverse called with NULL module state https://mail.python.org/pipermail/python-dev/2017-December/151238.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 16:04:52 2017 From: report at bugs.python.org (Aaron Meurer) Date: Wed, 13 Dec 2017 21:04:52 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513199092.64.0.213398074469.issue32300@psf.upfronthosting.co.za> Aaron Meurer added the comment: So the best fix is to just override keys() in the _Environ class, so that it returns an EnvironKeysView class that overrides __repr__? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 16:11:30 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 13 Dec 2017 21:11:30 +0000 Subject: [issue32312] Create Py_AtExitRegister C API In-Reply-To: <1513197920.45.0.213398074469.issue32312@psf.upfronthosting.co.za> Message-ID: <1513199490.74.0.213398074469.issue32312@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Calling "atexit.register" using the C API isn't very difficult. The annoying part is to wrap a simple C function pointer in a callable PyObject (I don't think there is a simple C API for that). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 16:11:40 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 13 Dec 2017 21:11:40 +0000 Subject: [issue32312] Create Py_AtExitRegister C API In-Reply-To: <1513197920.45.0.213398074469.issue32312@psf.upfronthosting.co.za> Message-ID: <1513199500.81.0.213398074469.issue32312@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 16:29:35 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 21:29:35 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513200575.47.0.213398074469.issue32300@psf.upfronthosting.co.za> STINNER Victor added the comment: > Don't make KeysView.__repr__ and ValuesView.__repr__ containing the lists of all keys and values. This will make the repr of the view of a mapping which is a proxy of an external DB containing the full content of that DB, which can be gigabytes. See for example rejected issue21670. The current implementation displays repr(self._mapping): class MappingView(Sized): ... def __repr__(self): return '{0.__class__.__name__}({0._mapping!r})'.format(self) For your proxy example: what is the proxy? The KeysView subtype, or the mapping? repr(list), repr(dict) and repr(set) all render their full content in the result, no? repr() on a list of 1 million of items *will* render all items, even if nobody wants to read such very long string :-) If you want to get a smarter __repr__() than the default implementation: just override __repr__(), no? I don't see why KeysView must be special. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 16:34:53 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 21:34:53 +0000 Subject: [issue32312] Create Py_AtExitRegister C API In-Reply-To: <1513197920.45.0.213398074469.issue32312@psf.upfronthosting.co.za> Message-ID: <1513200893.62.0.213398074469.issue32312@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh by the way, if we decide to add a function, I would prefer to start with a private function. The C API is big enough. We can decide in the next version if the function becomes useful enough to justify to be added to the public API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 16:38:57 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 Dec 2017 21:38:57 +0000 Subject: [issue32296] Implement asyncio._get_running_loop() and get_event_loop() in C In-Reply-To: <1513119563.35.0.213398074469.issue32296@psf.upfronthosting.co.za> Message-ID: <1513201137.38.0.213398074469.issue32296@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- pull_requests: +4739 stage: resolved -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 16:39:20 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 Dec 2017 21:39:20 +0000 Subject: [issue32296] Implement asyncio._get_running_loop() and get_event_loop() in C In-Reply-To: <1513119563.35.0.213398074469.issue32296@psf.upfronthosting.co.za> Message-ID: <1513201160.36.0.213398074469.issue32296@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks Victor. I've made a PR to fix this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 16:39:34 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 21:39:34 +0000 Subject: [issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor In-Reply-To: <1513179338.41.0.213398074469.issue32302@psf.upfronthosting.co.za> Message-ID: <1513201174.75.0.213398074469.issue32302@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- keywords: +patch pull_requests: +4740 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 16:44:18 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 21:44:18 +0000 Subject: [issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor In-Reply-To: <1513179338.41.0.213398074469.issue32302@psf.upfronthosting.co.za> Message-ID: <1513201458.61.0.213398074469.issue32302@psf.upfronthosting.co.za> STINNER Victor added the comment: > Happy for someone else to do it. I won't have time this week - too much going on at work. Sure. I wrote a PR to fix the exact bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 16:46:39 2017 From: report at bugs.python.org (Aaron Meurer) Date: Wed, 13 Dec 2017 21:46:39 +0000 Subject: [issue32313] Wrong inspect.getsource for datetime Message-ID: <1513201599.09.0.213398074469.issue32313@psf.upfronthosting.co.za> New submission from Aaron Meurer : inspect.getsource(datetime) shows the Python source code for datetime, even when it is the C extension. This is very confusing. I believe it's because _datetime is used to override everything in datetime at the end of the file (here https://github.com/python/cpython/blob/11a247df88f15b51feff8a3c46005676bb29b96e/Lib/datetime.py#L2285), but __file__ is not imported. ---------- messages: 308255 nosy: Aaron.Meurer priority: normal severity: normal status: open title: Wrong inspect.getsource for datetime _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 16:47:08 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 Dec 2017 21:47:08 +0000 Subject: [issue32314] Implement asyncio.run() Message-ID: <1513201628.59.0.213398074469.issue32314@psf.upfronthosting.co.za> New submission from Yury Selivanov : There's a fairly extensive discussion here: https://github.com/python/asyncio/pull/465 In short, asyncio.run() is a pretty straightforward addition, so let's add it. The discussion was more focused on the asyncio.run_forever() proposal. I now think that it shouldn't be implemented in asyncio. Instead we should fix cases where 'loop.run_forever' is usually required. Mainly that's servers, and they are easily fixable by making "Server" an async context manager and implementing a "server.serve_forever()" method. That way, with asyncio.run(): async def serve_something(): async with asyncio.start_server(...) as server: await server.serve_forever() asyncio.run(serve_something()) # No loop.run_forever()! ---------- assignee: yselivanov components: asyncio messages: 308256 nosy: asvetlov, lukasz.langa, yselivanov priority: normal severity: normal status: open title: Implement asyncio.run() type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 16:48:25 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 Dec 2017 21:48:25 +0000 Subject: [issue32314] Implement asyncio.run() In-Reply-To: <1513201628.59.0.213398074469.issue32314@psf.upfronthosting.co.za> Message-ID: <1513201705.1.0.213398074469.issue32314@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4741 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 16:54:44 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Wed, 13 Dec 2017 21:54:44 +0000 Subject: [issue32312] Create Py_AtExitRegister C API In-Reply-To: <1513197920.45.0.213398074469.issue32312@psf.upfronthosting.co.za> Message-ID: <1513202084.24.0.213398074469.issue32312@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Private is fine. We want to get the design correct before making it part of the official API. My thought is that providing a handy atexit hook would be a good thing in that it could be an alternative to 3rd party code using __del__ to do cleanup. One downside of atexit is that there is still a question of ordering the calls during shutdown. I had the idea that maybe register() should take some sort of argument to specify when the function should be called. That seems like leading down the road of madness maybe. It would be useful to look at what other languages do, e.g. Java. My understanding is that new versions of Java encourage finalizers like weakref callbacks and discourage or disallow finalizers like __del__. I.e. you are not allowed to see the state of the object being finalized and cannot resurrect it. Regarding m_traverse, maybe the list of finalizers should be stored somewhere in the interpreter state, not in the atexit module state. That would make more sense to me. atexit could merely be a way to manage it rather than actually holding it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 17:05:32 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 13 Dec 2017 22:05:32 +0000 Subject: [issue32314] Implement asyncio.run() In-Reply-To: <1513201628.59.0.213398074469.issue32314@psf.upfronthosting.co.za> Message-ID: <1513202732.48.0.213398074469.issue32314@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I like avoiding run_forever() -- the function always was too cumbersome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 17:07:44 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 Dec 2017 22:07:44 +0000 Subject: [issue32314] Implement asyncio.run() In-Reply-To: <1513201628.59.0.213398074469.issue32314@psf.upfronthosting.co.za> Message-ID: <1513202864.4.0.213398074469.issue32314@psf.upfronthosting.co.za> Yury Selivanov added the comment: I'll open a separate issue to improve Server's API. AFAIK it's the main reason for having run_forever(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 17:11:11 2017 From: report at bugs.python.org (Martin) Date: Wed, 13 Dec 2017 22:11:11 +0000 Subject: [issue32315] can't run any scripts with 2.7.x, 32 and 64-bit Message-ID: <1513203071.76.0.213398074469.issue32315@psf.upfronthosting.co.za> New submission from Martin : When I try to run a really simple script like: def fun(a): print a return I get this error: Exception in Tkinter callback Traceback (most recent call last): File "C:\Python27\lib\lib-tk\Tkinter.py", line 1541, in __call__ return self.func(*args) File "C:\Python27\lib\idlelib\MultiCall.py", line 166, in handler r = l[i](event) File "C:\Python27\lib\idlelib\ScriptBinding.py", line 149, in run_module_event if PyShell.use_subprocess: AttributeError: 'module' object has no attribute 'use_subprocess' It basically means Python is only usable by copy-pasting code into Shell, any kind of script fails with that error. ---------- components: Library (Lib) messages: 308260 nosy: DoctorEvil priority: normal severity: normal status: open title: can't run any scripts with 2.7.x, 32 and 64-bit versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 17:28:43 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 Dec 2017 22:28:43 +0000 Subject: [issue32296] Implement asyncio._get_running_loop() and get_event_loop() in C In-Reply-To: <1513119563.35.0.213398074469.issue32296@psf.upfronthosting.co.za> Message-ID: <1513204123.68.0.213398074469.issue32296@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset bfbf04ef18c93ca8cab0453f76aeea1d8fc23fb1 by Yury Selivanov in branch 'master': bpo-32296: Unbreak tests on Windows (#4850) https://github.com/python/cpython/commit/bfbf04ef18c93ca8cab0453f76aeea1d8fc23fb1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 17:32:34 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 22:32:34 +0000 Subject: [issue32316] [3.6] make regen-all fails on Travis CI on "python3.6" command Message-ID: <1513204354.33.0.213398074469.issue32316@psf.upfronthosting.co.za> New submission from STINNER Victor : The cpython job of Travis CI compiles Python with clang and then run "make regen-all" which fails. "make regen-all" fails for example on regen-typeslots which runs "$(PYTHON_FOR_REGEN) ...". On Travis CI, $(PYTHON_FOR_REGEN) is "python3.6", but running python3.6 fails with: """ The `python3.6' command exists in these Python versions: 3.6 3.6.3 """ Example of failed build: https://travis-ci.org/python/cpython/jobs/315978517 ---------- components: Build messages: 308262 nosy: brett.cannon, vstinner, zach.ware priority: normal severity: normal status: open title: [3.6] make regen-all fails on Travis CI on "python3.6" command versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 17:40:59 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 22:40:59 +0000 Subject: [issue32316] [3.6] make regen-all fails on Travis CI on "python3.6" command In-Reply-To: <1513204354.33.0.213398074469.issue32316@psf.upfronthosting.co.za> Message-ID: <1513204859.8.0.213398074469.issue32316@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- keywords: +patch pull_requests: +4742 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 17:59:01 2017 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Wed, 13 Dec 2017 22:59:01 +0000 Subject: [issue32143] os.statvfs lacks f_fsid In-Reply-To: <1511713053.6.0.213398074469.issue32143@psf.upfronthosting.co.za> Message-ID: <1513205941.83.0.213398074469.issue32143@psf.upfronthosting.co.za> Change by Fred L. Drake, Jr. : ---------- nosy: +fdrake _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 18:02:54 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 13 Dec 2017 23:02:54 +0000 Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za> Message-ID: <1513206174.27.0.213398074469.issue30491@psf.upfronthosting.co.za> Yury Selivanov added the comment: Matthias, Thanks a lot for such a detailed write-up! I now better understand how you want to use the proposed API in Trio, and why the weakref approach isn't going to work (at least not in a straightforward way). >> 2. What if another framework (say asyncio that you want to interoperate with) calls "sys.set_unawaited_coroutine_tracking(False)"? >> The API you propose has the *same* pitfall that 'sys.set_coroutine_wrapper()' has, when used by several frameworks simultaneously. > As far as I understand you'll need to yield back to the other framework at some > point. Then it's IMHO to the author to make sure to save the state of > `sys.collect_unawaited_coroutines()`, set > `sys.set_unawaited_coroutine_tracking(enabled: bool)` to what the other > framework expect, and do the opposite when they get control back. Who do you refer to, when you say "author"? In any case, in my opinion, it doesn't matter. `sys.set_coroutine_wrapper` controls a single thread-local setting, `sys.set_unawaited_coroutine_tracking` *also* controls a single thread-local setting. Both of them have the exact same problem when there's more than one user of the API. So we can't consider this as a strong argument in favour of the 'set_unawaited_coroutine_tracking' API. We can fix asyncio to manage coroutine wrappers more responsively. Right now it will raise an error if there's a wrapper set by another framework. Ideally, event loops should get the current wrapper, set their own, and then restore the original wrapper when they are done. With that all in mind, my question is: have you guys tried to write a wrapper object in C for coroutines (or you can use Cython to get an idea)? You can have a freelist of such objects to make their instantiation super cheap. And you only need to proxy the '__await__' method (tp_as_async.am_await). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 18:27:44 2017 From: report at bugs.python.org (Garrett Berg) Date: Wed, 13 Dec 2017 23:27:44 +0000 Subject: [issue32317] sys.exc_clear() clears exception in other stack frames Message-ID: <1513207664.32.0.213398074469.issue32317@psf.upfronthosting.co.za> New submission from Garrett Berg : # Summary In python (2 or 3) it should always be valid to have a bare *raise* statement in an exception block. try: do_something() except SomeException: do_cleanup() raise # always reraises SomeException with original stack trace You can see this in the python exception documentation: https://docs.python.org/2.7/tutorial/errors.html#raising-exceptions # Reproduction of Failure of invariants Example python file where this doesn't work: from __future__ import print_function import sys def doclear(): """This should basically be a noop""" sys.exc_clear() try: 1/0 except ZeroDivisionError: exc = sys.exc_info()[0] print("first exc:", exc) assert exc is ZeroDivisionError try: 1/0 except ZeroDivisionError: exc = sys.exc_info()[0] print("second exc (before doclear):", exc) doclear() exc = sys.exc_info()[0] print("second exc (after doclear):", exc) assert sys.exc_info()[0] is ZeroDivisionError # fails Running in python2.7 gives: first exc: second exc (before doclear): second exc (after doclear): None Traceback (most recent call last): File "doclear.py", line 23, in assert sys.exc_info()[0] is ZeroDivisionError # fails AssertionError # Conclusion There seems to be a bug in python 2.7 where it doesn't follow it's own spec. [sys.exc_clear()](https://docs.python.org/2/library/sys.html#sys.exc_clear) states: > This function clears all information relating to the current or last > exception that occurred in the current thread. After calling this function, > exc_info() will return three None values until another exception is raised in > the current thread or *the execution stack returns to a frame where another > exception is being handled*. The above code is clear example where sys.exc_clear() is changing the value of sys.exc_info() *in a different stack frame*, which is against what is stated in the above docs. This bug makes it impossible to reraise with a bare raise statement when doing cleanup that could use sys.exc_clear(). In other words, calling into functions can *change your local state* with regards to what exception is being handled. ---------- components: Interpreter Core messages: 308264 nosy: Garrett Berg priority: normal severity: normal status: open title: sys.exc_clear() clears exception in other stack frames type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 18:29:50 2017 From: report at bugs.python.org (Garrett Berg) Date: Wed, 13 Dec 2017 23:29:50 +0000 Subject: [issue32317] sys.exc_clear() clears exception in other stack frames In-Reply-To: <1513207664.32.0.213398074469.issue32317@psf.upfronthosting.co.za> Message-ID: <1513207790.2.0.213398074469.issue32317@psf.upfronthosting.co.za> Garrett Berg added the comment: I forgot to post this: python --version Python 2.7.14 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 18:30:43 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 Dec 2017 23:30:43 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513207843.25.0.213398074469.issue32300@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: shelve.Shelf is the example of such kind. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 18:45:09 2017 From: report at bugs.python.org (Geoff Kuenning) Date: Wed, 13 Dec 2017 23:45:09 +0000 Subject: [issue32298] Email.quopriprime over-encodes characters In-Reply-To: <1513127837.95.0.213398074469.issue32298@psf.upfronthosting.co.za> Message-ID: <1513208709.9.0.213398074469.issue32298@psf.upfronthosting.co.za> Geoff Kuenning added the comment: I should have read that part of RFC 2047 before I submitted. I'd love to claim that I'm going to write a patch that would do as you suggest. But the reality is that I'm unlikely to find the time, so I'm going to be wise for once and avoid promising what I can't deliver. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 18:51:52 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 23:51:52 +0000 Subject: [issue32316] [3.6] make regen-all fails on Travis CI on "python3.6" command In-Reply-To: <1513204354.33.0.213398074469.issue32316@psf.upfronthosting.co.za> Message-ID: <1513209112.67.0.213398074469.issue32316@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 1d2a387b9526ef5f4d694734d8022e739f7fd410 by Victor Stinner in branch '3.6': bpo-32316: Travis CI: use PYTHON_FOR_REGEN=python3 (#4853) https://github.com/python/cpython/commit/1d2a387b9526ef5f4d694734d8022e739f7fd410 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 18:52:31 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 13 Dec 2017 23:52:31 +0000 Subject: [issue32316] [3.6] make regen-all fails on Travis CI on "python3.6" command In-Reply-To: <1513204354.33.0.213398074469.issue32316@psf.upfronthosting.co.za> Message-ID: <1513209151.97.0.213398074469.issue32316@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 19:06:27 2017 From: report at bugs.python.org (Garrett Berg) Date: Thu, 14 Dec 2017 00:06:27 +0000 Subject: [issue32317] sys.exc_clear() clears exception in other stack frames In-Reply-To: <1513207664.32.0.213398074469.issue32317@psf.upfronthosting.co.za> Message-ID: <1513209987.98.0.213398074469.issue32317@psf.upfronthosting.co.za> Garrett Berg added the comment: I found a workaround, and probably the reason this has not been detected before: import sys def doclear2() try: 1/0 except ZeroDivisionError: sys.exc_clear() try: 1/0 except ZeroDivisionError: exc = sys.exc_info()[0] print("third exc (before doclear):", exc) doclear2() exc = sys.exc_info()[0] print("third exc (after doclear):", exc) assert sys.exc_info()[0] is ZeroDivisionError The above passes. It seems that being inside a local exception block allows for the spec to hold, only the "local exception" is cleared. I still think this is a pretty major bug, but it is good to know what the workaround/reason it's "been working" is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 19:58:31 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 00:58:31 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513213111.25.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4743 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 20:19:20 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 Dec 2017 01:19:20 +0000 Subject: [issue30241] Add contextlib.AbstractAsyncContextManager In-Reply-To: <1493784741.35.0.949796244558.issue30241@psf.upfronthosting.co.za> Message-ID: <1513214360.69.0.213398074469.issue30241@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 176baa326be4ec2dc70ca0c054b7e2ab7ca6a9cf by Yury Selivanov (Jelle Zijlstra) in branch 'master': bpo-30241: implement contextlib.AbstractAsyncContextManager (#1412) https://github.com/python/cpython/commit/176baa326be4ec2dc70ca0c054b7e2ab7ca6a9cf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 20:20:16 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 Dec 2017 01:20:16 +0000 Subject: [issue30241] Add contextlib.AbstractAsyncContextManager In-Reply-To: <1493784741.35.0.949796244558.issue30241@psf.upfronthosting.co.za> Message-ID: <1513214416.41.0.213398074469.issue30241@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 20:20:54 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 01:20:54 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513214454.86.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset b5fd9ad05e0f15f8272b8f1b829af22077230584 by Victor Stinner in branch 'master': bpo-32030: Rewrite _PyMainInterpreterConfig (#4854) https://github.com/python/cpython/commit/b5fd9ad05e0f15f8272b8f1b829af22077230584 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 20:29:40 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 01:29:40 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513214980.6.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4744 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 21:50:44 2017 From: report at bugs.python.org (Dustin Spicuzza) Date: Thu, 14 Dec 2017 02:50:44 +0000 Subject: [issue29877] compileall hangs when accessing urandom even if number of workers is 1 In-Reply-To: <1490162236.47.0.103711647228.issue29877@psf.upfronthosting.co.za> Message-ID: <1513219844.45.0.213398074469.issue29877@psf.upfronthosting.co.za> Change by Dustin Spicuzza : ---------- keywords: +patch pull_requests: +4745 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 23:30:55 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 Dec 2017 04:30:55 +0000 Subject: [issue32318] Remove "globals()" call from "socket.accept()" Message-ID: <1513225855.23.0.213398074469.issue32318@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- nosy: yselivanov priority: normal severity: normal status: open title: Remove "globals()" call from "socket.accept()" _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 23:31:08 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Thu, 14 Dec 2017 04:31:08 +0000 Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za> Message-ID: <1513225868.04.0.213398074469.issue30491@psf.upfronthosting.co.za> Nathaniel Smith added the comment: > 1. How will trio handle situations like: > > c = coro() > await ... > nursery.start_soon(c) > > ? [...] > Maybe creating a coroutine and not immediately passing it to 'start_soon' or similar API is an anti-pattern in Trio, but it is an OK thing to do in asyncio/curio/twisted. Yeah, for sure. This is sort of core to the overall motivation, so probably a good idea to make sure we're on the same page. So first... that's not how nursery.start_soon works :-). It actually takes an async function, not a coroutine object. In fact, if you try doing 'nursery.start_soon(c)' in trio v0.2.0, you get this error message (code I ran: https://gist.github.com/njsmith/87687ba5de1aeb5aa92336bd31891751): > TypeError: trio was expecting an async function, but instead it got a coroutine object > > Probably you did something like: > > trio.run(coro(...)) # incorrect! > nursery.start_soon(coro(...)) # incorrect! > > Instead, you want (notice the parentheses!): > > trio.run(coro, ...) # correct! > nursery.start_soon(coro, ...) # correct! (The 'coro' in my paste above isn't a placeholder, it's the actual name of your example async function that trio has interpolated into the error message, because I am a dorky perfectionist.) There's a broader point here beyond showing off my dorkiness. Trio is very careful to make sure that users don't need to know about the existence of coroutine objects *at all*. This is a *huge* win for teaching and understanding: I just tell people "async functions are a special class of functions; they're defined like 'async def func(): ...', and called like 'await func()', and btw you can only use 'await func()' inside an async function." and that is literally everything you need to know about async/await to use trio. I never use the word coroutine. It's way simpler, with no loss in expressivity, and part of why I can teach all of trio in a 30 minute talk and people are like "okay cool I know how to write concurrent programs now, why do people make such a big deal about it?". Buuuuuuut... that's the happy path. What happens when people make minor syntax mistakes? Sometimes, we can catch it -- like the example above, when they accidentally write 'nursery.start_soon(func())' -- and give a nice helpful message to tell them what to fix, and it's fine. But unawaited coroutines are a problem: most people are going to forget an 'await' sooner or later. And when the happens, then you get messages like "coroutine was never awaited" or "coroutine object has no attribute '...'" which are completely incomprehensible if you don't know that there are such things as coroutine objects. (And never mind the cases where you don't get an error/warning at all!) So then my users are forced to learn a bunch of new concepts and async/await implementation details, *just* to understand this one error case. So basically yeah, I am totally happy to prohibit 'c = coro(); await sleep(0); await c' because it's actually the key thing that makes the whole system simpler. Of course the problem is how to do this in a way that works for both trio and asyncio :-). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 23:32:14 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 Dec 2017 04:32:14 +0000 Subject: [issue32318] Remove "globals()" call from "socket.accept()" Message-ID: <1513225934.71.0.213398074469.issue32318@psf.upfronthosting.co.za> New submission from Yury Selivanov : socket.accept currently has this code: type = self.type & ~globals().get("SOCK_NONBLOCK", 0) which I believe is (a) bad Python style; (b) slows things down. ---------- components: +Library (Lib) nosy: +asvetlov, vstinner type: -> enhancement versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 23:33:31 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 Dec 2017 04:33:31 +0000 Subject: [issue32318] Remove "globals()" call from "socket.accept()" In-Reply-To: <1513225934.71.0.213398074469.issue32318@psf.upfronthosting.co.za> Message-ID: <1513226011.22.0.213398074469.issue32318@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4746 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 23:39:38 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 Dec 2017 04:39:38 +0000 Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za> Message-ID: <1513226378.46.0.213398074469.issue30491@psf.upfronthosting.co.za> Yury Selivanov added the comment: > So first... that's not how nursery.start_soon works :-). It actually takes an async function, not a coroutine object. [..] Interesting, and I think I like it. I definitely understand the motivation to not tell users the difference between coroutine functions and coroutine objects, but yeah, the ship has sailed for asyncio/curio/twisted. Anyways, I'm not saying we shouldn't implement your proposal, even if it is only going to be used by Trio. I'm saying that we need to consider all alternatives, and for that, I'd like to see what happens if we implement a tiny&fast coro wrapper in Trio. Maybe the runtime overhead of it will be negligible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 13 23:41:13 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Thu, 14 Dec 2017 04:41:13 +0000 Subject: [issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects In-Reply-To: <1495867380.86.0.533205071954.issue30491@psf.upfronthosting.co.za> Message-ID: <1513226473.64.0.213398074469.issue30491@psf.upfronthosting.co.za> Nathaniel Smith added the comment: > In any case, in my opinion, it doesn't matter. `sys.set_coroutine_wrapper` controls a single thread-local setting, `sys.set_unawaited_coroutine_tracking` *also* controls a single thread-local setting. Both of them have the exact same problem when there's more than one user of the API. So we can't consider this as a strong argument in favour of the 'set_unawaited_coroutine_tracking' API. [...] > With that all in mind, my question is: have you guys tried to write a wrapper object in C for coroutines (or you can use Cython to get an idea)? This is a fair point; we probably should try that :-). I do think that there's more of a difference than you're realizing between set_coroutine_wrapper and set_unawaited_coroutine_tracking WRT their behavior around conflicts. For set_unawaited_coroutine_tracking, the whole idea that makes it useful is if you have a single central piece of code that has a global view of what your program is doing, and can use that to figure out specific points where there should be no unawaited coroutines, plus has some strategy for reporting errors. For pytest-asyncio, it wants to check for these at the end of each test and then if found, fail that test. (Oh, I should mention that I did actually talk to the pytest-asyncio author about this and they do want to use it, this isn't hypothetical :-).) For trio, we have a more subtle rule like "check at each schedule point or catch-all exception handler, UNLESS it is in a task that is hosting asyncio code through our translation layer", and the reporting is more complicated too. But the point I want to make is that here, it's simpliy intrinsic in the design that whatever system is doing this has to have some pretty solid global knowledge, and it doesn't make sense to have two of these at once; no matter how we implemented this, two libraries trying to use it at the same time would necessarily need to coordinate somehow. OTOH, for set_coroutine_wrapper, it's such a catch-all that it is plausible to have two different libraries that both want to use it at the same time, for two things that in principle don't conflict at all. And not only is this plausible, it's what actually happens :-). If everyone uses set_coroutine_wrapper, then pytest-asyncio and asyncio will actually collide, and trio and asyncio will actually collide. But if we have set_unawaited_coroutine_tracking + set_coroutine_wrapper, then that's enough to prevent all the actual collisions we know about. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 00:46:18 2017 From: report at bugs.python.org (Nitish) Date: Thu, 14 Dec 2017 05:46:18 +0000 Subject: [issue32228] truncate() changes current stream position In-Reply-To: <1512515954.76.0.213398074469.issue32228@psf.upfronthosting.co.za> Message-ID: <1513230378.57.0.213398074469.issue32228@psf.upfronthosting.co.za> Change by Nitish : ---------- keywords: +patch pull_requests: +4747 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 01:43:07 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 06:43:07 +0000 Subject: [issue32318] Remove "globals()" call from "socket.accept()" In-Reply-To: <1513226011.28.0.912454111764.issue32318@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: IMHO we should add a private mask constant, see: https://github.com/python/cpython/pull/4231#issuecomment-351622381 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 02:47:22 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 14 Dec 2017 07:47:22 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1513237642.33.0.213398074469.issue29469@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset 7ea143ae795a9fd57eaccf490d316bdc13ee9065 by INADA Naoki in branch 'master': bpo-29469: Move constant folding to AST optimizer (GH-2858) https://github.com/python/cpython/commit/7ea143ae795a9fd57eaccf490d316bdc13ee9065 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 02:49:27 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 14 Dec 2017 07:49:27 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1513237767.74.0.213398074469.issue29469@psf.upfronthosting.co.za> Change by INADA Naoki : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 02:56:47 2017 From: report at bugs.python.org (Daniel Hrisca) Date: Thu, 14 Dec 2017 07:56:47 +0000 Subject: [issue32319] re fullmatch error with non greedy modifier Message-ID: <1513238207.94.0.213398074469.issue32319@psf.upfronthosting.co.za> New submission from Daniel Hrisca : Consider this code snippet: from re import match, fullmatch pattern = '".+?"' string = '"hello" "again"' print(match(pattern, string)) print(fullmatch(pattern, string)) Which prints: <_sre.SRE_Match object; span=(0, 7), match='"hello"'> <_sre.SRE_Match object; span=(0, 15), match='"hello" "again"'> The fullmatch function seems to ignore the non-greedy modifier. >From the fullmatch docstring I expected that fullmatch is equivalent to: def fullmatch(pattern, string): match = re.match(pattern, string) if match: if match.start() == 0 and match.end() == len(string): return match else: return None else: return None ---------- components: Library (Lib) messages: 308278 nosy: danielhrisca priority: normal severity: normal status: open title: re fullmatch error with non greedy modifier type: behavior versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 03:10:33 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 08:10:33 +0000 Subject: [issue32319] re fullmatch error with non greedy modifier In-Reply-To: <1513238207.94.0.213398074469.issue32319@psf.upfronthosting.co.za> Message-ID: <1513239033.54.0.213398074469.issue32319@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No, this is not how fullmatch() works. Otherwise there wouldn't be need to add it into the stdlib. You could just check end() of the result. fullmatch() acts like match() with added \Z. But if the pattern contains multiple alternates you need to add \Z at the end of every branch (r"foo\Z|bar\Z") or wrap the entire patch in a non-capturing group (r"(?:foo|bar)\Z"). ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 03:18:10 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 08:18:10 +0000 Subject: [issue28813] Remove unneeded folded consts after peephole In-Reply-To: <1480244746.98.0.558504847162.issue28813@psf.upfronthosting.co.za> Message-ID: <1513239490.33.0.213398074469.issue28813@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Moving constant folding to the AST level (issue29469) have made this patch outdated. In any case thank you for your patch Adrian. ---------- resolution: -> out of date stage: patch review -> resolved status: open -> closed superseder: -> AST-level Constant folding _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 03:27:59 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 08:27:59 +0000 Subject: [issue26549] co_stacksize is calculated from unoptimized code In-Reply-To: <1457822745.22.0.972836245522.issue26549@psf.upfronthosting.co.za> Message-ID: <1513240079.49.0.213398074469.issue26549@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Seems moving constant folding to the AST level (issue29469) have solved this issue. >>> def foo(): ... a = (1,2,3,4,5,6,7,8,9,10) ... >>> foo.__code__.co_stacksize 1 ---------- resolution: -> out of date stage: -> resolved status: open -> closed superseder: -> AST-level Constant folding _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 03:44:35 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 14 Dec 2017 08:44:35 +0000 Subject: [issue32320] Add default value support to collections.namedtuple() Message-ID: <1513241075.07.0.213398074469.issue32320@psf.upfronthosting.co.za> New submission from Raymond Hettinger : Add default argument support and _fields_defaults attribute modeled after typing.NamedTuple. ---------- components: Library (Lib) messages: 308282 nosy: rhettinger priority: normal severity: normal stage: patch review status: open title: Add default value support to collections.namedtuple() versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 03:47:31 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 14 Dec 2017 08:47:31 +0000 Subject: [issue32320] Add default value support to collections.namedtuple() In-Reply-To: <1513241075.07.0.213398074469.issue32320@psf.upfronthosting.co.za> Message-ID: <1513241251.3.0.213398074469.issue32320@psf.upfronthosting.co.za> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +4748 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 04:21:16 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 14 Dec 2017 09:21:16 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1513243276.72.0.213398074469.issue29469@psf.upfronthosting.co.za> Raymond Hettinger added the comment: ISTM, the constant-tracking macros for peephole.c can also be removed, essentially reverting back to the simpler cumlc-style code in Py2.5. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 05:17:01 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 10:17:01 +0000 Subject: [issue30416] constant folding opens compiler to quadratic time hashing In-Reply-To: <1495314097.2.0.680001526088.issue30416@psf.upfronthosting.co.za> Message-ID: <1513246621.17.0.213398074469.issue30416@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4749 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 05:17:01 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 10:17:01 +0000 Subject: [issue21074] Too aggressive constant folding In-Reply-To: <1395887196.57.0.903293210902.issue21074@psf.upfronthosting.co.za> Message-ID: <1513246621.29.0.00913614298617.issue21074@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +4750 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 05:39:37 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 10:39:37 +0000 Subject: [issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor In-Reply-To: <1513179338.41.0.213398074469.issue32302@psf.upfronthosting.co.za> Message-ID: <1513247977.04.0.213398074469.issue32302@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 9e7c136ad8bc8e8eec50c2a8ae5ff02752f695a2 by Victor Stinner in branch 'master': bpo-32302: Fix distutils bdist_wininst for CRT v142 (#4851) https://github.com/python/cpython/commit/9e7c136ad8bc8e8eec50c2a8ae5ff02752f695a2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 05:40:00 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 Dec 2017 10:40:00 +0000 Subject: [issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor In-Reply-To: <1513179338.41.0.213398074469.issue32302@psf.upfronthosting.co.za> Message-ID: <1513248000.53.0.213398074469.issue32302@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4751 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 05:59:47 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 14 Dec 2017 10:59:47 +0000 Subject: [issue32225] Implement PEP 562: module __getattr__ and __dir__ In-Reply-To: <1512866356.6.0.213398074469.issue32225@psf.upfronthosting.co.za> Message-ID: <1513249187.27.0.213398074469.issue32225@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: New changeset 5364b5cd7571f2dfa75acd37b388c14ac33fef73 by Ivan Levkivskyi in branch 'master': bpo-32225: Implementation of PEP 562 (#4731) https://github.com/python/cpython/commit/5364b5cd7571f2dfa75acd37b388c14ac33fef73 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 06:00:53 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 11:00:53 +0000 Subject: [issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor In-Reply-To: <1513179338.41.0.213398074469.issue32302@psf.upfronthosting.co.za> Message-ID: <1513249253.0.0.213398074469.issue32302@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 645fa19f15cddeec8d882a9e1420173e7516f0e4 by Victor Stinner (Miss Islington (bot)) in branch '3.6': bpo-32302: Fix distutils bdist_wininst for CRT v142 (GH-4851) (#4861) https://github.com/python/cpython/commit/645fa19f15cddeec8d882a9e1420173e7516f0e4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 06:04:55 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 14 Dec 2017 11:04:55 +0000 Subject: [issue32297] Few misspellings found in Python source code comments. In-Reply-To: <1513123806.73.0.213398074469.issue32297@psf.upfronthosting.co.za> Message-ID: <1513249495.41.0.213398074469.issue32297@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset 53f7a7c2814fbfd8a29200926601a32fa48bacb3 by Andrew Svetlov (Mike) in branch 'master': bpo-32297: Few misspellings found in Python source code comments. (#4803) https://github.com/python/cpython/commit/53f7a7c2814fbfd8a29200926601a32fa48bacb3 ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 06:05:28 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 11:05:28 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513249528.78.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 374c6e178a7599aae46c857b17c6c8bc19dfe4c2 by Victor Stinner in branch 'master': bpo-32030: Add _PyMainInterpreterConfig.warnoptions (#4855) https://github.com/python/cpython/commit/374c6e178a7599aae46c857b17c6c8bc19dfe4c2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 06:06:42 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 11:06:42 +0000 Subject: [issue32302] test_distutils: test_get_exe_bytes() failure on AppVeyor In-Reply-To: <1513179338.41.0.213398074469.issue32302@psf.upfronthosting.co.za> Message-ID: <1513249602.67.0.213398074469.issue32302@psf.upfronthosting.co.za> STINNER Victor added the comment: It seems like AppVeyor is fixed, thanks Steve for the help! Later, it would be nice to write a more generic fix than hardcoding two minor versions. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 06:09:01 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 14 Dec 2017 11:09:01 +0000 Subject: [issue32297] Few misspellings found in Python source code comments. In-Reply-To: <1513123806.73.0.213398074469.issue32297@psf.upfronthosting.co.za> Message-ID: <1513249741.75.0.213398074469.issue32297@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 06:15:00 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 14 Dec 2017 11:15:00 +0000 Subject: [issue32297] Few misspellings found in Python source code comments. In-Reply-To: <1513123806.73.0.213398074469.issue32297@psf.upfronthosting.co.za> Message-ID: <1513250100.5.0.213398074469.issue32297@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- pull_requests: +4752 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 06:17:05 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 14 Dec 2017 11:17:05 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1513250225.1.0.213398074469.issue29469@psf.upfronthosting.co.za> Change by INADA Naoki : ---------- pull_requests: +4753 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 06:19:15 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 14 Dec 2017 11:19:15 +0000 Subject: [issue32225] Implement PEP 562: module __getattr__ and __dir__ In-Reply-To: <1512866356.6.0.213398074469.issue32225@psf.upfronthosting.co.za> Message-ID: <1513250355.64.0.213398074469.issue32225@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Travis build on master successful, so I am closing this issue. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 06:25:50 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 14 Dec 2017 11:25:50 +0000 Subject: [issue32297] Few misspellings found in Python source code comments. In-Reply-To: <1513123806.73.0.213398074469.issue32297@psf.upfronthosting.co.za> Message-ID: <1513250750.92.0.213398074469.issue32297@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- pull_requests: +4754 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 07:22:24 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 12:22:24 +0000 Subject: [issue32226] Implement PEP 560: Core support for typing module and generic types In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za> Message-ID: <1513254144.95.0.213398074469.issue32226@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This adds an overhead to every indexing. $ ./python -m perf timeit --compare-to=./python0 -s 'a = [1]' --duplicate=10000 'a[0]' python0: ..................... 15.3 ns +- 0.5 ns python: ..................... 16.1 ns +- 0.3 ns Mean +- std dev: [python0] 15.3 ns +- 0.5 ns -> [python] 16.1 ns +- 0.3 ns: 1.05x slower (+5%) $ ./python -m perf timeit --compare-to=./python0 -s 'd = {1: 2}' --duplicate=10000 'd[1]' python0: ..................... 17.6 ns +- 0.6 ns python: ..................... 18.4 ns +- 0.5 ns Mean +- std dev: [python0] 17.6 ns +- 0.6 ns -> [python] 18.4 ns +- 0.5 ns: 1.05x slower (+5%) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 07:23:17 2017 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Thu, 14 Dec 2017 12:23:17 +0000 Subject: [issue32143] os.statvfs lacks f_fsid In-Reply-To: <1511713053.6.0.213398074469.issue32143@psf.upfronthosting.co.za> Message-ID: <1513254197.05.0.213398074469.issue32143@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: I think Giuseppe's patch is good, but there's a Windows failure on AppVeyor, so I'm a little wary. It doesn't look related, but I haven't looked at Python on Windows since... 2001, maybe? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 07:52:39 2017 From: report at bugs.python.org (Natanael Copa) Date: Thu, 14 Dec 2017 12:52:39 +0000 Subject: [issue32307] Bad assumption on thread stack size makes python crash with musl libc In-Reply-To: <1513187194.31.0.213398074469.issue32307@psf.upfronthosting.co.za> Message-ID: <1513255959.51.0.213398074469.issue32307@psf.upfronthosting.co.za> Natanael Copa added the comment: With "bad assumption" I mean that currently the code assumes that all unknown systems has big enough default thread stack size. This would not be a "bad assumption" if POSIX (or any other standard) would specify a requirement on the default stack size. To my understanding, there are no such requirement in the spec, and thus, applications can not really assume anything about the default thread stack size. musl libc does not provide any __MUSL__ macro by design, because they consider "it?s a bug to assume a certain implementation has particular properties rather than testing" so we cannot really make exception for musl. https://wiki.musl-libc.org/faq.html#Q:_Why_is_there_no___MUSL___macro? I think the options we have are: - at run time, use pthread_attr_getstacksize() to verify we have enough stack size. I don't know how to calculate the proper minimum, but some testing showed that we need 450k on musl x86_64 to reach sys.getrecursionlimit() so I'd say 1MB is a good limit - atleast for x86_64. - at build time, run pthread_attr_getstacksize() from configure script to detect default stack size. This will not work for cross compile. - reverse the current #ifdef behavior so that we check for known systems that has big enough system default (eg __GLIBC__ etc) and then fall back to something safe for everything else. - Do nothing. Systems with low stack needs to figure out to add -DTHREAD_STACK_SIZE=0x100000 to the CFLAGS (this is what Alpine does right now) I can of course make a check for musl in the configure script and special case it, but it still does not fix the issue: There is no guarantee that stack size is big enough for python's use for every existing and unknown future system. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 08:09:50 2017 From: report at bugs.python.org (Natanael Copa) Date: Thu, 14 Dec 2017 13:09:50 +0000 Subject: [issue32307] Bad assumption on thread stack size makes python crash with musl libc In-Reply-To: <1513187194.31.0.213398074469.issue32307@psf.upfronthosting.co.za> Message-ID: <1513256990.86.0.213398074469.issue32307@psf.upfronthosting.co.za> Natanael Copa added the comment: I ran a test of pthread_attr_getstacksize() on various systems. Here is what they return: Linux/glibc: 8388608 MacOS: 524288 FreeBSD 11.1: 0 (ulimit -s gives 524288) NetBSD 7.1: 4194304 OpenBSD 6.2: 524288 I could not see any #ifdef for __OpenBSD__ so I would expect to see segfaults on OpenBSD as well. Google gave me this: https://bugs.python.org/issue25342 https://github.com/alonho/pytrace/issues/8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 08:12:04 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 13:12:04 +0000 Subject: [issue1346238] A constant folding optimization pass for the AST Message-ID: <1513257124.91.0.213398074469.issue1346238@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Have been implemented in issue29469. ---------- nosy: +serhiy.storchaka resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> AST-level Constant folding _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 08:16:06 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 13:16:06 +0000 Subject: [issue27695] Long constant calculations stall compilation In-Reply-To: <1470418776.19.0.267562911935.issue27695@psf.upfronthosting.co.za> Message-ID: <1513257366.61.0.213398074469.issue27695@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Too aggressive constant folding _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 08:18:28 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 14 Dec 2017 13:18:28 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1513257508.51.0.213398074469.issue29469@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset eadad1b97f64619bfd246b9d3b60d25f456e0592 by INADA Naoki in branch 'master': bpo-29469: Remove unnecessary peephole optimizer (GH-4863) https://github.com/python/cpython/commit/eadad1b97f64619bfd246b9d3b60d25f456e0592 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 08:26:34 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 14 Dec 2017 13:26:34 +0000 Subject: [issue32321] functools.reduce has a redundant guard or needs a pure Python fallback Message-ID: <1513257994.59.0.213398074469.issue32321@psf.upfronthosting.co.za> New submission from Steven D'Aprano : The functools module imports reduce from _functools, using a guard in case it is not present: try: from _functools import reduce except ImportError: pass However, the documentation says nothing about reduce being optional, and it is unconditionally included in the module __all__. If reduce is guaranteed to be implemented in _functools, then the guard is redundant and should be removed. Otherwise, a pure python fallback should be added. (The docs for reduce include a pure Python equivalent which might be sufficient.) ---------- components: Library (Lib) keywords: easy messages: 308297 nosy: steven.daprano priority: normal severity: normal status: open title: functools.reduce has a redundant guard or needs a pure Python fallback versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 08:30:36 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 13:30:36 +0000 Subject: [issue26549] co_stacksize is calculated from unoptimized code In-Reply-To: <1457822745.22.0.972836245522.issue26549@psf.upfronthosting.co.za> Message-ID: <1513258236.64.0.213398074469.issue26549@psf.upfronthosting.co.za> STINNER Victor added the comment: > Seems moving constant folding to the AST level (issue29469) have solved this issue. Wow, it's cool to see this bug finally fixed! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 08:49:28 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 13:49:28 +0000 Subject: [issue30416] constant folding opens compiler to quadratic time hashing In-Reply-To: <1495314097.2.0.680001526088.issue30416@psf.upfronthosting.co.za> Message-ID: <1513259368.59.0.213398074469.issue30416@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4755 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 08:49:28 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 13:49:28 +0000 Subject: [issue21074] Too aggressive constant folding In-Reply-To: <1395887196.57.0.903293210902.issue21074@psf.upfronthosting.co.za> Message-ID: <1513259368.68.0.00913614298617.issue21074@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4756 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 09:19:55 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 14 Dec 2017 14:19:55 +0000 Subject: [issue32297] Few misspellings found in Python source code comments. In-Reply-To: <1513123806.73.0.213398074469.issue32297@psf.upfronthosting.co.za> Message-ID: <1513261195.6.0.213398074469.issue32297@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset 28453feaa8d88bbcbf6d834b1d5ca396d17265f2 by Andrew Svetlov in branch '3.6': [3.6] bpo-32297: Fix misspellings in Python source code comments (GH-4803) (#4864) https://github.com/python/cpython/commit/28453feaa8d88bbcbf6d834b1d5ca396d17265f2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 09:35:31 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 14:35:31 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1513262131.71.0.213398074469.issue29469@psf.upfronthosting.co.za> STINNER Victor added the comment: Thank you very much Naoki for taking time to implement this obvious "optimization", rewriting the peephole optimizer at the AST level, rather than modifying bytecode which is more complex to get it right and had annoying side effect (like inefficient stack size, now fixed: bpo-26549). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 09:42:24 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 Dec 2017 14:42:24 +0000 Subject: [issue32314] Implement asyncio.run() In-Reply-To: <1513201628.59.0.213398074469.issue32314@psf.upfronthosting.co.za> Message-ID: <1513262544.12.0.213398074469.issue32314@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 02a0a19206da6902c3855a1fa09e60b208474cfa by Yury Selivanov in branch 'master': bpo-32314: Implement asyncio.run() (#4852) https://github.com/python/cpython/commit/02a0a19206da6902c3855a1fa09e60b208474cfa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 09:43:04 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 Dec 2017 14:43:04 +0000 Subject: [issue32314] Implement asyncio.run() In-Reply-To: <1513201628.59.0.213398074469.issue32314@psf.upfronthosting.co.za> Message-ID: <1513262584.92.0.213398074469.issue32314@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 09:44:08 2017 From: report at bugs.python.org (Rostislav Kondratenko) Date: Thu, 14 Dec 2017 14:44:08 +0000 Subject: [issue32322] Heap type with Py_TPFLAGS_HAVE_GC leads to segfault due to not incrementing type object refcout in PyObject_GC_New Message-ID: <1513262648.0.0.213398074469.issue32322@psf.upfronthosting.co.za> New submission from Rostislav Kondratenko : If one creates a type with both Py_TPFLAGS_HAVE_GC and Py_TPFLAGS_HEAPTYPE set and implemented, one has to create instances with PyObject_GC_New() per current docs: https://docs.python.org/3.7/c-api/gcsupport.html . However, PyObject_GC_New() unlike PyType_GenericAlloc() does not increment refcount of a type object. As the refcount is still decremented when instances are destroyed, it leads to steady drain on type object's refcount. Eventually it reaches zero and the type object gets deleted while there are still instances and references to it. And it usually results in crash after a number of instances (20-50 is usually enough) is created and destroyed. One should either update the docs to point that call to PyType_GenericAlloc() would be sufficient (as it would use _PyObject_GC_Malloc() and increment refcount when appropriate) or update _PyObject_GC_New() code to increment type object's refcount when the type is heap type. Or both. ---------- assignee: docs at python components: Documentation, Interpreter Core messages: 308302 nosy: docs at python, rkond priority: normal severity: normal status: open title: Heap type with Py_TPFLAGS_HAVE_GC leads to segfault due to not incrementing type object refcout in PyObject_GC_New type: crash versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 09:45:16 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 14:45:16 +0000 Subject: [issue32314] Implement asyncio.run() In-Reply-To: <1513201628.59.0.213398074469.issue32314@psf.upfronthosting.co.za> Message-ID: <1513262716.34.0.213398074469.issue32314@psf.upfronthosting.co.za> STINNER Victor added the comment: Wow, I really love your new function. Thanks Yury! asyncio examples in the doc look much better now! ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 09:54:48 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 14:54:48 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1513263288.62.0.213398074469.issue29469@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4757 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 09:55:15 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 14:55:15 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1513263315.15.0.213398074469.issue29469@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 10:10:55 2017 From: report at bugs.python.org (Natanael Copa) Date: Thu, 14 Dec 2017 15:10:55 +0000 Subject: [issue32307] Bad assumption on thread stack size makes python crash with musl libc In-Reply-To: <1513187194.31.0.213398074469.issue32307@psf.upfronthosting.co.za> Message-ID: <1513264255.56.0.213398074469.issue32307@psf.upfronthosting.co.za> Natanael Copa added the comment: I suggest a runtime check like this: diff --git a/Python/thread_pthread.h b/Python/thread_pthread.h index b7463c0ca6..e9d0f638c9 100644 --- a/Python/thread_pthread.h +++ b/Python/thread_pthread.h @@ -34,6 +34,8 @@ #undef THREAD_STACK_SIZE #define THREAD_STACK_SIZE 0x400000 #endif +/* minimum size of the default thread stack size */ +#define THREAD_STACK_MIN_DEFAULT 0x100000 /* for safety, ensure a viable minimum stacksize */ #define THREAD_STACK_MIN 0x8000 /* 32 KiB */ #else /* !_POSIX_THREAD_ATTR_STACKSIZE */ @@ -187,6 +189,14 @@ PyThread_start_new_thread(void (*func)(void *), void *arg) PyThreadState *tstate = PyThreadState_GET(); size_t stacksize = tstate ? tstate->interp->pythread_stacksize : 0; tss = (stacksize != 0) ? stacksize : THREAD_STACK_SIZE; + if (tss == 0 && THREAD_STACK_SIZE == 0) { + if (pthread_attr_getstacksize(&attrs, &tss) != 0) { + pthread_attr_destroy(&attrs); + return PYTHREAD_INVALID_THREAD_ID; + } + if (tss != 0 && tss < THREAD_STACK_MIN_DEFAULT) + tss = THREAD_STACK_MIN_DEFAULT; + } if (tss != 0) { if (pthread_attr_setstacksize(&attrs, tss) != 0) { pthread_attr_destroy(&attrs); The reasoning here is: - if THREAD_STACK_SIZE is set to non-zero, then use that. This is so that you can at compile time set the default stack size to your liking. This is currently set for __APPLE__ and __FreeBSD__ and you can set it via CFLAGS, so this does not change anything for those. - if THREAD_STACK_SIZE is set to 0, then see if pthread_attr_getstacksize returns anything and if it does, make sure that we have at least 1MB stack size as default. Scripts that uses threading.stack_size() will still work as before, and you can still manually set the stack size down to 32k (THREAD_STACK_MIN) if you need that. This should keep existing behavior for known systems like glibc, OSX, FreeBSD, NetBSD but will raise the thread stack size for musl libc and OpenBSD to 1MB. What do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 10:19:03 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Dec 2017 15:19:03 +0000 Subject: [issue32307] Bad assumption on thread stack size makes python crash with musl libc In-Reply-To: <1513187194.31.0.213398074469.issue32307@psf.upfronthosting.co.za> Message-ID: <1513264743.63.0.213398074469.issue32307@psf.upfronthosting.co.za> R. David Murray added the comment: I think we need people who do a lot of work at the C level to evaluate this, so I've added a couple to the nosy list :) ---------- nosy: +serhiy.storchaka, vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 10:30:39 2017 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 14 Dec 2017 15:30:39 +0000 Subject: [issue32323] urllib.parse.urlsplit() must not lowercase() IPv6 scope value Message-ID: <1513265439.83.0.213398074469.issue32323@psf.upfronthosting.co.za> New submission from ???? ????????? : qwe = urlsplit('http://[FE80::822a:a8ff:fe49:470c%????]:1234/keys') qwe.hostname will be 'fe80::822a:a8ff:fe49:470c%????' Which is wrong. correct value is 'fe80::822a:a8ff:fe49:470c%????' so, IP-address is lowercased and zone id does not. ---------- components: Library (Lib) messages: 308306 nosy: socketpair priority: normal severity: normal status: open title: urllib.parse.urlsplit() must not lowercase() IPv6 scope value type: behavior versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 10:31:35 2017 From: report at bugs.python.org (Natanael Copa) Date: Thu, 14 Dec 2017 15:31:35 +0000 Subject: [issue32307] Bad assumption on thread stack size makes python crash with musl libc In-Reply-To: <1513187194.31.0.213398074469.issue32307@psf.upfronthosting.co.za> Message-ID: <1513265495.4.0.213398074469.issue32307@psf.upfronthosting.co.za> Natanael Copa added the comment: Exactly same as previous patch, but refactored to only have a single pthread_attr_destroy() call instead of 3. diff --git a/Python/thread_pthread.h b/Python/thread_pthread.h index b7463c0ca6..1006a168fa 100644 --- a/Python/thread_pthread.h +++ b/Python/thread_pthread.h @@ -34,6 +34,8 @@ #undef THREAD_STACK_SIZE #define THREAD_STACK_SIZE 0x400000 #endif +/* minimum size of the default thread stack size */ +#define THREAD_STACK_MIN_DEFAULT 0x100000 /* for safety, ensure a viable minimum stacksize */ #define THREAD_STACK_MIN 0x8000 /* 32 KiB */ #else /* !_POSIX_THREAD_ATTR_STACKSIZE */ @@ -167,7 +169,7 @@ unsigned long PyThread_start_new_thread(void (*func)(void *), void *arg) { pthread_t th; - int status; + int status = -1; #if defined(THREAD_STACK_SIZE) || defined(PTHREAD_SYSTEM_SCHED_SUPPORTED) pthread_attr_t attrs; #endif @@ -187,11 +189,15 @@ PyThread_start_new_thread(void (*func)(void *), void *arg) PyThreadState *tstate = PyThreadState_GET(); size_t stacksize = tstate ? tstate->interp->pythread_stacksize : 0; tss = (stacksize != 0) ? stacksize : THREAD_STACK_SIZE; + if (tss == 0 && THREAD_STACK_SIZE == 0) { + if (pthread_attr_getstacksize(&attrs, &tss) != 0) + goto thread_abort; + if (tss != 0 && tss < THREAD_STACK_MIN_DEFAULT) + tss = THREAD_STACK_MIN_DEFAULT; + } if (tss != 0) { - if (pthread_attr_setstacksize(&attrs, tss) != 0) { - pthread_attr_destroy(&attrs); - return PYTHREAD_INVALID_THREAD_ID; - } + if (pthread_attr_setstacksize(&attrs, tss) != 0) + goto thread_abort; } #endif #if defined(PTHREAD_SYSTEM_SCHED_SUPPORTED) @@ -209,6 +215,7 @@ PyThread_start_new_thread(void (*func)(void *), void *arg) ); #if defined(THREAD_STACK_SIZE) || defined(PTHREAD_SYSTEM_SCHED_SUPPORTED) +thread_abort: pthread_attr_destroy(&attrs); #endif if (status != 0) ---------- nosy: -serhiy.storchaka, vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 10:32:57 2017 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 14 Dec 2017 15:32:57 +0000 Subject: [issue32323] urllib.parse.urlsplit() must not lowercase() IPv6 scope value In-Reply-To: <1513265439.83.0.213398074469.issue32323@psf.upfronthosting.co.za> Message-ID: <1513265577.91.0.213398074469.issue32323@psf.upfronthosting.co.za> Change by ???? ????????? : ---------- keywords: +patch pull_requests: +4758 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 10:35:15 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 Dec 2017 15:35:15 +0000 Subject: [issue32314] Implement asyncio.run() In-Reply-To: <1513201628.59.0.213398074469.issue32314@psf.upfronthosting.co.za> Message-ID: <1513265715.37.0.213398074469.issue32314@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Wow, I really love your new function. Thanks Yury! asyncio examples in the doc look much better now! This year I'll stay for the sprints at PyCon, and will focus on improving the docs further. I needed asyncio.run for that :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 11:01:12 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 16:01:12 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513267272.18.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4760 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 11:05:28 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Thu, 14 Dec 2017 16:05:28 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513267528.28.0.213398074469.issue32300@psf.upfronthosting.co.za> Cheryl Sabella added the comment: Victor, Thanks! Yes, I can work this. It may take a few days for me to get to it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 11:09:15 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 16:09:15 +0000 Subject: [issue32324] [Security] "python3 directory" inserts "directory" at sys.path[0] even in isolated mode Message-ID: <1513267755.86.0.213398074469.issue32324@psf.upfronthosting.co.za> New submission from STINNER Victor : Christian Heimes, author of the -I option (isolated mode), asked me to open an issue to check if the following behaviour is correct (safe in term of security). "python3 directory" inserts "directory" at sys.path[0], even in isolated mode. Example: --- vstinner at apu$ mkdir directory vstinner at apu$ echo "import pprint, sys; pprint.pprint(sys.path)" > directory/__main__.py vstinner at apu$ python3 directory ['directory', '/usr/lib64/python3.6', ...] # Same behaviour with -I vstinner at apu$ python3 -I directory ['directory', '/usr/lib64/python3.6', ...] --- Same behaviour for a ZIP file: --- vstinner at apu$ cd directory/ vstinner at apu$ zip ../testzip.zp __main__.py adding: __main__.py (deflated 20%) vstinner at apu$ cd .. vstinner at apu$ python3 testzip.zip python3: can't open file 'testzip.zip': [Errno 2] No such file or directory vstinner at apu$ mv testzip.zp testzip.zip 'testzip.zp' -> 'testzip.zip' vstinner at apu$ python3 testzip.zip ['testzip.zip', '/usr/lib64/python3.6', ...] # Same behaviour with -I vstinner at apu$ python3 -I testzip.zip ['testzip.zip', '/usr/lib64/python3.6', ...] --- The -I option: https://docs.python.org/dev/using/cmdline.html#id2 ---------- messages: 308310 nosy: steve.dower, vstinner priority: normal severity: normal status: open title: [Security] "python3 directory" inserts "directory" at sys.path[0] even in isolated mode type: security versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 11:13:38 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 16:13:38 +0000 Subject: [issue32324] [Security] "python3 directory" inserts "directory" at sys.path[0] even in isolated mode In-Reply-To: <1513267755.86.0.213398074469.issue32324@psf.upfronthosting.co.za> Message-ID: <1513268018.48.0.213398074469.issue32324@psf.upfronthosting.co.za> STINNER Victor added the comment: "python3 directory" and "python3 testzip.zip" are implemented by calling runpy._run_module_as_main("__main__", set_argv0). Currently, sys.path is modified before calling _run_module_as_main(). Would it be possible to pass an additional path to importlib to import __main__, without modifying sys.path? ---------- nosy: +brett.cannon, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 11:23:21 2017 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 14 Dec 2017 16:23:21 +0000 Subject: [issue32226] Implement PEP 560: Core support for typing module and generic types In-Reply-To: <1513254144.95.0.213398074469.issue32226@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > This adds an overhead to every indexing. I'm not doubting your results, but I'm curious how that happened. The extra code in PyObject_GetItem is right before the point where it would otherwise raise TypeError -- I presume you benchmark never reached that point. Could it be that the compiler ends up rearranging the code in a way that is less optimal for the instruction cache? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 11:23:30 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 16:23:30 +0000 Subject: [issue32324] [Security] "python3 directory" inserts "directory" at sys.path[0] even in isolated mode In-Reply-To: <1513267755.86.0.213398074469.issue32324@psf.upfronthosting.co.za> Message-ID: <1513268610.24.0.213398074469.issue32324@psf.upfronthosting.co.za> STINNER Victor added the comment: See also https://github.com/python/cpython/pull/4868 : I propose a change to factorize the code, but the side effect is that sys.path is now modified before "import readline" (when using the -i option, like "python3 -i directory"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 11:28:40 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 16:28:40 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513268920.77.0.213398074469.issue32300@psf.upfronthosting.co.za> STINNER Victor added the comment: Currently, repr(Shelf.keys()) doesn't dump the content of the shelf: >>> import pickle, shelve >>> s=shelve.Shelf({b'key': pickle.dumps('value')}) >>> k=s.keys() >>> k KeysView() >>> list(k) ['key'] >>> list(s.values()) ['value'] I understand that changing KeysView.__repr__() changes repr(Shelf.keys()) behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 11:29:16 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 16:29:16 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513268956.97.0.213398074469.issue32300@psf.upfronthosting.co.za> STINNER Victor added the comment: Cheryl: "Thanks! Yes, I can work this. It may take a few days for me to get to it." It seems like we have a disagreement on how to fix this issue. We should first agree on the best solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 11:32:21 2017 From: report at bugs.python.org (Stephen Kelly) Date: Thu, 14 Dec 2017 16:32:21 +0000 Subject: [issue32325] C API should use 'const char *' instead of 'char *' Message-ID: <1513269141.75.0.213398074469.issue32325@psf.upfronthosting.co.za> New submission from Stephen Kelly : When using C++ to extend python, one may use PyGetSetDef for example: static PyGetSetDef Noddy_getseters[] = { {"first", (getter)Noddy_getfirst, (setter)Noddy_setfirst, "first name", NULL}, {"last", (getter)Noddy_getlast, (setter)Noddy_setlast, "last name", NULL}, {NULL} /* Sentinel */ }; However, in C++ implicit conversion from const char* to char* is deprecated since C++98, and is a removed conversion in C++11. https://godbolt.org/g/sswUKM GCC/Clang warn about this, and MSVC in conformance mode (/permissive-) errors on it. PyGetSetDef and similar APIs should use const char* instead of char* for members such as `name`. ---------- components: Library (Lib) messages: 308316 nosy: steveire priority: normal severity: normal status: open title: C API should use 'const char *' instead of 'char *' type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 11:37:49 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 16:37:49 +0000 Subject: [issue32325] C API should use 'const char *' instead of 'char *' In-Reply-To: <1513269141.75.0.213398074469.issue32325@psf.upfronthosting.co.za> Message-ID: <1513269469.34.0.213398074469.issue32325@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 11:42:03 2017 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 14 Dec 2017 16:42:03 +0000 Subject: [issue32221] Converting ipv6 address to string representation using getnameinfo() is wrong. In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za> Message-ID: <1513269723.47.0.213398074469.issue32221@psf.upfronthosting.co.za> ???? ????????? added the comment: Please look at my PR ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 11:51:14 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 16:51:14 +0000 Subject: [issue32325] C API should use 'const char *' instead of 'char *' In-Reply-To: <1513269141.75.0.213398074469.issue32325@psf.upfronthosting.co.za> Message-ID: <1513270274.13.0.213398074469.issue32325@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This already was done in issue28761. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 11:57:57 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 16:57:57 +0000 Subject: [issue32277] SystemError via chmod(symlink, ..., follow_symlinks=False) In-Reply-To: <1513014353.51.0.213398074469.issue32277@psf.upfronthosting.co.za> Message-ID: <1513270677.73.0.213398074469.issue32277@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 233ef249cc5c18d796fb581747179c5e062b4083 by Serhiy Storchaka (Anthony Sottile) in branch 'master': bpo-32277: Fix exception raised from chmod(..., follow_symlinks=False) (#4797) https://github.com/python/cpython/commit/233ef249cc5c18d796fb581747179c5e062b4083 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 11:58:08 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 Dec 2017 16:58:08 +0000 Subject: [issue32277] SystemError via chmod(symlink, ..., follow_symlinks=False) In-Reply-To: <1513014353.51.0.213398074469.issue32277@psf.upfronthosting.co.za> Message-ID: <1513270688.74.0.213398074469.issue32277@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4761 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 12:00:52 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 17:00:52 +0000 Subject: [issue32277] SystemError via chmod(symlink, ..., follow_symlinks=False) In-Reply-To: <1513014353.51.0.213398074469.issue32277@psf.upfronthosting.co.za> Message-ID: <1513270852.46.0.213398074469.issue32277@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I was going to request a test, but the fix is obvious and writing a test for this case can be not easy. Thank you Anthony for your report and patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 12:14:37 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 17:14:37 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513271677.5.0.213398074469.issue32300@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Options: 1. Use the subclass of KeyView with overridden __repr__ for os.environ.keys(). This will add a code for pretty rare use case. 2. Remove os.environ.__repr__. You can use repr(os.environ.copy()) or repr(dict(os.environ)) if you want to see a content. 3. Do not change anything. You can use repr(list(os.environ.keys())) if you want to see only keys. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 12:19:46 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 17:19:46 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1513271986.82.0.213398074469.issue29469@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PR 4866 also fixes the bug in optimizing chained 'i' and 'not in'. For example `1 in [1, 2] == [1, 2]` results in False (should be True) because it is changed to `1 in (1, 2) == [1, 2]`, and (1, 2) != [1, 2]. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 12:25:09 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 17:25:09 +0000 Subject: [issue32226] Implement PEP 560: Core support for typing module and generic types In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za> Message-ID: <1513272309.25.0.213398074469.issue32226@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think this is a cause. The difference may be dependent on the compiler and platform. ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 12:30:52 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 17:30:52 +0000 Subject: [issue32277] SystemError via chmod(symlink, ..., follow_symlinks=False) In-Reply-To: <1513014353.51.0.213398074469.issue32277@psf.upfronthosting.co.za> Message-ID: <1513272652.74.0.213398074469.issue32277@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset d1cb1067a82b11280204e36b695e786a5a3ca221 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6': bpo-32277: Fix exception raised from chmod(..., follow_symlinks=False) (GH-4797) (#4869) https://github.com/python/cpython/commit/d1cb1067a82b11280204e36b695e786a5a3ca221 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 12:31:17 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 17:31:17 +0000 Subject: [issue32277] SystemError via chmod(symlink, ..., follow_symlinks=False) In-Reply-To: <1513014353.51.0.213398074469.issue32277@psf.upfronthosting.co.za> Message-ID: <1513272677.11.0.213398074469.issue32277@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 12:51:24 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 Dec 2017 17:51:24 +0000 Subject: [issue32311] Implement asyncio.create_task() shortcut Message-ID: <1513273884.42.0.213398074469.issue32311@psf.upfronthosting.co.za> New submission from Yury Selivanov : There's a lengthy discussion of this proposal over here: https://github.com/python/asyncio/issues/477 Guido there likes the idea of adding asyncio.create_task(), so let's add it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 12:57:38 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 14 Dec 2017 17:57:38 +0000 Subject: [issue32323] urllib.parse.urlsplit() must not lowercase() IPv6 scope value In-Reply-To: <1513265439.83.0.213398074469.issue32323@psf.upfronthosting.co.za> Message-ID: <1513274258.57.0.213398074469.issue32323@psf.upfronthosting.co.za> R. David Murray added the comment: In quick search the only RFC reference to this I found was https://tools.ietf.org/id/draft-sweet-uri-zoneid-01.html, which doesn't match what you are requesting (not that urlsplit's current behavior matches that either). Do you have RFC references? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 13:24:33 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 18:24:33 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1513275873.21.0.213398074469.issue29469@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 15a8728415e765f57e37f431f09e5c5821a04063 by Serhiy Storchaka in branch 'master': bpo-29469: Optimize literal lists and sets iterating on the AST level. (#4866) https://github.com/python/cpython/commit/15a8728415e765f57e37f431f09e5c5821a04063 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 13:25:10 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 18:25:10 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1513275910.11.0.213398074469.issue29469@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 13:41:19 2017 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 14 Dec 2017 18:41:19 +0000 Subject: [issue32323] urllib.parse.urlsplit() must not lowercase() IPv6 scope value In-Reply-To: <1513265439.83.0.213398074469.issue32323@psf.upfronthosting.co.za> Message-ID: <1513276879.77.0.213398074469.issue32323@psf.upfronthosting.co.za> ???? ????????? added the comment: https://url.spec.whatwg.org/#host-representation -> Support for is intentionally omitted. https://tools.ietf.org/html/rfc6874 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 13:43:31 2017 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 14 Dec 2017 18:43:31 +0000 Subject: [issue32323] urllib.parse.urlsplit() must not lowercase() IPv6 scope value In-Reply-To: <1513265439.83.0.213398074469.issue32323@psf.upfronthosting.co.za> Message-ID: <1513277011.64.0.213398074469.issue32323@psf.upfronthosting.co.za> ???? ????????? added the comment: Also this: http://potaroo.net/ietf/idref/draft-kitamura-ipv6-zoneid-free/ So, I'm confused. Will investigate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 14:27:01 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Thu, 14 Dec 2017 19:27:01 +0000 Subject: [issue17852] Built-in module _io can lose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1513279621.33.0.213398074469.issue17852@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Attached is a script that triggers the non-flushing behaviour for me. I don't think it is reliable since it depends on the order that FileIO AND BufferedWriter are finalized when the gc finds them in a reference cycle. BTW, it is arguable that the root cause of this bug is that we no longer to topological ordering when calling finalizers. Originally, the cycle GC would refuse to call __del__ methods because once they are part of a cycle, there is no defined topological ordering. So, we linked that garage to gc.garbage rather than calling __del__ and have potentially undefined results. Now the GC has been changed to call __del__ anyhow. I haven't studied how this has been changed but this non-flushing bug is a result. Having the buffer added to gc.garbage would also result in the data not being flushed but arguably it would be more understandable what's going on. I'm not arguing that we should go back to that, just that current behaviour can be subtle and confusing. ---------- Added file: https://bugs.python.org/file47332/buffer_not_flushed.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 14:41:01 2017 From: report at bugs.python.org (Brett Cannon) Date: Thu, 14 Dec 2017 19:41:01 +0000 Subject: [issue32324] [Security] "python3 directory" inserts "directory" at sys.path[0] even in isolated mode In-Reply-To: <1513267755.86.0.213398074469.issue32324@psf.upfronthosting.co.za> Message-ID: <1513280461.36.0.213398074469.issue32324@psf.upfronthosting.co.za> Brett Cannon added the comment: Since the directory is where the code that is being executed exists don't you have to implicitly trust that directory is secure? Otherwise how can you even trust the code you're choosing to execute? ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 14:58:24 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 14 Dec 2017 19:58:24 +0000 Subject: [issue17852] Built-in module _io can lose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1513281504.74.0.213398074469.issue17852@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The reason Python 2 did well here is simply that Python 2 had a single Python object (the file object) for each actual file. Python 3 has several of them (the raw IO object, the buffered IO object, possibly the text IO wrapper), and so suddenly the finalization order matters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 15:25:55 2017 From: report at bugs.python.org (Decorater) Date: Thu, 14 Dec 2017 20:25:55 +0000 Subject: [issue32326] Update Build projects to version 10.0.16299.0 of the Windows 10 SDK. Message-ID: <1513283155.41.0.213398074469.issue32326@psf.upfronthosting.co.za> New submission from Decorater : It seems that When I uninstalled an older version of the Windows 10 SDK to make more disk space to update Visual Studio that now python 3.6 will not compile. I am not sure if Python 3.7 on master currently has this issue or not though I still have not tested it on 3.7 either. I am using Visual Studio 2017 to Compile the latest commit on branch 3.6. I could technically use branch master if the issue with Py_DecodeLocale() is fixed yet though. ---------- messages: 308333 nosy: Decorater priority: normal severity: normal status: open title: Update Build projects to version 10.0.16299.0 of the Windows 10 SDK. versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 15:26:15 2017 From: report at bugs.python.org (Decorater) Date: Thu, 14 Dec 2017 20:26:15 +0000 Subject: [issue32326] Update Build projects to version 10.0.16299.0 of the Windows 10 SDK. In-Reply-To: <1513283155.41.0.213398074469.issue32326@psf.upfronthosting.co.za> Message-ID: <1513283175.63.0.213398074469.issue32326@psf.upfronthosting.co.za> Change by Decorater : ---------- components: +Build, Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 15:37:57 2017 From: report at bugs.python.org (Aaron Meurer) Date: Thu, 14 Dec 2017 20:37:57 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513283877.69.0.213398074469.issue32300@psf.upfronthosting.co.za> Aaron Meurer added the comment: Serhiy, isn't option 4? 4. Make KeysView.__repr__ show list(self). Add a custom wrapper for Shelf's KeysView so that it doesn't do this. This seems to be what Victor is suggesting. It makes the most sense to me for the common (i.e., default) case to be to show the keys (and just the keys), and for use cases that want otherwise to subclass and modify. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 15:43:04 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 20:43:04 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513284184.34.0.213398074469.issue32300@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: With option 4 we need to add a custom wrapper not only for Shelf's KeysView, but for KeysView of all similar proxy classes, including classes in third-party code not available for us. This is impossible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 15:44:51 2017 From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=) Date: Thu, 14 Dec 2017 20:44:51 +0000 Subject: [issue28393] Update encoding lookup docs wrt #27938 In-Reply-To: <1476013149.31.0.17921258936.issue28393@psf.upfronthosting.co.za> Message-ID: <1513284291.2.0.213398074469.issue28393@psf.upfronthosting.co.za> Change by Ville Skytt? : ---------- pull_requests: +4762 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 15:44:51 2017 From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=) Date: Thu, 14 Dec 2017 20:44:51 +0000 Subject: [issue27938] PyUnicode_AsEncodedString, PyUnicode_Decode: add fast-path for "us-ascii" encoding In-Reply-To: <1472811574.16.0.472581628747.issue27938@psf.upfronthosting.co.za> Message-ID: <1513284291.3.0.00913614298617.issue27938@psf.upfronthosting.co.za> Change by Ville Skytt? : ---------- pull_requests: +4763 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 15:48:24 2017 From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=) Date: Thu, 14 Dec 2017 20:48:24 +0000 Subject: [issue28393] Update encoding lookup docs wrt #27938 In-Reply-To: <1476013149.31.0.17921258936.issue28393@psf.upfronthosting.co.za> Message-ID: <1513284504.05.0.213398074469.issue28393@psf.upfronthosting.co.za> Ville Skytt? added the comment: I'm getting a 500 internatl server error trying to update https://bugs.python.org/review/28393/, so noting here that the latest review issue has been addressed in https://github.com/python/cpython/pull/4871 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 15:53:14 2017 From: report at bugs.python.org (Aaron Meurer) Date: Thu, 14 Dec 2017 20:53:14 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513284794.47.0.213398074469.issue32300@psf.upfronthosting.co.za> Aaron Meurer added the comment: Can't third party code write their own proxies? Why do we have to do that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 15:58:58 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 Dec 2017 20:58:58 +0000 Subject: [issue32327] Make asyncio methods documented as coroutines - coroutines. Message-ID: <1513285138.55.0.213398074469.issue32327@psf.upfronthosting.co.za> New submission from Yury Selivanov : There's a handful of event loop methods that are currently documented as coroutines, but in reality they return asyncio.Future: * loop.sock_sendall, * loop.sock_accept, * loop.sock_recv, and * loop.run_in_executor. These methods need to become proper coroutines beacause: 1. loop.create_task(loop.sock_recv(..)) fails with a cryptic error. 2. It's harder for us to refactor the code keeping these functions as regular functions returning Futures. Once asyncio was broken because of the bug in loop.sock_connect() because of a complex refactoring. After we converted it to a coroutine in 3.6, we received 0 complaints, but the code became simpler. 3. It's easier to read the source code of asyncio, when all methods that are documented as coroutines are actually coroutines. 4. This downgrades the role of 'asyncio.ensure_future()' function. Basically, when a user needs a task, they can now use create_task() (which won't fail on some "coroutines" sometimes). asyncio users will be advised to design APIs in their programs and libraries around async/await and not Future objects. ---------- assignee: yselivanov components: asyncio messages: 308339 nosy: yselivanov priority: normal severity: normal status: open title: Make asyncio methods documented as coroutines - coroutines. versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 15:59:10 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 Dec 2017 20:59:10 +0000 Subject: [issue32327] Make asyncio methods documented as coroutines - coroutines. In-Reply-To: <1513285138.55.0.213398074469.issue32327@psf.upfronthosting.co.za> Message-ID: <1513285150.27.0.213398074469.issue32327@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 16:02:21 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 14 Dec 2017 21:02:21 +0000 Subject: [issue32327] Make asyncio methods documented as coroutines - coroutines. In-Reply-To: <1513285138.55.0.213398074469.issue32327@psf.upfronthosting.co.za> Message-ID: <1513285341.39.0.213398074469.issue32327@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4765 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 16:35:04 2017 From: report at bugs.python.org (Joshua Kinard) Date: Thu, 14 Dec 2017 21:35:04 +0000 Subject: [issue32328] ttk.Treeview: _tkinter.TclError: list element in quotes followed by "; " instead of space Message-ID: <1513287304.34.0.213398074469.issue32328@psf.upfronthosting.co.za> New submission from Joshua Kinard : I think I've found another bug with Tkinter's string handling in Python 2.7.14, before it passes off to the TCL interpreter when inserting items into a ttk.Treeview widget. Specifically, it doesn't handle strings containing semi-colons very well if they are passed in via a kwarg dict. Below is a simple test case. The "kw" variable has a 'values' key with a string value using single quotes to store the value '" ";': ------------------------------------------------------------------------------- from Tkinter import * from ttk import * root = Tk() tv = Treeview(root, columns=("foobar",)) tv.heading("foobar", text="Foobar!") tv.column("#0", width=0) tv.column("foobar", stretch=True, minwidth=100, width=400) tv.grid() kw = {'values': '" ";', 'tags': ''} tv.insert("", END, iid=None, **kw) root.mainloop() ------------------------------------------------------------------------------- This sample triggers this traceback: Traceback (most recent call last): File "test.py", line 14, in tv.insert("", END, iid=None, **kw) File "C:\Python27\lib\lib-tk\ttk.py", line 1339, in insert res = self.tk.call(self._w, "insert", parent, index, *opts) _tkinter.TclError: list element in quotes followed by ";" instead of space Furthermore, if the 'values' key is changed to the string 'X:"Y ";', you trigger a different traceback: Traceback (most recent call last): File "test.py", line 13, in tv.insert("", END, iid=None, **kw) File "C:\Python27\lib\lib-tk\ttk.py", line 1339, in insert res = self.tk.call(self._w, "insert", parent, index, *opts) _tkinter.TclError: unmatched open quote in list So definitely a case of something in the parser not handling things properly before sending to the TCL interpreter. I suspect this is similar to Issue #15861. One can work around this bug by checking for either a whitespace or backslash character in the string, and wrapping the string in curly braces if so, to disable TCL substitution mechanism, and it'll insert the string and display it correctly in the widget. I have only verified this in Python 2.7.14 at the moment, which is what I primarily work in right now. ---------- components: Tkinter messages: 308340 nosy: kumba priority: normal severity: normal status: open title: ttk.Treeview: _tkinter.TclError: list element in quotes followed by ";" instead of space type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 16:40:15 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 14 Dec 2017 21:40:15 +0000 Subject: [issue32328] ttk.Treeview: _tkinter.TclError: list element in quotes followed by "; " instead of space In-Reply-To: <1513287304.34.0.213398074469.issue32328@psf.upfronthosting.co.za> Message-ID: <1513287615.1.0.213398074469.issue32328@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 17:19:49 2017 From: report at bugs.python.org (Armin Rigo) Date: Thu, 14 Dec 2017 22:19:49 +0000 Subject: [issue17852] Built-in module _io can lose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1513289989.41.0.213398074469.issue17852@psf.upfronthosting.co.za> Change by Armin Rigo : ---------- nosy: -arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 17:33:03 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 14 Dec 2017 22:33:03 +0000 Subject: [issue32226] Implement PEP 560: Core support for typing module and generic types In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za> Message-ID: <1513290783.76.0.213398074469.issue32226@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: New changeset 2b5fd1e9ca9318673989e6ccac2c8acadc3809cd by Ivan Levkivskyi in branch 'master': bpo-32226: Implementation of PEP 560 (core components) (#4732) https://github.com/python/cpython/commit/2b5fd1e9ca9318673989e6ccac2c8acadc3809cd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 17:46:49 2017 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Thu, 14 Dec 2017 22:46:49 +0000 Subject: [issue32143] os.statvfs lacks f_fsid In-Reply-To: <1511713053.6.0.213398074469.issue32143@psf.upfronthosting.co.za> Message-ID: <1513291609.38.0.213398074469.issue32143@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: New changeset 96a5e50a5de3683b2afd6d680c7ecc4b525986f6 by Fred Drake (Giuseppe Scrivano) in branch 'master': bpo-32143: add f_fsid to os.statvfs() (#4571) https://github.com/python/cpython/commit/96a5e50a5de3683b2afd6d680c7ecc4b525986f6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 18:11:20 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 23:11:20 +0000 Subject: [issue32329] PYTHONHASHSEED=0 python3 -R should enable hash randomization Message-ID: <1513293080.01.0.213398074469.issue32329@psf.upfronthosting.co.za> New submission from STINNER Victor : Python pretends that hash randomization is always enabled, but it's not: $ PYTHONHASHSEED=0 python3 -c 'import sys; print(sys.flags.hash_randomization)' 1 vstinner at apu$ PYTHONHASHSEED=0 python3 -c 'import sys; print(hash("abc"))' 4596069200710135518 vstinner at apu$ PYTHONHASHSEED=0 python3 -c 'import sys; print(hash("abc"))' 4596069200710135518 vstinner at apu$ PYTHONHASHSEED=0 python3 -c 'import sys; print(hash("abc"))' 4596069200710135518 => sys.flags.hash_randomization must be zero Moreover, the -R flag is always ignored, it's not possible to override the PYTHONHASHSEED environment variable: vstinner at apu$ PYTHONHASHSEED=0 python3 -R -c 'import sys; print(sys.flags.hash_randomization)' 1 vstinner at apu$ PYTHONHASHSEED=0 python3 -R -c 'import sys; print(hash("abc"))' 4596069200710135518 vstinner at apu$ PYTHONHASHSEED=0 python3 -R -c 'import sys; print(hash("abc"))' 4596069200710135518 vstinner at apu$ PYTHONHASHSEED=0 python3 -R -c 'import sys; print(hash("abc"))' 4596069200710135518 I expect that -R enables hash randomization and overrides PYTHONHASHSEED environment variable. Attached PR fixes these issues and adds an unit test. ---------- messages: 308343 nosy: vstinner priority: normal severity: normal status: open title: PYTHONHASHSEED=0 python3 -R should enable hash randomization versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 18:16:46 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 23:16:46 +0000 Subject: [issue32329] PYTHONHASHSEED=0 python3 -R should enable hash randomization In-Reply-To: <1513293080.01.0.213398074469.issue32329@psf.upfronthosting.co.za> Message-ID: <1513293406.45.0.213398074469.issue32329@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- keywords: +patch pull_requests: +4766 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 18:16:46 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 23:16:46 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513293406.53.0.00913614298617.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4767 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 18:23:56 2017 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Thu, 14 Dec 2017 23:23:56 +0000 Subject: [issue32143] os.statvfs lacks f_fsid In-Reply-To: <1511713053.6.0.213398074469.issue32143@psf.upfronthosting.co.za> Message-ID: <1513293836.0.0.213398074469.issue32143@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: This has landed on master and will be part of Python 3.7. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 18:28:49 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Thu, 14 Dec 2017 23:28:49 +0000 Subject: [issue20329] zipfile.extractall fails in Posix shell with utf-8 filename In-Reply-To: <1390316753.93.0.767122614569.issue20329@psf.upfronthosting.co.za> Message-ID: <1513294129.48.0.213398074469.issue20329@psf.upfronthosting.co.za> Cheryl Sabella added the comment: I created an environment under 3.3.1 in which this error was still occurring, but within that same environment, it is not occurring for 3.7. I believe this can be closed. ---------- nosy: +csabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 18:39:06 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 23:39:06 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513294746.97.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4768 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 18:43:25 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 14 Dec 2017 23:43:25 +0000 Subject: [issue32226] Implement PEP 560: Core support for typing module and generic types In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za> Message-ID: <1513295005.42.0.213398074469.issue32226@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Interesting. I have noticed similar when I tried to add a fast loop proposed by Serhiy. It should save at least one pointer comparison for base class, but sometimes it actually led to slow-downs (although very small). How can one fight this kind of problems? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 18:46:37 2017 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 14 Dec 2017 23:46:37 +0000 Subject: [issue32226] Implement PEP 560: Core support for typing module and generic types In-Reply-To: <1513295005.42.0.213398074469.issue32226@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I think the best thing to do is not to panic! Also maybe PGO could help? On Dec 14, 2017 15:43, "Ivan Levkivskyi" wrote: > > Ivan Levkivskyi added the comment: > > Interesting. I have noticed similar when I tried to add a fast loop > proposed by Serhiy. It should save at least one pointer comparison for base > class, but sometimes it actually led to slow-downs (although very small). > How can one fight this kind of problems? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 18:51:24 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 23:51:24 +0000 Subject: [issue32329] PYTHONHASHSEED=0 python3 -R should enable hash randomization In-Reply-To: <1513293080.01.0.213398074469.issue32329@psf.upfronthosting.co.za> Message-ID: <1513295484.36.0.213398074469.issue32329@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 358e5e17a51ba00742bfaee4557a94c3c4179c22 by Victor Stinner in branch 'master': bpo-32329: Fix -R option for hash randomization (#4873) https://github.com/python/cpython/commit/358e5e17a51ba00742bfaee4557a94c3c4179c22 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 18:51:24 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Dec 2017 23:51:24 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513295484.43.0.912454111764.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 358e5e17a51ba00742bfaee4557a94c3c4179c22 by Victor Stinner in branch 'master': bpo-32329: Fix -R option for hash randomization (#4873) https://github.com/python/cpython/commit/358e5e17a51ba00742bfaee4557a94c3c4179c22 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 19:00:11 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 00:00:11 +0000 Subject: [issue32329] PYTHONHASHSEED=0 python3 -R should enable hash randomization In-Reply-To: <1513293080.01.0.213398074469.issue32329@psf.upfronthosting.co.za> Message-ID: <1513296011.88.0.213398074469.issue32329@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4769 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 19:09:59 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 00:09:59 +0000 Subject: [issue20329] zipfile.extractall fails in Posix shell with utf-8 filename In-Reply-To: <1390316753.93.0.767122614569.issue20329@psf.upfronthosting.co.za> Message-ID: <1513296599.92.0.213398074469.issue20329@psf.upfronthosting.co.za> STINNER Victor added the comment: > I created an environment under 3.3.1 in which this error was still occurring, but within that same environment, it is not occurring for 3.7. I believe this can be closed. Python 3.7 now uses the UTF-8 encoding when the LC_CTYPE locale is POSIX (PEP 538, PEP 540). You should still be able to reproduce the bug with a locale with an encoding different than UTF-8. Moreover, I understand that Python 3.6 is still affected by the bug. I don't think that we can fix this bug, sadly. But I'm happy to see that the PEP 538 and PEP 540 are already useful! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 19:12:29 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 00:12:29 +0000 Subject: [issue32226] Implement PEP 560: Core support for typing module and generic types In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za> Message-ID: <1513296749.86.0.213398074469.issue32226@psf.upfronthosting.co.za> STINNER Victor added the comment: It is very to get stable benchmarks with timings shorter than 1 ms, and even harder for timings shorter than 1 us. I wrote documentation to implement how to get more stable results: http://perf.readthedocs.io/en/latest/run_benchmark.html#how-to-get-reproductible-benchmark-results On Linux, using CPU isolation helps a lot, and perf uses automatically isolated CPUs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 19:22:26 2017 From: report at bugs.python.org (Steve Dower) Date: Fri, 15 Dec 2017 00:22:26 +0000 Subject: [issue32326] Update Build projects to version 10.0.16299.0 of the Windows 10 SDK. In-Reply-To: <1513283155.41.0.213398074469.issue32326@psf.upfronthosting.co.za> Message-ID: <1513297346.9.0.213398074469.issue32326@psf.upfronthosting.co.za> Steve Dower added the comment: It has been resolved in master, so we just need to backport PCbuild/python.props to get it in earlier branches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 19:25:27 2017 From: report at bugs.python.org (Mark Sapiro) Date: Fri, 15 Dec 2017 00:25:27 +0000 Subject: [issue32330] Email parser creates a message object that can't be flattened Message-ID: <1513297527.86.0.213398074469.issue32330@psf.upfronthosting.co.za> New submission from Mark Sapiro : This is related to https://bugs.python.org/issue27321 but a different exception is thrown for a different reason. This is caused by a defective spam message. I don't actually have the offending message from the wild, but the attached bad_email_2.eml illustrates the problem. The defect is the message declares the content charset as us-ascii, but the body contains non-ascii. When the message is parsed into an email.message.Message object and the objects as_string() method is called, UnicodeEncodeError is thrown as follows: >>> import email >>> with open('bad_email_2.eml', 'rb') as fp: ... msg = email.message_from_binary_file(fp) ... >>> msg.as_string() Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.5/email/message.py", line 159, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/python3.5/email/generator.py", line 115, in flatten self._write(msg) File "/usr/lib/python3.5/email/generator.py", line 181, in _write self._dispatch(msg) File "/usr/lib/python3.5/email/generator.py", line 214, in _dispatch meth(msg) File "/usr/lib/python3.5/email/generator.py", line 243, in _handle_text msg.set_payload(payload, charset) File "/usr/lib/python3.5/email/message.py", line 316, in set_payload payload = payload.encode(charset.output_charset) UnicodeEncodeError: 'ascii' codec can't encode characters in position 31-33: ordinal not in range(128) ---------- components: email files: bad_email_2.eml messages: 308353 nosy: barry, msapiro, r.david.murray priority: normal severity: normal status: open title: Email parser creates a message object that can't be flattened type: behavior versions: Python 3.5, Python 3.6 Added file: https://bugs.python.org/file47333/bad_email_2.eml _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 19:39:50 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 00:39:50 +0000 Subject: [issue32329] PYTHONHASHSEED=0 python3 -R should enable hash randomization In-Reply-To: <1513293080.01.0.213398074469.issue32329@psf.upfronthosting.co.za> Message-ID: <1513298390.81.0.213398074469.issue32329@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 22097aaa77b4f0473552fe840358d77e5b9a253f by Victor Stinner in branch '3.6': bpo-32329: Fix sys.flags.hash_randomization (#4875) https://github.com/python/cpython/commit/22097aaa77b4f0473552fe840358d77e5b9a253f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 19:43:00 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 00:43:00 +0000 Subject: [issue32329] PYTHONHASHSEED=0 python3 -R should enable hash randomization In-Reply-To: <1513293080.01.0.213398074469.issue32329@psf.upfronthosting.co.za> Message-ID: <1513298580.6.0.213398074469.issue32329@psf.upfronthosting.co.za> STINNER Victor added the comment: "PYTHONHASHSEED=0 python3 -R" now enables hash randomization on master (Python 3.7), I also fixed the sys.flags.hash_randomization value when using PYTHONHASHSEED=0. I chose to not modify the behaviour of the -R option in Python 3.6. I dislike having to document a behaviour change in a minor Python version (3.6.x). I only fixed the value of sys.flags.hash_randomization in Python 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 19:46:04 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 00:46:04 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513298764.79.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset da273412c4374de07a500e7f23f89a6bb7527398 by Victor Stinner in branch 'master': bpo-32030: Add _PyCoreConfig_Copy() (#4874) https://github.com/python/cpython/commit/da273412c4374de07a500e7f23f89a6bb7527398 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 19:47:14 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 00:47:14 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513298834.7.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4770 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 19:48:59 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 15 Dec 2017 00:48:59 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513298939.23.0.213398074469.issue32300@psf.upfronthosting.co.za> Cheryl Sabella added the comment: I'm missing something here, so please forgive me for asking, but why is it bad to add: def keys(self): return self._data.keys() def values(self): return self._data.values() def items(self): return self._data.items() to the _Environ class? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 19:51:31 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 15 Dec 2017 00:51:31 +0000 Subject: [issue32300] print(os.environ.keys()) should only print the keys In-Reply-To: <1513154220.65.0.213398074469.issue32300@psf.upfronthosting.co.za> Message-ID: <1513299091.68.0.213398074469.issue32300@psf.upfronthosting.co.za> Cheryl Sabella added the comment: Never mind. I see it's in bytes. I missed that the first time. But, if it wasn't in bytes, would that be an OK solution? Or is it bad to override those methods in that class? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 20:05:33 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 01:05:33 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513299933.12.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 41264f1cd4d6066b2797ff07cae465c1e06ff3b2 by Victor Stinner in branch 'master': bpo-32030: Add _PyMainInterpreterConfig.executable (#4876) https://github.com/python/cpython/commit/41264f1cd4d6066b2797ff07cae465c1e06ff3b2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 20:53:29 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 15 Dec 2017 01:53:29 +0000 Subject: [issue32327] Make asyncio methods documented as coroutines - coroutines. In-Reply-To: <1513285138.55.0.213398074469.issue32327@psf.upfronthosting.co.za> Message-ID: <1513302809.86.0.213398074469.issue32327@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 19a44f63c738388ef3c8515348b4ffc061dfd627 by Yury Selivanov in branch 'master': bpo-32327: Convert asyncio functions documented as coroutines to coroutines. (#4872) https://github.com/python/cpython/commit/19a44f63c738388ef3c8515348b4ffc061dfd627 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 20:53:44 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 15 Dec 2017 01:53:44 +0000 Subject: [issue32327] Make asyncio methods documented as coroutines - coroutines. In-Reply-To: <1513285138.55.0.213398074469.issue32327@psf.upfronthosting.co.za> Message-ID: <1513302824.38.0.213398074469.issue32327@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 21:34:12 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 15 Dec 2017 02:34:12 +0000 Subject: [issue32330] Email parser creates a message object that can't be flattened In-Reply-To: <1513297527.86.0.213398074469.issue32330@psf.upfronthosting.co.za> Message-ID: <1513305252.0.0.213398074469.issue32330@psf.upfronthosting.co.za> R. David Murray added the comment: What would you like to see happen in that situation? Should we use errors=replace like we do for headers? (That seems reasonable to me.) Note that it can be re-serialized as binary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 22:23:27 2017 From: report at bugs.python.org (Mark Sapiro) Date: Fri, 15 Dec 2017 03:23:27 +0000 Subject: [issue32330] Email parser creates a message object that can't be flattened In-Reply-To: <1513297527.86.0.213398074469.issue32330@psf.upfronthosting.co.za> Message-ID: <1513308207.85.0.213398074469.issue32330@psf.upfronthosting.co.za> Mark Sapiro added the comment: Yes. I think errors=replace is a good solution. In Mailman, we have our own mailman.email.message.Message class which is a subclass of email.message.Message and what we do to work around this and issue27321 is override as_string() with: def as_string(self): # Work around for https://bugs.python.org/issue27321 and # https://bugs.python.org/issue32330. try: value = email.message.Message.as_string(self) except (KeyError, UnicodeEncodeError): value = email.message.Message.as_bytes(self).decode( 'ascii', 'replace') return value ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 22:42:49 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 15 Dec 2017 03:42:49 +0000 Subject: [issue32331] apply SOCK_TYPE_MASK to socket.type on Linux Message-ID: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> New submission from Yury Selivanov : On Linux, socket type is both a socket type and a bit mask (of SOCK_CLOEXEC and SOCK_NONBLOCK). Therefore, anyone who write code like 'if sock.type == SOCK_STREAM' writes non-portable code, that occasionally breaks on Linux. This caused some hard to spot bugs in asyncio already: https://bugs.python.org/issue27456 -- this one was discovered only 1 year after the actual change. On Linux, in 'include/linux/net.h' there's a SOCK_TYPE_MASK macro defined to 0xF. The idea is that on Linux you should mask socket type before comparing it to SOCK_STREAM or other socket types. Using socket.SOCK_NONBLOCK on Python was always error-prone even if one targets only Linux. For instance, socket.type won't be updated to include SOCK_NONBLOCK if the socket was updated via ioctl call directly. Therefore, I propose to fix socket.type getter to always (on Linux) apply that mask in Python. ---------- components: Library (Lib) messages: 308363 nosy: asvetlov, inada.naoki, pitrou, vstinner, yselivanov priority: normal severity: normal status: open title: apply SOCK_TYPE_MASK to socket.type on Linux type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 14 22:45:18 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 15 Dec 2017 03:45:18 +0000 Subject: [issue32331] apply SOCK_TYPE_MASK to socket.type on Linux In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513309518.67.0.213398074469.issue32331@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4771 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 00:04:44 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 15 Dec 2017 05:04:44 +0000 Subject: [issue32311] Implement asyncio.create_task() shortcut In-Reply-To: <1513273884.42.0.213398074469.issue32311@psf.upfronthosting.co.za> Message-ID: <1513314284.36.0.213398074469.issue32311@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset f74ef458ab1f502e4e60bd1502ac1dc0d2cb3847 by Andrew Svetlov in branch 'master': bpo-32311: Implement asyncio.create_task() shortcut (#4848) https://github.com/python/cpython/commit/f74ef458ab1f502e4e60bd1502ac1dc0d2cb3847 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 00:27:34 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 15 Dec 2017 05:27:34 +0000 Subject: [issue32311] Implement asyncio.create_task() shortcut In-Reply-To: <1513273884.42.0.213398074469.issue32311@psf.upfronthosting.co.za> Message-ID: <1513315654.83.0.213398074469.issue32311@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 01:47:42 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 15 Dec 2017 06:47:42 +0000 Subject: [issue32332] Implement slots support for magic methods added in PEP 560 Message-ID: <1513320462.57.0.213398074469.issue32332@psf.upfronthosting.co.za> New submission from Yury Selivanov : I propose to add type slots for magic methods introduced by PEP 560. In the brief discussion on the mailing list Guido OK'd the idea: https://mail.python.org/pipermail/python-dev/2017-December/151262.html I'll submit a PR that implements this proposal by adding new 'tp_as_class' slot, that points to a PyClassMethods struct, that has two fields: `cm_getitem` and `cm_mro_entries`. Interestingly, when __class_getitem__ is implemented through the type/slots machinery it becomes a bit faster. Given the following microbenchmark: class Foo: def __class_getitem__(cls, o): return o for _ in range(3): t = time.monotonic() for i in range(10 ** 8): assert i == Foo[i] print(f'{time.monotonic() - t:.3f}s') I see these numbers for the master branch: 17.161s 17.024s 16.530s and these for the C-slots branch: 15.010s 15.693s 15.035s ---------- components: Interpreter Core messages: 308365 nosy: gvanrossum, levkivskyi, pitrou, yselivanov priority: normal severity: normal status: open title: Implement slots support for magic methods added in PEP 560 versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 01:48:54 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 15 Dec 2017 06:48:54 +0000 Subject: [issue32332] Implement slots support for magic methods added in PEP 560 In-Reply-To: <1513320462.57.0.213398074469.issue32332@psf.upfronthosting.co.za> Message-ID: <1513320534.31.0.213398074469.issue32332@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4772 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 01:54:28 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 15 Dec 2017 06:54:28 +0000 Subject: [issue32311] Implement asyncio.create_task() shortcut In-Reply-To: <1513273884.42.0.213398074469.issue32311@psf.upfronthosting.co.za> Message-ID: <1513320868.86.0.213398074469.issue32311@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thank you, Andrew! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 02:48:14 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 15 Dec 2017 07:48:14 +0000 Subject: [issue32264] move pygetopt.h into internal/ In-Reply-To: <1512857323.9.0.213398074469.issue32264@psf.upfronthosting.co.za> Message-ID: <1513324094.94.0.213398074469.issue32264@psf.upfronthosting.co.za> Benjamin Peterson added the comment: New changeset e425bd75177ffb7f098bdb0618b4a5ba3211fe52 by Benjamin Peterson in branch 'master': move pygetopt.h to internal (closes bpo-32264) (#4830) https://github.com/python/cpython/commit/e425bd75177ffb7f098bdb0618b4a5ba3211fe52 ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 02:51:15 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 07:51:15 +0000 Subject: [issue32332] Implement slots support for magic methods added in PEP 560 In-Reply-To: <1513320462.57.0.213398074469.issue32332@psf.upfronthosting.co.za> Message-ID: <1513324275.55.0.213398074469.issue32332@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This isn't so easy. You can't just access new slot, because this is binary incompatible. You should add new type flag, say Py_TPFLAGS_HAVE_CLASS, set it for all classes with tp_as_class, and guard access to tp_as_class with if (!PyType_HasFeature(tp, Py_TPFLAGS_HAVE_CLASS)) ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 04:20:48 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 15 Dec 2017 09:20:48 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1513329648.56.0.213398074469.issue29469@psf.upfronthosting.co.za> Change by INADA Naoki : ---------- pull_requests: +4773 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 04:22:07 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 15 Dec 2017 09:22:07 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1513329727.56.0.213398074469.issue29469@psf.upfronthosting.co.za> INADA Naoki added the comment: > ISTM, the constant-tracking macros for peephole.c can also be removed, essentially reverting back to the simpler cumlc-style code in Py2.5. I tried it in GH-4879. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 04:47:19 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 15 Dec 2017 09:47:19 +0000 Subject: [issue32331] apply SOCK_TYPE_MASK to socket.type on Linux In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513331239.24.0.213398074469.issue32331@psf.upfronthosting.co.za> INADA Naoki added the comment: Should we backport it to 3.6? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 04:53:13 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 09:53:13 +0000 Subject: [issue27169] __debug__ is not optimized out at compile time for anything but `if:` and `while:` blocks In-Reply-To: <1464720658.3.0.0366082537286.issue27169@psf.upfronthosting.co.za> Message-ID: <1513331593.86.0.213398074469.issue27169@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +4774 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 04:53:13 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 09:53:13 +0000 Subject: [issue22091] __debug__ in compile(optimize=1) In-Reply-To: <1406460720.31.0.52304616259.issue22091@psf.upfronthosting.co.za> Message-ID: <1513331593.98.0.00913614298617.issue22091@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +4775 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 04:56:50 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 15 Dec 2017 09:56:50 +0000 Subject: [issue32331] apply SOCK_TYPE_MASK to socket.type on Linux In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513331810.28.0.213398074469.issue32331@psf.upfronthosting.co.za> INADA Naoki added the comment: Document of socket.type says: The socket type. https://docs.python.org/3/library/socket.html#socket.socket.type OK, so, are SOCK_CLOEXEC and SOCK_NONBLOCK socket type? These two constants, if defined, can be combined with the socket types and allow you to set some flags atomically... https://docs.python.org/3/library/socket.html#socket.SOCK_CLOEXEC So they are not socket type. They are constants which can be used for setting some flags. Regarding to this document, I think this can be bugfix rather than behavior change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 05:07:08 2017 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 15 Dec 2017 10:07:08 +0000 Subject: [issue32240] Add the const qualifier for PyObject* array arguments In-Reply-To: <1512645701.53.0.213398074469.issue32240@psf.upfronthosting.co.za> Message-ID: <1513332428.91.0.213398074469.issue32240@psf.upfronthosting.co.za> Stefan Behnel added the comment: Seems ok from Cython side. Could be a bit difficult to make an actual use of this, but at least it shouldn't break anything. And it's a reasonable constraint to enforce. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 05:19:30 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 10:19:30 +0000 Subject: [issue28393] Update encoding lookup docs wrt #27938 In-Reply-To: <1476013149.31.0.17921258936.issue28393@psf.upfronthosting.co.za> Message-ID: <1513333170.07.0.213398074469.issue28393@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 297fd876aad8ef443d8992618de22c46dbda258b by Victor Stinner (Ville Skytt?) in branch 'master': bpo-28393: Update encoding lookup docs wrt bpo-27938 (#4871) https://github.com/python/cpython/commit/297fd876aad8ef443d8992618de22c46dbda258b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 05:19:30 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 10:19:30 +0000 Subject: [issue27938] PyUnicode_AsEncodedString, PyUnicode_Decode: add fast-path for "us-ascii" encoding In-Reply-To: <1472811574.16.0.472581628747.issue27938@psf.upfronthosting.co.za> Message-ID: <1513333170.22.0.912454111764.issue27938@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 297fd876aad8ef443d8992618de22c46dbda258b by Victor Stinner (Ville Skytt?) in branch 'master': bpo-28393: Update encoding lookup docs wrt bpo-27938 (#4871) https://github.com/python/cpython/commit/297fd876aad8ef443d8992618de22c46dbda258b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 05:19:30 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 15 Dec 2017 10:19:30 +0000 Subject: [issue32311] Implement asyncio.create_task() shortcut In-Reply-To: <1513273884.42.0.213398074469.issue32311@psf.upfronthosting.co.za> Message-ID: <1513333170.82.0.213398074469.issue32311@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Thanks for careful review! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 05:20:02 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Dec 2017 10:20:02 +0000 Subject: [issue28393] Update encoding lookup docs wrt #27938 In-Reply-To: <1476013149.31.0.17921258936.issue28393@psf.upfronthosting.co.za> Message-ID: <1513333202.86.0.213398074469.issue28393@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4776 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 05:20:03 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Dec 2017 10:20:03 +0000 Subject: [issue27938] PyUnicode_AsEncodedString, PyUnicode_Decode: add fast-path for "us-ascii" encoding In-Reply-To: <1472811574.16.0.472581628747.issue27938@psf.upfronthosting.co.za> Message-ID: <1513333203.02.0.00913614298617.issue27938@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4777 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 05:20:42 2017 From: report at bugs.python.org (Christian Heimes) Date: Fri, 15 Dec 2017 10:20:42 +0000 Subject: [issue32331] apply SOCK_TYPE_MASK to socket.type on Linux In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513333242.7.0.213398074469.issue32331@psf.upfronthosting.co.za> Christian Heimes added the comment: Python's handling of socket has multiple issues, see #28134 for more fun. At the moment the values of type, family and protocol are unreliable at best and dangerously wrong at worst. The attributes are only correct if and only if the socket has not been created from a file descriptor and the socket hasn't been manipulated with ioctl or setsockopt(). Now to the issue at hand. I'm -1 on applying a mask to type. You can easily work around your problem by replacing "sock.type == SOCK_STREAM" with "sock.type & SOCK_STREAM == SOCK_STREAM". ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 05:35:50 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 10:35:50 +0000 Subject: [issue22091] __debug__ in compile(optimize=1) In-Reply-To: <1406460720.31.0.52304616259.issue22091@psf.upfronthosting.co.za> Message-ID: <1513334150.92.0.213398074469.issue22091@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 3325a6780c81f1ea51190370b5454879c4862a37 by Serhiy Storchaka in branch 'master': bpo-27169: The __debug__ constant is now optimized out at compile time. (#4880) https://github.com/python/cpython/commit/3325a6780c81f1ea51190370b5454879c4862a37 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 05:35:51 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 10:35:51 +0000 Subject: [issue27169] __debug__ is not optimized out at compile time for anything but `if:` and `while:` blocks In-Reply-To: <1464720658.3.0.0366082537286.issue27169@psf.upfronthosting.co.za> Message-ID: <1513334151.17.0.912454111764.issue27169@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 3325a6780c81f1ea51190370b5454879c4862a37 by Serhiy Storchaka in branch 'master': bpo-27169: The __debug__ constant is now optimized out at compile time. (#4880) https://github.com/python/cpython/commit/3325a6780c81f1ea51190370b5454879c4862a37 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 05:46:03 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 10:46:03 +0000 Subject: [issue22091] __debug__ in compile(optimize=1) In-Reply-To: <1406460720.31.0.52304616259.issue22091@psf.upfronthosting.co.za> Message-ID: <1513334763.6.0.213398074469.issue22091@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is it worth to backport this change? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 05:54:23 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 10:54:23 +0000 Subject: [issue22091] __debug__ in compile(optimize=1) In-Reply-To: <1406460720.31.0.52304616259.issue22091@psf.upfronthosting.co.za> Message-ID: <1513335263.06.0.213398074469.issue22091@psf.upfronthosting.co.za> STINNER Victor added the comment: > Is it worth to backport this change? It's an optimization, usually the answer is no. The change is short and can be seen as a bugfix, so it's up to you, it's ok to backport to 3.6, and maybe even 2.7, if it's not too hard to write the backport. ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 06:02:27 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 11:02:27 +0000 Subject: [issue27169] __debug__ is not optimized out at compile time for anything but `if:` and `while:` blocks In-Reply-To: <1464720658.3.0.0366082537286.issue27169@psf.upfronthosting.co.za> Message-ID: <1513335747.83.0.213398074469.issue27169@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4778 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 06:02:28 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 11:02:28 +0000 Subject: [issue22091] __debug__ in compile(optimize=1) In-Reply-To: <1406460720.31.0.52304616259.issue22091@psf.upfronthosting.co.za> Message-ID: <1513335748.0.0.00913614298617.issue22091@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4779 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 06:11:14 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 11:11:14 +0000 Subject: [issue32240] Add the const qualifier for PyObject* array arguments In-Reply-To: <1512645701.53.0.213398074469.issue32240@psf.upfronthosting.co.za> Message-ID: <1513336274.17.0.213398074469.issue32240@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset a5552f023e1d8cbafee1e51d316cc581deb2295f by Serhiy Storchaka in branch 'master': bpo-32240: Add the const qualifier to declarations of PyObject* array arguments. (#4746) https://github.com/python/cpython/commit/a5552f023e1d8cbafee1e51d316cc581deb2295f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 06:15:02 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 11:15:02 +0000 Subject: [issue32240] Add the const qualifier for PyObject* array arguments In-Reply-To: <1512645701.53.0.213398074469.issue32240@psf.upfronthosting.co.za> Message-ID: <1513336502.82.0.213398074469.issue32240@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 06:26:28 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 11:26:28 +0000 Subject: [issue22091] __debug__ in compile(optimize=1) In-Reply-To: <1406460720.31.0.52304616259.issue22091@psf.upfronthosting.co.za> Message-ID: <1513337188.5.0.213398074469.issue22091@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset b82da9ebb20053637e731fd40589e1e52f9f8f6e by Serhiy Storchaka in branch '3.6': [3.6] bpo-27169: The __debug__ constant is now optimized out at compile time. (GH-4880) (#4882) https://github.com/python/cpython/commit/b82da9ebb20053637e731fd40589e1e52f9f8f6e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 06:26:28 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 11:26:28 +0000 Subject: [issue27169] __debug__ is not optimized out at compile time for anything but `if:` and `while:` blocks In-Reply-To: <1464720658.3.0.0366082537286.issue27169@psf.upfronthosting.co.za> Message-ID: <1513337188.69.0.912454111764.issue27169@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset b82da9ebb20053637e731fd40589e1e52f9f8f6e by Serhiy Storchaka in branch '3.6': [3.6] bpo-27169: The __debug__ constant is now optimized out at compile time. (GH-4880) (#4882) https://github.com/python/cpython/commit/b82da9ebb20053637e731fd40589e1e52f9f8f6e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 06:26:53 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 11:26:53 +0000 Subject: [issue27169] __debug__ is not optimized out at compile time for anything but `if:` and `while:` blocks In-Reply-To: <1464720658.3.0.0366082537286.issue27169@psf.upfronthosting.co.za> Message-ID: <1513337213.83.0.213398074469.issue27169@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- dependencies: -Build-out an AST optimizer, moving some functionality out of the peephole optimizer resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 06:28:34 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 11:28:34 +0000 Subject: [issue22091] __debug__ in compile(optimize=1) In-Reply-To: <1406460720.31.0.52304616259.issue22091@psf.upfronthosting.co.za> Message-ID: <1513337314.9.0.213398074469.issue22091@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The backport to 3.6 is straightforward, but backporting to 2.7 would require larger changes. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> behavior versions: +Python 3.6, Python 3.7 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 07:09:41 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 12:09:41 +0000 Subject: [issue32222] pygettext doesn't extract docstrings for functions with type annotated params In-Reply-To: <1512470175.69.0.213398074469.issue32222@psf.upfronthosting.co.za> Message-ID: <1513339781.9.0.213398074469.issue32222@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka versions: +Python 3.7 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 07:11:45 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 12:11:45 +0000 Subject: [issue21074] Too aggressive constant folding In-Reply-To: <1395887196.57.0.903293210902.issue21074@psf.upfronthosting.co.za> Message-ID: <1513339905.14.0.213398074469.issue21074@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 2e3f5701858d1fc04caedefdd9a8ea43810270d2 by Serhiy Storchaka in branch 'master': bpo-30416: Protect the optimizer during constant folding. (#4860) https://github.com/python/cpython/commit/2e3f5701858d1fc04caedefdd9a8ea43810270d2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 07:11:46 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 12:11:46 +0000 Subject: [issue30416] constant folding opens compiler to quadratic time hashing In-Reply-To: <1495314097.2.0.680001526088.issue30416@psf.upfronthosting.co.za> Message-ID: <1513339906.27.0.912454111764.issue30416@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 2e3f5701858d1fc04caedefdd9a8ea43810270d2 by Serhiy Storchaka in branch 'master': bpo-30416: Protect the optimizer during constant folding. (#4860) https://github.com/python/cpython/commit/2e3f5701858d1fc04caedefdd9a8ea43810270d2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 07:12:16 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 12:12:16 +0000 Subject: [issue21074] Too aggressive constant folding In-Reply-To: <1395887196.57.0.903293210902.issue21074@psf.upfronthosting.co.za> Message-ID: <1513339936.94.0.213398074469.issue21074@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset b580f4f2bf49fd3b11f2a046911993560c02492a by Serhiy Storchaka in branch '3.6': [3.6] bpo-30416: Protect the optimizer during constant folding. (#4865) https://github.com/python/cpython/commit/b580f4f2bf49fd3b11f2a046911993560c02492a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 07:12:17 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 12:12:17 +0000 Subject: [issue30416] constant folding opens compiler to quadratic time hashing In-Reply-To: <1495314097.2.0.680001526088.issue30416@psf.upfronthosting.co.za> Message-ID: <1513339937.08.0.912454111764.issue30416@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset b580f4f2bf49fd3b11f2a046911993560c02492a by Serhiy Storchaka in branch '3.6': [3.6] bpo-30416: Protect the optimizer during constant folding. (#4865) https://github.com/python/cpython/commit/b580f4f2bf49fd3b11f2a046911993560c02492a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 07:13:43 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 12:13:43 +0000 Subject: [issue32265] Correctly classify builtin static and class methods In-Reply-To: <1512860050.29.0.213398074469.issue32265@psf.upfronthosting.co.za> Message-ID: <1513340023.3.0.213398074469.issue32265@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 3327a2ddf1eaf8cc678f0219ba9edf7d632d1b20 by Serhiy Storchaka in branch 'master': bpo-32265: Classify class and static methods of builtin types. (#4776) https://github.com/python/cpython/commit/3327a2ddf1eaf8cc678f0219ba9edf7d632d1b20 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 07:14:40 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 12:14:40 +0000 Subject: [issue32265] Correctly classify builtin static and class methods In-Reply-To: <1512860050.29.0.213398074469.issue32265@psf.upfronthosting.co.za> Message-ID: <1513340080.3.0.213398074469.issue32265@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 08:53:23 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 13:53:23 +0000 Subject: [issue32324] [Security] "python3 directory" inserts "directory" at sys.path[0] even in isolated mode In-Reply-To: <1513267755.86.0.213398074469.issue32324@psf.upfronthosting.co.za> Message-ID: <1513346003.59.0.213398074469.issue32324@psf.upfronthosting.co.za> STINNER Victor added the comment: > Since the directory is where the code that is being executed exists don't you have to implicitly trust that directory is secure? Otherwise how can you even trust the code you're choosing to execute? The question is if the following example must work with -I: --- vstinner at apu$ mkdir directory vstinner at apu$ echo "import submodule" > directory/__main__.py vstinner at apu$ echo 'print("submodule", __file__)' > directory/submodule.py vstinner at apu$ python3 directory submodule directory/submodule.py vstinner at apu$ python3 -I directory submodule directory/submodule.py --- Do you expect that "python3 directory" allows imports from directory/? The second question is if directory must be prepended to sys.path (start), or if it must be appended to sys.path (end)? Prepend allows to override stdlib imports, whereas append risks of conflicts with others paths in sys.path and so loading the "wrong" submodule. For example, I still expect to run __main__ from directory in the following example: --- vstinner at apu$ mkdir other vstinner at apu$ echo "print('other main')" > other/__main__.py vstinner at apu$ PYTHONPATH=other python3 directory submodule directory/submodule.py --- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 09:23:26 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 14:23:26 +0000 Subject: [issue28393] Update encoding lookup docs wrt #27938 In-Reply-To: <1476013149.31.0.17921258936.issue28393@psf.upfronthosting.co.za> Message-ID: <1513347806.33.0.213398074469.issue28393@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 77bf6da7258b4a312e224860ea50ac010aa17c1e by Victor Stinner (Miss Islington (bot)) in branch '3.6': bpo-28393: Update encoding lookup docs wrt bpo-27938 (GH-4871) (#4881) https://github.com/python/cpython/commit/77bf6da7258b4a312e224860ea50ac010aa17c1e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 09:23:26 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 14:23:26 +0000 Subject: [issue27938] PyUnicode_AsEncodedString, PyUnicode_Decode: add fast-path for "us-ascii" encoding In-Reply-To: <1472811574.16.0.472581628747.issue27938@psf.upfronthosting.co.za> Message-ID: <1513347806.48.0.912454111764.issue27938@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 77bf6da7258b4a312e224860ea50ac010aa17c1e by Victor Stinner (Miss Islington (bot)) in branch '3.6': bpo-28393: Update encoding lookup docs wrt bpo-27938 (GH-4871) (#4881) https://github.com/python/cpython/commit/77bf6da7258b4a312e224860ea50ac010aa17c1e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 09:23:53 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 14:23:53 +0000 Subject: [issue28393] Update encoding lookup docs wrt #27938 In-Reply-To: <1476013149.31.0.17921258936.issue28393@psf.upfronthosting.co.za> Message-ID: <1513347833.16.0.213398074469.issue28393@psf.upfronthosting.co.za> STINNER Victor added the comment: Thank you Ville Skytt? for your contribution! I merged your PR and backported it to Python 3.6. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 09:37:59 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 14:37:59 +0000 Subject: [issue31940] copystat on symlinks fails for alpine -- faulty lchmod implementation? In-Reply-To: <1509753073.77.0.213398074469.issue31940@psf.upfronthosting.co.za> Message-ID: <1513348679.61.0.213398074469.issue31940@psf.upfronthosting.co.za> STINNER Victor added the comment: Dummy question. If lchmod() is not supported by the libc, would it be possible to reimplement it using readlink()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 09:40:10 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 15 Dec 2017 14:40:10 +0000 Subject: [issue32330] Email parser creates a message object that can't be flattened In-Reply-To: <1513297527.86.0.213398074469.issue32330@psf.upfronthosting.co.za> Message-ID: <1513348810.1.0.213398074469.issue32330@psf.upfronthosting.co.za> R. David Murray added the comment: I do wonder where you are using the string version of messages :) I actually thought I'd already done this (errors=replace), but obviously not. I don't have time now to work on a patch for this, and the patch in the other issue hasn't be updated to reflect the review I did :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 09:41:19 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 14:41:19 +0000 Subject: [issue32333] test_smtplib: dangling threads on x86 Gentoo Non-Debug with X 3.x Message-ID: <1513348879.75.0.213398074469.issue32333@psf.upfronthosting.co.za> New submission from STINNER Victor : http://buildbot.python.org/all/#/builders/99/builds/363 0:00:16 load avg: 2.60 [ 12/412/1] test_smtplib failed (env changed) testFailingHELO (test.test_smtplib.BadHELOServerTests) ... ok (...) testLineTooLong (test.test_smtplib.TooLongLineTests) ... ok ---------------------------------------------------------------------- Ran 54 tests in 1.828s OK (skipped=1) Warning -- threading_cleanup() failed to cleanup 0 threads (count: 0, dangling: 3) Dangling thread: <_MainThread(MainThread, started 3075602176)> Dangling thread: Dangling thread: ---------- components: Tests messages: 308396 nosy: vstinner priority: normal severity: normal status: open title: test_smtplib: dangling threads on x86 Gentoo Non-Debug with X 3.x versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 09:43:15 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 14:43:15 +0000 Subject: [issue32332] Implement slots support for magic methods added in PEP 560 In-Reply-To: <1513320462.57.0.213398074469.issue32332@psf.upfronthosting.co.za> Message-ID: <1513348995.37.0.213398074469.issue32332@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PR 4883 shows how magic methods for PEP 560 can be implemented without introducing new slots. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 09:45:07 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 14:45:07 +0000 Subject: [issue32334] test_configparser left @test_2876_tmp temporary file on x86 Windows7 3.x Message-ID: <1513349107.71.0.213398074469.issue32334@psf.upfronthosting.co.za> New submission from STINNER Victor : http://buildbot.python.org/all/#/builders/58/builds/332 running: test_multiprocessing_spawn (901 sec), test_concurrent_futures (151 sec) 0:47:16 [250/413/1] test_multiprocessing_spawn crashed (Exit code 1) -- running: test_concurrent_futures (154 sec) Timeout (0:15:00)! Thread 0x00000238 (most recent call first): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\popen_spawn_win32.py", line 80 in wait File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\process.py", line 140 in join File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 2128 in join_thread File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\_test_multiprocessing.py", line 83 in join_process File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\_test_multiprocessing.py", line 740 in test_sys_exit File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 615 in run File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 663 in __call__ File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__ File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__ File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__ File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\runner.py", line 176 in run File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1861 in _run_suite File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1951 in run_unittest File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 175 in test_runner File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 176 in runtest_inner File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 130 in runtest File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest_mp.py", line 67 in run_tests_slave File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 517 in _main File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 510 in main File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 585 in main File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 46 in _main File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 50 in File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 85 in _run_code File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 193 in _run_module_as_main 0:47:21 [251/413/1] test_timeit passed -- running: test_concurrent_futures (159 sec) (...) 0:54:34 [295/413/1] test_tempfile passed -- running: test_mmap (238 sec) minkernel\crts\ucrt\src\appcrt\lowio\write.cpp(49) : Assertion failed: (_osfile(fh) & FOPEN) 0:54:39 [296/413/2] test_configparser failed (env changed) -- running: test_mmap (243 sec) D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py:1000: RuntimeWarning: tests may fail, unable to create temporary directory 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\build\\build\\test_python_2876': [WinError 183] Cannot create a file when that file already exists: 'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\build\\build\\test_python_2876' with temp_dir(path=name, quiet=quiet) as temp_path: test_converters_at_init (test.test_configparser.BlatantOverrideConvertersTestCase) ... ok (...) test_write (test.test_configparser.StrictTestCase) ... ok ---------------------------------------------------------------------- Ran 341 tests in 3.745s OK (skipped=5) Warning -- files was modified by test_configparser Before: ['@test_2876_tmp'] After: [] ---------- components: Tests messages: 308398 nosy: vstinner priority: normal severity: normal status: open title: test_configparser left @test_2876_tmp temporary file on x86 Windows7 3.x versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 09:56:42 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 15 Dec 2017 14:56:42 +0000 Subject: [issue32332] Implement slots support for magic methods added in PEP 560 In-Reply-To: <1513320462.57.0.213398074469.issue32332@psf.upfronthosting.co.za> Message-ID: <1513349802.58.0.213398074469.issue32332@psf.upfronthosting.co.za> Yury Selivanov added the comment: Serhiy, I've tested METH_STATIC approach and it works just fine. Thanks for pointing that out! I agree that adding slots for something that's already possible is an overkill, so let's close this issue. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 10:00:39 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 15:00:39 +0000 Subject: [issue32329] PYTHONHASHSEED=0 python3 -R should enable hash randomization In-Reply-To: <1513293080.01.0.213398074469.issue32329@psf.upfronthosting.co.za> Message-ID: <1513350039.11.0.213398074469.issue32329@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4780 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 10:03:09 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 15:03:09 +0000 Subject: [issue32294] test_semaphore_tracker() of test_multiprocessing_spawn fails with -W error In-Reply-To: <1513116814.7.0.213398074469.issue32294@psf.upfronthosting.co.za> Message-ID: <1513350189.46.0.213398074469.issue32294@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- keywords: +patch pull_requests: +4781 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 10:09:10 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 15:09:10 +0000 Subject: [issue32124] Document functions safe to be called before Py_Initialize() In-Reply-To: <1511529556.02.0.213398074469.issue32124@psf.upfronthosting.co.za> Message-ID: <1513350550.76.0.213398074469.issue32124@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 10:10:40 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 15:10:40 +0000 Subject: [issue32119] test_notify_all() of test_multiprocessing_forkserver failed on Python on x86 Tiger 3.6 with "ValueError: cannot convert float NaN to integer" In-Reply-To: <1511425966.52.0.213398074469.issue32119@psf.upfronthosting.co.za> Message-ID: <1513350640.23.0.213398074469.issue32119@psf.upfronthosting.co.za> STINNER Victor added the comment: I really have no clue on the root bug, and the bug only occurred once, so I choose to close it. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 10:12:36 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 15:12:36 +0000 Subject: [issue31971] idle_test: failures on x86 Windows7 3.x In-Reply-To: <1510068197.3.0.213398074469.issue31971@psf.upfronthosting.co.za> Message-ID: <1513350756.31.0.213398074469.issue31971@psf.upfronthosting.co.za> STINNER Victor added the comment: Terry: you proposed a fix, do you still want to write it? The buildbot didn't fail again since I reported the failure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 10:13:28 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 15:13:28 +0000 Subject: [issue31967] [Windows] test_distutils: fatal error LNK1158: cannot run 'rc.exe' In-Reply-To: <1510048403.67.0.213398074469.issue31967@psf.upfronthosting.co.za> Message-ID: <1513350808.71.0.213398074469.issue31967@psf.upfronthosting.co.za> STINNER Victor added the comment: The AMD64 Windows10 3.x buildbot: is green again, I close the issue. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 10:17:50 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 15:17:50 +0000 Subject: [issue31964] [3.4][3.5] pyexpat: compilaton of libexpat fails with: ISO C90 forbids mixed declarations and code In-Reply-To: <1510016984.72.0.213398074469.issue31964@psf.upfronthosting.co.za> Message-ID: <1513351070.13.0.213398074469.issue31964@psf.upfronthosting.co.za> STINNER Victor added the comment: The bug has been fixed by commit 8b11e8de7aedacfbbcc8c780f3c4097396f1d1a3 in Python 3.4 ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 10:28:02 2017 From: report at bugs.python.org (Anthony Sottile) Date: Fri, 15 Dec 2017 15:28:02 +0000 Subject: [issue31940] copystat on symlinks fails for alpine -- faulty lchmod implementation? In-Reply-To: <1509753073.77.0.213398074469.issue31940@psf.upfronthosting.co.za> Message-ID: <1513351682.08.0.213398074469.issue31940@psf.upfronthosting.co.za> Anthony Sottile added the comment: if I'm reading the manpage correctly: `readlink` tells the filename that the symlink points to. lchmod is concerned with setting the `stat` on the link itself (which only some platforms actually support) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 10:29:08 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 15:29:08 +0000 Subject: [issue32329] PYTHONHASHSEED=0 python3 -R should enable hash randomization In-Reply-To: <1513293080.01.0.213398074469.issue32329@psf.upfronthosting.co.za> Message-ID: <1513351748.93.0.213398074469.issue32329@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 642d67b4f25262889b43f91ad2a96ca0e37fd5a2 by Victor Stinner in branch 'master': bpo-32329: Add versionchanged to -R option doc (#4884) https://github.com/python/cpython/commit/642d67b4f25262889b43f91ad2a96ca0e37fd5a2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 10:29:26 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 15:29:26 +0000 Subject: [issue32294] test_semaphore_tracker() of test_multiprocessing_spawn fails with -W error In-Reply-To: <1513116814.7.0.213398074469.issue32294@psf.upfronthosting.co.za> Message-ID: <1513351766.12.0.213398074469.issue32294@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 9402c8367bf6ada1b84f620ad957750c33adbaf9 by Victor Stinner in branch 'master': bpo-32294: Fix multiprocessing test_semaphore_tracker() (#4885) https://github.com/python/cpython/commit/9402c8367bf6ada1b84f620ad957750c33adbaf9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 10:29:42 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Dec 2017 15:29:42 +0000 Subject: [issue32294] test_semaphore_tracker() of test_multiprocessing_spawn fails with -W error In-Reply-To: <1513116814.7.0.213398074469.issue32294@psf.upfronthosting.co.za> Message-ID: <1513351782.93.0.213398074469.issue32294@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4782 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 10:38:35 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 15:38:35 +0000 Subject: [issue32290] bolen-dmg-3.6: compilation failed with OSError: [Errno 23] Too many open files in system In-Reply-To: <1513093245.22.0.213398074469.issue32290@psf.upfronthosting.co.za> Message-ID: <1513352315.57.0.213398074469.issue32290@psf.upfronthosting.co.za> STINNER Victor added the comment: Another different failure on "bolen-dmg-3.x". I don't understand the "RuntimeError: command failed: make" error :-( http://buildbot.python.org/all/#/builders/69/builds/69 (...) gcc-4.0 -c -fno-strict-aliasing -Wsign-compare -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -I/Users/db3l/buildarea.dmg/bolen-dmg-3.x/build/dmg/libraries/usr/local/include -std=c99 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -IObjects -IInclude -IPython -I. -I/Users/db3l/buildarea.dmg/bolen-dmg-3.x/build/Include -isysroot /Developer/SDKs/MacOSX10.4u.sdk -DPy_BUILD_CORE -o Python/frozen.o /Users/db3l/buildarea.dmg/bolen-dmg-3.x/build/Python/frozen.c rm -f libpython3.7m.a ar rcs libpython3.7m.a Modules/getbuildinfo.o Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Parser/myreadline.o Parser/parsetok.o Parser/tokenizer.o Objects/abstract.o Objects/accu.o Objects/boolobject.o Objects/bytes_methods.o Objects/bytearrayobject.o Objects/bytesobject.o Objects/call.o Objects/cellobject.o Objects/classobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/odictobject.o Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o Objects/namespaceobject.o Objects/object.o Objects/obmalloc.o Objects/capsule.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/unicodeobject.o Objects/unicodectype.o Objects/weakrefobject.o Python/_warnings.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/ast_opt.o Python/bltinmodule.o Python/ceval.o Python/compile.o Python/codecs.o Python/dynamic_annotations.o Python/errors.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/import.o Python/importdl.o Python/marshal.o Python/modsupport.o Python/mysnprintf.o Python/mystrtoul.o Python/pathconfig.o Python/peephole.o Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pyhash.o Python/pylifecycle.o Python/pymath.o Python/pystate.o Python/pythonrun.o Python/pytime.o Python/bootstrap_hash.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/thread.o Python/traceback.o Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/pystrhex.o Python/dtoa.o Python/formatter_unicode.o Python/fileutils.o Python/dynload_shlib.o Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/pwdmodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/_weakref.o Modules/_functoolsmodule.o Modules/_operator.o Modules/_collectionsmodule.o Modules/itertoolsmodule.o Modules/atexitmodule.o Modules/signalmodule.o Modules/_stat.o Modules/timemodule.o Modules/_threadmodule.o Modules/_localemodule.o Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o Modules/zipimport.o Modules/faulthandler.o Modules/_tracemalloc.o Modules/hashtable.o Modules/symtablemodule.o Modules/xxsubtype.o Python/frozen.o /usr/bin/install -c -d -m 755 Python.framework/Versions/3.7 gcc-4.0 -o Python.framework/Versions/3.7/Python -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -L/Users/db3l/buildarea.dmg/bolen-dmg-3.x/build/dmg/libraries/usr/local/lib -dynamiclib \ -all_load libpython3.7m.a -Wl,-single_module \ -install_name /Library/Frameworks/Python.framework/Versions/3.7/Python \ -compatibility_version 3.7 \ -current_version 3.7 \ -framework CoreFoundation -ldl -framework CoreFoundation; Traceback (most recent call last): File "/Users/db3l/buildarea.dmg/bolen-dmg-3.x/build/Mac/BuildScript/build-installer.py", line 1659, in main() File "/Users/db3l/buildarea.dmg/bolen-dmg-3.x/build/Mac/BuildScript/build-installer.py", line 1612, in main buildPython() File "/Users/db3l/buildarea.dmg/bolen-dmg-3.x/build/Mac/BuildScript/build-installer.py", line 1162, in buildPython runCommand(make_cmd) File "/Users/db3l/buildarea.dmg/bolen-dmg-3.x/build/Mac/BuildScript/build-installer.py", line 532, in runCommand raise RuntimeError("command failed: %s"%(commandline,)) RuntimeError: command failed: make program finished with exit code 1 elapsedTime=1601.300462 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 10:41:14 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 15:41:14 +0000 Subject: [issue31940] copystat on symlinks fails for alpine -- faulty lchmod implementation? In-Reply-To: <1509753073.77.0.213398074469.issue31940@psf.upfronthosting.co.za> Message-ID: <1513352474.64.0.213398074469.issue31940@psf.upfronthosting.co.za> STINNER Victor added the comment: > if I'm reading the manpage correctly: `readlink` tells the filename that the symlink points to. lchmod is concerned with setting the `stat` on the link itself (which only some platforms actually support) Oops, my bad. Ignore my comment :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 10:41:41 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 15:41:41 +0000 Subject: [issue32329] PYTHONHASHSEED=0 python3 -R should enable hash randomization In-Reply-To: <1513293080.01.0.213398074469.issue32329@psf.upfronthosting.co.za> Message-ID: <1513352501.48.0.213398074469.issue32329@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 11:09:45 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 15 Dec 2017 16:09:45 +0000 Subject: [issue32333] test_smtplib: dangling threads on x86 Gentoo Non-Debug with X 3.x In-Reply-To: <1513348879.75.0.213398074469.issue32333@psf.upfronthosting.co.za> Message-ID: <1513354185.0.0.213398074469.issue32333@psf.upfronthosting.co.za> Change by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 11:15:09 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 15 Dec 2017 16:15:09 +0000 Subject: [issue31265] Remove doubly-linked list from C OrderedDict In-Reply-To: <1503483859.09.0.0369181186057.issue31265@psf.upfronthosting.co.za> Message-ID: <1513354509.21.0.213398074469.issue31265@psf.upfronthosting.co.za> Change by Raymond Hettinger : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 11:26:57 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 16:26:57 +0000 Subject: [issue32294] test_semaphore_tracker() of test_multiprocessing_spawn fails with -W error In-Reply-To: <1513116814.7.0.213398074469.issue32294@psf.upfronthosting.co.za> Message-ID: <1513355217.84.0.213398074469.issue32294@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 11:32:58 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 15 Dec 2017 16:32:58 +0000 Subject: [issue32331] apply SOCK_TYPE_MASK to socket.type on Linux In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513355578.27.0.213398074469.issue32331@psf.upfronthosting.co.za> Yury Selivanov added the comment: > You can easily work around your problem by replacing "sock.type == SOCK_STREAM" with "sock.type & SOCK_STREAM == SOCK_STREAM". Heh :) No, that would be a buggy code. Try this on your Linux box: (socket.SOCK_SEQPACKET & socket.SOCK_STREAM) == socket.SOCK_STREAM The _only_ way of checking socket type reliably is to explicitly reset SOCK_NONBLOCK and SOCK_CLOEXEC or to apply 0xF mask on Linux, and don't do that on other platforms. That's why I think it's important to fix this one way or another. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 11:38:52 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 15 Dec 2017 16:38:52 +0000 Subject: [issue32331] apply SOCK_TYPE_MASK to socket.type on Linux In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513355932.76.0.213398074469.issue32331@psf.upfronthosting.co.za> Yury Selivanov added the comment: On GH (https://github.com/python/cpython/pull/4877), Antoine wrote: > I agree with Victor: > it can't go into 3.6 > making the change in 3.7 is contentious > Can there be an other way to solve the issue? Can we for example keep socket.type as it is and add a utility function or a property reporting the "masked" type? I agree. Here's what I propose: 1. We don't touch `socket.type`. We don't know what kind of code exists out there and in what ways it will break. The ship has sailed to fix it. 2. We add `socket.SOCK_TYPE_MASK` (on Linux). 3. We fix `socket.__repr__` to correctly render type. Currently: >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM | socket.SOCK_NONBLOCK) >>> s What I want to see: 4. We add `socket.true_type` which will apply `SOCK_TYPE_MASK` and return a socket type that's safe to compare to `socket.SOCK_*` constants. Thoughts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 11:59:19 2017 From: report at bugs.python.org (Christian Heimes) Date: Fri, 15 Dec 2017 16:59:19 +0000 Subject: [issue32331] apply SOCK_TYPE_MASK to socket.type on Linux In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513357159.55.0.213398074469.issue32331@psf.upfronthosting.co.za> Christian Heimes added the comment: Should socket.true_type use getsockopt(fd, ...) to get the actual type? While we are talking about socket types, please have a look at #28134 . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 12:15:34 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Fri, 15 Dec 2017 17:15:34 +0000 Subject: [issue32320] Add default value support to collections.namedtuple() In-Reply-To: <1513241075.07.0.213398074469.issue32320@psf.upfronthosting.co.za> Message-ID: <1513358134.04.0.213398074469.issue32320@psf.upfronthosting.co.za> Change by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 12:22:11 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 15 Dec 2017 17:22:11 +0000 Subject: [issue17852] Built-in module _io can lose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1513358531.65.0.213398074469.issue17852@psf.upfronthosting.co.za> Neil Schemenauer added the comment: In the process of trying to write a test for this, I now realize that PR 4847 is not really a fix. If the underlying file gets closed during an earlier gc.collect() and not during shutdown, the extra flushing step is not going to help. So, using atexit is not really a fix. Maybe there is something else we can do, need to think about it more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 12:27:34 2017 From: report at bugs.python.org (Amit Ghadge) Date: Fri, 15 Dec 2017 17:27:34 +0000 Subject: [issue32335] Failed Python build on Fedora 27 Message-ID: <1513358854.45.0.213398074469.issue32335@psf.upfronthosting.co.za> New submission from Amit Ghadge : Hi, I'm try to build Python from source on Fedora 27 but it shows below message and build was failed, gcc -pthread -Xlinker -export-dynamic -o python Programs/python.o libpython3.7dm.a -lpthread -ldl -lutil -lm gcc -pthread -Xlinker -export-dynamic -o Programs/_testembed Programs/_testembed.o libpython3.7dm.a -lpthread -ldl -lutil -lm ./python -E -S -m sysconfig --generate-posix-vars ;\ if test $? -ne 0 ; then \ echo "generate-posix-vars failed" ; \ rm -f ./pybuilddir.txt ; \ exit 1 ; \ fi Traceback (most recent call last): File "", line 1141, in _install File "", line 1133, in _setup File "", line 1100, in _builtin_from_name ImportError: no built-in module named _thread Fatal Python error: initimport: importlib install failed Current thread 0x00007fefeacef600 (most recent call first): /bin/sh: line 5: 12806 Aborted (core dumped) ./python -E -S -m sysconfig --generate-posix-vars generate-posix-vars failed make: *** [Makefile:590: pybuilddir.txt] Error 1 ---------- messages: 308413 nosy: amitg-b14 priority: normal severity: normal status: open title: Failed Python build on Fedora 27 type: compile error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 12:30:01 2017 From: report at bugs.python.org (Amit Ghadge) Date: Fri, 15 Dec 2017 17:30:01 +0000 Subject: [issue32335] Failed Python build on Fedora 27 In-Reply-To: <1513358854.45.0.213398074469.issue32335@psf.upfronthosting.co.za> Message-ID: <1513359001.41.0.213398074469.issue32335@psf.upfronthosting.co.za> Amit Ghadge added the comment: After the some investigation, 1f06a680de465be0c24a78ea3b610053955daa99 PR was OK, a6a4dc816d68df04a7d592e0b6af8c7ecc4d4344 build failed but ./python run 88c60c9668f0aa732693517a60b851cc1dfce0cb build failed and same error comes after click ./python ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 12:32:22 2017 From: report at bugs.python.org (Amit Ghadge) Date: Fri, 15 Dec 2017 17:32:22 +0000 Subject: [issue32335] Failed Python build on Fedora 27 In-Reply-To: <1513358854.45.0.213398074469.issue32335@psf.upfronthosting.co.za> Message-ID: <1513359142.75.0.213398074469.issue32335@psf.upfronthosting.co.za> Amit Ghadge added the comment: My current git log is, Author: Victor Stinner Date: Fri Dec 15 16:29:24 2017 +0100 bpo-32294: Fix multiprocessing test_semaphore_tracker() (#4885) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 13:11:24 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 15 Dec 2017 18:11:24 +0000 Subject: [issue32336] Save OrderedDict import in argparse Message-ID: <1513361484.23.0.213398074469.issue32336@psf.upfronthosting.co.za> New submission from Raymond Hettinger : Since regular dicts are now ordered by default, the OrderedDict import is no longer necessary. Removing it will give a small boost to start-up time. ---------- assignee: bethard components: Library (Lib) messages: 308416 nosy: bethard, rhettinger priority: normal severity: normal status: open title: Save OrderedDict import in argparse type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 13:12:52 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 15 Dec 2017 18:12:52 +0000 Subject: [issue32336] Save OrderedDict import in argparse In-Reply-To: <1513361484.23.0.213398074469.issue32336@psf.upfronthosting.co.za> Message-ID: <1513361572.01.0.213398074469.issue32336@psf.upfronthosting.co.za> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +4783 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 13:14:10 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 15 Dec 2017 18:14:10 +0000 Subject: [issue32337] Dict order is now guaranteed, so add tests for it Message-ID: <1513361650.47.0.213398074469.issue32337@psf.upfronthosting.co.za> Change by Raymond Hettinger : ---------- assignee: rhettinger components: Tests nosy: rhettinger priority: normal severity: normal stage: needs patch status: open title: Dict order is now guaranteed, so add tests for it versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 13:16:07 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 18:16:07 +0000 Subject: [issue17852] Built-in module _io can lose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1513361767.02.0.213398074469.issue17852@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm not well known with GC, but if it be possible to call destructors in the reversed chronological order, this could help with this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 13:21:39 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 18:21:39 +0000 Subject: [issue32338] Save OrderedDict import in re Message-ID: <1513362099.11.0.213398074469.issue32338@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : Since regular dicts are now ordered by default, the OrderedDict import is no longer necessary. ---------- components: Library (Lib), Regular Expressions messages: 308418 nosy: ezio.melotti, mrabarnett, rhettinger, serhiy.storchaka priority: normal severity: normal status: open title: Save OrderedDict import in re type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 13:25:31 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 18:25:31 +0000 Subject: [issue32338] Save OrderedDict import in re In-Reply-To: <1513362099.11.0.213398074469.issue32338@psf.upfronthosting.co.za> Message-ID: <1513362331.87.0.213398074469.issue32338@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +4784 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 13:36:23 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 15 Dec 2017 18:36:23 +0000 Subject: [issue17852] Built-in module _io can lose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1513362983.74.0.213398074469.issue17852@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Using reversed chronological order would work in 99% of the cases probably but then you would have that rare case where it didn't work. So, I'm not too keen on that approach. I think this is a classic problem with finalization and GC, probably should do some actual reading of literature. One idea that occurs to me is that the underlying file object could keep a weakref to the higher level (e.g. buffer) objects. Then, if the underlying file gets closes, it could make sure to call flush on the higher level objects first. The weakref would ensure that a ref cycle is not created. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 13:42:17 2017 From: report at bugs.python.org (Brett Cannon) Date: Fri, 15 Dec 2017 18:42:17 +0000 Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7 In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za> Message-ID: <1513363337.74.0.213398074469.issue32248@psf.upfronthosting.co.za> Change by Brett Cannon : ---------- keywords: +patch pull_requests: +4785 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 14:00:53 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 19:00:53 +0000 Subject: [issue32339] Make the dict type used in csv.DictReader configurable Message-ID: <1513364453.6.0.213398074469.issue32339@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : Since 3.6 csv.DictReader emits OrderedDicts instead of regular dicts. Since regular dicts are ordered in 3.7, this is an overkill. It would be nice to add a configuration option for a return type. This is an easy issue. ---------- components: Library (Lib) keywords: easy messages: 308420 nosy: serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Make the dict type used in csv.DictReader configurable type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 14:01:19 2017 From: report at bugs.python.org (Nitish) Date: Fri, 15 Dec 2017 19:01:19 +0000 Subject: [issue17852] Built-in module _io can lose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1513364479.67.0.213398074469.issue17852@psf.upfronthosting.co.za> Change by Nitish : ---------- nosy: +nitishch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 14:16:50 2017 From: report at bugs.python.org (Mark Sapiro) Date: Fri, 15 Dec 2017 19:16:50 +0000 Subject: [issue32330] Email parser creates a message object that can't be flattened In-Reply-To: <1513297527.86.0.213398074469.issue32330@psf.upfronthosting.co.za> Message-ID: <1513365410.16.0.213398074469.issue32330@psf.upfronthosting.co.za> Mark Sapiro added the comment: > I do wonder where you are using the string version of messages :) Probably some places where we could use bytes, but one of the problem areas is where we save the content of a message held for moderation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 14:33:53 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 15 Dec 2017 19:33:53 +0000 Subject: [issue31971] idle_test: failures on x86 Windows7 3.x In-Reply-To: <1510068197.3.0.213398074469.issue31971@psf.upfronthosting.co.za> Message-ID: <1513366433.96.0.213398074469.issue31971@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I want to add the try-except here and in the few other places where a method is temporarily masked. One failure causing another strikes me a test code bug. I would like to hold off on adding 'hover', as it now seems to have been an idiosyncratic and temporary glitch on one buildbot. I cannot see anything different about this particular button state check. If 'hover' were needed here, so it would seem equally needed in several other places. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 14:46:47 2017 From: report at bugs.python.org (ikram) Date: Fri, 15 Dec 2017 19:46:47 +0000 Subject: [issue32340] ValueError: time data 'N/A' does not match format '%Y%m%d' Message-ID: <1513367207.62.0.213398074469.issue32340@psf.upfronthosting.co.za> New submission from ikram : Traceback (most recent call last): File "H:\Whatsapp_Xtract_V2.2_2012-11-17\whatsapp_xtract.py", line 2453, in main(sys.argv[1:]) File "H:\Whatsapp_Xtract_V2.2_2012-11-17\whatsapp_xtract.py", line 1921, in main linkimage = findfile ("IMG", y.media_size, y.local_url, date, 2) File "H:\Whatsapp_Xtract_V2.2_2012-11-17\whatsapp_xtract.py", line 1266, in findfile timestamptoday = int(str(time.mktime(datetime.datetime.strptime(date, "%Y%m%d").timetuple()))[:-2]) File "C:\Python27\lib\_strptime.py", line 332, in _strptime (data_string, format)) ValueError: time data 'N/A' does not match format '%Y%m%d' Press any key to continue . . . ---------- components: Windows messages: 308423 nosy: marki94, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: ValueError: time data 'N/A' does not match format '%Y%m%d' type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 15:16:28 2017 From: report at bugs.python.org (Nikolaus Rath) Date: Fri, 15 Dec 2017 20:16:28 +0000 Subject: [issue17852] Built-in module _io can lose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1513368988.1.0.213398074469.issue17852@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Given the apparent difficulties getting this right, how about not attempting to implicitly flush buffers in the finalizer at all? This means scripts relying on this will break, but in contrast to the current behavior they will break consistently so it's easy to find and fix the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 15:50:25 2017 From: report at bugs.python.org (Stefan Pochmann) Date: Fri, 15 Dec 2017 20:50:25 +0000 Subject: [issue32341] itertools "generators"? Message-ID: <1513371025.57.0.213398074469.issue32341@psf.upfronthosting.co.za> New submission from Stefan Pochmann : The itertools page https://docs.python.org/3.6/library/itertools.html says "Combinatoric generators:" above the table with product(), permutations(), etc. But as far as I understand, they're not generators and they don't produce generator iterators. I think the table title should be "Combinatoric iterators:" instead, in line with "Infinite Iterators:" and "Iterators terminating on the shortest input sequence:" of the two tables above it. Reference: https://docs.python.org/3/glossary.html#term-generator ---------- assignee: docs at python components: Documentation messages: 308425 nosy: Stefan Pochmann, docs at python priority: normal severity: normal status: open title: itertools "generators"? versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 15:59:22 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 15 Dec 2017 20:59:22 +0000 Subject: [issue32341] itertools "generators"? In-Reply-To: <1513371025.57.0.213398074469.issue32341@psf.upfronthosting.co.za> Message-ID: <1513371562.53.0.213398074469.issue32341@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The term is used in the generic sense rather than the sense of an actual type. That said, I don't mind changing "Combinatoric generators" to "Combinatoric iterators" for 3.6 and 3.7. Otherwise, this isn't worth the backport effort. ---------- assignee: docs at python -> rhettinger nosy: +rhettinger priority: normal -> low versions: -Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 16:11:48 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 15 Dec 2017 21:11:48 +0000 Subject: [issue32341] itertools "generators"? In-Reply-To: <1513371025.57.0.213398074469.issue32341@psf.upfronthosting.co.za> Message-ID: <1513372308.95.0.213398074469.issue32341@psf.upfronthosting.co.za> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +4786 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 16:18:45 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 21:18:45 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1513372725.71.0.213398074469.issue29240@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4787 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 16:23:00 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 21:23:00 +0000 Subject: [issue30416] constant folding opens compiler to quadratic time hashing In-Reply-To: <1495314097.2.0.680001526088.issue30416@psf.upfronthosting.co.za> Message-ID: <1513372980.89.0.213398074469.issue30416@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4788 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 16:23:01 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Dec 2017 21:23:01 +0000 Subject: [issue21074] Too aggressive constant folding In-Reply-To: <1395887196.57.0.903293210902.issue21074@psf.upfronthosting.co.za> Message-ID: <1513372981.01.0.00913614298617.issue21074@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4789 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 16:28:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Dec 2017 21:28:31 +0000 Subject: [issue32341] itertools "generators"? In-Reply-To: <1513371025.57.0.213398074469.issue32341@psf.upfronthosting.co.za> Message-ID: <1513373311.08.0.213398074469.issue32341@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4790 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 16:30:05 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 15 Dec 2017 21:30:05 +0000 Subject: [issue32341] itertools "generators"? In-Reply-To: <1513371025.57.0.213398074469.issue32341@psf.upfronthosting.co.za> Message-ID: <1513373405.82.0.213398074469.issue32341@psf.upfronthosting.co.za> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 16:34:40 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 15 Dec 2017 21:34:40 +0000 Subject: [issue32340] ValueError: time data 'N/A' does not match format '%Y%m%d' In-Reply-To: <1513367207.62.0.213398074469.issue32340@psf.upfronthosting.co.za> Message-ID: <1513373680.85.0.213398074469.issue32340@psf.upfronthosting.co.za> R. David Murray added the comment: This is not a bug in python. If it is your code contact the pyhon-list mailing for help. If you got whatsapp_xtract from somewhere else, contact that community with your questions. ---------- nosy: +r.david.murray resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 16:35:31 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 15 Dec 2017 21:35:31 +0000 Subject: [issue32337] Dict order is now guaranteed, so add tests and doc for it Message-ID: <1513373731.93.0.213398074469.issue32337@psf.upfronthosting.co.za> Change by Raymond Hettinger : ---------- title: Dict order is now guaranteed, so add tests for it -> Dict order is now guaranteed, so add tests and doc for it _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 16:39:13 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 21:39:13 +0000 Subject: [issue32342] safe_power(): CID 1426161: Integer handling issues (DIVIDE_BY_ZERO) Message-ID: <1513373952.98.0.213398074469.issue32342@psf.upfronthosting.co.za> New submission from STINNER Victor : Coverity found an issue in the commit 2e3f5701858d1fc04caedefdd9a8ea43810270d2 (bpo-30416). New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1426161: Integer handling issues (DIVIDE_BY_ZERO) /Python/ast_opt.c: 219 in safe_power() ________________________________________________________________________________________________________ *** CID 1426161: Integer handling issues (DIVIDE_BY_ZERO) /Python/ast_opt.c: 219 in safe_power() 213 if (PyLong_Check(v) && PyLong_Check(w) && Py_SIZE(v) && Py_SIZE(w) > 0) { 214 size_t vbits = _PyLong_NumBits(v); 215 size_t wbits = PyLong_AsSize_t(w); 216 if (vbits == (size_t)-1 || wbits == (size_t)-1) { 217 return NULL; 218 } >>> CID 1426161: Integer handling issues (DIVIDE_BY_ZERO) >>> In expression "128UL / wbits", division by expression "wbits" which may be zero has undefined behavior. 219 if (vbits > MAX_INT_SIZE / wbits) { 220 return NULL; 221 } 222 } 223 224 return PyNumber_Power(v, w, Py_None); ---------- components: Interpreter Core messages: 308428 nosy: serhiy.storchaka, vstinner priority: normal severity: normal status: open title: safe_power(): CID 1426161: Integer handling issues (DIVIDE_BY_ZERO) versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 16:43:37 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 21:43:37 +0000 Subject: [issue32342] safe_power(): CID 1426161: Integer handling issues (DIVIDE_BY_ZERO) In-Reply-To: <1513373952.98.0.213398074469.issue32342@psf.upfronthosting.co.za> Message-ID: <1513374217.96.0.213398074469.issue32342@psf.upfronthosting.co.za> STINNER Victor added the comment: PyLong_AsSize_t(w) cannot be zero thanks to Py_SIZE(w) > 0. I classified the issue as a false positive. Sorry for the noise. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 16:43:46 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 15 Dec 2017 21:43:46 +0000 Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za> Message-ID: <1513374226.91.0.213398074469.issue20891@psf.upfronthosting.co.za> Change by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 17:06:23 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 15 Dec 2017 22:06:23 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1513375583.65.0.213398074469.issue29240@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset d2b02310acbfe6c978a8ad3cd3ac8b3f12927442 by Victor Stinner in branch 'master': bpo-29240: Don't define decode_locale() on macOS (#4895) https://github.com/python/cpython/commit/d2b02310acbfe6c978a8ad3cd3ac8b3f12927442 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 18:22:10 2017 From: report at bugs.python.org (Brett Cannon) Date: Fri, 15 Dec 2017 23:22:10 +0000 Subject: [issue32324] [Security] "python3 directory" inserts "directory" at sys.path[0] even in isolated mode In-Reply-To: <1513267755.86.0.213398074469.issue32324@psf.upfronthosting.co.za> Message-ID: <1513380130.36.0.213398074469.issue32324@psf.upfronthosting.co.za> Brett Cannon added the comment: I vote that it has to work and it should be prepended. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 19:05:21 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 Dec 2017 00:05:21 +0000 Subject: [issue32331] Add socket.truetype property In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513382721.96.0.213398074469.issue32331@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- title: apply SOCK_TYPE_MASK to socket.type on Linux -> Add socket.truetype property _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 19:11:31 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 Dec 2017 00:11:31 +0000 Subject: [issue32331] Add socket.truetype property In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513383091.17.0.213398074469.issue32331@psf.upfronthosting.co.za> Yury Selivanov added the comment: Update: I've rewritten the PR from scratch. 1. SOCK_TYPE_MASK isn't exported on Linux. Therefore we will not export socket.SOCK_TYPE_MASK too. 2. I've added the new socket.truetype property. 3. When a socket is created without an FD, e.g. "socket.socket(family, type, proto)", we trust that the type of the socket is correct. It might contain extra flags on Linux, so we filter them out. 4. When a socket is created from an FD, e.g. with "socket.fromfd" or with "socket.socket(family, type, proto, FD)" we don't trust the type. So socket.truetype will call getsockopt(SOL_SOCKET, SO_TYPE) on the FD to ensure we have the correct socket type at hand. 5. Since Linux doesn't export SOCK_TYPE_MASK I decided to hardcode it in socketmodule.c. My reasoning: a/ It's highly unlikely that Linux will implement 5 more new socket types anytime soon, so 0xF should last for a *very* long time. b/ It's more likely than "a/" that they add a new flag like SOCK_CLOEXEC, in which case the "type & ~(SOCK_NONBLOCK | SOCK_CLOEXEC)" approach will fail. So given a/ and b/ I think it's safe to just use 0xF mask on Linux. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 19:21:50 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 Dec 2017 00:21:50 +0000 Subject: [issue28134] socket.socket(fileno=fd) does not work as documented In-Reply-To: <1473794011.65.0.923929152137.issue28134@psf.upfronthosting.co.za> Message-ID: <1513383710.74.0.213398074469.issue28134@psf.upfronthosting.co.za> Yury Selivanov added the comment: Let's quickly iterate over what's possible first: * It's possible to check the type of the FD using "getsockopt(SOL_SOCKET, SO_TYPE)" on all platforms. * It's possible to check family/proto of the FD using "getsockopt(SOL_SOCKET, SO_DOMAIN/SO_PROTOCOL)" on Linux. Given the above I propose the following: 1. Passing a wrong type can be considered as a serious error. SOCK_STREAM is fundamentally different from SOCK_DGRAM. Because we have a way to validate socket type on all platforms, I propose to do this validation when we create a socket from an FD, and raise an error if the passed socket type isn't correct. 2. When Python is running with '-X dev' (new dev mode added by Victor), I propose to also validate socket.family and socket.proto on Linux, and raise a RuntimeWarning when they don't match. ---------- nosy: +pitrou, vstinner, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 19:25:09 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Dec 2017 00:25:09 +0000 Subject: [issue32339] Make the dict type used in csv.DictReader configurable In-Reply-To: <1513364453.6.0.213398074469.issue32339@psf.upfronthosting.co.za> Message-ID: <1513383909.29.0.213398074469.issue32339@psf.upfronthosting.co.za> Raymond Hettinger added the comment: For csv.DictReader and collections.namedtuple._asdict, it might be cleaner to just deprecate the OrderedDict in favor of returning regular dict. I suspect that in these contexts, no one really wants an actual OrderedDict. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 19:29:41 2017 From: report at bugs.python.org (Brett Cannon) Date: Sat, 16 Dec 2017 00:29:41 +0000 Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7 In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za> Message-ID: <1513384181.75.0.213398074469.issue32248@psf.upfronthosting.co.za> Brett Cannon added the comment: New changeset 4ac5150e068a3a795ef00465f6dff51747b62b91 by Brett Cannon in branch 'master': bpo-32248: Implement importlib.abc.ResourceReader (GH-4892) https://github.com/python/cpython/commit/4ac5150e068a3a795ef00465f6dff51747b62b91 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 19:32:27 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 Dec 2017 00:32:27 +0000 Subject: [issue27456] asyncio: set TCP_NODELAY flag by default In-Reply-To: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> Message-ID: <1513384347.14.0.213398074469.issue27456@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset e796b2fe26f220107ac50667de6cc86c82b465e3 by Yury Selivanov in branch 'master': bpo-27456: Ensure TCP_NODELAY is set on linux (#4231) https://github.com/python/cpython/commit/e796b2fe26f220107ac50667de6cc86c82b465e3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 19:44:21 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 Dec 2017 00:44:21 +0000 Subject: [issue27456] asyncio: set TCP_NODELAY flag by default In-Reply-To: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> Message-ID: <1513385061.02.0.213398074469.issue27456@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- pull_requests: +4791 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 19:46:17 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 Dec 2017 00:46:17 +0000 Subject: [issue27456] asyncio: set TCP_NODELAY flag by default In-Reply-To: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> Message-ID: <1513385177.35.0.213398074469.issue27456@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- pull_requests: +4792 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 19:48:36 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 Dec 2017 00:48:36 +0000 Subject: [issue32331] Add socket.truetype property In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513385316.05.0.213398074469.issue32331@psf.upfronthosting.co.za> Yury Selivanov added the comment: Another name option: socket.realtype ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 19:59:40 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 16 Dec 2017 00:59:40 +0000 Subject: [issue31265] Remove doubly-linked list from C OrderedDict In-Reply-To: <1503483859.09.0.0369181186057.issue31265@psf.upfronthosting.co.za> Message-ID: <1513385980.31.0.213398074469.issue31265@psf.upfronthosting.co.za> STINNER Victor added the comment: Dividing the memory consumption by two is quite impressive. Raymond: Would you mind to explain why you close the issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 20:39:15 2017 From: report at bugs.python.org (INADA Naoki) Date: Sat, 16 Dec 2017 01:39:15 +0000 Subject: [issue31265] Remove doubly-linked list from C OrderedDict In-Reply-To: <1503483859.09.0.0369181186057.issue31265@psf.upfronthosting.co.za> Message-ID: <1513388355.27.0.213398074469.issue31265@psf.upfronthosting.co.za> INADA Naoki added the comment: Since normal dict preserves insertion order, OrderedDict usage will be decreased. So I don't think 2x memory consumption is big issue. BTW, functools.lru_cache uses custom doubly-linked list which is much memory inefficient. Rewriting it to use OrderedDict will reduce memory usage significantly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 20:42:10 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 16 Dec 2017 01:42:10 +0000 Subject: [issue31265] Remove doubly-linked list from C OrderedDict In-Reply-To: <1503483859.09.0.0369181186057.issue31265@psf.upfronthosting.co.za> Message-ID: <1513388530.91.0.213398074469.issue31265@psf.upfronthosting.co.za> STINNER Victor added the comment: Writing code compatible with Python older than 3.5 (like Python 2.7) requires to use OrderedDict. I expect that very few users will use "dict if sys.version_info >= (3, 6) else OrderedDict" to get an ordered dict. OrderedDict remains useful when you need the methods added by the OrderedDict type. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 21:53:12 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 Dec 2017 02:53:12 +0000 Subject: [issue27456] asyncio: set TCP_NODELAY flag by default In-Reply-To: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> Message-ID: <1513392792.09.0.213398074469.issue27456@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 572636d42566da8eb6e85d5b8164e9ed8860a255 by Yury Selivanov in branch '3.6': bpo-27456: Ensure TCP_NODELAY is set on linux (#4231) (#4898) https://github.com/python/cpython/commit/572636d42566da8eb6e85d5b8164e9ed8860a255 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 21:54:32 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 Dec 2017 02:54:32 +0000 Subject: [issue27456] asyncio: set TCP_NODELAY flag by default In-Reply-To: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> Message-ID: <1513392872.52.0.213398074469.issue27456@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 22:10:30 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 16 Dec 2017 03:10:30 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1513393830.61.0.213398074469.issue29240@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4793 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 22:10:30 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 16 Dec 2017 03:10:30 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513393830.82.0.00913614298617.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4794 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 22:19:31 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Sat, 16 Dec 2017 03:19:31 +0000 Subject: [issue32331] Add socket.truetype property In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513394371.25.0.213398074469.issue32331@psf.upfronthosting.co.za> Nathaniel Smith added the comment: I think the earliest open bug about this is bpo-21327. ---------- nosy: +njs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 22:37:02 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 Dec 2017 03:37:02 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1513395422.93.0.213398074469.issue32259@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I think generically changing 'iterable' to 'iterable/unpackable' is wrong and would engender more confusion than at present. Most uses of iteration have nothing to do with multiple assignment target unpacking. Some minimal examples resulting in "TypeError: 'int' object is not iterable", where this change would be wrong, include iter(1) sorted(1) for _ in 1: pass What might be reasonable is to wrap iter(source) in multiple assignment target code with (the C equivalent, if it exists, of) try-except and augment the message before re-raising. The addition could be something explicit like "and cannot be the source for multiple target assignment". --- Camion, Steven gave you excellent advice about playing around with simplified code. If you had split the multiple-operation error raising line, for term, dgts in terms_generator(expected_precision): into two simpler lines that each do less, for value in terms_generator(expected_precision): term, dgts = value you would have likely have spent much less time looking in the wrong place. Isolating possible exception sources is a very useful debugging tool. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 22:39:59 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 Dec 2017 03:39:59 +0000 Subject: [issue17972] inspect module docs omits many functions In-Reply-To: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za> Message-ID: <1513395599.95.0.213398074469.issue17972@psf.upfronthosting.co.za> Change by Terry J. Reedy : ---------- type: enhancement -> behavior versions: +Python 3.7 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 22:41:19 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 Dec 2017 03:41:19 +0000 Subject: [issue32331] Add socket.truetype property In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513395679.76.0.213398074469.issue32331@psf.upfronthosting.co.za> Yury Selivanov added the comment: I've been thinking a lot about this problem, and I'm really tempted to fix sock.type property: 1. The problem first appeared in Python 3.2. 2. Python 2.7 doesn't have this problem at all, and doesn't even export socket.SOCK_NONBLOCK. If we fix this in 3.7 it *will* actually help some poor souls with porting their network applications. 3. People use Python when they want a high-level portable language. This annoying Linux quirk makes it super hard to write correct socket code. 4. I can't actually come up with any decent Linux-only example of using this quirk of socket.type. Why would one check if sock.type has SOCK_NONBLOCK? And even if they check it, one call to sock.settimeout() will make sock.type information outdated and simply wrong. Let's just fix sock.type? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 22:41:50 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 Dec 2017 03:41:50 +0000 Subject: [issue32261] Online doc does not include inspect.classify_class_attrs In-Reply-To: <1512846881.17.0.213398074469.issue32261@psf.upfronthosting.co.za> Message-ID: <1513395710.78.0.213398074469.issue32261@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Perhaps this should be closed as a 1/10 duplicate of #17972. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 22:46:09 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 Dec 2017 03:46:09 +0000 Subject: [issue32331] Add socket.truetype property In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513395969.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Yury Selivanov added the comment: There's also a precedent of us breaking socket API. In Python < 3.6: sock = socket.socket() fd = sock.fileno() os.close(fd) sock.close() Everything works fine. In 3.6+: sock.close() # Will raise OSError uvloop broke on this during the beta period and I fixed the issue quickly. I don't remember seeing any complaints about this, so I suspect that this issue wasn't a big deal, people just fixed their code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 22:54:25 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 16 Dec 2017 03:54:25 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513396465.08.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 9454060e84a669dde63824d9e2fcaf295e34f687 by Victor Stinner in branch 'master': bpo-29240, bpo-32030: Py_Main() re-reads config if encoding changes (#4899) https://github.com/python/cpython/commit/9454060e84a669dde63824d9e2fcaf295e34f687 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 22:54:25 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 16 Dec 2017 03:54:25 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1513396465.27.0.912454111764.issue29240@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 9454060e84a669dde63824d9e2fcaf295e34f687 by Victor Stinner in branch 'master': bpo-29240, bpo-32030: Py_Main() re-reads config if encoding changes (#4899) https://github.com/python/cpython/commit/9454060e84a669dde63824d9e2fcaf295e34f687 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 22:57:44 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 Dec 2017 03:57:44 +0000 Subject: [issue32263] Template string docs refer to "normal %-based substitutions" In-Reply-To: <1512855398.42.0.213398074469.issue32263@psf.upfronthosting.co.za> Message-ID: <1513396664.79.0.213398074469.issue32263@psf.upfronthosting.co.za> Terry J. Reedy added the comment: https://github.com/python/cpython/commit/9f74deba784fc8781d13ed564f69c02ed7c331bb merged by Warsaw (last March). It removed the whole phrase, "Instead of the normal %-based substitutions," I think the other changes would be more worth backporting, (assuming correct for 3.6, which I believe they are) if anything is. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 23:17:11 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Sat, 16 Dec 2017 04:17:11 +0000 Subject: [issue32331] Add socket.truetype property In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513397831.78.0.213398074469.issue32331@psf.upfronthosting.co.za> Nathaniel Smith added the comment: I did a little digging. It's more complicated than just "on Linux, these show up in the socket type". Background: SOCK_NONBLOCK and SOCK_CLOEXEC are Linux-isms. The standard way to control blocking-ness and cloexec-ness is via ioctl/fcntl, and Linux supports that too. But as an extension, it also has these flags that can be passed as part of the socket type, which is nice because it lets you set the flag atomically at the time the socket is created, which is very important for CLOEXEC, and ... kinda pointless for NONBLOCK, but whatever, Linux supports it. Note that as far as Linux is concerned, this is just a sneaky way to smuggle an extra argument through the socket() call. The flags *do not become part of the socket type*. If you create a socket with type=SOCK_STREAM | SOCK_NONBLOCK, and then do getsockopt(SOL_SOCKET, SOCK_TYPE) on it, Linux reports that the socket's type is just SOCK_STREAM, *without* mentioning SOCK_NONBLOCK. One more important piece of background: Python's socket.type attribute doesn't really have any connection to the OS-level socket type. (This is part of what bpo-28134 is about.) Python just takes whatever value the user passed as the type= argument when calling socket(), and stashes it in an instance variable so it can be retrieved later. Okay, so what's going on with socket.type? Python gained support for SOCK_NONBLOCK and SOCK_CLOEXEC in commit b1c54967381062bccef7db574b8e84f48a0eca76 (bpo-7523), which mainly just exposed the constants, so that users could manually pass these in as part of the type= argument when creating the socket. However, it also made another change: it made it so that that whenever Python toggles the blocking state of the socket, it also toggles the SOCK_NONBLOCK bit in the Python-level variable that represents socket.type. Logically, this doesn't make any sense. As noted above, SOCK_NONBLOCK is never considered part of the socket type, on any operating system. And the function that is doing this doesn't even have anything to do with SOCK_NONBLOCK; it's actually using ioctl/fcntl, which is a totally unrelated mechanism for toggling blocking-ness. And it only does this on Linux (because only Linux *has* a SOCK_NONBLOCK bit to toggle), so this is kind of just introducing gratuitous brokenness. The one advantage of this is that it makes these two pieces of code consistent: # Version A s = socket.socket(type=socket.SOCK_STREAM | socket.SOCK_NONBLOCK) # Blindly returns what we passed to type=, even though it's # not the actual type: s.type # Version B s = socket.socket() s.setblocking(False) s.type This is a weird choice. Basically version A here is revealing a bug in how Python's type tracking works (s.type disagrees with s.getsockopt(SOL_SOCKET, SOL_TYPE)), that is only triggered if the user takes advantage of a rarely-used, non-portable feature. Then version B was written to intentionally introduce the same bug in a much more common case, I guess for consistency. But the bug is still non-portable. The only time SOCK_CLOEXEC shows up in socket.type is if the user explicitly passed it in their call to socket.socket(), which has been a no-op (except for its effect on socket.type) since PEP 446 made SOCK_CLOEXEC the default. I think there's a pretty strong argument here that what we really ought to do is *never* show SOCK_NONBLOCK or SOCK_CLOEXEC in in socket.type. That's what Linux itself does, it's the only possibility on every other OS, and it fixes this very annoying issue. (To add to Yury's comments about bugs in asycnio, it took me ages to figure out wtf was going on here and work around it in trio. The current behavior really does cause bugs.) It also sets the stage for fixing bpo-28134 -- right now socket.type's semantics are "whatever you passed in, whether that's actually the socket's type or not", and that's something that's impossible to determine reliably for a bare fd; I'm suggesting they should become "the socket's type", which *is* possible to determine reliably for a bare fd, at least in some cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 23:25:52 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Sat, 16 Dec 2017 04:25:52 +0000 Subject: [issue32331] Add socket.truetype property In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513398352.92.0.213398074469.issue32331@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Re-reading my above post, I realized I want to emphasize a little more how odd the current relationship is between socket.type and SOCK_CLOEXEC. Right now, the way it works is: Python *always* adds SOCK_CLOEXEC to the type that it passes to the operating system when creating a socket. You can later toggle this with socket.set_inheritable, and check it with socket.get_inheritable. You might expect that you could also check it with (socket.type | SOCK_CLOEXEC), and this does tell you *something*... but it has *no relationship at all* to whether the socket has close-on-exec enabled. Instead, what it tells you whether you passed SOCK_CLOEXEC to the socket constructor. Given that passing SOCK_CLOEXEC to the socket constructor is otherwise *completely ignored*, this seems like a weird piece of information to make available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 23:48:19 2017 From: report at bugs.python.org (Kirit Sankar Gupta) Date: Sat, 16 Dec 2017 04:48:19 +0000 Subject: [issue32343] Leak Sanitizer reports memory leaks while building using ASAN Message-ID: <1513399699.11.0.213398074469.issue32343@psf.upfronthosting.co.za> New submission from Kirit Sankar Gupta : ./python -E -S -m sysconfig --generate-posix-vars ;\ if test $? -ne 0 ; then \ echo "generate-posix-vars failed" ; \ rm -f ./pybuilddir.txt ; \ exit 1 ; \ fi ================================================================= ==12061==ERROR: LeakSanitizer: detected memory leaks Direct leak of 287665 byte(s) in 116 object(s) allocated from: #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0) #1 0x6411a9 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12 #2 0x6411a9 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560 #3 0x6462c7 in PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:616:12 Direct leak of 5096 byte(s) in 9 object(s) allocated from: #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0) #1 0x6411a9 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12 #2 0x6411a9 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560 #3 0x6462c7 in PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:616:12 #4 0x9786dd in _PyObject_GC_Malloc /home/ksg/cpython/Modules/gcmodule.c:1713:12 #5 0x9786dd in _PyObject_GC_NewVar /home/ksg/cpython/Modules/gcmodule.c:1742 Direct leak of 2746 byte(s) in 3 object(s) allocated from: #0 0x4efdd5 in realloc (/home/ksg/cpython/python+0x4efdd5) #1 0x641828 in PyMem_RawRealloc /home/ksg/cpython/Objects/obmalloc.c:521:12 #2 0x641828 in _PyObject_Realloc /home/ksg/cpython/Objects/obmalloc.c:1905 #3 0x6463fd in PyObject_Realloc /home/ksg/cpython/Objects/obmalloc.c:634:12 Direct leak of 591 byte(s) in 1 object(s) allocated from: #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0) #1 0x6411a9 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12 #2 0x6411a9 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560 #3 0x6462c7 in PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:616:12 #4 0x8dace5 in r_object /home/ksg/cpython/Python/marshal.c:1392:20 #5 0x8d8780 in r_object /home/ksg/cpython/Python/marshal.c:1224:18 #6 0x8dad1c in r_object /home/ksg/cpython/Python/marshal.c:1395:22 #7 0x8d8780 in r_object /home/ksg/cpython/Python/marshal.c:1224:18 #8 0x8dad1c in r_object /home/ksg/cpython/Python/marshal.c:1395:22 #9 0x8d3e1d in PyMarshal_ReadObjectFromString /home/ksg/cpython/Python/marshal.c:1598:14 #10 0x8bffa6 in get_frozen_object /home/ksg/cpython/Python/import.c:1258:12 #11 0x8bffa6 in _imp_get_frozen_object_impl /home/ksg/cpython/Python/import.c:2018 #12 0x8bffa6 in _imp_get_frozen_object /home/ksg/cpython/Python/clinic/import.c.h:176 #13 0x568e15 in _PyMethodDef_RawFastCallDict /home/ksg/cpython/Objects/call.c:497:18 #14 0x56772b in _PyCFunction_FastCallDict /home/ksg/cpython/Objects/call.c:582:14 #15 0x56772b in PyCFunction_Call /home/ksg/cpython/Objects/call.c:787 Direct leak of 560 byte(s) in 1 object(s) allocated from: #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0) #1 0x641900 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12 #2 0x641900 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560 #3 0x641900 in pymalloc_realloc /home/ksg/cpython/Objects/obmalloc.c:1882 #4 0x641900 in _PyObject_Realloc /home/ksg/cpython/Objects/obmalloc.c:1901 #5 0x6463fd in PyObject_Realloc /home/ksg/cpython/Objects/obmalloc.c:634:12 Direct leak of 2 byte(s) in 2 object(s) allocated from: #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0) #1 0x6411a9 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12 #2 0x6411a9 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560 #3 0x645e07 in PyMem_Malloc /home/ksg/cpython/Objects/obmalloc.c:536:12 Indirect leak of 28768 byte(s) in 31 object(s) allocated from: #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0) #1 0x6411a9 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12 #2 0x6411a9 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560 #3 0x6462c7 in PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:616:12 #4 0x67ab2a in PyType_GenericAlloc /home/ksg/cpython/Objects/typeobject.c:969:15 Indirect leak of 8028 byte(s) in 8 object(s) allocated from: #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0) #1 0x6411a9 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12 #2 0x6411a9 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560 #3 0x6462c7 in PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:616:12 Indirect leak of 2571 byte(s) in 2 object(s) allocated from: #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0) #1 0x6411a9 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12 #2 0x6411a9 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560 #3 0x6462c7 in PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:616:12 #4 0x68d0b6 in type_call /home/ksg/cpython/Objects/typeobject.c:928:11 #5 0x569c86 in _PyMethodDef_RawFastCallKeywords /home/ksg/cpython/Objects/call.c:656:18 Indirect leak of 2096 byte(s) in 3 object(s) allocated from: #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0) #1 0x6411a9 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12 #2 0x6411a9 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560 #3 0x6462c7 in PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:616:12 #4 0x9786dd in _PyObject_GC_Malloc /home/ksg/cpython/Modules/gcmodule.c:1713:12 #5 0x9786dd in _PyObject_GC_NewVar /home/ksg/cpython/Modules/gcmodule.c:1742 Indirect leak of 632 byte(s) in 1 object(s) allocated from: #0 0x4ef9b0 in malloc (/home/ksg/cpython/python+0x4ef9b0) #1 0x641900 in PyMem_RawMalloc /home/ksg/cpython/Objects/obmalloc.c:503:12 #2 0x641900 in _PyObject_Malloc /home/ksg/cpython/Objects/obmalloc.c:1560 #3 0x641900 in pymalloc_realloc /home/ksg/cpython/Objects/obmalloc.c:1882 #4 0x641900 in _PyObject_Realloc /home/ksg/cpython/Objects/obmalloc.c:1901 #5 0x6463fd in PyObject_Realloc /home/ksg/cpython/Objects/obmalloc.c:634:12 SUMMARY: AddressSanitizer: 338755 byte(s) leaked in 177 allocation(s). generate-posix-vars failed Makefile:589: recipe for target 'pybuilddir.txt' failed make: *** [pybuilddir.txt] Error 1 ---------- components: Build messages: 308452 nosy: kirit1193 priority: normal severity: normal status: open title: Leak Sanitizer reports memory leaks while building using ASAN versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 15 23:50:42 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 Dec 2017 04:50:42 +0000 Subject: [issue32331] Fix socket.type on Linux In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513399842.98.0.213398074469.issue32331@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- title: Add socket.truetype property -> Fix socket.type on Linux _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 00:10:15 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 Dec 2017 05:10:15 +0000 Subject: [issue32315] can't run any scripts with 2.7.x, 32 and 64-bit In-Reply-To: <1513203071.76.0.213398074469.issue32315@psf.upfronthosting.co.za> Message-ID: <1513401015.65.0.213398074469.issue32315@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Your posted code and much else runs fine for me with 2.7.14 on Win 10. Millions of lines of legal Python code run on perhaps a million machines aroung the world. Except possibly for your particular machine, your conclusion is wrong. >From the traceback, you are running code via IDLE, most likely from the editor. Please specify exactly what you do to get the error, starting with which 2.7.z patch release you are using. When current Python and IDLE are correctly installed, PyShell.use_subprocess is set to True nearly first thing on startup. If one starts IDLE with the '-n' option, use_subprocess is set to False. The variable is never deleted. This is the first report I know of where Python sees use_subprocess as missing. Why? I can think of the following possibilities of what might be wrong on your machine: * Your python installation has a severe bug. If you need help with re-installing, try the python-list mailing list. * Hardware bug. See a tech. * You are using an obsolete version of 2.7 and ran into a bug since fixed. Upgrade to 2.7.14. * You have MacOS and ignored https://www.python.org/download/mac/tcltk/. Click Help and About IDLE and the box will include the tcl/tk version being run. Follow the instruction very carefully. None of the above are in scope for this tracker. * You somehow triggered a severe super-obscure bug. If you convince me that there might plausibly be a bug in IDLE, and agree to help investigate, I will try to find and fix it. For a start, run "python -m test" on a terminal or command line, where 'python' is the specific command to run 2.7 on your OS. ---------- status: -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 00:11:07 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 Dec 2017 05:11:07 +0000 Subject: [issue32315] can't run any scripts with 2.7.x, 32 and 64-bit In-Reply-To: <1513203071.76.0.213398074469.issue32315@psf.upfronthosting.co.za> Message-ID: <1513401067.47.0.213398074469.issue32315@psf.upfronthosting.co.za> Change by Terry J. Reedy : ---------- Removed message: https://bugs.python.org/msg308454 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 00:13:02 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 Dec 2017 05:13:02 +0000 Subject: [issue32331] Fix socket.type on Linux In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513401182.7.0.213398074469.issue32331@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nathaniel, thanks a lot for the comprehensive analysis. It's now obvious that this weird Linux-specific socket.type quirk is of our own making and specific only to Python. I've updated the PR: 1. *type* argument of 'socket.socket()' is passed as is to OS functions. It is now cleared of SOCK_NONBLOCK and SOCK_CLOEXEC on Linux. 2. socket.setblocking() no longer applies SOCK_NONBLOCK to socket.type. That's it. I'm now certain that this is the correct way of handling this situation. socket.type must be fixed. Please review the updated PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 00:23:01 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 16 Dec 2017 05:23:01 +0000 Subject: [issue32328] ttk.Treeview: _tkinter.TclError: list element in quotes followed by "; " instead of space In-Reply-To: <1513287304.34.0.213398074469.issue32328@psf.upfronthosting.co.za> Message-ID: <1513401781.92.0.213398074469.issue32328@psf.upfronthosting.co.za> Terry J. Reedy added the comment: With imports modified, same exceptions in 3.7.0a2 on Win10 ---------- nosy: +terry.reedy versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 02:19:57 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Dec 2017 07:19:57 +0000 Subject: [issue31265] Remove doubly-linked list from C OrderedDict In-Reply-To: <1503483859.09.0.0369181186057.issue31265@psf.upfronthosting.co.za> Message-ID: <1513408797.3.0.213398074469.issue31265@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Raymond: Would you mind to explain why you close the issue? On python-dev, Inada suggested he would drop this issue if Guido approved regular dicts having guaranteed order. That occurred and I closed this issue. The other reasons were listed earlier in this thread and on my python-dev post. Roughly, the OP is making the wrong trade-offs, trying to optimize what regular dicts are already good at. The OrderedDict aspires to be good at other things and to serve as an alternative to regular dicts in situations that aren't favorable to regular dicts. The OP seems to be infinitely persistent on this subject eventhough I've clearly stated that I do not approve of this going forward. No amount of talking seems to convince him of the merits of doubly linked list. In the LRU case, when the cache is large enough, there will be a high hit rate. With a doubly-linked list, all that is entailed is a single dict lookup for the link and a fast link update (all currently done in C with beautifully clean and efficient code). Without a doubly-linked list, we have to remove an element from the dictionary (leaving a hole), then re-add the element at the end and then periodically run and an O(n) compaction. The current design doesn't have any of that cost. The current ordered dict could run move_to_end() a billion times in succession and never trigger an O(n) resize or compaction. The OP either doesn't get this or doesn't care about what ordered dicts were actually designed to be good at. The current design was done on purpose. There were explicitly rejected alternatives. For example, we could have keep a regular dictionary augmented by a list, just appending and periodically compacting. This would have given faster iteration, less memory usage, and a simpler implementation; however, it was explicitly rejected because doubly-linked lists could gracefully handle frequent semi-random deletions, insertions, and moves-to-end points. For example, the compact dict would perform terribly for repeated move to front operations. When I get time over the holidays, I will build some examples where the proposed patch causes performance to crater. In the mean time, I have other important things to work on (documenting and testing the new dict guarantees, features for 3.7 before the freeze, etc). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 02:55:51 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Dec 2017 07:55:51 +0000 Subject: [issue32276] there is no way to make tempfile reproducible (i.e. seed the used RNG) In-Reply-To: <1513002327.33.0.213398074469.issue32276@psf.upfronthosting.co.za> Message-ID: <1513410951.32.0.213398074469.issue32276@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This seems ill-advised: * If a deterministic filename is needed, tempfile probably shouldn't be used. * Mock objects are typically used when alternative behavior is needed for testing. * The proposed feature would preclude a possible future development path to use SystemRandom which wouldn't be able to accept a seed. * Having the same filename used on successive runs will likely cause other problems. Generally, a user of tempname can assume that filename doesn't already exist and the proposed option would undermine that assumption. * I suspect if there were a real need here, we would have heard about it a long time ago. This module is over two decades old. ---------- components: +Library (Lib) versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 03:02:14 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Dec 2017 08:02:14 +0000 Subject: [issue29084] C API of OrderedDict In-Reply-To: <1482847157.79.0.799208161515.issue29084@psf.upfronthosting.co.za> Message-ID: <1513411334.49.0.213398074469.issue29084@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +4795 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 03:14:21 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Dec 2017 08:14:21 +0000 Subject: [issue31954] Don't prevent dict optimization by coupling with OrderedDict In-Reply-To: <1509961081.05.0.213398074469.issue31954@psf.upfronthosting.co.za> Message-ID: <1513412061.53.0.213398074469.issue31954@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please make a review Raymond? ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 03:26:57 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Dec 2017 08:26:57 +0000 Subject: [issue31954] Don't prevent dict optimization by coupling with OrderedDict In-Reply-To: <1509961081.05.0.213398074469.issue31954@psf.upfronthosting.co.za> Message-ID: <1513412817.24.0.213398074469.issue31954@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This looks reasonable to me. The previous design was too tightly coupled. The regular dict shouldn't have to care about the OrderedDict at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 03:28:39 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Dec 2017 08:28:39 +0000 Subject: [issue32276] there is no way to make tempfile reproducible (i.e. seed the used RNG) In-Reply-To: <1513002327.33.0.213398074469.issue32276@psf.upfronthosting.co.za> Message-ID: <1513412919.34.0.213398074469.issue32276@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I concur with Raymond. Monkey patching the tempfile module looks the right solution of this uncommon problem. ---------- nosy: +serhiy.storchaka resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 03:32:11 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Dec 2017 08:32:11 +0000 Subject: [issue31954] Don't prevent dict optimization by coupling with OrderedDict In-Reply-To: <1509961081.05.0.213398074469.issue31954@psf.upfronthosting.co.za> Message-ID: <1513413131.31.0.213398074469.issue31954@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: But this increases the size of regular dicts. Is it appropriate? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 03:37:05 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Dec 2017 08:37:05 +0000 Subject: [issue29084] C API of OrderedDict In-Reply-To: <1482847157.79.0.799208161515.issue29084@psf.upfronthosting.co.za> Message-ID: <1513413425.08.0.213398074469.issue29084@psf.upfronthosting.co.za> Raymond Hettinger added the comment: With today's announcement of guaranteed ordering for regular dicts, OrderedDict just became much less important (almost insignificant). Also, the original reason for having this C API no longer applies. There is a reasonable case to be made for removing the API entirely (given that it was never documented, that it is buggy, and that it is no longer of any significance). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 03:44:00 2017 From: report at bugs.python.org (Martin) Date: Sat, 16 Dec 2017 08:44:00 +0000 Subject: [issue32315] can't run any scripts with 2.7.x, 32 and 64-bit In-Reply-To: <1513203071.76.0.213398074469.issue32315@psf.upfronthosting.co.za> Message-ID: <1513413840.1.0.213398074469.issue32315@psf.upfronthosting.co.za> Martin added the comment: I used Python on other machines, I know how it's supposed to work. I'm using Windows 7 and this problem happened with 2.7.14, 2.7.13 and 2.7.9. I didn't bother trying all other versions because it looked like it didn't matter what version it was. For every version, I was running scripts with PyShell file (59 KB) from idlelib. I found another two files called "idle" in idlelib, one with and other without console. Either of those when ran starts Shell window and I can run scripts perfectly fine from there. I don't know what the problem is with PyShell file, but since with idle files it works as expected, I won't chase the cause of this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 03:47:00 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Dec 2017 08:47:00 +0000 Subject: [issue31954] Don't prevent dict optimization by coupling with OrderedDict In-Reply-To: <1509961081.05.0.213398074469.issue31954@psf.upfronthosting.co.za> Message-ID: <1513414020.73.0.213398074469.issue31954@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I also have misgivings about the extra field. Perhaps solicit some other opinions about whether the trade-off is worth it. Maybe Tim can provide an insight. My suspicion is that the current tight coupling is going to cost us in other ways. The OrderedDict is now less important than ever, so we really don't want regular dicts to have to pay any price just for the convenience of OrderedDict. ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 03:51:23 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 16 Dec 2017 08:51:23 +0000 Subject: [issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C" In-Reply-To: <1510310872.23.0.213398074469.issue32002@psf.upfronthosting.co.za> Message-ID: <1513414283.8.0.213398074469.issue32002@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset 9c19b020249c451891affd81751947321a1e6957 by Nick Coghlan in branch 'master': bpo-32002: Refactor C locale coercion tests (GH-4369) https://github.com/python/cpython/commit/9c19b020249c451891affd81751947321a1e6957 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 04:04:09 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Dec 2017 09:04:09 +0000 Subject: [issue32344] Explore whether peephole.c tuple of constants folding can be an AST transformation Message-ID: <1513415049.96.0.213398074469.issue32344@psf.upfronthosting.co.za> New submission from Raymond Hettinger : Can the peephole optimizer's fold_tuple_on_constants() be moved to ast_opt? It looks to me like there is sufficient information in the tree: import ast print(ast.dump(ast.parse('c = (50+1, 60+2)'))) ----------------------------------------------- Module(body=[Assign(targets=[Name(id='c', ctx=Store())], value=Tuple(elts=[BinOp(left=Num(n=50), op=Add(), right=Num(n=1)), BinOp(left=Num(n=60), op=Add(), right=Num(n=2))], ctx=Load()))], docstring=None) ''' ---------- assignee: serhiy.storchaka components: Interpreter Core messages: 308467 nosy: inada.naoki, rhettinger, serhiy.storchaka, vstinner priority: low severity: normal status: open title: Explore whether peephole.c tuple of constants folding can be an AST transformation versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 04:14:51 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 16 Dec 2017 09:14:51 +0000 Subject: [issue32321] functools.reduce has a redundant guard or needs a pure Python fallback In-Reply-To: <1513257994.59.0.213398074469.issue32321@psf.upfronthosting.co.za> Message-ID: <1513415691.13.0.213398074469.issue32321@psf.upfronthosting.co.za> Change by Raymond Hettinger : ---------- assignee: -> ncoghlan nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 04:28:32 2017 From: report at bugs.python.org (Creideiki) Date: Sat, 16 Dec 2017 09:28:32 +0000 Subject: [issue32345] EIO from write() is only fatal if print() contains a newline Message-ID: <1513416512.67.0.213398074469.issue32345@psf.upfronthosting.co.za> New submission from Creideiki : This is Python 2.7.14 on Gentoo Linux. I ran into an issue where a program crashes if I run it from a terminal, put it in the background, and then close the terminal too soon. Upstream bug report: https://github.com/micahflee/torbrowser-launcher/issues/298 It seems the cause is that a print() call without a newline ignores the EIO returned by the write() syscall, but if there is a newline in the string, that EIO is suddenly a fatal error. Reproducer: $ cat fatal.py #!/bin/env python2.7 import time time.sleep(5) print('A') print('B\nC') print('D') Run this program in the background under strace to see what it does, and while it is sleeping, close its controlling terminal: $ strace -s 256 -o fatal.log -f ./fatal.py & [1] 17974 ^d Now look at the strace log: $ grep write fatal.log 17978 write(1, "A\n", 2) = -1 EIO (Input/output error) 17978 write(1, "B\n", 2) = -1 EIO (Input/output error) 17978 write(2, "Traceback (most recent call last):\n", 35) = -1 EIO (Input/output error) 17978 write(2, " File \"./fatal.py\", line 5, in \n", 41) = -1 EIO (Input/output error) 17978 write(2, " ", 4) = -1 EIO (Input/output error) 17978 write(2, "print('B\\nC')\n", 14) = -1 EIO (Input/output error) 17978 write(2, "IOError", 7) = -1 EIO (Input/output error) 17978 write(2, ": ", 2) = -1 EIO (Input/output error) 17978 write(2, "[Errno 5] Input/output error", 28) = -1 EIO (Input/output error) 17978 write(2, "\n", 1) = -1 EIO (Input/output error) The first print('A') ran and had an EIO error, which was ignored. The second print('B\nC') tried to write 'B', had an EIO error, and crashed. The third print('D') was never attempted. ---------- components: IO messages: 308468 nosy: Creideiki priority: normal severity: normal status: open title: EIO from write() is only fatal if print() contains a newline versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 04:51:39 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Dec 2017 09:51:39 +0000 Subject: [issue32344] Explore whether peephole.c tuple of constants folding can be an AST transformation In-Reply-To: <1513415049.96.0.213398074469.issue32344@psf.upfronthosting.co.za> Message-ID: <1513417899.13.0.213398074469.issue32344@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Tuples represented in AST already are optimized at AST level. But there are tuples created at compilation stage (see the code emitting BUILD_TUPLE). Inada's PR 4879 simplifies the peephole optimizer. I tried to move this optimization at the compiler level, but it is more complex change. Making this change can have additional advantages, but is just more complex. I think at end all remaining peephole optimizations will be moved to the compiler, so that it will generate already optimized code. Many optimizations had already moved, and I have yet few unfinished patches. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 05:18:21 2017 From: report at bugs.python.org (Segev Finer) Date: Sat, 16 Dec 2017 10:18:21 +0000 Subject: [issue19764] subprocess: use PROC_THREAD_ATTRIBUTE_HANDLE_LIST with STARTUPINFOEX on Windows Vista In-Reply-To: <1385370115.99.0.757096187315.issue19764@psf.upfronthosting.co.za> Message-ID: <1513419501.24.0.213398074469.issue19764@psf.upfronthosting.co.za> Segev Finer added the comment: The PR has been sitting there for quite a while now... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 05:44:10 2017 From: report at bugs.python.org (Julien Palard) Date: Sat, 16 Dec 2017 10:44:10 +0000 Subject: [issue32276] there is no way to make tempfile reproducible (i.e. seed the used RNG) In-Reply-To: <1513002327.33.0.213398074469.issue32276@psf.upfronthosting.co.za> Message-ID: <1513421050.76.0.213398074469.issue32276@psf.upfronthosting.co.za> Julien Palard added the comment: I concur with Raymond and Serhiy here, and monkeypatching tmpfile should not be that hard, maybe patching `tempfile._Random` with `partial(random.Random, seed)` if done soon enough? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 06:03:53 2017 From: report at bugs.python.org (Camion) Date: Sat, 16 Dec 2017 11:03:53 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1513422233.08.0.213398074469.issue32259@psf.upfronthosting.co.za> Camion added the comment: Jerry, I've been troubleshooting thing for 30 years and I'm quite experienced at it, and in the end I was perfectly able to manage this problem and solve this problem by myself. My point is not about my own difficulty to solve this problem, but about the fact that an information was lacking clarity in a language which claims that things must be told. You mention the fact that Steven suggested playing playing around with simplified code, but it's not what Steven suggested. Steven suggested to make the example simpler, and I replied him that this example was not chosen to describe the programming situation but illustrate the troubleshooting situation and provide a good way to show how a real situation might be problematic to analyse with this message - and Steven confirmed that he was also put out on a wrong track by this message. For sure, when you are an experienced programmer, you will develop a different way to understand this. My point is that it seems to go in contradiction with "Python's Zen". You suggest that I should have split the packing and the unpacking on two separate lines. Ok, but this is an easy suggestion to make _when you already know the cause of the problem_. Each language has it's programming culture and; Ok, I'm new here but I haven't seen any recommendation going in that direction. On the contrary all the sample code and course I have seen on that topic encourage young programmer not to use this practice - and I believe it would be simpler to find a way to adapt the error message to make things clear that such an error can also arise for unpacking reasons (whatever the way you word it), than to change the programming/training culture around python. I have been made multiple propositions to re-word this message, and Steven also made some. My last proposition was motivated by the idea of keeping the message short. Some other were longer. One might also write : "not iterable (this problem may sometimes arise from unpacking)" or something else. The point is that in many situation, the problem comes from a mismatching between the number of values packed and the number of destination positions for unpacking; and in this case, you have a ValueError message stating clearly what happens. Only in this case, when the fact that you had only one value and didn't see it, makes that you no longer have an iterable type - do you get a TypeError. And Ok, I agree with Serhiy that the type of exception is correct, but I believe that the whole situation is misleading and should be corrected. (I apologize for my long sentences : My mother tongue is french and it's not always easy for me to to make them short like you do in English XD ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 06:56:50 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Dec 2017 11:56:50 +0000 Subject: [issue31954] Don't prevent dict optimization by coupling with OrderedDict In-Reply-To: <1509961081.05.0.213398074469.issue31954@psf.upfronthosting.co.za> Message-ID: <1513425410.03.0.213398074469.issue31954@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4796 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 07:00:02 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Dec 2017 12:00:02 +0000 Subject: [issue31954] Don't prevent dict optimization by coupling with OrderedDict In-Reply-To: <1509961081.05.0.213398074469.issue31954@psf.upfronthosting.co.za> Message-ID: <1513425602.54.0.213398074469.issue31954@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PR 4901 implements Inada's idea about changing dk_lookup to an index. This decreases the size, but can have negative performance effect (I didn't make benchmarks). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 07:21:18 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 16 Dec 2017 12:21:18 +0000 Subject: [issue32346] Speed up slot lookup for class creation Message-ID: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za> New submission from Antoine Pitrou : As mentioned in https://mail.python.org/pipermail/python-dev/2017-December/151298.html, slot lookup can take 75 to 80% of the runtime when creating a new class. This was slightly improved in https://bugs.python.org/issue31336 but we're still doing one lookup per possible slot name *and* per class along the MRO. I propose to speed up this step by caching the known descriptors for each class. This way, when instantiating a new class, you can simply iterate over the known descriptors of the MRO without wasting time on hundreds of dict lookups. (and it is reasonably easy to find all slot descriptors in a dict: first select only __dunder__ names, then look them up in a dedicated mapping) ---------- components: Interpreter Core messages: 308474 nosy: pitrou, scoder, serhiy.storchaka priority: normal severity: normal status: open title: Speed up slot lookup for class creation type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 07:24:09 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 16 Dec 2017 12:24:09 +0000 Subject: [issue32346] Speed up slot lookup for class creation In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za> Message-ID: <1513427049.21.0.213398074469.issue32346@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- keywords: +patch pull_requests: +4797 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 07:26:38 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 16 Dec 2017 12:26:38 +0000 Subject: [issue32346] Speed up slot lookup for class creation In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za> Message-ID: <1513427198.0.0.213398074469.issue32346@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I posted https://github.com/python/cpython/pull/4902 for this. This approach has two drawbacks: - uses an additional tp_ slot (and a corresponding TPFLAGS) - adds a bit of code complexity (but quite localized) ---------- stage: patch review -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 07:31:15 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Dec 2017 12:31:15 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1513427475.54.0.213398074469.issue32259@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4798 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 07:32:04 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 16 Dec 2017 12:32:04 +0000 Subject: [issue32346] Speed up slot lookup for class creation In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za> Message-ID: <1513427524.75.0.213398074469.issue32346@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Some micro-benchmarks: $ ./python -m timeit "class Test: pass" - before: 8.84 usec per loop - after: 7.03 usec per loop $ ./python -m timeit "class Test(tuple): pass" - before: 10.1 usec per loop - after: 8.4 usec per loop $ ./python -m timeit -s "from logging import Logger" "class Test(Logger): pass" - before: 12 usec per loop - after: 6.25 usec per loop $ ./python -m timeit -s "from logging.handlers import DatagramHandler" "class Test(DatagramHandler): pass" - before: 15 usec per loop - after: 6.68 usec per loop $ ./python -m timeit -s "from unittest.mock import MagicMock" "class Test(MagicMock): pass" - before: 18.2 usec per loop - after: 6.56 usec per loop $ ./python -m timeit -s "from shelve import Shelf" "class Test(Shelf): pass" - before: 28.6 usec per loop - after: 18.4 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 07:32:32 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 16 Dec 2017 12:32:32 +0000 Subject: [issue32346] Speed up slot lookup for class creation In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za> Message-ID: <1513427552.2.0.213398074469.issue32346@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 07:33:14 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Dec 2017 12:33:14 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1513427594.45.0.213398074469.issue32259@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PR 4903 makes the error message more specific for this case. >>> a, b = 1 Traceback (most recent call last): File "", line 1, in TypeError: cannot unpack int object I don't know whether it is worth to do this change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 08:34:53 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 16 Dec 2017 13:34:53 +0000 Subject: [issue32346] Speed up slot lookup for class creation In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za> Message-ID: <1513431293.01.0.213398074469.issue32346@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 09:01:52 2017 From: report at bugs.python.org (shangdahao) Date: Sat, 16 Dec 2017 14:01:52 +0000 Subject: [issue32339] Make the dict type used in csv.DictReader configurable In-Reply-To: <1513364453.6.0.213398074469.issue32339@psf.upfronthosting.co.za> Message-ID: <1513432912.82.0.213398074469.issue32339@psf.upfronthosting.co.za> Change by shangdahao : ---------- keywords: +patch pull_requests: +4799 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 11:33:41 2017 From: report at bugs.python.org (Steve Dower) Date: Sat, 16 Dec 2017 16:33:41 +0000 Subject: [issue32324] [Security] "python3 directory" inserts "directory" at sys.path[0] even in isolated mode In-Reply-To: <1513267755.86.0.213398074469.issue32324@psf.upfronthosting.co.za> Message-ID: <1513442021.27.0.213398074469.issue32324@psf.upfronthosting.co.za> Steve Dower added the comment: The more interesting part is the relative directory and how often is it resolved? Can you change a program's imports by inducing it to change its working directory immediately after startup (or before any lazy imports)? If so, we should resolve it to a full path when adding it, regardless of -I. Having the first entry there is required for local imports to work from the startup script, so I don't see it going anywhere. There have been many discussions about how to deal with the shadowing "problem", but the eventual answer was consenting adults. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 11:45:01 2017 From: report at bugs.python.org (Ryan Govostes) Date: Sat, 16 Dec 2017 16:45:01 +0000 Subject: [issue32347] System Integrity Protection breaks shutil.copystat() Message-ID: <1513442701.16.0.213398074469.issue32347@psf.upfronthosting.co.za> New submission from Ryan Govostes : On macOS, shutil.copystat() uses chflags() to try to copy filesystem flags from the source to destination. In recent years, Apple introduced System Integrity Protection, which prevents modification of system files. These files have the non-standard SF_RESTRICTED flag set, which only the superuser can set. Thus, unprivileged users can no longer use shutil.copy2() et al. to copy system files, which is a regression from previous releases of the OS. It's unclear what the correct behavior should be: It some cases, it would be desirable to attempt to copy the bit. It might be informative to look at the behavior of Apple's `copyfile_stat` function, which unsets these two flags: /* * File flags that are not preserved when copying stat information. */ #define COPYFILE_OMIT_FLAGS (UF_TRACKED | SF_RESTRICTED) https://opensource.apple.com/source/copyfile/copyfile-146/copyfile.c.auto.html This was also filed to Apple as rdar://36090921 ---------- components: macOS messages: 308479 nosy: Ryan Govostes, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: System Integrity Protection breaks shutil.copystat() type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 14:58:40 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 16 Dec 2017 19:58:40 +0000 Subject: [issue32250] Add asyncio.current_task() and asyncio.all_tasks() funcitons In-Reply-To: <1512687842.07.0.213398074469.issue32250@psf.upfronthosting.co.za> Message-ID: <1513454320.54.0.213398074469.issue32250@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset 44d1a5912ea629aa20fdc377a5ab69d9ccf75d61 by Andrew Svetlov in branch 'master': bpo-32250: Implement asyncio.current_task() and asyncio.all_tasks() (#4799) https://github.com/python/cpython/commit/44d1a5912ea629aa20fdc377a5ab69d9ccf75d61 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 14:59:57 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 16 Dec 2017 19:59:57 +0000 Subject: [issue32250] Add asyncio.current_task() and asyncio.all_tasks() funcitons In-Reply-To: <1512687842.07.0.213398074469.issue32250@psf.upfronthosting.co.za> Message-ID: <1513454397.6.0.213398074469.issue32250@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- components: +Library (Lib) resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 16:47:46 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sat, 16 Dec 2017 21:47:46 +0000 Subject: [issue32226] Implement PEP 560: Core support for typing module and generic types In-Reply-To: <1512506292.69.0.213398074469.issue32226@psf.upfronthosting.co.za> Message-ID: <1513460866.13.0.213398074469.issue32226@psf.upfronthosting.co.za> Change by Ivan Levkivskyi : ---------- pull_requests: +4800 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 18:50:13 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 Dec 2017 23:50:13 +0000 Subject: [issue32348] Optimize asyncio.Future schedule/add/remove callback Message-ID: <1513468213.29.0.213398074469.issue32348@psf.upfronthosting.co.za> New submission from Yury Selivanov : Key observation: 99.9% of the time Futures and Tasks have only one callback. Currently we have a list of callbacks in each Future/Task. We can avoid list object allocation if we add a field to store the first callback. This way we'll only need to ever allocate the list if a Future/Task has more than one done callbacks. asyncio with the proposed patch applied shows that 3-6% better performance of an asyncio echo server implemented using asyncio.streams. This benchmark involves quite a bit of other Python code, so this improvement is actually quite significant. The patch consists of: 1. first callback / callbacks list refactoring. 2. a free list implementation for Future.__await__ objects (which are created on almost all awaits in asyncio). 3. a big cleanup of the code, ensuring that Future/Task are always initialized properly. ---------- assignee: yselivanov components: asyncio messages: 308481 nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Optimize asyncio.Future schedule/add/remove callback versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 18:52:37 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 16 Dec 2017 23:52:37 +0000 Subject: [issue32348] Optimize asyncio.Future schedule/add/remove callback In-Reply-To: <1513468213.29.0.213398074469.issue32348@psf.upfronthosting.co.za> Message-ID: <1513468357.12.0.213398074469.issue32348@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4801 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 20:13:48 2017 From: report at bugs.python.org (David Bolen) Date: Sun, 17 Dec 2017 01:13:48 +0000 Subject: [issue32264] move pygetopt.h into internal/ In-Reply-To: <1512857323.9.0.213398074469.issue32264@psf.upfronthosting.co.za> Message-ID: <1513473228.99.0.213398074469.issue32264@psf.upfronthosting.co.za> David Bolen added the comment: This commit appears to have broken OSX installer builds using the build-installer.py script (as in the last two attempts on the bolen-dmg-3.x builder), confirmed with a bisection from the first failing worker build (covering the range 02a0a19..3327a2d) It fails during the main python compilation with: ld: multiple definitions of symbol __PyOS_optarg libpython3.7m.a(getopt.o) definition of __PyOS_optarg in section (__DATA,__data) libpython3.7m.a(main.o) definition of __PyOS_optarg in section (__DATA,__common) ld: multiple definitions of symbol __PyOS_opterr (repeated for the various __PyOS__opt* symbols. It doesn't seem to be a problem with a simple manual configure/make build (probably why the regular OSX workers aren't failing). So best guess at the moment is it's related to one of the extra configure options used by the build-installer script. I'm not sure which of the commit or build process needs correction, although reverting this at least temporarily would resolve the immediate issue. ---------- nosy: +db3l, ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 16 21:03:44 2017 From: report at bugs.python.org (David Bolen) Date: Sun, 17 Dec 2017 02:03:44 +0000 Subject: [issue32264] move pygetopt.h into internal/ In-Reply-To: <1512857323.9.0.213398074469.issue32264@psf.upfronthosting.co.za> Message-ID: <1513476224.22.0.213398074469.issue32264@psf.upfronthosting.co.za> David Bolen added the comment: After some further testing, it does not appear to be configure related but something environmental (maybe MACOSX_DEPLOYMENT_TARGET) - using the same configure options manually as build-installer seems ok. For what it's worth, since there do appear to be duplicate definitions in pygetopt.h and getopt.c, adding "extern" to the declarations in pygetopt.h appears to resolve the issue. It looks like that was lost with the removal of PyAPI_DATA. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 00:29:21 2017 From: report at bugs.python.org (=?utf-8?b?7JaR7Jyg7ISd?=) Date: Sun, 17 Dec 2017 05:29:21 +0000 Subject: [issue32349] Add detailed return value information for set.intersection function Message-ID: <1513488561.11.0.213398074469.issue32349@psf.upfronthosting.co.za> New submission from ??? : I think it's intentional behavior seems to be minor though. At a glance, I assume that a.set(b) should return items in a. But I found out the implementation always return items in smaller set. There is no issue for common case, but custom class can make a trouble. So, I think additional information of return value is helpful. ---------- assignee: docs at python components: Documentation messages: 308484 nosy: docs at python, ??? priority: normal severity: normal status: open title: Add detailed return value information for set.intersection function type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 06:59:07 2017 From: report at bugs.python.org (Cutter) Date: Sun, 17 Dec 2017 11:59:07 +0000 Subject: [issue32350] pip can't handle MSVC warnings containing special characters Message-ID: <1513511947.07.0.213398074469.issue32350@psf.upfronthosting.co.za> New submission from Cutter : When trying to install pylint using pip on Windows 10, the installation of wrapt (a dependency of pylint) fails because a special character in an MSVC warning can't be decoded to utf-8. Below is the relevant part of the console output: --- Exception: Traceback (most recent call last): File "C:\Users\(...)\AppData\Local\Programs\Python\Python36\lib\site-packages\pip\compat\__init__.py", line 73, in console_to_str return s.decode(sys.__stdout__.encoding) UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 51: invalid start byte During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\Users\(...)\AppData\Local\Programs\Python\Python36\lib\site-packages\pip\basecommand.py", line 215, in main status = self.run(options, args) File "C:\Users\(...)\AppData\Local\Programs\Python\Python36\lib\site-packages\pip\commands\install.py", line 342, in run prefix=options.prefix_path, File "C:\Users\(...)\AppData\Local\Programs\Python\Python36\lib\site-packages\pip\req\req_set.py", line 784, in install **kwargs File "C:\Users\(...)\AppData\Local\Programs\Python\Python36\lib\site-packages\pip\req\req_install.py", line 878, in install spinner=spinner, File "C:\Users\(...)\AppData\Local\Programs\Python\Python36\lib\site-packages\pip\utils\__init__.py", line 676, in call_subprocess line = console_to_str(proc.stdout.readline()) File "C:\Users\(...)\AppData\Local\Programs\Python\Python36\lib\site-packages\pip\compat\__init__.py", line 75, in console_to_str return s.decode('utf_8') UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 51: invalid start byte --- I changed line 73 in \pip\compat\__init__.py to: print("!! TEST !! : ", s). The full console output after that change is in the attachment. The relevant part is: !! TEST !! : b'C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.11.25503\\bin\\HostX86\\x64\\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MD -IC:\\Users\\(...)\\AppData\\Local\\Programs\\Python\\Python36\\include -IC:\\Users\\(...)\\AppData\\Local\\Programs\\Python\\Python36\\include "-IC:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.11.25503\\ATLMFC\\include" "-IC:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.11.25503\\include" "-IC:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.16299.0\\ucrt" "-IC:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.16299.0\\shared" "-IC:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.16299.0\\um" "-IC:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.16299.0\\winrt" /Tcsrc/wrapt/_wrappers.c /Fobuild\\temp.win-amd64-3.6\\Release\\src/wrapt/_wrappers.obj\r\n' !! TEST !! : b'_wrappers.c\r\n' !! TEST !! : b"src/wrapt/_wrappers.c(195): warning C4244: 'return'\xff: conversion de 'Py_hash_t' en 'long', perte possible de donn\x82es\r\n" error Exception: Traceback (most recent call last): File "C:\Users\(...)\AppData\Local\Programs\Python\Python36\Lib\site-packages\pip\compat\__init__.py", line 74, in console_to_str return s.decode(sys.__stdout__.encoding) UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 51: invalid start byte As a workaround I've changed the original line 73 in \pip\compat\__init__.py : return s.decode(sys.__stdout__.encoding) to: return s.decode(sys.__stdout__.encoding, "replace") (thanks to dieter on comp.lang.python for his help). I don't have the knowledge to propose a patch. ---------- components: Windows files: console.txt messages: 308485 nosy: Cutter, Marcus.Smith, dstufft, ncoghlan, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: pip can't handle MSVC warnings containing special characters type: crash versions: Python 3.6 Added file: https://bugs.python.org/file47334/console.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 07:17:26 2017 From: report at bugs.python.org (Paul Moore) Date: Sun, 17 Dec 2017 12:17:26 +0000 Subject: [issue32350] pip can't handle MSVC warnings containing special characters In-Reply-To: <1513511947.07.0.213398074469.issue32350@psf.upfronthosting.co.za> Message-ID: <1513513046.17.0.213398074469.issue32350@psf.upfronthosting.co.za> Paul Moore added the comment: This is a pip issue, not a Python issue. It's a known issue in the current version of pip, and should be fixed in the development version (via pull request https://github.com/pypa/pip/pull/4486). If you like, you can try the development version of pip. At the moment there is no planned date for the next release of pip, but we're hoping to put together a release in the not too distant future. ---------- assignee: -> paul.moore resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 07:22:02 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 17 Dec 2017 12:22:02 +0000 Subject: [issue32351] Use fastpath in asyncio.sleep if delay<0 Message-ID: <1513513322.7.0.213398074469.issue32351@psf.upfronthosting.co.za> New submission from Andrew Svetlov : Currently asyncio.sleep schedules a callback execution by `loop.call_later()` call, which has the same behavior but 2x slower. ---------- components: Library (Lib), asyncio messages: 308487 nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Use fastpath in asyncio.sleep if delay<0 versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 07:25:17 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 17 Dec 2017 12:25:17 +0000 Subject: [issue32351] Use fastpath in asyncio.sleep if delay<0 In-Reply-To: <1513513322.7.0.213398074469.issue32351@psf.upfronthosting.co.za> Message-ID: <1513513517.94.0.213398074469.issue32351@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- keywords: +patch pull_requests: +4802 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 08:47:09 2017 From: report at bugs.python.org (thautwarm) Date: Sun, 17 Dec 2017 13:47:09 +0000 Subject: [issue32352] `inspect.getfullargspec` doesn't work fine for some builtin callable objects Message-ID: <1513518429.74.0.213398074469.issue32352@psf.upfronthosting.co.za> New submission from thautwarm : It's quite confusing to me that `inspect.getfullargspec` crashed when it was applied on some builtin callable objects. ``` for each in __builtin__.__dict__: try: obj = getattr(__builtin__, each) if not callable(obj): continue inspect.getfullargspec(obj) except Exception as e: print(each, e) ``` Here are the results: ``` __build_class__ unsupported callable __import__ unsupported callable dir unsupported callable getattr unsupported callable iter unsupported callable max unsupported callable min unsupported callable next unsupported callable print unsupported callable round unsupported callable vars unsupported callable bool unsupported callable bytearray unsupported callable bytes unsupported callable classmethod unsupported callable complex unsupported callable dict unsupported callable enumerate unsupported callable filter unsupported callable float unsupported callable frozenset unsupported callable property unsupported callable int unsupported callable list unsupported callable map unsupported callable range unsupported callable reversed unsupported callable set unsupported callable slice unsupported callable staticmethod unsupported callable str unsupported callable super unsupported callable tuple unsupported callable type unsupported callable zip unsupported callable BaseException unsupported callable Exception unsupported callable TypeError unsupported callable StopAsyncIteration unsupported callable StopIteration unsupported callable GeneratorExit unsupported callable SystemExit unsupported callable KeyboardInterrupt unsupported callable ImportError unsupported callable ModuleNotFoundError unsupported callable OSError unsupported callable EnvironmentError unsupported callable IOError unsupported callable WindowsError unsupported callable EOFError unsupported callable RuntimeError unsupported callable RecursionError unsupported callable NotImplementedError unsupported callable NameError unsupported callable UnboundLocalError unsupported callable AttributeError unsupported callable SyntaxError unsupported callable IndentationError unsupported callable TabError unsupported callable LookupError unsupported callable IndexError unsupported callable KeyError unsupported callable ValueError unsupported callable UnicodeError unsupported callable UnicodeEncodeError unsupported callable UnicodeDecodeError unsupported callable UnicodeTranslateError unsupported callable AssertionError unsupported callable ArithmeticError unsupported callable FloatingPointError unsupported callable OverflowError unsupported callable ZeroDivisionError unsupported callable SystemError unsupported callable ReferenceError unsupported callable BufferError unsupported callable MemoryError unsupported callable Warning unsupported callable UserWarning unsupported callable DeprecationWarning unsupported callable PendingDeprecationWarning unsupported callable SyntaxWarning unsupported callable RuntimeWarning unsupported callable FutureWarning unsupported callable ImportWarning unsupported callable UnicodeWarning unsupported callable BytesWarning unsupported callable ResourceWarning unsupported callable ConnectionError unsupported callable BlockingIOError unsupported callable BrokenPipeError unsupported callable ChildProcessError unsupported callable ConnectionAbortedError unsupported callable ConnectionRefusedError unsupported callable ConnectionResetError unsupported callable FileExistsError unsupported callable FileNotFoundError unsupported callable IsADirectoryError unsupported callable NotADirectoryError unsupported callable InterruptedError unsupported callable PermissionError unsupported callable ProcessLookupError unsupported callable TimeoutError unsupported callable ``` ---------- components: Library (Lib) messages: 308488 nosy: thautwarm priority: normal severity: normal status: open title: `inspect.getfullargspec` doesn't work fine for some builtin callable objects type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 09:41:33 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 17 Dec 2017 14:41:33 +0000 Subject: [issue32351] Use fastpath in asyncio.sleep if delay<0 In-Reply-To: <1513513322.7.0.213398074469.issue32351@psf.upfronthosting.co.za> Message-ID: <1513521693.52.0.213398074469.issue32351@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset 5382c05021026fe623def829d121f5f6af4909fb by Andrew Svetlov in branch 'master': bpo-32351: Use fastpath in asyncio.sleep if delay<0 (#4908) https://github.com/python/cpython/commit/5382c05021026fe623def829d121f5f6af4909fb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 09:42:09 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 17 Dec 2017 14:42:09 +0000 Subject: [issue32351] Use fastpath in asyncio.sleep if delay<0 In-Reply-To: <1513513322.7.0.213398074469.issue32351@psf.upfronthosting.co.za> Message-ID: <1513521729.63.0.213398074469.issue32351@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 10:29:14 2017 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 17 Dec 2017 15:29:14 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1513524554.73.0.213398074469.issue32259@psf.upfronthosting.co.za> Eric V. Smith added the comment: The PR looks okay to me. I'm also not sure it's worth the change, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 13:14:27 2017 From: report at bugs.python.org (Sergey Fedoseev) Date: Sun, 17 Dec 2017 18:14:27 +0000 Subject: [issue32147] improve performance of binascii.unhexlify() by using conversion table In-Reply-To: <1511784869.56.0.213398074469.issue32147@psf.upfronthosting.co.za> Message-ID: <1513534467.25.0.213398074469.issue32147@psf.upfronthosting.co.za> Sergey Fedoseev added the comment: Is there anything I can do to push this forward? BTW, Serhiy, what are your OS, compiler and CPU? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 13:15:35 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 17 Dec 2017 18:15:35 +0000 Subject: [issue32264] move pygetopt.h into internal/ In-Reply-To: <1512857323.9.0.213398074469.issue32264@psf.upfronthosting.co.za> Message-ID: <1513534535.45.0.213398074469.issue32264@psf.upfronthosting.co.za> Change by Benjamin Peterson : ---------- pull_requests: +4803 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 13:16:14 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 17 Dec 2017 18:16:14 +0000 Subject: [issue32264] move pygetopt.h into internal/ In-Reply-To: <1512857323.9.0.213398074469.issue32264@psf.upfronthosting.co.za> Message-ID: <1513534574.84.0.213398074469.issue32264@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thanks the report and debugging. You're exactly right?I forgot to add extern. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 13:28:43 2017 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 17 Dec 2017 18:28:43 +0000 Subject: [issue32349] Add detailed return value information for set.intersection function In-Reply-To: <1513488561.11.0.213398074469.issue32349@psf.upfronthosting.co.za> Message-ID: <1513535323.79.0.213398074469.issue32349@psf.upfronthosting.co.za> Mark Dickinson added the comment: To clarify, are you referring to this behaviour? >>> a = {1, 2, 3} >>> b = {1.0, 4.0} >>> a.intersection(b) # expect {1} {1.0} I'd personally expect this to be implementation-dependent: since for set operations you usually only care about objects up to equality, it would be a bit unusual to care whether you get {1} or {1.0} in the above situation, and I'd say the implementation should be free to do whatever's convenient. Making documented guarantees would unnecessarily constrain other implementations. I suppose one could document the *lack* of a guarantee here ... ---------- nosy: +mark.dickinson, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 13:34:02 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 17 Dec 2017 18:34:02 +0000 Subject: [issue32264] move pygetopt.h into internal/ In-Reply-To: <1512857323.9.0.213398074469.issue32264@psf.upfronthosting.co.za> Message-ID: <1513535642.3.0.213398074469.issue32264@psf.upfronthosting.co.za> Benjamin Peterson added the comment: New changeset 4c72bc4a38eced10a55ba7071e084b26a2b5ed4b by Benjamin Peterson in branch 'master': add 'extern' to pygetopt.h symbols, so then don't end up in comdat (#4909) https://github.com/python/cpython/commit/4c72bc4a38eced10a55ba7071e084b26a2b5ed4b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 14:18:22 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 17 Dec 2017 19:18:22 +0000 Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7 In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za> Message-ID: <1513538302.16.0.213398074469.issue32248@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I have the tests and code ported, but there are still a few things to do, but here's a question: We're using type annotations in importlib_resources, which of course is the right decision. But I think we still have a moratorium on typing in the stdlib. So do we want to remove the types from importlib.resources? Doing so could make for more work as we continue to track importlib_resource, so I'm inclined not to remove them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 15:04:01 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 17 Dec 2017 20:04:01 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1513541041.63.0.213398074469.issue32259@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thanks, Serhiy, for the C implementation, and Eric for reviewing it. I would add 'non-iterable', to get "cannot unpack non-iterable int object", to tell people what is needed instead. I do think this worthwhile. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 15:09:34 2017 From: report at bugs.python.org (Decorater) Date: Sun, 17 Dec 2017 20:09:34 +0000 Subject: [issue32353] Add docs about Embedding with an frozen module limitation. Message-ID: <1513541374.74.0.213398074469.issue32353@psf.upfronthosting.co.za> New submission from Decorater : It seems that 1 thing that bites me is that there is no section on the embedding docs about limitations to using frozen modules in them. So lets say for example your program has this like in the main function on an embedded python: ```c PyRun_SimpleString("import mymodule"); ``` And lets say ``mymodule`` is supposed to be an frozen module in that embedded interpreter named ``myprogram`` It would fail to work because it wont be able to find ``mymodule`` when it really should. This doc change should help fix that senerio and hopefully suggest an fix to that senerio as well. ---------- assignee: docs at python components: Documentation messages: 308497 nosy: Decorater, docs at python priority: normal severity: normal status: open title: Add docs about Embedding with an frozen module limitation. versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 15:09:59 2017 From: report at bugs.python.org (Decorater) Date: Sun, 17 Dec 2017 20:09:59 +0000 Subject: [issue32353] Add docs about Embedding with an frozen module limitation. In-Reply-To: <1513541374.74.0.213398074469.issue32353@psf.upfronthosting.co.za> Message-ID: <1513541399.83.0.213398074469.issue32353@psf.upfronthosting.co.za> Change by Decorater : ---------- keywords: +patch pull_requests: +4804 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 15:19:31 2017 From: report at bugs.python.org (Meador Inge) Date: Sun, 17 Dec 2017 20:19:31 +0000 Subject: [issue32147] improve performance of binascii.unhexlify() by using conversion table In-Reply-To: <1511784869.56.0.213398074469.issue32147@psf.upfronthosting.co.za> Message-ID: <1513541971.62.0.213398074469.issue32147@psf.upfronthosting.co.za> Meador Inge added the comment: FWIW, I see a win on OS X 10.12.6: ?:[master !?](~/Code/src/python/cpython)=> cc --version Apple LLVM version 8.1.0 (clang-802.0.42) Target: x86_64-apple-darwin16.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin ?:[master !?](~/Code/src/python/cpython)=> uname -a Darwin ripley.attlocal.net 16.7.0 Darwin Kernel Version 16.7.0: Wed Oct 4 00:17:00 PDT 2017; root:xnu-3789.71.6~1/RELEASE_X86_64 x86_64 - Before: ?:[master ?](~/Code/src/python/cpython)=> ./python.exe -m timeit -s "from binascii import unhexlify; b = b'aa'*2**20" "unhexlify(b)" 20 loops, best of 5: 11.3 msec per loop - After: ?:[master !?](~/Code/src/python/cpython)=> ./python.exe -m timeit -s "from binascii import unhexlify; b = b'aa'*2**20" "unhexlify(b)" 50 loops, best of 5: 4.15 msec per loop ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 15:29:06 2017 From: report at bugs.python.org (Nikhil Hegde) Date: Sun, 17 Dec 2017 20:29:06 +0000 Subject: [issue32152] Add pid to .cover filename in lib/trace.py In-Reply-To: <1511858704.48.0.213398074469.issue32152@psf.upfronthosting.co.za> Message-ID: <1513542546.03.0.213398074469.issue32152@psf.upfronthosting.co.za> Nikhil Hegde added the comment: Any ETA I can get on this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 15:34:49 2017 From: report at bugs.python.org (Meador Inge) Date: Sun, 17 Dec 2017 20:34:49 +0000 Subject: [issue32352] `inspect.getfullargspec` doesn't work fine for some builtin callable objects In-Reply-To: <1513518429.74.0.213398074469.issue32352@psf.upfronthosting.co.za> Message-ID: <1513542889.38.0.213398074469.issue32352@psf.upfronthosting.co.za> Meador Inge added the comment: This is a documented limitation for CPython: https://docs.python.org/3.7/library/inspect.html#inspect.signature ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 18:16:09 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 17 Dec 2017 23:16:09 +0000 Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7 In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za> Message-ID: <1513552569.92.0.213398074469.issue32248@psf.upfronthosting.co.za> Change by Barry A. Warsaw : ---------- pull_requests: +4805 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 18:18:45 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 17 Dec 2017 23:18:45 +0000 Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7 In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za> Message-ID: <1513552725.03.0.213398074469.issue32248@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: PR 4911 implements the importlib.resources API, along with tests and documentation. @brett.cannon - I'm thinking we should do the native ResourceReader implementations for the built-in loaders as a separate branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 20:19:50 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 01:19:50 +0000 Subject: [issue32348] Optimize asyncio.Future schedule/add/remove callback In-Reply-To: <1513468213.29.0.213398074469.issue32348@psf.upfronthosting.co.za> Message-ID: <1513559990.39.0.213398074469.issue32348@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 1b7c11ff0ee3efafbf5b38c3c6f37de5d63efb81 by Yury Selivanov in branch 'master': bpo-32348: Optimize asyncio.Future schedule/add/remove callback. (#4907) https://github.com/python/cpython/commit/1b7c11ff0ee3efafbf5b38c3c6f37de5d63efb81 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 20:22:36 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 01:22:36 +0000 Subject: [issue32348] Optimize asyncio.Future schedule/add/remove callback In-Reply-To: <1513468213.29.0.213398074469.issue32348@psf.upfronthosting.co.za> Message-ID: <1513560156.64.0.213398074469.issue32348@psf.upfronthosting.co.za> Yury Selivanov added the comment: The attached benchmark from https://bugs.python.org/issue32204 shows that the updated Task is 15% faster. ---------- Added file: https://bugs.python.org/file47335/t.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 20:22:51 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 01:22:51 +0000 Subject: [issue32348] Optimize asyncio.Future schedule/add/remove callback In-Reply-To: <1513468213.29.0.213398074469.issue32348@psf.upfronthosting.co.za> Message-ID: <1513560171.73.0.213398074469.issue32348@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 20:23:47 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 01:23:47 +0000 Subject: [issue32204] async/await performance is very low In-Reply-To: <1512292149.52.0.213398074469.issue32204@psf.upfronthosting.co.za> Message-ID: <1513560227.42.0.213398074469.issue32204@psf.upfronthosting.co.za> Yury Selivanov added the comment: Liran, Task (C implementation) was optimized in issue 32348; your benchmark now runs 15% faster. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 20:37:50 2017 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 Dec 2017 01:37:50 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1513561070.21.0.213398074469.issue15873@psf.upfronthosting.co.za> Martin Panter added the comment: Regarding Matthieu?s RFC 3339 parser, Victor wanted to use the round-half-to-even rule to get a whole number of microseconds. But considering the ?time? class cannot represent 24:00, how do you round up in the extreme case past 23:59? time.fromisoformat("23:59:59.9999995") Perhaps it is better to always truncate to zero, only support 6 digits (rejecting fractions of a microsecond), or add Anders?s truncate_microseconds=True option. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 21:00:12 2017 From: report at bugs.python.org (Campbell Barton) Date: Mon, 18 Dec 2017 02:00:12 +0000 Subject: [issue32354] Unclear intention of deprecating Py_UNICODE_TOLOWER / Py_UNICODE_TOUPPER Message-ID: <1513562412.88.0.213398074469.issue32354@psf.upfronthosting.co.za> New submission from Campbell Barton : Py_UNICODE_TOLOWER / Py_UNICODE_TOUPPER are marked as deprecated in the docs. https://docs.python.org/3/c-api/unicode.html?highlight=py_unicode_tolower#c.Py_UNICODE_TOLOWER Someone submitted a patch to our project which uses these. What is unclear, is if there is an intention to replace these (wrappers for '_PyUnicode_ToLowerFull' for eg). Or if this will be removed without any alternative. I assume the functionality will be kept somewhere since Python needs str.lower/upper. Will there be a way to perform this in the future? Either way, could docs be updated to reflect this? ---------- components: Unicode messages: 308506 nosy: ezio.melotti, ideasman42, vstinner priority: normal severity: normal status: open title: Unclear intention of deprecating Py_UNICODE_TOLOWER / Py_UNICODE_TOUPPER versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 21:10:02 2017 From: report at bugs.python.org (Ryan Govostes) Date: Mon, 18 Dec 2017 02:10:02 +0000 Subject: [issue32347] System Integrity Protection breaks shutil.copystat() In-Reply-To: <1513442701.16.0.213398074469.issue32347@psf.upfronthosting.co.za> Message-ID: <1513563002.59.0.213398074469.issue32347@psf.upfronthosting.co.za> Change by Ryan Govostes : ---------- keywords: +patch pull_requests: +4806 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 21:19:47 2017 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 18 Dec 2017 02:19:47 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1513563587.39.0.213398074469.issue15873@psf.upfronthosting.co.za> Paul Ganssle added the comment: @martin.panter I don't see the problem here? Wouldn't 23:59.9999995 round up to 00:00? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 21:41:07 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 02:41:07 +0000 Subject: [issue32355] Optimize asyncio.gather() Message-ID: <1513564867.85.0.213398074469.issue32355@psf.upfronthosting.co.za> New submission from Yury Selivanov : asyncio.gather can be made faster if: 1. we don't use functools.partial 2. create less intermittent collections 3. drop unnecessary code (e.g. gather has some code that's duplicated in ensure_future that it uses etc) The proposed PR makes asyncio.gather 10-15% faster on the attached benchmark. ---------- assignee: yselivanov components: asyncio files: t.py messages: 308508 nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Optimize asyncio.gather() type: performance versions: Python 3.7 Added file: https://bugs.python.org/file47336/t.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 21:43:10 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 02:43:10 +0000 Subject: [issue32355] Optimize asyncio.gather() In-Reply-To: <1513564867.85.0.213398074469.issue32355@psf.upfronthosting.co.za> Message-ID: <1513564990.92.0.213398074469.issue32355@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4807 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 22:50:01 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 03:50:01 +0000 Subject: [issue32356] asyncio: Make transport.pause_reading()/resume_reading() idempotent; add transport.is_reading() In-Reply-To: <1513568775.87.0.213398074469.issue32356@psf.upfronthosting.co.za> Message-ID: <1513569001.08.0.213398074469.issue32356@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 22:52:32 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 03:52:32 +0000 Subject: [issue32356] asyncio: Make transport.pause_reading()/resume_reading() idempotent; add transport.is_reading() In-Reply-To: <1513568775.87.0.213398074469.issue32356@psf.upfronthosting.co.za> Message-ID: <1513569152.46.0.213398074469.issue32356@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4808 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 22:46:15 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 03:46:15 +0000 Subject: [issue32356] asyncio: Make transport.pause_reading()/resume_reading() idempotent; add transport.is_reading() Message-ID: <1513568775.87.0.213398074469.issue32356@psf.upfronthosting.co.za> New submission from Yury Selivanov : As briefly discussed on https://github.com/python/asyncio/issues/488 and https://github.com/python/cpython/pull/528 ---------- messages: 308509 nosy: yselivanov priority: normal severity: normal status: open title: asyncio: Make transport.pause_reading()/resume_reading() idempotent; add transport.is_reading() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 23:01:51 2017 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 Dec 2017 04:01:51 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1513569711.76.0.213398074469.issue15873@psf.upfronthosting.co.za> Martin Panter added the comment: Not if the time is associated with a particular day. Imagine implementing datetime.fromisoformat by separately calling date.fromisoformat and time.fromisoformat. The date will be off by one day if you naively rounded 2017-12-18 23:59 ?up? to 2017-12-18 00:00. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 23:10:20 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 04:10:20 +0000 Subject: [issue30050] Please provide a way to disable the warning printed if the signal module's wakeup fd overflows In-Reply-To: <1491987273.45.0.570112423464.issue30050@psf.upfronthosting.co.za> Message-ID: <1513570220.33.0.213398074469.issue30050@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 902ab80b590e474bb2077b1fae8aac497b856d66 by Yury Selivanov (Nathaniel J. Smith) in branch 'master': bpo-30050: Allow disabling full buffer warnings in signal.set_wakeup_fd (#4792) https://github.com/python/cpython/commit/902ab80b590e474bb2077b1fae8aac497b856d66 ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 23:13:58 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 04:13:58 +0000 Subject: [issue30050] Please provide a way to disable the warning printed if the signal module's wakeup fd overflows In-Reply-To: <1491987273.45.0.570112423464.issue30050@psf.upfronthosting.co.za> Message-ID: <1513570438.28.0.213398074469.issue30050@psf.upfronthosting.co.za> Yury Selivanov added the comment: I think that what Nathaniel proposes is very reasonable. The PR is LGTM and I've just merged it. Closing the issue. ---------- components: +Interpreter Core resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 23:29:16 2017 From: report at bugs.python.org (Liran Nuna) Date: Mon, 18 Dec 2017 04:29:16 +0000 Subject: [issue32204] async/await performance is very low In-Reply-To: <1512292149.52.0.213398074469.issue32204@psf.upfronthosting.co.za> Message-ID: <1513571356.28.0.213398074469.issue32204@psf.upfronthosting.co.za> Liran Nuna added the comment: Yury, thank you very much for circling back. I wish I could be more helpful in pursuing performance improvements. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 17 23:33:05 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 04:33:05 +0000 Subject: [issue32204] async/await performance is very low In-Reply-To: <1512292149.52.0.213398074469.issue32204@psf.upfronthosting.co.za> Message-ID: <1513571585.23.0.213398074469.issue32204@psf.upfronthosting.co.za> Yury Selivanov added the comment: NP. I have another PR in the pipeline: https://github.com/python/cpython/pull/4913 Both optimizations make your benchmark run 30% faster on 3.7. If you compile asyncio.gather() with Cython you will get it another 5-15% faster. If you use uvloop - another 10-20%. If it's still slower than asynq, then the issue must be in how asynq schedules its callbacks, it might be more optimal for some specific use cases than asyncio. FWIW I don't expect asynq to be any faster than asyncio (or than uvloop) for network IO. And there's definitely no problem with async/await performance -- we're optimizing asyncio here, not the interpreter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 00:33:40 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 05:33:40 +0000 Subject: [issue32357] Optimize asyncio.iscoroutine() for non-native coroutines Message-ID: <1513575220.77.0.213398074469.issue32357@psf.upfronthosting.co.za> New submission from Yury Selivanov : asyncio.Task now uses asyncio.iscoroutine() to give a comprehensible error if a user creates a Task for a non-awaitable type. The problem is that iscoroutine() is quite expensive for non-native coroutines (like the ones compiled with Cython), as it uses `isinstance(obj, collections.abc.Coroutine)` call. This makes 'loop.create_task(cython_coroutine)' 20% slower than 'loop.create_task(python_coroutine)'. The PR adds a positive type cache to the iscoroutine() function and to the asyncio.Task C implementation. Both caches make 'loop.create_task()' equally fast for all kinds of coroutines. ---------- components: asyncio messages: 308515 nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Optimize asyncio.iscoroutine() for non-native coroutines versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 00:33:56 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 05:33:56 +0000 Subject: [issue32357] Optimize asyncio.iscoroutine() and loop.create_task() for non-native coroutines In-Reply-To: <1513575220.77.0.213398074469.issue32357@psf.upfronthosting.co.za> Message-ID: <1513575236.09.0.213398074469.issue32357@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- title: Optimize asyncio.iscoroutine() for non-native coroutines -> Optimize asyncio.iscoroutine() and loop.create_task() for non-native coroutines _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 00:37:46 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 05:37:46 +0000 Subject: [issue32357] Optimize asyncio.iscoroutine() and loop.create_task() for non-native coroutines In-Reply-To: <1513575220.77.0.213398074469.issue32357@psf.upfronthosting.co.za> Message-ID: <1513575466.79.0.213398074469.issue32357@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4809 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 01:20:59 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 18 Dec 2017 06:20:59 +0000 Subject: [issue32338] Save OrderedDict import in re In-Reply-To: <1513362099.11.0.213398074469.issue32338@psf.upfronthosting.co.za> Message-ID: <1513578059.77.0.213398074469.issue32338@psf.upfronthosting.co.za> INADA Naoki added the comment: Please don't do this. del d[next(iter(d))] is not O(1) on current dict implementation. OrderedDict is designed for such use cases. Please keep using it. ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 01:24:46 2017 From: report at bugs.python.org (TaoQingyun) Date: Mon, 18 Dec 2017 06:24:46 +0000 Subject: [issue32358] json.dump: fp must be a text file object Message-ID: <1513578286.44.0.213398074469.issue32358@psf.upfronthosting.co.za> New submission from TaoQingyun <845767657 at qq.com>: ``` >>> import json >>> f = open('/tmp/t.json', 'wb') >>> json.dump(123, f) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.6/json/__init__.py", line 180, in dump fp.write(chunk) TypeError: a bytes-like object is required, not 'str' ``` This may not a bug. But it should mention at docs https://docs.python.org/3/library/json.html#json.dump ---------- components: Library (Lib) messages: 308517 nosy: qingyunha priority: normal severity: normal status: open title: json.dump: fp must be a text file object versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 01:41:19 2017 From: report at bugs.python.org (Glenn Linderman) Date: Mon, 18 Dec 2017 06:41:19 +0000 Subject: [issue31639] http.server and SimpleHTTPServer hang after a few requests In-Reply-To: <1506701944.65.0.213398074469.issue31639@psf.upfronthosting.co.za> Message-ID: <1513579279.47.0.213398074469.issue31639@psf.upfronthosting.co.za> Glenn Linderman added the comment: Same behavior on Windows. ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, v+python, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 01:52:57 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 18 Dec 2017 06:52:57 +0000 Subject: [issue29469] AST-level Constant folding In-Reply-To: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> Message-ID: <1513579977.37.0.213398074469.issue29469@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset 87010e85cb37192d63b1a30e5fabba307ad5a3f5 by INADA Naoki in branch 'master': bpo-29469: peephole: Remove const_stack (GH-4879) https://github.com/python/cpython/commit/87010e85cb37192d63b1a30e5fabba307ad5a3f5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 02:16:04 2017 From: report at bugs.python.org (Martin Panter) Date: Mon, 18 Dec 2017 07:16:04 +0000 Subject: [issue32352] `inspect.getfullargspec` doesn't work fine for some builtin callable objects In-Reply-To: <1513518429.74.0.213398074469.issue32352@psf.upfronthosting.co.za> Message-ID: <1513581364.81.0.213398074469.issue32352@psf.upfronthosting.co.za> Martin Panter added the comment: This was documented for the ?getfullargspec? function in Issue 7422 (long before ?signature? existed). The error message was also clarified in Issue 6905. However IMO the term ?Python function? is too subtle and ambiguous. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 02:46:38 2017 From: report at bugs.python.org (Glenn Linderman) Date: Mon, 18 Dec 2017 07:46:38 +0000 Subject: [issue31639] http.server and SimpleHTTPServer hang after a few requests In-Reply-To: <1506701944.65.0.213398074469.issue31639@psf.upfronthosting.co.za> Message-ID: <1513583198.34.0.213398074469.issue31639@psf.upfronthosting.co.za> Glenn Linderman added the comment: This probably has been around for a while: this 2011 thread in a Chromium wontfix bug is enlightening, but the solution suggested, a ThreadingMixIn for the HTTPServer, didn't help me. https://bugs.chromium.org/p/chromium/issues/detail?id=195550 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 03:00:14 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 18 Dec 2017 08:00:14 +0000 Subject: [issue32349] Add detailed return value information for set.intersection function In-Reply-To: <1513488561.11.0.213398074469.issue32349@psf.upfronthosting.co.za> Message-ID: <1513584014.23.0.213398074469.issue32349@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The implementation detail is not documented because it is not guaranteed. The behavior has changed over time and other implementation are allowed to do something different. For example, collections.abc.Set.__and__ has different behavior. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 03:56:54 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 08:56:54 +0000 Subject: [issue32354] Unclear intention of deprecating Py_UNICODE_TOLOWER / Py_UNICODE_TOUPPER In-Reply-To: <1513562412.88.0.213398074469.issue32354@psf.upfronthosting.co.za> Message-ID: <1513587414.49.0.213398074469.issue32354@psf.upfronthosting.co.za> STINNER Victor added the comment: Py_UNICODE_TOLOWER / Py_UNICODE_TOUPPER *API* doesn't respect the latest Unicode standard. For example, it doesn't support this operation: >>> "?".upper() 'SS' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:08:33 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Dec 2017 09:08:33 +0000 Subject: [issue32338] Save OrderedDict import in re In-Reply-To: <1513362099.11.0.213398074469.issue32338@psf.upfronthosting.co.za> Message-ID: <1513588113.0.0.213398074469.issue32338@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is surprising. But OrderedDict also can be O(N) here. Do you have benchmarking results Inada? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:23:33 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 18 Dec 2017 09:23:33 +0000 Subject: [issue32338] Save OrderedDict import in re In-Reply-To: <1513362099.11.0.213398074469.issue32338@psf.upfronthosting.co.za> Message-ID: <1513589013.45.0.213398074469.issue32338@psf.upfronthosting.co.za> INADA Naoki added the comment: > This is surprising. But OrderedDict also can be O(N) here. Current dict implementation doesn't skip empty entries. So next(iter(D)) takes time. On the other hand, OrderedDict uses doubly-linked list to find first entry. (I fixed it in compact ODict branch, but it added one word to dict) > Do you have benchmarking results Inada? $ ./python -m perf timeit -s 'cache={}' -- ' for i in range(10000): if len(cache) > 512: del cache[next(iter(cache))] cache[i]=i ' ..................... Mean +- std dev: 6.81 ms +- 0.08 ms $ ./python -m perf timeit -s 'from collections import OrderedDict; cache=OrderedDict()' -- ' for i in range(10000): if len(cache) > 512: cache.popitem(last=False) cache[i]=i ' ..................... Mean +- std dev: 3.75 ms +- 0.07 ms Performance difference is measurable even when N is only 512. Maybe, we can use hack similar to Python 3.5 had for O(1) popitem(). When entries[0].key==NULL, (Py_ssize_t)entries[0].value can be index to first known non-empty entry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:25:33 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 18 Dec 2017 09:25:33 +0000 Subject: [issue32338] Save OrderedDict import in re In-Reply-To: <1513362099.11.0.213398074469.issue32338@psf.upfronthosting.co.za> Message-ID: <1513589133.44.0.213398074469.issue32338@psf.upfronthosting.co.za> INADA Naoki added the comment: Hmm, 0.3 ?s for each lookup may be negligible compared to re.compile() speed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:26:16 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 09:26:16 +0000 Subject: [issue32338] Save OrderedDict import in re In-Reply-To: <1513362099.11.0.213398074469.issue32338@psf.upfronthosting.co.za> Message-ID: <1513589176.08.0.213398074469.issue32338@psf.upfronthosting.co.za> STINNER Victor added the comment: > del d[next(iter(d))] is not O(1) on current dict implementation. We are talking about a dictionary of 512 items in the worst case. On such very tiny collection, benchmarking matters more than O(...) complexity ;-) ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:28:27 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 09:28:27 +0000 Subject: [issue19764] subprocess: use PROC_THREAD_ATTRIBUTE_HANDLE_LIST with STARTUPINFOEX on Windows Vista In-Reply-To: <1385370115.99.0.757096187315.issue19764@psf.upfronthosting.co.za> Message-ID: <1513589307.21.0.213398074469.issue19764@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset b2a6083eb0384f38839d3f1ed32262a3852026fa by Victor Stinner (Segev Finer) in branch 'master': bpo-19764: Implemented support for subprocess.Popen(close_fds=True) on Windows (#1218) https://github.com/python/cpython/commit/b2a6083eb0384f38839d3f1ed32262a3852026fa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:29:45 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 18 Dec 2017 09:29:45 +0000 Subject: [issue32338] Save OrderedDict import in re In-Reply-To: <1513362099.11.0.213398074469.issue32338@psf.upfronthosting.co.za> Message-ID: <1513589385.27.0.213398074469.issue32338@psf.upfronthosting.co.za> INADA Naoki added the comment: > We are talking about a dictionary of 512 items in the worst case. On such very tiny collection, benchmarking matters more than O(...) complexity ;-) You're right. Rob Pike said: "Fancy algorithms are slow when n is small, and n is usually small." http://users.ece.utexas.edu/~adnan/pike.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:32:52 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 09:32:52 +0000 Subject: [issue19764] subprocess: use PROC_THREAD_ATTRIBUTE_HANDLE_LIST with STARTUPINFOEX on Windows Vista In-Reply-To: <1385370115.99.0.757096187315.issue19764@psf.upfronthosting.co.za> Message-ID: <1513589572.47.0.213398074469.issue19764@psf.upfronthosting.co.za> STINNER Victor added the comment: Copy of my comment on the PR. https://github.com/python/cpython/pull/1218#issuecomment-352372211 > Merged from master... Again... Hopefully this won't end up missing 3.7 entirely... ? Oops sorry, I wanted this feature but I didn't follow closely the PR. I don't know well the Windows API, so I didn't want to take the responsability of reviewing (approving) such PR. But I see that @zooba and @gpshead approved it, so I'm now confortable to merge it :-) Moreover, AppVeyor validated the PR, so let me merge it. I prefer to merge the PR right now to not miss the Python 3.7 feature freeze, and maybe fix issues later if needed, before 3.7 final. Thank you @segevfiner for this major subprocess enhancement. I really love to see close_fds default changing to True on Windows. It will help to fix many corner cases which are very tricky to debug. Sorry for the slow review, but the subprocess is a critical module of Python, and we lack of Windows developers to review changes specific to Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:35:37 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 09:35:37 +0000 Subject: [issue19764] subprocess: use PROC_THREAD_ATTRIBUTE_HANDLE_LIST with STARTUPINFOEX on Windows Vista In-Reply-To: <1385370115.99.0.757096187315.issue19764@psf.upfronthosting.co.za> Message-ID: <1513589737.45.0.213398074469.issue19764@psf.upfronthosting.co.za> STINNER Victor added the comment: Thank you Sergev Finer for finishing the implementation of my PEP 446. Supporting to only inherit a set of Windows handles was a "small note" my PEP 446, mostly because I didn't feel able to implement the feature, but also because we still supported Windows versions which didn't implement this feature (PROC_THREAD_ATTRIBUTE_HANDLE_LIST) if I recall correctly. Thanks Eryk Sun, Gregory P. Smith and Steve Dower for the reviews and help on getting this nice feature into Python 3.7! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:41:35 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 09:41:35 +0000 Subject: [issue30121] Windows: subprocess debug assertion on failure to execute the process In-Reply-To: <1492728235.69.0.898513798091.issue30121@psf.upfronthosting.co.za> Message-ID: <1513590095.63.0.213398074469.issue30121@psf.upfronthosting.co.za> STINNER Victor added the comment: Oops, I merged the pull requests, but I forgot to close the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:41:45 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Mon, 18 Dec 2017 09:41:45 +0000 Subject: [issue32359] Add getters for all SSLContext internal configuration Message-ID: <1513590105.76.0.213398074469.issue32359@psf.upfronthosting.co.za> New submission from Nathaniel Smith : Suppose you're writing a library that allows users to make or accept SSL/TLS connections. You use the 'ssl' module, because that's convenient. You need to let your users configure your SSL/TLS connections, and there really isn't any generic abstract way to do that -- SSL/TLS configuration is pretty complicated -- so you let your users set up an ssl.SSLContext and pass it into your API. Later, you hit a limit in the ssl module and want to switch to PyOpenSSL, or perhaps eventually PEP 543. No problem: just switch what you're doing internally, and use some shim code to take the ssl.SSLContext objects that your users are passing in, and convert that to whatever your new library wants. Except... ssl.SSLContext objects are almost entirely opaque. You can't read off the ciphers, or the ALPN protocols, or the servername_callback... so you're sunk. Once you expose ssl.SSLContext in your public API, you're stuck using the ssl module forever. It would be nice if ssl.SSLContext provided getters that let you read off all the different configuration it holds. ---------- assignee: christian.heimes components: SSL messages: 308533 nosy: alex, christian.heimes, dstufft, janssen, njs priority: normal severity: normal status: open title: Add getters for all SSLContext internal configuration _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:44:55 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 18 Dec 2017 09:44:55 +0000 Subject: [issue32338] Save OrderedDict import in re In-Reply-To: <1513362099.11.0.213398074469.issue32338@psf.upfronthosting.co.za> Message-ID: <1513590295.5.0.213398074469.issue32338@psf.upfronthosting.co.za> INADA Naoki added the comment: * del cache[next(iter(cache))] happens only when sre.compile() is called. * del cache[next(iter(cache))] is much faster than sre.compile(). OK, performance difference is negligible, surely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:45:46 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 18 Dec 2017 09:45:46 +0000 Subject: [issue32360] Save OrderedDict imports in various stdlibs. Message-ID: <1513590346.77.0.213398074469.issue32360@psf.upfronthosting.co.za> Change by INADA Naoki : ---------- nosy: inada.naoki priority: normal severity: normal status: open title: Save OrderedDict imports in various stdlibs. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:49:57 2017 From: report at bugs.python.org (Christian Heimes) Date: Mon, 18 Dec 2017 09:49:57 +0000 Subject: [issue32359] Add getters for all SSLContext internal configuration In-Reply-To: <1513590105.76.0.213398074469.issue32359@psf.upfronthosting.co.za> Message-ID: <1513590597.81.0.213398074469.issue32359@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm considering to add CAPI capsule to the _ssl module. It would allow third parties to get hold of the internal SSL* and SSL_CTX* pointers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:52:27 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Dec 2017 09:52:27 +0000 Subject: [issue32360] Save OrderedDict imports in various stdlibs. Message-ID: <1513590747.1.0.213398074469.issue32360@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- components: +Library (Lib) dependencies: +Save OrderedDict import in argparse, Save OrderedDict import in re type: -> performance versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:53:28 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Dec 2017 09:53:28 +0000 Subject: [issue32336] Save OrderedDict import in argparse In-Reply-To: <1513361484.23.0.213398074469.issue32336@psf.upfronthosting.co.za> Message-ID: <1513590808.08.0.213398074469.issue32336@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- dependencies: +Dict order is now guaranteed, so add tests and doc for it _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:53:44 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Dec 2017 09:53:44 +0000 Subject: [issue32338] Save OrderedDict import in re In-Reply-To: <1513362099.11.0.213398074469.issue32338@psf.upfronthosting.co.za> Message-ID: <1513590824.45.0.213398074469.issue32338@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- dependencies: +Dict order is now guaranteed, so add tests and doc for it _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:53:57 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Dec 2017 09:53:57 +0000 Subject: [issue32360] Save OrderedDict imports in various stdlibs. Message-ID: <1513590837.32.0.213398074469.issue32360@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- dependencies: +Dict order is now guaranteed, so add tests and doc for it _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:59:37 2017 From: report at bugs.python.org (Christian Heimes) Date: Mon, 18 Dec 2017 09:59:37 +0000 Subject: [issue32359] Add getters for all SSLContext internal configuration In-Reply-To: <1513590105.76.0.213398074469.issue32359@psf.upfronthosting.co.za> Message-ID: <1513591177.11.0.213398074469.issue32359@psf.upfronthosting.co.za> Christian Heimes added the comment: Let's see what's missing: * alpn_protocols -- OpenSSL doesn't have SSL_CTX_get_alpn_protos(), so we'd have to keep the list around ourselves. * npn_protocols -- deprecated, I'd rather add a getter * servername_callback -- simply expose the PyObject* from our struct * ecdh_curve -- OpenSSL has no getter * ciphers is covered by https://docs.python.org/3/library/ssl.html#ssl.SSLContext.get_ciphers It doens't return the cipher string but the actual list of enabled ciphers with some extra metadata. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 04:59:49 2017 From: report at bugs.python.org (Camion) Date: Mon, 18 Dec 2017 09:59:49 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? Message-ID: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> New submission from Camion : Hello, "PEP 3104 -- Access to Names in Outer Scopes" introduced the keywords "global" and "nonlocal". but didn't make clear (to me) if this behaviour is a bug, an intentional feature, or a design hole which might be considered good or bad. I have observed that when the nonlocal keyword gives acces to a grand parent function's variable, the presence in the parent function, of an access to a global variable with the same name, blocks it with a syntax error (SyntaxError: no binding for nonlocal 'a' found). a = "a : global" def f(): a = "a : local to f" def g(): # global a # uncommenting this line causes a syntax error. # a = a+", modified in g" def h(): nonlocal a a = a+", modified in h" h() print (f"in g : a = '{a}'") g() print (f"in f : a = '{a}'") f() print (f"glogal : a = '{a}'") ---------- components: Interpreter Core messages: 308537 nosy: Camion priority: normal severity: normal status: open title: global / nonlocal interference : is this a bug, a feature or a design hole ? type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 05:00:11 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 18 Dec 2017 10:00:11 +0000 Subject: [issue32360] Save OrderedDict imports in various stdlibs. Message-ID: <1513591210.99.0.213398074469.issue32360@psf.upfronthosting.co.za> New submission from INADA Naoki : csv and re has issues already. There are some remaining OrderdDict, including docstring. It looks like some of them can be removed easily without doc update. This is `ag --exclude-dir=test OrderedDict`, exluding csv, re, pprint and collections. typing: 2109: nm_tpl.__annotations__ = nm_tpl._field_types = collections.OrderedDict(types) unittest/util.py 3:from collections import namedtuple, OrderedDict 158: c = OrderedDict() enum.py 153: enum_class._member_map_ = OrderedDict() # name->value map 615: # We use an OrderedDict of sorted source keys so that the lib2to3/pgen2/grammar.py 91: dump() recursively changes all dict to OrderedDict, so the pickled file 93: pickled file to create the tables, but only changes OrderedDict to dict 94: at the top level; it does not recursively change OrderedDict to dict. 96: passed to load() in that some of the OrderedDict (from the pickled file) 98: performance because OrderedDict uses dict's __getitem__ with nothing in 142: return collections.OrderedDict( asyncio/base_events.py 842: addr_infos = collections.OrderedDict() configparser.py 142:from collections import OrderedDict as _default_dict, ChainMap as _ChainMap inspect.py 52:from collections import namedtuple, OrderedDict 1712: new_params = OrderedDict(old_params.items()) 2563: * arguments : OrderedDict 2663: self.arguments = OrderedDict(new_arguments) 2694: * parameters : OrderedDict 2724: params = OrderedDict() 2727: params = OrderedDict() 2762: params = OrderedDict(((param.name, param) 2839: arguments = OrderedDict() json/tool.py 41: object_pairs_hook=collections.OrderedDict) json/__init__.py 31: >>> from collections import OrderedDict 32: >>> mydict = OrderedDict([('4', 5), ('6', 7)]) 290: collections.OrderedDict will remember the order of insertion). If 318: collections.OrderedDict will remember the order of insertion). If json/decoder.py 297: collections.OrderedDict will remember the order of insertion). If email/_header_value_parser.py 73:from collections import OrderedDict 720: params = OrderedDict() pydoc_data/topics.py 8585: '"collections.OrderedDict" to remember the order that class ' 8593: ' return collections.OrderedDict()\n' 8614: 'empty "collections.OrderedDict". That mapping records the ' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 05:17:27 2017 From: report at bugs.python.org (Mark) Date: Mon, 18 Dec 2017 10:17:27 +0000 Subject: [issue32362] multiprocessing.connection.Connection misdocumented as multiprocessing.Connection Message-ID: <1513592247.3.0.213398074469.issue32362@psf.upfronthosting.co.za> New submission from Mark : https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Connection purports to document the multiprocessing.Connection class. There's no such thing: Python 3.6.1 (v3.6.1:69c0db5050, Mar 21 2017, 01:21:04) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import multiprocessing >>> multiprocessing.Connection Traceback (most recent call last): File "", line 1, in AttributeError: module 'multiprocessing' has no attribute 'Connection' I think it should be multiprocessing.connection.Connection? ---------- assignee: docs at python components: Documentation messages: 308539 nosy: Amery, docs at python priority: normal severity: normal status: open title: multiprocessing.connection.Connection misdocumented as multiprocessing.Connection versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 05:21:12 2017 From: report at bugs.python.org (=?utf-8?b?7JaR7Jyg7ISd?=) Date: Mon, 18 Dec 2017 10:21:12 +0000 Subject: [issue32349] Add detailed return value information for set.intersection function In-Reply-To: <1513488561.11.0.213398074469.issue32349@psf.upfronthosting.co.za> Message-ID: <1513592472.21.0.213398074469.issue32349@psf.upfronthosting.co.za> ??? added the comment: Ok, I got a point of implementation-dependent things. Thank you for comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 05:30:54 2017 From: report at bugs.python.org (Christian Heimes) Date: Mon, 18 Dec 2017 10:30:54 +0000 Subject: [issue32359] Add getters for all SSLContext internal configuration In-Reply-To: <1513590105.76.0.213398074469.issue32359@psf.upfronthosting.co.za> Message-ID: <1513593054.46.0.213398074469.issue32359@psf.upfronthosting.co.za> Christian Heimes added the comment: I opened an issue about missing getters for ALPN protos in OpenSSL 1.1: https://github.com/openssl/openssl/issues/4952 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 05:56:09 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 18 Dec 2017 10:56:09 +0000 Subject: [issue32296] Implement asyncio._get_running_loop() and get_event_loop() in C In-Reply-To: <1513119563.35.0.213398074469.issue32296@psf.upfronthosting.co.za> Message-ID: <1513594569.08.0.213398074469.issue32296@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 05:59:23 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 18 Dec 2017 10:59:23 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() Message-ID: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> New submission from Andrew Svetlov : Task result is given from coroutine execution, explicit modification of the value should be deprecated and eventually removed. ---------- components: Library (Lib), asyncio messages: 308542 nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Deprecate task.set_result() and task.set_exception() type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 06:13:10 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 18 Dec 2017 11:13:10 +0000 Subject: [issue32364] Add AbstractFuture and AbstractTask Message-ID: <1513595590.31.0.213398074469.issue32364@psf.upfronthosting.co.za> New submission from Andrew Svetlov : Asyncio supports custom future and task by third-party loop implementation. Abstract classes for them is needed. AbstractTask should not have set_result()/set_exception() maybe, is this case abstract base is needed (AbstractPromise, AbstractCancellableValue or whatever). ---------- components: Library (Lib), asyncio messages: 308543 nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Add AbstractFuture and AbstractTask versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 06:24:03 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 11:24:03 +0000 Subject: [issue32365] Referenc leak: test_ast test_builtin test_compile Message-ID: <1513596243.38.0.213398074469.issue32365@psf.upfronthosting.co.za> New submission from STINNER Victor : The following tests are leaking references: test_ast test_builtin test_compile. It seems to be a regression introduced by the commit 3325a6780c81f1ea51190370b5454879c4862a37, bpo-27169. Serhiy: would you mind to take a look? ---------- components: Tests messages: 308544 nosy: serhiy.storchaka, vstinner priority: normal severity: normal status: open title: Referenc leak: test_ast test_builtin test_compile type: resource usage versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 06:25:54 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 11:25:54 +0000 Subject: [issue32365] Referenc leak: test_ast test_builtin test_compile In-Reply-To: <1513596243.38.0.213398074469.issue32365@psf.upfronthosting.co.za> Message-ID: <1513596354.44.0.213398074469.issue32365@psf.upfronthosting.co.za> STINNER Victor added the comment: Python 3.6 and master are affected by the issue. Buildbots: * x86 Gentoo Refleaks 3.x * AMD64 Windows8.1 Refleaks 3.x * AMD64 Windows8.1 Refleaks 3.6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 06:29:07 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 11:29:07 +0000 Subject: [issue32365] Reference leak: test_ast test_builtin test_compile In-Reply-To: <1513596243.38.0.213398074469.issue32365@psf.upfronthosting.co.za> Message-ID: <1513596547.44.0.213398074469.issue32365@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- title: Referenc leak: test_ast test_builtin test_compile -> Reference leak: test_ast test_builtin test_compile versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 06:37:43 2017 From: report at bugs.python.org (iMath) Date: Mon, 18 Dec 2017 11:37:43 +0000 Subject: [issue32366] suggestion:html.escape(s, quote=True) escape \n to
Message-ID: <1513597063.07.0.213398074469.issue32366@psf.upfronthosting.co.za> New submission from iMath : It would be better if html.escape(s, quote=True) could escape linefeed to
https://docs.python.org/3/library/html.html#html.escape ---------- components: XML messages: 308546 nosy: redstone-cold priority: normal severity: normal status: open title: suggestion:html.escape(s, quote=True) escape \n to
type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 07:02:13 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Mon, 18 Dec 2017 12:02:13 +0000 Subject: [issue32359] Add getters for all SSLContext internal configuration In-Reply-To: <1513590105.76.0.213398074469.issue32359@psf.upfronthosting.co.za> Message-ID: <1513598533.88.0.213398074469.issue32359@psf.upfronthosting.co.za> Nathaniel Smith added the comment: I think we already hold onto the ALPN list internally. A possibly stickier issue is retrieving certificates, keys, trust db configuration. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 07:10:27 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Dec 2017 12:10:27 +0000 Subject: [issue32365] Reference leak: test_ast test_builtin test_compile In-Reply-To: <1513596243.38.0.213398074469.issue32365@psf.upfronthosting.co.za> Message-ID: <1513599027.71.0.213398074469.issue32365@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +4810 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 07:10:27 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Dec 2017 12:10:27 +0000 Subject: [issue27169] __debug__ is not optimized out at compile time for anything but `if:` and `while:` blocks In-Reply-To: <1464720658.3.0.0366082537286.issue27169@psf.upfronthosting.co.za> Message-ID: <1513599027.78.0.00913614298617.issue27169@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4811 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 07:19:54 2017 From: report at bugs.python.org (Christian Heimes) Date: Mon, 18 Dec 2017 12:19:54 +0000 Subject: [issue32359] Add getters for all SSLContext internal configuration In-Reply-To: <1513590105.76.0.213398074469.issue32359@psf.upfronthosting.co.za> Message-ID: <1513599594.65.0.213398074469.issue32359@psf.upfronthosting.co.za> Christian Heimes added the comment: For certs and keys I have some plans. You might not be able to get hold of the actual private key bits, but it is always possible to get the public bits and key information. The trust store information is pretty much opaque and often loaded by demand. https://docs.python.org/3/library/ssl.html#ssl.SSLContext.get_ca_certs and https://docs.python.org/3/library/ssl.html#ssl.get_default_verify_paths is pretty much everything I know how to retrieve. If find more stuff, I'm more than happy to expose it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 07:29:16 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Dec 2017 12:29:16 +0000 Subject: [issue32365] Reference leak: test_ast test_builtin test_compile In-Reply-To: <1513596243.38.0.213398074469.issue32365@psf.upfronthosting.co.za> Message-ID: <1513600156.61.0.213398074469.issue32365@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset bd6ec4d79e8575df3d08f8a89ba721930032714c by Serhiy Storchaka in branch 'master': bpo-32365: Fix a reference leak when compile __debug__. (#4916) https://github.com/python/cpython/commit/bd6ec4d79e8575df3d08f8a89ba721930032714c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 07:29:16 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Dec 2017 12:29:16 +0000 Subject: [issue27169] __debug__ is not optimized out at compile time for anything but `if:` and `while:` blocks In-Reply-To: <1464720658.3.0.0366082537286.issue27169@psf.upfronthosting.co.za> Message-ID: <1513600156.72.0.912454111764.issue27169@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset bd6ec4d79e8575df3d08f8a89ba721930032714c by Serhiy Storchaka in branch 'master': bpo-32365: Fix a reference leak when compile __debug__. (#4916) https://github.com/python/cpython/commit/bd6ec4d79e8575df3d08f8a89ba721930032714c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 07:30:31 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 Dec 2017 12:30:31 +0000 Subject: [issue32365] Reference leak: test_ast test_builtin test_compile In-Reply-To: <1513596243.38.0.213398074469.issue32365@psf.upfronthosting.co.za> Message-ID: <1513600231.94.0.213398074469.issue32365@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4812 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 07:30:32 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 Dec 2017 12:30:32 +0000 Subject: [issue27169] __debug__ is not optimized out at compile time for anything but `if:` and `while:` blocks In-Reply-To: <1464720658.3.0.0366082537286.issue27169@psf.upfronthosting.co.za> Message-ID: <1513600232.02.0.00913614298617.issue27169@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4813 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 08:11:58 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Dec 2017 13:11:58 +0000 Subject: [issue32365] Reference leak: test_ast test_builtin test_compile In-Reply-To: <1513596243.38.0.213398074469.issue32365@psf.upfronthosting.co.za> Message-ID: <1513602718.2.0.213398074469.issue32365@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 5659743b5693c9e23313a74117948294e35013f4 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6': bpo-32365: Fix a reference leak when compile __debug__. (GH-4916) (#4918) https://github.com/python/cpython/commit/5659743b5693c9e23313a74117948294e35013f4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 08:11:58 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Dec 2017 13:11:58 +0000 Subject: [issue27169] __debug__ is not optimized out at compile time for anything but `if:` and `while:` blocks In-Reply-To: <1464720658.3.0.0366082537286.issue27169@psf.upfronthosting.co.za> Message-ID: <1513602718.28.0.912454111764.issue27169@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 5659743b5693c9e23313a74117948294e35013f4 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6': bpo-32365: Fix a reference leak when compile __debug__. (GH-4916) (#4918) https://github.com/python/cpython/commit/5659743b5693c9e23313a74117948294e35013f4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 08:12:47 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Dec 2017 13:12:47 +0000 Subject: [issue32365] Reference leak: test_ast test_builtin test_compile In-Reply-To: <1513596243.38.0.213398074469.issue32365@psf.upfronthosting.co.za> Message-ID: <1513602767.03.0.213398074469.issue32365@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Victor. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 08:15:27 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 18 Dec 2017 13:15:27 +0000 Subject: [issue32221] Converting ipv6 address to string representation using getnameinfo() is wrong. In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za> Message-ID: <1513602927.11.0.213398074469.issue32221@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- versions: -Python 3.6, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 08:16:15 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 18 Dec 2017 13:16:15 +0000 Subject: [issue32221] Converting ipv6 address to string representation using getnameinfo() is wrong. In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za> Message-ID: <1513602975.33.0.213398074469.issue32221@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > `recvfrom` from multicast socket is painfull slow. What do you mean? Can you give results for a benchmark of your choice? How much does your PR speed it up? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 08:28:31 2017 From: report at bugs.python.org (Matthias Klose) Date: Mon, 18 Dec 2017 13:28:31 +0000 Subject: [issue1294959] Problems with /usr/lib64 builds. Message-ID: <1513603711.72.0.213398074469.issue1294959@psf.upfronthosting.co.za> Matthias Klose added the comment: the patch looks ok. was it tested on a Debian or Ubuntu system to produce the same layout with this patch and without the new configure option? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 08:34:22 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Dec 2017 13:34:22 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1513604062.95.0.213398074469.issue32259@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > I would add 'non-iterable', to get "cannot unpack non-iterable int object", to tell people what is needed instead. Doesn't this imply that there are iterable int objects which can be unpacked? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 08:37:06 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 Dec 2017 13:37:06 +0000 Subject: [issue32276] there is no way to make tempfile reproducible (i.e. seed the used RNG) In-Reply-To: <1513002327.33.0.213398074469.issue32276@psf.upfronthosting.co.za> Message-ID: <1513604226.52.0.213398074469.issue32276@psf.upfronthosting.co.za> R. David Murray added the comment: IMO it is better to have an API that can be used when, for example, writing tests, than to monkey patch. On the other hand, I've never had an occasion when I cared about the names of tempfiles (or directories) in my test code, and it is hard to imagine a circumstance when being able to reproduce the sequence of tempfile names chosen would matter for debugging...especially since which filenames are actually chosen from the randomly generated sequence can depend on other activity on the system. So I concur with the rejection. I wouldn't object to some sort of API that allowed one to control the filename generation without worrying that later changes to the module would break ones code, but that isn't actually the use case here, so no one has actually asked for this feature ;) ---------- nosy: +r.david.murray resolution: fixed -> rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 08:39:19 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Dec 2017 13:39:19 +0000 Subject: [issue30416] constant folding opens compiler to quadratic time hashing In-Reply-To: <1495314097.2.0.680001526088.issue30416@psf.upfronthosting.co.za> Message-ID: <1513604358.99.0.213398074469.issue30416@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PR 4896 fixes this issue in 2.7, but I'm not sure that I want to merge it. The code in 2.7 is more complex because of two integer types. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 09:01:59 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 Dec 2017 14:01:59 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513605719.14.0.213398074469.issue32361@psf.upfronthosting.co.za> Change by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 09:04:06 2017 From: report at bugs.python.org (sblondon) Date: Mon, 18 Dec 2017 14:04:06 +0000 Subject: [issue32234] Add context management to mailbox.Mailbox In-Reply-To: <1512947519.97.0.213398074469.issue32234@psf.upfronthosting.co.za> Message-ID: sblondon added the comment: If the access is read-only, the lock is not required [1]. However, I agree it does not worth to be more complex (changing the signature of the subclass or adding another context manager for the lock). I updated the patch and documentation so the mailbox is locked at the __enter__(). 1: For example, the first source code example at https://docs.python.org/3/library/mailbox.html#examples ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 09:08:09 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 Dec 2017 14:08:09 +0000 Subject: [issue32366] suggestion:html.escape(s, quote=True) escape \n to
In-Reply-To: <1513597063.07.0.213398074469.issue32366@psf.upfronthosting.co.za> Message-ID: <1513606089.33.0.213398074469.issue32366@psf.upfronthosting.co.za> R. David Murray added the comment: The point of html.escape is to sanitize a string that contains html such that *it does not get interpreted as html*. So adding html markup would go against its purpose. Further, including
in an attribute value (which is the purpose of quote=True) would make no sense and serve no purpose that I can see. Clearly you have a use case in mind, but you did not describe it. I would recommend posting to the python-list mailing list for advice on the best way to accomplish your use case. ---------- components: +Library (Lib) -XML nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 09:27:34 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 14:27:34 +0000 Subject: [issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za> Message-ID: <1513607254.65.0.213398074469.issue31900@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh. Another Python function is impacted by the bug, str.format: $ env -i python3 -c 'import locale; locale.setlocale(locale.LC_ALL, "fr_FR"); locale.setlocale(locale.LC_NUMERIC, "es_MX.utf8"); print(ascii(f"{1000:n}"))' '1\xe2\x80\x89000' It should be '1\u2009000' ('1', '\u2009', '000'). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 09:27:51 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 14:27:51 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513607271.01.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4814 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 09:31:51 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 14:31:51 +0000 Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za> Message-ID: <1513607511.33.0.213398074469.issue19977@psf.upfronthosting.co.za> STINNER Victor added the comment: Follow-up: the PEP 538 (bpo-28180) and PEP 540 (bpo-29240) have been accepted and implemented in Python 3.7! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 09:32:57 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 14:32:57 +0000 Subject: [issue19847] Setting the default filesystem-encoding In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za> Message-ID: <1513607577.61.0.213398074469.issue19847@psf.upfronthosting.co.za> STINNER Victor added the comment: Follow-up: the PEP 538 (bpo-28180) and PEP 540 (bpo-29240) have been accepted and implemented in Python 3.7. Python 3.7 will now use UTF-8 by default for the POSIX locale, and the encoding can be forced to UTF-8 using -X utf8 option. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 09:36:01 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 14:36:01 +0000 Subject: [issue29042] os.path.exists should not throw "Embedded NUL character" exception In-Reply-To: <1482381388.92.0.462077532018.issue29042@psf.upfronthosting.co.za> Message-ID: <1513607761.53.0.213398074469.issue29042@psf.upfronthosting.co.za> STINNER Victor added the comment: > A path containing an embedded NUL character simply cannot name an existing file, and therefore os.path.exists should return False for such a path. I disagree. Python doesn't call the syscall and so must raise a different exception. You must not pass a path with embedded NULL character/byte. That's all. Write your own wrapper to os.path.exists() if you want to a different behaviour. ---------- nosy: +vstinner resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 09:36:37 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 14:36:37 +0000 Subject: [issue22016] Add a new 'surrogatereplace' output only error handler In-Reply-To: <1405855154.64.0.953436457536.issue22016@psf.upfronthosting.co.za> Message-ID: <1513607797.57.0.213398074469.issue22016@psf.upfronthosting.co.za> STINNER Victor added the comment: Follow-up: the PEP 538 (bpo-28180) and PEP 540 (bpo-29240) have been accepted and implemented in Python 3.7! ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 09:36:59 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 14:36:59 +0000 Subject: [issue21368] Check for systemd locale on startup if current locale is set to POSIX In-Reply-To: <1398627025.84.0.804520187603.issue21368@psf.upfronthosting.co.za> Message-ID: <1513607819.08.0.213398074469.issue21368@psf.upfronthosting.co.za> STINNER Victor added the comment: Follow-up: the PEP 538 (bpo-28180) and PEP 540 (bpo-29240) have been accepted and implemented in Python 3.7! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 09:38:09 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 14:38:09 +0000 Subject: [issue19846] Python 3 raises Unicode errors with the C locale In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za> Message-ID: <1513607889.08.0.213398074469.issue19846@psf.upfronthosting.co.za> STINNER Victor added the comment: Follow-up: the PEP 538 (bpo-28180) and PEP 540 (bpo-29240) have been accepted and implemented in Python 3.7! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 09:39:09 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 14:39:09 +0000 Subject: [issue20329] zipfile.extractall fails in Posix shell with utf-8 filename In-Reply-To: <1390316753.93.0.767122614569.issue20329@psf.upfronthosting.co.za> Message-ID: <1513607949.5.0.213398074469.issue20329@psf.upfronthosting.co.za> STINNER Victor added the comment: > I don't think that we can fix this bug, sadly. But I'm happy to see that the PEP 538 and PEP 540 are already useful! Oops, I mean "we cannot *close* this bug" (right now). Sorry. I mean that IMHO we still have to fix the bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 09:59:52 2017 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 18 Dec 2017 14:59:52 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1513609192.6.0.213398074469.issue15873@psf.upfronthosting.co.za> Paul Ganssle added the comment: > Not if the time is associated with a particular day. Imagine implementing datetime.fromisoformat by separately calling date.fromisoformat and time.fromisoformat. The date will be off by one day if you naively rounded 2017-12-18 23:59 ?up? to 2017-12-18 00:00. Yes, I suppose this is a problem if you implement it that way. Seems like a somewhat moot point, but I think any decision about rounding should probably be driven by what people are expecting more than by how it is implemented. That said, I can see a good case for truncation *and* rounding up for something like '2016-12-31T23:59:59.999999999'. Rounding up to '2017-01-01' is certainly the closest whole millisecond to round to, *but* often people expressing a "23:59:59.9999999" are trying to actually express "the last possible moment *before* 00:00". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 11:11:18 2017 From: report at bugs.python.org (Camion) Date: Mon, 18 Dec 2017 16:11:18 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513613478.16.0.213398074469.issue32361@psf.upfronthosting.co.za> Camion added the comment: I forgot to mention, that I wonder if the interpreter shouldn't instead, - either consider that since global a is used is g, it should be considered as also local to g from h point of view, - or if h should be able to access f's version of a. - (or if on the contrary, this ambiguity is the very reason to cause a syntax error, -- but in this case, one might need to change the text of the error message to make it more accurate. --) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 11:15:41 2017 From: report at bugs.python.org (Alexey Izbyshev) Date: Mon, 18 Dec 2017 16:15:41 +0000 Subject: [issue32236] open() shouldn't silently ignore buffering=1 in binary mode In-Reply-To: <1512604009.3.0.213398074469.issue32236@psf.upfronthosting.co.za> Message-ID: <1513613741.13.0.213398074469.issue32236@psf.upfronthosting.co.za> Alexey Izbyshev added the comment: I had similar thoughts when I was fixing tests that broke due to ValueError. I've updated the PR to issue a RuntimeWarning instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 11:29:03 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 16:29:03 +0000 Subject: [issue32367] CVE-2017-17522: webbrowser.py in Python does not validate strings Message-ID: <1513614543.15.0.213398074469.issue32367@psf.upfronthosting.co.za> New submission from STINNER Victor : https://security-tracker.debian.org/tracker/CVE-2017-17522 Lib/webbrowser.py in Python through 3.6.3 does not validate strings before launching the program specified by the BROWSER environment variable, which might allow remote attackers to conduct argument-injection attacks via a crafted URL. ---------- components: Library (Lib) messages: 308572 nosy: vstinner priority: normal severity: normal status: open title: CVE-2017-17522: webbrowser.py in Python does not validate strings type: security versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 11:29:24 2017 From: report at bugs.python.org (Stefan Nordhausen) Date: Mon, 18 Dec 2017 16:29:24 +0000 Subject: [issue32368] Segfault when compiling many conditional expressions Message-ID: <1513614564.0.0.213398074469.issue32368@psf.upfronthosting.co.za> New submission from Stefan Nordhausen : The following code reproducibly segfaults in version 2.7.13, 3.6.3 and the current git master (3.7.0a3+): code = "42 if True else 43\n" * 200000 compile(code, "foobar", "exec") This issue was originally found because the Jinja templating engine internally produces large tuples with many conditional expressions, thus triggering this bug (see https://github.com/pallets/jinja/issues/784 ). ---------- components: Interpreter Core messages: 308573 nosy: snordhausen priority: normal severity: normal status: open title: Segfault when compiling many conditional expressions type: crash versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 11:29:29 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 16:29:29 +0000 Subject: [issue32367] [Security] CVE-2017-17522: webbrowser.py in Python does not validate strings In-Reply-To: <1513614543.15.0.213398074469.issue32367@psf.upfronthosting.co.za> Message-ID: <1513614569.13.0.213398074469.issue32367@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- title: CVE-2017-17522: webbrowser.py in Python does not validate strings -> [Security] CVE-2017-17522: webbrowser.py in Python does not validate strings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 11:31:33 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 16:31:33 +0000 Subject: [issue32367] [Security] CVE-2017-17522: webbrowser.py in Python does not validate strings In-Reply-To: <1513614543.15.0.213398074469.issue32367@psf.upfronthosting.co.za> Message-ID: <1513614693.88.0.213398074469.issue32367@psf.upfronthosting.co.za> STINNER Victor added the comment: Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-17522 Ubuntu: https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-17522.html SUSE: https://bugzilla.novell.com/show_bug.cgi?id=CVE-2017-17522 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 11:42:20 2017 From: report at bugs.python.org (Christian Heimes) Date: Mon, 18 Dec 2017 16:42:20 +0000 Subject: [issue32368] Segfault when compiling many conditional expressions In-Reply-To: <1513614564.0.0.213398074469.issue32368@psf.upfronthosting.co.za> Message-ID: <1513615340.22.0.213398074469.issue32368@psf.upfronthosting.co.za> Christian Heimes added the comment: Looks like 174,565 stack frames are a bit too much :) (gdb) bt #0 dfs (c=0x7fffffffcbe0, b=0x7fffea076d60, a=0x7fffffffcb50) at Python/compile.c:4903 #1 0x00000000004e47a2 in dfs (c=0x7fffffffcbe0, b=0x7fffea076db0, a=0x7fffffffcb50) at Python/compile.c:4903 #2 0x00000000004e47a2 in dfs (c=0x7fffffffcbe0, b=0x7fffea076cc0, a=0x7fffffffcb50) at Python/compile.c:4903 #3 0x00000000004e47a2 in dfs (c=0x7fffffffcbe0, b=0x7fffea076d10, a=0x7fffffffcb50) at Python/compile.c:4903 #4 0x00000000004e47a2 in dfs (c=0x7fffffffcbe0, b=0x7fffea076c20, a=0x7fffffffcb50) at Python/compile.c:4903 #5 0x00000000004e47a2 in dfs (c=0x7fffffffcbe0, b=0x7fffea076c70, a=0x7fffffffcb50) at Python/compile.c:4903 #6 0x00000000004e47a2 in dfs (c=0x7fffffffcbe0, b=0x7fffea076b80, a=0x7fffffffcb50) at Python/compile.c:4903 #7 0x00000000004e47a2 in dfs (c=0x7fffffffcbe0, b=0x7fffea076bd0, a=0x7fffffffcb50) at Python/compile.c:4903 #8 0x00000000004e47a2 in dfs (c=0x7fffffffcbe0, b=0x7fffea076ae0, a=0x7fffffffcb50) at Python/compile.c:4903 #9 0x00000000004e47a2 in dfs (c=0x7fffffffcbe0, b=0x7fffea076b30, a=0x7fffffffcb50) at Python/compile.c:4903 #10 0x00000000004e47a2 in dfs (c=0x7fffffffcbe0, b=0x7fffea076a40, a=0x7fffffffcb50) at Python/compile.c:4903 #11 0x00000000004e47a2 in dfs (c=0x7fffffffcbe0, b=0x7fffea076a90, a=0x7fffffffcb50) at Python/compile.c:4903 #12 0x00000000004e47a2 in dfs (c=0x7fffffffcbe0, b=0x7fffea0769a0, a=0x7fffffffcb50) at Python/compile.c:4903 #13 0x00000000004e47a2 in dfs (c=0x7fffffffcbe0, b=0x7fffea0769f0, a=0x7fffffffcb50) at Python/compile.c:4903 #14 0x00000000004e47a2 in dfs (c=0x7fffffffcbe0, b=0x7fffea076900, a=0x7fffffffcb50) at Python/compile.c:4903 (gdb) bt -50 ... #174562 0x00000000004e47a2 in dfs (c=0x7fffffffcbe0, b=0x7ffff04609a0, a=0x7fffffffcb50) at Python/compile.c:4903 #174563 0x00000000004e47a2 in dfs (c=0x7fffffffcbe0, b=0x7ffff04609f0, a=0x7fffffffcb50) at Python/compile.c:4903 #174564 0x00000000004e47a2 in dfs (c=0x7fffffffcbe0, b=0x7ffff0460900, a=0x7fffffffcb50) at Python/compile.c:4903 #174565 0x00000000004e47a2 in dfs (c=0x7fffffffcbe0, b=0x7ffff0460950, a=0x7fffffffcb50) at Python/compile.c:4903 #174566 0x00000000004e47a2 in dfs (c=c at entry=0x7fffffffcbe0, b=b at entry=0x7ffff04608b0, a=a at entry=0x7fffffffcb50) at Python/compile.c:4903 #174567 0x00000000004e9844 in assemble (c=c at entry=0x7fffffffcbe0, addNone=) at Python/compile.c:5411 #174568 0x00000000004ed809 in compiler_mod (c=c at entry=0x7fffffffcbe0, mod=mod at entry=0x3523788) at Python/compile.c:1494 #174569 0x00000000004eda33 in PyAST_CompileObject (mod=0x3523788, filename=filename at entry='foobar', flags=flags at entry=0x7fffffffccb4, optimize=optimize at entry=-1, arena=arena at entry=0x7ffff0466f40) at Python/compile.c:345 #174570 0x000000000050fcaa in Py_CompileStringObject ( str=0x7fffef9d1070 "42 if True else 43\n42 if True else 43\n42 if True else 43\n42 if True else 43\n42 if True else 43\n42 if True else 43\n42 if True else 43\n42 if True else 43\n42 if True else 43\n42 if True else 43\n42 if True"..., filename=filename at entry='foobar', start=start at entry=257, flags=flags at entry=0x7fffffffccb4, optimize=optimize at entry=-1) at Python/pythonrun.c:1098 #174571 0x00000000004d2146 in builtin_compile_impl (module=module at entry=, ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 11:51:06 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Dec 2017 16:51:06 +0000 Subject: [issue32368] Segfault when compiling many conditional expressions In-Reply-To: <1513614564.0.0.213398074469.issue32368@psf.upfronthosting.co.za> Message-ID: <1513615866.12.0.213398074469.issue32368@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Duplicate of issue31113? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 11:57:52 2017 From: report at bugs.python.org (Charalampos Stratakis) Date: Mon, 18 Dec 2017 16:57:52 +0000 Subject: [issue32367] [Security] CVE-2017-17522: webbrowser.py in Python does not validate strings In-Reply-To: <1513614543.15.0.213398074469.issue32367@psf.upfronthosting.co.za> Message-ID: <1513616272.92.0.213398074469.issue32367@psf.upfronthosting.co.za> Change by Charalampos Stratakis : ---------- nosy: +cstratak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 12:08:45 2017 From: report at bugs.python.org (Christian Heimes) Date: Mon, 18 Dec 2017 17:08:45 +0000 Subject: [issue32368] Segfault when compiling many conditional expressions In-Reply-To: <1513614564.0.0.213398074469.issue32368@psf.upfronthosting.co.za> Message-ID: <1513616925.4.0.213398074469.issue32368@psf.upfronthosting.co.za> Christian Heimes added the comment: I think so, too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 12:24:15 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 17:24:15 +0000 Subject: [issue32357] Optimize asyncio.iscoroutine() and loop.create_task() for non-native coroutines In-Reply-To: <1513575220.77.0.213398074469.issue32357@psf.upfronthosting.co.za> Message-ID: <1513617855.63.0.213398074469.issue32357@psf.upfronthosting.co.za> Change by Yury Selivanov : Added file: https://bugs.python.org/file47337/bench.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 13:05:24 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 18:05:24 +0000 Subject: [issue32364] Add AbstractFuture and AbstractTask In-Reply-To: <1513595590.31.0.213398074469.issue32364@psf.upfronthosting.co.za> Message-ID: <1513620324.89.0.213398074469.issue32364@psf.upfronthosting.co.za> Yury Selivanov added the comment: +1, let's do it. I'd add a new module - 'asyncio.abc' and put them both there (as well as asyncio.isfuture() function). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 13:05:48 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 18:05:48 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() In-Reply-To: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> Message-ID: <1513620348.85.0.213398074469.issue32363@psf.upfronthosting.co.za> Yury Selivanov added the comment: +1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 13:45:30 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 18 Dec 2017 18:45:30 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513622730.35.0.213398074469.issue32361@psf.upfronthosting.co.za> R. David Murray added the comment: What is happening here is that what nonlocal does is give the function containing the nonlocal statement access to the "cell" in the parent function that holds the local variable of that function. When you use a global statement, the name instead refers to a global variable, and there is no local cell created for that variable name. Thus you get "no binding [cell] for nonlocal 'a' found". That is literally correct from the compiler's point of view. I agree that this message is mysterious unless you understand how python scoping works at a fairly detailed level, and thus it would be nice if the error message could be improved. The code generating the message may not know that there's a global statement for that name in effect, though, so it might not be trivial to improve it. Would it be possible for nonlocal to effectively "chain", and turn the references in the inner function into global references? In theory the answer would be yes, but in practice it might be distinctly non-trivial, and would probably be a PEP level change to the language. It is currently documented that nonlocal does not look in to the global namespace (https://docs.python.org/3/reference/simple_stmts.html#nonlocal): "The nonlocal statement causes the listed identifiers to refer to previously bound variables in the nearest enclosing scope excluding globals.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 14:23:30 2017 From: report at bugs.python.org (Alexey Izbyshev) Date: Mon, 18 Dec 2017 19:23:30 +0000 Subject: [issue32369] test_subprocess: last part of test_close_fds() doesn't check what's intended Message-ID: <1513625010.32.0.213398074469.issue32369@psf.upfronthosting.co.za> New submission from Alexey Izbyshev : The last part of test_close_fds() doesn't match its own comment. The following assertion always holds because fds_to_keep and open_fds are disjoint by construction. self.assertFalse(remaining_fds & fds_to_keep & open_fds, "Some fds not in pass_fds were left open") ---------- components: Tests messages: 308581 nosy: izbyshev priority: normal severity: normal status: open title: test_subprocess: last part of test_close_fds() doesn't check what's intended type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 14:28:31 2017 From: report at bugs.python.org (Alexey Izbyshev) Date: Mon, 18 Dec 2017 19:28:31 +0000 Subject: [issue32369] test_subprocess: last part of test_close_fds() doesn't check what's intended In-Reply-To: <1513625010.32.0.213398074469.issue32369@psf.upfronthosting.co.za> Message-ID: <1513625311.62.0.213398074469.issue32369@psf.upfronthosting.co.za> Change by Alexey Izbyshev : ---------- nosy: +gregory.p.smith, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 14:33:32 2017 From: report at bugs.python.org (Alexey Izbyshev) Date: Mon, 18 Dec 2017 19:33:32 +0000 Subject: [issue32369] test_subprocess: last part of test_close_fds() doesn't check what's intended In-Reply-To: <1513625010.32.0.213398074469.issue32369@psf.upfronthosting.co.za> Message-ID: <1513625612.44.0.213398074469.issue32369@psf.upfronthosting.co.za> Change by Alexey Izbyshev : ---------- keywords: +patch pull_requests: +4815 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 15:26:53 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 18 Dec 2017 20:26:53 +0000 Subject: [issue32369] test_subprocess: last part of test_close_fds() doesn't check what's intended In-Reply-To: <1513625010.32.0.213398074469.issue32369@psf.upfronthosting.co.za> Message-ID: <1513628813.56.0.213398074469.issue32369@psf.upfronthosting.co.za> Gregory P. Smith added the comment: New changeset 2d8f06382e7d5a759ca554110a699a397114824a by Gregory P. Smith (izbyshev) in branch 'master': bpo-32369: test_subprocess: Fix pass_fds check in test_close_fds() (#4920) https://github.com/python/cpython/commit/2d8f06382e7d5a759ca554110a699a397114824a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 15:32:16 2017 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 18 Dec 2017 20:32:16 +0000 Subject: [issue32278] Allow dataclasses.make_dataclass() to omit type information In-Reply-To: <1513021651.3.0.213398074469.issue32278@psf.upfronthosting.co.za> Message-ID: <1513629136.02.0.213398074469.issue32278@psf.upfronthosting.co.za> Eric V. Smith added the comment: I'm going to use "typing.Any" (as a string) if the type information is omitted in the call to make_dataclass(). That way I don't need to import typing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 15:50:41 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 18 Dec 2017 20:50:41 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1513630241.65.0.213398074469.issue32259@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In English, 'adjective noun' does not necessarily imply the existence of 'not-adjective' nouns, and the adjective may serve as a reminder or reason. For instance, "This job is too dangerous for mortal humans!" In the current context, failure of 'iter(ob)', by itself, only tells us that the particular object ob is not iterable. "'X' object is not iterable", rather that "'X' objects are not iterable", is correct. (Ditto for other messages.) That said, I think "cannot unpack int object, because not iterable" is better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 16:40:26 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 18 Dec 2017 21:40:26 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1513633226.62.0.213398074469.issue32259@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is it worth to emit more specific (but possible uniform) error messages in other unpacking cases (see msg307999)? FYI if a class implements __iter__ which returns non-iterable, the following error is raised: >>> class C: ... def __iter__(self): ... return 1 ... >>> a, b = C() Traceback (most recent call last): File "", line 1, in TypeError: iter() returned non-iterator of type 'int' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 16:59:47 2017 From: report at bugs.python.org (Brett Cannon) Date: Mon, 18 Dec 2017 21:59:47 +0000 Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7 In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za> Message-ID: <1513634387.03.0.213398074469.issue32248@psf.upfronthosting.co.za> Brett Cannon added the comment: Yep, I assumed implementing the ReourceReader API would be a separate step. As for the type hints, I thought it was lifted such that new code could include it but we wouldn't be taking PRs to add them to pre-existing code? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 17:03:29 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 22:03:29 +0000 Subject: [issue32356] asyncio: Make transport.pause_reading()/resume_reading() idempotent; add transport.is_reading() In-Reply-To: <1513568775.87.0.213398074469.issue32356@psf.upfronthosting.co.za> Message-ID: <1513634609.33.0.213398074469.issue32356@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset d757aaf9dd767d13205bf9917e520ebf43e7f6e5 by Yury Selivanov in branch 'master': bpo-32356: idempotent pause_/resume_reading; new is_reading method. (#4914) https://github.com/python/cpython/commit/d757aaf9dd767d13205bf9917e520ebf43e7f6e5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 17:03:50 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 22:03:50 +0000 Subject: [issue32356] asyncio: Make transport.pause_reading()/resume_reading() idempotent; add transport.is_reading() In-Reply-To: <1513568775.87.0.213398074469.issue32356@psf.upfronthosting.co.za> Message-ID: <1513634630.49.0.213398074469.issue32356@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 17:06:50 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 22:06:50 +0000 Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za> Message-ID: <1513634810.61.0.213398074469.issue20891@psf.upfronthosting.co.za> STINNER Victor added the comment: I ran pyperformance on my PR 4700. Differences of at least 5%: haypo at speed-python$ python3 -m perf compare_to ~/json/uploaded/2017-12-18_12-29-master-bd6ec4d79e85.json.gz /home/haypo/json/patch/2017-12-18_12-29-master-bd6ec4d79e85-patch-4700.json.gz --table --min-speed=5 +----------------------+--------------------------------------+-------------------------------------------------+ | Benchmark | 2017-12-18_12-29-master-bd6ec4d79e85 | 2017-12-18_12-29-master-bd6ec4d79e85-patch-4700 | +======================+======================================+=================================================+ | pathlib | 41.8 ms | 44.3 ms: 1.06x slower (+6%) | +----------------------+--------------------------------------+-------------------------------------------------+ | scimark_monte_carlo | 197 ms | 210 ms: 1.07x slower (+7%) | +----------------------+--------------------------------------+-------------------------------------------------+ | spectral_norm | 243 ms | 269 ms: 1.11x slower (+11%) | +----------------------+--------------------------------------+-------------------------------------------------+ | sqlite_synth | 7.30 us | 8.13 us: 1.11x slower (+11%) | +----------------------+--------------------------------------+-------------------------------------------------+ | unpickle_pure_python | 707 us | 796 us: 1.13x slower (+13%) | +----------------------+--------------------------------------+-------------------------------------------------+ Not significant (55): 2to3; chameleon; chaos; (...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 17:34:22 2017 From: report at bugs.python.org (Alexey Izbyshev) Date: Mon, 18 Dec 2017 22:34:22 +0000 Subject: [issue32369] test_subprocess: last part of test_close_fds() doesn't check what's intended In-Reply-To: <1513625010.32.0.213398074469.issue32369@psf.upfronthosting.co.za> Message-ID: <1513636462.25.0.213398074469.issue32369@psf.upfronthosting.co.za> Change by Alexey Izbyshev : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 17:34:53 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 22:34:53 +0000 Subject: [issue32331] Fix socket.type on Linux In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513636493.22.0.213398074469.issue32331@psf.upfronthosting.co.za> STINNER Victor added the comment: This issue is not specific to Linux. FreeBSD is also affected: >>> s=socket.socket() >>> s.type >>> s.setblocking(False) >>> s.type 536870913 See for example https://sourceware.org/ml/libc-alpha/2013-08/msg00528.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 17:36:25 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 22:36:25 +0000 Subject: [issue32331] Fix socket.type on Linux In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513636585.93.0.213398074469.issue32331@psf.upfronthosting.co.za> Yury Selivanov added the comment: > This issue is not specific to Linux. FreeBSD is also affected: So instead of '#ifdef __linux__' we should use `#ifdef SOCK_NONBLOCK` etc. I'll update the PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 17:36:38 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 22:36:38 +0000 Subject: [issue32331] Fix socket.type on Linux In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513636598.76.0.213398074469.issue32331@psf.upfronthosting.co.za> STINNER Victor added the comment: The most portable solution seems to getsockopt(): >>> s.getsockopt(socket.SOL_SOCKET, socket.SO_TYPE) 1 But I would prefer to avoid a syscall just to clear flags :-/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 17:38:30 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 18 Dec 2017 22:38:30 +0000 Subject: [issue32331] Fix socket.type on Linux In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513636710.53.0.213398074469.issue32331@psf.upfronthosting.co.za> Yury Selivanov added the comment: > But I would prefer to avoid a syscall just to clear flags :-/ Yes, that's what I want to do. We control what constants the socket module exports. Let's just clear them if we export them -- that's a good working solution (and also the most backwards compatible, as opposed to calling sock.getsockopt) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 17:42:57 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 18 Dec 2017 22:42:57 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513636977.85.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 6efcb6d3d5911aaf699f9df3bb3bc26e94f38e6d by Victor Stinner in branch 'master': bpo-32030: Fix compilation on FreeBSD, #include (#4919) https://github.com/python/cpython/commit/6efcb6d3d5911aaf699f9df3bb3bc26e94f38e6d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 18:38:34 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Mon, 18 Dec 2017 23:38:34 +0000 Subject: [issue32359] Add getters for all SSLContext internal configuration In-Reply-To: <1513590105.76.0.213398074469.issue32359@psf.upfronthosting.co.za> Message-ID: <1513640314.98.0.213398074469.issue32359@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Yeah, I'm not entirely sure whether fixing this is actually doable or worthwhile, but figured I should at least make an issue to discuss :-). The problem is, in the motivating use case of wanting to be able to reliably convert an SSLContext into some other representation, we really need to be able to get 100% of the configuration out. I think the trust configuration can probably be handled in principle by remembering the arguments to any calls to load_verify_locations, so they can be replayed later. But... that won't work for private keys, because if they're password-protected then replaying a call to load_cert_chain will end up prompting for the password twice. So maybe we really would need a way to pull out the actual private key bits. And if we can't do that, then maybe it's not worth stressing about the other stuff either... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 19:13:25 2017 From: report at bugs.python.org (Segev Finer) Date: Tue, 19 Dec 2017 00:13:25 +0000 Subject: [issue32245] OSError: raw write() returned invalid length on latest Win 10 Consoles In-Reply-To: <1512660082.17.0.213398074469.issue32245@psf.upfronthosting.co.za> Message-ID: <1513642405.62.0.213398074469.issue32245@psf.upfronthosting.co.za> Segev Finer added the comment: Upstream issue https://github.com/Microsoft/console/issues/40, also has links to similar issues this caused in other projects. ---------- nosy: +Segev Finer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 19:17:04 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 19 Dec 2017 00:17:04 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1513642624.82.0.213398074469.issue32259@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I retested and iter(ob) (1) apparently raises 'not iterable' only when it can find neither __iter__ nor __getitem__. It (2) raises 'non-iterator', as above, when it finds __iter__, calls its, and get a non-iterator. (3) Exceptions in __iter__ are passed through. (If it finds and wraps __getitem__, errors only appear during iteration.) The current patch for assignment unpacking catches case (1) with "v->ob_type->tp_iter == NULL && !PySequence_Check(v))". Removing this would catch case (2) and incidentally case (3) TypeErrors. Not catching user TypeErrors would require looking at the message. I intentionally am not proposing to remove the TypeError check. Presuming the existence of a PyErr_' function to get exception messages, we could simply prefix the existing message with a short 'Cannot unpack. ' The same could be done for the other cases in msg307999, but I don't know if they are subject to the same need. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 19:24:51 2017 From: report at bugs.python.org (Segev Finer) Date: Tue, 19 Dec 2017 00:24:51 +0000 Subject: [issue32370] Wrong ANSI encoding used by subprocess for some locales Message-ID: <1513643091.19.0.213398074469.issue32370@psf.upfronthosting.co.za> New submission from Segev Finer : The following test is failing randomly for me (python -m test test_uuid -v): ====================================================================== ERROR: test_ipconfig_getnode (test.test_uuid.TestInternalsWithoutExtModule) ---------------------------------------------------------------------- Traceback (most recent call last): File "cpython\lib\test\test_uuid.py", line 551, in test_ipconfig_getnode node = self.uuid._ipconfig_getnode() File "cpython\lib\uuid.py", line 487, in _ipconfig_getnode for line in pipe: File "cpython\lib\encodings\cp1255.py", line 23, in decode return codecs.charmap_decode(input,self.errors,decoding_table)[0] UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position 682: character maps to This is caused by trying to decode the output of "ipconfig" using cp1255, while the output really uses cp862 and annoyingly it started to print times using the current locale (Which displays broken in the console anyhow, question mark boxes... *sigh*) in some Windows version (Using Windows 10.0.16299 ATM). ---------- components: Windows messages: 308597 nosy: Segev Finer, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Wrong ANSI encoding used by subprocess for some locales type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 19:46:51 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Dec 2017 00:46:51 +0000 Subject: [issue31803] time.clock() should emit a DeprecationWarning In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za> Message-ID: <1513644411.3.0.213398074469.issue31803@psf.upfronthosting.co.za> STINNER Victor added the comment: I read again the whole issue and I dislike the "time.clock becomes an alias to time.perf_counter" idea. Calling time.clock() now emits a deprecation warning, the issue is fixed, so I close it. Many discussions were about removal of the function. IHMO it's out of the scope of this specific issue and should be discussed later, once someone will propose to remove time.clock(). ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 19:50:48 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Dec 2017 00:50:48 +0000 Subject: [issue32324] [Security] "python3 directory" inserts "directory" at sys.path[0] even in isolated mode In-Reply-To: <1513267755.86.0.213398074469.issue32324@psf.upfronthosting.co.za> Message-ID: <1513644648.63.0.213398074469.issue32324@psf.upfronthosting.co.za> STINNER Victor added the comment: A compromise would be to refuse to start on "python3 -I directory" to remain secure and respect -I documentation: https://docs.python.org/dev/using/cmdline.html#id2 "In isolated mode sys.path contains neither the script?s directory nor the user?s site-packages directory." Example of error message: "Running a Python package is incompatible with the isolated mode (-I option)" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 20:00:15 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Dec 2017 01:00:15 +0000 Subject: [issue19100] Use backslashreplace in pprint In-Reply-To: <1380279910.92.0.349060015388.issue19100@psf.upfronthosting.co.za> Message-ID: <1513645215.12.0.213398074469.issue19100@psf.upfronthosting.co.za> STINNER Victor added the comment: $ LANG= ./python -c "import pprint; pprint.pprint('\u20ac')" Thanks to the PEP 538 and PEP 540, this command now works as expected in Python 3.7: vstinner at apu$ LANG= python3.7 -c "import pprint; pprint.pprint('\u20ac')" '?' Do we still need pprint_unencodable_2.patch workaround? ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 20:01:26 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Dec 2017 01:01:26 +0000 Subject: [issue13643] 'ascii' is a bad filesystem default encoding In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za> Message-ID: <1513645286.96.0.213398074469.issue13643@psf.upfronthosting.co.za> STINNER Victor added the comment: Follow-up: the PEP 538 (bpo-28180) and PEP 540 (bpo-29240) have been accepted and implemented in Python 3.7! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 20:01:55 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Dec 2017 01:01:55 +0000 Subject: [issue11574] TextIOWrapper: Unicode Fallback Encoding on Python 3.3 In-Reply-To: <1300296395.6.0.964785890032.issue11574@psf.upfronthosting.co.za> Message-ID: <1513645315.79.0.213398074469.issue11574@psf.upfronthosting.co.za> STINNER Victor added the comment: Follow-up: the PEP 538 (bpo-28180) and PEP 540 (bpo-29240) have been accepted and implemented in Python 3.7! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 20:03:00 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 01:03:00 +0000 Subject: [issue32331] Fix socket.type on Linux In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513645380.43.0.213398074469.issue32331@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 9818142b1bd20243733a953fb8aa2c7be314c47c by Yury Selivanov in branch 'master': bpo-32331: Fix socket.type when SOCK_NONBLOCK is available (#4877) https://github.com/python/cpython/commit/9818142b1bd20243733a953fb8aa2c7be314c47c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 20:08:26 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 01:08:26 +0000 Subject: [issue32331] Fix socket.type on Linux In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513645706.73.0.213398074469.issue32331@psf.upfronthosting.co.za> Yury Selivanov added the comment: I've merged the PR. Summary of the final change: 1. socket.socket(family, type, proto) constructor clears SOCK_NONBLOCK and SOCK_CLOEXEC from 'type' before assigning it to 'sock.type'. 2. socket.socket(family, SOCK_STREAM | SOCK_NONBLOCK) will still create a non-blocking socket. 3. socket.setblocking() no longer sets/unsets SOCK_NONBLOCK flag on sock.type. This is 3.7 only change. Big thanks to Nathaniel and Victor for the help! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 20:09:51 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 01:09:51 +0000 Subject: [issue32331] Fix socket.type on OSes with SOCK_NONBLOCK In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513645791.67.0.213398074469.issue32331@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- title: Fix socket.type on Linux -> Fix socket.type on OSes with SOCK_NONBLOCK _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 20:10:26 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Dec 2017 01:10:26 +0000 Subject: [issue32331] Fix socket.type on OSes with SOCK_NONBLOCK In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513645826.4.0.213398074469.issue32331@psf.upfronthosting.co.za> STINNER Victor added the comment: > This is 3.7 only change. In this case, bpo-27456 should be reopened or a new issue should be opened to fix asyncio in Python 3.6, no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 20:13:44 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Dec 2017 01:13:44 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513646024.73.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4816 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 20:14:15 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 01:14:15 +0000 Subject: [issue32331] Fix socket.type on OSes with SOCK_NONBLOCK In-Reply-To: <1513309369.41.0.213398074469.issue32331@psf.upfronthosting.co.za> Message-ID: <1513646055.0.0.213398074469.issue32331@psf.upfronthosting.co.za> Yury Selivanov added the comment: > In this case, bpo-27456 should be reopened or a new issue should be opened to fix asyncio in Python 3.6, no? I'll make a PR to fix it in 3.7. Code in 3.6 is good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 20:32:44 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 01:32:44 +0000 Subject: [issue27456] asyncio: set TCP_NODELAY flag by default In-Reply-To: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> Message-ID: <1513647164.87.0.213398074469.issue27456@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- pull_requests: +4817 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 21:11:01 2017 From: report at bugs.python.org (Campbell Barton) Date: Tue, 19 Dec 2017 02:11:01 +0000 Subject: [issue32354] Unclear intention of deprecating Py_UNICODE_TOLOWER / Py_UNICODE_TOUPPER In-Reply-To: <1513562412.88.0.213398074469.issue32354@psf.upfronthosting.co.za> Message-ID: <1513649461.66.0.213398074469.issue32354@psf.upfronthosting.co.za> Campbell Barton added the comment: Thanks for the info, in that case will there be a way to do this from the CPython API which can work with raw strings? (utf8, wchat_t or similar types), that doesn't require the GIL and alloc/free of PyObjects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 21:41:17 2017 From: report at bugs.python.org (Christopher Barker) Date: Tue, 19 Dec 2017 02:41:17 +0000 Subject: [issue32216] Document PEP 557 Data Classes In-Reply-To: <1512439511.23.0.213398074469.issue32216@psf.upfronthosting.co.za> Message-ID: <1513651277.65.0.213398074469.issue32216@psf.upfronthosting.co.za> Christopher Barker added the comment: It was suggested that I could contirbute to the docs of dataclasses in this issue. Which confuses me, as there doesn't appear to be any content here to comment on. But what the heck: As I've been annoyingly persistent about on the python-dev list, I think we need to be quite careful about making type hints appear to be a requirement for using dataclasses. In order to counter this, we could: * have the first couple example be type-less: @dataclass class C: a: ... # field without a default b: ... = 0 # field with a default or something like that. Then purposely introduce "how to add type hints" a bit down in the docs. ---------- nosy: +Chris.Barker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 22:39:53 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 03:39:53 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() In-Reply-To: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> Message-ID: <1513654793.7.0.213398074469.issue32363@psf.upfronthosting.co.za> Yury Selivanov added the comment: Actually, I don't think we need a deprecation period. Both methods are completely unusable now. Given: async def foo(): await asyncio.sleep(1) print('AAAAA') return 42 1. Let's try to use Task.set_result(): async def main(): f = asyncio.create_task(foo()) f.set_result(123) result = await f print(result) asyncio.run(main()) This will print "123", but will give us an "AssertionError: _step(): already done: result=123> None" logged. 2. Let's try set_result + a sleep: async def main(): f = asyncio.create_task(foo()) await asyncio.sleep(2) f.set_result(123) result = await f print(result) asyncio.run(main()) This just crashes with an InvalidStateError. 3. Same happens with set_exception(). All in all, deprecation periods are useful when there's some working and useful functionality that has to be removed in the future. In this case there's no working and no useful functionality. So let's just make Task.set_result() and Task.set_exception() raise NotImplementedError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 22:57:54 2017 From: report at bugs.python.org (Camion) Date: Tue, 19 Dec 2017 03:57:54 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513655874.3.0.213398074469.issue32361@psf.upfronthosting.co.za> Camion added the comment: Well, David, I'm convinced this behavior is "logical" and is not some "logic" flaw. My question is more about the fact that it is desirable and was intentionally designed that way,or if on the contrary no one thought it might happen that way and it's not what was wished. I understand that it might be a problem to link to a global (global a), a variable (h's a) which was declared in a non-global way, but is makes sense to have the presence of "global a" in g, block all possibility for h, to access it's grand parent's a. In all case, I believe this should at lease be clearly documented in (or in relation with) PEP 3104 to make sure it has been decided that way, or else it will look like a design hole. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 23:02:25 2017 From: report at bugs.python.org (Camion) Date: Tue, 19 Dec 2017 04:02:25 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513656145.55.0.213398074469.issue32361@psf.upfronthosting.co.za> Camion added the comment: Oops, in my previous post please read : "but does it makes sense to have the presence of "global a" in g, block all possibility for h, to access it's grand parent's a ?" instead of "but is makes sense to [...] grand parent's a." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 23:31:36 2017 From: report at bugs.python.org (Camion) Date: Tue, 19 Dec 2017 04:31:36 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1513657896.16.0.213398074469.issue32259@psf.upfronthosting.co.za> Camion added the comment: thank You Serhiy for your C implementation. About this question of the dilemma around the meaning of "non iterable int" why not simply put the "non iterable" between parenthesis to avoid making it too verbose ? "cannot unpack (non-iterable) int object" or "cannot unpack int object (not iterable) However, I wonder why nearly all the changes I've seen, seem to be about int ? This situation might arise with any non-iterable type (I got it first with Fraction). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 18 23:50:03 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 04:50:03 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() In-Reply-To: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> Message-ID: <1513659003.72.0.213398074469.issue32363@psf.upfronthosting.co.za> Yury Selivanov added the comment: About the only use case I can come up with is subclassing asyncio.Task and overriding set_result and set_exception implementations. This use case has been broken (unintentionally) in Python 3.6, when we first implemented Task in _asynciomodule.c. C Task doesn't try to resolve 'self.set_result()' or 'self.set_exception()'. It calls the C "super" implementations instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 00:39:55 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 05:39:55 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() In-Reply-To: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> Message-ID: <1513661995.67.0.213398074469.issue32363@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4818 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 00:44:09 2017 From: report at bugs.python.org (Eryk Sun) Date: Tue, 19 Dec 2017 05:44:09 +0000 Subject: [issue32370] Wrong ANSI encoding used by subprocess for some locales In-Reply-To: <1513643091.19.0.213398074469.issue32370@psf.upfronthosting.co.za> Message-ID: <1513662249.68.0.213398074469.issue32370@psf.upfronthosting.co.za> Eryk Sun added the comment: ipconfig uses (or defaults to) OEM encoded output when writing to a pipe or file. On the other hand, Python's TextIOWrapper defaults to ANSI (i.e. 'mbcs'). In 3.6+, uuid._ipconfig_getnode could be rewritten to call subprocess.Popen with the new 'oem' encoding. In Windows 10, the networking command-line utilities (e.g. ipconfig, netstat, nbtstat, ping, tracert, hostname, finger, and ftp) support an "OutputEncoding" environment variable. Its value can be set to "Unicode" (UTF-16), "UTF-8", or "Ansi". I don't think this is supported in Windows 7, however. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 01:12:05 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 19 Dec 2017 06:12:05 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1513663925.08.0.213398074469.issue32259@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 'int' is a standin for non-iterable and easy to type. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 01:20:46 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 19 Dec 2017 06:20:46 +0000 Subject: [issue31094] asyncio: get list of connected clients In-Reply-To: <1501564064.1.0.785973244818.issue31094@psf.upfronthosting.co.za> Message-ID: <1513664446.17.0.213398074469.issue31094@psf.upfronthosting.co.za> Andrew Svetlov added the comment: This tracker is not the best place for questions about development *with* Python -- it is for questions for development *of* Python itself. Please use resources like StackOverflow next time. `asyncio.Server.sockets` is a list of connected socket objects -- but usually Protocol implementation handles a list of alive clients separately, protocol.connection_made() and protocol.connection_lost() allows to do it easy. ---------- nosy: +asvetlov resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 01:37:49 2017 From: report at bugs.python.org (Steve Dower) Date: Tue, 19 Dec 2017 06:37:49 +0000 Subject: [issue32324] [Security] "python3 directory" inserts "directory" at sys.path[0] even in isolated mode In-Reply-To: <1513267755.86.0.213398074469.issue32324@psf.upfronthosting.co.za> Message-ID: <1513665469.65.0.213398074469.issue32324@psf.upfronthosting.co.za> Steve Dower added the comment: > A compromise would be to refuse to start on "python3 -I directory" to remain secure What would that achieve, considering that "python3 -I directory/__main__.py" would let you start with exactly the same sys.path?[*] The only change that might be of any value would be to resolve the path as early as possible so that an absolute path is added to sys.path[0]. Not adding the directory of the startup script is a breaking change with no security benefits -- it has to stay there. -I is not a protection against command-line arguments. [*] On Windows, using the filename seems to resolve the directory while using just the directory name does not. I'm not sure why they aren't identical, and obviously I think they should be, but I'd expect the initialization work to streamline it (when getpath.c becomes sensible). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 02:02:52 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Dec 2017 07:02:52 +0000 Subject: [issue19100] Use backslashreplace in pprint In-Reply-To: <1380279910.92.0.349060015388.issue19100@psf.upfronthosting.co.za> Message-ID: <1513666972.28.0.213398074469.issue19100@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Try with LANG=en_US. And even UTF-8 can fail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 02:06:25 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Dec 2017 07:06:25 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513667185.39.0.213398074469.issue32361@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 02:50:50 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 19 Dec 2017 07:50:50 +0000 Subject: [issue32284] typing.TextIO and BinaryIO are not aliases of IO[...] In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za> Message-ID: <1513669850.88.0.213398074469.issue32284@psf.upfronthosting.co.za> Ned Deily added the comment: New changeset 898a3e4901b3b6de9b540e18faa457a6ac3e49bb by Ned Deily (Miss Islington (bot)) in branch '3.6': bpo-32284: Fix documentation of BinaryIO and TextIO (GH-4832) (#4833) https://github.com/python/cpython/commit/898a3e4901b3b6de9b540e18faa457a6ac3e49bb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 03:17:04 2017 From: report at bugs.python.org (Camion) Date: Tue, 19 Dec 2017 08:17:04 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1513671424.75.0.213398074469.issue32259@psf.upfronthosting.co.za> Camion added the comment: Even in the code !?? I may have missed something, but I based my question on what I read in the pull request... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 03:50:39 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Dec 2017 08:50:39 +0000 Subject: [issue27942] Default value identity regression In-Reply-To: <1472834737.57.0.822205168917.issue27942@psf.upfronthosting.co.za> Message-ID: <1513673439.59.0.213398074469.issue27942@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: -1087 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 03:54:24 2017 From: report at bugs.python.org (Ned Deily) Date: Tue, 19 Dec 2017 08:54:24 +0000 Subject: [issue28791] update SQLite libraries for Windows and macOS installers In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1513673664.02.0.213398074469.issue28791@psf.upfronthosting.co.za> Ned Deily added the comment: Looks like unless Benjamin would like 2.7.x updated, this can now be closed. ---------- assignee: -> benjamin.peterson priority: deferred blocker -> status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 04:06:27 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Dec 2017 09:06:27 +0000 Subject: [issue30416] constant folding opens compiler to quadratic time hashing In-Reply-To: <1495314097.2.0.680001526088.issue30416@psf.upfronthosting.co.za> Message-ID: <1513674387.96.0.213398074469.issue30416@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What do you suggest to do with 2.7? Revert the changes that introduced the regression, merge the backported fix, or keep all as is? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 04:45:32 2017 From: report at bugs.python.org (Stefan Krah) Date: Tue, 19 Dec 2017 09:45:32 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513676732.2.0.213398074469.issue32361@psf.upfronthosting.co.za> Stefan Krah added the comment: > Does it makes sense to have the presence of "global a" in g, block all possibility for h, to access it's grand parent's a ? >From the perspective of ML-style languages with pure lexical scoping, no, it does not make sense. But Python started with C-like simple name spaces, then nested functions and 'nonlocal' were added. I think the answer (as usual) is that people may rely on the established convention and that it is no problem in practice. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 04:54:17 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 19 Dec 2017 09:54:17 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1513677257.54.0.213398074469.issue32259@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Yes, in the code for the the unpack message test, the specific non-iterable is not relevant. These are not tests of the iter builtin. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 05:29:36 2017 From: report at bugs.python.org (Camion) Date: Tue, 19 Dec 2017 10:29:36 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1513679376.28.0.213398074469.issue32259@psf.upfronthosting.co.za> Camion added the comment: Ok then. Thank you :-) It also seemed strange that there were so many messages about int ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 05:31:40 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Dec 2017 10:31:40 +0000 Subject: [issue32367] [Security] CVE-2017-17522: webbrowser.py in Python does not validate strings In-Reply-To: <1513614543.15.0.213398074469.issue32367@psf.upfronthosting.co.za> Message-ID: <1513679500.29.0.213398074469.issue32367@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 05:36:04 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Dec 2017 10:36:04 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513679764.96.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 5d8624647d0b8ccb22b17b9e819a8e0c3fb4fe4a by Victor Stinner in branch 'master': bpo-32030: Fix compiler warnings (#4921) https://github.com/python/cpython/commit/5d8624647d0b8ccb22b17b9e819a8e0c3fb4fe4a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 06:44:44 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 11:44:44 +0000 Subject: [issue27456] asyncio: set TCP_NODELAY flag by default In-Reply-To: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> Message-ID: <1513683884.66.0.213398074469.issue27456@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset a7bd64c0c01379e9b82e86ad41a301329a0775d9 by Yury Selivanov in branch 'master': bpo-27456: Simplify sock type checks (#4922) https://github.com/python/cpython/commit/a7bd64c0c01379e9b82e86ad41a301329a0775d9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 06:45:41 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 11:45:41 +0000 Subject: [issue32367] [Security] CVE-2017-17522: webbrowser.py in Python does not validate strings In-Reply-To: <1513614543.15.0.213398074469.issue32367@psf.upfronthosting.co.za> Message-ID: <1513683941.4.0.213398074469.issue32367@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 06:49:25 2017 From: report at bugs.python.org (desbma) Date: Tue, 19 Dec 2017 11:49:25 +0000 Subject: [issue32073] Add copy_directory_metadata parameter to shutil.copytree In-Reply-To: <1511032407.02.0.213398074469.issue32073@psf.upfronthosting.co.za> Message-ID: <1513684165.21.0.213398074469.issue32073@psf.upfronthosting.co.za> desbma added the comment: Ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 06:54:40 2017 From: report at bugs.python.org (Erik Bray) Date: Tue, 19 Dec 2017 11:54:40 +0000 Subject: [issue32287] Import of _pyio module failed on cygwin In-Reply-To: <1513077242.25.0.213398074469.issue32287@psf.upfronthosting.co.za> Message-ID: <1513684480.51.0.213398074469.issue32287@psf.upfronthosting.co.za> Erik Bray added the comment: Indeed, this is a duplicate of #28459. I'll also update the existing patch to a pull request. ---------- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 06:56:31 2017 From: report at bugs.python.org (Erik Bray) Date: Tue, 19 Dec 2017 11:56:31 +0000 Subject: [issue28459] _pyio module broken on Cygwin / setmode not usable In-Reply-To: <1476701892.4.0.598393414511.issue28459@psf.upfronthosting.co.za> Message-ID: <1513684591.33.0.213398074469.issue28459@psf.upfronthosting.co.za> Erik Bray added the comment: Right, the current patch is really combining several issues. I'll make a PR from it that just fixes the _pyio issue. I'll also open an issue for fixing the ctypes bug (this is a patch I've had in my cygwin branch for ages but just never got around to making a report for...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 07:18:47 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 12:18:47 +0000 Subject: [issue32357] Optimize asyncio.iscoroutine() and loop.create_task() for non-native coroutines In-Reply-To: <1513575220.77.0.213398074469.issue32357@psf.upfronthosting.co.za> Message-ID: <1513685927.42.0.213398074469.issue32357@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset a9d7e552c72b6e9515e76a1dd4b247da86da23de by Yury Selivanov in branch 'master': bpo-32357: Optimize asyncio.iscoroutine() for non-native coroutines (#4915) https://github.com/python/cpython/commit/a9d7e552c72b6e9515e76a1dd4b247da86da23de ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 07:19:04 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 12:19:04 +0000 Subject: [issue32357] Optimize asyncio.iscoroutine() and loop.create_task() for non-native coroutines In-Reply-To: <1513575220.77.0.213398074469.issue32357@psf.upfronthosting.co.za> Message-ID: <1513685944.78.0.213398074469.issue32357@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 07:19:55 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 12:19:55 +0000 Subject: [issue32355] Optimize asyncio.gather() In-Reply-To: <1513564867.85.0.213398074469.issue32355@psf.upfronthosting.co.za> Message-ID: <1513685995.55.0.213398074469.issue32355@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 36c2c044782997520df7fc5604742a615ccf6b17 by Yury Selivanov in branch 'master': bpo-32355: Optimize asyncio.gather() (#4913) https://github.com/python/cpython/commit/36c2c044782997520df7fc5604742a615ccf6b17 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 07:20:10 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 12:20:10 +0000 Subject: [issue32355] Optimize asyncio.gather() In-Reply-To: <1513564867.85.0.213398074469.issue32355@psf.upfronthosting.co.za> Message-ID: <1513686010.94.0.213398074469.issue32355@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 07:23:19 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 12:23:19 +0000 Subject: [issue29711] When you use stop_serving in proactor loop it's kill all listening servers In-Reply-To: <1488552886.51.0.862043273037.issue29711@psf.upfronthosting.co.za> Message-ID: <1513686199.44.0.213398074469.issue29711@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 319c0345cdd8fddb49d235462e71883f1dd51b99 by Yury Selivanov (Julien Duponchelle) in branch 'master': bpo-29711: Fix stop_serving in proactor loop kill all listening servers (#431) https://github.com/python/cpython/commit/319c0345cdd8fddb49d235462e71883f1dd51b99 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 07:23:48 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 12:23:48 +0000 Subject: [issue29711] When you use stop_serving in proactor loop it's kill all listening servers In-Reply-To: <1488552886.51.0.862043273037.issue29711@psf.upfronthosting.co.za> Message-ID: <1513686228.29.0.213398074469.issue29711@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 07:41:00 2017 From: report at bugs.python.org (Stefan Nordhausen) Date: Tue, 19 Dec 2017 12:41:00 +0000 Subject: [issue32368] Segfault when compiling many conditional expressions In-Reply-To: <1513614564.0.0.213398074469.issue32368@psf.upfronthosting.co.za> Message-ID: <1513687260.18.0.213398074469.issue32368@psf.upfronthosting.co.za> Stefan Nordhausen added the comment: I tried out PR 3015 of Serhiy and this fixes the segfaults. So it seems to be a duplicate. As for backporting the fix: Is this a 'reliable' segfault (i.e. it always segfaults when the limit is exceeded) or could there be some silent data corruption? If data can be corrupted, I'd consider this bug very serious, otherwise it's a rather small annoyance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 07:46:33 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 19 Dec 2017 12:46:33 +0000 Subject: [issue31954] Don't prevent dict optimization by coupling with OrderedDict In-Reply-To: <1509961081.05.0.213398074469.issue31954@psf.upfronthosting.co.za> Message-ID: <1513687593.22.0.213398074469.issue31954@psf.upfronthosting.co.za> INADA Naoki added the comment: pyperformance doesn't show significant performance degration. (using commit 5d8d3d1) $ ./python -m perf compare_to -G --min-speed=2 default.json patched.json Slower (5): - pickle_list: 9.40 us +- 0.98 us -> 9.96 us +- 1.20 us: 1.06x slower (+6%) - pickle_dict: 63.1 us +- 0.6 us -> 65.6 us +- 5.2 us: 1.04x slower (+4%) - regex_effbot: 5.39 ms +- 0.09 ms -> 5.60 ms +- 0.35 ms: 1.04x slower (+4%) - genshi_xml: 188 ms +- 2 ms -> 193 ms +- 3 ms: 1.03x slower (+3%) - pickle: 22.4 us +- 0.2 us -> 22.9 us +- 0.3 us: 1.02x slower (+2%) Faster (5): - mako: 38.8 ms +- 0.2 ms -> 37.6 ms +- 0.2 ms: 1.03x faster (-3%) - regex_v8: 44.3 ms +- 0.7 ms -> 43.1 ms +- 0.4 ms: 1.03x faster (-3%) - scimark_monte_carlo: 254 ms +- 10 ms -> 248 ms +- 6 ms: 1.03x faster (-3%) - scimark_fft: 740 ms +- 20 ms -> 721 ms +- 14 ms: 1.03x faster (-2%) - regex_dna: 289 ms +- 5 ms -> 282 ms +- 9 ms: 1.02x faster (-2%) Benchmark hidden because not significant (50)... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 07:58:52 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Dec 2017 12:58:52 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1513688332.22.0.213398074469.issue26439@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset c5ae169e1b73315672770517bf51cf8464286c76 by Victor Stinner (Michael Felt) in branch 'master': bpo-26439 Fix ctypes.util.find_library failure on AIX (#4507) https://github.com/python/cpython/commit/c5ae169e1b73315672770517bf51cf8464286c76 ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 08:10:51 2017 From: report at bugs.python.org (Daniel Holmes) Date: Tue, 19 Dec 2017 13:10:51 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1513689051.37.0.213398074469.issue15873@psf.upfronthosting.co.za> Daniel Holmes added the comment: I wanted to note here... I've been trying to get strptime to work with the types of dates specified in this request and came across a documentation bug here: https://docs.python.org/3.5/library/time.html#time.strptime You can see that the %z attribute's examples given have colons in them while the format specified is +HHMM rather than +HH:MM which the examples illude to. ---------- nosy: +jaitaiwan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 08:11:53 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Dec 2017 13:11:53 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1513689113.43.0.213398074469.issue26439@psf.upfronthosting.co.za> STINNER Victor added the comment: Michael Felt: I merged your PR ??? ! Thank you very much for your patience and perseverance. 80 comments on this bug, 117 comments and 19 commits in the PR... wow! AIX is not dead ? I leave the bug open since Martin, Mariatta and me were interested to make further minor coding style changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 08:13:18 2017 From: report at bugs.python.org (Pierre Chatelier) Date: Tue, 19 Dec 2017 13:13:18 +0000 Subject: [issue32371] Delay-loading of python dll is impossible when using some C macros Message-ID: <1513689198.93.0.213398074469.issue32371@psf.upfronthosting.co.za> New submission from Pierre Chatelier : Delay-loading of the python DLL is impossible when using some C macros. For instance, PyLong_Check() is OK, but PyBool_Check() or PyFunc_Check() will eventually raise a link error. This is due to the fact that PyBool_Check() directly use the PyBool_Type symbol instead of getting a reference through a function. For the same reason, Py_False and Py_True are problematic. ---------- components: Windows messages: 308639 nosy: Pierre Chatelier, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Delay-loading of python dll is impossible when using some C macros type: compile error versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 08:20:05 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Dec 2017 13:20:05 +0000 Subject: [issue27456] asyncio: set TCP_NODELAY flag by default In-Reply-To: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> Message-ID: <1513689605.96.0.213398074469.issue27456@psf.upfronthosting.co.za> STINNER Victor added the comment: Yury: thanks for fixing socket.socket.type. asyncio code now looks simpler and easier to follow without the helper functions just to test the socket type for equality. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 08:29:50 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 19 Dec 2017 13:29:50 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513690190.34.0.213398074469.issue32361@psf.upfronthosting.co.za> R. David Murray added the comment: Right, it was indeed "designed that way" in the sense that nolocal was only ever intended to access variables from the surrounding local scope, *not* the global scope. If you put a variable name in the global scope, nonlocal was not intended to be able to access it (it is then a global variable, not a local variable). So the only question that keeps this issue open is can the error message be improved for the case where a global declaration affects the variable name in question (the message is clear when there is no variable with that name in the outer function at all). Any change to this design would be an enhancement request and discussion of it should start on the python-ideas mailing list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 08:35:45 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 19 Dec 2017 13:35:45 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513690545.91.0.213398074469.issue32361@psf.upfronthosting.co.za> R. David Murray added the comment: When I said "the only thing keeping this issue open" is the message, I should acknowledge that you mentioned clarifying the documentation, but as I pointed out the documentation is already clear: it says nonlocal does not access variables in the global scope, and in your example 'a' is a variable in the global scope, because it is declared to be one. We generally don't update PEPs after they are accepted and implemented; after that point the documentation is the real reference since the implementation may actually be different in detail than the PEP due to later enhancements. The PEP is still useful as an historical document. (There are exceptions to that, but that is the general rule.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 09:11:45 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Dec 2017 14:11:45 +0000 Subject: [issue32372] Optimize out __debug__ at the AST level Message-ID: <1513692705.53.0.213398074469.issue32372@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : __debug__ is substituted by the constant value at the code generation stage (see issue27169). This prevents it from participating in constant folding at the AST level. The proposed patch moves this optimization to the AST level. This will lead to optimizing "if not __debug__" and will allow to add more optimizations at the AST level (like optimizing expressions "a if __debug__ else b" and "__debug__ and a"). ---------- assignee: serhiy.storchaka components: Interpreter Core messages: 308643 nosy: inada.naoki, pitrou, rhettinger, serhiy.storchaka priority: normal severity: normal status: open title: Optimize out __debug__ at the AST level type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 09:17:18 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 19 Dec 2017 14:17:18 +0000 Subject: [issue32372] Optimize out __debug__ at the AST level In-Reply-To: <1513692705.53.0.213398074469.issue32372@psf.upfronthosting.co.za> Message-ID: <1513693038.56.0.213398074469.issue32372@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +4819 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 09:22:11 2017 From: report at bugs.python.org (Stefan Krah) Date: Tue, 19 Dec 2017 14:22:11 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513693331.33.0.213398074469.issue32361@psf.upfronthosting.co.za> Stefan Krah added the comment: I guess I'd vote for closing this, because the first Google result for "no binding for nonlocal" on Stackoverflow is quite clear. The ideal message would be "'a' cannot be both global and nonlocal", but it would probably complicate the compiler ever so slightly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 09:23:24 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 14:23:24 +0000 Subject: [issue32373] Add socket.getblocking() method Message-ID: <1513693404.23.0.213398074469.issue32373@psf.upfronthosting.co.za> New submission from Yury Selivanov : Currently we have the following methods: * socket.settimeout(t) -- can set the socket in blocking mode, when t==0. * socket.setblocking(flag) -- sets in blocking or non-blocking mode. * socket.gettimeout() -- returns 0 when socket is in non-blocking mode. socket.gettimeout() is the only easy way of checking if the socket is non-blocking or blocking, but it's not intuitive to use it. It's especially strange that we have a setblocking() method without a corresponding getblocking(). I propose to add a 'socket.getblocking() -> bool' method. ---------- assignee: yselivanov components: Library (Lib) messages: 308645 nosy: yselivanov priority: normal severity: normal status: open title: Add socket.getblocking() method type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 09:24:18 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 14:24:18 +0000 Subject: [issue32373] Add socket.getblocking() method In-Reply-To: <1513693404.23.0.213398074469.issue32373@psf.upfronthosting.co.za> Message-ID: <1513693458.8.0.213398074469.issue32373@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- nosy: +asvetlov, vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 09:24:57 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 14:24:57 +0000 Subject: [issue32373] Add socket.getblocking() method In-Reply-To: <1513693404.23.0.213398074469.issue32373@psf.upfronthosting.co.za> Message-ID: <1513693497.78.0.213398074469.issue32373@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4820 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 09:37:22 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 14:37:22 +0000 Subject: [issue32306] Clarify map API in concurrent.futures In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za> Message-ID: <1513694242.4.0.213398074469.issue32306@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hi David, > what happens behind the scenes is that the call blocks until all results are computed and only then starts yielding them. The current implementation of the Executor.map() generator is: def result_iterator(): try: # reverse to keep finishing order fs.reverse() while fs: # Careful not to keep a reference to the popped future if timeout is None: yield fs.pop().result() else: yield fs.pop().result(end_time - time.time()) finally: for future in fs: future.cancel() So it seems to me that results are yielded as soon as they arrive (provided they arrive in the right order). ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, pitrou type: enhancement -> behavior versions: +Python 3.6, Python 3.7 -Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 09:40:38 2017 From: report at bugs.python.org (Petr Viktorin) Date: Tue, 19 Dec 2017 14:40:38 +0000 Subject: [issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL Message-ID: <1513694438.46.0.213398074469.issue32374@psf.upfronthosting.co.za> New submission from Petr Viktorin : After the create phase of multiphase initialization, the per-module state is NULL and the module object is reachable by the garbage collector. Between the create and exec phases, Python code is run and garbage collection can be triggered. So, any custom m_traverse/m_clear/m_free function must be prepared to handle m_state being NULL. This is currently not well documented. It might be useful to insert a call m_traverse after the first phase, at least in --with-pydebug mode, so the potential error gets triggered early. ---------- components: Extension Modules messages: 308647 nosy: encukou priority: normal severity: normal status: open title: Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 09:41:21 2017 From: report at bugs.python.org (Petr Viktorin) Date: Tue, 19 Dec 2017 14:41:21 +0000 Subject: [issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL In-Reply-To: <1513694438.46.0.213398074469.issue32374@psf.upfronthosting.co.za> Message-ID: <1513694481.52.0.213398074469.issue32374@psf.upfronthosting.co.za> Petr Viktorin added the comment: Marcel, could you look into this? ---------- nosy: +Dormouse759 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 09:42:42 2017 From: report at bugs.python.org (Marcel Plch) Date: Tue, 19 Dec 2017 14:42:42 +0000 Subject: [issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL In-Reply-To: <1513694438.46.0.213398074469.issue32374@psf.upfronthosting.co.za> Message-ID: <1513694562.34.0.213398074469.issue32374@psf.upfronthosting.co.za> Change by Marcel Plch : ---------- keywords: +patch pull_requests: +4821 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 09:44:02 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 14:44:02 +0000 Subject: [issue29877] compileall hangs when accessing urandom even if number of workers is 1 In-Reply-To: <1490162236.47.0.103711647228.issue29877@psf.upfronthosting.co.za> Message-ID: <1513694642.5.0.213398074469.issue29877@psf.upfronthosting.co.za> Antoine Pitrou added the comment: So calling urandom() hangs on your device because there's not enough entropy? What OS is this running? Modern Linux, at least, should never block in urandom() (AFAIK). ---------- nosy: +christian.heimes, pitrou type: behavior -> resource usage versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 09:45:19 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 14:45:19 +0000 Subject: [issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL In-Reply-To: <1513694438.46.0.213398074469.issue32374@psf.upfronthosting.co.za> Message-ID: <1513694719.9.0.213398074469.issue32374@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 09:45:28 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 14:45:28 +0000 Subject: [issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL In-Reply-To: <1513694438.46.0.213398074469.issue32374@psf.upfronthosting.co.za> Message-ID: <1513694728.49.0.213398074469.issue32374@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 09:46:32 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 14:46:32 +0000 Subject: [issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL In-Reply-To: <1513694438.46.0.213398074469.issue32374@psf.upfronthosting.co.za> Message-ID: <1513694792.39.0.213398074469.issue32374@psf.upfronthosting.co.za> Antoine Pitrou added the comment: By the way, I think you forgot to answer my question on python-dev: > can you get multi-interpreter support *without* PEP 489? That is, using single-phase initialization and PyModule_GetState(). The doc currently isn't very clear about this. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 09:47:33 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 14:47:33 +0000 Subject: [issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL In-Reply-To: <1513694438.46.0.213398074469.issue32374@psf.upfronthosting.co.za> Message-ID: <1513694853.18.0.213398074469.issue32374@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 09:47:42 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 14:47:42 +0000 Subject: [issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL In-Reply-To: <1513694438.46.0.213398074469.issue32374@psf.upfronthosting.co.za> Message-ID: <1513694862.14.0.213398074469.issue32374@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 09:50:28 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Dec 2017 14:50:28 +0000 Subject: [issue29877] compileall hangs when accessing urandom even if number of workers is 1 In-Reply-To: <1490162236.47.0.103711647228.issue29877@psf.upfronthosting.co.za> Message-ID: <1513695028.19.0.213398074469.issue29877@psf.upfronthosting.co.za> STINNER Victor added the comment: > Found on Python 3.6 on a low-resource platform (NI RoboRIO), ... Hum, it looks like an "embedded device", likely with no entropy source. To check if os.urandom() will block, try to call the following function in your main script: >>> import os; os.getrandom(1, flags=os.GRND_NONBLOCK) b'\xd1' os.urandom() blocks at system startup until the entropy pool is initialized with 128 bytes of entropy. Once it's initialized, os.urandom() will never block again. You may also check the number of entropy bytes available to /dev/random (Python uses /dev/urandom which is different): $ cat /proc/sys/kernel/random/entropy_avail 3748 For a longer explanation, see the PEP 524. ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 10:01:12 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 15:01:12 +0000 Subject: [issue31489] Signal delivered to a subprocess triggers parent's handler In-Reply-To: <1505539554.17.0.680456394796.issue31489@psf.upfronthosting.co.za> Message-ID: <1513695672.51.0.213398074469.issue31489@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I get the feeling (without actually investigating) that this is because a fork()-created process inherits all the parent's configuration, including (in this case) signal handlers and whatever file descriptor was configured to receive signal events using signal.set_wakeup_fd(). So the child process, when it receives a signal, also writes on that file descriptor which happens to be the same underlying self-pipe as in the parent. In Python 3.6 it seems there isn't much you can't do against this (well, nothing obvious, in any case). In Python 3.7, you'll have two fixes available in ProcessPoolExecutor (*): * either pass an initializer function that resets signal configuration to a sane default state * or pass a "forkserver" multiprocessing context that will avoid inheritance issues in the process pool workers (*) see docs at https://docs.python.org/3.7/library/concurrent.futures.html#concurrent.futures.ProcessPoolExecutor I would generally recommend using "forkserver" whenever possible, since it eliminates all those inheritance issues by design. ---------- nosy: +njs, pitrou versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 10:05:24 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 15:05:24 +0000 Subject: [issue32375] Compilation warnings with gcc Message-ID: <1513695924.3.0.213398074469.issue32375@psf.upfronthosting.co.za> New submission from Antoine Pitrou : On Ubuntu 16.04: $ gcc --version gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ make [...] In function ?wcsncpy?, inlined from ?calculate_zip_path? at ./Modules/getpath.c:797:5: /usr/include/x86_64-linux-gnu/bits/wchar2.h:200:9: warning: call to ?__wcsncpy_chk_warn? declared with attribute warning: wcsncpy called with length bigger than size of destination buffer return __wcsncpy_chk_warn (__dest, __src, __n, ^ In function ?wcsncpy?, inlined from ?calculate_zip_path? at ./Modules/getpath.c:806:9: /usr/include/x86_64-linux-gnu/bits/wchar2.h:200:9: warning: call to ?__wcsncpy_chk_warn? declared with attribute warning: wcsncpy called with length bigger than size of destination buffer return __wcsncpy_chk_warn (__dest, __src, __n, ^ In function ?wcsncpy?, inlined from ?calculate_argv0_path? at ./Modules/getpath.c:683:5: /usr/include/x86_64-linux-gnu/bits/wchar2.h:200:9: warning: call to ?__wcsncpy_chk_warn? declared with attribute warning: wcsncpy called with length bigger than size of destination buffer return __wcsncpy_chk_warn (__dest, __src, __n, ^ In function ?wcsncpy?, inlined from ?calculate_argv0_path? at ./Modules/getpath.c:736:13: /usr/include/x86_64-linux-gnu/bits/wchar2.h:200:9: warning: call to ?__wcsncpy_chk_warn? declared with attribute warning: wcsncpy called with length bigger than size of destination buffer return __wcsncpy_chk_warn (__dest, __src, __n, ^ ---------- components: Interpreter Core messages: 308653 nosy: pitrou, serhiy.storchaka, vstinner priority: low severity: normal status: open title: Compilation warnings with gcc type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 10:22:49 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 15:22:49 +0000 Subject: [issue29877] compileall hangs when accessing urandom even if number of workers is 1 In-Reply-To: <1513695028.19.0.213398074469.issue29877@psf.upfronthosting.co.za> Message-ID: <713d34b8-9f4d-84cd-d6e8-066f374411ab@free.fr> Antoine Pitrou added the comment: Le 19/12/2017 ? 15:50, STINNER Victor a ?crit?: > > Hum, it looks like an "embedded device", likely with no entropy source. If it does I/O (which it probably does, being used for robotics), it should certainly be able to extract entropy from the outside world. If it doesn't, it's an OS implementation issue. Of course it probably doesn't hurt to import concurrent.futures lazily. However, people should generally not expect us to never call urandom() when importing stdlib modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 10:49:46 2017 From: report at bugs.python.org (Dustin Spicuzza) Date: Tue, 19 Dec 2017 15:49:46 +0000 Subject: [issue29877] compileall hangs when accessing urandom even if number of workers is 1 In-Reply-To: <1490162236.47.0.103711647228.issue29877@psf.upfronthosting.co.za> Message-ID: <1513698586.29.0.213398074469.issue29877@psf.upfronthosting.co.za> Dustin Spicuzza added the comment: I'm sure that the platform (a RT linux customized by National Instruments) has issues related to urandom, as this has reared it's ugly head with other PEP 525 related issues also: https://bugs.python.org/issue29208 I'll have to try those suggestions to investigate the os.urandom issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 10:56:14 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 15:56:14 +0000 Subject: [issue32373] Add socket.getblocking() method In-Reply-To: <1513693404.23.0.213398074469.issue32373@psf.upfronthosting.co.za> Message-ID: <1513698974.74.0.213398074469.issue32373@psf.upfronthosting.co.za> Yury Selivanov added the comment: It looks like we have a bug with 'sock.settimeout()' and non-blocking/blocking modes (or maybe this is a feature?) Currently: * to make a socket non-blocking, we call 'sock.settimeout(0)'. * to make a socket blocking, we call 'sock.settimeout(None)'. What happens if we call sock.settimeout(t), where t > 0? The internal timeout field of the socket object will simply be set to 't'. What happens if the socket was in a non-blocking mode? Nothing, it stays in non-blocking mode. What it means: suppose you have a non-blocking socket. You call socket.settimeout(10), and most likely you wanted to make it blocking again. Because all operations on the socket become blocking from moment (sock_call_ex repeats on EWOULDBLOCK and EAGAIN). Now is having a timeout and blocking send/recv methods on a non-blocking socket a feature? Or is this a bug? ---------- nosy: +njs, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 10:59:56 2017 From: report at bugs.python.org (Dmitry sky) Date: Tue, 19 Dec 2017 15:59:56 +0000 Subject: [issue32376] Unusable syntax error reported when Python keyword in a f-string Message-ID: <1513699196.74.0.213398074469.issue32376@psf.upfronthosting.co.za> New submission from Dmitry sky : def get_search_url(from_, to): return f"http://thesite.com/Search?SO0={from_}&SD0={to}&SD1={from}&NA=false" # pls note `from_` vs `from` ^^^^^^ $ python fstring.py File "", line 1 (from) ^ SyntaxError: invalid syntax Should report real line #. ---------- components: Interpreter Core files: fstring.py messages: 308657 nosy: Dmitry sky priority: normal severity: normal status: open title: Unusable syntax error reported when Python keyword in a f-string type: behavior versions: Python 3.6 Added file: https://bugs.python.org/file47338/fstring.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 11:10:04 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 16:10:04 +0000 Subject: [issue32373] Add socket.getblocking() method In-Reply-To: <1513693404.23.0.213398074469.issue32373@psf.upfronthosting.co.za> Message-ID: <1513699804.9.0.213398074469.issue32373@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Now is having a timeout and blocking send/recv methods on a non-blocking socket a feature? Or is this a bug? I agree it's a bug (but should only be fixed in 3.7). Also I agree with adding a socket.getblocking() method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 11:11:45 2017 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 19 Dec 2017 16:11:45 +0000 Subject: [issue32376] Unusable syntax error reported when Python keyword in a f-string In-Reply-To: <1513699196.74.0.213398074469.issue32376@psf.upfronthosting.co.za> Message-ID: <1513699905.35.0.213398074469.issue32376@psf.upfronthosting.co.za> Eric V. Smith added the comment: Yes, this is a real problem. I think there's already an issue for this, but I can't find it. Unfortunately, to fix it requires a bit of refactoring on how line numbers and errors are tracked. It's on my list of things to do. ---------- nosy: +eric.smith stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 11:29:59 2017 From: report at bugs.python.org (Eric Cousineau) Date: Tue, 19 Dec 2017 16:29:59 +0000 Subject: [issue32377] Difference in ressurrection behavior with __del__ in py2 vs. py3 Message-ID: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za> New submission from Eric Cousineau : Due to how `PyObject_CallFinalizer` is written in python3, `__del__` will only *ever* be called once. In my use case, I am experimenting with a feature in `pybind11` to prevent slicing with Python class instances that inherit from pybind11-C++ base classes, which involves detecting when an instance loses all reference in Python (`Py_REFCNT(...) == 0`) but still has reference in C++ (`shared_ptr::count() > 0`), and reviving the Python portion when this situation happens. In python2, I could do this without a hitch, as a resurrected object could have its `__del__` method called multiple times (through `tp_dealloc` I believe?). But in python3, the object is marked with `_PyGC_SET_FINALIZED(...)`, thus preventing `__del__` from being called again. It'd be nice to either (a) somehow allow `__del__` to be called naturally without too much fuss or, at the least, (b) have this reflected in the documentation: https://docs.python.org/3/reference/datamodel.html#object.__del__ See attached `revive_test`. Example execution: ``` $ python2 ./revive_test.py Revive Destroy [ Done ] $ python3 ./revive_test.py Revive [ Done ] ``` ---------- assignee: docs at python components: Documentation files: revive_test.py messages: 308660 nosy: Eric Cousineau, docs at python priority: normal severity: normal status: open title: Difference in ressurrection behavior with __del__ in py2 vs. py3 type: behavior versions: Python 3.4, Python 3.5, Python 3.6 Added file: https://bugs.python.org/file47339/revive_test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 11:33:22 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 16:33:22 +0000 Subject: [issue32377] Difference in ressurrection behavior with __del__ in py2 vs. py3 In-Reply-To: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za> Message-ID: <1513701202.54.0.213398074469.issue32377@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the report. Apparently I forgot to update that piece of documentation when PEP 442 was implemented. ---------- nosy: +pitrou stage: -> needs patch versions: +Python 3.7 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 11:46:38 2017 From: report at bugs.python.org (Eric Cousineau) Date: Tue, 19 Dec 2017 16:46:38 +0000 Subject: [issue32377] Difference in ressurrection behavior with __del__ in py2 vs. py3 In-Reply-To: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za> Message-ID: <1513701998.29.0.213398074469.issue32377@psf.upfronthosting.co.za> Eric Cousineau added the comment: You're welcome, and thank you for the prompt response! I will say that it feels a tad odd to only have `tp_finalize` be called once for the entire lifetime of the object, while still having the option of it being resurrected. Is there any way to somehow "un-mark" the object to enable this workflow that I would like to have? My current hack is to call `_PyGC_SET_FINALIZED(self, 0)` - may I ask if there is a simpler way to do this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 12:10:41 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 19 Dec 2017 17:10:41 +0000 Subject: [issue32373] Add socket.getblocking() method In-Reply-To: <1513693404.23.0.213398074469.issue32373@psf.upfronthosting.co.za> Message-ID: <1513703441.33.0.213398074469.issue32373@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Agree, it's a bug. +1 for getblocking() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 12:13:08 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 17:13:08 +0000 Subject: [issue32377] Difference in ressurrection behavior with __del__ in py2 vs. py3 In-Reply-To: <1513701998.29.0.213398074469.issue32377@psf.upfronthosting.co.za> Message-ID: <08662082-d18c-003a-ce80-4450d851de35@free.fr> Antoine Pitrou added the comment: Le 19/12/2017 ? 17:46, Eric Cousineau a ?crit?: > > My current hack is to call `_PyGC_SET_FINALIZED(self, 0)` - may I ask if there is a simpler way to do this? Well... perhaps you could create another PyObject (it's just a wrapper, right?) since the old one doesn't have any outside references to it remaining. Note that calling __del__ only once is also how PyPy works: http://doc.pypy.org/en/latest/cpython_differences.html#differences-related-to-garbage-collection-strategies If there is some demand we could expose a higher-level spelling of `_PyGC_SET_FINALIZED(self, 0)`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 12:13:09 2017 From: report at bugs.python.org (Stefan Nordhausen) Date: Tue, 19 Dec 2017 17:13:09 +0000 Subject: [issue31113] Stack overflow with large program In-Reply-To: <1501747851.67.0.0193426592051.issue31113@psf.upfronthosting.co.za> Message-ID: <1513703589.6.0.213398074469.issue31113@psf.upfronthosting.co.za> Change by Stefan Nordhausen : ---------- nosy: +snordhausen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 12:39:31 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 17:39:31 +0000 Subject: [issue32377] Difference in ressurrection behavior with __del__ in py2 vs. py3 In-Reply-To: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za> Message-ID: <1513705171.7.0.213398074469.issue32377@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- keywords: +patch pull_requests: +4822 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 12:47:38 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 17:47:38 +0000 Subject: [issue32377] Difference in ressurrection behavior with __del__ in py2 vs. py3 In-Reply-To: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za> Message-ID: <1513705658.78.0.213398074469.issue32377@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've proposed a documentation improvement in https://github.com/python/cpython/pull/4927 . Please chime in if you see have issues with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 13:42:23 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 19 Dec 2017 18:42:23 +0000 Subject: [issue17852] Built-in module _io can lose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1513708943.75.0.213398074469.issue17852@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Welp, another day another attempt. As mentioned in the PR 4847, atexit is not the answer. If the raw/buffered file pair are part of a reference cycle and the GC cleans it before atexit runs, then the buffered data can get lost. I attempted to implement my weakref idea (i.e. raw file keeps a weakref to the buffered file, calls flush before the raw file gets closed). That doesn't work either because the GC clears the weakref before calling __del__. The attached patch "buffer_register_flush.txt" does seem to work. The downside is that it creates a reference cycle between the raw and buffered file objects. Perhaps that is not a problem since unless you call close() on the raw file, you will be leaking resources anyhow. In the patch, calling close() removes the reference cycle. I still feel like this is worth fixing, as ugly as the implementation is. ---------- assignee: -> nascheme Added file: https://bugs.python.org/file47340/buffer_register_flush.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 13:48:47 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 18:48:47 +0000 Subject: [issue32377] Difference in ressurrection behavior with __del__ in py2 vs. py3 In-Reply-To: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za> Message-ID: <1513709327.96.0.213398074469.issue32377@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New changeset 4b965930e8625f77cb0e821daf5cc40e85b45f84 by Antoine Pitrou in branch 'master': bpo-32377: improve __del__ docs and fix mention about resurrection (#4927) https://github.com/python/cpython/commit/4b965930e8625f77cb0e821daf5cc40e85b45f84 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 13:49:01 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 Dec 2017 18:49:01 +0000 Subject: [issue32377] Difference in ressurrection behavior with __del__ in py2 vs. py3 In-Reply-To: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za> Message-ID: <1513709341.67.0.213398074469.issue32377@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4823 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 13:51:12 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 18:51:12 +0000 Subject: [issue17852] Built-in module _io can lose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1513709472.13.0.213398074469.issue17852@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think it would be quite disruptive to create a reference cycle each time open() is called. It may also break user scripts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 13:59:04 2017 From: report at bugs.python.org (Christian Heimes) Date: Tue, 19 Dec 2017 18:59:04 +0000 Subject: [issue32378] test_npn_protocols broken with LibreSSL 2.6.1+ Message-ID: <1513709944.02.0.213398074469.issue32378@psf.upfronthosting.co.za> New submission from Christian Heimes : LibreSSL 2.6.1 to 2.6.4 have a broken implementation of NPN protocol. 2.6.0 and earlier are fine. ====================================================================== FAIL: test_npn_protocols (test.test_ssl.ThreadedTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 3424, in test_npn_protocols self.assertEqual(client_result, expected, msg % (client_result, "client")) AssertionError: None != 'http/1.1' : failed trying ['http/1.1', 'spdy/2'] (s) and ['http/1.1', 'spdy/2'] (c). was expecting http/1.1, but got None from the client Upstream issue https://github.com/libressl-portable/portable/issues/368 ---------- assignee: christian.heimes components: SSL messages: 308669 nosy: christian.heimes priority: normal severity: normal status: open title: test_npn_protocols broken with LibreSSL 2.6.1+ versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 13:59:42 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Tue, 19 Dec 2017 18:59:42 +0000 Subject: [issue31489] Signal delivered to a subprocess triggers parent's handler In-Reply-To: <1505539554.17.0.680456394796.issue31489@psf.upfronthosting.co.za> Message-ID: <1513709982.43.0.213398074469.issue31489@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Ouch, yes, that's a tricky bug. This is definitely caused by the way that asyncio internally converts signals into messages along a pipe (well, socket, but same thing), and then after a fork-without-exec the child keeps writing into that pipe. It's exacerbated by asyncio's choice to use the self-pipe as its source of truth about which signals have arrived vs just a wake-up pipe (see [1]), but that's not really the main issue; even without this we'd get spurious wakeups and other unpleasantness. In addition to the workarounds Antoine suggested, it would possibly make sense for forked children to disable any wakeup_fd, perhaps in PyOS_AfterFork or by adding a getpid() check to the C level signal handler. I can't think of any cases where you actually want to processes to share the same wake-up fd. And even if this isn't fixed at that level, it would make sense for asyncio to use the new atfork module to do something similar for asyncio specifically. Also relevant: https://github.com/python/asyncio/issues/347 [1] https://github.com/dabeaz/curio/issues/118 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 14:00:18 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 19:00:18 +0000 Subject: [issue32377] Difference in ressurrection behavior with __del__ in py2 vs. py3 In-Reply-To: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za> Message-ID: <1513710018.97.0.213398074469.issue32377@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New changeset dc5770b161a5e28eeff73a406cd4eddb0676c5b5 by Antoine Pitrou (Miss Islington (bot)) in branch '3.6': bpo-32377: improve __del__ docs and fix mention about resurrection (GH-4927) (#4929) https://github.com/python/cpython/commit/dc5770b161a5e28eeff73a406cd4eddb0676c5b5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 14:00:56 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 19:00:56 +0000 Subject: [issue32377] Difference in ressurrection behavior with __del__ in py2 vs. py3 In-Reply-To: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za> Message-ID: <1513710056.96.0.213398074469.issue32377@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 14:03:16 2017 From: report at bugs.python.org (Christian Heimes) Date: Tue, 19 Dec 2017 19:03:16 +0000 Subject: [issue32378] test_npn_protocols broken with LibreSSL 2.6.1+ In-Reply-To: <1513709944.02.0.213398074469.issue32378@psf.upfronthosting.co.za> Message-ID: <1513710196.91.0.213398074469.issue32378@psf.upfronthosting.co.za> Change by Christian Heimes : ---------- keywords: +patch pull_requests: +4824 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 14:34:52 2017 From: report at bugs.python.org (Anthony Sottile) Date: Tue, 19 Dec 2017 19:34:52 +0000 Subject: [issue30697] segfault in PyErr_NormalizeException() after memory exhaustion In-Reply-To: <1497792581.23.0.578886308028.issue30697@psf.upfronthosting.co.za> Message-ID: <1513712092.54.0.213398074469.issue30697@psf.upfronthosting.co.za> Anthony Sottile added the comment: Should this have landed in python3.6? It removes a public symbol `PyExc_RecursionErrorInst` (abi break?) ---------- nosy: +Anthony Sottile _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 14:45:44 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 19 Dec 2017 19:45:44 +0000 Subject: [issue29970] Severe open file leakage running asyncio SSL server In-Reply-To: <1491228615.05.0.224246839796.issue29970@psf.upfronthosting.co.za> Message-ID: <1513712744.45.0.213398074469.issue29970@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset f7686c1f5553b24e3307506a18e18f6544de94d3 by Andrew Svetlov (Neil Aspinall) in branch 'master': bpo-29970: Add timeout for SSL handshake in asyncio https://github.com/python/cpython/commit/f7686c1f5553b24e3307506a18e18f6544de94d3 ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 14:54:59 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 19:54:59 +0000 Subject: [issue32379] MRO computation could be faster Message-ID: <1513713299.76.0.213398074469.issue32379@psf.upfronthosting.co.za> New submission from Antoine Pitrou : MRO computation involves a complicated merge calculation over several lists. But, for the simple (common) case where a class has a single base, the computation could be much simpler: take the base's MRO and prepend the derived class. ---------- components: Interpreter Core messages: 308674 nosy: pitrou priority: normal severity: normal status: open title: MRO computation could be faster type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 14:56:32 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 19:56:32 +0000 Subject: [issue32379] MRO computation could be faster In-Reply-To: <1513713299.76.0.213398074469.issue32379@psf.upfronthosting.co.za> Message-ID: <1513713392.28.0.213398074469.issue32379@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- keywords: +patch pull_requests: +4825 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 14:56:53 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 19:56:53 +0000 Subject: [issue32379] MRO computation could be faster In-Reply-To: <1513713299.76.0.213398074469.issue32379@psf.upfronthosting.co.za> Message-ID: <1513713413.09.0.213398074469.issue32379@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- nosy: +inada.naoki, serhiy.storchaka, vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 15:00:20 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 20:00:20 +0000 Subject: [issue32379] MRO computation could be faster In-Reply-To: <1513713299.76.0.213398074469.issue32379@psf.upfronthosting.co.za> Message-ID: <1513713620.2.0.213398074469.issue32379@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Benchmarks: * before: $ ./env-orig/bin/pyperf timeit "class Test: pass" ..................... Mean +- std dev: 9.51 us +- 0.17 us * after: $ ./env/bin/pyperf timeit "class Test: pass" ..................... Mean +- std dev: 8.89 us +- 0.09 us ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 15:02:01 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 19 Dec 2017 20:02:01 +0000 Subject: [issue29970] Severe open file leakage running asyncio SSL server In-Reply-To: <1491228615.05.0.224246839796.issue29970@psf.upfronthosting.co.za> Message-ID: <1513713721.79.0.213398074469.issue29970@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 15:02:17 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 19 Dec 2017 20:02:17 +0000 Subject: [issue29970] Severe open file leakage running asyncio SSL server In-Reply-To: <1491228615.05.0.224246839796.issue29970@psf.upfronthosting.co.za> Message-ID: <1513713737.94.0.213398074469.issue29970@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Fixed in 3.7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 15:05:35 2017 From: report at bugs.python.org (Ilya Kulakov) Date: Tue, 19 Dec 2017 20:05:35 +0000 Subject: [issue31489] Signal delivered to a subprocess triggers parent's handler In-Reply-To: <1505539554.17.0.680456394796.issue31489@psf.upfronthosting.co.za> Message-ID: <1513713935.93.0.213398074469.issue31489@psf.upfronthosting.co.za> Ilya Kulakov added the comment: Can you suggest an alternative to ProcessPoolExecutor for 3.6? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 15:06:55 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 20:06:55 +0000 Subject: [issue31489] Signal delivered to a subprocess triggers parent's handler In-Reply-To: <1505539554.17.0.680456394796.issue31489@psf.upfronthosting.co.za> Message-ID: <1513714015.61.0.213398074469.issue31489@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You may switch to multiprocessing.Pool (with the "forkserver" method). Otherwise, you could workaround it by executing a function on all workers that will reset the signal configuration. To maximize the chances that it does get executed on all workers, you could add a sleep() call inside it... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 15:08:45 2017 From: report at bugs.python.org (Camion) Date: Tue, 19 Dec 2017 20:08:45 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513714125.66.0.213398074469.issue32361@psf.upfronthosting.co.za> Camion added the comment: David and Stefan, you're both missing my main point which is the fact that the presence of the global declaration in the parent (g) **blocks the access to the grand parent context**, which would be accessible without this global declaration (of another variable since that one is global. It just happen to have the same name) in g; and the stackoverflow post also ignores this question. I do not disagree that this might be a desired feature (we might wish to reject this because of the potential confusion caused by this kind of name collision situation), but without any clear specification on it (since this point doesn't seem to have been discussed in the (or any?) PEP), it could always be challenged as a design flaw. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 15:28:58 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 19 Dec 2017 20:28:58 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513715338.29.0.213398074469.issue32361@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. I suppose that could be clarified in the docs. I would find it very counter-intuitive for the grandparent 'a' to be accessible, which is probably why I did not consider that an issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 15:42:52 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 19 Dec 2017 20:42:52 +0000 Subject: [issue17852] Built-in module _io can lose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1513716172.68.0.213398074469.issue17852@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Yeah, I think you are correct. Currently files not part of reference cycles get properly flushed and closed by the reference counter. Implementing my "buffer_register_flush" patch would cause files to be closed only by the cyclic garbage collector (if not explicitly closed). That would mean a script that opens a large number of files could run out of file descriptors. Basically, we lose one of the main advantages of reference counting. Probably the GC should keep track of how many files are open and call collect() when a threshold is reached. Still, forcing every file to be collected only by the cyclic GC seems too ugly of a solution to this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 15:45:50 2017 From: report at bugs.python.org (Camion) Date: Tue, 19 Dec 2017 20:45:50 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513716350.99.0.213398074469.issue32361@psf.upfronthosting.co.za> Camion added the comment: My interrogation is about the fact that this doesn't seem to have been a collective decision and I'm not even sure it WAS anyone decision : it might as well have been an unintentional consequence of an implementation choice. So, in the "weakest" configuration, avoiding the implementation challenge for "design flaw" would require a language specification to at least mention that in this case, the behavior in undefined. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 15:47:47 2017 From: report at bugs.python.org (Stefan Krah) Date: Tue, 19 Dec 2017 20:47:47 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513716467.72.0.213398074469.issue32361@psf.upfronthosting.co.za> Stefan Krah added the comment: Okay, I have never used something like that. Personally, I'd disallow the global statement in g() if 'a' is local in f(). >>> a = 10 >>> def f(): ... a = 20 ... def g(): ... global a ... print(a) ... g() ... >>> >>> f() 10 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 16:08:10 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 19 Dec 2017 21:08:10 +0000 Subject: [issue32376] Unusable syntax error reported when Python keyword in a f-string In-Reply-To: <1513699196.74.0.213398074469.issue32376@psf.upfronthosting.co.za> Message-ID: <1513717690.04.0.213398074469.issue32376@psf.upfronthosting.co.za> R. David Murray added the comment: The existing issue is #29051. ---------- nosy: +r.david.murray resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> Improve error reporting involving f-strings (PEP 498) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 16:15:51 2017 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 19 Dec 2017 21:15:51 +0000 Subject: [issue29051] Improve error reporting involving f-strings (PEP 498) In-Reply-To: <1482494461.91.0.191852219403.issue29051@psf.upfronthosting.co.za> Message-ID: <1513718151.74.0.213398074469.issue29051@psf.upfronthosting.co.za> Eric V. Smith added the comment: The example above (msg289501) has been fixed. I think it was in #30465. It also fixes some of these other cases, but I haven't reviewed them all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 16:32:52 2017 From: report at bugs.python.org (Brett Cannon) Date: Tue, 19 Dec 2017 21:32:52 +0000 Subject: [issue30697] segfault in PyErr_NormalizeException() after memory exhaustion In-Reply-To: <1497792581.23.0.578886308028.issue30697@psf.upfronthosting.co.za> Message-ID: <1513719172.66.0.213398074469.issue30697@psf.upfronthosting.co.za> Brett Cannon added the comment: Re-opened as a release blocker to make sure we're okay with the potential ABI breakage. ---------- nosy: +ned.deily priority: normal -> release blocker status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 17:23:08 2017 From: report at bugs.python.org (Ethan Smith) Date: Tue, 19 Dec 2017 22:23:08 +0000 Subject: [issue32380] functools.singledispatch interacts poorly with methods Message-ID: <1513722188.44.0.213398074469.issue32380@psf.upfronthosting.co.za> New submission from Ethan Smith : Consider the following: from functools import singledispatch class Dispatch: @singledispatch def foo(self, a): return a @foo.register(int) def _(self, a): return "int" @foo.register(str) def _(self, a): return "str" cls = Dispatch() cls.foo(3) # 3 cls.foo('hm') # 'hm' I find this quite unintuitive. Essentially, since singledispatch dispatches based solely on a functions first argument, it is useless on methods unless one wraps it and modifies how it uses the internal wrapper function. I believe this should be relatively easy to fix with adding a check of inspect.ismethod and then modifying the number of the checked argument where appropriate. I'm happy to write a patch if this change is seen as a good idea. ---------- components: Library (Lib) messages: 308687 nosy: Ethan Smith priority: normal severity: normal status: open title: functools.singledispatch interacts poorly with methods type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 17:26:01 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Dec 2017 22:26:01 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513722361.72.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4826 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 17:48:04 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Dec 2017 22:48:04 +0000 Subject: [issue29877] compileall hangs when accessing urandom even if number of workers is 1 In-Reply-To: <1490162236.47.0.103711647228.issue29877@psf.upfronthosting.co.za> Message-ID: <1513723684.3.0.213398074469.issue29877@psf.upfronthosting.co.za> STINNER Victor added the comment: In kernel logs (look at dmesg), I found two messages: vstinner at apu$ journalctl -k|grep random d?c. 14 23:10:28 apu kernel: random: fast init done d?c. 14 23:10:32 apu kernel: random: crng init done Sadly, I don't know which one means that urandom is initialized. See also https://wiki.archlinux.org/index.php/Random_number_generation ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 17:48:19 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Dec 2017 22:48:19 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513723699.54.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset c4bca951065f4b2b6833f6ce7a0721e863e2343e by Victor Stinner in branch 'master': bpo-32030: Add _PyCoreConfig.argv (#4934) https://github.com/python/cpython/commit/c4bca951065f4b2b6833f6ce7a0721e863e2343e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 18:12:20 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 19 Dec 2017 23:12:20 +0000 Subject: [issue32315] can't run any scripts with 2.7.x, 32 and 64-bit In-Reply-To: <1513203071.76.0.213398074469.issue32315@psf.upfronthosting.co.za> Message-ID: <1513725140.39.0.213398074469.issue32315@psf.upfronthosting.co.za> Change by Terry J. Reedy : ---------- resolution: -> not a bug stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 18:19:29 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 23:19:29 +0000 Subject: [issue32345] EIO from write() is only fatal if print() contains a newline In-Reply-To: <1513416512.67.0.213398074469.issue32345@psf.upfronthosting.co.za> Message-ID: <1513725569.23.0.213398074469.issue32345@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Python 2 doesn't call write(), it calls fwrite() and friends (i.e. it uses the libc's buffered I/O API). Also we don't do anything special if the printed string has a newline in it. So my guess is that it's a bug in the libc. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 18:29:59 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 19 Dec 2017 23:29:59 +0000 Subject: [issue32304] Upload failed (400): Digests do not match on .tar.gz ending with x0d binary code In-Reply-To: <1513180109.43.0.213398074469.issue32304@psf.upfronthosting.co.za> Message-ID: <1513726199.61.0.213398074469.issue32304@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I agree with the suggested fix. Do you want to submit a PR? ---------- nosy: +pitrou -llecaroz stage: -> needs patch versions: +Python 3.6 -Python 3.5, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 18:30:34 2017 From: report at bugs.python.org (Alexey Luchko) Date: Tue, 19 Dec 2017 23:30:34 +0000 Subject: [issue32268] quopri.decode(): string argument expected, got 'bytes' In-Reply-To: <1512902753.61.0.213398074469.issue32268@psf.upfronthosting.co.za> Message-ID: <1513726234.18.0.213398074469.issue32268@psf.upfronthosting.co.za> Alexey Luchko added the comment: I didn't mean type checking. The point is that since string and bytes are different types, then binary and text files are actually much more different than before python 3. Therefore they better be of different protocols. Then inside quopri with StringIO in place of BytesIO the error would be much more clear and this issue would not have appeared. This would be helpful in lack of one's intuition, like with newcomers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 18:40:15 2017 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 19 Dec 2017 23:40:15 +0000 Subject: [issue32373] Add socket.getblocking() method In-Reply-To: <1513693404.23.0.213398074469.issue32373@psf.upfronthosting.co.za> Message-ID: <1513726815.8.0.213398074469.issue32373@psf.upfronthosting.co.za> Yury Selivanov added the comment: It appears the the timeouts situation is a bit more complex. It's perfectly normal for a Python socket object to be in a "blocking" mode and for its FD to be in a non-blocking mode. Read more about this in the latest docs update to the PR: https://github.com/python/cpython/pull/4926/commits/adcc91f93e1538f0d25645ebe0285b12137a3e3b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 18:50:51 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 19 Dec 2017 23:50:51 +0000 Subject: [issue32268] quopri.decode(): string argument expected, got 'bytes' In-Reply-To: <1512902753.61.0.213398074469.issue32268@psf.upfronthosting.co.za> Message-ID: <1513727451.45.0.213398074469.issue32268@psf.upfronthosting.co.za> R. David Murray added the comment: That's type checking. Not type checking is to call the method that writes the data, expecting the object to handle the bytes it is passed, and then that object raises an error to indicate that it cannot. There is no protocol that can be checked for. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 18:54:12 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Tue, 19 Dec 2017 23:54:12 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513727652.06.0.213398074469.issue32361@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Stefan, your last example is formally speaking OK, if one reads the "Execution model" literally. The original example is however too ambiguous, so it is good that it triggers an error. I think there is a chance to improve the error message here, but I didn't think about this carefully (in particular, a situation where `global` appears after the inner function `h` definition worries me). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 19:04:15 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 00:04:15 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513728255.7.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4827 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 19:25:03 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Wed, 20 Dec 2017 00:25:03 +0000 Subject: [issue31489] Signal delivered to a subprocess triggers parent's handler In-Reply-To: <1505539554.17.0.680456394796.issue31489@psf.upfronthosting.co.za> Message-ID: <1513729503.2.0.213398074469.issue31489@psf.upfronthosting.co.za> Nathaniel Smith added the comment: It might be possible to create ProcessPoolExecutor and get it to spawn all the workers *before* you start the asyncio loop. It looks like ProcessPoolExecutor delays spawning workers until the first piece of work is submitted, but at that point it spawns all of them immediately, so something like this might work: executor = ProcessPoolExecutor(...) executor.submit(lambda: None).wait() with asyncio.get_event_loop() as loop: loop.run_until_complete(...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 19:25:58 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 00:25:58 +0000 Subject: [issue32375] Compilation warnings with gcc In-Reply-To: <1513695924.3.0.213398074469.issue32375@psf.upfronthosting.co.za> Message-ID: <1513729558.64.0.213398074469.issue32375@psf.upfronthosting.co.za> STINNER Victor added the comment: In function ?wcsncpy?, inlined from ?calculate_zip_path? at ./Modules/getpath.c:797:5: /usr/include/x86_64-linux-gnu/bits/wchar2.h:200:9: warning: call to ?__wcsncpy_chk_warn? declared with attribute warning: wcsncpy called with length bigger than size of destination buffer return __wcsncpy_chk_warn (__dest, __src, __n, ^ Line 797: wcsncpy(calculate->zip_path, prefix, MAXPATHLEN); calculate type is "PyCalculatePath *" which is defined as: typedef struct { ... wchar_t zip_path[MAXPATHLEN+1]; /* ".../lib/pythonXY.zip" */ ... } PyCalculatePath; Earlier, all bytes are set to 0: memset(&calculate, 0, sizeof(calculate)); So I don't see how wcsncpy() can overflow. By the way, I'm unable to reproduce the warning on Fedora 27 with GCC 7.2.1. Are you using -D_FORTIFY_SOURCE=1? Are you compiling Python in release mode? Can you try to find the command line compiling getpath.c? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 19:42:01 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 00:42:01 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513730521.48.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 19760863623b636a63ccf649107d9504c6465a92 by Victor Stinner in branch 'master': bpo-32030: Cleanup pymain_main() (#4935) https://github.com/python/cpython/commit/19760863623b636a63ccf649107d9504c6465a92 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 19:43:30 2017 From: report at bugs.python.org (Eric Snow) Date: Wed, 20 Dec 2017 00:43:30 +0000 Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7 In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za> Message-ID: <1513730610.49.0.213398074469.issue32248@psf.upfronthosting.co.za> Change by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 20:06:45 2017 From: report at bugs.python.org (Alexey Luchko) Date: Wed, 20 Dec 2017 01:06:45 +0000 Subject: [issue32268] quopri.decode(): string argument expected, got 'bytes' In-Reply-To: <1512902753.61.0.213398074469.issue32268@psf.upfronthosting.co.za> Message-ID: <1513732005.35.0.213398074469.issue32268@psf.upfronthosting.co.za> Alexey Luchko added the comment: 1. On quopri. It is counter-intuitive despite the clear statement in the doc-string. Quoted-printable is used mostly for text encoding. (It would be quite awkward and inefficient to use it for binary data.) My case: I have a text and I mean to get a text. Why on earth StringIO is not suitable for this goal... It is just crazy! 2. On duck typing and StringIO. It should make life easy, not crazy. But with great power... You know. Taking a wider look than just quopri, the case shows a problem ? writing text to StringIO produces a type error stating *string argument expected*. That is crazy and as counter-duck-typing as type checking. And even more ... crazy in case of 7bit ascii! There could be a solution on StringIO side, like an encoding it should expect on input if it gets binary data. At least 7bit ascii would be totally ok for default it this case. Then it either would have worked or would have produced a clear text encoding related error that would be *meaningful* and *instructive*. 3. On protocol. A protocol: write_bytes() and write_string() methods that would have been raising type error in case of text_file.write_bytes() or binary_file.write_string(). Then one having bytes-*like* object (like quopri.decode) would call write_bytes() and StringIO would raise smth like 'StringIO used for binary output, consider BytesIO' or 'Text file requires strings, not bytes' that would be meaningful as well. Other one having string-*like* object would call knowingly write_string() with a corresponding error from BytesIO or binary file. *There is nothing of checking in the protocol, but clear intention statement.* Disclaimer: It is just an example and an opinion. There is no reason for holy war. I don't pretend it would be any better... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 20:55:47 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 01:55:47 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513734947.2.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: I like the new shape of Py_Main(). The main parts of Py_Main() are now well identified: * init "cmdline" * init "python core" * init "python main" * run python * cleanup ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 21:35:20 2017 From: report at bugs.python.org (Camion) Date: Wed, 20 Dec 2017 02:35:20 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513737320.52.0.213398074469.issue32361@psf.upfronthosting.co.za> Camion added the comment: Ivan, I believe, this sentence : "(the scope in which a new binding should be created cannot be determined unambiguously)" in https://docs.python.org/fr/3/reference/simple_stmts.html#nonlocal, is the one which should be clarified first, and then this would probably give the bases to improve the error message. It raises the following concerns : 1/ Is it me or there is a nasty double negation in this sentence which make it tell the contrary of what it should ? 2/ What are the conditions which would make such an ambiguity appear ? I wonder what the persons who wrote this had on their mind when they wrote it, but in regard with code reading/reviewing, my original example might be an example of such an ambiguous situation. Now the question is: are there others and what would they look like ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 22:00:55 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 03:00:55 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513738855.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4828 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 22:13:09 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Dec 2017 03:13:09 +0000 Subject: [issue32268] quopri.decode(): string argument expected, got 'bytes' In-Reply-To: <1512902753.61.0.213398074469.issue32268@psf.upfronthosting.co.za> Message-ID: <1513739589.59.0.213398074469.issue32268@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, if that protocol existed the errors would be clearer. But it doesn't, for historical reasons, and that is unlikely to change. You are welcome to submit an enhancement request to make quopri accept string as an argument when decoding. But when encoding, it must produce bytes, because "ASCII" is a *byte* encoding, not a unicode encoding (unicode is ascii compatible, but it is neither ascii nor bytes). You might have to write the PR yourself, I'm not sure if anyone else will be interested (but some of the people on the core-mentorship mailing list might be). StringIO is specifically designed to only operate on strings. If you want to decode the bytes you feed it, you have to do that. This is an intentional design. Further discussion of ways to improve the situation should move to the python-idea mailing list. There's really nothing to do here from a bug tracker perspective, unless you want to open an enhancement request as mentioned above. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 19 22:51:30 2017 From: report at bugs.python.org (Camion) Date: Wed, 20 Dec 2017 03:51:30 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513741890.92.0.213398074469.issue32361@psf.upfronthosting.co.za> Camion added the comment: What I mean is that we need to clarify (by giving examples ?) what make the scope for the new binding "not be unambiguously decidable", because, for an example : My example is totaly unambiguously decidable for an interpreter. It's for a human reader that it might lead to mistakes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 00:34:05 2017 From: report at bugs.python.org (Liran Nuna) Date: Wed, 20 Dec 2017 05:34:05 +0000 Subject: [issue32204] async/await performance is very low In-Reply-To: <1512292149.52.0.213398074469.issue32204@psf.upfronthosting.co.za> Message-ID: <1513748045.03.0.213398074469.issue32204@psf.upfronthosting.co.za> Liran Nuna added the comment: Yuri, Those speed improvements are awesome and I'm really excited about them, performance is slowly starting to match asynq and would make us migrating our code to async/await more feasable! Today, python3.6.4 was released and these performance improvements did not make it in this version. I'm not familiar with python's release processes , what are the steps or time line for these to be backported to 3.6 and released on next minor version as to avoid a lengthy wait for python3.7? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 01:07:25 2017 From: report at bugs.python.org (tianjg) Date: Wed, 20 Dec 2017 06:07:25 +0000 Subject: [issue32381] python3.6 can not reopen .pyc file with Chinese path Message-ID: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za> New submission from tianjg : have a problem that python3.6 can not reopen .pyc file with Chinese path, and python3.5 can reopen the same pyc file. As shown in the picture ---------- components: Windows files: 20171218111240.jpg messages: 308705 nosy: paul.moore, steve.dower, tianjg, tim.golden, zach.ware priority: normal severity: normal status: open title: python3.6 can not reopen .pyc file with Chinese path type: compile error versions: Python 3.6 Added file: https://bugs.python.org/file47341/20171218111240.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 02:18:20 2017 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Wed, 20 Dec 2017 07:18:20 +0000 Subject: [issue27456] asyncio: set TCP_NODELAY flag by default In-Reply-To: <1467732468.65.0.201519937735.issue27456@psf.upfronthosting.co.za> Message-ID: <1513754300.56.0.213398074469.issue27456@psf.upfronthosting.co.za> ???? ????????? added the comment: Note, TCP_NODELAY can not be set on UNIX streaming socket. Do you have corresponding tests for UNIX sockets ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 02:35:55 2017 From: report at bugs.python.org (Eryk Sun) Date: Wed, 20 Dec 2017 07:35:55 +0000 Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za> Message-ID: <1513755355.67.0.213398074469.issue32381@psf.upfronthosting.co.za> Eryk Sun added the comment: run_file encodes the file path via PyUnicode_EncodeFSDefault, which encodes as UTF-8 in Windows, starting with 3.6. PyRun_SimpleFileExFlags subsequently tries to open this encoded path via _Py_fopen, which calls fopen. The CRT expects an ANSI encoded path, so only the common ASCII subset will work. Non-ASCII paths will fail. This could be addressed in _Py_fopen by decoding the path and calling _wfopen instead of fopen. Executing a .pyc also fails in 3.5 if the wide-character path can't be encoded as ANSI, but the 3.5 branch only accepts security fixes. ---------- components: +Interpreter Core, Unicode nosy: +eryksun, ezio.melotti, vstinner stage: -> test needed title: python3.6 can not reopen .pyc file with Chinese path -> Python 3.6 cannot reopen .pyc file with non-ASCII path type: compile error -> behavior versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 03:33:23 2017 From: report at bugs.python.org (Christoph Reiter) Date: Wed, 20 Dec 2017 08:33:23 +0000 Subject: [issue32268] quopri.decode(): string argument expected, got 'bytes' In-Reply-To: <1512902753.61.0.213398074469.issue32268@psf.upfronthosting.co.za> Message-ID: <1513758803.03.0.213398074469.issue32268@psf.upfronthosting.co.za> Change by Christoph Reiter : ---------- nosy: -lazka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 03:39:03 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 20 Dec 2017 08:39:03 +0000 Subject: [issue32185] SSLContext.wrap_socket sends SNI Extension when server_hostname is IP In-Reply-To: <1512065109.64.0.213398074469.issue32185@psf.upfronthosting.co.za> Message-ID: <1513759143.39.0.213398074469.issue32185@psf.upfronthosting.co.za> Change by Christian Heimes : ---------- keywords: +3.5regression stage: -> patch review type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 03:42:12 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 20 Dec 2017 08:42:12 +0000 Subject: [issue32185] SSLContext.wrap_socket sends SNI Extension when server_hostname is IP In-Reply-To: <1512065109.64.0.213398074469.issue32185@psf.upfronthosting.co.za> Message-ID: <1513759332.96.0.213398074469.issue32185@psf.upfronthosting.co.za> Change by Christian Heimes : ---------- keywords: +patch pull_requests: +4829 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 03:54:11 2017 From: report at bugs.python.org (Atsuo Ishimoto) Date: Wed, 20 Dec 2017 08:54:11 +0000 Subject: [issue16482] pdb.set_trace() clobbering traceback on error In-Reply-To: <1353002125.56.0.265106335805.issue16482@psf.upfronthosting.co.za> Message-ID: <1513760051.38.0.213398074469.issue16482@psf.upfronthosting.co.za> Change by Atsuo Ishimoto : ---------- nosy: +ishimoto _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 03:56:12 2017 From: report at bugs.python.org (Atsuo Ishimoto) Date: Wed, 20 Dec 2017 08:56:12 +0000 Subject: [issue17277] incorrect line numbers in backtrace after removing a trace function In-Reply-To: <1361551369.14.0.772985934528.issue17277@psf.upfronthosting.co.za> Message-ID: <1513760172.4.0.213398074469.issue17277@psf.upfronthosting.co.za> Change by Atsuo Ishimoto : ---------- nosy: +ishimoto _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 04:01:29 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 09:01:29 +0000 Subject: [issue32375] Compilation warnings with gcc In-Reply-To: <1513695924.3.0.213398074469.issue32375@psf.upfronthosting.co.za> Message-ID: <1513760489.7.0.213398074469.issue32375@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is the command line: gcc -pthread -c -Wno-unused-result -Wsign-compare -g -Og -Wall -Wstrict-prototypes -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -I. -I./Include -DPy_BUILD_CORE -DPYTHONPATH='":"' \ -DPREFIX='"/usr/local"' \ -DEXEC_PREFIX='"/usr/local"' \ -DVERSION='"3.7"' \ -DVPATH='""' \ -o Modules/getpath.o ./Modules/getpath.c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 04:53:43 2017 From: report at bugs.python.org (Tianjg) Date: Wed, 20 Dec 2017 09:53:43 +0000 Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path In-Reply-To: <1513755355.67.0.213398074469.issue32381@psf.upfronthosting.co.za> Message-ID: Tianjg added the comment: Thanks a lot. What should I do to reopen .pyc file with non-ASCII path use python3.6 in cmd?Could you give me* some **code examples*.Thank you again, and I look forward to hearing from you 2017-12-20 15:35 GMT+08:00 Eryk Sun : > > Eryk Sun added the comment: > > run_file encodes the file path via PyUnicode_EncodeFSDefault, which > encodes as UTF-8 in Windows, starting with 3.6. PyRun_SimpleFileExFlags > subsequently tries to open this encoded path via _Py_fopen, which calls > fopen. The CRT expects an ANSI encoded path, so only the common ASCII > subset will work. Non-ASCII paths will fail. > > This could be addressed in _Py_fopen by decoding the path and calling > _wfopen instead of fopen. > > Executing a .pyc also fails in 3.5 if the wide-character path can't be > encoded as ANSI, but the 3.5 branch only accepts security fixes. > > ---------- > components: +Interpreter Core, Unicode > nosy: +eryksun, ezio.melotti, vstinner > stage: -> test needed > title: python3.6 can not reopen .pyc file with Chinese path -> Python 3.6 > cannot reopen .pyc file with non-ASCII path > type: compile error -> behavior > versions: +Python 3.7 > > _______________________________________ > Python tracker > > _______________________________________ > ---------- nosy: +Tianjg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 04:55:32 2017 From: report at bugs.python.org (Weize Xu) Date: Wed, 20 Dec 2017 09:55:32 +0000 Subject: [issue32382] Python mulitiprocessing.Queue fail to get according to correct sequence Message-ID: <1513763732.34.0.213398074469.issue32382@psf.upfronthosting.co.za> New submission from Weize Xu : I try to implement a "producer consumer" like design with mulitiprocessing module in my project, but I found that mulitiprocessing.Queue 's behavior is not as my expected. It seems Queue.get method return the end flag at the end of my queue too early. I am not experienced at muliti-process programing, I am not sure it's a bug or not. For reproduce this, I have simplified my code as following: ``` Python import time import multiprocessing as mp def worker(task_queue, output_queue): while 1: i = task_queue.get() if i is None: print("Process-%d done"%mp.current_process().pid) task_queue.task_done() break output_queue.put(i+1) task_queue.task_done() def outputer(output_queue): c = 0 # val for count how many obj geted while 1: j = output_queue.get() if j is None: print("Process(output)-%d done"%mp.current_process().pid) c += 1 print("outputer get %d objects from the output_queue"%c) assert output_queue.empty(), "output queue should be empty here" break time.sleep(0.0001) # do output here c += 1 if __name__ == "__main__": task_queue = mp.JoinableQueue() #output_queue = mp.JoinableQueue() output_queue = mp.Queue() workers = [mp.Process(target=worker, args=(task_queue, output_queue)) for i in range(10)] outputer = mp.Process(target=outputer, args=(output_queue,)) for w in workers: w.start() outputer.start() for i in range(10**6): task_queue.put(i) for w in workers: # put end flag to task queue task_queue.put(None) task_queue.join() # wait all tasks done print("all tasks done.") print("queue size before put end flag: %d"%output_queue.qsize()) output_queue.put(None) # put end flag to output queue print("end") ``` Get the output: Process-20923 done Process-20931 done Process-20925 done Process-20930 done Process-20927 done Process-20929 done Process-20928 done Process-20926 done Process-20924 done Process-20932 done all tasks done. queue size before put end flag: 914789 end Process(output)-20933 done outputer get 90383 objects from the output_queue Process Process-11: Traceback (most recent call last): File "/home/nanguage/S/miniconda3/lib/python3.6/multiprocessing/process.py", line 249, in _bootstrap self.run() File "/home/nanguage/S/miniconda3/lib/python3.6/multiprocessing/process.py", line 93, in run self._target(*self._args, **self._kwargs) File "joinablequeue.py", line 27, in outputer assert output_queue.empty(), "output queue should be empty here" AssertionError: output queue should be empty here I have wait all worker put the output to the output queue use taks_queue.join(), then I put the end flag to the output queue, but according to outputer's printed information, it get the `None` end flag before other value in the queue. It seems queue not get value according to 'FIFO' rule. ---------- components: Library (Lib) messages: 308710 nosy: Weize Xu, davin priority: normal severity: normal status: open title: Python mulitiprocessing.Queue fail to get according to correct sequence type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 04:57:21 2017 From: report at bugs.python.org (=?utf-8?b?0J3QuNC60L7Qu9Cw0Lkg0KHQvtC60L7Qu9C+0LI=?=) Date: Wed, 20 Dec 2017 09:57:21 +0000 Subject: [issue32383] subprocess.Popen() is slower than subprocess.run() Message-ID: <1513763841.52.0.213398074469.issue32383@psf.upfronthosting.co.za> New submission from ??????? ??????? : Hello. I noticed different speed of application, which was execute with subprocess.Popen() and subprocess.run(). I tested on Linux Ubuntu 17.04 and Windows 10. My command line is: "ffmpeg -i big_buck_bunny_480p_surround-fix.avi -f null -" you can use any video file on your PC. I used ffmpeg (open source encoder/decoder/and etc.), but you can use any applications, which counts himself speed of work. I got a difference in speed: Using by terminal: fps=4402 (frame per second); Using by run(): fps=4019; Using by Popen(): fps=3431; On Windows is difference about 5% percent, on Linux about 10% percent. I did not use additional flags. All by default. I downloaded video stream here https://peach.blender.org/download/ ---------- components: Library (Lib) messages: 308711 nosy: ??????? ??????? priority: normal severity: normal status: open title: subprocess.Popen() is slower than subprocess.run() type: performance versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 05:04:19 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 10:04:19 +0000 Subject: [issue32185] SSLContext.wrap_socket sends SNI Extension when server_hostname is IP In-Reply-To: <1512065109.64.0.213398074469.issue32185@psf.upfronthosting.co.za> Message-ID: <1513764259.04.0.213398074469.issue32185@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > There is no platform-compatible way to detect if a string is an IP address. Actually, you could use the ipaddress module. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 05:14:23 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 10:14:23 +0000 Subject: [issue32185] SSLContext.wrap_socket sends SNI Extension when server_hostname is IP In-Reply-To: <1512065109.64.0.213398074469.issue32185@psf.upfronthosting.co.za> Message-ID: <1513764863.97.0.213398074469.issue32185@psf.upfronthosting.co.za> Antoine Pitrou added the comment: By the way, Windows nowadays has inet_pton(): https://msdn.microsoft.com/en-us/library/windows/desktop/cc805844(v=vs.85).aspx Are there other platforms without it? inet_pton() is part of POSIX. ---------- nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 05:18:05 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 10:18:05 +0000 Subject: [issue31901] atexit callbacks should be run at subinterpreter shutdown In-Reply-To: <1509378283.18.0.213398074469.issue31901@psf.upfronthosting.co.za> Message-ID: <1513765085.09.0.213398074469.issue31901@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New changeset 776407fe893fd42972c7e3f71423d9d86741d07c by Antoine Pitrou (Marcel Plch) in branch 'master': bpo-31901: atexit callbacks should be run at subinterpreter shutdown (#4611) https://github.com/python/cpython/commit/776407fe893fd42972c7e3f71423d9d86741d07c ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 05:18:52 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 10:18:52 +0000 Subject: [issue31901] atexit callbacks should be run at subinterpreter shutdown In-Reply-To: <1509378283.18.0.213398074469.issue31901@psf.upfronthosting.co.za> Message-ID: <1513765132.35.0.213398074469.issue31901@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 05:33:57 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 20 Dec 2017 10:33:57 +0000 Subject: [issue32185] SSLContext.wrap_socket sends SNI Extension when server_hostname is IP In-Reply-To: <1512065109.64.0.213398074469.issue32185@psf.upfronthosting.co.za> Message-ID: <1513766037.52.0.213398074469.issue32185@psf.upfronthosting.co.za> Christian Heimes added the comment: The code works on all platforms with OpenSSL >= 1.0.2. OpenSSL 1.0.1, 0.9.8 and earlier are no longer supported by upstream. Anybody with even marginal interest in secure TLS/SSL should update. Python.org's Windows and macOS binaries are good. The inet_pton() code in my patch is for those poor souls that are stuck with RHEL 6, CentOS 6, or Ubuntu 14.04. RHEL 7, CentOS 7, and Ubuntu 16.04 have OpenSSL 1.0.2. The IP address module is slow and hard to use from C code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 05:34:29 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 20 Dec 2017 10:34:29 +0000 Subject: [issue32185] SSLContext.wrap_socket sends SNI Extension when server_hostname is IP In-Reply-To: <1512065109.64.0.213398074469.issue32185@psf.upfronthosting.co.za> Message-ID: <1513766069.34.0.213398074469.issue32185@psf.upfronthosting.co.za> Christian Heimes added the comment: PS: With OpenSSL >= 1.0.2, inet_pton() is not required. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 05:38:06 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 10:38:06 +0000 Subject: [issue29970] Severe open file leakage running asyncio SSL server In-Reply-To: <1491228615.05.0.224246839796.issue29970@psf.upfronthosting.co.za> Message-ID: <1513766286.73.0.213398074469.issue29970@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- pull_requests: +4830 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 05:50:40 2017 From: report at bugs.python.org (Liqun Peng) Date: Wed, 20 Dec 2017 10:50:40 +0000 Subject: [issue32384] Generator tests is broken in non-CPython implementation Message-ID: <1513767040.63.0.213398074469.issue32384@psf.upfronthosting.co.za> New submission from Liqun Peng : The fix for bpo-30039 introduced a regression test in `test.test_generators` which uses `_testcapi` module, it doesn't check `ImportError` and so breaks on other implementations. ---------- components: Tests messages: 308717 nosy: isaiahp priority: normal severity: normal status: open title: Generator tests is broken in non-CPython implementation type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 06:09:59 2017 From: report at bugs.python.org (Creideiki) Date: Wed, 20 Dec 2017 11:09:59 +0000 Subject: [issue32345] EIO from write() is only fatal if print() contains a newline In-Reply-To: <1513416512.67.0.213398074469.issue32345@psf.upfronthosting.co.za> Message-ID: <1513768199.13.0.213398074469.issue32345@psf.upfronthosting.co.za> Creideiki added the comment: Hmm. Yes and no; you seem to be correct in that the problem is on the libc level, but Python definitely does something special. By the way, this is glibc 2.26. I tried this C program: #include #include int main() { usleep(5 * 1000 * 1000); fwrite("A", 1, 1, stdout); perror("A"); fwrite("\n", 1, 1, stdout); perror("newline 1"); fwrite("B\nC", 3, 1, stdout); perror("BC"); fwrite("\n", 1, 1, stdout); perror("newline 2"); fwrite("D", 1, 1, stdout); perror("D"); fwrite("\n", 1, 1, stdout); perror("newline 3"); return 0; } Which behaves similarly when there's a newline in the middle of the string, in that fwrite() returns with an error after writing the newline: write(3, "A: Success\n", 11) = -1 EIO (Input/output error) write(1, "A\n", 2) = -1 EIO (Input/output error) write(3, "newline 1: Input/output error\n", 30) = -1 EIO (Input/output error) write(1, "B\n", 2) = -1 EIO (Input/output error) write(3, "BC: Input/output error\n", 23) = -1 EIO (Input/output error) write(1, "\n", 1) = -1 EIO (Input/output error) write(3, "newline 2: Input/output error\n", 30) = -1 EIO (Input/output error) write(3, "D: Input/output error\n", 22) = -1 EIO (Input/output error) write(1, "D\n", 2) = -1 EIO (Input/output error) write(3, "newline 3: Input/output error\n", 30) = -1 EIO (Input/output error) However, as can be seen from the result of the perror() calls, every fwrite() after the first buffer flush (which happens on newlines, since stdout to a terminal is line buffered) fails with EIO. This should mean that, at the latest, the second Python print() call should fail. But it doesn't: #!/bin/env python2.7 import time time.sleep(5) print('A') print('E') print('B\nC') print('D') write(1, "A\n", 2) = -1 EIO (Input/output error) write(1, "E\n", 2) = -1 EIO (Input/output error) write(1, "B\n", 2) = -1 EIO (Input/output error) write(2, "Traceback (most recent call last):\n", 35) = -1 EIO (Input/output error) write(2, " File \"./fatal.py\", line 6, in \n", 41) = -1 EIO (Input/output error) So Python does make a difference between the implicit newline added to the end of each print() and a newline in the middle of the user-supplied string. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 06:13:36 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 11:13:36 +0000 Subject: [issue32345] EIO from write() is only fatal if print() contains a newline In-Reply-To: <1513416512.67.0.213398074469.issue32345@psf.upfronthosting.co.za> Message-ID: <1513768416.5.0.213398074469.issue32345@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think the difference here is that Python calls ferror() to tell whether an error occurred on the underlying FILE*. Can you adapt your C program to check ferror()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 06:21:24 2017 From: report at bugs.python.org (=?utf-8?q?David_Luke=C5=A1?=) Date: Wed, 20 Dec 2017 11:21:24 +0000 Subject: [issue32306] Clarify map API in concurrent.futures In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za> Message-ID: <1513768884.04.0.213398074469.issue32306@psf.upfronthosting.co.za> David Luke? added the comment: Hi Antoine, Thanks for the response! :) I think the problem lies in the line immediately preceding the code you've posted: ``` fs = [self.submit(fn, *args) for args in zip(*iterables)] ``` In other words, all the jobs are first submitted and their futures stored in a list, which is then iterated over. This approach obviously breaks down when there is a great number of jobs, or when it's part of a pipeline meant for processing jobs continuously as they come. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 06:23:19 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Dec 2017 11:23:19 +0000 Subject: [issue32375] Compilation warnings with gcc In-Reply-To: <1513695924.3.0.213398074469.issue32375@psf.upfronthosting.co.za> Message-ID: <1513768999.68.0.213398074469.issue32375@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The same on Ubuntu 17.10 with gcc 7.2.0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 06:31:39 2017 From: report at bugs.python.org (Stefan Krah) Date: Wed, 20 Dec 2017 11:31:39 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513769499.36.0.213398074469.issue32361@psf.upfronthosting.co.za> Stefan Krah added the comment: > Stefan, your last example is formally speaking OK, if one reads the "Execution model" literally. The original example is however too +ambiguous, so it is good that it triggers an error. OK yes -- desirable, no. IMO execution models are not a great definition for scoping. It certainly prevents Python scopes from being called "lexical scopes". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 06:31:49 2017 From: report at bugs.python.org (Eryk Sun) Date: Wed, 20 Dec 2017 11:31:49 +0000 Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za> Message-ID: <1513769509.19.0.213398074469.issue32381@psf.upfronthosting.co.za> Eryk Sun added the comment: Workarounds: (1) force 3.6 to use the legacy ANSI filesystem encoding by setting the environment variable PYTHONLEGACYWINDOWSFSENCODING. (2) Use 8.3 DOS names, if creating them is enabled on the volume. You can check their value in CMD via `dir /x`. (3) Create alternative directory symbolic links or junctions with ASCII names via CMD's `mklink` command. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 06:32:22 2017 From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=) Date: Wed, 20 Dec 2017 11:32:22 +0000 Subject: [issue1294959] Problems with /usr/lib64 builds. Message-ID: <1513769542.28.0.213398074469.issue1294959@psf.upfronthosting.co.za> Change by Miro Hron?ok : ---------- nosy: +encukou, hroncok _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 06:33:51 2017 From: report at bugs.python.org (=?utf-8?b?0J3QuNC60L7Qu9Cw0Lkg0KHQvtC60L7Qu9C+0LI=?=) Date: Wed, 20 Dec 2017 11:33:51 +0000 Subject: [issue32383] subprocess.Popen() is slower than subprocess.run() In-Reply-To: <1513763841.52.0.213398074469.issue32383@psf.upfronthosting.co.za> Message-ID: <1513769631.68.0.213398074469.issue32383@psf.upfronthosting.co.za> ??????? ??????? added the comment: I incorrectly used the loop to check if the process is alive: while process.poll() is None: pass else: stdout, stderr = process.communicate() ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 06:34:47 2017 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Wed, 20 Dec 2017 11:34:47 +0000 Subject: [issue32221] Converting ipv6 address to string representation using getnameinfo() is wrong. In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za> Message-ID: <1513769687.65.0.213398074469.issue32221@psf.upfronthosting.co.za> ???? ????????? added the comment: Original (not patched) python: ``` In [1]s = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM) In [2]: s.bind(('ff02::1de:c0db', 1234, 0, 2)) In [3]: timeit s.getsockname() The slowest run took 12.06 times longer than the fastest. This could mean that an intermediate result is being cached. 100000 loops, best of 3: 3.8 ?s per loop In [5]: d = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM) In [6]: d.bind(('::', 1235, 0, 0)) In [7]: timeit d.getsockname() The slowest run took 23.18 times longer than the fastest. This could mean that an intermediate result is being cached. 1000000 loops, best of 3: 532 ns per loop ``` On patched version, times for both cases should be the same exactly (i.e. 532 ns) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 06:36:12 2017 From: report at bugs.python.org (Isaiah Peng) Date: Wed, 20 Dec 2017 11:36:12 +0000 Subject: [issue32384] Generator tests is broken in non-CPython implementation In-Reply-To: <1513767040.63.0.213398074469.issue32384@psf.upfronthosting.co.za> Message-ID: <1513769772.01.0.213398074469.issue32384@psf.upfronthosting.co.za> Change by Isaiah Peng : ---------- keywords: +patch pull_requests: +4831 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 06:36:38 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 11:36:38 +0000 Subject: [issue32306] Clarify map API in concurrent.futures In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za> Message-ID: <1513769798.17.0.213398074469.issue32306@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I see. So the problem you are pointing out is that the tasks *arguments* are consumed eagerly. I agree that may be a problem in some cases, though I think in most cases people are concerned with the *results*. (note that multiprocessing.Pool() has an imap() method which does what you would like) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 06:44:11 2017 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Wed, 20 Dec 2017 11:44:11 +0000 Subject: [issue32221] Converting ipv6 address to string representation using getnameinfo() is wrong. In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za> Message-ID: <1513770251.45.0.213398074469.issue32221@psf.upfronthosting.co.za> ???? ????????? added the comment: So it may affect applications, that work with UDP and .recvfrom() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 07:06:40 2017 From: report at bugs.python.org (=?utf-8?q?David_Luke=C5=A1?=) Date: Wed, 20 Dec 2017 12:06:40 +0000 Subject: [issue32306] Clarify map API in concurrent.futures In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za> Message-ID: <1513771600.8.0.213398074469.issue32306@psf.upfronthosting.co.za> David Luke? added the comment: Yes, sorry for not being quite clear the first time around :) I eventually found out about Pool.imap (see item 3 on list in OP) and indeed it fits my use case very nicely, but my point was that the documentation is somewhat misleading with respect to the semantics of built-in `map()` in Python 3. Specifically, I would argue that it is unexpected for a function which claims to be "Equivalent to map(func, *iterables)" to require allocating a list the length of the shortest iterable. Maybe a code example will make this clearer for potential newcomers to the discussion -- this is what I would expect to happen (= the behavior of built-in `map()` itself), yielding values from the iterable is interleaved with calls to the mapped function: ``` >>> def gen(): ... for i in range(3): ... print("yielding", i) ... yield i ... >>> def add1(i): ... print("adding 1 to", i) ... return i + 1 ... >>> list(map(add1, gen())) yielding 0 adding 1 to 0 yielding 1 adding 1 to 1 yielding 2 adding 1 to 2 [1, 2, 3] ``` This is what happens instead with `concurrent.futures.Executor.map()`: ``` >>> def my_map(fn, iterable): ... lst = list(iterable) ... for i in lst: ... yield fn(i) ... >>> list(my_map(add1, gen())) yielding 0 yielding 1 yielding 2 adding 1 to 0 adding 1 to 1 adding 1 to 2 [1, 2, 3] ``` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 07:41:00 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 12:41:00 +0000 Subject: [issue32221] Converting ipv6 address to string representation using getnameinfo() is wrong. In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za> Message-ID: <1513773660.61.0.213398074469.issue32221@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Wow. That's a heavy price to pay indeed. Unfortunately I'm not competent on IPv6. I'm cc-ing other core developers so that they may chime in. ---------- nosy: +gregory.p.smith, neologix, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 07:45:19 2017 From: report at bugs.python.org (Camion) Date: Wed, 20 Dec 2017 12:45:19 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513773919.28.0.213398074469.issue32361@psf.upfronthosting.co.za> Camion added the comment: Stefan, You wrote : ? It certainly prevents Python scopes from being called "lexical scopes". ? I don't understand why... Could you explain ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 07:58:22 2017 From: report at bugs.python.org (Stefan Krah) Date: Wed, 20 Dec 2017 12:58:22 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513774702.79.0.213398074469.issue32361@psf.upfronthosting.co.za> Stefan Krah added the comment: Because in the example in msg308683 true lexical scoping should, when processing g()'s name space, search for the name 'a' in the lexically closest scope f(), find it there and conclude that 'a' cannot be global. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 08:10:12 2017 From: report at bugs.python.org (Creideiki) Date: Wed, 20 Dec 2017 13:10:12 +0000 Subject: [issue32345] EIO from write() is only fatal if print() contains a newline In-Reply-To: <1513416512.67.0.213398074469.issue32345@psf.upfronthosting.co.za> Message-ID: <1513775412.66.0.213398074469.issue32345@psf.upfronthosting.co.za> Creideiki added the comment: I ran this program: #include #include #include #include void print(const char *s, size_t l) { errno = 0; fwrite(s, l, 1, stdout); int saved_errno = errno; fprintf(stderr, "After \"%s\": ferror(): %i, strerror(): %s\n", s, ferror(stdout), strerror(saved_errno)); clearerr(stdout); } int main() { usleep(5 * 1000 * 1000); print("A", 1); print("\n", 1); print("B\nC", 3); print("\n", 1); print("D", 1); print("\n", 1); return 0; } Got this result: write(2, "After \"A\": ferror(): 0, strerror(): Success\n", 44) = -1 EIO (Input/output error) write(1, "A\n", 2) = -1 EIO (Input/output error) write(2, "After \"\n\": ferror(): 1, strerror(): Input/output error\n", 55) = -1 EIO (Input/output error) write(1, "B\n", 2) = -1 EIO (Input/output error) write(2, "After \"B\nC\": ferror(): 1, strerror(): Input/output error\n", 57) = -1 EIO (Input/output error) write(1, "\n", 1) = -1 EIO (Input/output error) write(2, "After \"\n\": ferror(): 1, strerror(): Input/output error\n", 55) = -1 EIO (Input/output error) write(2, "After \"D\": ferror(): 0, strerror(): Success\n", 44) = -1 EIO (Input/output error) write(1, "D\n", 2) = -1 EIO (Input/output error) write(2, "After \"\n\": ferror(): 1, strerror(): Input/output error\n", 55) = -1 EIO (Input/output error) So, fwrite() with a string which does not contain a newline is buffered and ferror() returns 0. fwrite() with a string which does contain a newline, in the middle or at the end, flushes the buffer and makes ferror() return 1. I think this means that after print('A') gets turned into write(1, "A\n", 2), ferror() should still be 1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 09:06:12 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Dec 2017 14:06:12 +0000 Subject: [issue32379] MRO computation could be faster In-Reply-To: <1513713299.76.0.213398074469.issue32379@psf.upfronthosting.co.za> Message-ID: <1513778772.0.0.213398074469.issue32379@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM in general. But mro() returns a list. "class Test: pass" is a trivial case. What are results if the class has a parent? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 09:15:19 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 14:15:19 +0000 Subject: [issue32379] MRO computation could be faster In-Reply-To: <1513713299.76.0.213398074469.issue32379@psf.upfronthosting.co.za> Message-ID: <1513779319.88.0.213398074469.issue32379@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Benchmarks with a parent: * Before: $ ./env-orig/bin/pyperf timeit -s "from unittest import TestCase" "class Test(TestCase): pass" ..................... Mean +- std dev: 10.4 us +- 0.1 us * After: $ ./env/bin/pyperf timeit -s "from unittest import TestCase" "class Test(TestCase): pass" ..................... Mean +- std dev: 9.89 us +- 0.12 us ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 09:24:04 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Dec 2017 14:24:04 +0000 Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za> Message-ID: <1513779843.99.0.213398074469.issue32381@psf.upfronthosting.co.za> Change by R. David Murray : ---------- keywords: +3.6regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 09:35:03 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Dec 2017 14:35:03 +0000 Subject: [issue32384] Generator tests is broken in non-CPython implementation In-Reply-To: <1513767040.63.0.213398074469.issue32384@psf.upfronthosting.co.za> Message-ID: <1513780503.94.0.213398074469.issue32384@psf.upfronthosting.co.za> Change by R. David Murray : ---------- nosy: +yselivanov type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 09:38:28 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 20 Dec 2017 14:38:28 +0000 Subject: [issue30697] segfault in PyErr_NormalizeException() after memory exhaustion In-Reply-To: <1497792581.23.0.578886308028.issue30697@psf.upfronthosting.co.za> Message-ID: <1513780708.06.0.213398074469.issue30697@psf.upfronthosting.co.za> Change by Xavier de Gaye : ---------- pull_requests: +4833 stage: resolved -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 09:47:52 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 Dec 2017 14:47:52 +0000 Subject: [issue32204] async/await performance is very low In-Reply-To: <1512292149.52.0.213398074469.issue32204@psf.upfronthosting.co.za> Message-ID: <1513781272.97.0.213398074469.issue32204@psf.upfronthosting.co.za> Yury Selivanov added the comment: Unfortunately they will not be backported, that's against our release policies, and I can't do anything about it. You can backport them yourself and build your own CPython 3.6. That's what bigger users (e.g. Facebook/Google) of Python usually do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 09:52:46 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 20 Dec 2017 14:52:46 +0000 Subject: [issue30697] segfault in PyErr_NormalizeException() after memory exhaustion In-Reply-To: <1497792581.23.0.578886308028.issue30697@psf.upfronthosting.co.za> Message-ID: <1513781566.4.0.213398074469.issue30697@psf.upfronthosting.co.za> Xavier de Gaye added the comment: As a reference the discussion about the removal of PyExc_RecursionErrorInst took place at PR 1981. The new PR 4941 restores PyExc_RecursionErrorInst on 3.6, not sure if this should be merged. The same operation could be done on 3.7. Python is not using PyExc_RecursionErrorInst anymore and it is doubtful that anyone does. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 09:58:23 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 14:58:23 +0000 Subject: [issue32379] MRO computation could be faster In-Reply-To: <1513713299.76.0.213398074469.issue32379@psf.upfronthosting.co.za> Message-ID: <1513781903.76.0.213398074469.issue32379@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New changeset 1f1a34c3145781628e10534440017b3b43211a60 by Antoine Pitrou in branch 'master': bpo-32379: Faster MRO computation for single inheritance (#4932) https://github.com/python/cpython/commit/1f1a34c3145781628e10534440017b3b43211a60 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 09:58:51 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 14:58:51 +0000 Subject: [issue32379] MRO computation could be faster In-Reply-To: <1513713299.76.0.213398074469.issue32379@psf.upfronthosting.co.za> Message-ID: <1513781931.45.0.213398074469.issue32379@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 10:29:11 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 15:29:11 +0000 Subject: [issue32346] Speed up slot lookup for class creation In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za> Message-ID: <1513783751.77.0.213398074469.issue32346@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated benchmarks against git master (and using pyperf): - before: $ ./env-orig/bin/pyperf timeit -q "class Test: pass" Mean +- std dev: 8.89 us +- 0.09 us $ ./env-orig/bin/pyperf timeit -q -s "from logging import Logger" "class Test(Logger): pass" Mean +- std dev: 12.0 us +- 0.2 us $ ./env-orig/bin/pyperf timeit -q -s "from unittest.mock import MagicMock" "class Test(MagicMock): pass" Mean +- std dev: 18.6 us +- 0.2 us - after: $ ./env/bin/pyperf timeit -q "class Test: pass" Mean +- std dev: 6.90 us +- 0.11 us $ ./env/bin/pyperf timeit -q -s "from logging import Logger" "class Test(Logger): pass" Mean +- std dev: 5.86 us +- 0.08 us $ ./env/bin/pyperf timeit -q -s "from unittest.mock import MagicMock" "class Test(MagicMock): pass" Mean +- std dev: 6.13 us +- 0.08 us ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 10:40:56 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Dec 2017 15:40:56 +0000 Subject: [issue32385] Clean up the C3 MRO algorithm implementation. Message-ID: <1513784456.46.0.213398074469.issue32385@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : The C3 MRO algorithm implementation uses lists and converts input tuples to lists. This is redundant, because these lists are not mutated. The proposed PR makes the implementation using tuples and gets rid of unneeded conversions. ---------- components: Interpreter Core messages: 308739 nosy: pitrou, serhiy.storchaka priority: normal severity: normal status: open title: Clean up the C3 MRO algorithm implementation. type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 10:42:35 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Dec 2017 15:42:35 +0000 Subject: [issue32385] Clean up the C3 MRO algorithm implementation. In-Reply-To: <1513784456.46.0.213398074469.issue32385@psf.upfronthosting.co.za> Message-ID: <1513784555.65.0.213398074469.issue32385@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +4834 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 10:44:33 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 15:44:33 +0000 Subject: [issue32386] dynload_next.c is obsolete Message-ID: <1513784673.38.0.213398074469.issue32386@psf.upfronthosting.co.za> New submission from Antoine Pitrou : The configure scripts has the following comment: """Use dynload_next.c only on 10.2 and below, which don't have native dlopen()""" It seems dynload_next.c can be removed now. ---------- messages: 308740 nosy: ned.deily, pitrou, ronaldoussoren priority: normal severity: normal status: open title: dynload_next.c is obsolete type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 10:47:54 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 15:47:54 +0000 Subject: [issue32387] Disallow untagged C extension import on major platforms Message-ID: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Windows and the major POSIX platforms (including Linux and macOS) now support loading C extension with a version-tagged name (and build them likewise), such as "foobar.cpython-36.so". Following the discussion in https://mail.python.org/pipermail/python-dev/2017-December/151328.html, I propose to remove the ability to load untagged C extension names on those platforms. IOW, "foobar.dll" or "foobar.so" will not be recognized when "import foobar" is executed anymore. ---------- components: Interpreter Core messages: 308741 nosy: brett.cannon, eric.snow, ncoghlan, ned.deily, paul.moore, pitrou, ronaldoussoren, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Disallow untagged C extension import on major platforms type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 10:49:45 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 15:49:45 +0000 Subject: [issue32387] Disallow untagged C extension import on major platforms In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za> Message-ID: <1513784985.37.0.213398074469.issue32387@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- nosy: +njs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 10:50:04 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 15:50:04 +0000 Subject: [issue32387] Disallow untagged C extension import on major platforms In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za> Message-ID: <1513785004.68.0.213398074469.issue32387@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- keywords: +patch pull_requests: +4835 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 10:50:25 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 15:50:25 +0000 Subject: [issue32387] Disallow untagged C extension import on major platforms In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za> Message-ID: <1513785025.72.0.213398074469.issue32387@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Interestingly, the test suite doesn't seem affected at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 11:00:37 2017 From: report at bugs.python.org (Camion) Date: Wed, 20 Dec 2017 16:00:37 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513785637.41.0.213398074469.issue32361@psf.upfronthosting.co.za> Camion added the comment: I don't think there anything in the definition of "lexical scoping", which forbids to have a way to access globals from some place. Lexical scoping just means that scoping is defined in regards of the source code, by opposition dynamic scoping, which defines the scope in regard with execution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 11:09:37 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Dec 2017 16:09:37 +0000 Subject: [issue32346] Speed up slot lookup for class creation In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za> Message-ID: <1513786177.47.0.213398074469.issue32346@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Due to its complexity it will take a time to make a review of this patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 11:09:58 2017 From: report at bugs.python.org (Stefan Krah) Date: Wed, 20 Dec 2017 16:09:58 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513786198.97.0.213398074469.issue32361@psf.upfronthosting.co.za> Stefan Krah added the comment: You can access globals, but not through another nested scope where the global name is shadowed. I have to excuse myself from this discussion. It's interesting, but I don't have enough bandwidth. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 11:10:15 2017 From: report at bugs.python.org (Stefan Krah) Date: Wed, 20 Dec 2017 16:10:15 +0000 Subject: [issue32361] global / nonlocal interference : is this a bug, a feature or a design hole ? In-Reply-To: <1513591189.6.0.213398074469.issue32361@psf.upfronthosting.co.za> Message-ID: <1513786215.71.0.213398074469.issue32361@psf.upfronthosting.co.za> Change by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 11:11:55 2017 From: report at bugs.python.org (Michael Haubenwallner) Date: Wed, 20 Dec 2017 16:11:55 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1513786315.03.0.213398074469.issue26439@psf.upfronthosting.co.za> Michael Haubenwallner added the comment: Although I'm unable to double check for the moment, feels like the "SVR4" support still is incomplete: Remember that even the libNAME.so file may be an archive, or a symlink to an archive, with the real Shared Object as member having the F_LOADONLY flag set and usually named shr.o or shr_64.o, besides an Import File shr.imp or shr_64.imp, which actually is used at linktime and referring to the real Shared Object: This is necessary to emulate the "DT_SONAME" feature seen with ELF shared libraries. For reference, please have a look at the shared libraries created by recent libtool when --with-aix-soname=svr4 configure option is set. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 11:14:16 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 16:14:16 +0000 Subject: [issue32346] Speed up slot lookup for class creation In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za> Message-ID: <1513786456.88.0.213398074469.issue32346@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes... The patch itself is not very complex, but you have to dive into the intricacies of typeobject.c to understand it :-/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 11:16:08 2017 From: report at bugs.python.org (irdb) Date: Wed, 20 Dec 2017 16:16:08 +0000 Subject: [issue26568] Add a new warnings.showwarnmsg() function taking a warnings.WarningMessage object In-Reply-To: <1458052320.63.0.791464551893.issue26568@psf.upfronthosting.co.za> Message-ID: <1513786568.88.0.213398074469.issue26568@psf.upfronthosting.co.za> Change by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 11:43:15 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 16:43:15 +0000 Subject: [issue32387] Disallow untagged C extension import on major platforms In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za> Message-ID: <1513788195.69.0.213398074469.issue32387@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Actually, let me correct this: the build fails on Windows (see AppVeyor). That's because the Windows build process, for some reason, produces untagged pyd files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 11:45:07 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 16:45:07 +0000 Subject: [issue32387] Disallow untagged C extension import on major platforms In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za> Message-ID: <1513788307.63.0.213398074469.issue32387@psf.upfronthosting.co.za> Antoine Pitrou added the comment: If I'm understanding correctly, the ".pyd" extension is hardcoded in the various ".vcxproj" files. Which means this PR would need the help of a Windows expert to progress forward :-S ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 12:00:27 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 17:00:27 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513789226.99.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset ca719ac42b3d58f7c3bcdf63f45b6d62b08b0d01 by Victor Stinner in branch 'master': bpo-32030: Add _PyCoreConfig.warnoptions (#4936) https://github.com/python/cpython/commit/ca719ac42b3d58f7c3bcdf63f45b6d62b08b0d01 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 12:18:17 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Dec 2017 17:18:17 +0000 Subject: [issue32385] Clean up the C3 MRO algorithm implementation. In-Reply-To: <1513784456.46.0.213398074469.issue32385@psf.upfronthosting.co.za> Message-ID: <1513790297.79.0.213398074469.issue32385@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This has also a performance effect. $ ./python -m perf timeit -s "class A: pass" -s "class B: pass" --duplicate 1000 "class C(A, B): pass" Before: Mean +- std dev: 9.41 us +- 0.28 us After: Mean +- std dev: 8.94 us +- 0.28 us ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 12:21:04 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Dec 2017 17:21:04 +0000 Subject: [issue32385] Clean up the C3 MRO algorithm implementation. In-Reply-To: <1513784456.46.0.213398074469.issue32385@psf.upfronthosting.co.za> Message-ID: <1513790464.88.0.213398074469.issue32385@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 6b91a5972107ec8dd5334f4f2005626baa2b8847 by Serhiy Storchaka in branch 'master': bpo-32385: Clean up the C3 MRO algorithm implementation. (#4942) https://github.com/python/cpython/commit/6b91a5972107ec8dd5334f4f2005626baa2b8847 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 12:26:59 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 20 Dec 2017 17:26:59 +0000 Subject: [issue32385] Clean up the C3 MRO algorithm implementation. In-Reply-To: <1513784456.46.0.213398074469.issue32385@psf.upfronthosting.co.za> Message-ID: <1513790819.29.0.213398074469.issue32385@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 12:27:59 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 17:27:59 +0000 Subject: [issue32388] Remove cross-version binary compatibility Message-ID: <1513790879.02.0.213398074469.issue32388@psf.upfronthosting.co.za> New submission from Antoine Pitrou : See original discussion on python-dev: https://mail.python.org/pipermail/python-dev/2017-December/151328.html Summary: binary compatibility for C extensions which don't use the stable ABI is currently "best effort" and uses distinguished flags in the tp_flags field of type objects to indicate whether a field is physically present or not. Unfortunately, tp_flags is 32 bits and therefore a scarce resource. Also, binary compatibility is 1) not guaranteed anyway 2) of less use nowadays. So we propose to remove the binary compatibility requirement when creating static type objects (i.e. not using the stable ABI). ---------- components: Interpreter Core messages: 308753 nosy: barry, paul.moore, pitrou, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Remove cross-version binary compatibility type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 12:29:26 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 17:29:26 +0000 Subject: [issue32388] Remove cross-version binary compatibility In-Reply-To: <1513790879.02.0.213398074469.issue32388@psf.upfronthosting.co.za> Message-ID: <1513790966.9.0.213398074469.issue32388@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- nosy: +njs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 12:29:43 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 17:29:43 +0000 Subject: [issue32388] Remove cross-version binary compatibility In-Reply-To: <1513790879.02.0.213398074469.issue32388@psf.upfronthosting.co.za> Message-ID: <1513790983.13.0.213398074469.issue32388@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- keywords: +patch pull_requests: +4836 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 12:30:17 2017 From: report at bugs.python.org (Decorater) Date: Wed, 20 Dec 2017 17:30:17 +0000 Subject: [issue32326] Update Build projects to version 10.0.16299.0 of the Windows 10 SDK. In-Reply-To: <1513283155.41.0.213398074469.issue32326@psf.upfronthosting.co.za> Message-ID: <1513791017.59.0.213398074469.issue32326@psf.upfronthosting.co.za> Change by Decorater : ---------- keywords: +patch pull_requests: +4837 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 12:31:25 2017 From: report at bugs.python.org (Decorater) Date: Wed, 20 Dec 2017 17:31:25 +0000 Subject: [issue32326] Update Build projects to version 10.0.16299.0 of the Windows 10 SDK. In-Reply-To: <1513283155.41.0.213398074469.issue32326@psf.upfronthosting.co.za> Message-ID: <1513791085.41.0.213398074469.issue32326@psf.upfronthosting.co.za> Decorater added the comment: Alright made the backport PR on it. Not sure if it needs an news entry or if it is trivial though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 12:48:47 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 17:48:47 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513792127.01.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4838 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 12:53:22 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 17:53:22 +0000 Subject: [issue32306] Clarify map API in concurrent.futures In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za> Message-ID: <1513792402.47.0.213398074469.issue32306@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- keywords: +patch pull_requests: +4839 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 12:55:26 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 17:55:26 +0000 Subject: [issue32388] Remove cross-version binary compatibility In-Reply-To: <1513790879.02.0.213398074469.issue32388@psf.upfronthosting.co.za> Message-ID: <1513792526.4.0.213398074469.issue32388@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 12:55:33 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 17:55:33 +0000 Subject: [issue32375] Compilation warnings with gcc In-Reply-To: <1513695924.3.0.213398074469.issue32375@psf.upfronthosting.co.za> Message-ID: <1513792533.07.0.213398074469.issue32375@psf.upfronthosting.co.za> STINNER Victor added the comment: Ah, I missed the warning because I forge -O0 when I build Python. https://wiki.ubuntu.com/ToolChain/CompilerFlags Ubuntu adds -D_FORTIFY_SOURCE=2 flag by default. The warnings can be seen with "-D_FORTIFY_SOURCE=2 -Og", but not with "-D_FORTIFY_SOURCE=2 -O3". Moreover, "-D_FORTIFY_SOURCE=2 -O0" complains that _FORTIFY_SOURCE requires to optimize the code. It looks more like a false alarm because -D_FORTIFY_SOURCE=2 is incompatible with -Og. Maybe we should force -D_FORTIFY_SOURCE=0 when we build Python in debug mode? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 12:56:33 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 17:56:33 +0000 Subject: [issue32375] Compilation warnings with gcc In-Reply-To: <1513695924.3.0.213398074469.issue32375@psf.upfronthosting.co.za> Message-ID: <1513792593.51.0.213398074469.issue32375@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't think so. It's good to have fortify enabled, especially in debug mode :-) If the warnings are harmless and there isn't an easy way to suppress them, then I'm ok to close this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 12:57:02 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 17:57:02 +0000 Subject: [issue32375] Compilation warnings in getpath.c with gcc on Ubuntu / -D_FORTIFY_SOURCE=2 In-Reply-To: <1513695924.3.0.213398074469.issue32375@psf.upfronthosting.co.za> Message-ID: <1513792622.98.0.213398074469.issue32375@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- title: Compilation warnings with gcc -> Compilation warnings in getpath.c with gcc on Ubuntu / -D_FORTIFY_SOURCE=2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:02:13 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 18:02:13 +0000 Subject: [issue32375] Compilation warnings in getpath.c with gcc on Ubuntu / -D_FORTIFY_SOURCE=2 In-Reply-To: <1513695924.3.0.213398074469.issue32375@psf.upfronthosting.co.za> Message-ID: <1513792933.94.0.213398074469.issue32375@psf.upfronthosting.co.za> STINNER Victor added the comment: getpath.c uses many buffers of MAXPATHLEN+1 wide characters. Example: wchar_t argv0_path[MAXPATHLEN+1]; These buffers are initialized to zero to make sure that the last character is always a NULL character. To keep the final NULL character, string copies use: wcsncpy(dest, src, MAXPATHLEN); This code is wrong: it truncates the string if it's longer than MAXPATHLEN characters. I modified the code to move global buffers closer to where there are used, and to dynamically allocate strings on the heap, rather using fixed sizes. But I didn't finish to "cleanup" Modules/getpath.c and PC/getpathp.c. The code still uses the buffer of fixed size and truncate strings. The real fix would be to avoid these fixed-size buffers, and only use dynamically allocated strings. I modified the code to allow to report errors. Previously, it wasn't possible exception using Py_FatalError() which is not a nice way to report errors, especially when Python is embedded in an application. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:02:53 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 18:02:53 +0000 Subject: [issue32375] Compilation warnings in getpath.c with gcc on Ubuntu / -D_FORTIFY_SOURCE=2 In-Reply-To: <1513695924.3.0.213398074469.issue32375@psf.upfronthosting.co.za> Message-ID: <1513792973.39.0.213398074469.issue32375@psf.upfronthosting.co.za> STINNER Victor added the comment: See bpo-32030 for my huge refactoring work on the Python initialization code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:04:35 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 18:04:35 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1513793075.1.0.213398074469.issue26439@psf.upfronthosting.co.za> STINNER Victor added the comment: > Although I'm unable to double check for the moment, feels like the "SVR4" support still is incomplete: (...) Sorry, I don't know what is SVR4. Is it a version of AIX? If it's rarely used, maybe a different issue should be opened to ask for an enhancement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:06:23 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 18:06:23 +0000 Subject: [issue32306] Clarify map API in concurrent.futures In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za> Message-ID: <1513793183.87.0.213398074469.issue32306@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New changeset a7a751dd7b08a5bb6cb399c1b2a6ca7b24aba51d by Antoine Pitrou in branch 'master': bpo-32306: Clarify c.f.Executor.map() documentation (#4947) https://github.com/python/cpython/commit/a7a751dd7b08a5bb6cb399c1b2a6ca7b24aba51d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:06:39 2017 From: report at bugs.python.org (Roundup Robot) Date: Wed, 20 Dec 2017 18:06:39 +0000 Subject: [issue32306] Clarify map API in concurrent.futures In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za> Message-ID: <1513793199.91.0.213398074469.issue32306@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4840 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:15:40 2017 From: report at bugs.python.org (Gianguido Piani) Date: Wed, 20 Dec 2017 18:15:40 +0000 Subject: [issue32389] urllib3 wrong computation of 'Content-Length' for file upload Message-ID: <1513793740.16.0.213398074469.issue32389@psf.upfronthosting.co.za> New submission from Gianguido Piani : Hi! This is my first posting ever on this site. I need to upload a simple text file to Internet servers. With "curl" the operation goes smoothly, both with http and https protocols, both up/downloads. With urllib3 and other TCP-IP handlers the generated header for 'Content-Length' contains a wrong file length indication (log verification with TCPDUMP), the file is not uploaded, the servers return different error messages. On the contrary, urllib3 file downloads do work, also with authentication. code example headers = {'authorization': 'Basic ==codeduserpwd=='} resp = http_client.request('PUT', 'https://webserver.com', headers=headers, fields={'whatfile': (filename, file_data)} ) In addition, in the documentation I still haven't figured out what 'whatfile' (or any of the other keywords used there) actually is. Is this a keyword (where is the list of all allowed kwds?), the source file, the target file, or what else?? How does the function behaviour change depending on that indication? Thankful for your support! ---------- components: Library (Lib) messages: 308761 nosy: gianguido priority: normal severity: normal status: open title: urllib3 wrong computation of 'Content-Length' for file upload type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:19:20 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 18:19:20 +0000 Subject: [issue32306] Clarify map API in concurrent.futures In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za> Message-ID: <1513793960.4.0.213398074469.issue32306@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New changeset 4aa84e728565a15a82727b9b971126e355f47e9d by Antoine Pitrou (Miss Islington (bot)) in branch '3.6': bpo-32306: Clarify c.f.Executor.map() documentation (GH-4947) (#4948) https://github.com/python/cpython/commit/4aa84e728565a15a82727b9b971126e355f47e9d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:19:42 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 18:19:42 +0000 Subject: [issue32306] Clarify map API in concurrent.futures In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za> Message-ID: <1513793982.52.0.213398074469.issue32306@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think the documentation is now clearer. Closing! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:19:46 2017 From: report at bugs.python.org (Decorater) Date: Wed, 20 Dec 2017 18:19:46 +0000 Subject: [issue32326] Update Build projects to version 10.0.16299.0 of the Windows 10 SDK. In-Reply-To: <1513283155.41.0.213398074469.issue32326@psf.upfronthosting.co.za> Message-ID: <1513793986.93.0.213398074469.issue32326@psf.upfronthosting.co.za> Decorater added the comment: Oddly AppVeyor failed on VS2017 but build works on my end though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:24:45 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 18:24:45 +0000 Subject: [issue29970] Severe open file leakage running asyncio SSL server In-Reply-To: <1491228615.05.0.224246839796.issue29970@psf.upfronthosting.co.za> Message-ID: <1513794285.84.0.213398074469.issue29970@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset 51eb1c6b9c0b382dfd6e0428eacff0c7891a6fc3 by Andrew Svetlov in branch 'master': bpo-29970: Make ssh_handshake_timeout None by default (#4939) https://github.com/python/cpython/commit/51eb1c6b9c0b382dfd6e0428eacff0c7891a6fc3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:36:48 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 18:36:48 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513795008.43.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 9cfc00262c7f6b93072762eed1dc5d94fa3897f0 by Victor Stinner in branch 'master': bpo-32030: Complete _PyCoreConfig_Read() (#4946) https://github.com/python/cpython/commit/9cfc00262c7f6b93072762eed1dc5d94fa3897f0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:39:12 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 18:39:12 +0000 Subject: [issue32389] urllib3 wrong computation of 'Content-Length' for file upload In-Reply-To: <1513793740.16.0.213398074469.issue32389@psf.upfronthosting.co.za> Message-ID: <1513795152.95.0.213398074469.issue32389@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Is your question about urllib3? This bug tracker is about python itself. urllbib3 should be discussed here: https://github.com/shazow/urllib3 ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:39:30 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 Dec 2017 18:39:30 +0000 Subject: [issue32318] Remove "globals()" call from "socket.accept()" In-Reply-To: <1513225934.71.0.213398074469.issue32318@psf.upfronthosting.co.za> Message-ID: <1513795170.62.0.213398074469.issue32318@psf.upfronthosting.co.za> Yury Selivanov added the comment: This was fixed as part of https://bugs.python.org/issue32331 ---------- resolution: -> out of date stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:40:27 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 Dec 2017 18:40:27 +0000 Subject: [issue29970] Severe open file leakage running asyncio SSL server In-Reply-To: <1491228615.05.0.224246839796.issue29970@psf.upfronthosting.co.za> Message-ID: <1513795227.31.0.213398074469.issue29970@psf.upfronthosting.co.za> Yury Selivanov added the comment: Should we backport this to 3.6? This is a security issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:48:17 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 18:48:17 +0000 Subject: [issue32052] Provide access to buffer of asyncio.StreamReader In-Reply-To: <1510859388.33.0.213398074469.issue32052@psf.upfronthosting.co.za> Message-ID: <1513795697.3.0.213398074469.issue32052@psf.upfronthosting.co.za> Andrew Svetlov added the comment: If the problm is in readuntil() functionality -- let's discuss th function improvement (in separate issue). Exposing streams internals is antipattern and very bad idea. I suggest closing the issue. Yury, what is your opinion? ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:49:03 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 18:49:03 +0000 Subject: [issue32364] Add AbstractFuture and AbstractTask In-Reply-To: <1513595590.31.0.213398074469.issue32364@psf.upfronthosting.co.za> Message-ID: <1513795743.94.0.213398074469.issue32364@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Let's postpone it to Python 3.8 ---------- versions: +Python 3.8 -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:50:31 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 Dec 2017 18:50:31 +0000 Subject: [issue32052] Provide access to buffer of asyncio.StreamReader In-Reply-To: <1510859388.33.0.213398074469.issue32052@psf.upfronthosting.co.za> Message-ID: <1513795831.57.0.213398074469.issue32052@psf.upfronthosting.co.za> Yury Selivanov added the comment: I'd be more comfortable with the idea of exposing the buffer when we have BufferedProtocol. Let's wait on this one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:52:50 2017 From: report at bugs.python.org (Michael Felt) Date: Wed, 20 Dec 2017 18:52:50 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1513795970.43.0.213398074469.issue26439@psf.upfronthosting.co.za> Michael Felt added the comment: SVR4 - stands for AT&T System V Release 4 - the beginning (as I understand it) of shared libraries as (indivudual) .so files in UNIX. SVR3 (and earlier) used .a files (aka archives with members inside). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 13:59:15 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 20 Dec 2017 18:59:15 +0000 Subject: [issue32389] urllib3 wrong computation of 'Content-Length' for file upload In-Reply-To: <1513793740.16.0.213398074469.issue32389@psf.upfronthosting.co.za> Message-ID: <1513796355.44.0.213398074469.issue32389@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, this would appear to be both 3rd party and a support request rather than a bug report. Gianguido: please work with the urllib3 community, or post to the python-list mailing list. If you identify an actual bug in Python itself, you can come back here to report it. ---------- nosy: +r.david.murray resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:02:31 2017 From: report at bugs.python.org (Michael Felt) Date: Wed, 20 Dec 2017 19:02:31 +0000 Subject: [issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c: Explicit dimension specification or initializer required Message-ID: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za> New submission from Michael Felt : current level: commit 4b965930e8625f77cb0e821daf5cc40e85b45f84 (HEAD -> master, upstream/master, origin/master, origin/HEAD) Build message: michael at x071:[/data/prj/python/git/python3-3.7.X]make xlc_r -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I. -I./Include -I/opt/include -DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o "./Modules/posixmodule.c", line 5514.11: 1506-131 (W) Explicit dimension specification or initializer required for an auto or static array. "./Modules/posixmodule.c", line 9328.64: 1506-280 (S) Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed. Makefile:1765: recipe for target 'Modules/posixmodule.o' failed make: *** [Modules/posixmodule.o] Error 1 Details (note rewrite from listing for line 5514) 5514 | PyDoc_VAR(os_sched_param__doc__); 5514 + static char os_sched_param__doc__[]; "./Modules/posixmodule.c", line 5514.11: 1506-131 (W) Explicit dimension specification or initializer required for an auto or static array. 5515 | 5516 | static PyStructSequence_Field sched_param_fields[] = { 5517 | {"sched_priority", "the scheduling priority"}, 5518 | {0} 5519 | }; ---------- components: Build messages: 308775 nosy: Michael.Felt priority: normal severity: normal status: open title: AIX (xlc_r) compile error with Modules/posixmodule.c: Explicit dimension specification or initializer required type: compile error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:07:29 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 19:07:29 +0000 Subject: [issue30782] Allow limiting the number of concurrent tasks in asyncio.as_completed In-Reply-To: <1498525522.6.0.617023291854.issue30782@psf.upfronthosting.co.za> Message-ID: <1513796849.3.0.213398074469.issue30782@psf.upfronthosting.co.za> Andrew Svetlov added the comment: as_completed() is low-level API. Let's not overload it with different parameters. Anyway `as_completed()` uses only asyncio.Future and it's public API like `add_done_callback()` etc. You can master everything what you need without asyncio modification. Let's close the issue with "wont fix" resolution. ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:08:53 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 19:08:53 +0000 Subject: [issue31491] Add is_closing() to asyncio.StreamWriter. In-Reply-To: <1505562512.04.0.45746323543.issue31491@psf.upfronthosting.co.za> Message-ID: <1513796933.7.0.213398074469.issue31491@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Makes sense. ---------- assignee: -> asvetlov nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:09:26 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 Dec 2017 19:09:26 +0000 Subject: [issue31491] Add is_closing() to asyncio.StreamWriter. In-Reply-To: <1505562512.04.0.45746323543.issue31491@psf.upfronthosting.co.za> Message-ID: <1513796966.15.0.213398074469.issue31491@psf.upfronthosting.co.za> Yury Selivanov added the comment: OK. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:11:32 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 Dec 2017 19:11:32 +0000 Subject: [issue30782] Allow limiting the number of concurrent tasks in asyncio.as_completed In-Reply-To: <1498525522.6.0.617023291854.issue30782@psf.upfronthosting.co.za> Message-ID: <1513797092.15.0.213398074469.issue30782@psf.upfronthosting.co.za> Yury Selivanov added the comment: I agree, let's keep as_completed() simple for now. Handling generators+async correctly is hard, so we definitely don't have time for this in 3.7. ---------- versions: +Python 3.8 -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:12:25 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 19:12:25 +0000 Subject: [issue32391] Add StreamWriter.wait_closed() Message-ID: <1513797145.51.0.213398074469.issue32391@psf.upfronthosting.co.za> New submission from Andrew Svetlov : Without the method there is no possibility to wait for actual writer closing (it's performed at least on next loop iteration, and even later for SSL transports). Without waiting for actual closing writing tests is a pain: user should either add asyncio.sleep() after writer closing or suppress many warnings about unclosed resources. ---------- components: Library (Lib), asyncio messages: 308780 nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Add StreamWriter.wait_closed() versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:13:19 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 Dec 2017 19:13:19 +0000 Subject: [issue32391] Add StreamWriter.wait_closed() In-Reply-To: <1513797145.51.0.213398074469.issue32391@psf.upfronthosting.co.za> Message-ID: <1513797199.46.0.213398074469.issue32391@psf.upfronthosting.co.za> Yury Selivanov added the comment: We've discussed this before, please go ahead. ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:14:11 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 19:14:11 +0000 Subject: [issue32382] Python mulitiprocessing.Queue fail to get according to correct sequence In-Reply-To: <1513763732.34.0.213398074469.issue32382@psf.upfronthosting.co.za> Message-ID: <1513797251.93.0.213398074469.issue32382@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hi Weize, Since this seems be a support question, I suggest you ask it either on https://stackoverflow.com/ or on the Python users' mailing-list https://mail.python.org/mailman/listinfo/python-list ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:15:14 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 19:15:14 +0000 Subject: [issue32382] Python mulitiprocessing.Queue fail to get according to correct sequence In-Reply-To: <1513763732.34.0.213398074469.issue32382@psf.upfronthosting.co.za> Message-ID: <1513797314.17.0.213398074469.issue32382@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Closing this issue in the meantime. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:22:00 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 19:22:00 +0000 Subject: [issue29970] Severe open file leakage running asyncio SSL server In-Reply-To: <1491228615.05.0.224246839796.issue29970@psf.upfronthosting.co.za> Message-ID: <1513797720.99.0.213398074469.issue29970@psf.upfronthosting.co.za> Andrew Svetlov added the comment: The fix introduces a new parameter in public API. That's why I think we shouldn't backport it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:23:54 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 Dec 2017 19:23:54 +0000 Subject: [issue29970] Severe open file leakage running asyncio SSL server In-Reply-To: <1491228615.05.0.224246839796.issue29970@psf.upfronthosting.co.za> Message-ID: <1513797834.45.0.213398074469.issue29970@psf.upfronthosting.co.za> Yury Selivanov added the comment: > The fix introduces a new parameter in public API. Maybe we can get away with this if we do not document it in 3.6 and add a comment to the source code that using this new parameter will make the code incompatible with earlier 3.6.x versions? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:27:29 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 19:27:29 +0000 Subject: [issue29970] Severe open file leakage running asyncio SSL server In-Reply-To: <1491228615.05.0.224246839796.issue29970@psf.upfronthosting.co.za> Message-ID: <1513798049.23.0.213398074469.issue29970@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Don't know. Ask other coredevs maybe? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:30:57 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 19:30:57 +0000 Subject: [issue17852] Built-in module _io can lose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1513798257.65.0.213398074469.issue17852@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here's another idea: have a new type field (a tp_something) that exposes the GC priority for this type. It could be an integer between -8 and 7, for example (0 being the default). Then tp_finalize would be called in sorted priority order. The tricky part of course is to make this acceptable performance-wise (i.e. avoid walking the collectable list 16 times, once for each priority level). For example by creating bucket lists for each priority level (only for objects with a non-NULL tp_finalize). ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:31:46 2017 From: report at bugs.python.org (Tim Peters) Date: Wed, 20 Dec 2017 19:31:46 +0000 Subject: [issue32382] Python mulitiprocessing.Queue fail to get according to correct sequence In-Reply-To: <1513763732.34.0.213398074469.issue32382@psf.upfronthosting.co.za> Message-ID: <1513798306.18.0.213398074469.issue32382@psf.upfronthosting.co.za> Tim Peters added the comment: First thing: the code uses the global name `outputer` for two different things, as the name of a module function and as the global name given to the Process object running that function. At least on Windows under Python 3.6.4 that confusion prevents the program from running. So rename one of them. Then comes the pain ;-) A multiprocessing queue is a rather complex object under the covers, and the docs don't really spell out all the details. Maybe they should. The docs do vaguely sketch that a "feeder thread" is created in each process using an mp.queue, which feeds object you .put() from an internal buffer into an interprocess pipe. The internal buffer is needed in case you .put() so many objects so fast that feeding them into a pipe directly would cause the OS pipe functions to fail. And that happens in your case: you have 10 producers running at full speed overwhelming a single slow consumer. _Most_ of the data enqueued by output_queue.put(i+1) is sitting in those internal buffers most of the time, and the base interprocess pipe doesn't know anything about them for the duration. The practical consequence: while the queue always reflects the order in which objects were .put() within a single process, there's no guarantee about ordering _across_ processes. Objects are fed from internal buffers into the shared pipe whenever a process's feeder thread happens to wake up and sees that the pipe isn't "too full". task_queue.task_done() only records that an object has been taken off of task_queue and _given_ to output_queue.put(i+1); most of the time, the latter just sticks i+1 into an internal buffer because output_queue's shared pipe is too full to accept another object. Given that this is how things actually work, what you can do instead is add: for w in workers: w.join() somwehere before output_queue.put(None). A worker process doesn't end until its feeder thread(s) complete feeding all the internal buffer objects into pipes, so .join()'ing a worker is the one "obvious" way to guarantee that all the worker's .put() actions have wholly completed. In which case, there's no point to using a JoinableQueue at all - .task_done() no longer serves any real purpose in the code then. ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:35:23 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 20 Dec 2017 19:35:23 +0000 Subject: [issue32387] Disallow untagged C extension import on major platforms In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za> Message-ID: <1513798523.2.0.213398074469.issue32387@psf.upfronthosting.co.za> Gregory P. Smith added the comment: +1 on doing this. It might also be worth examining all of the latest package version wheels on pypi to see which packages claiming to support Python 3 have binary wheels containing untagged .pyd or .so files. ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:36:36 2017 From: report at bugs.python.org (Michael Felt) Date: Wed, 20 Dec 2017 19:36:36 +0000 Subject: [issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed In-Reply-To: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za> Message-ID: <1513798596.32.0.213398074469.issue32390@psf.upfronthosting.co.za> Michael Felt added the comment: OOps - wrong error! It is the new fsid variable! michael at x071:[/data/prj/python/git/python3-3.7.0.a3]xlc_r -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I. -I./Include -I/opt/in> "./Modules/posixmodule.c", line 5514.11: 1506-131 (W) Explicit dimension specification or initializer required for an auto or static array. "./Modules/posixmodule.c", line 9328.64: 1506-280 (S) Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed. 9326 | PyStructSequence_SET_ITEM(v, 9, PyLong_FromLong((long) st.f_namemax)); 9326 + (((PyTupleObject *)(v))->ob_item[9] = PyLong_FromLong((long) st.f_namemax)); 9327 | #endif "./Modules/posixmodule.c", line 9328.64: 1506-280 (S) Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed . 9328 | PyStructSequence_SET_ITEM(v, 10, PyLong_FromUnsignedLong(st.f_fsid)); 9328 + (((PyTupleObject *)(v))->ob_item[10] = PyLong_FromUnsignedLong(st.f_fsid)); 9329 | if (PyErr_Occurred()) { 9330 | Py_DECREF(v); 9330 + do { PyObject *_py_decref_tmp = (PyObject *)(v); if ( --(_py_decref_tmp)->ob_refcnt != 0) ; else ( (*(((PyObject*)(_py_d ecref_tmp))->ob_type)->tp_dealloc)((PyObject *)(_py_decref_tmp))); } while (0); ---------- title: AIX (xlc_r) compile error with Modules/posixmodule.c: Explicit dimension specification or initializer required -> AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:37:15 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 20 Dec 2017 19:37:15 +0000 Subject: [issue32387] Disallow untagged C extension import on major platforms In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za> Message-ID: <1513798635.44.0.213398074469.issue32387@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Also, even if they are common, it seems reasonable that pip could be trained to rename untagged binaries on install after doing something to determine if they should be compatible with >=3.7 or not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:38:03 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 20 Dec 2017 19:38:03 +0000 Subject: [issue32387] Disallow untagged C extension import on major platforms In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za> Message-ID: <1513798683.87.0.213398074469.issue32387@psf.upfronthosting.co.za> Antoine Pitrou added the comment: cc'ing people for the pip/PyPI aspects of this. ---------- nosy: +Marcus.Smith, dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:39:10 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 19:39:10 +0000 Subject: [issue31059] asyncio.StreamReader.read hangs if n<0 In-Reply-To: <1501179219.52.0.217830379676.issue31059@psf.upfronthosting.co.za> Message-ID: <1513798750.18.0.213398074469.issue31059@psf.upfronthosting.co.za> Andrew Svetlov added the comment: `.read(-1)` reads up to end of stream (closing the underlying socket by peer). If other side doesn't close connection after sending data -- read(-1) hangs, but it is not asyncio bug. ---------- nosy: +asvetlov resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:49:51 2017 From: report at bugs.python.org (Michael Felt) Date: Wed, 20 Dec 2017 19:49:51 +0000 Subject: [issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed In-Reply-To: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za> Message-ID: <1513799391.36.0.213398074469.issue32390@psf.upfronthosting.co.za> Michael Felt added the comment: FYI: from /usr/include/types.h /* typedef for the File System Identifier (fsid). This must correspond * to the "struct fsid" structure in _ALL_SOURCE below. */ typedef struct fsid_t { #ifdef __64BIT_KERNEL unsigned long val[2]; #else /* __64BIT_KERNEL */ #ifdef _ALL_SOURCE unsigned int val[2]; #else /* _ALL_SOURCE */ unsigned int __val[2]; #endif /* _ALL_SOURCE */ #endif /* __64BIT_KERNEL */ } fsid_t; And, currently I am building in 32-bit mode, with a 64BIT kernel (AIX 6.1) - so I expect it to be 2 unsigned_longs. However, I am not smart enough to find a solution: I tried: PyStructSequence_SET_ITEM(v, 10, PyLong_FromUnsignedLong((unsigned long) st.f_fsid)); and PyStructSequence_SET_ITEM(v, 10, PyLong_FromUnsignedLong((unsigned long *) st.f_fsid)); Both return: "./Modules/posixmodule.c", line 9328.80: 1506-117 (S) Operand must be a scalar type. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:55:10 2017 From: report at bugs.python.org (Srinivas Reddy T) Date: Wed, 20 Dec 2017 19:55:10 +0000 Subject: [issue32321] functools.reduce has a redundant guard or needs a pure Python fallback In-Reply-To: <1513257994.59.0.213398074469.issue32321@psf.upfronthosting.co.za> Message-ID: <1513799710.32.0.213398074469.issue32321@psf.upfronthosting.co.za> Change by Srinivas Reddy T : ---------- keywords: +patch pull_requests: +4841 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 14:57:22 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Wed, 20 Dec 2017 19:57:22 +0000 Subject: [issue30492] 'make clinic' does not work for out of tree builds / clinic.py is not in the devguide In-Reply-To: <1495909690.05.0.0866994683674.issue30492@psf.upfronthosting.co.za> Message-ID: <1513799842.32.0.213398074469.issue30492@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Thanks for fixing this. I always do my builds in subfolders as well. It is handy to have multiple builds (debug, opt, profiled) that all use a single source tree. I don't like to hijack this issue but could we get some of the build bots to do their builds in a subfolder? I don't know who would be able to make that change. It would be good to smoke out these kinds of problems early. Otherwise wierdo's like gps and I don't notice them until later. If we don't keep this working, we should just rip the ability to do builds outside of the source tree out of the Makefile. There is no point to maintaining the extra complication if it doesn't actually work. With git shallow clones, I could live with that. However, it seems a shame to lose it when it basically currently works fine. ---------- nosy: +nascheme _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:00:01 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 20:00:01 +0000 Subject: [issue30539] Make Proactor public in asyncio.ProactorEventLoop In-Reply-To: <1496325546.51.0.723953827271.issue30539@psf.upfronthosting.co.za> Message-ID: <1513800001.23.0.213398074469.issue30539@psf.upfronthosting.co.za> Andrew Svetlov added the comment: asyncio doesn't expose `loop.selector` and `loop.proactor` -- it is deliberate choice. What proactor methods are needed to serial support? Maybe we can incorporate them into event loop itself -- as we did for `loop.sock_*`? ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:02:43 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 20:02:43 +0000 Subject: [issue29922] error message when __aexit__ is not async In-Reply-To: <1490635462.94.0.877144122619.issue29922@psf.upfronthosting.co.za> Message-ID: <1513800163.27.0.213398074469.issue29922@psf.upfronthosting.co.za> Andrew Svetlov added the comment: It's Interpreter Core problem, not specific to asyncio bug. ---------- components: +Interpreter Core -asyncio nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:04:21 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 Dec 2017 20:04:21 +0000 Subject: [issue30539] Make Proactor public in asyncio.ProactorEventLoop In-Reply-To: <1496325546.51.0.723953827271.issue30539@psf.upfronthosting.co.za> Message-ID: <1513800261.42.0.213398074469.issue30539@psf.upfronthosting.co.za> Yury Selivanov added the comment: Big -1 from me. If proactor is public, alternative event loop implementations like uvloop will have to implement its full API, which actually puts restrictions on us refactoring asyncio itself. If there's some missing functionality we should think about adding new specific APIs for it, and not exposing internals. I'm closing this issue, but please feel free to open a new one requesting to implement whatever pyserial-asyncio implements in asyncio itself. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:05:25 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 Dec 2017 20:05:25 +0000 Subject: [issue29922] error message when __aexit__ is not async In-Reply-To: <1490635462.94.0.877144122619.issue29922@psf.upfronthosting.co.za> Message-ID: <1513800325.46.0.213398074469.issue29922@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- versions: +Python 3.8 -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:05:52 2017 From: report at bugs.python.org (Zachary Ware) Date: Wed, 20 Dec 2017 20:05:52 +0000 Subject: [issue30492] 'make clinic' does not work for out of tree builds / clinic.py is not in the devguide In-Reply-To: <1495909690.05.0.0866994683674.issue30492@psf.upfronthosting.co.za> Message-ID: <1513800352.59.0.213398074469.issue30492@psf.upfronthosting.co.za> Zachary Ware added the comment: > I don't like to hijack this issue but could we get some of the build bots to do their builds in a subfolder? The buildmaster config is at https://github.com/python/buildmaster-config, feel free to submit a pull request that sets the ware-gentoo bot building out-of-tree. Victor or I can merge and deploy, but I don't have the bandwidth to make the change myself currently. ---------- nosy: +vstinner, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:07:05 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 20:07:05 +0000 Subject: [issue20493] select module: loop if the timeout is too large (OverflowError "timeout is too large") In-Reply-To: <1391387871.01.0.754074352669.issue20493@psf.upfronthosting.co.za> Message-ID: <1513800425.74.0.213398074469.issue20493@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Documentation for asyncio specifies a cap for timeout to one day. Closing the issue. ---------- nosy: +asvetlov resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:12:51 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 20:12:51 +0000 Subject: [issue29517] "Can't pickle local object" when uses functools.partial with method and args... In-Reply-To: <1486676485.08.0.362566272702.issue29517@psf.upfronthosting.co.za> Message-ID: <1513800771.53.0.213398074469.issue29517@psf.upfronthosting.co.za> Andrew Svetlov added the comment: asyncio objects are not pickable and shouldn't be -- they are ephemeral. Like pickling open socket object doesn't make sense -- there is no possibility to restore connection to peer on unpickling. Not sure if we can do anything here. I suggest closing the issue. ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:14:36 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 Dec 2017 20:14:36 +0000 Subject: [issue29517] "Can't pickle local object" when uses functools.partial with method and args... In-Reply-To: <1486676485.08.0.362566272702.issue29517@psf.upfronthosting.co.za> Message-ID: <1513800876.73.0.213398074469.issue29517@psf.upfronthosting.co.za> Yury Selivanov added the comment: Closing this one. Quoting my other comment from this issue: > Well, I don't think we can do something about it. Just re-pack your arguments from WeakSet to a regular set. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:17:04 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 20:17:04 +0000 Subject: [issue29689] Asyncio-namespace helpers for async_generators In-Reply-To: <1488394375.71.0.89348090398.issue29689@psf.upfronthosting.co.za> Message-ID: <1513801024.75.0.213398074469.issue29689@psf.upfronthosting.co.za> Andrew Svetlov added the comment: asyncio is a library for asynchronous network communications and related stuff. Converting async iterator into a list is out of scope of the library. If you want incorporate aitertools into Python stdlib -- please create a separate issue (but better discuss it in python-ideas mailing list first). ---------- nosy: +asvetlov resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:29:27 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 20:29:27 +0000 Subject: [issue29558] Provide run_until_complete inside loop In-Reply-To: <1487092620.31.0.174365857148.issue29558@psf.upfronthosting.co.za> Message-ID: <1513801767.58.0.213398074469.issue29558@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Awaiting a future from blocking code which in turn is executed from async code is very dangerous idea -- it will block other async code execution. The feature will be never implemented as well as nested loops, sorry. Closing. ---------- nosy: +asvetlov resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:31:42 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 20:31:42 +0000 Subject: [issue28942] await expressions in f-strings In-Reply-To: <1481541122.12.0.429355486169.issue28942@psf.upfronthosting.co.za> Message-ID: <1513801902.3.0.213398074469.issue28942@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Yury, ping. ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:31:53 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 20:31:53 +0000 Subject: [issue28942] await expressions in f-strings In-Reply-To: <1481541122.12.0.429355486169.issue28942@psf.upfronthosting.co.za> Message-ID: <1513801913.36.0.213398074469.issue28942@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:34:07 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 Dec 2017 20:34:07 +0000 Subject: [issue28942] await expressions in f-strings In-Reply-To: <1481541122.12.0.429355486169.issue28942@psf.upfronthosting.co.za> Message-ID: <1513802047.62.0.213398074469.issue28942@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks, I'll take a look. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:36:49 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 20:36:49 +0000 Subject: [issue30014] Speedup DefaultSelectors.modify() by 2x In-Reply-To: <1491561607.45.0.330964035773.issue30014@psf.upfronthosting.co.za> Message-ID: <1513802209.98.0.213398074469.issue30014@psf.upfronthosting.co.za> Andrew Svetlov added the comment: PR was merged 6 months ago, closing the issue. ---------- nosy: +asvetlov resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:38:50 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 20:38:50 +0000 Subject: [issue29344] sock_recv not detected a coroutine In-Reply-To: <1485094185.41.0.725056014669.issue29344@psf.upfronthosting.co.za> Message-ID: <1513802330.42.0.213398074469.issue29344@psf.upfronthosting.co.za> Andrew Svetlov added the comment: sock_recv was converted into genuine coroutine in Python 3.7 Closing the issue. ---------- nosy: +asvetlov resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:40:10 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 20:40:10 +0000 Subject: [issue28697] asyncio.Lock, Condition, Semaphore docs don't mention `async with` syntax In-Reply-To: <1479225811.34.0.0222578393475.issue28697@psf.upfronthosting.co.za> Message-ID: <1513802409.99.0.213398074469.issue28697@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Fixed by recent docs update for Python 3.7 ---------- nosy: +asvetlov resolution: -> fixed stage: -> resolved status: open -> closed versions: -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:40:16 2017 From: report at bugs.python.org (Srinivas Reddy T) Date: Wed, 20 Dec 2017 20:40:16 +0000 Subject: [issue15852] typos in curses argument error messages In-Reply-To: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za> Message-ID: <1513802416.55.0.213398074469.issue15852@psf.upfronthosting.co.za> Change by Srinivas Reddy T : ---------- pull_requests: +4843 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:47:11 2017 From: report at bugs.python.org (Oleh Prypin) Date: Wed, 20 Dec 2017 20:47:11 +0000 Subject: [issue32392] subprocess.run documentation does not have **kwargs Message-ID: <1513802831.78.0.213398074469.issue32392@psf.upfronthosting.co.za> New submission from Oleh Prypin : I was just looking at documentation of https://docs.python.org/3.6/library/subprocess.html#subprocess.run and thought that it doesn't support passing `env` because the list of supported keyword arguments is exhaustive (no **kwargs). But it does support passing **kwargs to Popen, so that should be specified in the docs. ---------- assignee: docs at python components: Documentation messages: 308810 nosy: docs at python, oprypin priority: normal severity: normal status: open title: subprocess.run documentation does not have **kwargs versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:50:35 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 20:50:35 +0000 Subject: [issue29243] --enable-optimizations makes common build commands always need to compile from scratch In-Reply-To: <1484151314.82.0.308427338149.issue29243@psf.upfronthosting.co.za> Message-ID: <1513803035.34.0.213398074469.issue29243@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Is the issue done? Can it be closed? ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:51:31 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 20:51:31 +0000 Subject: [issue29889] test_asyncio fails always In-Reply-To: <1490304644.24.0.581268594683.issue29889@psf.upfronthosting.co.za> Message-ID: <1513803091.35.0.213398074469.issue29889@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Confirm: no problems on master (Ubuntu 17.10). Closing the issue. ---------- nosy: +asvetlov resolution: -> works for me stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:57:20 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 20:57:20 +0000 Subject: [issue25749] asyncio.Server class documented but not exported In-Reply-To: <1448652516.67.0.0555030356133.issue25749@psf.upfronthosting.co.za> Message-ID: <1513803440.01.0.213398074469.issue25749@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- assignee: -> asvetlov nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 15:57:36 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 20:57:36 +0000 Subject: [issue25749] asyncio.Server class documented but not exported In-Reply-To: <1448652516.67.0.0555030356133.issue25749@psf.upfronthosting.co.za> Message-ID: <1513803456.34.0.213398074469.issue25749@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- versions: +Python 3.7 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:01:36 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 21:01:36 +0000 Subject: [issue26188] Provide more helpful error message when `await` is called inside non-`async` method In-Reply-To: <1453601163.58.0.356009781594.issue26188@psf.upfronthosting.co.za> Message-ID: <1513803696.78.0.213398074469.issue26188@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Nothing to do. Python parser always report with such text on syntax error, there is nothing special for async/await ---------- nosy: +asvetlov resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:05:28 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 21:05:28 +0000 Subject: [issue27665] Make create_server able to listen on several ports In-Reply-To: <1470091847.64.0.679712938011.issue27665@psf.upfronthosting.co.za> Message-ID: <1513803928.54.0.213398074469.issue27665@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Let's don't -- all combinations of hosts, ports, sock objects makes a mess already. I suggest not complicate already complex signature and just close the issue as "won't fix". Multiple server objects never was a problem. ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:06:23 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 21:06:23 +0000 Subject: [issue27746] ResourceWarnings in test_asyncio In-Reply-To: <1471004022.68.0.202760199133.issue27746@psf.upfronthosting.co.za> Message-ID: <1513803983.85.0.213398074469.issue27746@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Fixed in master already. ---------- nosy: +asvetlov resolution: -> out of date stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:09:08 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 21:09:08 +0000 Subject: [issue25675] doc for BaseEventLoop.run_in_executor() says its a coroutine, but it is not In-Reply-To: <1447970161.65.0.436017258107.issue25675@psf.upfronthosting.co.za> Message-ID: <1513804148.4.0.213398074469.issue25675@psf.upfronthosting.co.za> Andrew Svetlov added the comment: It was always awaitable object, in Python 3.7 the method was converted into genuine coroutine. ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:09:25 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 21:09:25 +0000 Subject: [issue25675] doc for BaseEventLoop.run_in_executor() says its a coroutine, but it is not In-Reply-To: <1447970161.65.0.436017258107.issue25675@psf.upfronthosting.co.za> Message-ID: <1513804165.71.0.213398074469.issue25675@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:11:18 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 21:11:18 +0000 Subject: [issue24539] StreamReaderProtocol.eof_received() should return True to keep the transport open In-Reply-To: <1435668886.87.0.254771488213.issue24539@psf.upfronthosting.co.za> Message-ID: <1513804278.24.0.213398074469.issue24539@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Done two years ago. ---------- nosy: +asvetlov resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:11:54 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 21:11:54 +0000 Subject: [issue25074] Bind logger and waninigs modules for asyncio __del__ methods In-Reply-To: <1441998965.13.0.504603864253.issue25074@psf.upfronthosting.co.za> Message-ID: <1513804314.6.0.213398074469.issue25074@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- resolution: -> wont fix stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:15:08 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 20 Dec 2017 21:15:08 +0000 Subject: [issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed In-Reply-To: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za> Message-ID: <1513804508.55.0.213398074469.issue32390@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The PPC64 AIX 3.x Python buildbot (http://buildbot.python.org/all/#/builders/10) has been failing upon this same error for over a month. Can you please try with: PyStructSequence_SET_ITEM(v, 10, PyLong_FromUnsignedLong(st.f_fsid.val[0])); Or if statvfs.f_fsid is a pointer to fsid_t, try this instead: PyStructSequence_SET_ITEM(v, 10, PyLong_FromUnsignedLong(st.f_fsid->val[0])); ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:15:10 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 21:15:10 +0000 Subject: [issue26133] asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za> Message-ID: <1513804510.56.0.213398074469.issue26133@psf.upfronthosting.co.za> Andrew Svetlov added the comment: `remove_signal_handler()` should do nothing if `sys.is_finalizing()` is true. ---------- assignee: -> asvetlov nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:18:01 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 20 Dec 2017 21:18:01 +0000 Subject: [issue24795] Make event loops with statement context managers In-Reply-To: <1438778311.28.0.548352526709.issue24795@psf.upfronthosting.co.za> Message-ID: <1513804681.09.0.213398074469.issue24795@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Superseded by `asyncio.run()` function. P.S. Context manager is not a solution because `loop.shutdown_asyncgens()` should be called before `loop.close()` and the method is a coroutine. ---------- nosy: +asvetlov resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:20:48 2017 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Wed, 20 Dec 2017 21:20:48 +0000 Subject: [issue32221] Converting ipv6 address to string representation using getnameinfo() is wrong. In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za> Message-ID: <1513804848.18.0.213398074469.issue32221@psf.upfronthosting.co.za> ???? ????????? added the comment: After my patch: $ python3.7 -m timeit --setup 'import socket; s = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM); s.bind(("ff02::1de:c0db", 1234, 0, 2))' 's.getsockname()' 500000 loops, best of 5: 613 nsec per loop $ python3.7 -m timeit --setup 'import socket; s = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM); s.bind(("::", 1235, 0, 0))' 's.getsockname()' 500000 loops, best of 5: 420 nsec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:21:32 2017 From: report at bugs.python.org (Decorater) Date: Wed, 20 Dec 2017 21:21:32 +0000 Subject: [issue32387] Disallow untagged C extension import on major platforms In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za> Message-ID: <1513804892.16.0.213398074469.issue32387@psf.upfronthosting.co.za> Decorater added the comment: If needed I could help upload the updated project files here for this issue. ---------- nosy: +Decorater _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:26:36 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 20 Dec 2017 21:26:36 +0000 Subject: [issue32392] subprocess.run documentation does not have **kwargs In-Reply-To: <1513802831.78.0.213398074469.issue32392@psf.upfronthosting.co.za> Message-ID: <1513805196.04.0.213398074469.issue32392@psf.upfronthosting.co.za> Xavier de Gaye added the comment: But the documentation does say "The arguments shown above are merely the most common ones...The full function signature is largely the same as that of the Popen constructor...", no ? ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:28:14 2017 From: report at bugs.python.org (Oleh Prypin) Date: Wed, 20 Dec 2017 21:28:14 +0000 Subject: [issue32392] subprocess.run documentation does not have **kwargs In-Reply-To: <1513802831.78.0.213398074469.issue32392@psf.upfronthosting.co.za> Message-ID: <1513805294.47.0.213398074469.issue32392@psf.upfronthosting.co.za> Oleh Prypin added the comment: Yes, but the most prominent thing to indicate that is **kwargs in the actual function signature. And, as far as I'm concerned, lack of **kwargs means the function signature is exhaustive and there's no point in looking for fine print somewhere in the middle of the textual description. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:32:07 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 Dec 2017 21:32:07 +0000 Subject: [issue32221] Converting ipv6 address to string representation using getnameinfo() is wrong. In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za> Message-ID: <1513805527.17.0.213398074469.issue32221@psf.upfronthosting.co.za> Yury Selivanov added the comment: I thought the improvements were way bigger than 200nsec, no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:34:17 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 Dec 2017 21:34:17 +0000 Subject: [issue27665] Make create_server able to listen on several ports In-Reply-To: <1470091847.64.0.679712938011.issue27665@psf.upfronthosting.co.za> Message-ID: <1513805657.21.0.213398074469.issue27665@psf.upfronthosting.co.za> Yury Selivanov added the comment: Agree. It's also challenging to design the API that binds to multiple hosts *and* ports -- a crossproduct of some sorts. > Multiple server objects never was a problem. Right. Let's close this. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:37:43 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 Dec 2017 21:37:43 +0000 Subject: [issue25749] asyncio.Server class documented but not exported In-Reply-To: <1448652516.67.0.0555030356133.issue25749@psf.upfronthosting.co.za> Message-ID: <1513805863.95.0.213398074469.issue25749@psf.upfronthosting.co.za> Yury Selivanov added the comment: There's no point in exporting the Server class as "asyncio.Server". It'd created and managed by the event loop, and there's no point to instantiate it in user code. We can add an abstract base class AbstractServer though, similar to AbstractFuture and AbstractTask proposed in https://bugs.python.org/issue32364. This is a low priority feature and can probably wait till 3.8 though. ---------- versions: +Python 3.8 -Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:38:56 2017 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 20 Dec 2017 21:38:56 +0000 Subject: [issue26133] asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za> Message-ID: <1513805936.86.0.213398074469.issue26133@psf.upfronthosting.co.za> Yury Selivanov added the comment: > `remove_signal_handler()` should do nothing if `sys.is_finalizing()` is true. Probably a good idea. See also https://github.com/python/asyncio/pull/456. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:43:25 2017 From: report at bugs.python.org (Decorater) Date: Wed, 20 Dec 2017 21:43:25 +0000 Subject: [issue32387] Disallow untagged C extension import on major platforms In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za> Message-ID: <1513806205.3.0.213398074469.issue32387@psf.upfronthosting.co.za> Decorater added the comment: Attached is my changes to the vcxproj files based on an field already in python.props. ---------- Added file: https://bugs.python.org/file47342/changes.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 16:52:40 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 21:52:40 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513806760.39.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4844 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 17:15:34 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 22:15:34 +0000 Subject: [issue26133] asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za> Message-ID: <1513808134.71.0.213398074469.issue26133@psf.upfronthosting.co.za> STINNER Victor added the comment: > `remove_signal_handler()` should do nothing if `sys.is_finalizing()` is true. I dislike this option. If you want to use sys.is_finalizing(), I would prefer to modify _UnixSelectorEventLoop.close() to not try to remove signal handler if close() has been called too late during Python finalization. But I also expect a warning in this case, not hide bugs silently. If you reach this case, close() has probably been called by BaseEventLoop.__del__(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 17:35:02 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 22:35:02 +0000 Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za> Message-ID: <1513809302.29.0.213398074469.issue32381@psf.upfronthosting.co.za> STINNER Victor added the comment: run_file() gets a wchar_t* string which comes from wmain() argv. run_file() encodes the wchar_t* using PyUnicode_EncodeFSDefault(). Later, PyRun_SimpleFileExFlags() calls indirectly fopen() with the encoded filename. > This could be addressed in _Py_fopen by decoding the path and calling _wfopen instead of fopen. I agree that it's the correct fix. I would make _Py_fopen() more compatible with the PEP 529. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 17:35:31 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 22:35:31 +0000 Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za> Message-ID: <1513809331.66.0.213398074469.issue32381@psf.upfronthosting.co.za> STINNER Victor added the comment: > I would make _Py_fopen() more compatible with the PEP 529. Typo: It* would ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 17:41:41 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 22:41:41 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513809701.13.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 31e99080f6f8cf7faaba9fe3a4e0996e49163317 by Victor Stinner in branch 'master': bpo-32030: Fix usage of memory allocators (#4953) https://github.com/python/cpython/commit/31e99080f6f8cf7faaba9fe3a4e0996e49163317 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 18:00:52 2017 From: report at bugs.python.org (Joseph Hendrey) Date: Wed, 20 Dec 2017 23:00:52 +0000 Subject: [issue32393] nav menu jitter in old documentation Message-ID: <1513810852.69.0.213398074469.issue32393@psf.upfronthosting.co.za> New submission from Joseph Hendrey : The sidebar navigation menu jitters when scrolling on the 2.7 documentation pages (at least in Chrome). A seemingly unrelated issue is that the collapse symbol '<<' is a fixed distance from the top of the page rather than staying in the centre (height-wise) of the screen (it should always be visible). It seems it has been fixed for newer documentation, but since the fix is so simple it would be nice to fix it for the old documentation too. Setting the position property of the span element seems to fix both issues for me (see attached screenshot) ---------- assignee: docs at python components: Documentation files: screenshot.JPG messages: 308834 nosy: Joseph Hendrey, docs at python priority: normal severity: normal status: open title: nav menu jitter in old documentation type: behavior versions: Python 2.7 Added file: https://bugs.python.org/file47343/screenshot.JPG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 18:27:16 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 20 Dec 2017 23:27:16 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513812436.24.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: Summary of the visible changes: * sys.argv is now set earlier, before "import site" * The implementation of the PEP 538 now respects -E and -I options. * _PyCoreConfig now allows to modify a lot of configuration options which wasn't possible to configure previously. (_PyMainInterpreterConfig allows to configure options using Python types.) It should be very useful for embedded Python, once the API will be public. Summary of the most important changes: * On Unix, char **argv of main() is now decoded again and the configuration (cmdline, env vars, etc.) is read again if the C locale is coerced (PEP 538) or if the UTF-8 Mode is enabled (PEP 540). * The "path configuration" (sys.path, sys.prefix, sys.exec_prefix, etc.) is now computed before _Py_InitializeMainInterpreter(), by _PyMainInterpreterConfig_Read() * Warning options are now computed in a list from -W options and PYTHONWARNINGS env var, before setting sys.warnoptions. Similar change has been done for sys._xoptions: xoptions are first stored in a wchar_t** list. * A new _PyInitError structure has been introduced to be able to report failures instead of calling Py_FatalError(). Most of the Python initializatioin code has been modified to use it. * Py_Main() now only uses regular C functions (using wchar_t* type for example) before _Py_InitializeCore(), the Python C API is now only used after _Py_InitializeCore(). * A new _PyCoreConfig_Read() has been added to read most configuration options using C types. _PyMainInterpreterConfig_Read() is now mostly responsible to convert C types to Python types. * It becomes simpler to decide the priority between env vars, -X options, command line options, Py_xxx global variables, etc. The code to read these options and to code to "merge" these options is now decoupled. * Each interpreter now has its copy of the "core_config" (_PyCoreConfig) and the main "config" (_PyMainInterpreterConfig). When using multiple interpreters, it is important to get Python objects created with the right interpreter for the main config. The ownership of these configurations becomes more obvious. * Many global buffers with a fixed size like "static wchar_t progpath[MAXPATHLEN+1];" in Modules/getpath.c have been replaced with memory allocated on the heap with functions to release memory. * Python/pathconfig.c (360 lines) has been added. More code is shared between Windows and Unix to compute the module search path (sys.path). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 19:06:00 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 Dec 2017 00:06:00 +0000 Subject: [issue28942] await expressions in f-strings In-Reply-To: <1481541122.12.0.429355486169.issue28942@psf.upfronthosting.co.za> Message-ID: <1513814760.6.0.213398074469.issue28942@psf.upfronthosting.co.za> Yury Selivanov added the comment: Looks like it's working now: import asyncio async def foo(): return 32 async def bar(): print(f'{await foo()}') asyncio.run(bar()) Prints: 32 ---------- resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 19:12:44 2017 From: report at bugs.python.org (Kamil) Date: Thu, 21 Dec 2017 00:12:44 +0000 Subject: [issue32394] socket lib beahavior change in 3.6.4 Message-ID: <1513815164.25.0.213398074469.issue32394@psf.upfronthosting.co.za> New submission from Kamil : On Windows, python 3.6.3 code "hasattr(socket, 'TCP_KEEPCNT')" gives False, python 3.6.4 gives True. This behavior breaks many libraries that i use. ---------- components: Library (Lib) messages: 308837 nosy: skn78 priority: normal severity: normal status: open title: socket lib beahavior change in 3.6.4 type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 19:50:00 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 00:50:00 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513817400.32.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4845 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 19:59:55 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 21 Dec 2017 00:59:55 +0000 Subject: [issue15216] Add encoding & errors parameters to TextIOWrapper.reconfigure() In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1513817995.48.0.213398074469.issue15216@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset 507434fd504f3ebc1da72aa77544edc0d73f136e by INADA Naoki in branch 'master': bpo-15216: io: TextIOWrapper.reconfigure() accepts encoding, errors and newline (GH-2343) https://github.com/python/cpython/commit/507434fd504f3ebc1da72aa77544edc0d73f136e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 21:53:17 2017 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 21 Dec 2017 02:53:17 +0000 Subject: [issue32221] Converting ipv6 address to string representation using getnameinfo() is wrong. In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za> Message-ID: <1513824797.35.0.213398074469.issue32221@psf.upfronthosting.co.za> ???? ????????? added the comment: No, Improvement for typical case (not scoped IPv6 addresses) was not the target, but fortunatelly it also sped up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 21:54:20 2017 From: report at bugs.python.org (Ron Frederick) Date: Thu, 21 Dec 2017 02:54:20 +0000 Subject: [issue25749] asyncio.Server class documented but not exported In-Reply-To: <1448652516.67.0.0555030356133.issue25749@psf.upfronthosting.co.za> Message-ID: <1513824860.7.0.213398074469.issue25749@psf.upfronthosting.co.za> Ron Frederick added the comment: In my original report, I suggested _either_ exporting asyncio.Server since that's what was documented elsewhere _OR_ adding AbstractServer to the documentation and changing existing references to asyncio.Server to point at asyncio.AbstractServer instead, as that symbol is already exported but is not currently documented. There appear to be good reasons for hiding the implementation details of Server, and I'm good with that. I just think the docs and the exports need to agree on one or the other. I originally had references to AbstractServer in my project docs, but changed them to Server after seeing that only Server was currently in the public Python documentation. As for references to the "sockets" member of Server, I'm not currently relying on that in my code. I have code that can handle getaddrinfo() returning more than one address to listen on, but I create separate Server instances for each individual address right now, as this gives me better control when a caller asks to listen on a dynamic port on multiple interfaces at once. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 22:08:13 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 Dec 2017 03:08:13 +0000 Subject: [issue25749] asyncio.Server class documented but not exported In-Reply-To: <1448652516.67.0.0555030356133.issue25749@psf.upfronthosting.co.za> Message-ID: <1513825693.02.0.213398074469.issue25749@psf.upfronthosting.co.za> Yury Selivanov added the comment: Server.sockets property will be a public API and defined in the AbstractServer, so you can start using them. Just don't try to call socket.send() or socket.accept() as that will break things. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 22:12:36 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 Dec 2017 03:12:36 +0000 Subject: [issue32221] Converting ipv6 address to string representation using getnameinfo() is wrong. In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za> Message-ID: <1513825956.62.0.213398074469.issue32221@psf.upfronthosting.co.za> Yury Selivanov added the comment: The PR looks good, but I don't have the capacity right now to merge it. Ill need some time for research to double check if it's ok to drop scope id. Will try to find it in the next few days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 22:32:58 2017 From: report at bugs.python.org (Ron Frederick) Date: Thu, 21 Dec 2017 03:32:58 +0000 Subject: [issue25749] asyncio.Server class documented but not exported In-Reply-To: <1448652516.67.0.0555030356133.issue25749@psf.upfronthosting.co.za> Message-ID: <1513827178.44.0.213398074469.issue25749@psf.upfronthosting.co.za> Ron Frederick added the comment: Thanks. Unfortunately, in the case of the way SSH listeners with dynamic ports, the protocol only allows a single port number to be returned. So, when binding on multiple interfaces there's a requirement that the SAME port be chosen for all of the socket bindings, which can't easily be done today with a single asyncio.Server object. That's a bit off-topic for this issue, though. Regarding exposing the sockets, it would never really make sense to directly call send() on a listening socket, and I can see why it also wouldn't make sense to allow calling accept(). I'm really not sure there's ANY call other than getsockaddr() that really makes sense here, though, so perhaps it would be better to evolve the API in AbstractServer into returning a list of sockaddr tuples rather than sockets. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 22:39:29 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 03:39:29 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513827569.12.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, the following command does crash: PYTHONMALLOC=pymalloc ./Programs/_testembed forced_io_encoding ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 22:45:43 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 Dec 2017 03:45:43 +0000 Subject: [issue25749] asyncio.Server class documented but not exported In-Reply-To: <1448652516.67.0.0555030356133.issue25749@psf.upfronthosting.co.za> Message-ID: <1513827943.91.0.213398074469.issue25749@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I'm really not sure there's ANY call other than getsockaddr() that really makes sense here, though, so perhaps it would be better to evolve the API in AbstractServer into returning a list of sockaddr tuples rather than sockets. Right, that's why uvloop exposes only SocketLike objects, that have getsockaddr() and getsockopt(), but raise when sock.send() is called. Maybe we'll do the same thing in asyncio. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 22:49:30 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 21 Dec 2017 03:49:30 +0000 Subject: [issue31584] Documentation Language mixed up In-Reply-To: <1506402847.94.0.987670636111.issue31584@psf.upfronthosting.co.za> Message-ID: <1513828170.79.0.213398074469.issue31584@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Seems like this is happening again. English docs are showing Japanese content. https://github.com/python/pythondotorg/issues/1207 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 22:51:02 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 21 Dec 2017 03:51:02 +0000 Subject: [issue31584] Documentation Language mixed up In-Reply-To: <1506402847.94.0.987670636111.issue31584@psf.upfronthosting.co.za> Message-ID: <1513828262.17.0.213398074469.issue31584@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Hmm only for that one page it seems? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 22:54:34 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 Dec 2017 03:54:34 +0000 Subject: [issue25749] asyncio.Server class documented but not exported In-Reply-To: <1448652516.67.0.0555030356133.issue25749@psf.upfronthosting.co.za> Message-ID: <1513828474.76.0.213398074469.issue25749@psf.upfronthosting.co.za> Yury Selivanov added the comment: > _OR_ adding AbstractServer to the documentation and changing existing references to asyncio.Server to point at asyncio.AbstractServer instead, as that symbol is already exported but is not currently documented. I completely missed the fact that we already export AbstractServer and that the documentation doesn't actually refer to it, and that it has less APIs than Server. Thanks for reminding me of that, Ron. I'll try to address the docs part before 3.7 comes out. > So, when binding on multiple interfaces there's a requirement that the SAME port be chosen for all of the socket bindings, which can't easily be done today with a single asyncio.Server object. That's a bit off-topic for this issue, though. And why do you need a single Server object? ---------- versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 23:09:50 2017 From: report at bugs.python.org (Ron Frederick) Date: Thu, 21 Dec 2017 04:09:50 +0000 Subject: [issue25749] asyncio.Server class documented but not exported In-Reply-To: <1448652516.67.0.0555030356133.issue25749@psf.upfronthosting.co.za> Message-ID: <1513829390.85.0.213398074469.issue25749@psf.upfronthosting.co.za> Ron Frederick added the comment: That'd be great if you could add AbstractServer to the 3.7 docs - thanks! Regarding the other issue, I'm already set up to use multiple asyncio.Server objects to deal with the shared port issue and it's working fine. It did mean duplicating a handful of lines of code from asyncio to iterate over the getaddrinfo() results (creating one asyncio.Server per sockaddr instead of letting asyncio create a single asyncio.Server with multiple listening sockets) and there are some other minor details like cleaning up if the kernel-selected dynamic port chosen for the first interface is not actually free on all other interfaces, but I'm not actually looking for any changes in how that's working right now. Here's the code I'm referring to if you're curious: https://github.com/ronf/asyncssh/blob/master/asyncssh/listener.py#L192 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 20 23:19:02 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 Dec 2017 04:19:02 +0000 Subject: [issue25749] asyncio.Server class documented but not exported In-Reply-To: <1448652516.67.0.0555030356133.issue25749@psf.upfronthosting.co.za> Message-ID: <1513829942.95.0.213398074469.issue25749@psf.upfronthosting.co.za> Yury Selivanov added the comment: > It did mean duplicating a handful of lines of code from asyncio to iterate over the getaddrinfo() results (creating one asyncio.Server per sockaddr instead of letting asyncio create a single asyncio.Server with multiple listening sockets) and there are some other minor details like cleaning up if the kernel-selected dynamic port chosen for the first interface is not actually free on all other interfaces, but I'm not actually looking for any changes in how that's working right now. I think you're doing it the right way. It's a rather niche requirement, so I don't think we should make create_server to somehow support this use case. asyncssh looks absolutely amazing, btw. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 00:33:56 2017 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 21 Dec 2017 05:33:56 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1513834436.75.0.213398074469.issue15873@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: New changeset 09dc2f508c8513e0466a759cc27a09108c1e55c2 by Alexander Belopolsky (Paul Ganssle) in branch 'master': bpo-15873: Implement [date][time].fromisoformat (#4699) https://github.com/python/cpython/commit/09dc2f508c8513e0466a759cc27a09108c1e55c2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 00:42:35 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 Dec 2017 05:42:35 +0000 Subject: [issue15852] typos in curses argument error messages In-Reply-To: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za> Message-ID: <1513834955.89.0.213398074469.issue15852@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4846 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 00:43:06 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 Dec 2017 05:43:06 +0000 Subject: [issue15852] typos in curses argument error messages In-Reply-To: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za> Message-ID: <1513834986.11.0.213398074469.issue15852@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4847 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 00:44:03 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 21 Dec 2017 05:44:03 +0000 Subject: [issue15852] typos in curses argument error messages In-Reply-To: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za> Message-ID: <1513835043.92.0.213398074469.issue15852@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 00:52:54 2017 From: report at bugs.python.org (Bruce Merry) Date: Thu, 21 Dec 2017 05:52:54 +0000 Subject: [issue32395] asyncio.StreamReader.readuntil is not general enough Message-ID: <1513835574.11.0.213398074469.issue32395@psf.upfronthosting.co.za> New submission from Bruce Merry : I'd proposed one specific solution in Issue 32052 which asvetlov didn't like, so as requested I'm filing a bug about the problem rather than the solution. The specific case I have is reading a protocol in which either \r or \n can be used to terminate lines. With StreamReader.readuntil, it's only possible to specify one separator, so it can't easily be used (*). Some nice-to-have features, from specific to general: 1. Specify multiple alternate separators. 2. Specify a regex for a separator. 3. Specify a regex for the line. 4. Specify a callback that takes a string and returns the position of the end of the line, if any. Of course, some of these risk quadratic-time behaviour if they have to check the whole buffer every time the buffer is extended, so that would need to be considered in the design. In the last case, the callback could take care of it itself by maintaining internal state. (*) I actually have a solution for this case (https://github.com/ska-sa/aiokatcp/blob/bd8263cefe213003a218fac0dd8c5207cc76aeef/aiokatcp/connection.py#L44-L52), but it only works because \r and \n are semantically equivalent in the particular protocol I'm parsing. ---------- components: asyncio messages: 308852 nosy: Bruce Merry, yselivanov priority: normal severity: normal status: open title: asyncio.StreamReader.readuntil is not general enough type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 01:00:11 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 21 Dec 2017 06:00:11 +0000 Subject: [issue32395] asyncio.StreamReader.readuntil is not general enough In-Reply-To: <1513835574.11.0.213398074469.issue32395@psf.upfronthosting.co.za> Message-ID: <1513836011.38.0.213398074469.issue32395@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 01:06:37 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 21 Dec 2017 06:06:37 +0000 Subject: [issue32395] asyncio.StreamReader.readuntil is not general enough In-Reply-To: <1513835574.11.0.213398074469.issue32395@psf.upfronthosting.co.za> Message-ID: <1513836397.07.0.213398074469.issue32395@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Support multiple separators looks easy, I don't expect any performance impact. Like we already have it for strings: s.startswith(('\n', '\r')) Regexps are more expensive thing, callbacks are kind of evil. Let's add a patch for multiple separators first, maybe it covers 99.9% use cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 01:09:24 2017 From: report at bugs.python.org (Julien Palard) Date: Thu, 21 Dec 2017 06:09:24 +0000 Subject: [issue31584] Documentation Language mixed up In-Reply-To: <1506402847.94.0.987670636111.issue31584@psf.upfronthosting.co.za> Message-ID: <1513836564.84.0.213398074469.issue31584@psf.upfronthosting.co.za> Julien Palard added the comment: Sadly I can't see it, it may have already been fixed by the cron task (I'm 3 hours late). I grepped on the server to check if there's another page: no one found. I'll try to fix it by the proposed simple idea that make sense of using different directories for the different builds, will track this in: https://github.com/python/docsbuild-scripts/issues/35 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 01:21:17 2017 From: report at bugs.python.org (Ilya Kulakov) Date: Thu, 21 Dec 2017 06:21:17 +0000 Subject: [issue29890] Constructor of ipaddress.IPv*Interface does not follow documentation In-Reply-To: <1490306388.92.0.69250411121.issue29890@psf.upfronthosting.co.za> Message-ID: <1513837277.41.0.213398074469.issue29890@psf.upfronthosting.co.za> Ilya Kulakov added the comment: Do you need any help with the change? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 01:22:33 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 21 Dec 2017 06:22:33 +0000 Subject: [issue32321] functools.reduce has a redundant guard or needs a pure Python fallback In-Reply-To: <1513257994.59.0.213398074469.issue32321@psf.upfronthosting.co.za> Message-ID: <1513837353.4.0.213398074469.issue32321@psf.upfronthosting.co.za> Andrew Svetlov added the comment: See discussion in https://bugs.python.org/issue12428 (especially the last message) ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 01:37:36 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 21 Dec 2017 06:37:36 +0000 Subject: [issue15216] Add encoding & errors parameters to TextIOWrapper.reconfigure() In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1513838256.58.0.213398074469.issue15216@psf.upfronthosting.co.za> Change by INADA Naoki : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 01:38:15 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 21 Dec 2017 06:38:15 +0000 Subject: [issue26133] asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za> Message-ID: <1513838295.57.0.213398074469.issue26133@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- keywords: +patch pull_requests: +4848 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 01:44:26 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 21 Dec 2017 06:44:26 +0000 Subject: [issue32386] dynload_next.c is obsolete In-Reply-To: <1513784673.38.0.213398074469.issue32386@psf.upfronthosting.co.za> Message-ID: <1513838666.0.0.213398074469.issue32386@psf.upfronthosting.co.za> Change by Benjamin Peterson : ---------- keywords: +patch pull_requests: +4849 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 02:29:59 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 21 Dec 2017 07:29:59 +0000 Subject: [issue15852] typos in curses argument error messages In-Reply-To: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za> Message-ID: <1513841399.77.0.213398074469.issue15852@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It was worth to honor Chris as the author of the patch in the commit message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 03:44:55 2017 From: report at bugs.python.org (=?utf-8?q?David_Luke=C5=A1?=) Date: Thu, 21 Dec 2017 08:44:55 +0000 Subject: [issue32306] Clarify map API in concurrent.futures In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za> Message-ID: <1513845895.47.0.213398074469.issue32306@psf.upfronthosting.co.za> David Luke? added the comment: Perfect, thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 04:15:26 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 21 Dec 2017 09:15:26 +0000 Subject: [issue26133] asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za> Message-ID: <1513847726.43.0.213398074469.issue26133@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Implemented PR 4956 following Victor's suggestion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 04:22:34 2017 From: report at bugs.python.org (Michael Haubenwallner) Date: Thu, 21 Dec 2017 09:22:34 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1513848154.12.0.213398074469.issue26439@psf.upfronthosting.co.za> Michael Haubenwallner added the comment: Within this context, the "svr4" label originates in the "-bsvr4" AIX linker flag, and actually is another (yet fully documented by the ld(1) man page) method for creating shared libraries on AIX to support filename based shared library versioning, which is known as the DT_SONAME tag with the ELF binary format. For details please refer to the GCC install doc: https://gcc.gnu.org/install/configure.html#WithAixSoname ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 04:24:04 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 21 Dec 2017 09:24:04 +0000 Subject: [issue26357] asyncio.wait loses coroutine return value In-Reply-To: <1455398273.27.0.148553648829.issue26357@psf.upfronthosting.co.za> Message-ID: <1513848244.68.0.213398074469.issue26357@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Let's close as "wont fix". If user need an identity for awaited coroutine -- he/she should return it as part of coroutine result. ---------- nosy: +asvetlov resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 04:28:56 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 21 Dec 2017 09:28:56 +0000 Subject: [issue28212] Closing server in asyncio is not efficient In-Reply-To: <1474362608.68.0.912694843367.issue28212@psf.upfronthosting.co.za> Message-ID: <1513848536.49.0.213398074469.issue28212@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Superseded by https://bugs.python.org/issue32391 ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Add StreamWriter.wait_closed() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 04:37:37 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 21 Dec 2017 09:37:37 +0000 Subject: [issue30996] add coroutine AbstractEventLoop.sock_close In-Reply-To: <1500802208.0.0.551974338989.issue30996@psf.upfronthosting.co.za> Message-ID: <1513849057.26.0.213398074469.issue30996@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Well, removing the reader on future cancellation makes sense. Can be done by add_done_callback(). Yury, what do you think? ---------- nosy: +asvetlov versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 04:56:14 2017 From: report at bugs.python.org (Srinivas Reddy T) Date: Thu, 21 Dec 2017 09:56:14 +0000 Subject: [issue32394] socket lib beahavior change in 3.6.4 In-Reply-To: <1513815164.25.0.213398074469.issue32394@psf.upfronthosting.co.za> Message-ID: <1513850174.37.0.213398074469.issue32394@psf.upfronthosting.co.za> Srinivas Reddy T added the comment: dtdev at dtdev-centos $ python3 Python 3.6.3 (default, Oct 11 2017, 18:17:01) [GCC 4.4.7 20120313 (Red Hat 4.4.7-18)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> hasattr(socket, 'TCP_KEEPCNT') True >>> I have linux system. Above is the output i got. ---------- nosy: +thatiparthy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 06:02:32 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 21 Dec 2017 11:02:32 +0000 Subject: [issue32394] socket lib beahavior change in 3.6.4 In-Reply-To: <1513815164.25.0.213398074469.issue32394@psf.upfronthosting.co.za> Message-ID: <1513854152.31.0.213398074469.issue32394@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 06:13:22 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 11:13:22 +0000 Subject: [issue31851] test_subprocess hangs randomly on Windows with Python 3.x In-Reply-To: <1508781289.15.0.213398074469.issue31851@psf.upfronthosting.co.za> Message-ID: <1513854802.08.0.213398074469.issue31851@psf.upfronthosting.co.za> STINNER Victor added the comment: The bug still occurs randomly: http://buildbot.python.org/all/#/builders/38/builds/122 1:34:03 [404/406] test_typing passed -- running: test_subprocess (4577 sec) 1:34:22 [405/406] test_winreg passed -- running: test_subprocess (4596 sec) command timed out: 1200 seconds without output running ['Tools\\buildbot\\test.bat', '-x64', '-j2', '--timeout', '900'], attempting to kill program finished with exit code 1 elapsedTime=6864.917000 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 06:23:21 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 21 Dec 2017 11:23:21 +0000 Subject: [issue32346] Speed up slot lookup for class creation In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za> Message-ID: <1513855401.01.0.213398074469.issue32346@psf.upfronthosting.co.za> INADA Naoki added the comment: New slot is really required? My idea is: * Copy slots from MRO * Iterate namespace dict and override slots if dunder is defined Is it impossible or harder than my thought? ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 06:37:33 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 21 Dec 2017 11:37:33 +0000 Subject: [issue32346] Speed up slot lookup for class creation In-Reply-To: <1513426878.39.0.213398074469.issue32346@psf.upfronthosting.co.za> Message-ID: <1513856253.84.0.213398074469.issue32346@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't really understand your proposal, so it's hard to answer :-) Perhaps you can try to implement it so that we can compare? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 07:16:29 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 Dec 2017 12:16:29 +0000 Subject: [issue32323] urllib.parse.urlsplit() must not lowercase() IPv6 scope value In-Reply-To: <1513265439.83.0.213398074469.issue32323@psf.upfronthosting.co.za> Message-ID: <1513858589.16.0.213398074469.issue32323@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4850 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 07:38:39 2017 From: report at bugs.python.org (Ron Frederick) Date: Thu, 21 Dec 2017 12:38:39 +0000 Subject: [issue25749] asyncio.Server class documented but not exported In-Reply-To: <1448652516.67.0.0555030356133.issue25749@psf.upfronthosting.co.za> Message-ID: <1513859919.84.0.213398074469.issue25749@psf.upfronthosting.co.za> Ron Frederick added the comment: > I think you're doing it the right way. It's a rather niche requirement, so I don't think we should make create_server to somehow support this use case. Agreed. > asyncssh looks absolutely amazing, btw. Thanks so much! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 07:42:09 2017 From: report at bugs.python.org (jabdoa) Date: Thu, 21 Dec 2017 12:42:09 +0000 Subject: [issue32396] Implement method to write/read to serials without blocking on windows with asyncio Message-ID: <1513860129.41.0.213398074469.issue32396@psf.upfronthosting.co.za> New submission from jabdoa : This is a follow up to Issue30539. The main issue is that serial ports on windows do not behave like socket on unix. Therefore, pyserial-asyncio cannot use the asyncio socket api. Can we implement serial_recv and serial_send in asyncio? This would help to create a true platform independent implementation. On Linux and Mac serial_send/recv could probably just call to socket_sendall/recv. On Windows this would map to ProactorEventLoop.send/recv. ---------- components: asyncio messages: 308869 nosy: asvetlov, jabdoa, yselivanov priority: normal severity: normal status: open title: Implement method to write/read to serials without blocking on windows with asyncio versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 07:54:47 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 21 Dec 2017 12:54:47 +0000 Subject: [issue32323] urllib.parse.urlsplit() must not lowercase() IPv6 scope value In-Reply-To: <1513265439.83.0.213398074469.issue32323@psf.upfronthosting.co.za> Message-ID: <1513860887.43.0.213398074469.issue32323@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset fdb148f949e3ae66036b75163ff68042d19cf0fc by Andrew Svetlov (Miss Islington (bot)) in branch '3.6': bpo-32323: urllib.parse.urlsplit() must not lowercase() IPv6 scope value (GH-4867) (#4959) https://github.com/python/cpython/commit/fdb148f949e3ae66036b75163ff68042d19cf0fc ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 07:58:46 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 21 Dec 2017 12:58:46 +0000 Subject: [issue32323] urllib.parse.urlsplit() must not lowercase() IPv6 scope value In-Reply-To: <1513265439.83.0.213398074469.issue32323@psf.upfronthosting.co.za> Message-ID: <1513861126.76.0.213398074469.issue32323@psf.upfronthosting.co.za> Andrew Svetlov added the comment: RFC doesn't specify a case for Zone ID, let's keep it untouched (no lowercasing) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 09:10:43 2017 From: report at bugs.python.org (Larry Hastings) Date: Thu, 21 Dec 2017 14:10:43 +0000 Subject: [issue32397] textwrap output may change if you wrap a paragraph twice Message-ID: <1513865443.17.0.213398074469.issue32397@psf.upfronthosting.co.za> New submission from Larry Hastings : If you word-wrap a paragraph twice with textwrap, you may get different results. Specifically, you *will* get different results when: * the original text has a line that is too long by one character, * the last word on the line is the first word in a new sentence, and * there are two spaces after the period. The first textwrap will replace the two spaces after the period with a newline; the second textwrap will replace the newline with a single space. Attached is a test case demonstrating the problem. It's not a big problem, but it did cause an assertion failure in blurb. The workaround was to word-wrap all paragraphs twice, which works but is kind of dumb. ---------- components: Library (Lib) files: textwrap.isnt.stable.py messages: 308872 nosy: larry priority: low severity: normal status: open title: textwrap output may change if you wrap a paragraph twice versions: Python 3.7 Added file: https://bugs.python.org/file47344/textwrap.isnt.stable.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 09:11:26 2017 From: report at bugs.python.org (Larry Hastings) Date: Thu, 21 Dec 2017 14:11:26 +0000 Subject: [issue32397] textwrap output may change if you wrap a paragraph twice In-Reply-To: <1513865443.17.0.213398074469.issue32397@psf.upfronthosting.co.za> Message-ID: <1513865486.35.0.213398074469.issue32397@psf.upfronthosting.co.za> Larry Hastings added the comment: FWIW, the test program produces this output: ------------------------------ original: 'xxxx xxxx xxxx xxxx xxxx. xxxx' wrapped: 'xxxx xxxx xxxx xxxx xxxx.\nxxxx' wrapped twice: 'xxxx xxxx xxxx xxxx xxxx. xxxx' Traceback (most recent call last): File "textwrap.isnt.stable.py", line 24, in assert wrapped == wrapped2 AssertionError ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 09:27:07 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 14:27:07 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513866427.3.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4851 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 09:45:21 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 14:45:21 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513867521.63.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset e47e698da6bd982da277960c14afa9d9939e3155 by Victor Stinner in branch 'master': bpo-32030: Add _Py_EncodeUTF8_surrogateescape() (#4960) https://github.com/python/cpython/commit/e47e698da6bd982da277960c14afa9d9939e3155 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 09:48:48 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 14:48:48 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513867728.38.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4852 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 09:55:31 2017 From: report at bugs.python.org (Anand Reddy Pandikunta) Date: Thu, 21 Dec 2017 14:55:31 +0000 Subject: [issue17972] inspect module docs omits many functions In-Reply-To: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za> Message-ID: <1513868131.69.0.213398074469.issue17972@psf.upfronthosting.co.za> Change by Anand Reddy Pandikunta : ---------- nosy: +chillaranand _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 10:06:48 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 21 Dec 2017 15:06:48 +0000 Subject: [issue26133] asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za> Message-ID: <1513868808.98.0.213398074469.issue26133@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset 4a02543cf97e8cbf9293741379f977b85531e4c2 by Andrew Svetlov in branch 'master': bpo-26133: Dont unsubscribe signals in UNIX even loop on interpreter shutdown (#4956) https://github.com/python/cpython/commit/4a02543cf97e8cbf9293741379f977b85531e4c2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 10:07:38 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 Dec 2017 15:07:38 +0000 Subject: [issue26133] asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za> Message-ID: <1513868858.33.0.213398074469.issue26133@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4853 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 10:20:34 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 15:20:34 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513869634.81.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 9dd762013fd9fcf975ad51700b55d050ca9ed60e by Victor Stinner in branch 'master': bpo-32030: Add _Py_EncodeLocaleRaw() (#4961) https://github.com/python/cpython/commit/9dd762013fd9fcf975ad51700b55d050ca9ed60e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 10:23:29 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 15:23:29 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513869809.12.0.213398074469.issue32030@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4854 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 10:28:39 2017 From: report at bugs.python.org (Julien Palard) Date: Thu, 21 Dec 2017 15:28:39 +0000 Subject: [issue32393] nav menu jitter in old documentation In-Reply-To: <1513810852.69.0.213398074469.issue32393@psf.upfronthosting.co.za> Message-ID: <1513870119.76.0.213398074469.issue32393@psf.upfronthosting.co.za> Change by Julien Palard : ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 10:49:20 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 15:49:20 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513871360.22.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 9bee329130aae5a13050c08dab9d349b76e66835 by Victor Stinner in branch 'master': bpo-32030: Add _Py_FindEnvConfigValue() (#4963) https://github.com/python/cpython/commit/9bee329130aae5a13050c08dab9d349b76e66835 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 11:19:10 2017 From: report at bugs.python.org (Julien Palard) Date: Thu, 21 Dec 2017 16:19:10 +0000 Subject: [issue30607] Extract documentation theme into a separate package In-Reply-To: <1496981279.71.0.300273355047.issue30607@psf.upfronthosting.co.za> Message-ID: <1513873150.57.0.213398074469.issue30607@psf.upfronthosting.co.za> Change by Julien Palard : ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 11:41:00 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 21 Dec 2017 16:41:00 +0000 Subject: [issue32387] Disallow untagged C extension import on major platforms In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za> Message-ID: <1513874460.89.0.213398074469.issue32387@psf.upfronthosting.co.za> Steve Dower added the comment: Please don't rush this in, at least for Windows. I deliberately decided to keep the included pyd files untagged for a reason, and need to recall what that was. (It might be in the issue when we added the tags.) Considering a .pyd file linking against pythonXY.dll is only going to load in the context of that version anyway, this is hardly urgent. There is also no supported tag on Windows for building against the stable ABI, so that would have to be added and enabled in the various build tools. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 11:42:40 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 21 Dec 2017 16:42:40 +0000 Subject: [issue32387] Disallow untagged C extension import on major platforms In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za> Message-ID: <1513874560.52.0.213398074469.issue32387@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the heads-up Steve. > Considering a .pyd file linking against pythonXY.dll is only going to load in the context of that version anyway, this is hardly urgent. I see. That's a good argument for keeping the current extensions list, then. We can narrow the change to POSIX platforms. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 11:48:22 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 21 Dec 2017 16:48:22 +0000 Subject: [issue32326] Update Build projects to version 10.0.16299.0 of the Windows 10 SDK. In-Reply-To: <1513283155.41.0.213398074469.issue32326@psf.upfronthosting.co.za> Message-ID: <1513874902.26.0.213398074469.issue32326@psf.upfronthosting.co.za> Steve Dower added the comment: Apparently Tk has something in its e_capi.c file that does not work with the latest SDK (I guess they're redefining macros). In master, we use prebuilt binaries, which is why this is not a problem. But we'll either need to fix Tk's sources or backport the code that uses the prebuilt binaries (just for Tcl and Tk - the OpenSSL part is not compatible) before we can merge this. I'll try and take a look at it over the next few weeks. An a workaround, you should be able to "SET WindowsSDKVersion=10.0.16299.0" and pass "--no-tkinter" to build.bat to compile without the change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 11:51:10 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 21 Dec 2017 16:51:10 +0000 Subject: [issue32388] Remove cross-version binary compatibility In-Reply-To: <1513790879.02.0.213398074469.issue32388@psf.upfronthosting.co.za> Message-ID: <1513875070.74.0.213398074469.issue32388@psf.upfronthosting.co.za> Steve Dower added the comment: Totally okay with this in theory, but wanted to clarify that the linked PR is really just taking advantage of removing the guarantee? That is, the change isn't necessary to remove the requirement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 11:54:34 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 21 Dec 2017 16:54:34 +0000 Subject: [issue32388] Remove cross-version binary compatibility In-Reply-To: <1513790879.02.0.213398074469.issue32388@psf.upfronthosting.co.za> Message-ID: <1513875274.55.0.213398074469.issue32388@psf.upfronthosting.co.za> Antoine Pitrou added the comment: That's basically exact. Actually, there is no ABI guarantee at all (when not using the stable ABI), just a best effort for advanced users who know what they're doing. Actually, this PR stems from Nathaniel's message here: https://mail.python.org/pipermail/python-dev/2017-December/151345.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 11:59:10 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 21 Dec 2017 16:59:10 +0000 Subject: [issue32394] socket lib beahavior change in 3.6.4 In-Reply-To: <1513815164.25.0.213398074469.issue32394@psf.upfronthosting.co.za> Message-ID: <1513875550.2.0.213398074469.issue32394@psf.upfronthosting.co.za> Steve Dower added the comment: Which libraries break? And which version of Windows are you running on? If TCP_KEEPCNT was only added recently (perhaps in an SDK update) then it may not really be available on all versions. (+Ned for awareness of the regression - not sure we need to respin immediately, but let's figure it out asap) ---------- keywords: +3.6regression nosy: +ned.deily priority: normal -> release blocker stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 12:01:13 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 21 Dec 2017 17:01:13 +0000 Subject: [issue32388] Remove cross-version binary compatibility In-Reply-To: <1513790879.02.0.213398074469.issue32388@psf.upfronthosting.co.za> Message-ID: <1513875673.21.0.213398074469.issue32388@psf.upfronthosting.co.za> Steve Dower added the comment: Good to know. As I said on the other issue, Windows won't load extension modules built for a different version anyway unless they use the stable ABI, so there's no real reason these flags need to be binary compatible between 3.x versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 12:09:10 2017 From: report at bugs.python.org (TJG) Date: Thu, 21 Dec 2017 17:09:10 +0000 Subject: [issue32394] socket lib beahavior change in 3.6.4 In-Reply-To: <1513875550.2.0.213398074469.issue32394@psf.upfronthosting.co.za> Message-ID: TJG added the comment: It's a compile-time option in socketmodule.c. https://github.com/python/cpython/blob/3.6/Modules/socketmodule.c#L7466 The MSDN page suggests that it was added for Win10: https://msdn.microsoft.com/en-us/library/windows/desktop/ms738596(v=vs.85).aspx Is it possible that the build machine has changed its OS/SDK between building 3.6.3 and 3.6.4? ---------- nosy: +tjguk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 12:09:50 2017 From: report at bugs.python.org (Erik Bray) Date: Thu, 21 Dec 2017 17:09:50 +0000 Subject: [issue32243] Tests that set aggressive switch interval hang in Cygwin on a VM In-Reply-To: <1512657533.84.0.213398074469.issue32243@psf.upfronthosting.co.za> Message-ID: <1513876190.74.0.213398074469.issue32243@psf.upfronthosting.co.za> Change by Erik Bray : ---------- keywords: +patch pull_requests: +4855 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 12:09:50 2017 From: report at bugs.python.org (Erik Bray) Date: Thu, 21 Dec 2017 17:09:50 +0000 Subject: [issue23428] Use the monotonic clock for thread conditions on POSIX platforms In-Reply-To: <1423517667.9.0.82075564578.issue23428@psf.upfronthosting.co.za> Message-ID: <1513876190.81.0.00913614298617.issue23428@psf.upfronthosting.co.za> Change by Erik Bray : ---------- pull_requests: +4856 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 12:19:58 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 Dec 2017 17:19:58 +0000 Subject: [issue32323] urllib.parse.urlsplit() must not lowercase() IPv6 scope value In-Reply-To: <1513265439.83.0.213398074469.issue32323@psf.upfronthosting.co.za> Message-ID: <1513876798.23.0.213398074469.issue32323@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think a zone id in that form is actually valid in a URI, but I agree that not messing with whatever is there is probably the best policy as long as we aren't directly supporting whatever *is* valid. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 12:22:59 2017 From: report at bugs.python.org (Eduardo Suarez-Santana) Date: Thu, 21 Dec 2017 17:22:59 +0000 Subject: [issue32398] GDAL compilation error Message-ID: <1513876979.22.0.213398074469.issue32398@psf.upfronthosting.co.za> New submission from Eduardo Suarez-Santana : When compiling GDAL with python support, under certain build chain environment variables, next error may appear when building and linking python extensions (https://www.mail-archive.com/freebsd-ports at freebsd.org/msg41030.html): /bin/sh: -d: invalid option See the Github PR for proposed solution. ---------- components: Distutils messages: 308887 nosy: dstufft, eric.araujo, esuarezsantana priority: normal pull_requests: 4857 severity: normal status: open title: GDAL compilation error type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 12:24:20 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 21 Dec 2017 17:24:20 +0000 Subject: [issue32394] socket lib beahavior change in 3.6.4 In-Reply-To: <1513815164.25.0.213398074469.issue32394@psf.upfronthosting.co.za> Message-ID: <1513877060.03.0.213398074469.issue32394@psf.upfronthosting.co.za> Steve Dower added the comment: Yeah, I updated the build machine before doing 3.6.4rc1 (I never update between rc and final releases). I'm intrigued to see why it breaks libraries though - typically unsupported enum values like this are silently ignored on older Windows versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 12:31:13 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 Dec 2017 17:31:13 +0000 Subject: [issue32398] GDAL compilation error In-Reply-To: <1513876979.22.0.213398074469.issue32398@psf.upfronthosting.co.za> Message-ID: <1513877473.28.0.213398074469.issue32398@psf.upfronthosting.co.za> R. David Murray added the comment: Please describe the problem and your proposed solution in more detail and in terms of CPython, so that it can be discussed by the relevant experts. GDAL is a third party product and only relevant as an example, so it would also be good to come up with a better title for the issues ;) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 12:39:32 2017 From: report at bugs.python.org (Eduardo Suarez-Santana) Date: Thu, 21 Dec 2017 17:39:32 +0000 Subject: [issue32398] OSX C++ linking workaround in distutils breaks other packages In-Reply-To: <1513876979.22.0.213398074469.issue32398@psf.upfronthosting.co.za> Message-ID: <1513877972.91.0.213398074469.issue32398@psf.upfronthosting.co.za> Change by Eduardo Suarez-Santana : ---------- title: GDAL compilation error -> OSX C++ linking workaround in distutils breaks other packages _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 12:42:34 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 21 Dec 2017 17:42:34 +0000 Subject: [issue26133] asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za> Message-ID: <1513878154.31.0.213398074469.issue26133@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset 3bc68cff5b821e83ee5df8b8cd13f4f54151b406 by Andrew Svetlov (Miss Islington (bot)) in branch '3.6': bpo-26133: Dont unsubscribe signals in UNIX even loop on interpreter shutdown (GH-4956) (#4962) https://github.com/python/cpython/commit/3bc68cff5b821e83ee5df8b8cd13f4f54151b406 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 12:45:02 2017 From: report at bugs.python.org (Eduardo Suarez-Santana) Date: Thu, 21 Dec 2017 17:45:02 +0000 Subject: [issue32398] OSX C++ linking workaround in distutils breaks other packages In-Reply-To: <1513876979.22.0.213398074469.issue32398@psf.upfronthosting.co.za> Message-ID: <1513878302.26.0.213398074469.issue32398@psf.upfronthosting.co.za> Eduardo Suarez-Santana added the comment: When compiling GDAL with python support, before Lib/distutils/unixccompiler.py:180, self.compiler_cxx = ['/bin/sh', '/usr/x86_64-pc-linux-gnu/bin/libtool', '--mode=compile', '--tag=CXX', 'x86_64-pc-linux-gnu-c++'] linker = ['x86_64-pc-linux-gnu-cc', '-pthread', '-shared', '-march=native', '-pipe', '-O2', '-Wall', '-Wdeclaration-after-statement', '-Wextra', '-Winit-self', '-Wunused-parameter', '-Wmissing-prototypes', '-Wmissing-declarations', '-Wformat', '-Werror=format-security', '-Wno-format-nonliteral', '-Wlogical-op', '-Wshadow', '-Werror=vla', '-Wdeclaration-after-statement', '-Wnull-dereference', '-Wduplicated-cond', '-DOGR_ENABLED', '-march=native', '-pipe', '-O2', '-I/var/tmp/paludis/build/sci-libs-gdal-2.1.1/work/gdal-2.1.1/port', '-DGDAL_COMPILATION'] and after the workaround code: linker = ['/bin/sh', '-pthread', '-shared', '-march=native', '-pipe', '-O2', '-Wall', '-Wdeclaration-after-statement', '-Wextra', '-Winit-self', '-Wunused-parameter', '-Wmissing-prototypes', '-Wmissing-declarations', '-Wformat', '-Werror=format-security', '-Wno-format-nonliteral', '-Wlogical-op', '-Wshadow', '-Werror=vla', '-Wdeclaration-after-statement', '-Wnull-dereference', '-Wduplicated-cond', '-DOGR_ENABLED', '-march=native', '-pipe', '-O2', '-I/var/tmp/paludis/build/sci-libs-gdal-2.1.1/work/gdal-2.1.1/port', '-DGDAL_COMPILATION'] which leads to next error: /bin/sh: -d: invalid option Some fixes to compilation (https://www.michael-joost.de/gdal_install.html) have been found, but anyway the existing workaround: 1. ...is a hack about OSX but there is no platform checking, 2. ...assumes linker and compiler commands have similar structure and environment settings (no documentation reference found about that), and 3. ...assumes `env`, if used, does not come with any modifier. My proposal is to remove the workaround and delegate right environmental variables to packagers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 12:48:19 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 Dec 2017 17:48:19 +0000 Subject: [issue32398] OSX C++ linking workaround in distutils breaks other packages In-Reply-To: <1513876979.22.0.213398074469.issue32398@psf.upfronthosting.co.za> Message-ID: <1513878499.57.0.213398074469.issue32398@psf.upfronthosting.co.za> R. David Murray added the comment: I doubt we can make the change this way for backward compatibility reasons. That doesn't mean the situation can't be improved, though. ---------- components: +macOS nosy: +ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 13:20:55 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 21 Dec 2017 18:20:55 +0000 Subject: [issue31821] pause_reading() doesn't work from connection_made() In-Reply-To: <1508438943.14.0.213398074469.issue31821@psf.upfronthosting.co.za> Message-ID: <1513880455.28.0.213398074469.issue31821@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 13:29:06 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 21 Dec 2017 18:29:06 +0000 Subject: [issue22908] ZipExtFile in zipfile can be seekable In-Reply-To: <1416496843.38.0.905339069508.issue22908@psf.upfronthosting.co.za> Message-ID: <1513880946.12.0.213398074469.issue22908@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4858 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 13:39:41 2017 From: report at bugs.python.org (Michael Felt) Date: Thu, 21 Dec 2017 18:39:41 +0000 Subject: [issue28009] core logic of uuid.getnode() is broken for AIX - all versions In-Reply-To: <1473290315.48.0.840701308825.issue28009@psf.upfronthosting.co.za> Message-ID: <1513881581.59.0.213398074469.issue28009@psf.upfronthosting.co.za> Michael Felt added the comment: Sure - I'll work on a PR. This will be the easier one. Where I am currently 'lost' is to correct _uuidmodule.c - another thing that has always been broken (new issue, about to open). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 13:49:07 2017 From: report at bugs.python.org (Michael Felt) Date: Thu, 21 Dec 2017 18:49:07 +0000 Subject: [issue32399] _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc.. Message-ID: <1513882147.82.0.213398074469.issue32399@psf.upfronthosting.co.za> New submission from Michael Felt : I was hoping for something simple - as in: +1 #define PY_SSIZE_T_CLEAN +2 +3 #include "Python.h" +4 #ifndef _AIX +5 #include +6 #else +7 #include +8 #endif However, it dies - instantly. 11 | static PyObject * 12 | py_uuid_generate_time_safe(void) 13 | { 14 | #ifdef HAVE_UUID_GENERATE_TIME_SAFE 15 | uuid_t out; 16 | int res; 17 | 18 | res = uuid_generate_time_safe(out); 19 | return Py_BuildValue("y#i", (const char *) out, sizeof(out), res); 20 | #else 21 | uuid_t out; 22 | uuid_generate_time(out); 23 | return Py_BuildValue("y#O", (const char *) out, sizeof(out), Py_None); 23 + return _Py_BuildValue_SizeT("y#O", (const char *) out, sizeof(out), (&_Py_NoneStruct)); "/data/prj/python/git/python3-3.7.0.a3/Modules/_uuidmodule.c", line 23.48: 1506-117 (S) Operand must be a scalar type. 24 | #endif 25 | } 26 | On a linux system I see: typedef unsigned char uuid_t[16]; while on AIX the typedef is: /* * Universal Unique Identifier (UUID) types. */ typedef struct _uuid_t { unsigned32 time_low; unsigned16 time_mid; unsigned16 time_hi_and_version; unsigned8 clock_seq_hi_and_reserved; unsigned8 clock_seq_low; byte node[6]; } uuid_t, *uuid_p_t; So, mentioning this for now - as I do not yet know the module. If someone with intimate knowledge of the current implementation is willing to help me - I'll dabble and learn - and see if we can make it work on AIX as well. p.s. - guessing on the "Extension Modules" label. If not the right choice, please update. ---------- components: Extension Modules messages: 308894 nosy: Michael.Felt priority: normal severity: normal status: open title: _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc.. versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 13:57:05 2017 From: report at bugs.python.org (Lior Cohen) Date: Thu, 21 Dec 2017 18:57:05 +0000 Subject: [issue32400] inspect.isdatadescriptor fasle negative Message-ID: <1513882624.99.0.213398074469.issue32400@psf.upfronthosting.co.za> New submission from Lior Cohen : According to the c code in Include/descrobject.h #define PyDescr_IsData(d) (Py_TYPE(d)->tp_descr_set != NULL) and according to the "data model" chapter, a data descriptor is an object who has __set__ and /or __delete__. the "inspect.isdatadescriptor" checks for existence of __get__ and __set__ which IMHO is wrong. an object with __set__/__delete__ only will return falsely False (should be True). This is related to @Serhiy Storchaka comment in issue 26103 opened by @Aaron Hall. ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 308895 nosy: chnlior, docs at python priority: normal severity: normal status: open title: inspect.isdatadescriptor fasle negative type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 13:57:44 2017 From: report at bugs.python.org (Lior Cohen) Date: Thu, 21 Dec 2017 18:57:44 +0000 Subject: [issue32400] inspect.isdatadescriptor false negative In-Reply-To: <1513882624.99.0.213398074469.issue32400@psf.upfronthosting.co.za> Message-ID: <1513882664.78.0.213398074469.issue32400@psf.upfronthosting.co.za> Change by Lior Cohen : ---------- title: inspect.isdatadescriptor fasle negative -> inspect.isdatadescriptor false negative _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 14:13:40 2017 From: report at bugs.python.org (Michael Felt) Date: Thu, 21 Dec 2017 19:13:40 +0000 Subject: [issue32399] _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc.. In-Reply-To: <1513882147.82.0.213398074469.issue32399@psf.upfronthosting.co.za> Message-ID: <1513883620.07.0.213398074469.issue32399@psf.upfronthosting.co.za> Michael Felt added the comment: So - KISS principle: This diff shows what can compile: diff --git a/Modules/_uuidmodule.c b/Modules/_uuidmodule.c index d4bc3c7..5550705 100644 --- a/Modules/_uuidmodule.c +++ b/Modules/_uuidmodule.c @@ -1,7 +1,11 @@ #define PY_SSIZE_T_CLEAN #include "Python.h" +#ifndef _AIX #include +#else +#include +#endif static PyObject * @@ -16,7 +20,11 @@ py_uuid_generate_time_safe(void) #else uuid_t out; uuid_generate_time(out); +#ifndef _AIX return Py_BuildValue("y#O", (const char *) out, sizeof(out), Py_None); +#else + return Py_BuildValue("y#O", (const char *) &out, sizeof(out), Py_None); +#endif #endif } However, no uuid_generate_time(). So, ends with: ld: 0711-317 ERROR: Undefined symbol: .uuid_generate_time ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 14:19:17 2017 From: report at bugs.python.org (Zachary Ware) Date: Thu, 21 Dec 2017 19:19:17 +0000 Subject: [issue28459] _pyio module broken on Cygwin / setmode not usable In-Reply-To: <1476701892.4.0.598393414511.issue28459@psf.upfronthosting.co.za> Message-ID: <1513883957.65.0.213398074469.issue28459@psf.upfronthosting.co.za> Change by Zachary Ware : ---------- nosy: +zach.ware stage: -> patch review versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 14:25:03 2017 From: report at bugs.python.org (YoSTEALTH) Date: Thu, 21 Dec 2017 19:25:03 +0000 Subject: [issue32401] No module named '_ctypes' Message-ID: <1513884303.03.0.213398074469.issue32401@psf.upfronthosting.co.za> New submission from YoSTEALTH : I tried to install python3.7.0a3 just to test it out and i keep getting error: Traceback (most recent call last): File "/tmp/psi/Python-3.7.0a3/Lib/runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "/tmp/psi/Python-3.7.0a3/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/tmp/psi/Python-3.7.0a3/Lib/ensurepip/__main__.py", line 5, in sys.exit(ensurepip._main()) File "/tmp/psi/Python-3.7.0a3/Lib/ensurepip/__init__.py", line 204, in _main default_pip=args.default_pip, File "/tmp/psi/Python-3.7.0a3/Lib/ensurepip/__init__.py", line 117, in _bootstrap return _run_pip(args + [p[0] for p in _PROJECTS], additional_paths) File "/tmp/psi/Python-3.7.0a3/Lib/ensurepip/__init__.py", line 27, in _run_pip import pip File "/tmp/tmpuwh0fjm1/pip-9.0.1-py2.py3-none-any.whl/pip/__init__.py", line 28, in File "/tmp/tmpuwh0fjm1/pip-9.0.1-py2.py3-none-any.whl/pip/vcs/mercurial.py", line 9, in File "/tmp/tmpuwh0fjm1/pip-9.0.1-py2.py3-none-any.whl/pip/download.py", line 36, in File "/tmp/tmpuwh0fjm1/pip-9.0.1-py2.py3-none-any.whl/pip/utils/glibc.py", line 4, in File "/tmp/psi/Python-3.7.0a3/Lib/ctypes/__init__.py", line 7, in from _ctypes import Union, Structure, Array ModuleNotFoundError: No module named '_ctypes' Makefile:1108: recipe for target 'install' failed make: *** [install] Error 1 System: Linux (4.10.0-42-generic) 64bit I have installed 3.6.0 and 3.6.4 without any problems. ---------- components: Installation messages: 308897 nosy: YoSTEALTH priority: normal severity: normal status: open title: No module named '_ctypes' type: compile error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 14:48:19 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 21 Dec 2017 19:48:19 +0000 Subject: [issue32115] Ignored SIGCHLD causes asyncio.Process.wait to hang forever In-Reply-To: <1511375532.97.0.213398074469.issue32115@psf.upfronthosting.co.za> Message-ID: <1513885699.08.0.213398074469.issue32115@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Thank for bug report. Do you know other widespread tools with this problem? plan9port sounds too esoteric to me. ---------- nosy: +asvetlov versions: +Python 3.6, Python 3.7 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 15:01:36 2017 From: report at bugs.python.org (Ned Deily) Date: Thu, 21 Dec 2017 20:01:36 +0000 Subject: [issue32387] Disallow untagged C extension import on major platforms In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za> Message-ID: <1513886496.53.0.213398074469.issue32387@psf.upfronthosting.co.za> Ned Deily added the comment: With my macOS hat on, I don't see a problem with doing this. C extensions built via Distutils have been version-tagged on macOS since 3.5.0 (for some reason, macOS was skipped when PEP 3149 was originally implemented). With my release manager hat on, it sounds like a good idea. But it could introduce a compatibility problem for anyone who doesn't use Distutils to produce extension modules. So I'd like to see this proposal get a little more visibility, at the minimum, bringing it up on the Distutils SIG mailing list. We should also ensure that the change gets mentioned in the 3.7 What's New document. And somewhere in the docset there should be some documentation for the .so file name requirements. AFAICT, today it's really not mentioned anywhere in the docs other than the reference to PEP 3149 in the 3.2 What's New. Until the packaging documents for extension modules get overhauled perhaps something could be added to the Building chapter of the Extending and Embedding document: https://docs.python.org/3/extending/building.html#building-c-and-c-extensions ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 15:06:42 2017 From: report at bugs.python.org (Kamil) Date: Thu, 21 Dec 2017 20:06:42 +0000 Subject: [issue32394] socket lib beahavior change in 3.6.4 In-Reply-To: <1513815164.25.0.213398074469.issue32394@psf.upfronthosting.co.za> Message-ID: <1513886802.14.0.213398074469.issue32394@psf.upfronthosting.co.za> Kamil added the comment: My OS version is Windows 7 x64. I ran the script on the same computer, but with different versions of the python: import socket import platform print('1) OS Info: ', platform.architecture(), platform.platform()) print('2) Python Info: ', platform.python_build(), platform.python_compiler()) print('3) TCP_KEEPCNT = ', hasattr(socket, 'TCP_KEEPCNT') ) Result for python 3.6.3: 1) OS Info: ('64bit', 'WindowsPE') Windows-7-6.1.7601-SP1 2) Python Info: ('v3.6.3:2c5fed8', 'Oct 3 2017 18:11:49') MSC v.1900 64 bit (AMD64) 3) TCP_KEEPCNT = False Result for python 3.6.4: 1) OS Info: ('64bit', 'WindowsPE') Windows-7-6.1.7601-SP1 2) Python Info: ('v3.6.4:d48eceb', 'Dec 19 2017 06:54:40') MSC v.1900 64 bit (AMD64) 3) TCP_KEEPCNT = True ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 15:14:05 2017 From: report at bugs.python.org (Ned Deily) Date: Thu, 21 Dec 2017 20:14:05 +0000 Subject: [issue32388] Remove cross-version binary compatibility In-Reply-To: <1513790879.02.0.213398074469.issue32388@psf.upfronthosting.co.za> Message-ID: <1513887245.94.0.213398074469.issue32388@psf.upfronthosting.co.za> Change by Ned Deily : ---------- nosy: +ncoghlan, ned.deily -njs, serhiy.storchaka stage: patch review -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 15:14:32 2017 From: report at bugs.python.org (Ned Deily) Date: Thu, 21 Dec 2017 20:14:32 +0000 Subject: [issue32388] Remove cross-version binary compatibility In-Reply-To: <1513790879.02.0.213398074469.issue32388@psf.upfronthosting.co.za> Message-ID: <1513887272.28.0.213398074469.issue32388@psf.upfronthosting.co.za> Change by Ned Deily : ---------- nosy: +njs, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 15:14:49 2017 From: report at bugs.python.org (Ned Deily) Date: Thu, 21 Dec 2017 20:14:49 +0000 Subject: [issue32388] Remove cross-version binary compatibility In-Reply-To: <1513790879.02.0.213398074469.issue32388@psf.upfronthosting.co.za> Message-ID: <1513887289.54.0.213398074469.issue32388@psf.upfronthosting.co.za> Change by Ned Deily : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 15:21:31 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 21 Dec 2017 20:21:31 +0000 Subject: [issue32394] socket lib beahavior change in 3.6.4 In-Reply-To: <1513815164.25.0.213398074469.issue32394@psf.upfronthosting.co.za> Message-ID: <1513887691.75.0.213398074469.issue32394@psf.upfronthosting.co.za> Steve Dower added the comment: Yes, I recognise that the change happened. I don't understand what breaks as a result. You said it breaks "many libraries" - can you name some of them and provide sample code? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 15:44:36 2017 From: report at bugs.python.org (Kamil) Date: Thu, 21 Dec 2017 20:44:36 +0000 Subject: [issue32394] socket lib beahavior change in 3.6.4 In-Reply-To: <1513815164.25.0.213398074469.issue32394@psf.upfronthosting.co.za> Message-ID: <1513889076.61.0.213398074469.issue32394@psf.upfronthosting.co.za> Kamil added the comment: websocket-client 0.44.0 https://pypi.python.org/pypi/websocket-client/0.44.0 My script gives the following Erroe: File "C:\Program Files\Python36\lib\site-packages\websocket\_http.py", line 108, in _open_socket sock.setsockopt(*opts) OSError: [WinError 10042] ??? ?????? getsockopt ??? setsockopt ??? ?????? ???????????, ???????????? ??? ???????????????? ???????? ??? ??????? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 15:50:02 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 20:50:02 +0000 Subject: [issue32402] Coverity: CID 1426868/1426867: Null pointer dereferences in textio.c Message-ID: <1513889402.22.0.213398074469.issue32402@psf.upfronthosting.co.za> New submission from STINNER Victor : The following warning may have been introduced by the commit 507434fd504f3ebc1da72aa77544edc0d73f136e from bpo-15216. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1426868: Null pointer dereferences (NULL_RETURNS) /Modules/_io/textio.c: 1251 in textiowrapper_change_encoding() ________________________________________________________________________________________________________ *** CID 1426868: Null pointer dereferences (NULL_RETURNS) /Modules/_io/textio.c: 1251 in textiowrapper_change_encoding() 1245 encoding = self->encoding; 1246 if (errors == Py_None) { 1247 errors = self->errors; 1248 } 1249 } 1250 else if (errors == Py_None) { >>> CID 1426868: Null pointer dereferences (NULL_RETURNS) >>> Assigning: "errors" = null return value from "_PyUnicode_FromId". 1251 errors = _PyUnicode_FromId(&PyId_strict); 1252 } 1253 1254 const char *c_errors = PyUnicode_AsUTF8(errors); 1255 if (c_errors == NULL) { 1256 return -1; ** CID 1426867: Null pointer dereferences (NULL_RETURNS) /Modules/_io/textio.c: 1153 in _io_TextIOWrapper___init___impl() ________________________________________________________________________________________________________ *** CID 1426867: Null pointer dereferences (NULL_RETURNS) /Modules/_io/textio.c: 1153 in _io_TextIOWrapper___init___impl() 1147 } 1148 1149 /* XXX: Failures beyond this point have the potential to leak elements 1150 * of the partially constructed object (like self->encoding) 1151 */ 1152 >>> CID 1426867: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a null pointer "errors". 1153 Py_INCREF(errors); 1154 self->errors = errors; 1155 self->chunk_size = 8192; 1156 self->line_buffering = line_buffering; 1157 self->write_through = write_through; 1158 if (set_newline(self, newline) < 0) { ---------- components: IO messages: 308903 nosy: inada.naoki, vstinner priority: normal severity: normal status: open title: Coverity: CID 1426868/1426867: Null pointer dereferences in textio.c versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 16:13:20 2017 From: report at bugs.python.org (Steve Dower) Date: Thu, 21 Dec 2017 21:13:20 +0000 Subject: [issue32394] socket lib beahavior change in 3.6.4 In-Reply-To: <1513815164.25.0.213398074469.issue32394@psf.upfronthosting.co.za> Message-ID: <1513890800.9.0.213398074469.issue32394@psf.upfronthosting.co.za> Steve Dower added the comment: Okay, so it looks like we don't have any prior art to conditionally omit constants from _socket based on OS level, and nothing in the setsockopt() doc suggests that it may fail like this. So we either need to explicitly exclude this symbol on Windows (at least until we drop support for pre-Windows 10 versions) or silently ignore setsockopt errors for future good arguments. I'm inclined to do the former - other opinions? ---------- components: +Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 16:28:30 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 21:28:30 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1513891710.62.0.213398074469.issue32030@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, _PyCoreConfig.ignore_environment is redundant with Py_IgnoreEnvironmentFlag. I don't recall why I added it to _PyCoreConfig. Maybe it should be removed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 16:43:55 2017 From: report at bugs.python.org (TJG) Date: Thu, 21 Dec 2017 21:43:55 +0000 Subject: [issue32394] socket lib beahavior change in 3.6.4 In-Reply-To: <1513890800.9.0.213398074469.issue32394@psf.upfronthosting.co.za> Message-ID: <14a90407-da28-cb6c-12e3-dc3940f50927@timgolden.me.uk> TJG added the comment: Excluding for now seems like a simple option. (Basically a reversion to previous behaviour). And allows us easily to include again later easily. Messing with setsockopt seems a little more risky. In short: I'm with you -- exclude for now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 16:51:14 2017 From: report at bugs.python.org (Paul Ganssle) Date: Thu, 21 Dec 2017 21:51:14 +0000 Subject: [issue32403] date, time and datetime alternate constructors should take fast construction path Message-ID: <1513893074.5.0.213398074469.issue32403@psf.upfronthosting.co.za> New submission from Paul Ganssle : In the addition of the `fromisoformat()` alternate constructor (bpo-15873: https://github.com/python/cpython/pull/4699), I noted that I was able to get some significant speedup by special-casing the `datetime` baseclass in the C code so that it bypasses the Python constructor, by replacing code that looks like this: return PyObject_CallFunction(cls, "iii", year, month, day); With code that looks like this: PyObject *result; if ( (PyTypeObject *)cls == & PyDateTime_DateType ) { result = new_date_ex(year, month, day, (PyTypeObject *)cls); } else { result = PyObject_CallFunction(cls, "iii", year, month, day); } return result; (This is for `date`, but the results are even more striking for `datetime`). In my initial proof of concept implementation of a `new_date_subclass_ex` method, I've seen (this is not compiled with optimizations on, mind you) speedups for the other constructors as well: Old constructor: ================ Class: date constructor: 940.5ns date.fromordinal: 1544.8ns date.fromtimestamp: 1941.9ns Class: DateSubclass constructor: 1016.6ns date.fromordinal: 1760.3ns date.fromtimestamp: 2295.3ns With fastpath: ============== Class: date constructor: 964.3ns date.fromordinal: 997.6ns date.fromtimestamp: 1130.2ns Class: DateSubclass constructor: 1086.9ns date.fromordinal: 1818.5ns date.fromtimestamp: 2129.9ns As you can see, this is a fairly significant speedup in the common case with no cost in the unusual case and no change in behavior. I propose that we switch over all the C constructors where it makes sense to do so in date, time and datetime. I'll have a PR forthcoming soon. ---------- messages: 308907 nosy: belopolsky, p-ganssle priority: normal severity: normal status: open title: date, time and datetime alternate constructors should take fast construction path type: enhancement versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 16:54:13 2017 From: report at bugs.python.org (Paul Ganssle) Date: Thu, 21 Dec 2017 21:54:13 +0000 Subject: [issue32404] fromtimestamp does not call __new__ in datetime subclasses Message-ID: <1513893253.21.0.213398074469.issue32404@psf.upfronthosting.co.za> New submission from Paul Ganssle : In writing some tests for the alternate date constructors as part of my PR for issue 32403 (https://bugs.python.org/issue32403), I noticed that for `datetime`, the `fromtimestamp` bypasses the `__new__` call on the subclass: from datetime import datetime args = (2003, 4, 14) ts = 1050292800.0 # Equivalent timestamp d_ord = 731319 # Equivalent ordinal date class DatetimeSubclass(datetime): def __new__(cls, *args, **kwargs): result = datetime.__new__(cls, *args, **kwargs) result.extra = 7 return result base_d = DatetimeSubclass(*args) assert isinstance(base_d, DatetimeSubclass) # Passes assert base_d.extra == 7 # Passes ord_d = DatetimeSubclass.fromordinal(d_ord) assert isinstance(ord_d, DatetimeSubclass) # Passes assert ord_d.extra == 7 # Passes ts_d = DatetimeSubclass.fromtimestamp(ts) assert isinstance(ts_d, DatetimeSubclass) # Passes assert ts_d.extra == 7 # Fails Replacing `datetime` with `date` in the above code we don't get a failure, but with `datetime`, it fails with: AttributeError: 'DatetimeSubclass' object has no attribute 'extra' Regardless of the status of 32403, I think this should be fixed (though I can try to fix them both at the same time). ---------- messages: 308908 nosy: belopolsky, p-ganssle priority: normal severity: normal status: open title: fromtimestamp does not call __new__ in datetime subclasses versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 16:58:48 2017 From: report at bugs.python.org (Ranya) Date: Thu, 21 Dec 2017 21:58:48 +0000 Subject: [issue32405] clr: AttributeError: 'module' object has no attribute 'AddReference' Message-ID: <1513893528.75.0.213398074469.issue32405@psf.upfronthosting.co.za> New submission from Ranya : Am trying to use clr.AddReference and clr.AddReferenceToFile to import an assembly, but python(2.7) keeps making this error: Traceback (most recent call last): File "", line 1, in clr.AddReference("UnityEngine") AttributeError: 'module' object has no attribute 'AddReference' Can anyone tell me how to fix this. ---------- assignee: terry.reedy components: IDLE messages: 308909 nosy: Rany, terry.reedy priority: normal severity: normal status: open title: clr: AttributeError: 'module' object has no attribute 'AddReference' versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 17:22:19 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Thu, 21 Dec 2017 22:22:19 +0000 Subject: [issue28236] In xml.etree.ElementTree Element can be created with empty and None tag In-Reply-To: <1474458735.99.0.896501689259.issue28236@psf.upfronthosting.co.za> Message-ID: <1513894939.92.0.213398074469.issue28236@psf.upfronthosting.co.za> Gordon P. Hemsley added the comment: I decided to take a look at this, since it seems easy... At first glance, this would appear to be a straightforward change--the docs state in multiple places that Element() takes a string as its tag argument. But it turns out that a lot of internal functionality depends on passing in non-strings as the tag value. ---------- nosy: +gphemsley _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 17:41:09 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 21 Dec 2017 22:41:09 +0000 Subject: [issue32399] _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc.. In-Reply-To: <1513882147.82.0.213398074469.issue32399@psf.upfronthosting.co.za> Message-ID: <1513896069.19.0.213398074469.issue32399@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Keep in mind _uuid is an optional C extension that is used to accelerate the uuid module when available. It doesn't bring any additional functionality by itself. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 17:43:08 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 21 Dec 2017 22:43:08 +0000 Subject: [issue32405] clr: AttributeError: 'module' object has no attribute 'AddReference' In-Reply-To: <1513893528.75.0.213398074469.issue32405@psf.upfronthosting.co.za> Message-ID: <1513896188.91.0.213398074469.issue32405@psf.upfronthosting.co.za> R. David Murray added the comment: Whatever clr is, it doesn't look like it is part of the Python standard library. Please contact the clr community for support on this package, or post to the python-list mailing list. ---------- nosy: +r.david.murray resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 17:47:27 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 22:47:27 +0000 Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za> Message-ID: <1513896447.81.0.213398074469.issue20891@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4859 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 17:51:06 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 22:51:06 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1513896666.17.0.213398074469.issue29240@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4860 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 17:55:32 2017 From: report at bugs.python.org (Ranya) Date: Thu, 21 Dec 2017 22:55:32 +0000 Subject: [issue32405] clr: AttributeError: 'module' object has no attribute 'AddReference' In-Reply-To: <1513893528.75.0.213398074469.issue32405@psf.upfronthosting.co.za> Message-ID: <1513896932.48.0.213398074469.issue32405@psf.upfronthosting.co.za> Ranya added the comment: Could you provide me a link to contact the clr community please? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 18:05:07 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 23:05:07 +0000 Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za> Message-ID: <1513897507.04.0.213398074469.issue20891@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 550ee051d605b909dd75ef686d8e1244a0994394 by Victor Stinner in branch 'master': bpo-20891: Skip test_embed.test_bpo20891() (#4967) https://github.com/python/cpython/commit/550ee051d605b909dd75ef686d8e1244a0994394 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 18:07:50 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 23:07:50 +0000 Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za> Message-ID: <1513897670.96.0.213398074469.issue20891@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- pull_requests: +4861 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 18:09:28 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 23:09:28 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1513897768.68.0.213398074469.issue29240@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 424315fa865b43f67e36a40647107379adf031da by Victor Stinner in branch 'master': bpo-29240: Skip test_readline.test_nonascii() (#4968) https://github.com/python/cpython/commit/424315fa865b43f67e36a40647107379adf031da ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 18:11:01 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 23:11:01 +0000 Subject: [issue29240] PEP 540: Add a new UTF-8 mode In-Reply-To: <1484133592.17.0.263024020483.issue29240@psf.upfronthosting.co.za> Message-ID: <1513897861.14.0.213398074469.issue29240@psf.upfronthosting.co.za> STINNER Victor added the comment: IHMO test_readline should be fixed by ignoring the UTF-8 mode in Py_EncodeLocale/Py_DecodeLocale, but only when called from the Python readline module. We need maybe new functions, something like: Py_EncodeCurrentLocale/Py_DecodeCurrentLocale. I will work on a patch when I will be back from holiday. In the meanwhile, I skipped the test to repair FreeBSD 3.x buildbots. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 18:32:29 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 23:32:29 +0000 Subject: [issue20891] PyGILState_Ensure on non-Python thread causes fatal error In-Reply-To: <1394563213.18.0.508100602451.issue20891@psf.upfronthosting.co.za> Message-ID: <1513899149.77.0.213398074469.issue20891@psf.upfronthosting.co.za> STINNER Victor added the comment: New changeset 2e1ef00171179a8b906631b175cde2e68a804522 by Victor Stinner in branch '3.6': bpo-20891: Skip test_embed.test_bpo20891() (#4967) (#4969) https://github.com/python/cpython/commit/2e1ef00171179a8b906631b175cde2e68a804522 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 18:37:58 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 23:37:58 +0000 Subject: [issue32406] Doc: The new dataclasses module is not documented Message-ID: <1513899478.4.0.213398074469.issue32406@psf.upfronthosting.co.za> New submission from STINNER Victor : bpo-32214 "Implement PEP 557: Data Classes" added a new dataclasses module and was closed, but the new module is not documented: https://docs.python.org/dev/library/dataclasses.html And it's also missing from What's New in Python 3.7: https://docs.python.org/dev/whatsnew/3.7.html ---------- assignee: docs at python components: Documentation messages: 308918 nosy: docs at python, eric.smith, vstinner priority: normal severity: normal status: open title: Doc: The new dataclasses module is not documented versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 18:44:19 2017 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 21 Dec 2017 23:44:19 +0000 Subject: [issue32216] Document PEP 557 Data Classes (dataclasses module) In-Reply-To: <1512439511.23.0.213398074469.issue32216@psf.upfronthosting.co.za> Message-ID: <1513899859.13.0.213398074469.issue32216@psf.upfronthosting.co.za> Change by Eric V. Smith : ---------- title: Document PEP 557 Data Classes -> Document PEP 557 Data Classes (dataclasses module) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 18:45:25 2017 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 21 Dec 2017 23:45:25 +0000 Subject: [issue32406] Doc: The new dataclasses module is not documented In-Reply-To: <1513899478.4.0.213398074469.issue32406@psf.upfronthosting.co.za> Message-ID: <1513899925.53.0.213398074469.issue32406@psf.upfronthosting.co.za> Eric V. Smith added the comment: This is a duplicate of #32216, which is no doubt hard to find because the subject doesn't contain "dataclasses". I've fixed that. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 18:48:08 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 21 Dec 2017 23:48:08 +0000 Subject: [issue32216] Document PEP 557 Data Classes (dataclasses module) In-Reply-To: <1512439511.23.0.213398074469.issue32216@psf.upfronthosting.co.za> Message-ID: <1513900088.54.0.213398074469.issue32216@psf.upfronthosting.co.za> STINNER Victor added the comment: My Issue32406 has been marked as a duplicate of this one. Copy of my message: bpo-32214 "Implement PEP 557: Data Classes" added a new dataclasses module and was closed, but the new module is not documented: https://docs.python.org/dev/library/dataclasses.html And it's also missing from What's New in Python 3.7: https://docs.python.org/dev/whatsnew/3.7.html ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 21 23:58:47 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 22 Dec 2017 04:58:47 +0000 Subject: [issue32405] clr: AttributeError: 'module' object has no attribute 'AddReference' In-Reply-To: <1513893528.75.0.213398074469.issue32405@psf.upfronthosting.co.za> Message-ID: <1513918727.19.0.213398074469.issue32405@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am 99.99% sure that this is not an IDLE issue. IDLE submits your code to Python to be exec-ed. The exception comes from Python. You should get the same exception (though with a different fake file name) if you ran the same code directly with Python, without IDLE running. ---------- assignee: terry.reedy -> components: -IDLE _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 00:43:13 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 22 Dec 2017 05:43:13 +0000 Subject: [issue32386] dynload_next.c is obsolete In-Reply-To: <1513784673.38.0.213398074469.issue32386@psf.upfronthosting.co.za> Message-ID: <1513921393.77.0.213398074469.issue32386@psf.upfronthosting.co.za> Benjamin Peterson added the comment: New changeset 62ed6be8da5fd1142f838582ecdb338af539e85b by Benjamin Peterson in branch 'master': remove the dynload_next.c file (closes bpo-32386) (#4957) https://github.com/python/cpython/commit/62ed6be8da5fd1142f838582ecdb338af539e85b ---------- nosy: +benjamin.peterson resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 00:49:46 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 22 Dec 2017 05:49:46 +0000 Subject: [issue32407] lib2to3 doesn't work when zipped Message-ID: <1513921786.02.0.213398074469.issue32407@psf.upfronthosting.co.za> New submission from Benjamin Peterson : 2to3 pokes around on the file system to find the grammar files it needs in source or pickled form. This makes it not work if lib2to3 is running from a zip file. lib2to3 should use pkgutil.get_data() instead to load grammar files. ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 308923 nosy: benjamin.peterson priority: normal severity: normal status: open title: lib2to3 doesn't work when zipped type: behavior versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 01:14:05 2017 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 22 Dec 2017 06:14:05 +0000 Subject: [issue32408] Performance regression in urllib.proxy_bypass_environment Message-ID: <1513923244.99.0.213398074469.issue32408@psf.upfronthosting.co.za> New submission from Xiang Zhang : Recently we update our environment from Python2.7.5 to Python2.7.13. Then one process's CPU usage grow from 15% to 70%. The cause is urllib.proxy_bypass_environment, the commit I wrote in #26864. Our environments get a no_proxy environment variable which contains 4000+ items. See the performance difference: cascading-controller:~ # time python2 -c 'import urllib; urllib.proxy_bypass_environment("1.1.1.1")' real 0m1.134s user 0m1.126s sys 0m0.007s cascading-controller:~ # time python2 -c 'import urllib; urllib.proxy_bypass_environment("1.1.1.1")' real 0m0.037s user 0m0.024s sys 0m0.013s Temporarily I increased regex cache size to 6000 and the CPU usage and time return to a reasonable range. ---------- components: Library (Lib) messages: 308924 nosy: xiang.zhang priority: normal severity: normal status: open title: Performance regression in urllib.proxy_bypass_environment type: performance versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 01:38:30 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 Dec 2017 06:38:30 +0000 Subject: [issue28236] In xml.etree.ElementTree Element can be created with empty and None tag In-Reply-To: <1474458735.99.0.896501689259.issue28236@psf.upfronthosting.co.za> Message-ID: <1513924710.52.0.213398074469.issue28236@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I don't think this is worth fixing. The package is under no obligation to make early type checks for arguments. It is typical in the Python world to let those kinds of input errors surface downstream when they are used. In contrast, C code typically does the checks when the arguments are passed in. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 02:40:06 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Fri, 22 Dec 2017 07:40:06 +0000 Subject: [issue32401] No module named '_ctypes' In-Reply-To: <1513884303.03.0.213398074469.issue32401@psf.upfronthosting.co.za> Message-ID: <1513928406.27.0.213398074469.issue32401@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Most likely the same issue as issue31652. Passing --without-ensurepip to ./configure is a workaround. ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 02:51:51 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 22 Dec 2017 07:51:51 +0000 Subject: [issue32402] Coverity: CID 1426868/1426867: Null pointer dereferences in textio.c In-Reply-To: <1513889402.22.0.213398074469.issue32402@psf.upfronthosting.co.za> Message-ID: <1513929111.0.0.213398074469.issue32402@psf.upfronthosting.co.za> Change by INADA Naoki : ---------- keywords: +patch pull_requests: +4862 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 03:42:06 2017 From: report at bugs.python.org (Dustin Spicuzza) Date: Fri, 22 Dec 2017 08:42:06 +0000 Subject: [issue29877] compileall hangs when accessing urandom even if number of workers is 1 In-Reply-To: <1490162236.47.0.103711647228.issue29877@psf.upfronthosting.co.za> Message-ID: <1513932126.73.0.213398074469.issue29877@psf.upfronthosting.co.za> Dustin Spicuzza added the comment: Finally got around to looking at this. # cat /proc/sys/kernel/random/entropy_avail 183 .. ran python3 -c 'import os; os.getrandom(1, flags=os.GRND_NONBLOCK)' a few times, but didn't run into a hang. Seems like the entropy_avail is staying at about the same level? It's worth noting that I ran into this error with last year's firmware image, and I haven't actually tested this year's firmware image for this particular issue... just that I had it on my TODO list to fix for this year. :) I think it's still a good change to make regardless. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 03:55:32 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 22 Dec 2017 08:55:32 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1513932932.53.0.213398074469.issue17611@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Are one of the variants of this patch ready to apply? I'm hoping that the window for 3.7 isn't missed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 04:00:24 2017 From: report at bugs.python.org (Michael Felt) Date: Fri, 22 Dec 2017 09:00:24 +0000 Subject: [issue32399] _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc.. In-Reply-To: <1513882147.82.0.213398074469.issue32399@psf.upfronthosting.co.za> Message-ID: <1513933224.15.0.213398074469.issue32399@psf.upfronthosting.co.za> Michael Felt added the comment: Understood. What I have learned. Although the types are quite different, they are both 16 bytes. Starting with AIX 6.1, libc includes uuid_create(&uuid, &status) which fills "uuid" with a uuid.uuid1() like result. After calling uuid_to_string( &uuid, &uuid_string, &status); the result: "13d866fa-e6f1-11e7-8017-fad18cf76204" Further reading of the documentation within """ and """ in Lib/uuid.py helps me realize that the AIX approach aligns with the UUID fields description: fields a tuple of the six integer fields of the UUID, which are also available as six individual attributes and two derived attributes: time_low the first 32 bits of the UUID time_mid the next 16 bits of the UUID time_hi_version the next 16 bits of the UUID clock_seq_hi_variant the next 8 bits of the UUID clock_seq_low the next 8 bits of the UUID node the last 48 bits of the UUID So - with this: there is also more than can be done for AIX re: https://bugs.python.org/issue28009 More to come... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 04:00:38 2017 From: report at bugs.python.org (Michael Felt) Date: Fri, 22 Dec 2017 09:00:38 +0000 Subject: [issue32399] _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc.. In-Reply-To: <1513882147.82.0.213398074469.issue32399@psf.upfronthosting.co.za> Message-ID: <1513933238.68.0.213398074469.issue32399@psf.upfronthosting.co.za> Change by Michael Felt : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 04:08:02 2017 From: report at bugs.python.org (Michael Felt) Date: Fri, 22 Dec 2017 09:08:02 +0000 Subject: [issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed In-Reply-To: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za> Message-ID: <1513933682.02.0.213398074469.issue32390@psf.upfronthosting.co.za> Michael Felt added the comment: Well, replied via email response - but it did not show up here. You suggestion worked. I'll start a PR and we can see if your suggestion also works for all the other platforms. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 04:46:42 2017 From: report at bugs.python.org (Michael Felt) Date: Fri, 22 Dec 2017 09:46:42 +0000 Subject: [issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed In-Reply-To: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za> Message-ID: <1513936002.4.0.213398074469.issue32390@psf.upfronthosting.co.za> Change by Michael Felt : ---------- keywords: +patch pull_requests: +4863 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 05:14:56 2017 From: report at bugs.python.org (shangdahao) Date: Fri, 22 Dec 2017 10:14:56 +0000 Subject: [issue32337] Dict order is now guaranteed, so add tests and doc for it Message-ID: <1513937696.32.0.213398074469.issue32337@psf.upfronthosting.co.za> Change by shangdahao : ---------- keywords: +patch pull_requests: +4864 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 05:17:02 2017 From: report at bugs.python.org (Michael Felt) Date: Fri, 22 Dec 2017 10:17:02 +0000 Subject: [issue32399] _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc.. In-Reply-To: <1513882147.82.0.213398074469.issue32399@psf.upfronthosting.co.za> Message-ID: <1513937822.64.0.213398074469.issue32399@psf.upfronthosting.co.za> Change by Michael Felt : ---------- keywords: +patch pull_requests: +4865 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 05:36:15 2017 From: report at bugs.python.org (Jaakko Roponen) Date: Fri, 22 Dec 2017 10:36:15 +0000 Subject: =?utf-8?q?=5Bissue32409=5D_venv_activation_doesn=27t_work=2C_if_project_i?= =?utf-8?q?s_in_a_Windows_folder_that_has_latin-1_supplement_characters_?= =?utf-8?b?KHN1Y2ggYXMgw6Qsw7Ysw6UpIGluIGl0cyBwYXRo?= Message-ID: <1513938975.69.0.213398074469.issue32409@psf.upfronthosting.co.za> New submission from Jaakko Roponen : Let's say I have a folder c:\test-? in Windows Now if I run: py -m venv env and activate: env\scripts\activate and check: where python the result is incorrectly just: C:\Users\Username\AppData\Local\Programs\Python\Python36\python.exe If I run: path the result is: PATH=C:\test-??\env\Scripts;... So clearly the encoding is broken for the folder name. I can fix this by changing activate.bat character encoding to OEM-US and then replacing "test-??" by "test-?". If I now activate and run: where python the result is (as should be): C:\test-?\env\Scripts\python.exe C:\Users\Username\AppData\Local\Programs\Python\Python36\python.exe By running: path I get: PATH=C:\test-?\env\Scripts;... So looks good here as well. I suggest that what ever is creating activate.bat file, is using incorrect character encoding for the creation of the file. If this is somehow platform specific, there could be a guide in the venv documentation about how to fix this. ---------- components: Extension Modules messages: 308931 nosy: Jac0 priority: normal severity: normal status: open title: venv activation doesn't work, if project is in a Windows folder that has latin-1 supplement characters (such as ?,?,?) in its path type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 08:07:13 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 22 Dec 2017 13:07:13 +0000 Subject: [issue32410] Implement loop.sock_sendfile method Message-ID: <1513948033.17.0.213398074469.issue32410@psf.upfronthosting.co.za> New submission from Andrew Svetlov : The method should be low-level coroutine, implemented on loops with native sendfile support only (UnixEventLoop). The signature should be close to socket.sendfile() method Next step is implementing loop.sendfile(transport, ...) with fallback to sending by chunks if sendfile is not supported. ---------- components: Library (Lib), asyncio messages: 308932 nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Implement loop.sock_sendfile method versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 08:08:47 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 22 Dec 2017 13:08:47 +0000 Subject: [issue32410] Implement loop.sock_sendfile method In-Reply-To: <1513948033.17.0.213398074469.issue32410@psf.upfronthosting.co.za> Message-ID: <1513948127.15.0.213398074469.issue32410@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- keywords: +patch pull_requests: +4866 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 08:23:30 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 22 Dec 2017 13:23:30 +0000 Subject: [issue32396] Implement method to write/read to serials without blocking on windows with asyncio In-Reply-To: <1513860129.41.0.213398074469.issue32396@psf.upfronthosting.co.za> Message-ID: <1513949010.45.0.213398074469.issue32396@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Looking on serial port support in twisted (https://github.com/twisted/twisted/blob/trunk/src/twisted/internet/_win32serialport.py) I see that it is implemented by OVERLAPPED structure and ReadFile/WriterFile calls. On other hand loop.sock_send() in ProactorEventLoop uses Proactor.send() (https://github.com/python/cpython/blob/master/Lib/asyncio/windows_events.py#L457). The method calls WriteFile is sock is not socket.socket instance. Did you check if `loop.sock_send()`/`loop.sock_recv()` works for serail port object? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 08:24:49 2017 From: report at bugs.python.org (Eryk Sun) Date: Fri, 22 Dec 2017 13:24:49 +0000 Subject: [issue32409] venv activate.bat is UTF-8 encoded but uses current console codepage In-Reply-To: <1513938975.69.0.213398074469.issue32409@psf.upfronthosting.co.za> Message-ID: <1513949089.95.0.213398074469.issue32409@psf.upfronthosting.co.za> Eryk Sun added the comment: The CMD shell decodes batch scripts using the attached console's output codepage, which defaults to OEM. OTOH, venv writes the replacement values for the template activate.bat as UTF-8 (codepage 65001), which is correct and should not be downgraded to OEM. Instead, the batch script could temporarily switch the console to codepage 65001. Then restore the previous codepage at the end. For example: @echo off for /f "tokens=2 delims=:" %%a in ('"%SystemRoot%\System32\chcp.com"') do ( set "CODEPAGE=%%a" ) "%SystemRoot%\System32\chcp.com" 65001 > nul [rest of script] "%SystemRoot%\System32\chcp.com" %CODEPAGE% > nul set "CODEPAGE=" :END ---------- components: +Library (Lib), Unicode, Windows -Extension Modules nosy: +eryksun, ezio.melotti, paul.moore, steve.dower, tim.golden, vstinner, zach.ware stage: -> needs patch title: venv activation doesn't work, if project is in a Windows folder that has latin-1 supplement characters (such as ?,?,?) in its path -> venv activate.bat is UTF-8 encoded but uses current console codepage versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 08:44:50 2017 From: report at bugs.python.org (John Jolly) Date: Fri, 22 Dec 2017 13:44:50 +0000 Subject: [issue22908] ZipExtFile in zipfile can be seekable In-Reply-To: <1416496843.38.0.905339069508.issue22908@psf.upfronthosting.co.za> Message-ID: <1513950290.08.0.213398074469.issue22908@psf.upfronthosting.co.za> John Jolly added the comment: Please be gentle, this is my first submission to python. The use case for me was a recursive zip-within-a-zip situation. I wanted to allow the creation of a zipfile.ZipFile from an existing zipfile.ZipExtFile, but the lack of seek prevented this. I simply treated forward seeks as a read, and backward seeks as a reset-and-read. The reset was the tricky part as it required restoring several original values such as the remaining compressed length, remaining data length, and the running crc32. I pushed this into the latest upstream branch, but as I am testing this in v3.4 it should be easy to backport if necessary (I suspect not). I based my fix on a little program that I wrote to test the feasibility of this idea. I am attaching that test program here. ---------- nosy: +jjolly Added file: https://bugs.python.org/file47345/ziz.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 08:54:56 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Dec 2017 13:54:56 +0000 Subject: [issue32407] lib2to3 doesn't work when zipped In-Reply-To: <1513921786.02.0.213398074469.issue32407@psf.upfronthosting.co.za> Message-ID: <1513950896.6.0.213398074469.issue32407@psf.upfronthosting.co.za> R. David Murray added the comment: Duplicate of issue 24960. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Can't use lib2to3 with embeddable zip file. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 08:57:48 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 22 Dec 2017 13:57:48 +0000 Subject: [issue32407] lib2to3 doesn't work when zipped In-Reply-To: <1513921786.02.0.213398074469.issue32407@psf.upfronthosting.co.za> Message-ID: <1513951068.82.0.213398074469.issue32407@psf.upfronthosting.co.za> R. David Murray added the comment: Funny, you are already nosy on that issue. Does this one have a different goal, or did you just forget about that one? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 11:33:44 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 22 Dec 2017 16:33:44 +0000 Subject: [issue32407] lib2to3 doesn't work when zipped In-Reply-To: <1513921786.02.0.213398074469.issue32407@psf.upfronthosting.co.za> Message-ID: <1513960424.95.0.213398074469.issue32407@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I tend to get nosied on all 2to3 issues, but I only just started caring about this one. :) Thanks for finding the prior art. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 12:28:47 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 22 Dec 2017 17:28:47 +0000 Subject: [issue24960] Can't use lib2to3 with embeddable zip file. In-Reply-To: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za> Message-ID: <1513963727.25.0.213398074469.issue24960@psf.upfronthosting.co.za> Change by Benjamin Peterson : ---------- keywords: +patch pull_requests: +4867 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 13:24:42 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 22 Dec 2017 18:24:42 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1513967082.55.0.213398074469.issue17611@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Hello Raymond, I don't have anything ready to go. PR 4682 has some major outstanding issues. Specifically, exits from finally bodies did not cleanup the fblock stack correctly. I still think this patch is a good idea and that it can work. My goal is to have something that performs better but, more importantly is more understandable from a code maintenance point of view. I expect it will not be ready for 3.7 however. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 15:18:40 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 22 Dec 2017 20:18:40 +0000 Subject: [issue24960] Can't use lib2to3 with embeddable zip file. In-Reply-To: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za> Message-ID: <1513973920.44.0.213398074469.issue24960@psf.upfronthosting.co.za> Benjamin Peterson added the comment: New changeset 8a5877165e993afb2633cd48da5222326d3f6e0e by Benjamin Peterson in branch 'master': bpo-24960: use pkgutil.get_data in lib2to3 to read pickled grammar files (#4977) https://github.com/python/cpython/commit/8a5877165e993afb2633cd48da5222326d3f6e0e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 15:18:51 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 22 Dec 2017 20:18:51 +0000 Subject: [issue24960] Can't use lib2to3 with embeddable zip file. In-Reply-To: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za> Message-ID: <1513973931.89.0.213398074469.issue24960@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4868 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 15:22:31 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 22 Dec 2017 20:22:31 +0000 Subject: [issue24960] Can't use lib2to3 with embeddable zip file. In-Reply-To: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za> Message-ID: <1513974151.48.0.213398074469.issue24960@psf.upfronthosting.co.za> Change by Benjamin Peterson : ---------- pull_requests: +4869 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 15:51:48 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 22 Dec 2017 20:51:48 +0000 Subject: [issue24960] Can't use lib2to3 with embeddable zip file. In-Reply-To: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za> Message-ID: <1513975908.14.0.213398074469.issue24960@psf.upfronthosting.co.za> Benjamin Peterson added the comment: New changeset c1b8eb8006ed79bbf91dc7d89918f39cc10b4fe6 by Benjamin Peterson (Miss Islington (bot)) in branch '3.6': bpo-24960: use pkgutil.get_data in lib2to3 to read pickled grammar files (GH-4977) (#4979) https://github.com/python/cpython/commit/c1b8eb8006ed79bbf91dc7d89918f39cc10b4fe6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 15:52:12 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 22 Dec 2017 20:52:12 +0000 Subject: [issue24960] Can't use lib2to3 with embeddable zip file. In-Reply-To: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za> Message-ID: <1513975932.7.0.213398074469.issue24960@psf.upfronthosting.co.za> Benjamin Peterson added the comment: New changeset 770a802df7057bcf0d72bbc01026fac8d396e1b3 by Benjamin Peterson in branch '2.7': [2.7] bpo-24960: use pkgutil.get_data in lib2to3 to read pickled grammar files (GH-4977) (#4980) https://github.com/python/cpython/commit/770a802df7057bcf0d72bbc01026fac8d396e1b3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 15:52:37 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 22 Dec 2017 20:52:37 +0000 Subject: [issue24960] Can't use lib2to3 with embeddable zip file. In-Reply-To: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za> Message-ID: <1513975957.03.0.213398074469.issue24960@psf.upfronthosting.co.za> Change by Benjamin Peterson : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 16:06:09 2017 From: report at bugs.python.org (Nitish) Date: Fri, 22 Dec 2017 21:06:09 +0000 Subject: [issue32391] Add StreamWriter.wait_closed() In-Reply-To: <1513797145.51.0.213398074469.issue32391@psf.upfronthosting.co.za> Message-ID: <1513976769.84.0.213398074469.issue32391@psf.upfronthosting.co.za> Change by Nitish : ---------- nosy: +nitishch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 16:43:07 2017 From: report at bugs.python.org (Dmitry Kazakov) Date: Fri, 22 Dec 2017 21:43:07 +0000 Subject: [issue27639] UserList.__getitem__ doesn't account for slices In-Reply-To: <1469686507.89.0.362648270021.issue27639@psf.upfronthosting.co.za> Message-ID: <1513978987.38.0.213398074469.issue27639@psf.upfronthosting.co.za> Change by Dmitry Kazakov : ---------- pull_requests: +4870 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 16:59:13 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 22 Dec 2017 21:59:13 +0000 Subject: [issue32261] Online doc does not include inspect.classify_class_attrs In-Reply-To: <1512846881.17.0.213398074469.issue32261@psf.upfronthosting.co.za> Message-ID: <1513979953.44.0.213398074469.issue32261@psf.upfronthosting.co.za> Change by Cheryl Sabella : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> inspect module docs omits many functions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 16:59:56 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Fri, 22 Dec 2017 21:59:56 +0000 Subject: [issue17972] inspect module docs omits many functions In-Reply-To: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za> Message-ID: <1513979996.87.0.213398074469.issue17972@psf.upfronthosting.co.za> Change by Cheryl Sabella : ---------- dependencies: -Online doc does not include inspect.classify_class_attrs keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 17:02:46 2017 From: report at bugs.python.org (Dmitry Kazakov) Date: Fri, 22 Dec 2017 22:02:46 +0000 Subject: [issue27639] UserList.__getitem__ doesn't account for slices In-Reply-To: <1469686507.89.0.362648270021.issue27639@psf.upfronthosting.co.za> Message-ID: <1513980166.66.0.213398074469.issue27639@psf.upfronthosting.co.za> Change by Dmitry Kazakov : ---------- nosy: +vaultah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 17:35:46 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 22 Dec 2017 22:35:46 +0000 Subject: [issue32278] Allow dataclasses.make_dataclass() to omit type information In-Reply-To: <1513021651.3.0.213398074469.issue32278@psf.upfronthosting.co.za> Message-ID: <1513982146.0.0.213398074469.issue32278@psf.upfronthosting.co.za> Change by Gregory P. Smith : ---------- keywords: +patch pull_requests: +4871 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 17:38:50 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 22 Dec 2017 22:38:50 +0000 Subject: [issue32278] Allow dataclasses.make_dataclass() to omit type information In-Reply-To: <1513021651.3.0.213398074469.issue32278@psf.upfronthosting.co.za> Message-ID: <1513982330.01.0.213398074469.issue32278@psf.upfronthosting.co.za> Change by Gregory P. Smith : ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 18:20:38 2017 From: report at bugs.python.org (Kamil) Date: Fri, 22 Dec 2017 23:20:38 +0000 Subject: [issue32394] socket lib beahavior change in 3.6.4 In-Reply-To: <1513815164.25.0.213398074469.issue32394@psf.upfronthosting.co.za> Message-ID: <1513984838.58.0.213398074469.issue32394@psf.upfronthosting.co.za> Kamil added the comment: I suggest inserting the following code into socket.py: if hasattr(sys, 'getwindowsversion') and sys.getwindowsversion()[0] < 10: del socket.TCP_KEEPCNT del socket.TCP_FASTOPEN ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 18:53:47 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Fri, 22 Dec 2017 23:53:47 +0000 Subject: [issue32380] functools.singledispatch interacts poorly with methods In-Reply-To: <1513722188.44.0.213398074469.issue32380@psf.upfronthosting.co.za> Message-ID: <1513986827.7.0.213398074469.issue32380@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: I have also noticed this problem and I like the idea. It appeared some time ago on python-ideas, but no one has written a patch. ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 21:41:09 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 23 Dec 2017 02:41:09 +0000 Subject: [issue32411] Idlelib.browser: stop sorting dicts created by pyclbr Message-ID: <1513996869.13.0.213398074469.issue32411@psf.upfronthosting.co.za> New submission from Terry J. Reedy : pyclbr does a linear scan of a file and returns a dict, and Class objects have a dict of children. For objects in the file being scanned, insertion order is the same as line number order. idlelib.browser.transform children filters out objects not in the file, changes the .name of some objects in the file, appends to a list, and sorts by line number. (I should have done the sort in place.) For insertion order dicts, the sort does nothing. In 3.7, insertion order is a language guarantee, not just a (current) CPython implementation detail. The sort does not change the order and is therefore no longer needed. We can reduce return sorted(obs, key=lambda o: o.lineno) to return obs However, I do want to make sure that there is at least one test that will break if there is a bug somewhere. ---------- assignee: terry.reedy components: IDLE messages: 308945 nosy: terry.reedy priority: normal severity: normal stage: test needed status: open title: Idlelib.browser: stop sorting dicts created by pyclbr type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 23:23:15 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Sat, 23 Dec 2017 04:23:15 +0000 Subject: [issue20291] Argument Clinic should understand *args and **kwargs parameters In-Reply-To: <1390010125.91.0.58212727704.issue20291@psf.upfronthosting.co.za> Message-ID: <1514002995.63.0.213398074469.issue20291@psf.upfronthosting.co.za> Change by Gordon P. Hemsley : ---------- nosy: +gphemsley _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 23:35:29 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 23 Dec 2017 04:35:29 +0000 Subject: [issue32412] help() of bitwise operators should mention sets as well Message-ID: <1514003729.76.0.213398074469.issue32412@psf.upfronthosting.co.za> New submission from Steven D'Aprano : If you ask for help on the set operators ^ & and | then help docs only talk about them as bitwise operators. Since sets and frozensets are important, built-in types, the help should mention them as well. ---------- assignee: docs at python components: Documentation messages: 308946 nosy: docs at python, steven.daprano priority: normal severity: normal status: open title: help() of bitwise operators should mention sets as well type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 22 23:53:49 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sat, 23 Dec 2017 04:53:49 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1514004829.43.0.213398074469.issue26439@psf.upfronthosting.co.za> Change by Mariatta Wijaya : ---------- pull_requests: +4872 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 00:52:42 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 23 Dec 2017 05:52:42 +0000 Subject: [issue32413] Document that locals() may return globals() Message-ID: <1514008362.41.0.213398074469.issue32413@psf.upfronthosting.co.za> New submission from Steven D'Aprano : The obvious documentation for locals() fails to mention that when called from the top level of a module (outside of a function or class body) it returns the same dict as globals(). https://docs.python.org/2/library/functions.html#locals ---------- assignee: docs at python components: Documentation messages: 308947 nosy: docs at python, steven.daprano priority: normal severity: normal status: open title: Document that locals() may return globals() type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 02:12:16 2017 From: report at bugs.python.org (Ethan Smith) Date: Sat, 23 Dec 2017 07:12:16 +0000 Subject: [issue32380] functools.singledispatch interacts poorly with methods In-Reply-To: <1513722188.44.0.213398074469.issue32380@psf.upfronthosting.co.za> Message-ID: <1514013136.35.0.213398074469.issue32380@psf.upfronthosting.co.za> Change by Ethan Smith : ---------- keywords: +patch pull_requests: +4873 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 02:39:05 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sat, 23 Dec 2017 07:39:05 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1514014745.91.0.213398074469.issue26439@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset c0919c27c6442aa147ae559a936b1b8deb4ee783 by Mariatta in branch 'master': bpo-26439: Convert %s in Lib/ctypes/_aix.py to f-strings. (GH-4986) https://github.com/python/cpython/commit/c0919c27c6442aa147ae559a936b1b8deb4ee783 ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 03:09:45 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 Dec 2017 08:09:45 +0000 Subject: [issue32413] Document that locals() may return globals() In-Reply-To: <1514008362.41.0.213398074469.issue32413@psf.upfronthosting.co.za> Message-ID: <1514016585.77.0.213398074469.issue32413@psf.upfronthosting.co.za> Change by Raymond Hettinger : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 03:12:02 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 Dec 2017 08:12:02 +0000 Subject: [issue32413] Document that locals() may return globals() In-Reply-To: <1514008362.41.0.213398074469.issue32413@psf.upfronthosting.co.za> Message-ID: <1514016722.23.0.213398074469.issue32413@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, this isn't a quirk of how locals() works. Instead, it reflects the more interesting reality that at the top level, locals and globals *are* the same dictionary. Also, that is not the only occurrence -- if exec() is called with only one dictionary, that dict is used for both locals and globals. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 04:47:09 2017 From: report at bugs.python.org (lekma) Date: Sat, 23 Dec 2017 09:47:09 +0000 Subject: [issue32414] PyCapsule_Import fails when name is in the form 'package.module.capsule' Message-ID: <1514022429.41.0.213398074469.issue32414@psf.upfronthosting.co.za> New submission from lekma : When capsule name is in the form 'package.module.capsule', PyCapsule_Import fails with an AttributeError (module is never an attribute of package). ---------- components: Interpreter Core messages: 308950 nosy: lekma priority: normal severity: normal status: open title: PyCapsule_Import fails when name is in the form 'package.module.capsule' type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 05:15:44 2017 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Dec 2017 10:15:44 +0000 Subject: [issue32414] PyCapsule_Import fails when name is in the form 'package.module.capsule' In-Reply-To: <1514022429.41.0.213398074469.issue32414@psf.upfronthosting.co.za> Message-ID: <1514024144.01.0.213398074469.issue32414@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +4874 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 05:26:22 2017 From: report at bugs.python.org (Michael Felt) Date: Sat, 23 Dec 2017 10:26:22 +0000 Subject: [issue32399] _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc.. In-Reply-To: <1513882147.82.0.213398074469.issue32399@psf.upfronthosting.co.za> Message-ID: <1514024782.52.0.213398074469.issue32399@psf.upfronthosting.co.za> Michael Felt added the comment: As the 'basics' seem to be 'accepted', going to work on the PR so that configure.ac can prepare the right choices, rather than rely on a hard-coded _AIX determined macro. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 06:09:36 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 23 Dec 2017 11:09:36 +0000 Subject: [issue32399] _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc.. In-Reply-To: <1513882147.82.0.213398074469.issue32399@psf.upfronthosting.co.za> Message-ID: <1514027376.95.0.213398074469.issue32399@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Does this approach allow test_uuid to pass for you? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 06:56:43 2017 From: report at bugs.python.org (Michael Felt) Date: Sat, 23 Dec 2017 11:56:43 +0000 Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX) In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za> Message-ID: <1514030203.19.0.213398074469.issue26439@psf.upfronthosting.co.za> Michael Felt added the comment: will open a new PR for ./Doc/library/ctypes.rst ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 09:46:19 2017 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sat, 23 Dec 2017 14:46:19 +0000 Subject: [issue31106] os.posix_fallocate() generate exception with errno 0 In-Reply-To: <1501686186.83.0.555586832167.issue31106@psf.upfronthosting.co.za> Message-ID: <1514040379.36.0.213398074469.issue31106@psf.upfronthosting.co.za> ???? ????????? added the comment: Yes, I can. Should I create new PR ? to which branch ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 11:24:04 2017 From: report at bugs.python.org (R. David Murray) Date: Sat, 23 Dec 2017 16:24:04 +0000 Subject: [issue32412] help() of bitwise operators should mention sets as well In-Reply-To: <1514003729.76.0.213398074469.issue32412@psf.upfronthosting.co.za> Message-ID: <1514046244.76.0.213398074469.issue32412@psf.upfronthosting.co.za> R. David Murray added the comment: Which help are you talking about? The Operator Precedence table that you get if you do, eg: help('&')? I don't think it would be appropriate to mention specialized uses of the operators there, although perhaps we could add a general note about operator overloading in the intro paragraph and use set as the example. Looking at help('BITWISE'), we could add 'when the arguments are numbers' after the precedence table, but since that section is called 'bitwise' I don't think we even want to mention set there. Did you have other sections in mind? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 11:44:11 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 23 Dec 2017 16:44:11 +0000 Subject: [issue32357] Optimize asyncio.iscoroutine() and loop.create_task() for non-native coroutines In-Reply-To: <1513575220.77.0.213398074469.issue32357@psf.upfronthosting.co.za> Message-ID: <1514047451.92.0.213398074469.issue32357@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- pull_requests: +4877 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 11:55:19 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 23 Dec 2017 16:55:19 +0000 Subject: [issue32357] Optimize asyncio.iscoroutine() and loop.create_task() for non-native coroutines In-Reply-To: <1513575220.77.0.213398074469.issue32357@psf.upfronthosting.co.za> Message-ID: <1514048119.56.0.213398074469.issue32357@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- pull_requests: +4878 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 11:59:11 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 23 Dec 2017 16:59:11 +0000 Subject: [issue32415] Add Task.get_loop() and Future.get_loop() Message-ID: <1514048351.13.0.213398074469.issue32415@psf.upfronthosting.co.za> New submission from Yury Selivanov : Currently, asyncio code accesses Future._loop and Task._loop property to validate the event loop and implement functions like "Task.all_tasks()". So the "_loop" is a semi-official public API that other Task & Future implementations must follow in order to be compatible with asyncio code. I propose to add Future.get_loop() and Task.get_loop() methods, and soft-deprecate ._loop property. ---------- assignee: yselivanov components: asyncio messages: 308957 nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Add Task.get_loop() and Future.get_loop() versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 12:00:16 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 23 Dec 2017 17:00:16 +0000 Subject: [issue32415] Add Task.get_loop() and Future.get_loop() In-Reply-To: <1514048351.13.0.213398074469.issue32415@psf.upfronthosting.co.za> Message-ID: <1514048416.65.0.213398074469.issue32415@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Agree ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 12:14:03 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Dec 2017 17:14:03 +0000 Subject: [issue32416] Refactor and add new tests for the f_lineno setter Message-ID: <1514049243.28.0.213398074469.issue32416@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : Proposed PR refactors existing tests for the f_lineno setter and adds few new tests. This will help to avoid regressions in issue17611. I have found that some illegal jumps are not prohibited. They can lead to crashes or weird behavior. For example jumps to or from the bare except block. This will be fixed in a separate issue. ---------- components: Tests messages: 308959 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Refactor and add new tests for the f_lineno setter type: enhancement versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 12:19:14 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Dec 2017 17:19:14 +0000 Subject: [issue32416] Refactor and add new tests for the f_lineno setter In-Reply-To: <1514049243.28.0.213398074469.issue32416@psf.upfronthosting.co.za> Message-ID: <1514049554.63.0.213398074469.issue32416@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +4879 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 12:19:27 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Dec 2017 17:19:27 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1514049567.94.0.213398074469.issue17611@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- dependencies: +Refactor and add new tests for the f_lineno setter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 12:44:32 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 23 Dec 2017 17:44:32 +0000 Subject: [issue32357] Optimize asyncio.iscoroutine() and loop.create_task() for non-native coroutines In-Reply-To: <1513575220.77.0.213398074469.issue32357@psf.upfronthosting.co.za> Message-ID: <1514051072.72.0.213398074469.issue32357@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 558aa30f7971e087c4a00b1f49cc2ef3195c01ca by Yury Selivanov in branch 'master': bpo-32357: Fix tests in refleak mode (#4989) https://github.com/python/cpython/commit/558aa30f7971e087c4a00b1f49cc2ef3195c01ca ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 12:46:20 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 23 Dec 2017 17:46:20 +0000 Subject: [issue32415] Add Task.get_loop() and Future.get_loop() In-Reply-To: <1514048351.13.0.213398074469.issue32415@psf.upfronthosting.co.za> Message-ID: <1514051180.89.0.213398074469.issue32415@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4880 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 13:15:39 2017 From: report at bugs.python.org (Paul Ganssle) Date: Sat, 23 Dec 2017 18:15:39 +0000 Subject: [issue32417] fromutc does not respect datetime subclasses Message-ID: <1514052939.19.0.213398074469.issue32417@psf.upfronthosting.co.za> New submission from Paul Ganssle : When preparing some tests for how subclasses of date and datetime react as part of a fix for issue 32403, I noticed a fairly big example of where subclass is not preserved - `tzinfo.fromutc`: from datetime import datetime, timezone class DateTimeSubclass(datetime): pass dt = DateTimeSubclass(2012, 1, 1) dt2 = dt.astimezone(timezone.utc) print(type(dt)) print(type(dt2)) # Result: # # This also affects `datetime.fromtimestamp` and `datetime.now`, since both of these, when passed a time zone argument, will call `fromutc` internally. I personally think that Python's `tzinfo.fromutc` should preserve the object's class, but this *is* counter to the current API. And either way, it's quite inconsistent to have `DateTimeSubclass.now()` return `DateTimeSubclass` but have `DateTimeSubclass.now(timezone.utc)` return `datetime.datetime`. There is probably a somewhat inelegant way to get the alternate constructors working properly (ignore the type of the argument up until the last return and then construct the subclass from the components of the datetime), but I think it might be better to fix the behavior of tzinfo.fromutc. Somewhat related to issue 32404 and 31222, in that this concerns which operations preserve type in subclasses. ---------- messages: 308961 nosy: belopolsky, p-ganssle priority: normal severity: normal status: open title: fromutc does not respect datetime subclasses versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 13:19:08 2017 From: report at bugs.python.org (Paul Ganssle) Date: Sat, 23 Dec 2017 18:19:08 +0000 Subject: [issue32417] fromutc does not respect datetime subclasses In-Reply-To: <1514052939.19.0.213398074469.issue32417@psf.upfronthosting.co.za> Message-ID: <1514053148.53.0.213398074469.issue32417@psf.upfronthosting.co.za> Paul Ganssle added the comment: I've noticed that there's another complicating factor here, which is that addition of `timedelta` does not respect subclasses either, which means that third party libraries implementing fromutc (as was recommended in issue 28602), who will likely make use of timedelta addition, are going to have a harder time providing something that respects subclass. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 14:10:59 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 23 Dec 2017 19:10:59 +0000 Subject: [issue32418] Implement Server.get_loop() method Message-ID: <1514056259.94.0.213398074469.issue32418@psf.upfronthosting.co.za> New submission from Andrew Svetlov : Future and Task will have the method (bpo-32415) AbstractServer and Server should support it too. ---------- components: Library (Lib), asyncio messages: 308963 nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: Implement Server.get_loop() method type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 14:52:31 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 23 Dec 2017 19:52:31 +0000 Subject: [issue29780] Interpreter hang on self._epoll.poll(timeout, max_ev) In-Reply-To: <1489139274.42.0.877186515769.issue29780@psf.upfronthosting.co.za> Message-ID: <1514058751.66.0.213398074469.issue29780@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I see no hang in attached snapshot but notmal behavior. asyncio iterates over epoll.poll constantly waiting for network events or timeout. Closing the issue. ---------- nosy: +asvetlov resolution: -> works for me stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 14:55:53 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 23 Dec 2017 19:55:53 +0000 Subject: [issue26666] File object hook to modify select(ors) event mask In-Reply-To: <1459265321.27.0.359178089762.issue26666@psf.upfronthosting.co.za> Message-ID: <1514058953.48.0.213398074469.issue26666@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Out of asynio library scope. ---------- nosy: +asvetlov resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 15:02:38 2017 From: report at bugs.python.org (Paul Ganssle) Date: Sat, 23 Dec 2017 20:02:38 +0000 Subject: [issue32403] date, time and datetime alternate constructors should take fast construction path In-Reply-To: <1513893074.5.0.213398074469.issue32403@psf.upfronthosting.co.za> Message-ID: <1514059358.94.0.213398074469.issue32403@psf.upfronthosting.co.za> Change by Paul Ganssle : ---------- keywords: +patch pull_requests: +4881 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 15:02:39 2017 From: report at bugs.python.org (Paul Ganssle) Date: Sat, 23 Dec 2017 20:02:39 +0000 Subject: [issue32404] fromtimestamp does not call __new__ in datetime subclasses In-Reply-To: <1513893253.21.0.213398074469.issue32404@psf.upfronthosting.co.za> Message-ID: <1514059359.03.0.00913614298617.issue32404@psf.upfronthosting.co.za> Change by Paul Ganssle : ---------- keywords: +patch pull_requests: +4882 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 15:04:17 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 23 Dec 2017 20:04:17 +0000 Subject: [issue32415] Add Task.get_loop() and Future.get_loop() In-Reply-To: <1514048351.13.0.213398074469.issue32415@psf.upfronthosting.co.za> Message-ID: <1514059457.7.0.213398074469.issue32415@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset ca9b36cd1a384e5ecb56d9df9a59144240353ef0 by Yury Selivanov in branch 'master': bpo-32415: Add asyncio.Task.get_loop() and Future.get_loop() (#4992) https://github.com/python/cpython/commit/ca9b36cd1a384e5ecb56d9df9a59144240353ef0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 15:04:40 2017 From: report at bugs.python.org (Srinivas Reddy T) Date: Sat, 23 Dec 2017 20:04:40 +0000 Subject: [issue32360] Save OrderedDict imports in various stdlibs. In-Reply-To: <1513591210.99.0.213398074469.issue32360@psf.upfronthosting.co.za> Message-ID: <1514059480.43.0.213398074469.issue32360@psf.upfronthosting.co.za> Change by Srinivas Reddy T : ---------- keywords: +patch pull_requests: +4883 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 15:06:48 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 23 Dec 2017 20:06:48 +0000 Subject: [issue32357] Optimize asyncio.iscoroutine() and loop.create_task() for non-native coroutines In-Reply-To: <1513575220.77.0.213398074469.issue32357@psf.upfronthosting.co.za> Message-ID: <1514059608.86.0.213398074469.issue32357@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 0f47fa2c89a6b9a04969219dfb0c3801c611e3ca by Yury Selivanov (Andrew Svetlov) in branch 'master': bpo-32357: Use PySet_GET_SIZE macro in _is_coroutine() from _asynciomodule.c (#4990) https://github.com/python/cpython/commit/0f47fa2c89a6b9a04969219dfb0c3801c611e3ca ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 15:08:07 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 23 Dec 2017 20:08:07 +0000 Subject: [issue32415] Add Task.get_loop() and Future.get_loop() In-Reply-To: <1514048351.13.0.213398074469.issue32415@psf.upfronthosting.co.za> Message-ID: <1514059687.34.0.213398074469.issue32415@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 15:19:01 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 23 Dec 2017 20:19:01 +0000 Subject: [issue32415] Add Task.get_loop() and Future.get_loop() In-Reply-To: <1514048351.13.0.213398074469.issue32415@psf.upfronthosting.co.za> Message-ID: <1514060341.57.0.213398074469.issue32415@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- pull_requests: +4884 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 15:35:37 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 23 Dec 2017 20:35:37 +0000 Subject: [issue32327] Make asyncio methods documented as coroutines - coroutines. In-Reply-To: <1513285138.55.0.213398074469.issue32327@psf.upfronthosting.co.za> Message-ID: <1514061337.75.0.213398074469.issue32327@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- pull_requests: +4885 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 15:42:29 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 23 Dec 2017 20:42:29 +0000 Subject: [issue32415] Add Task.get_loop() and Future.get_loop() In-Reply-To: <1514048351.13.0.213398074469.issue32415@psf.upfronthosting.co.za> Message-ID: <1514061749.36.0.213398074469.issue32415@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset a8fb07978953d3f55cfce836e3669d8b8e82b4c1 by Yury Selivanov in branch 'master': bpo-32415: Add more tests (#4995) https://github.com/python/cpython/commit/a8fb07978953d3f55cfce836e3669d8b8e82b4c1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 15:45:37 2017 From: report at bugs.python.org (Srinivas Reddy T) Date: Sat, 23 Dec 2017 20:45:37 +0000 Subject: [issue32418] Implement Server.get_loop() method In-Reply-To: <1514056259.94.0.213398074469.issue32418@psf.upfronthosting.co.za> Message-ID: <1514061937.58.0.213398074469.issue32418@psf.upfronthosting.co.za> Change by Srinivas Reddy T : ---------- keywords: +patch pull_requests: +4886 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 16:10:50 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 23 Dec 2017 21:10:50 +0000 Subject: [issue32415] Add Task.get_loop() and Future.get_loop() In-Reply-To: <1514048351.13.0.213398074469.issue32415@psf.upfronthosting.co.za> Message-ID: <1514063450.33.0.213398074469.issue32415@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- pull_requests: +4887 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 16:21:03 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Sat, 23 Dec 2017 21:21:03 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1514064063.98.0.213398074469.issue17611@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Ho ho ho! I spent some time to try to resolve the remaining issues with PR 4682. I think everything now works. Returns from a final body of a try/finally was the remaining issue. I've solved it by introducing the POP_NO_EXCEPT opcode. I added a number of comments to help explain to future maintainers what is going on. The PR still could use some polishing. I have some test cases to add, to trigger the previously buggy try/finally + return case. Also, I think the fblock_unwind_ functions in the compiler could be done more simply. I don't think we need a separate function for each type, just use a case statement on the fblock type. That's a fairly minor detail though. I would also like to add a bunch more comments. I've spent many hours figuring out how all this stuff works, not that I totally understand everthing. The test case test_contextlib test_exit_exception_with_existing_context() was especially brain-busting. I'm a bit horrified that Python has become so complex to support such things. Anyhow, I'm off for holidays so no time for further polish until after Christmas. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 16:26:00 2017 From: report at bugs.python.org (Bassem Girgis) Date: Sat, 23 Dec 2017 21:26:00 +0000 Subject: [issue32419] Add unittest support for pyc projects Message-ID: <1514064360.62.0.213398074469.issue32419@psf.upfronthosting.co.za> New submission from Bassem Girgis : This PR makes it possible to "unittest" projects that are all pyc with no __init__.py which is hardcoded in few checks in unittest.loader ---------- components: Extension Modules messages: 308970 nosy: brgirgis priority: normal pull_requests: 4888 severity: normal status: open title: Add unittest support for pyc projects type: enhancement versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 16:29:28 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 23 Dec 2017 21:29:28 +0000 Subject: [issue32415] Add Task.get_loop() and Future.get_loop() In-Reply-To: <1514048351.13.0.213398074469.issue32415@psf.upfronthosting.co.za> Message-ID: <1514064568.79.0.213398074469.issue32415@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 719ccbca69b21013a783b829de3404b5aa243827 by Yury Selivanov in branch 'master': bpo-32415: Fix "error is already set" (#4999) https://github.com/python/cpython/commit/719ccbca69b21013a783b829de3404b5aa243827 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 17:00:05 2017 From: report at bugs.python.org (Srinivas Reddy T) Date: Sat, 23 Dec 2017 22:00:05 +0000 Subject: [issue32360] Save OrderedDict imports in various stdlibs. In-Reply-To: <1513591210.99.0.213398074469.issue32360@psf.upfronthosting.co.za> Message-ID: <1514066405.82.0.213398074469.issue32360@psf.upfronthosting.co.za> Change by Srinivas Reddy T : ---------- pull_requests: +4889 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 18:02:37 2017 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 23 Dec 2017 23:02:37 +0000 Subject: [issue32419] Add unittest support for pyc projects In-Reply-To: <1514064360.62.0.213398074469.issue32419@psf.upfronthosting.co.za> Message-ID: <1514070157.56.0.213398074469.issue32419@psf.upfronthosting.co.za> ?ric Araujo added the comment: Could you tell more about these projects? In current Python 3 pyc files are in a __pycache__ sub-directory, not directly in the package dir; what tool produces ?pyc projects?? ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 18:03:11 2017 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 23 Dec 2017 23:03:11 +0000 Subject: [issue32295] User friendly message when invoking bdist_wheel sans wheel package In-Reply-To: <1513118394.49.0.213398074469.issue32295@psf.upfronthosting.co.za> Message-ID: <1514070191.38.0.213398074469.issue32295@psf.upfronthosting.co.za> ?ric Araujo added the comment: Will close soon unless someone disagrees. ---------- resolution: -> wont fix status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 18:09:33 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 23 Dec 2017 23:09:33 +0000 Subject: [issue32360] Save OrderedDict imports in various stdlibs. In-Reply-To: <1513591210.99.0.213398074469.issue32360@psf.upfronthosting.co.za> Message-ID: <1514070573.33.0.213398074469.issue32360@psf.upfronthosting.co.za> Raymond Hettinger added the comment: These should be looked at one at a time (no sweeping search and replace missions). The original author should be consulted when possible (they are in a better position to judge whether the original intent was preserved). Published APIs should not be changed (i.e. you can't just change the default argument for configparser). Docs should be changed carefully (i.e. let Bob Ippolito decide whether he wants to change the examples of how to use the object_pairs_hook). Guido was very clear that you can't just downgrade every occurrence of OrderedDict with dict. Please don't be so aggressive (grepping every occurrence in the standard library without giving it individual consideration). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 19:03:07 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Sun, 24 Dec 2017 00:03:07 +0000 Subject: [issue28236] In xml.etree.ElementTree Element can be created with empty and None tag In-Reply-To: <1474458735.99.0.896501689259.issue28236@psf.upfronthosting.co.za> Message-ID: <1514073787.31.0.213398074469.issue28236@psf.upfronthosting.co.za> Gordon P. Hemsley added the comment: I disagree. This library is meant to be an interface onto XML syntax, and XML has pretty strict requirements on syntax. As msg277125 shows, you're liable to get very far downstream before the error becomes apparent. In addition, I'm finding a number of internal inconsistencies, both between the docs and the code and between the Python code and the C code, that demonstrate that doing these type checks up front would be beneficial to the entire library. (Note: The C code also does not do them.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 20:29:23 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 24 Dec 2017 01:29:23 +0000 Subject: [issue32402] Coverity: CID 1426868/1426867: Null pointer dereferences in textio.c In-Reply-To: <1513889402.22.0.213398074469.issue32402@psf.upfronthosting.co.za> Message-ID: <1514078963.28.0.213398074469.issue32402@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset 4856b0f34a6f4074cd86e66f11a635422374ae98 by INADA Naoki in branch 'master': bpo-32402: io: Add missing NULL check. (GH-4971) https://github.com/python/cpython/commit/4856b0f34a6f4074cd86e66f11a635422374ae98 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 21:20:37 2017 From: report at bugs.python.org (Kaoru Kitamura) Date: Sun, 24 Dec 2017 02:20:37 +0000 Subject: [issue32420] LookupError : unknown encoding : [0x7FF092395AD0] ANOMALY Message-ID: <1514082037.96.0.213398074469.issue32420@psf.upfronthosting.co.za> New submission from Kaoru Kitamura : I tried to activate tensorflow after creating tensorflow environment with Anaconda Prompt. Then, Python clashed in fatal error as attached. I searched this kind of issues and made environment variable for UTF-8 , but it did not work. Does anyone have any suggestions? ---------- components: Windows files: error_capture.png messages: 308977 nosy: Kitamura, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: LookupError : unknown encoding : [0x7FF092395AD0] ANOMALY type: crash versions: Python 3.6 Added file: https://bugs.python.org/file47346/error_capture.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 21:27:03 2017 From: report at bugs.python.org (Yonatan Zunger) Date: Sun, 24 Dec 2017 02:27:03 +0000 Subject: [issue32421] Keeping an exception in cache can segfault the interpreter Message-ID: <1514082423.32.0.213398074469.issue32421@psf.upfronthosting.co.za> New submission from Yonatan Zunger : Using the following decorator to memoize a function causes the interpreter to segfault on exit if any exceptions were stored in the cache. Changing the bad line to instead store copy.copy(e) makes the problem go away. Almost certainly some kind of problem with the GC of the traceback not happening at the moment the interpreter expects it, but I haven't had time to investigate any more deeply yet. def memoize(keyFunc=lambda x: x, cacheExceptions: bool=True): def wrapper(func): return _Memo(func, keyFunc, cacheExceptions) return wrapper class _Memo(object): def __init__(self, func, keyFunc, cacheExceptions: bool) -> None: self.func = func self.keyFunc = keyFunc self.cacheExceptions = cacheExceptions self.lock = threading.Lock() self.cache = {} def __call__(self, *args, **kwargs) -> Any: key = self.keyFunc(*args, **kwargs) assert isinstance(key, collections.Hashable) with self.lock: if key in self.cache: value = self.cache[key] if isinstance(value, BaseException): raise value return value try: result = self.func(*args, **kwargs) except BaseException as e: if self.cacheExceptions: with self.lock: self.cache[key] = e # BAD LINE six.reraise(*sys.exc_info()) else: with self.lock: self.cache[key] = result return result ---------- components: Interpreter Core messages: 308978 nosy: zunger priority: normal severity: normal status: open title: Keeping an exception in cache can segfault the interpreter type: crash versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 23 22:58:13 2017 From: report at bugs.python.org (Thomas Waldmann) Date: Sun, 24 Dec 2017 03:58:13 +0000 Subject: [issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups In-Reply-To: <1232404142.93.0.545475464378.issue5004@psf.upfronthosting.co.za> Message-ID: <1514087893.6.0.213398074469.issue5004@psf.upfronthosting.co.za> Thomas Waldmann added the comment: Embarassing as always to stumble over some stuff and then find a 9y old ticket here, where it is discussed and even (almost) solved. Our ticket: https://github.com/borgbackup/borg/issues/3471 Fixed getfqdn we use now instead of socket.getfqdn(): https://github.com/borgbackup/borg/pull/3484/commits/9b0d0f3127289fc3bbe620e8adce8038ed594e9f#diff-4b53f84e19a3bb376bf2202371ed269aR188 Note: no "else: name = hostname" at the end, that is a bug in the patch attached to this ticket (hostname is undefined after applying the patch). ---------- nosy: +Thomas.Waldmann _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 00:19:02 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 24 Dec 2017 05:19:02 +0000 Subject: [issue32422] Make OrderedDict can be used for LRU from C Message-ID: <1514092742.06.0.213398074469.issue32422@psf.upfronthosting.co.za> New submission from INADA Naoki : Currently, functools.lru_cache implement own doubly-linked list. But it is inefficient than OrderedDict because each link node is GC object. So it may eat more memory and take longer GC time. I added two private C API for OrderedDict and make lru_cache use it. * _PyODict_LRUGetItem(): Similar to PyDict_GetItemWithHash() + od.move_to_end(last=True). * _PyODict_PopItem(): Similar to odict.popitem(). Why I didn't implement C version of move_to_end() is to reduce lookup. _PyODict_LRUGetItem(key) lookup key once while od[key]; od.move_to_end(key) lookup key twice. I'll benchmark it and report result here. ---------- components: Interpreter Core messages: 308980 nosy: inada.naoki priority: normal severity: normal status: open title: Make OrderedDict can be used for LRU from C versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 00:32:45 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 24 Dec 2017 05:32:45 +0000 Subject: [issue32422] Make OrderedDict can be used for LRU from C In-Reply-To: <1514092742.06.0.213398074469.issue32422@psf.upfronthosting.co.za> Message-ID: <1514093565.22.0.213398074469.issue32422@psf.upfronthosting.co.za> INADA Naoki added the comment: Current implementation (no news entry yet): https://github.com/methane/cpython/pull/10/files ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 00:40:15 2017 From: report at bugs.python.org (Isuru Fernando) Date: Sun, 24 Dec 2017 05:40:15 +0000 Subject: [issue32423] The Windows SDK version 10.0.15063.0 was not found Message-ID: <1514094015.43.0.213398074469.issue32423@psf.upfronthosting.co.za> New submission from Isuru Fernando : When compiling python 3.6.4 on appveyor using MSVC 2015 following error occurs. (C:\bld\python_1514037886491\_b_env) C:\bld\python_1514037886491\work\Python-3.6.4\PCbuild>"C:\Program Files (x86)\MSBuild\14.0\Bin\amd64\MSBuild.exe" "C:\bld\python_1514037886491\work\Python-3.6.4\PCbuild\pcbuild.proj" /t:Build /m /nologo /v:m /p:Configuration=Release /p:Platform=x64 /p:IncludeExternals=true /p:IncludeSSL=true /p:IncludeTkinter=true /p:UseTestMarker= /p:GIT="C:\Program Files\Git\cmd\git.exe" C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\x64\PlatformToolsets\v140\Toolset.targets(36,5): error MSB8036: The Windows SDK version 10.0.15063.0 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution". [C:\bld\python_1514037886491\work\Python-3.6.4\PCbuild\pythoncore.vcxproj] Note that appveyor Visual Studio 2015 image has only 10.0.10586, 10.0.14393 and 10.0.26624 Here's a simple patch that fixes this on 3.6 branch. https://github.com/isuruf/cpython/commit/9432a2c7f63b3bb55e8066e91eade81321154476 I haven't checked that the patch works on a machine with 10.0.15063 ---------- components: Windows messages: 308982 nosy: Isuru Fernando, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: The Windows SDK version 10.0.15063.0 was not found type: compile error versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 00:48:13 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 24 Dec 2017 05:48:13 +0000 Subject: [issue32360] Save OrderedDict imports in various stdlibs. In-Reply-To: <1513591210.99.0.213398074469.issue32360@psf.upfronthosting.co.za> Message-ID: <1514094493.79.0.213398074469.issue32360@psf.upfronthosting.co.za> INADA Naoki added the comment: Agreed. I won't remove OrderedDict usages which is part of public APIs. This issue is for finding and removing easy local usages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 00:54:53 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 24 Dec 2017 05:54:53 +0000 Subject: [issue32360] Save OrderedDict imports in various stdlibs. In-Reply-To: <1513591210.99.0.213398074469.issue32360@psf.upfronthosting.co.za> Message-ID: <1514094893.57.0.213398074469.issue32360@psf.upfronthosting.co.za> Change by INADA Naoki : ---------- pull_requests: +4890 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 01:07:59 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 24 Dec 2017 06:07:59 +0000 Subject: [issue32360] Save OrderedDict imports in various stdlibs. In-Reply-To: <1513591210.99.0.213398074469.issue32360@psf.upfronthosting.co.za> Message-ID: <1514095679.29.0.213398074469.issue32360@psf.upfronthosting.co.za> INADA Naoki added the comment: Let's remove from these: * asyncio/base_events.py: Used for local variable. * email/_header_value_parser.py: Used for local variable. * json: Examples (in document and docstring) for keeping order, and json.tool. I don't touch other modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 03:05:28 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Dec 2017 08:05:28 +0000 Subject: [issue32422] Make OrderedDict can be used for LRU from C In-Reply-To: <1514092742.06.0.213398074469.issue32422@psf.upfronthosting.co.za> Message-ID: <1514102728.38.0.213398074469.issue32422@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is a duplicate of issue28239. ---------- nosy: +serhiy.storchaka resolution: -> duplicate superseder: -> Implement functools.lru_cache() using ordered dict _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 03:07:29 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Dec 2017 08:07:29 +0000 Subject: [issue32422] Make OrderedDict can be used for LRU from C In-Reply-To: <1514092742.06.0.213398074469.issue32422@psf.upfronthosting.co.za> Message-ID: <1514102849.83.0.213398074469.issue32422@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 03:11:19 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Dec 2017 08:11:19 +0000 Subject: [issue32422] Make OrderedDict can be used for LRU from C In-Reply-To: <1514092742.06.0.213398074469.issue32422@psf.upfronthosting.co.za> Message-ID: <1514103079.18.0.213398074469.issue32422@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, sorry, you use OrderedDict instead of just ordered dict. It should have different timing and memory consumption. ---------- resolution: duplicate -> stage: resolved -> status: closed -> open superseder: Implement functools.lru_cache() using ordered dict -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 03:18:24 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Dec 2017 08:18:24 +0000 Subject: [issue32360] Save OrderedDict imports in various stdlibs. In-Reply-To: <1513591210.99.0.213398074469.issue32360@psf.upfronthosting.co.za> Message-ID: <1514103504.9.0.213398074469.issue32360@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I concur with Raymond. I made the same searching before and have found that there are not much opportunities for getting rid of OrderedDict and there are even less cases that will get a benefit from this. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 03:20:57 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Dec 2017 08:20:57 +0000 Subject: [issue32421] Keeping an exception in cache can segfault the interpreter In-Reply-To: <1514082423.32.0.213398074469.issue32421@psf.upfronthosting.co.za> Message-ID: <1514103657.48.0.213398074469.issue32421@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 03:27:31 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Dec 2017 08:27:31 +0000 Subject: [issue28236] In xml.etree.ElementTree Element can be created with empty and None tag In-Reply-To: <1474458735.99.0.896501689259.issue28236@psf.upfronthosting.co.za> Message-ID: <1514104051.16.0.213398074469.issue28236@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I concur with Raymond. Supporting non-string tags is a feature of ElementTree that is used internally (for comments, etc) and can be used in user code. And the C implementation intentionally reproduces this feature. ---------- nosy: +eli.bendersky, scoder, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 03:28:55 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Dec 2017 08:28:55 +0000 Subject: [issue32420] LookupError : unknown encoding : [0x7FF092395AD0] ANOMALY In-Reply-To: <1514082037.96.0.213398074469.issue32420@psf.upfronthosting.co.za> Message-ID: <1514104135.47.0.213398074469.issue32420@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please provide the output as a text instead of a picture? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 03:30:38 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Dec 2017 08:30:38 +0000 Subject: [issue32419] Add unittest support for pyc projects In-Reply-To: <1514064360.62.0.213398074469.issue32419@psf.upfronthosting.co.za> Message-ID: <1514104238.24.0.213398074469.issue32419@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- components: +Library (Lib) -Extension Modules nosy: +ezio.melotti, michael.foord, rbcollins versions: -Python 3.6, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 03:41:59 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Dec 2017 08:41:59 +0000 Subject: [issue32414] PyCapsule_Import fails when name is in the form 'package.module.capsule' In-Reply-To: <1514022429.41.0.213398074469.issue32414@psf.upfronthosting.co.za> Message-ID: <1514104919.7.0.213398074469.issue32414@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PR 4988 will break the case 'module.attr.capsule' if 'module.attr' is not a module. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 04:32:48 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 24 Dec 2017 09:32:48 +0000 Subject: [issue26133] asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za> Message-ID: <1514107968.09.0.213398074469.issue26133@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- pull_requests: +4891 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 04:55:21 2017 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 24 Dec 2017 09:55:21 +0000 Subject: [issue32398] OSX C++ linking workaround in distutils breaks other packages In-Reply-To: <1513876979.22.0.213398074469.issue32398@psf.upfronthosting.co.za> Message-ID: <1514109321.7.0.213398074469.issue32398@psf.upfronthosting.co.za> Ronald Oussoren added the comment: As I mentioned on the pull request it is not clear to me what the actual issue is. What are the settings for building that cause problems? In particular, what are the compiler/linker related variables in Python's Makefile (and _sysconfigdata.py)? With the currently available information I'm -1 w.r.t accepting the attached pull request. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 04:59:52 2017 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 24 Dec 2017 09:59:52 +0000 Subject: [issue28236] In xml.etree.ElementTree Element can be created with empty and None tag In-Reply-To: <1474458735.99.0.896501689259.issue28236@psf.upfronthosting.co.za> Message-ID: <1514109592.35.0.213398074469.issue28236@psf.upfronthosting.co.za> Stefan Behnel added the comment: I also consider it an actual feature of ElementTree to allow arbitrary objects as its tags, even if it's not one of the most prominent. lxml cannot copy this because it is based on C libraries internally, but that shouldn't prevent ET from allowing it. The fact that None tags disappear is also definitely a feature. It's an easy way to delete tags from trees without requiring any restructuring. OTOH, whether an empty string should be serialised in the way the OP shows is not so clear. The output is not XML. I can't see any use case for this, but it feels like a potential source of bugs. I think it would be better to have the serialiser explicitly reject this than letting it silently generate broken output. Not something to change in Py3.6, though. ---------- versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 05:09:04 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 24 Dec 2017 10:09:04 +0000 Subject: [issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed In-Reply-To: <1513796551.12.0.213398074469.issue32390@psf.upfronthosting.co.za> Message-ID: <1514110144.12.0.213398074469.issue32390@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > The PPC64 AIX 3.x Python buildbot (http://buildbot.python.org/all/#/builders/10) has been failing upon this same error for over a month. Michael Felt answered by email: > Not quite a month: 8 days ago (test 357 was the first with this error). Great suggestion! Right, f_fsid has been added only few days ago by issue 32143. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 05:10:36 2017 From: report at bugs.python.org (lekma) Date: Sun, 24 Dec 2017 10:10:36 +0000 Subject: [issue32414] PyCapsule_Import fails when name is in the form 'package.module.capsule' In-Reply-To: <1514104919.7.0.213398074469.issue32414@psf.upfronthosting.co.za> Message-ID: <20171224111031.48c6b556@esmeralda> lekma added the comment: > PR 4988 will break the case 'module.attr.capsule' if 'module.attr' is > not a module. you are right, but is that a case you would expect in an import statement? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 06:50:06 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 24 Dec 2017 11:50:06 +0000 Subject: [issue26133] asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za> Message-ID: <1514116206.37.0.213398074469.issue26133@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset 4f146f9ed133b9ad56d4ee7a653396836af34067 by Andrew Svetlov in branch 'master': bpo-26133: Clear signals list on interpreter finalizing (#5002) https://github.com/python/cpython/commit/4f146f9ed133b9ad56d4ee7a653396836af34067 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 06:50:17 2017 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Dec 2017 11:50:17 +0000 Subject: [issue26133] asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za> Message-ID: <1514116217.15.0.213398074469.issue26133@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4892 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 07:31:00 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 24 Dec 2017 12:31:00 +0000 Subject: [issue26133] asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za> Message-ID: <1514118660.67.0.213398074469.issue26133@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset 5ff5d1167de88eb37265dcaf1396d12617a0ace7 by Andrew Svetlov (Miss Islington (bot)) in branch '3.6': bpo-26133: Clear signals list on interpreter finalizing (GH-5002) (#5003) https://github.com/python/cpython/commit/5ff5d1167de88eb37265dcaf1396d12617a0ace7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 07:32:05 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 24 Dec 2017 12:32:05 +0000 Subject: [issue26133] asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za> Message-ID: <1514118725.85.0.213398074469.issue26133@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.6, Python 3.7 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 10:19:38 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 24 Dec 2017 15:19:38 +0000 Subject: [issue32335] Failed Python build on Fedora 27 In-Reply-To: <1513358854.45.0.213398074469.issue32335@psf.upfronthosting.co.za> Message-ID: <1514128778.5.0.213398074469.issue32335@psf.upfronthosting.co.za> Xavier de Gaye added the comment: I get the same build failure when the following line is commented out in Modules/Setup: _thread _threadmodule.c # low-level threading interface Can you please attach the full output of the build. ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 10:22:18 2017 From: report at bugs.python.org (Kaoru Kitamura) Date: Sun, 24 Dec 2017 15:22:18 +0000 Subject: [issue32420] LookupError : unknown encoding : [0x7FF092395AD0] ANOMALY In-Reply-To: <1514082037.96.0.213398074469.issue32420@psf.upfronthosting.co.za> Message-ID: <1514128938.12.0.213398074469.issue32420@psf.upfronthosting.co.za> Kaoru Kitamura added the comment: The below is the output of error. :\Users\kitamura>activate tensorflow ?????????????? - [0x7FFD92395AD0] [0x7FFD8F53DFE0] ANOMALY: meaningless REX prefix used [0x7FFD8F555A20] ANOMALY: meaningless REX prefix used [0x7FFD905417D0] ANOMALY: use of REX.w is meaningless (default operand size is 64) [0x7FFD90567C60] ANOMALY: use of REX.w is meaningless (default operand size is 64) [0x7FFD92395AD0] ANOMALY: meaningless REX prefix used [0x7FFD8F53DFE0] ANOMALY: meaningless REX prefix used [0x7FFD8F555A20] ANOMALY: meaningless REX prefix used [0x7FFD905417D0] ANOMALY: use of REX.w is meaningless (default operand size is 64) [0x7FFD90567C60] ANOMALY: use of REX.w is meaningless (default operand size is 64) [0x7FFD92395AD0] ANOMALY: meaningless REX prefix used Fatal Python error: Py_Initialize: can't initialize sys standard streams LookupError: unknown encoding: [0x7FFD92395AD0] ANOMALY Current thread 0x000031ac (most recent call first): Fatal Python error: Py_Initialize: can't initialize sys standard streams LookupError: unknown encoding: [0x7FFD92395AD0] ANOMALY Current thread 0x00002bd0 (most recent call first): Fatal Python error: Py_Initialize: can't initialize sys standard streams LookupError: unknown encoding: [0x7FFD92395AD0] ANOMALY Current thread 0x000004a4 (most recent call first): Fatal Python error: Py_Initialize: can't initialize sys standard streams LookupError: unknown encoding: [0x7FFD92395AD0] ANOMALY Current thread 0x00002264 (most recent call first): ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 10:40:03 2017 From: report at bugs.python.org (Amit Ghadge) Date: Sun, 24 Dec 2017 15:40:03 +0000 Subject: [issue32335] Failed Python build on Fedora 27 In-Reply-To: <1513358854.45.0.213398074469.issue32335@psf.upfronthosting.co.za> Message-ID: <1514130003.57.0.213398074469.issue32335@psf.upfronthosting.co.za> Amit Ghadge added the comment: build failure output; ---------- Added file: https://bugs.python.org/file47347/build_.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 10:49:27 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 24 Dec 2017 15:49:27 +0000 Subject: [issue32335] Failed Python build on Fedora 27 In-Reply-To: <1513358854.45.0.213398074469.issue32335@psf.upfronthosting.co.za> Message-ID: <1514130567.51.0.213398074469.issue32335@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Your build failure output shows that _threadmodule.c is not compiled and therefore the _thread module is missing. You just need to overwrite the current Modules/Setup file (it is possibly corrupted somehow) as suggested at the start of your attached build output and then run make again: $ cp Modules/Setup.dist Modules/Setup $ make ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 11:19:28 2017 From: report at bugs.python.org (R. David Murray) Date: Sun, 24 Dec 2017 16:19:28 +0000 Subject: [issue32419] Add unittest support for pyc projects In-Reply-To: <1514064360.62.0.213398074469.issue32419@psf.upfronthosting.co.za> Message-ID: <1514132368.29.0.213398074469.issue32419@psf.upfronthosting.co.za> R. David Murray added the comment: ?ric: in python3 if no .py is found but a .pyc is found where the .py is expected, it will be imported and run. This supports sourceless package distributions, which is something we only sorta-support :) The change looks simple enough that it might be worth doing, but I'll leave that to the unittest maintainers. If accepted there should be comments as to why a .pyc is being checked for. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 11:31:08 2017 From: report at bugs.python.org (Amit Ghadge) Date: Sun, 24 Dec 2017 16:31:08 +0000 Subject: [issue32335] Failed Python build on Fedora 27 In-Reply-To: <1513358854.45.0.213398074469.issue32335@psf.upfronthosting.co.za> Message-ID: <1514133068.97.0.213398074469.issue32335@psf.upfronthosting.co.za> Amit Ghadge added the comment: It's work and build succeed. Thanks Xavier ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 11:53:05 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Dec 2017 16:53:05 +0000 Subject: [issue32419] Add unittest support for pyc projects In-Reply-To: <1514064360.62.0.213398074469.issue32419@psf.upfronthosting.co.za> Message-ID: <1514134385.71.0.213398074469.issue32419@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 12:24:14 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 24 Dec 2017 17:24:14 +0000 Subject: [issue32422] Make OrderedDict can be used for LRU from C In-Reply-To: <1514092742.06.0.213398074469.issue32422@psf.upfronthosting.co.za> Message-ID: <1514136254.19.0.213398074469.issue32422@psf.upfronthosting.co.za> INADA Naoki added the comment: Hmm, it seems my implementation is 30% slower when many mishit scenario. Maybe, dict is faster than OrderedDict about massive insert/discard. But I need to profile it. On the other hand, GC speed looks about 2x faster as expected. $ ./python -m perf compare_to master.json patched.json -G Slower (5): - lru_1000_100: 217 ns +- 6 ns -> 302 ns +- 6 ns: 1.39x slower (+39%) - lru_10000_1000: 225 ns +- 4 ns -> 309 ns +- 2 ns: 1.37x slower (+37%) - lru_100_1000: 114 ns +- 5 ns -> 119 ns +- 1 ns: 1.05x slower (+5%) - lru_100_100: 115 ns +- 6 ns -> 119 ns +- 1 ns: 1.03x slower (+3%) - lru_1000_1000: 134 ns +- 6 ns -> 136 ns +- 1 ns: 1.02x slower (+2%) Faster (4): - gc(1000000): 98.3 ms +- 0.3 ms -> 37.9 ms +- 0.2 ms: 2.59x faster (-61%) - gc(100000): 11.7 ms +- 0.0 ms -> 5.10 ms +- 0.02 ms: 2.29x faster (-56%) - gc(10000): 1.48 ms +- 0.02 ms -> 1.04 ms +- 0.01 ms: 1.41x faster (-29%) - lru_10_100: 149 ns +- 6 ns -> 147 ns +- 2 ns: 1.02x faster (-2%) ---------- Added file: https://bugs.python.org/file47348/lru_bench.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 12:31:13 2017 From: report at bugs.python.org (Srinivas Reddy T) Date: Sun, 24 Dec 2017 17:31:13 +0000 Subject: [issue32413] Document that locals() may return globals() In-Reply-To: <1514008362.41.0.213398074469.issue32413@psf.upfronthosting.co.za> Message-ID: <1514136673.88.0.213398074469.issue32413@psf.upfronthosting.co.za> Change by Srinivas Reddy T : ---------- keywords: +patch pull_requests: +4893 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 12:42:42 2017 From: report at bugs.python.org (Srinivas Reddy T) Date: Sun, 24 Dec 2017 17:42:42 +0000 Subject: [issue32413] Document that locals() may return globals() In-Reply-To: <1514008362.41.0.213398074469.issue32413@psf.upfronthosting.co.za> Message-ID: <1514137362.08.0.213398074469.issue32413@psf.upfronthosting.co.za> Srinivas Reddy T added the comment: Done. exec(...)'s documentation covers raymond's comment. ---------- nosy: +thatiparthy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 12:44:19 2017 From: report at bugs.python.org (Christian Heimes) Date: Sun, 24 Dec 2017 17:44:19 +0000 Subject: [issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups In-Reply-To: <1232404142.93.0.545475464378.issue5004@psf.upfronthosting.co.za> Message-ID: <1514137459.65.0.213398074469.issue5004@psf.upfronthosting.co.za> Change by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 12:51:00 2017 From: report at bugs.python.org (Shinjo Park) Date: Sun, 24 Dec 2017 17:51:00 +0000 Subject: [issue21872] LZMA library sometimes fails to decompress a file In-Reply-To: <1403720935.87.0.990494824612.issue21872@psf.upfronthosting.co.za> Message-ID: <1514137860.6.0.213398074469.issue21872@psf.upfronthosting.co.za> Shinjo Park added the comment: Hi, I think I encountered this bug with Ubuntu 17.10 / Python 3.6.3. The same error was triggered by Python's LZMA library, while the xz command line tool can extract the problematic file. Not sure whether there is the bug in 3.7/3.8. I am attaching the problematic archives, they should contain UTF-16LE encoded text. ---------- nosy: +peremen versions: +Python 3.6 Added file: https://bugs.python.org/file47349/failed_files_more.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 13:14:24 2017 From: report at bugs.python.org (INADA Naoki) Date: Sun, 24 Dec 2017 18:14:24 +0000 Subject: [issue32422] Make OrderedDict can be used for LRU from C In-Reply-To: <1514092742.06.0.213398074469.issue32422@psf.upfronthosting.co.za> Message-ID: <1514139264.41.0.213398074469.issue32422@psf.upfronthosting.co.za> INADA Naoki added the comment: I found odict.pop() and odict.popitem() is very inefficient because it look up key multiple times. odict seems not optimized well and very slow than dict in some area... I'll try to optimize it in holidays. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 13:28:48 2017 From: report at bugs.python.org (Srinivas Reddy T) Date: Sun, 24 Dec 2017 18:28:48 +0000 Subject: [issue32384] Generator tests is broken in non-CPython implementation In-Reply-To: <1513767040.63.0.213398074469.issue32384@psf.upfronthosting.co.za> Message-ID: <1514140128.44.0.213398074469.issue32384@psf.upfronthosting.co.za> Change by Srinivas Reddy T : ---------- pull_requests: +4894 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 13:28:58 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 24 Dec 2017 18:28:58 +0000 Subject: [issue32422] Make OrderedDict can be used for LRU from C In-Reply-To: <1514092742.06.0.213398074469.issue32422@psf.upfronthosting.co.za> Message-ID: <1514140138.92.0.213398074469.issue32422@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Please stop revising every single thing you look at. The traditional design of LRU caches used doubly linked lists for a reason. In particular, when there is a high hit rate, the links can be updated without churning the underlying dictionary. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 13:34:21 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 24 Dec 2017 18:34:21 +0000 Subject: [issue32360] Save OrderedDict imports in various stdlibs. In-Reply-To: <1513591210.99.0.213398074469.issue32360@psf.upfronthosting.co.za> Message-ID: <1514140461.9.0.213398074469.issue32360@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > * asyncio/base_events.py: Used for local variable. > * email/_header_value_parser.py: Used for local variable. > * json: Examples (in document and docstring) for keeping order, and json.tool. All of these modules have active maintainers. You should create separate issues for each one of these and assign to those maintainers. You don't just get to mow down all the other developers. That isn't how we work together. In the JSON module, there does need to be an example of how to use object_pairs_hook, so you will need to come up with a replacement or an additional note explaining in Py3.7 and later, most of the OrderedDict use cases have been supplanted by the regular dict. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 13:36:59 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Sun, 24 Dec 2017 18:36:59 +0000 Subject: [issue28236] In xml.etree.ElementTree Element can be created with empty and None tag In-Reply-To: <1474458735.99.0.896501689259.issue28236@psf.upfronthosting.co.za> Message-ID: <1514140619.51.0.213398074469.issue28236@psf.upfronthosting.co.za> Gordon P. Hemsley added the comment: To be clear, we are talking about the Element class of the ElementTree module, which is distinct from the ElementTree class of the same module. That said, I personally question the implementation decision to represent things like treating comments as an Element with a tag of a Comment function. The XML standard is pretty clear that neither comments nor processing instructions are in fact elements, and I don't see it as a Good Thing that arbitrary objects are allowed as the value of tag, unless there is a requirement that such objects are subclasses of str. Note also that the documentation makes no mention of tag being anything other than a string. And there is inconsistency with where bytes are supposedly allowed (according to the documentation) and where they're actually allowed (according to the code). Given this, I think it's hard to say what user code is expected to make use of. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 13:51:40 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Sun, 24 Dec 2017 18:51:40 +0000 Subject: [issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation Message-ID: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> New submission from Gordon P. Hemsley : Currently, the Python implementation of the Element class in xml.etree.ElementTree defines a method called copy() which the C implementation does not define, whereas the C implementation defines a __copy__() method (and a __deepcopy__() method) which the Python implementation does not define. Given that the documentation makes no mention of a copy() method and that its definition would be masked by a standard import of xml.etree.ElementTree, I propose that it be renamed to __copy__() so that copy.copy() can make use of it. ---------- components: Library (Lib), XML messages: 309010 nosy: eli.bendersky, gphemsley, scoder priority: normal severity: normal status: open title: Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 14:08:23 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Sun, 24 Dec 2017 19:08:23 +0000 Subject: [issue32425] Allow non-default XML parsers to take advantage of a _parse_whole definition in xml.etree.ElementTree.ElementTree.parse() Message-ID: <1514142503.5.0.213398074469.issue32425@psf.upfronthosting.co.za> New submission from Gordon P. Hemsley : Currently, ElementTree.parse() in xml.etree.ElementTree only invokes _parse_whole() on the parser if no parser is specified and it falls back to the built-in XMLParser. This has two drawbacks: * If the built-in XMLParser is specified explicitly, it does not get the advantage of using its _parse_whole() method. * If another XML parser is specified, it does not have the option to define a _parse_whole() method. In both cases, the parser parses in chunks (of 16 KiB), which is potentially slower. I propose allowing any parser to take advantage of _parse_whole() if it has defined such a method. (This would also have the benefit of eliminating some minor code duplication--two return branches could become one.) ---------- components: Library (Lib), XML messages: 309011 nosy: eli.bendersky, gphemsley, scoder priority: normal severity: normal status: open title: Allow non-default XML parsers to take advantage of a _parse_whole definition in xml.etree.ElementTree.ElementTree.parse() type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 14:09:24 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Sun, 24 Dec 2017 19:09:24 +0000 Subject: [issue32425] Allow non-default XML parsers to take advantage of a _parse_whole definition in xml.etree.ElementTree.ElementTree.parse() In-Reply-To: <1514142503.5.0.213398074469.issue32425@psf.upfronthosting.co.za> Message-ID: <1514142564.15.0.213398074469.issue32425@psf.upfronthosting.co.za> Gordon P. Hemsley added the comment: Sorry, the chunks are 64 KiB. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 14:16:30 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 24 Dec 2017 19:16:30 +0000 Subject: [issue32422] Make OrderedDict can be used for LRU from C In-Reply-To: <1514092742.06.0.213398074469.issue32422@psf.upfronthosting.co.za> Message-ID: <1514142990.49.0.213398074469.issue32422@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I'm the original author and designer of this code, so it would have been appropriate to assign this to me for sign-off on any proposed changes. ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 14:23:22 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Sun, 24 Dec 2017 19:23:22 +0000 Subject: [issue29209] Remove old-deprecated ElementTree features In-Reply-To: <1483898185.03.0.0187159979308.issue29209@psf.upfronthosting.co.za> Message-ID: <1514143402.67.0.213398074469.issue29209@psf.upfronthosting.co.za> Change by Gordon P. Hemsley : ---------- nosy: +gphemsley _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 14:24:53 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Dec 2017 19:24:53 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1514143493.08.0.213398074469.issue17611@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4895 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 14:30:16 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Sun, 24 Dec 2017 19:30:16 +0000 Subject: [issue28236] In xml.etree.ElementTree Element can be created with empty and None tag In-Reply-To: <1474458735.99.0.896501689259.issue28236@psf.upfronthosting.co.za> Message-ID: <1514143816.94.0.213398074469.issue28236@psf.upfronthosting.co.za> Gordon P. Hemsley added the comment: Issues of potential relevance to this discussion: * Issue28237 - In xml.etree.ElementTree bytes tag or attributes raises on serialization * Issue5166 - ElementTree and minidom don't prevent creation of not well-formed XML ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 14:41:34 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Dec 2017 19:41:34 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1514144494.52.0.213398074469.issue17611@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The main problem was with the frame.f_lineno setter. I have finally solved it in PR 5006. It solves also the regression in the with statement mentioned in msg307577 (by just restoring the original SETUP_WITH), and some other minor issues which I forgot. Tests for the frame.f_lineno setter are provided in issue32416. I want to backport these changes and add new tests in PR 5006 (which allows to catch more illegal jumps than the current code), thus a separate issue. PR 2827 and PR 4682 crash with these tests. Additionally PR 5006 may fix several issues with stack size calculation. I'll add tests later if there are reproducers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 14:49:25 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Dec 2017 19:49:25 +0000 Subject: [issue32422] Make OrderedDict can be used for LRU from C In-Reply-To: <1514142990.49.0.213398074469.issue32422@psf.upfronthosting.co.za> Message-ID: <11217721.geQatjNpgD@saraksh> Serhiy Storchaka added the comment: > FWIW, I'm the original author and designer of this code, so it would have > been appropriate to assign this to me for sign-off on any proposed changes. Not me (the C implementation)? ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 15:37:54 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Dec 2017 20:37:54 +0000 Subject: [issue28239] Implement functools.lru_cache() using ordered dict In-Reply-To: <1474465931.98.0.374027560088.issue28239@psf.upfronthosting.co.za> Message-ID: <1514147874.0.0.213398074469.issue28239@psf.upfronthosting.co.za> Change by Serhiy Storchaka : Added file: https://bugs.python.org/file47350/lru_cache-get-del-set-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 15:38:17 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Dec 2017 20:38:17 +0000 Subject: [issue28239] Implement functools.lru_cache() using ordered dict In-Reply-To: <1474465931.98.0.374027560088.issue28239@psf.upfronthosting.co.za> Message-ID: <1514147897.9.0.213398074469.issue28239@psf.upfronthosting.co.za> Change by Serhiy Storchaka : Added file: https://bugs.python.org/file47351/lru_cache-pop-set-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 15:38:41 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Dec 2017 20:38:41 +0000 Subject: [issue28239] Implement functools.lru_cache() using ordered dict In-Reply-To: <1474465931.98.0.374027560088.issue28239@psf.upfronthosting.co.za> Message-ID: <1514147921.73.0.213398074469.issue28239@psf.upfronthosting.co.za> Change by Serhiy Storchaka : Added file: https://bugs.python.org/file47352/lru_cache-move_to_end-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 15:47:45 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Dec 2017 20:47:45 +0000 Subject: [issue28239] Implement functools.lru_cache() using ordered dict In-Reply-To: <1474465931.98.0.374027560088.issue28239@psf.upfronthosting.co.za> Message-ID: <1514148465.53.0.213398074469.issue28239@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Since this theme has been raised again in issue32422 and old patches no longer apply clearly I have updated patches and benchmark results on 64 bit. $ ./python -m perf timeit -s "from functools import lru_cache; f = lru_cache(512)(lambda x: x); a = list(range(500))*100" -- "list(map(f, a))" Unpatched: Mean +- std dev: 3.03 ms +- 0.02 ms get-del-set: Mean +- std dev: 5.73 ms +- 0.04 ms pop-set: Mean +- std dev: 4.63 ms +- 0.04 ms move_to_end: Mean +- std dev: 3.57 ms +- 0.06 ms $ ./python -m perf timeit -s "from functools import lru_cache; f = lru_cache(512)(lambda x: x); a = list(range(50000))" -- "list(map(f, a))" Unpatched: Mean +- std dev: 6.65 ms +- 0.11 ms get-del-set: Mean +- std dev: 15.5 ms +- 0.1 ms pop-set: Mean +- std dev: 15.4 ms +- 0.1 ms move_to_end: Mean +- std dev: 15.5 ms +- 0.2 ms All patches cause significant slowdown (around 2.3x) in the case of many misses. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 15:58:51 2017 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 24 Dec 2017 20:58:51 +0000 Subject: [issue28236] In xml.etree.ElementTree Element can be created with empty and None tag In-Reply-To: <1514140619.51.0.213398074469.issue28236@psf.upfronthosting.co.za> Message-ID: <6D479AA0-C018-4959-A51A-FE27A43AB2D9@behnel.de> Stefan Behnel added the comment: >That said, I personally question the implementation decision to >represent things like treating comments as an Element with a tag of a >Comment function. This is not going to change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 16:09:11 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 24 Dec 2017 21:09:11 +0000 Subject: [issue32414] PyCapsule_Import fails when name is in the form 'package.module.capsule' In-Reply-To: <1514022429.41.0.213398074469.issue32414@psf.upfronthosting.co.za> Message-ID: <1514149751.03.0.213398074469.issue32414@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- nosy: +brett.cannon, eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 17:18:53 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 24 Dec 2017 22:18:53 +0000 Subject: [issue28236] In xml.etree.ElementTree Element can be created with empty and None tag In-Reply-To: <1474458735.99.0.896501689259.issue28236@psf.upfronthosting.co.za> Message-ID: <1514153933.0.0.213398074469.issue28236@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Marking this as closed. Gordon, thank you for showing an interest in this tracker item. While fixing bugs is of interest, altering long standing intentional design decisions is not useful. The time to do that is before a module is released, not a decade later. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 17:22:15 2017 From: report at bugs.python.org (Josh Holland) Date: Sun, 24 Dec 2017 22:22:15 +0000 Subject: [issue32421] Keeping an exception in cache can segfault the interpreter In-Reply-To: <1514082423.32.0.213398074469.issue32421@psf.upfronthosting.co.za> Message-ID: <1514154135.55.0.213398074469.issue32421@psf.upfronthosting.co.za> Change by Josh Holland : ---------- nosy: +anowlcalledjosh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 19:08:45 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Dec 2017 00:08:45 +0000 Subject: [issue29084] C API of OrderedDict In-Reply-To: <1482847157.79.0.799208161515.issue29084@psf.upfronthosting.co.za> Message-ID: <1514160525.86.0.213398074469.issue29084@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 1b3029ac8370ac76fa9571aef540e10aed0667ff by Serhiy Storchaka in branch 'master': bpo-29084: Exclude C API for OrderedDict from the limited C API. (#4900) https://github.com/python/cpython/commit/1b3029ac8370ac76fa9571aef540e10aed0667ff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 19:08:59 2017 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Dec 2017 00:08:59 +0000 Subject: [issue29084] C API of OrderedDict In-Reply-To: <1482847157.79.0.799208161515.issue29084@psf.upfronthosting.co.za> Message-ID: <1514160539.12.0.213398074469.issue29084@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4896 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 19:17:07 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Dec 2017 00:17:07 +0000 Subject: [issue32137] Stack overflow in repr of deeply nested dicts In-Reply-To: <1511686410.56.0.213398074469.issue32137@psf.upfronthosting.co.za> Message-ID: <1514161027.36.0.213398074469.issue32137@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please take a look at PR 4689 and PR 4812 Raymond? I remember you had objections against similar changes and I have small hesitates. What way of solving this issue in maintained releases do you prefer? ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 19:20:47 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Dec 2017 00:20:47 +0000 Subject: [issue30296] Remove unnecessary tuples, lists, sets, and dicts from Lib In-Reply-To: <1494162484.35.0.941296488498.issue30296@psf.upfronthosting.co.za> Message-ID: <1514161247.27.0.213398074469.issue30296@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What will you say Raymond? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 19:42:23 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Mon, 25 Dec 2017 00:42:23 +0000 Subject: [issue32411] Idlelib.browser: stop sorting dicts created by pyclbr In-Reply-To: <1513996869.13.0.213398074469.issue32411@psf.upfronthosting.co.za> Message-ID: <1514162543.63.0.213398074469.issue32411@psf.upfronthosting.co.za> Cheryl Sabella added the comment: Terry, In test_browser, would it be a good test if mock_pyclbr_tree was created as `mock_pyclbr_tree = {'C0': C0, 'f0': f0}` instead of `mock_pyclbr_tree = {'f0': f0, 'C0': C0}`? The reason that I'm asking is that, under 2.7 and 3.3, this dictionary does not retain the insertion order, but changes it from (C0, f0) to (f0, C0). Or did you just want a test that checks that the line numbers are still in order when the code is returned from transform_children? ---------- nosy: +csabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 20:41:35 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Dec 2017 01:41:35 +0000 Subject: [issue30722] Tools/demo/redemo.py broken In-Reply-To: <1498035463.93.0.0897725262949.issue30722@psf.upfronthosting.co.za> Message-ID: <1514166095.71.0.213398074469.issue30722@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The news message is verbose but looks misleading to me. There is nothing invalid with usages like getattr(re, 'DOTALL'). It is the same as re.DOTALL, and using enums haven't changed this. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 21:51:54 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 25 Dec 2017 02:51:54 +0000 Subject: [issue32408] Performance regression in urllib.proxy_bypass_environment In-Reply-To: <1513923244.99.0.213398074469.issue32408@psf.upfronthosting.co.za> Message-ID: <1514170314.01.0.213398074469.issue32408@psf.upfronthosting.co.za> Xiang Zhang added the comment: Okay, the real performance is: time python2 -c 'import urllib; urllib.proxy_bypass_environment("1.1.1.1")' real 0m0.661s user 0m0.654s sys 0m0.007s I compile it with a wrong option with the specific GCC version. But still really slow comparing to before. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 22:57:57 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 25 Dec 2017 03:57:57 +0000 Subject: [issue32411] Idlelib.browser: stop sorting dicts created by pyclbr In-Reply-To: <1513996869.13.0.213398074469.issue32411@psf.upfronthosting.co.za> Message-ID: <1514174277.84.0.213398074469.issue32411@psf.upfronthosting.co.za> Terry J. Reedy added the comment: (f0, C0) is the correct insertion and line number order for the dict that would be returned by pyclbr for a fleshed-out file. After 'sorted' is removed, the mock must imitate that. One could argue that previously, and even now for 3.6, the initial insertion order should be 'wrong' to test that format_children sorts the return list. But what is the chance that there will ever be an alternate 3.6 (or even later) implementation that runs tkinter and therefore might run IDLE but has a dict that does not preserve insert order? I probably should not worry about the dict insert order guarantee being rescinded in a future version. Maybe instead I should just add a comment that transform_children depends on iteration order being insert order == line-number order. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 24 23:37:30 2017 From: report at bugs.python.org (Nitish) Date: Mon, 25 Dec 2017 04:37:30 +0000 Subject: [issue32421] Keeping an exception in cache can segfault the interpreter In-Reply-To: <1514082423.32.0.213398074469.issue32421@psf.upfronthosting.co.za> Message-ID: <1514176650.66.0.213398074469.issue32421@psf.upfronthosting.co.za> Nitish added the comment: What is six.reraise in except block? ---------- nosy: +nitishch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 00:26:16 2017 From: report at bugs.python.org (Yonatan Zunger) Date: Mon, 25 Dec 2017 05:26:16 +0000 Subject: [issue32421] Keeping an exception in cache can segfault the interpreter In-Reply-To: <1514176650.66.0.213398074469.issue32421@psf.upfronthosting.co.za> Message-ID: Yonatan Zunger added the comment: It's just a clean version of reraise. Part of the six (Py2/Py3 compatibility) library, but pretty useful on its own anyway. On Sun, Dec 24, 2017 at 8:37 PM, Nitish wrote: > > Nitish added the comment: > > What is six.reraise in except block? > > ---------- > nosy: +nitishch > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 01:53:12 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 25 Dec 2017 06:53:12 +0000 Subject: [issue32422] Reduce lru_cache memory overhead. In-Reply-To: <1514092742.06.0.213398074469.issue32422@psf.upfronthosting.co.za> Message-ID: <1514184792.46.0.213398074469.issue32422@psf.upfronthosting.co.za> INADA Naoki added the comment: > Please stop revising every single thing you look at. The traditional design of LRU caches used doubly linked lists for a reason. In particular, when there is a high hit rate, the links can be updated without churning the underlying dictionary. I don't proposing removing doubly linked list; OrderedDict uses doubly-linked list too, and I found no problem for most-hit scenario. On the other hand, I found problem of OrderedDict for most mis hit scenario. Now I think lru_cache's implementation is better OrderedDict. PyODict is slower than lru_cache's dict + linked list because of historical reason (compatibility with pure Python implemantation.) So I stop trying to remove lru_cache's own implementation. I'll try to reduce overhead of lru_cache, by removing GC header from link node. ---------- title: Make OrderedDict can be used for LRU from C -> Reduce lru_cache memory overhead. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 02:40:29 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Dec 2017 07:40:29 +0000 Subject: [issue29084] C API of OrderedDict In-Reply-To: <1482847157.79.0.799208161515.issue29084@psf.upfronthosting.co.za> Message-ID: <1514187629.68.0.213398074469.issue29084@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset d62b7412c18bd5dfa6d7346abfaf8a922818e6db by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6': bpo-29084: Exclude C API for OrderedDict from the limited C API. (GH-4900) (#5007) https://github.com/python/cpython/commit/d62b7412c18bd5dfa6d7346abfaf8a922818e6db ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 02:41:02 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Dec 2017 07:41:02 +0000 Subject: [issue29084] C API of OrderedDict In-Reply-To: <1482847157.79.0.799208161515.issue29084@psf.upfronthosting.co.za> Message-ID: <1514187662.7.0.213398074469.issue29084@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 02:55:25 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 25 Dec 2017 07:55:25 +0000 Subject: [issue32422] Reduce lru_cache memory overhead. In-Reply-To: <1514092742.06.0.213398074469.issue32422@psf.upfronthosting.co.za> Message-ID: <1514188525.6.0.213398074469.issue32422@psf.upfronthosting.co.za> Change by INADA Naoki : ---------- keywords: +patch pull_requests: +4897 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 02:56:15 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 25 Dec 2017 07:56:15 +0000 Subject: [issue32422] Reduce lru_cache memory overhead. In-Reply-To: <1514092742.06.0.213398074469.issue32422@psf.upfronthosting.co.za> Message-ID: <1514188575.75.0.213398074469.issue32422@psf.upfronthosting.co.za> INADA Naoki added the comment: PR-5008 benchmark: $ ./python -m perf compare_to master.json patched2.json -G Faster (9): - gc(1000000): 98.3 ms +- 0.3 ms -> 29.9 ms +- 0.4 ms: 3.29x faster (-70%) - gc(100000): 11.7 ms +- 0.0 ms -> 3.71 ms +- 0.03 ms: 3.14x faster (-68%) - gc(10000): 1.48 ms +- 0.02 ms -> 940 us +- 6 us: 1.57x faster (-36%) - lru_10_100: 149 ns +- 6 ns -> 138 ns +- 1 ns: 1.08x faster (-8%) - lru_100_100: 115 ns +- 6 ns -> 108 ns +- 1 ns: 1.07x faster (-6%) - lru_1000_1000: 134 ns +- 6 ns -> 127 ns +- 1 ns: 1.05x faster (-5%) - lru_100_1000: 114 ns +- 5 ns -> 108 ns +- 1 ns: 1.05x faster (-5%) - lru_1000_100: 217 ns +- 6 ns -> 212 ns +- 4 ns: 1.03x faster (-2%) - lru_10000_1000: 225 ns +- 4 ns -> 221 ns +- 5 ns: 1.02x faster (-2%) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 03:58:42 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Dec 2017 08:58:42 +0000 Subject: [issue32422] Reduce lru_cache memory overhead. In-Reply-To: <1514092742.06.0.213398074469.issue32422@psf.upfronthosting.co.za> Message-ID: <1514192322.53.0.213398074469.issue32422@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 03:59:02 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Dec 2017 08:59:02 +0000 Subject: [issue32422] Reduce lru_cache memory overhead. In-Reply-To: <1514092742.06.0.213398074469.issue32422@psf.upfronthosting.co.za> Message-ID: <1514192342.0.0.213398074469.issue32422@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- type: -> resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 04:30:41 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Dec 2017 09:30:41 +0000 Subject: [issue31983] Officially add Py_SETREF and Py_XSETREF In-Reply-To: <1510158281.4.0.213398074469.issue31983@psf.upfronthosting.co.za> Message-ID: <1514194241.16.0.213398074469.issue31983@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Since there are objections, it is too early to make this a public C API. ---------- resolution: -> rejected stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 04:32:28 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Dec 2017 09:32:28 +0000 Subject: [issue31988] Saving bytearray to binary plist file doesn't work In-Reply-To: <1510183221.28.0.213398074469.issue31988@psf.upfronthosting.co.za> Message-ID: <1514194348.38.0.213398074469.issue31988@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed in issue32072. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Issues with binary plists _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 05:21:10 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 25 Dec 2017 10:21:10 +0000 Subject: [issue32335] Failed Python build on Fedora 27 In-Reply-To: <1513358854.45.0.213398074469.issue32335@psf.upfronthosting.co.za> Message-ID: <1514197270.75.0.213398074469.issue32335@psf.upfronthosting.co.za> Change by Xavier de Gaye : ---------- resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 05:47:57 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Dec 2017 10:47:57 +0000 Subject: [issue32372] Optimize out __debug__ at the AST level In-Reply-To: <1513692705.53.0.213398074469.issue32372@psf.upfronthosting.co.za> Message-ID: <1514198877.54.0.213398074469.issue32372@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 3dfbaf51f0d90646e0414ddbd3b513ee8e5ffe9b by Serhiy Storchaka in branch 'master': bpo-32372: Move __debug__ optimization to the AST level. (#4925) https://github.com/python/cpython/commit/3dfbaf51f0d90646e0414ddbd3b513ee8e5ffe9b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 05:48:57 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Dec 2017 10:48:57 +0000 Subject: [issue32372] Optimize out __debug__ at the AST level In-Reply-To: <1513692705.53.0.213398074469.issue32372@psf.upfronthosting.co.za> Message-ID: <1514198937.59.0.213398074469.issue32372@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 07:23:25 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 25 Dec 2017 12:23:25 +0000 Subject: [issue32402] Coverity: CID 1426868/1426867: Null pointer dereferences in textio.c In-Reply-To: <1513889402.22.0.213398074469.issue32402@psf.upfronthosting.co.za> Message-ID: <1514204605.88.0.213398074469.issue32402@psf.upfronthosting.co.za> Change by INADA Naoki : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 07:44:02 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 25 Dec 2017 12:44:02 +0000 Subject: [issue31721] assertion failure in FutureObj_finalize() after setting _log_traceback to True In-Reply-To: <1507385964.19.0.213398074469.issue31721@psf.upfronthosting.co.za> Message-ID: <1514205842.92.0.213398074469.issue31721@psf.upfronthosting.co.za> Andrew Svetlov added the comment: _log_traceback is a private property and asyncio implementation detail, you should never touch it. ---------- nosy: +asvetlov resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 10:48:17 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 25 Dec 2017 15:48:17 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() In-Reply-To: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> Message-ID: <1514216897.66.0.213398074469.issue32363@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 0cf16f9ea014b17d398ee3971d4976c698533318 by Yury Selivanov in branch 'master': bpo-32363: Disable Task.set_exception() and Task.set_result() (#4923) https://github.com/python/cpython/commit/0cf16f9ea014b17d398ee3971d4976c698533318 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 10:48:39 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 25 Dec 2017 15:48:39 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() In-Reply-To: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> Message-ID: <1514216919.69.0.213398074469.issue32363@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 11:08:39 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 25 Dec 2017 16:08:39 +0000 Subject: [issue31721] assertion failure in FutureObj_finalize() after setting _log_traceback to True In-Reply-To: <1507385964.19.0.213398074469.issue31721@psf.upfronthosting.co.za> Message-ID: <1514218119.12.0.213398074469.issue31721@psf.upfronthosting.co.za> Yury Selivanov added the comment: > _log_traceback is a private property and asyncio implementation detail, you should never touch it. But still, we shouldn't let Python crash if someone sets it. I'll make a PR to fix this the way Oren proposed. Andrew, let's discuss later with what we want to replace _log_traceback. I don't like that it's a semi-public thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 11:11:22 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 25 Dec 2017 16:11:22 +0000 Subject: [issue31721] assertion failure in FutureObj_finalize() after setting _log_traceback to True In-Reply-To: <1507385964.19.0.213398074469.issue31721@psf.upfronthosting.co.za> Message-ID: <1514218282.75.0.213398074469.issue31721@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- pull_requests: +4898 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 11:11:43 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 25 Dec 2017 16:11:43 +0000 Subject: [issue31721] assertion failure in FutureObj_finalize() after setting _log_traceback to True In-Reply-To: <1507385964.19.0.213398074469.issue31721@psf.upfronthosting.co.za> Message-ID: <1514218303.73.0.213398074469.issue31721@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: wont fix -> stage: resolved -> patch review status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 11:57:34 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Dec 2017 16:57:34 +0000 Subject: [issue28307] Accelerate 'string' % (value, ...) by using formatted string literals In-Reply-To: <1475138996.48.0.897803092987.issue28307@psf.upfronthosting.co.za> Message-ID: <1514221054.59.0.213398074469.issue28307@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 11:57:46 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 25 Dec 2017 16:57:46 +0000 Subject: [issue28308] Accelerate 'string'.format(value, ...) by using formatted string literals In-Reply-To: <1475139004.07.0.645331102167.issue28308@psf.upfronthosting.co.za> Message-ID: <1514221066.25.0.213398074469.issue28308@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 12:03:26 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 25 Dec 2017 17:03:26 +0000 Subject: [issue32422] Reduce lru_cache memory overhead. In-Reply-To: <1514092742.06.0.213398074469.issue32422@psf.upfronthosting.co.za> Message-ID: <1514221406.35.0.213398074469.issue32422@psf.upfronthosting.co.za> INADA Naoki added the comment: New changeset 3070b71e5eedf62e49b8e7dedab75742a5f67ece by INADA Naoki in branch 'master': bpo-32422: Reduce lru_cache memory usage (GH-5008) https://github.com/python/cpython/commit/3070b71e5eedf62e49b8e7dedab75742a5f67ece ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 12:03:57 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 25 Dec 2017 17:03:57 +0000 Subject: [issue32422] Reduce lru_cache memory overhead. In-Reply-To: <1514092742.06.0.213398074469.issue32422@psf.upfronthosting.co.za> Message-ID: <1514221437.57.0.213398074469.issue32422@psf.upfronthosting.co.za> Change by INADA Naoki : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 13:10:03 2017 From: report at bugs.python.org (Bassem Girgis) Date: Mon, 25 Dec 2017 18:10:03 +0000 Subject: [issue32419] Add unittest support for pyc projects In-Reply-To: <1514134385.74.0.912454111764.issue32419@psf.upfronthosting.co.za> Message-ID: Bassem Girgis added the comment: Hi Eric, Yes it is like David said. For the projects you don't distribute the code with the deployment package, you end up distributing only pyc files. As of how to get these files, you can make use of py_compile or compileall modules. For compileall, however, you have to pass the legacy flag to avoid the __pycache__ standard. What I found strange in the unittest code while trying to resolve this issue is that, it is relying on hardcoded searches for __init__.py to find if a module is loadable. I would have imagined that there is a standard why to answer this question. Best regards, Bassem Bassem Girgis, PhD Email: brgirgis at gmail.com On Sun, Dec 24, 2017 at 10:53 AM, Serhiy Storchaka wrote: > > Change by Serhiy Storchaka : > > > ---------- > stage: -> test needed > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 13:14:35 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 25 Dec 2017 18:14:35 +0000 Subject: [issue32419] Add unittest support for pyc projects In-Reply-To: <1514064360.62.0.213398074469.issue32419@psf.upfronthosting.co.za> Message-ID: <1514225675.1.0.213398074469.issue32419@psf.upfronthosting.co.za> R. David Murray added the comment: There may be now, but I don't think there was when unittest was written. Also, if someone decided to use namespace packages for tests for some reason, the current check would also probably fail, so it may be worth looking for (or creating if needed) a standard way to check via importlib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 16:16:13 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 25 Dec 2017 21:16:13 +0000 Subject: [issue31721] assertion failure in FutureObj_finalize() after setting _log_traceback to True In-Reply-To: <1507385964.19.0.213398074469.issue31721@psf.upfronthosting.co.za> Message-ID: <1514236573.13.0.213398074469.issue31721@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset e0aef4f3cd339a405d2a7fbd35a50afa64834f84 by Yury Selivanov in branch 'master': bpo-31721: Allow Future._log_traceback to only be set to False (#5009) https://github.com/python/cpython/commit/e0aef4f3cd339a405d2a7fbd35a50afa64834f84 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 16:16:59 2017 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 25 Dec 2017 21:16:59 +0000 Subject: [issue31721] assertion failure in FutureObj_finalize() after setting _log_traceback to True In-Reply-To: <1507385964.19.0.213398074469.issue31721@psf.upfronthosting.co.za> Message-ID: <1514236619.9.0.213398074469.issue31721@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 16:18:28 2017 From: report at bugs.python.org (Joseph Mitzen) Date: Mon, 25 Dec 2017 21:18:28 +0000 Subject: [issue29504] blake2: compile error with -march=bdver2 In-Reply-To: <1486574963.2.0.72017577066.issue29504@psf.upfronthosting.co.za> Message-ID: <1514236708.9.0.213398074469.issue29504@psf.upfronthosting.co.za> Joseph Mitzen added the comment: Is this ever going to get merged? The gentoo bug report link includes a patch that simply removes the nested comments, which is all that is needed to get the code to compile properly on Bulldozer processors. There's no "manual massaging" or anything else necessary to fix the bug. I've tested it out and it works. ---------- nosy: +Joseph Mitzen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 16:21:31 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 25 Dec 2017 21:21:31 +0000 Subject: [issue26133] asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za> Message-ID: <1514236891.01.0.213398074469.issue26133@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- pull_requests: +4899 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 16:42:57 2017 From: report at bugs.python.org (Julien Palard) Date: Mon, 25 Dec 2017 21:42:57 +0000 Subject: [issue31584] Documentation Language mixed up In-Reply-To: <1506402847.94.0.987670636111.issue31584@psf.upfronthosting.co.za> Message-ID: <1514238177.53.0.213398074469.issue31584@psf.upfronthosting.co.za> Julien Palard added the comment: https://github.com/python/docsbuild-scripts/pull/36 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 17:37:11 2017 From: report at bugs.python.org (Alessandro Piccione) Date: Mon, 25 Dec 2017 22:37:11 +0000 Subject: [issue32426] Tkinter.ttk Widget does not define wich option exists to set the cursor Message-ID: <1514241431.48.0.213398074469.issue32426@psf.upfronthosting.co.za> New submission from Alessandro Piccione : In the documentation of Tkinter.ttk Widget it is defined the "cursor" parameter. It is: cursor Specifies the mouse cursor to be used for the widget. If set to the empty string (the default), the cursor is inherited for the parent widget. There is not ANY way to knok wich value this parameter accept. Searching "cursor" in the documentation does not find nothing, apart database cursor and this page (Tkinter.ttk.Widget). Thanks, Alessandro ---------- components: Tkinter messages: 309045 nosy: alex.75 priority: normal severity: normal status: open title: Tkinter.ttk Widget does not define wich option exists to set the cursor type: resource usage versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 18:49:51 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 25 Dec 2017 23:49:51 +0000 Subject: [issue32345] EIO from write() is only fatal if print() contains a newline In-Reply-To: <1513416512.67.0.213398074469.issue32345@psf.upfronthosting.co.za> Message-ID: <1514245791.33.0.213398074469.issue32345@psf.upfronthosting.co.za> Change by STINNER Victor : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 18:51:50 2017 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 25 Dec 2017 23:51:50 +0000 Subject: [issue32145] Wrong ExitStack Callback recipe In-Reply-To: <1511771653.67.0.213398074469.issue32145@psf.upfronthosting.co.za> Message-ID: <1514245910.29.0.213398074469.issue32145@psf.upfronthosting.co.za> Nick Coghlan added the comment: Regarding super().__init__(): I added ExitStack to contextlib2 first, so I was thinking in the Py2/3 compatible subset when I wrote the original docs. We can freely change that for the standard library recipes. Regarding the "how to create a copy" question, while I don't especially like the notion of adding a dedicated semi-public copy method, I think you're right that it may be the best option: 1. Full pickle/copy module support doesn't make sense, since exit stacks are inherently stateful - you can't save them to use later, since you'd need to repeat the setup steps as well, but we don't keep track of what the setup steps actually *were*. 2. `stack.pop_all()` was designed such that if you clone the stack, you ensure that the original stack *won't* call the cleanup callbacks any more. If we were to add a fully public `stack.copy()` method (or `copy.copy(stack)` support via `stack.__copy__()`), then we'd lose that deliberate nudge, and put folks more at risk of "double-free" style bugs, where they run the cleanup functions multiple times. 3. A for-subclasses-only "self._clone()" API could work as follows: def _clone(self, new_instance=None): if new_instance is None: new_instance = type(self)() # Clone state here return new_instance Then subclasses could override *just* the instance creation part by doing: def _clone(self): return super()._clone(self._make_instance()) While also being free to add their own additional state copying code if needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 18:56:17 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Mon, 25 Dec 2017 23:56:17 +0000 Subject: [issue32411] Idlelib.browser: stop sorting dicts created by pyclbr In-Reply-To: <1513996869.13.0.213398074469.issue32411@psf.upfronthosting.co.za> Message-ID: <1514246177.74.0.213398074469.issue32411@psf.upfronthosting.co.za> Change by Cheryl Sabella : ---------- keywords: +patch pull_requests: +4900 stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 18:58:24 2017 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 25 Dec 2017 23:58:24 +0000 Subject: [issue24991] Define instance mutability explicitly on type objects? In-Reply-To: <1441260483.41.0.785006760825.issue24991@psf.upfronthosting.co.za> Message-ID: <1514246304.17.0.213398074469.issue24991@psf.upfronthosting.co.za> Nick Coghlan added the comment: Declaring "I intend for instances of this class to be immutable" isn't a fuzzy concept - it's in the same vein as other type hints, like "I intend for this to be a string". The part that's fuzzy is how well Python actually enforces that declaration, and hence the degree to which you can actually rely on it at runtime. In most cases, detecting and reporting *violations* of that intent would be in the realm of typecheckers rather than the language interpeter, but there'd be cases where the interpreter itself could make useful inferences from such a declaration (for example, by prohibiting conventional mutation operations, the way "frozen=True" does for data classes). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 19:02:15 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Tue, 26 Dec 2017 00:02:15 +0000 Subject: [issue32411] Idlelib.browser: stop sorting dicts created by pyclbr In-Reply-To: <1513996869.13.0.213398074469.issue32411@psf.upfronthosting.co.za> Message-ID: <1514246535.99.0.213398074469.issue32411@psf.upfronthosting.co.za> Cheryl Sabella added the comment: Terry, I'm not sure if I phrased my initial question correctly. I've made a pull request to show you what I was thinking. What I had tried to show with the test case change is that, prior to the guarantee of insertion order on the dictionary, the check `eq(tcl, [C0, f0])` would have failed without the sort because `transform_children` would have returned `[f0, C0]`. With the sort in place or with the guarantee insertion order, this test doesn't fail. Thanks! ---------- stage: patch review -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 19:04:15 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Dec 2017 00:04:15 +0000 Subject: [issue28307] Accelerate 'string' % (value, ...) by using formatted string literals In-Reply-To: <1475138996.48.0.897803092987.issue28307@psf.upfronthosting.co.za> Message-ID: <1514246655.15.0.213398074469.issue28307@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +4901 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 19:07:35 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Dec 2017 00:07:35 +0000 Subject: [issue28307] Accelerate 'string' % (value, ...) by using formatted string literals In-Reply-To: <1475138996.48.0.897803092987.issue28307@psf.upfronthosting.co.za> Message-ID: <1514246855.57.0.213398074469.issue28307@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PR 5012 implements transformation simple format strings containing only %s, %r and %a into f-strings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 19:19:41 2017 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 Dec 2017 00:19:41 +0000 Subject: [issue32324] [Security] "python3 directory" inserts "directory" at sys.path[0] even in isolated mode In-Reply-To: <1513267755.86.0.213398074469.issue32324@psf.upfronthosting.co.za> Message-ID: <1514247581.31.0.213398074469.issue32324@psf.upfronthosting.co.za> Nick Coghlan added the comment: When executing a sys.path entry, you're executing that *entire* entry (whether it's a directory or zipfile). This isn't a bug, and it isn't in conflict with the assurances offered by isolated mode (it would only be a problem if running "~/code/mydirectory" added "~/code" to sys.path). ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 19:22:37 2017 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 Dec 2017 00:22:37 +0000 Subject: [issue32324] [Security] "python3 directory" inserts "directory" at sys.path[0] even in isolated mode In-Reply-To: <1513267755.86.0.213398074469.issue32324@psf.upfronthosting.co.za> Message-ID: <1514247756.99.0.213398074469.issue32324@psf.upfronthosting.co.za> Nick Coghlan added the comment: (However, the behaviour Steve is describing suggests that sys.path[0] initialisation may have problems on Windows that the test suite isn't picking up - "-I" should *not* add the script directory to the path, and directory execution should always add an absolute path, not a relative one) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 19:26:21 2017 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 Dec 2017 00:26:21 +0000 Subject: [issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL In-Reply-To: <1513694438.46.0.213398074469.issue32374@psf.upfronthosting.co.za> Message-ID: <1514247981.89.0.213398074469.issue32374@psf.upfronthosting.co.za> Nick Coghlan added the comment: Yep, the requirement for supporting multiple interpreters is just that you either avoid relying on C global state entirely, or else correctly synchronise access to it. Multi-phase initialisation just provides a few nudges in the direction of doing that more consistently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 19:31:21 2017 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 26 Dec 2017 00:31:21 +0000 Subject: [issue32030] PEP 432: Rewrite Py_Main() In-Reply-To: <1510709424.02.0.213398074469.issue32030@psf.upfronthosting.co.za> Message-ID: <1514248281.84.0.213398074469.issue32030@psf.upfronthosting.co.za> Nick Coghlan added the comment: _PyCoreConfig.ignore_environment was part of the initial PEP 432 implementation that I wrote. It's that due to the design goal that once the refactoring is complete, an embedding application should be able to control *all* the settings through the config structs, without *ever* touching the global variables directly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 25 23:15:51 2017 From: report at bugs.python.org (Srinivas Reddy T) Date: Tue, 26 Dec 2017 04:15:51 +0000 Subject: [issue32360] Save OrderedDict imports in various stdlibs. In-Reply-To: <1513591210.99.0.213398074469.issue32360@psf.upfronthosting.co.za> Message-ID: <1514261751.55.0.213398074469.issue32360@psf.upfronthosting.co.za> Change by Srinivas Reddy T : ---------- pull_requests: +4902 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 00:00:56 2017 From: report at bugs.python.org (Srinivas Reddy T) Date: Tue, 26 Dec 2017 05:00:56 +0000 Subject: [issue32338] Save OrderedDict import in re In-Reply-To: <1513362099.11.0.213398074469.issue32338@psf.upfronthosting.co.za> Message-ID: <1514264456.45.0.213398074469.issue32338@psf.upfronthosting.co.za> Change by Srinivas Reddy T : ---------- pull_requests: +4903 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 04:53:45 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 26 Dec 2017 09:53:45 +0000 Subject: [issue26133] asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za> Message-ID: <1514282025.74.0.213398074469.issue26133@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset a8f4e15f3d33084862ddd3a7d58cd00034e94f16 by Andrew Svetlov in branch 'master': bpo-26133: Fix typos (#5010) https://github.com/python/cpython/commit/a8f4e15f3d33084862ddd3a7d58cd00034e94f16 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 04:53:58 2017 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Dec 2017 09:53:58 +0000 Subject: [issue26133] asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za> Message-ID: <1514282038.05.0.213398074469.issue26133@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4904 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 05:14:59 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Dec 2017 10:14:59 +0000 Subject: [issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub() In-Reply-To: <1513189718.03.0.213398074469.issue32308@psf.upfronthosting.co.za> Message-ID: <1514283299.18.0.213398074469.issue32308@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could anybody please make a review of at least the documentation part? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 05:29:35 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 26 Dec 2017 10:29:35 +0000 Subject: [issue26133] asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly In-Reply-To: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za> Message-ID: <1514284175.85.0.213398074469.issue26133@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset 32518b439b9590cce0ef0639e558dc1ce2e152bb by Andrew Svetlov (Miss Islington (bot)) in branch '3.6': bpo-26133: Fix typos (GH-5010) (#5014) https://github.com/python/cpython/commit/32518b439b9590cce0ef0639e558dc1ce2e152bb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 05:30:43 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Dec 2017 10:30:43 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1514284243.16.0.213398074469.issue32259@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 13a6c098c215921e35004f9d3a9b70f601e56500 by Serhiy Storchaka in branch 'master': bpo-32259: Make a TypeError message when unpack non-iterable more specific. (#4903) https://github.com/python/cpython/commit/13a6c098c215921e35004f9d3a9b70f601e56500 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 05:32:10 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Dec 2017 10:32:10 +0000 Subject: [issue32259] Misleading "not iterable" Error Message when generator return a "simple" type, and a tuple is expected In-Reply-To: <1512821432.36.0.213398074469.issue32259@psf.upfronthosting.co.za> Message-ID: <1514284330.29.0.213398074469.issue32259@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 05:47:13 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Dec 2017 10:47:13 +0000 Subject: [issue32196] Rewrite plistlib with functional style In-Reply-To: <1512156516.89.0.213398074469.issue32196@psf.upfronthosting.co.za> Message-ID: <1514285233.74.0.213398074469.issue32196@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have made this PR because functional style looks to me more for this kind of tasks. For every serialization or deseralization we have a distinct set of functions with common state. The state can be passes between functions as attributes of a one-time object or as non-local variables. The latter looks syntactically cleaner to me and, as a side effect, is faster. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 06:03:38 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Dec 2017 11:03:38 +0000 Subject: [issue32072] Issues with binary plists In-Reply-To: <1511031976.48.0.213398074469.issue32072@psf.upfronthosting.co.za> Message-ID: <1514286218.06.0.213398074469.issue32072@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For example: a = [] for i in range(22): a = [a, a] b = plistlib.dumps(a, fmt=plistlib.FMT_BINARY) The result is 130 bytes long on patched plistlib. But plistlib.dumps(b) will expand to a structure consuming almost a gigabyte of memory on unpatched plistlib. Increasing the level of nesting by one will duplicate memory consumption, so it is easy to consume all available memory on any computer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 06:25:14 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 26 Dec 2017 11:25:14 +0000 Subject: [issue32337] Dict order is now guaranteed, so add tests and doc for it Message-ID: <1514287514.34.0.213398074469.issue32337@psf.upfronthosting.co.za> New submission from INADA Naoki : FYI, Builtin dict is tested for ordering already: https://github.com/python/cpython/blob/13a6c098c215921e35004f9d3a9b70f601e56500/Lib/test/test_ordered_dict.py#L646-L662 ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 06:26:31 2017 From: report at bugs.python.org (Julien Palard) Date: Tue, 26 Dec 2017 11:26:31 +0000 Subject: [issue32421] Keeping an exception in cache can segfault the interpreter In-Reply-To: <1514082423.32.0.213398074469.issue32421@psf.upfronthosting.co.za> Message-ID: <1514287591.64.0.213398074469.issue32421@psf.upfronthosting.co.za> Julien Palard added the comment: Tested with: @memoize() def foo(x): raise Exception("From foo") for _ ? range(5): try: foo(42) except Exception as err: print(err) using a python 3.5.4, 3.6.4, and master(13a6c09), and was unable to reproduce it, which version of Python are you using? How are you reproducing it? ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 06:48:18 2017 From: report at bugs.python.org (Yonatan Zunger) Date: Tue, 26 Dec 2017 11:48:18 +0000 Subject: [issue32421] Keeping an exception in cache can segfault the interpreter In-Reply-To: <1514287591.64.0.213398074469.issue32421@psf.upfronthosting.co.za> Message-ID: Yonatan Zunger added the comment: 3.6.2. But Nick Coghlan pointed out elsewhere that the underlying issue is more likely to be one of the other objects being pinned in-memory because of the traceback, so the exception may actually be just an incidental thing. I'm going to have to work on a better minimal repro case -- this particular example had both a subprocess.Popen open at the time and a message-channel object that holds some os.pipes, so there are all sorts of fun things that may be causing the trouble. I'll update the bug when I have a chance to do that and narrow it down a bit more. On Tue, Dec 26, 2017 at 3:26 AM, Julien Palard wrote: > > Julien Palard added the comment: > > Tested with: > > @memoize() > def foo(x): > raise Exception("From foo") > > > for _ ? range(5): > try: > foo(42) > except Exception as err: > print(err) > > using a python 3.5.4, 3.6.4, and master(13a6c09), and was unable to > reproduce it, which version of Python are you using? How are you > reproducing it? > > ---------- > nosy: +mdk > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 07:43:46 2017 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 26 Dec 2017 12:43:46 +0000 Subject: [issue32427] Rename and expose dataclasses._MISSING Message-ID: <1514292226.17.0.213398074469.issue32427@psf.upfronthosting.co.za> New submission from Eric V. Smith : There are occasions where you want to know the missing value, such as introspection and in cases like: Field(default=a if a is not None else _MISSING). I'll rename _MISSING to MISSING. ---------- assignee: eric.smith components: Library (Lib) messages: 309063 nosy: eric.smith priority: normal severity: normal status: open title: Rename and expose dataclasses._MISSING versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 11:58:39 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 26 Dec 2017 16:58:39 +0000 Subject: [issue32145] Wrong ExitStack Callback recipe In-Reply-To: <1514245910.29.0.213398074469.issue32145@psf.upfronthosting.co.za> Message-ID: <57C412E0-BCE9-4721-91DE-ABAD44040E2F@python.org> Barry A. Warsaw added the comment: On Dec 25, 2017, at 18:51, Nick Coghlan wrote: > > 3. A for-subclasses-only "self._clone()" API could work as follows: > > def _clone(self, new_instance=None): > if new_instance is None: > new_instance = type(self)() > # Clone state here > return new_instance > > Then subclasses could override *just* the instance creation part by doing: > > def _clone(self): > return super()._clone(self._make_instance()) > > While also being free to add their own additional state copying code if needed. So _make_instance() wouldn?t be part of ExitStack?s API, but subclasses could implement it (and name it whatever they want of course)? I?m not sure _clone() is the right name here since that implies to me state copy as well, and I totally agree with your other points. That?s why I originally suggested _make_instance() would be the name and API in the base class. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 13:34:08 2017 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 26 Dec 2017 18:34:08 +0000 Subject: [issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass Message-ID: <1514313248.8.0.213398074469.issue32428@psf.upfronthosting.co.za> New submission from Eric V. Smith : For this class: @dataclass class C: x: int = 0 y = 0 Generate a TypeError. 'y' is not a field (as defined by @dataclass). It should either be a regular field (by giving it a type annotation) or a ClassVar field. ---------- assignee: eric.smith components: Library (Lib) messages: 309065 nosy: eric.smith priority: normal severity: normal status: open title: dataclasses: make it an error to have initialized non-fields in a dataclass type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 17:10:38 2017 From: report at bugs.python.org (Julien Palard) Date: Tue, 26 Dec 2017 22:10:38 +0000 Subject: [issue32429] Outdated Modules/Setup warning is invisible Message-ID: <1514326238.69.0.213398074469.issue32429@psf.upfronthosting.co.za> New submission from Julien Palard : The devguide advise to run `make -j`, why not, but in any cases between `make -j4` and `make -j` the warning: ----------------------------------------------- Modules/Setup.dist is newer than Modules/Setup; check to make sure you have all the updates you need in your Modules/Setup file. Usually, copying Modules/Setup.dist to Modules/Setup will work. ----------------------------------------------- is invisible (gets on screen first, and get kicked real quick by the compilation lines). This got me once, and I'm not alone: https://bugs.python.org/issue32335 (And I suspect we're more than just two). I propose to make this stop the compilation, proposing two cases: - You modified the file? Touch it so it gets seen as up to date by makefile - You didn't modified it? Copy Modules/Setup.dist to Modules/Setup Something like: $ make ----------------------------------------------- Modules/Setup.dist is newer than Modules/Setup; check to make sure you have all the updates you need in your Modules/Setup file. Usually, copying Modules/Setup.dist to Modules/Setup will work. Or if you want to keep your modifications, touch Modules/Setup to skip this warning. ----------------------------------------------- Makefile:703: recipe for target 'Modules/Setup' failed make: *** [Modules/Setup] Error 1 ---------- assignee: mdk components: Build messages: 309066 nosy: mdk, xdegaye priority: low severity: normal status: open title: Outdated Modules/Setup warning is invisible type: enhancement versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 17:12:35 2017 From: report at bugs.python.org (Julien Palard) Date: Tue, 26 Dec 2017 22:12:35 +0000 Subject: [issue32429] Outdated Modules/Setup warning is invisible In-Reply-To: <1514326238.69.0.213398074469.issue32429@psf.upfronthosting.co.za> Message-ID: <1514326355.42.0.213398074469.issue32429@psf.upfronthosting.co.za> Change by Julien Palard : ---------- keywords: +patch pull_requests: +4905 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 17:38:58 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Dec 2017 22:38:58 +0000 Subject: [issue32416] Refactor and add new tests for the f_lineno setter In-Reply-To: <1514049243.28.0.213398074469.issue32416@psf.upfronthosting.co.za> Message-ID: <1514327938.52.0.213398074469.issue32416@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 53f9135667226f33e049e327db60fb033afbd77a by Serhiy Storchaka in branch 'master': bpo-32416: Refactor tests for the f_lineno setter and add new tests. (#4991) https://github.com/python/cpython/commit/53f9135667226f33e049e327db60fb033afbd77a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 18:17:52 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 26 Dec 2017 23:17:52 +0000 Subject: [issue32429] Outdated Modules/Setup warning is invisible In-Reply-To: <1514326238.69.0.213398074469.issue32429@psf.upfronthosting.co.za> Message-ID: <1514330272.32.0.213398074469.issue32429@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'd really like it if we could get rid of the Setup/Setup.dist thing. It's a distraction to have to type `cp -f Modules/Setup.dist Modules/Setup` from time to time... even though I have never customized the Setup file. ---------- nosy: +barry, benjamin.peterson, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 18:19:04 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 26 Dec 2017 23:19:04 +0000 Subject: [issue32429] Outdated Modules/Setup warning is invisible In-Reply-To: <1514330272.32.0.213398074469.issue32429@psf.upfronthosting.co.za> Message-ID: <064F7A3D-A0B7-47E7-AB97-B3C1036887E3@python.org> Barry A. Warsaw added the comment: On Dec 26, 2017, at 18:17, Antoine Pitrou wrote: > > I'd really like it if we could get rid of the Setup/Setup.dist thing. It's a distraction to have to type `cp -f Modules/Setup.dist Modules/Setup` from time to time... even though I have never customized the Setup file. +1 - do you have any thoughts on that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 18:22:31 2017 From: report at bugs.python.org (Julien Palard) Date: Tue, 26 Dec 2017 23:22:31 +0000 Subject: [issue32429] Outdated Modules/Setup warning is invisible In-Reply-To: <1514326238.69.0.213398074469.issue32429@psf.upfronthosting.co.za> Message-ID: <1514330551.84.0.213398074469.issue32429@psf.upfronthosting.co.za> Julien Palard added the comment: Antoine: I may take a look at this too. Still, stopping in the Makefile looks a first trivial step toward not being screwed by it, removing it looks non trivial, will raise discussions, let's make it another issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 18:24:43 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Tue, 26 Dec 2017 23:24:43 +0000 Subject: [issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass In-Reply-To: <1514313248.8.0.213398074469.issue32428@psf.upfronthosting.co.za> Message-ID: <1514330683.6.0.213398074469.issue32428@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: A possible question here is should we give an error for any non-callable name in `__dict__` which is not in `__annotations__` or only for `Field`s? After some thinking I am actually leaning towards the first option. ---------- nosy: +gvanrossum, levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 18:24:44 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 26 Dec 2017 23:24:44 +0000 Subject: [issue32429] Outdated Modules/Setup warning is invisible In-Reply-To: <1514326238.69.0.213398074469.issue32429@psf.upfronthosting.co.za> Message-ID: <1514330684.71.0.213398074469.issue32429@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > +1 - do you have any thoughts on that? I think the current scheme may have been useful at a time where DVCS didn't exist. You would maintain an unversioned copy of Modules/Setup.dist in your work-tree. Nowadays you can fork a github repo and maintain your own branch with changes to a tracked file. I don't think Modules/Setup deserves special treatment compared to, say, setup.py or Makefile.pre.in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 18:27:33 2017 From: report at bugs.python.org (Julien Palard) Date: Tue, 26 Dec 2017 23:27:33 +0000 Subject: [issue32429] Outdated Modules/Setup warning is invisible In-Reply-To: <1514326238.69.0.213398074469.issue32429@psf.upfronthosting.co.za> Message-ID: <1514330853.61.0.213398074469.issue32429@psf.upfronthosting.co.za> Julien Palard added the comment: > maintain your own branch with changes to a tracked file Make sense for me, Xavier, would this fit your usage? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 18:54:54 2017 From: report at bugs.python.org (Julien Palard) Date: Tue, 26 Dec 2017 23:54:54 +0000 Subject: [issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514332494.1.0.213398074469.issue32424@psf.upfronthosting.co.za> Julien Palard added the comment: As the C implementation is already shadowing the Python implementation when available (last lines of Lib/xml/etree/ElementTree.py), using `.copy()` is already a bug magnet (works when the Python implem is used, does not work when shadowed by the C implem). So renaming the copy method to __copy__ in the python implementation looks good to me. Ultimately the Python implementation would require a __deepcopy__ too? ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 26 21:09:29 2017 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 27 Dec 2017 02:09:29 +0000 Subject: [issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass In-Reply-To: <1514313248.8.0.213398074469.issue32428@psf.upfronthosting.co.za> Message-ID: <1514340569.95.0.213398074469.issue32428@psf.upfronthosting.co.za> Eric V. Smith added the comment: I'm not sure I understand the distinction. You have to look through everything in `__dict__`, then exclude those things that are any type of field (so, real fields or pseudo-fields). Those are the things that are in `__annotations__`, anyway. The trick is what else to exclude. In this class: class C: x: int = 0 y = 0 def func(self): pass @staticmethod def staticmeth() : pass @classmethod def classmeth(cls) : pass @property def prop(self): pass These are the non-callables: print([k for k in C.__dict__ if not callable(getattr(C, k))]) ['__module__', '__annotations__', 'x', 'y', 'prop', '__dict__', '__weakref__', '__doc__'] How do we only pick out `y` and probably `prop`, and ignore the rest, without being overly fragile to new things being added? I guess ignoring dunders and things in `__annotations__`. Is that close enough? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 03:27:58 2017 From: report at bugs.python.org (Roger Wang) Date: Wed, 27 Dec 2017 08:27:58 +0000 Subject: [issue31639] http.server and SimpleHTTPServer hang after a few requests In-Reply-To: <1506701944.65.0.213398074469.issue31639@psf.upfronthosting.co.za> Message-ID: <1514363278.73.0.213398074469.issue31639@psf.upfronthosting.co.za> Change by Roger Wang : ---------- nosy: +rogerwang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 04:25:17 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Dec 2017 09:25:17 +0000 Subject: [issue32416] Refactor and add new tests for the f_lineno setter In-Reply-To: <1514049243.28.0.213398074469.issue32416@psf.upfronthosting.co.za> Message-ID: <1514366717.14.0.213398074469.issue32416@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4906 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 04:33:27 2017 From: report at bugs.python.org (Julien Palard) Date: Wed, 27 Dec 2017 09:33:27 +0000 Subject: [issue31639] http.server and SimpleHTTPServer hang after a few requests In-Reply-To: <1506701944.65.0.213398074469.issue31639@psf.upfronthosting.co.za> Message-ID: <1514367207.78.0.213398074469.issue31639@psf.upfronthosting.co.za> Julien Palard added the comment: I straced both chromium and Python during the issue and seen this: Chromium open a socket (port 55084), sends "GET /domain1.html" to it. Python accepts it, reads "GET /domain1.html", replies, OK Chromium closes socket on port 55084 Chromium opens three sockets: - port 55086 - port 55088 - port 55090 Python accepts a socket on port 55088 and read on it (blocking) Chromium writes "GET /domain2.html" on socket on port 55090 At this point we're stuck, three socket are opened, Python is reading on one of them, Chromium is writing on another. ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From mal at egenix.com Wed Dec 27 04:37:44 2017 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 27 Dec 2017 10:37:44 +0100 Subject: [issue32429] Outdated Modules/Setup warning is invisible In-Reply-To: <1514330684.71.0.213398074469.issue32429@psf.upfronthosting.co.za> References: <1514330684.71.0.213398074469.issue32429@psf.upfronthosting.co.za> Message-ID: <481bce7a-1746-1e58-f410-30e37f88a06f@egenix.com> On 27.12.2017 00:24, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> +1 - do you have any thoughts on that? > > I think the current scheme may have been useful at a time where DVCS didn't exist. You would maintain an unversioned copy of Modules/Setup.dist in your work-tree. Nowadays you can fork a github repo and maintain your own branch with changes to a tracked file. I don't think Modules/Setup deserves special treatment compared to, say, setup.py or Makefile.pre.in. The file is mostly meant for people using tar balls rather than checkouts to give them an easy way back to default settings after making changes to the Modules/Setup file. The same could be had by having Makefile.pre.in generate Setup.dist from Setup while booting into build mode, avoiding the need to sometimes create Modules/Setup manually. -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Wed Dec 27 04:37:56 2017 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 27 Dec 2017 09:37:56 +0000 Subject: [issue32429] Outdated Modules/Setup warning is invisible In-Reply-To: <1514330684.71.0.213398074469.issue32429@psf.upfronthosting.co.za> Message-ID: <481bce7a-1746-1e58-f410-30e37f88a06f@egenix.com> Marc-Andre Lemburg added the comment: On 27.12.2017 00:24, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> +1 - do you have any thoughts on that? > > I think the current scheme may have been useful at a time where DVCS didn't exist. You would maintain an unversioned copy of Modules/Setup.dist in your work-tree. Nowadays you can fork a github repo and maintain your own branch with changes to a tracked file. I don't think Modules/Setup deserves special treatment compared to, say, setup.py or Makefile.pre.in. The file is mostly meant for people using tar balls rather than checkouts to give them an easy way back to default settings after making changes to the Modules/Setup file. The same could be had by having Makefile.pre.in generate Setup.dist from Setup while booting into build mode, avoiding the need to sometimes create Modules/Setup manually. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 04:50:55 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Dec 2017 09:50:55 +0000 Subject: [issue32416] Refactor and add new tests for the f_lineno setter In-Reply-To: <1514049243.28.0.213398074469.issue32416@psf.upfronthosting.co.za> Message-ID: <1514368255.4.0.213398074469.issue32416@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- pull_requests: +4907 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 05:30:41 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 27 Dec 2017 10:30:41 +0000 Subject: [issue32429] Outdated Modules/Setup warning is invisible In-Reply-To: <1514326238.69.0.213398074469.issue32429@psf.upfronthosting.co.za> Message-ID: <1514370641.52.0.213398074469.issue32429@psf.upfronthosting.co.za> Xavier de Gaye added the comment: It seems that it is possible to keep the current behavior for those that want to customize the configuration of Modules/Setup.dist (knowing that they can just use Modules/Setup.local if they are only doing additions to the Setup configuration) and at the same time get rid of these warnings for those that never change Modules/Setup.dist. This could be done this way: * 'configure' does not create anymore Modules/Setup. * The 'Makefile' target of the Makefile uses now Modules/Setup.dist when Modules/Setup is missing. * A developer that wants to customize Modules/Setup.dist needs to copy (only once) manually Modules/Setup.dist to Modules/Setup and to modify this last file accordingly. She/he gets then the same warnings as those that are occuring currently and in that case it is useful to have the build abort upon such warnings as proposed in the current issue. If this proposal is acceptable then it should be implemented in another issue, I think. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 06:15:04 2017 From: report at bugs.python.org (Julien Palard) Date: Wed, 27 Dec 2017 11:15:04 +0000 Subject: [issue32430] Simplify Modules/Setup{,.dist,.local} Message-ID: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za> New submission from Julien Palard : Related to: https://bugs.python.org/issue32429 The bahavior of Modules/Setup{,.dist,.local} looks inherited from an old time: - A Setup.dist exist - ./configure copies it to Setup (cp $srcdir/Modules/Setup.dist Modules/Setup) - ./configure installs a dummy Modules/Setup.local file - One can add an optional things to Setup.local - One can have to modify Setup itself (to modify things) >From this point in time, Setup is newer than Setup.dist (as copied from it), the following can happen: - The Setup file is manually modified, it's still newer than Setup.dist, it does not change the situation - The Setup.dist file gets updated (via a git checkout or git merge), the Makefile detects it and warn the user: - Either the user modified the Setup file and don't want it to be overridden - Either the user didn't modified it and just want the updated version We don't know, so the Makefile is printing a warning telling he don't know and we have to fix the situation. First problem is: this warning is invisible due to the high load of Makefile prints, this is the issue https://bugs.python.org/issue32429. Proposed solutions are: - Xavier de Gaye: Use Setup.dist instead of Setup when Setup is missing (https://bugs.python.org/issue32429#msg309078) - Just keep a single versionned Setup file, let those who modify it use branches to commit their modifications Marc-Andre Lemburg noted that for those using a sources tarballs, in the single Setup file case, it's not nice for them to loose the original content of Setup when modifying it, and being able to do a `cp Modules/Setup.dist Modules/Setup` to restore it is nice. Personally I'll go for a single Setup file (No .dist, no .local, no copy), that one can modify and commit, delegating the pain of merging to git, as I prefer simple solutions. I don't think the importance of keeping a ".dist" backup is worth the pain and we're not doing it for other files (If one using a source tarball is modifying a .c file, the original content is lost too, and we'll not provide .c.dist files). ---------- messages: 309079 nosy: mdk priority: normal severity: normal status: open title: Simplify Modules/Setup{,.dist,.local} _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 06:15:23 2017 From: report at bugs.python.org (Julien Palard) Date: Wed, 27 Dec 2017 11:15:23 +0000 Subject: [issue32429] Outdated Modules/Setup warning is invisible In-Reply-To: <1514326238.69.0.213398074469.issue32429@psf.upfronthosting.co.za> Message-ID: <1514373323.11.0.213398074469.issue32429@psf.upfronthosting.co.za> Julien Palard added the comment: Discussion about further simplifications goes here: https://bugs.python.org/issue32430 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 06:15:44 2017 From: report at bugs.python.org (Julien Palard) Date: Wed, 27 Dec 2017 11:15:44 +0000 Subject: [issue32430] Simplify Modules/Setup{,.dist,.local} In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za> Message-ID: <1514373344.76.0.213398074469.issue32430@psf.upfronthosting.co.za> Change by Julien Palard : ---------- components: +Build versions: +Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 06:54:28 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 27 Dec 2017 11:54:28 +0000 Subject: [issue32430] Simplify Modules/Setup{,.dist,.local} In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za> Message-ID: <1514375668.37.0.213398074469.issue32430@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Personally I'll go for a single Setup file (No .dist, no .local, no copy), that one can modify and commit, delegating the pain of merging to git, as I prefer simple solutions. +1 for this. ---------- nosy: +barry, pitrou type: -> enhancement versions: -Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 07:12:40 2017 From: report at bugs.python.org (Dmitriy Shashkin) Date: Wed, 27 Dec 2017 12:12:40 +0000 Subject: [issue12178] csv writer doesn't escape escapechar In-Reply-To: <1306348030.98.0.468032848078.issue12178@psf.upfronthosting.co.za> Message-ID: <1514376760.85.0.213398074469.issue12178@psf.upfronthosting.co.za> Change by Dmitriy Shashkin : ---------- nosy: +Dmitriy Shashkin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 08:02:55 2017 From: report at bugs.python.org (Julien Palard) Date: Wed, 27 Dec 2017 13:02:55 +0000 Subject: [issue31639] http.server and SimpleHTTPServer hang after a few requests In-Reply-To: <1506701944.65.0.213398074469.issue31639@psf.upfronthosting.co.za> Message-ID: <1514379775.38.0.213398074469.issue31639@psf.upfronthosting.co.za> Change by Julien Palard : ---------- keywords: +patch pull_requests: +4908 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 08:04:17 2017 From: report at bugs.python.org (Julien Palard) Date: Wed, 27 Dec 2017 13:04:17 +0000 Subject: [issue31639] http.server and SimpleHTTPServer hang after a few requests In-Reply-To: <1506701944.65.0.213398074469.issue31639@psf.upfronthosting.co.za> Message-ID: <1514379857.41.0.213398074469.issue31639@psf.upfronthosting.co.za> Julien Palard added the comment: I wrote a 2 lines PR in which I propose to use threads to handle connections as it's well supported by socketserver via a ThreadingMixIn and fixes the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 08:51:17 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 Dec 2017 13:51:17 +0000 Subject: [issue31639] http.server and SimpleHTTPServer hang after a few requests In-Reply-To: <1506701944.65.0.213398074469.issue31639@psf.upfronthosting.co.za> Message-ID: <1514382677.53.0.213398074469.issue31639@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think the PR as it stands is a good idea. These classes are designed to be composable, so it should be up to the library user whether or not to use threads. However it would be perfectly reasonable to choose to use threads in the 'test' function and thus the cli. Which fact should then be documented, and chromium can even be mentioned as one of the motivations for using threads in the cli server. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 09:10:28 2017 From: report at bugs.python.org (Jerome Leclanche) Date: Wed, 27 Dec 2017 14:10:28 +0000 Subject: [issue29097] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6 In-Reply-To: <1482958160.11.0.32337159902.issue29097@psf.upfronthosting.co.za> Message-ID: <1514383828.94.0.213398074469.issue29097@psf.upfronthosting.co.za> Jerome Leclanche added the comment: Anything holding up the PR? Looks good at a glance, would be nice to get this landed in time for 3.7. ---------- nosy: +jleclanche _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 09:27:08 2017 From: report at bugs.python.org (Stefan Krah) Date: Wed, 27 Dec 2017 14:27:08 +0000 Subject: [issue26746] struct.pack(): trailing padding bytes on x64 In-Reply-To: <1460536729.2.0.723853097724.issue26746@psf.upfronthosting.co.za> Message-ID: <1514384828.58.0.213398074469.issue26746@psf.upfronthosting.co.za> Stefan Krah added the comment: I have just worked on PEP-3118 ==> Datashape translation and I have encountered many issues similar to the ones in the PR referenced by Allan. It seems to me that we should simplify the PEP-3118 struct syntax as much as possible in order to remove any ambiguities. I think generally that numpy's approach is the best for data interchange, so I would propose this modified struct syntax for PEP-3118: 1) Padding is always explicit and exact, also for natively aligned types. 2) Padding is only allowed in struct fields. 3) Trailing padding is explicit. 4) If no padding is present in a struct, it is assumed to be packed with alignment 1 for the entire struct. 5) The tuple syntax "bxL" is not supported, only the T{} syntax with explicit field names. 6) Repetition "10s" is only allowed for bytes. "10f" is a tuple (not supported), an array of 10 floats would be (10)f. 7) Modifiers (@, =, <, >, !) are only given for primitive data types, not for entire structs or types. 8) Implementations are free to reject any padding that would not arise naturally by specifying alignment or packing constraints (like gcc does with attributes). Here is my implementation with a grammar: https://github.com/plures/ndtypes/blob/master/libndtypes/compat/bpgrammar.y Some tests against numpy: https://github.com/plures/xnd/blob/master/python/test_xnd.py#L1509 I think the best way forward would be to tweak the above grammar so that it covers everything that numpy can export. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 09:27:23 2017 From: report at bugs.python.org (Stefan Krah) Date: Wed, 27 Dec 2017 14:27:23 +0000 Subject: [issue26746] struct.pack(): trailing padding bytes on x64 In-Reply-To: <1460536729.2.0.723853097724.issue26746@psf.upfronthosting.co.za> Message-ID: <1514384843.5.0.213398074469.issue26746@psf.upfronthosting.co.za> Change by Stefan Krah : ---------- versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 10:17:14 2017 From: report at bugs.python.org (Jonathan Underwood) Date: Wed, 27 Dec 2017 15:17:14 +0000 Subject: [issue32431] Two bytes objects of zero length don't compare equal Message-ID: <1514387834.13.0.213398074469.issue32431@psf.upfronthosting.co.za> New submission from Jonathan Underwood : With the current logic in Objects/bytesobject.c in the function bytes_compare_eq it can be the case that zero length bytes object object created in an extension module like this: val = PyBytes_FromStringAndSize (NULL, 20); Py_SIZE(val) = 0; won't compare equal to b'' because the memory is not initialized, so the first two bytes won't be equal. Nonetheless, the Python interpreter does return b'' for print(repr(val)), so this behaviour is very confusing. To get the correct behaviour, one would have to initialize the memory: val = PyBytes_FromStringAndSize (NULL, 20); c = PyBytes_AS_STRING (val); c[0] = '\0'; Py_SIZE(val) = 0; However, it would be more sensible to fix the logic in bytes_compare_eq in my opinion. That function should return true for two zero length bytes objects, irrespective of the memory contents. ---------- components: Interpreter Core messages: 309086 nosy: jonathanunderwood priority: normal severity: normal status: open title: Two bytes objects of zero length don't compare equal type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 10:20:22 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Wed, 27 Dec 2017 15:20:22 +0000 Subject: [issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514388022.61.0.213398074469.issue32424@psf.upfronthosting.co.za> Change by Gordon P. Hemsley : ---------- keywords: +patch pull_requests: +4909 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 10:22:00 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 Dec 2017 15:22:00 +0000 Subject: [issue32431] Two bytes objects of zero length don't compare equal In-Reply-To: <1514387834.13.0.213398074469.issue32431@psf.upfronthosting.co.za> Message-ID: <1514388120.73.0.213398074469.issue32431@psf.upfronthosting.co.za> R. David Murray added the comment: My suspicion is that this behavior/code is left over from when the code was handling strings in python2, where strings were always null terminated and so the equal-bytes test would always pass. I don't think this is appropriate for bytes objects, so I think the compare logic should be fixed. But I don't deal with the C code much, so I'd like an opinion from a core dev who does. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 10:23:11 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Wed, 27 Dec 2017 15:23:11 +0000 Subject: [issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514388191.28.0.213398074469.issue32424@psf.upfronthosting.co.za> Gordon P. Hemsley added the comment: Ultimately, yeah, the Python version should probably define __deepcopy__ as well. But since this is just a rename of an existing method, I figure we can defer that to another time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 10:25:15 2017 From: report at bugs.python.org (Jonathan Underwood) Date: Wed, 27 Dec 2017 15:25:15 +0000 Subject: [issue32431] Two bytes objects of zero length don't compare equal In-Reply-To: <1514387834.13.0.213398074469.issue32431@psf.upfronthosting.co.za> Message-ID: <1514388315.55.0.213398074469.issue32431@psf.upfronthosting.co.za> Jonathan Underwood added the comment: https://github.com/python/cpython/pull/5021 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 10:31:43 2017 From: report at bugs.python.org (Jonathan Underwood) Date: Wed, 27 Dec 2017 15:31:43 +0000 Subject: [issue32431] Two bytes objects of zero length don't compare equal In-Reply-To: <1514387834.13.0.213398074469.issue32431@psf.upfronthosting.co.za> Message-ID: <1514388703.06.0.213398074469.issue32431@psf.upfronthosting.co.za> Change by Jonathan Underwood : ---------- keywords: +patch pull_requests: +4911 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 12:14:57 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Dec 2017 17:14:57 +0000 Subject: [issue32431] Two bytes objects of zero length don't compare equal In-Reply-To: <1514387834.13.0.213398074469.issue32431@psf.upfronthosting.co.za> Message-ID: <1514394897.69.0.213398074469.issue32431@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Much C code implies that bytes are null terminated. For example bytes-to-number converters and most functions that accept bytes as file path. Changing just the compare logic will not help. The documented way of changing the size of the bytes object is _PyBytes_Resize(). But since this is a private function the only way of resizing the bytes object using public functions is creating a new object with PyBytes_FromStringAndSize(). If the new size is 0, it will return a singleton, thus this is a fast and memory efficient way. Using the Py_SIZE() macro with the bytes object is not even documented. We should either document this way with its caveats (for example misusing it can lead to inefficient use of memory), or admit that this is working with internal representation which we shouldn't encourage. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 12:27:02 2017 From: report at bugs.python.org (Felipe Filgueira Barral) Date: Wed, 27 Dec 2017 17:27:02 +0000 Subject: [issue32432] [BUG] Python vs Macbook High Sierra 10.13.2 Message-ID: <1514395616.6.0.213398074469.issue32432@psf.upfronthosting.co.za> New submission from Felipe Filgueira Barral : When i open the IDLE and try include ' or " in any script, the python closes alone! Does anyone know what might be happening? I use mac, version high sierra... Process: Python [1048] Path: /Applications/Python 3.6/IDLE.app/Contents/MacOS/Python Identifier: org.python.IDLE Version: 3.6.4 (3.6.4) Code Type: X86 (Native) Parent Process: ??? [1] Responsible: Python [1048] User ID: 501 Date/Time: 2017-12-27 14:12:58.552 -0200 OS Version: Mac OS X 10.13.2 (17C88) Report Version: 12 Anonymous UUID: 0681CD4F-4E3E-670B-B04B-6F062C271803 Time Awake Since Boot: 3800 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Illegal instruction: 4 Termination Reason: Namespace SIGNAL, Code 0x4 Terminating Process: exc handler [0] Application Specific Information: *** Terminating app due to uncaught exception 'NSRangeException', reason: '-[__NSCFConstantString characterAtIndex:]: Range or index out of bounds' Application Specific Backtrace 1: 0 CoreFoundation 0x93a5f0e2 __raiseError + 178 1 libobjc.A.dylib 0xa6aaa346 objc_exception_throw + 273 2 CoreFoundation 0x93a5f005 +[NSException raise:format:] + 101 3 CoreFoundation 0x9394de6d -[__NSCFString characterAtIndex:] + 93 4 Tk 0x9d5c486a TkpInitKeymapInfo + 609 5 Tk 0x9d5c0cb7 TkpRedirectKeyEvent + 1098 6 Tk 0x9d5ca1f6 Tk_MacOSXSetupTkNotifier + 744 7 Tcl 0x9d4ca37e Tcl_DoOneEvent + 269 8 _tkinter.cpython-36m-darwin.so 0x003ee679 _tkinter_tkapp_mainloop + 233 9 Python 0x0006c566 _PyCFunction_FastCallDict + 582 10 Python 0x000f5e75 call_function + 629 11 Python 0x000fbd89 _PyEval_EvalFrameDefault + 23241 12 Python 0x000f51bf _PyEval_EvalCodeWithName + 2367 13 Python 0x000f59f9 fast_function + 249 14 Python 0x000f5e50 call_function + 592 15 Python 0x000fbd89 _PyEval_EvalFrameDefault + 23241 16 Python 0x000f51bf _PyEval_EvalCodeWithName + 2367 17 Python 0x000f59f9 fast_function + 249 18 Python 0x000f5e50 call_function + 592 19 Python 0x000fbd89 _PyEval_EvalFrameDefault + 23241 20 Python 0x000f51bf _PyEval_EvalCodeWithName + 2367 21 Python 0x000f5383 PyEval_EvalCode + 115 22 Python 0x0013090e PyRun_FileExFlags + 206 23 Python 0x00130c39 PyRun_SimpleFileExFlags + 505 24 Python 0x0014b3fb Py_Main + 4139 25 Python 0x00001e62 main + 498 26 Python 0x00001c65 start + 53 27 ??? 0x00000002 0x0 + 2 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.CoreFoundation 0x93a5f3e3 TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION + 3 1 com.apple.CoreFoundation 0x93a5f381 __raiseError + 849 2 libobjc.A.dylib 0xa6aaa346 objc_exception_throw + 273 3 com.apple.CoreFoundation 0x93a5f005 +[NSException raise:format:] + 101 4 com.apple.CoreFoundation 0x9394de6d -[__NSCFString characterAtIndex:] + 93 5 Tk 0x9d5c486a 0x9d518000 + 706666 6 Tk 0x9d5c0cb7 0x9d518000 + 691383 7 Tk 0x9d5ca1f6 0x9d518000 + 729590 8 Tcl 0x9d4ca37e Tcl_DoOneEvent + 269 9 _tkinter.cpython-36m-darwin.so 0x003ee679 _tkinter_tkapp_mainloop + 233 10 org.python.python 0x0006c566 _PyCFunction_FastCallDict + 582 11 org.python.python 0x000f5e75 call_function + 629 12 org.python.python 0x000fbd89 _PyEval_EvalFrameDefault + 23241 13 org.python.python 0x000f51bf _PyEval_EvalCodeWithName + 2367 14 org.python.python 0x000f59f9 fast_function + 249 15 org.python.python 0x000f5e50 call_function + 592 16 org.python.python 0x000fbd89 _PyEval_EvalFrameDefault + 23241 17 org.python.python 0x000f51bf _PyEval_EvalCodeWithName + 2367 18 org.python.python 0x000f59f9 fast_function + 249 19 org.python.python 0x000f5e50 call_function + 592 20 org.python.python 0x000fbd89 _PyEval_EvalFrameDefault + 23241 21 org.python.python 0x000f51bf _PyEval_EvalCodeWithName + 2367 22 org.python.python 0x000f5383 PyEval_EvalCode + 115 23 org.python.python 0x0013090e PyRun_FileExFlags + 206 24 org.python.python 0x00130c39 PyRun_SimpleFileExFlags + 505 25 org.python.python 0x0014b3fb Py_Main + 4139 26 Python 0x00001e62 main + 498 27 Python 0x00001c65 start + 53 Thread 1: 0 libsystem_kernel.dylib 0xa76ad6ee __workq_kernreturn + 10 1 libsystem_pthread.dylib 0xa77dae70 _pthread_wqthread + 992 2 libsystem_pthread.dylib 0xa77daa6a start_wqthread + 34 Thread 2: 0 libsystem_kernel.dylib 0xa76ad6ee __workq_kernreturn + 10 1 libsystem_pthread.dylib 0xa77db090 _pthread_wqthread + 1536 2 libsystem_pthread.dylib 0xa77daa6a start_wqthread + 34 Thread 3: 0 libsystem_kernel.dylib 0xa76ad07e __select + 10 1 Tcl 0x9d4fa09e 0x9d454000 + 680094 2 libsystem_pthread.dylib 0xa77db50d _pthread_body + 347 3 libsystem_pthread.dylib 0xa77db3b2 _pthread_start + 357 4 libsystem_pthread.dylib 0xa77daa8e thread_start + 34 Thread 4:: com.apple.NSEventThread 0 libsystem_kernel.dylib 0xa76a3742 mach_msg_trap + 10 1 libsystem_kernel.dylib 0xa76a2d7f mach_msg + 47 2 com.apple.CoreFoundation 0x9394d3b8 __CFRunLoopServiceMachPort + 296 3 com.apple.CoreFoundation 0x9394c3a6 __CFRunLoopRun + 2262 4 com.apple.CoreFoundation 0x9394b7a1 CFRunLoopRunSpecific + 641 5 com.apple.CoreFoundation 0x9394b50a CFRunLoopRunInMode + 122 6 com.apple.AppKit 0x914a1614 _NSEventThread + 165 7 libsystem_pthread.dylib 0xa77db50d _pthread_body + 347 8 libsystem_pthread.dylib 0xa77db3b2 _pthread_start + 357 9 libsystem_pthread.dylib 0xa77daa8e thread_start + 34 Thread 5: 0 libsystem_kernel.dylib 0xa76ad6ee __workq_kernreturn + 10 1 libsystem_pthread.dylib 0xa77dae9b _pthread_wqthread + 1035 2 libsystem_pthread.dylib 0xa77daa6a start_wqthread + 34 Thread 6: 0 libsystem_pthread.dylib 0xa77daa48 start_wqthread + 0 1 org.python.python 0x00040003 PyFloat_GetInfo + 275 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x5ad6001b ebx: 0x0059e590 ecx: 0x00000000 edx: 0x00000000 edi: 0x93a5f03e esi: 0x01416400 ebp: 0xbfffe1d8 esp: 0xbfffe1d8 ss: 0x00000023 efl: 0x00010282 eip: 0x93a5f3e3 cs: 0x0000001b ds: 0x00000023 es: 0x00000023 fs: 0x00000000 gs: 0x0000000f cr2: 0xa7f97ecc Logical CPU: 0 Error Code: 0x00000000 Trap Number: 6 Binary Images: 0x1000 - 0x1ff7 +Python (???) /Applications/Python 3.6/IDLE.app/Contents/MacOS/Python 0x4000 - 0x1f1fff +org.python.python (3.6.4, [c] 2001-2017 Python Software Foundation. - 3.6.4) /Library/Frameworks/Python.framework/Versions/3.6/Python 0x3e6000 - 0x3e7ff7 +_heapq.cpython-36m-darwin.so (???) <5A29681A-FD13-A85B-42F3-0897C55A0F96> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_heapq.cpython-36m-darwin.so 0x3eb000 - 0x3f2ff7 +_tkinter.cpython-36m-darwin.so (???) /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_tkinter.cpython-36m-darwin.so 0x7f7000 - 0x7f8ff7 +_posixsubprocess.cpython-36m-darwin.so (???) /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_posixsubprocess.cpython-36m-darwin.so 0x7fb000 - 0x7fbff7 +_opcode.cpython-36m-darwin.so (???) <9B012FE1-6DE8-BAED-D91C-2979B28D8AA2> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_opcode.cpython-36m-darwin.so 0x2afb000 - 0x2afcff7 +_bz2.cpython-36m-darwin.so (???) <80FCCD7B-886A-9D06-5680-6E17B2AF9D16> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_bz2.cpython-36m-darwin.so 0x2d00000 - 0x2d04ff7 +_struct.cpython-36m-darwin.so (???) <3095297A-8F67-6764-A633-9CCF6097917C> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_struct.cpython-36m-darwin.so 0x2d0b000 - 0x2d0eff7 +select.cpython-36m-darwin.so (???) <069CC8D2-F791-F5CF-E895-87CABD8D52B1> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/select.cpython-36m-darwin.so 0x2d14000 - 0x2d19fe7 +math.cpython-36m-darwin.so (???) <6BEDA9EC-9730-7381-D95C-2619361ECF64> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/math.cpython-36m-darwin.so 0x2d20000 - 0x2d2aff7 +_socket.cpython-36m-darwin.so (???) /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_socket.cpython-36m-darwin.so 0x2d35000 - 0x2d38ff7 +zlib.cpython-36m-darwin.so (???) /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/zlib.cpython-36m-darwin.so 0x2d3d000 - 0x2d3dff7 +grp.cpython-36m-darwin.so (???) /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/grp.cpython-36m-darwin.so 0x47c7000 - 0x47ecff7 +_lzma.cpython-36m-darwin.so (???) <5C81CC46-1F73-F635-1584-A438E5DF5C92> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_lzma.cpython-36m-darwin.so 0x47f5000 - 0x47f7ff7 +_hashlib.cpython-36m-darwin.so (???) <1F407598-2886-0DF1-78E1-FF12A926664A> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_hashlib.cpython-36m-darwin.so 0x47fb000 - 0x47fbff7 +_bisect.cpython-36m-darwin.so (???) <200AEE40-86B4-F4C5-3903-968586AB7A49> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_bisect.cpython-36m-darwin.so 0x4ad1000 - 0x4b1ffff +libssl.1.0.0.dylib (1) <49DC030B-D0EF-37B6-F345-BC6FFBE25541> /Library/Frameworks/Python.framework/Versions/3.6/lib/libssl.1.0.0.dylib 0x4b39000 - 0x4c84fff +libcrypto.1.0.0.dylib (1) /Library/Frameworks/Python.framework/Versions/3.6/lib/libcrypto.1.0.0.dylib 0x4ce5000 - 0x4cf1ff7 +_blake2.cpython-36m-darwin.so (???) <7F9E2841-944F-20F0-E6F2-A7FF74C1A5EA> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_blake2.cpython-36m-darwin.so 0x4cf6000 - 0x4cfbff7 +_sha3.cpython-36m-darwin.so (???) /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_sha3.cpython-36m-darwin.so 0x4d00000 - 0x4d01ff7 +_random.cpython-36m-darwin.so (???) <86D566CD-DF59-C2D8-B5F0-6E08368673A0> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_random.cpython-36m-darwin.so 0x4d44000 - 0x4d54ff7 +_pickle.cpython-36m-darwin.so (???) <3455B4C8-D4B0-3F44-A0CB-5B0566769416> /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_pickle.cpython-36m-darwin.so 0x7800000 - 0x7d3efff com.apple.driver.AppleIntelHD4000GraphicsGLDriver (10.30.12 - 10.3.0) <3A85569D-C753-365C-AEF0-67704DB7CB96> /System/Library/Extensions/AppleIntelHD4000GraphicsGLDriver.bundle/Contents/MacOS/AppleIntelHD4000GraphicsGLDriver 0x90298000 - 0x90298fff com.apple.Accelerate (1.11 - Accelerate 1.11) /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 0x90299000 - 0x902afffb libCGInterfaces.dylib (417) <92B03F58-1974-35E7-BC7F-28B6B285A860> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/Libraries/libCGInterfaces.dylib 0x902b0000 - 0x909f1fdf com.apple.vImage (8.1 - ???) <591C941E-6475-347E-89DA-F541E88F949A> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage 0x909f2000 - 0x90b2dff7 libBLAS.dylib (1211.30.1) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 0x90b2e000 - 0x90b5bffb libBNNS.dylib (37) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib 0x90b5c000 - 0x90ecffff libLAPACK.dylib (1211.30.1) <2DDDE838-0FF1-3679-8E62-9C09923ECB7E> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib 0x90ed0000 - 0x90ee6ffb libLinearAlgebra.dylib (1211.30.1) <8A120E75-CAF4-3CAE-BBE6-E2F5FAE44DB8> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLinearAlgebra.dylib 0x90ee7000 - 0x90f00ff7 libSparseBLAS.dylib (1211.30.1) <0C5E0EF4-E9A5-3FC4-B7A3-1FE59DB4A2AA> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparseBLAS.dylib 0x90f01000 - 0x9105ffc7 libvDSP.dylib (622.20.8) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib 0x91060000 - 0x9113effb libvMisc.dylib (622.20.8) <1C8D5D80-F32C-3853-8309-57C8A82B7DA5> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib 0x9113f000 - 0x9113ffff com.apple.Accelerate.vecLib (3.11 - vecLib 3.11) <7A0D5DD6-C302-390D-9178-0B2EA94BB5ED> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib 0x91333000 - 0x920f4ffb com.apple.AppKit (6.9 - 1561.20.106) <5EC573DC-BD5D-3901-AC06-65690425A1B1> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x92146000 - 0x92146fff com.apple.ApplicationServices (48 - 50) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices 0x92147000 - 0x921adff3 com.apple.ApplicationServices.ATS (377 - 445) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS 0x921b0000 - 0x922d4ff3 libFontParser.dylib (222.1.2) <8F7D388A-299C-3C6D-9864-40EC0914A96B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib 0x922d5000 - 0x92321ffb libFontRegistry.dylib (221) <8D81FDCF-F05D-3556-AB6D-090F9508C25E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib 0x92370000 - 0x923a3ff3 libTrueTypeScaler.dylib (222.1.2) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libTrueTypeScaler.dylib 0x9240f000 - 0x92414fff com.apple.ColorSyncLegacy (4.13.0 - 1) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSyncLegacy.framework/Versions/A/ColorSyncLegacy 0x924be000 - 0x92515ff7 com.apple.HIServices (1.22 - 622) <8544026A-17BE-301D-BA2A-782F3AD864DA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x92516000 - 0x92525ff7 com.apple.LangAnalysis (1.7.0 - 1.7.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis 0x92526000 - 0x9257effb com.apple.print.framework.PrintCore (13 - 503) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore 0x9257f000 - 0x92615ffb com.apple.QD (3.12 - 403) <372AFF26-17D1-3C6F-9E47-17C955C2045B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD 0x92616000 - 0x92622ff3 com.apple.speech.synthesis.framework (7.2.1 - 7.2.1) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis 0x92623000 - 0x9286fff3 com.apple.audio.toolbox.AudioToolbox (1.14 - 1.14) <489BC806-28CC-3340-BB52-D37A65CADEC9> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox 0x92871000 - 0x92871fff com.apple.audio.units.AudioUnit (1.14 - 1.14) <3CF15BE4-B8D9-3D92-AB17-B613CD0BFBFE> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit 0x92b8f000 - 0x92efcffb com.apple.CFNetwork (893.13.1 - 893.13.1) <960BA636-F94A-3DF7-B587-3165654BF020> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork 0x92f11000 - 0x92f11fff com.apple.Carbon (158 - 158) <1545E2E8-F562-33D6-8DA7-5FD34045B314> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 0x92f12000 - 0x92f1bff3 com.apple.audio.SoundManager (4.2 - 4.2) <83AE7AA9-8661-3449-99F4-291A42640692> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound 0x92f1c000 - 0x92f20fff com.apple.CommonPanels (1.2.6 - 98) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels 0x92f21000 - 0x932b7ffb com.apple.HIToolbox (2.1.1 - 910.4) <16D13C1E-B4A1-3AF0-A7A3-B3AC344D25F6> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox 0x932b8000 - 0x9330cffb com.apple.htmlrendering (77 - 1.1.4) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering 0x9330d000 - 0x93310fff com.apple.help (1.3.8 - 64) <1E913488-5D7B-388E-904D-64EF8C99E704> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help 0x93311000 - 0x93316ffb com.apple.ImageCapture (9.0 - 9.0) <1887749B-D641-3057-B91F-3C2D8E990115> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture 0x93317000 - 0x933b1ffb com.apple.ink.framework (10.9 - 220) <5340E055-BD3D-35AD-9797-F22E1ECEDAC6> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink 0x933b2000 - 0x933ecfff com.apple.NavigationServices (3.8 - 227) <6B1000C3-9C00-33F5-88D5-62F6BD5DD7F8> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices 0x933ed000 - 0x93408ffb com.apple.openscripting (1.7 - 174) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting 0x93409000 - 0x9340efff com.apple.print.framework.Print (12 - 267) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print 0x9340f000 - 0x93411fff com.apple.securityhi (9.0 - 55006) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI 0x93412000 - 0x93418fff com.apple.speech.recognition.framework (6.0.3 - 6.0.3) <1C27FB7B-A467-3171-A73B-8C9B403028E1> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition 0x93419000 - 0x93419fff com.apple.Cocoa (6.11 - 22) <299860CC-316E-3580-B0A3-3BF73B6E80E8> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 0x93426000 - 0x934e5ff7 com.apple.ColorSync (4.13.0 - 546) /System/Library/Frameworks/ColorSync.framework/Versions/A/ColorSync 0x934e6000 - 0x93581fff com.apple.audio.CoreAudio (4.3.0 - 4.3.0) /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio 0x935df000 - 0x935e4fff com.apple.CoreBluetooth (1.0 - 1) /System/Library/Frameworks/CoreBluetooth.framework/Versions/A/CoreBluetooth 0x935e5000 - 0x938c5fff com.apple.CoreData (120 - 849.2) /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData 0x938c6000 - 0x938ccff3 com.apple.CoreDisplay (1.0 - 81.7) /System/Library/Frameworks/CoreDisplay.framework/Versions/A/CoreDisplay 0x938cd000 - 0x93d57ff3 com.apple.CoreFoundation (6.9 - 1450.16) <5FAD88AF-D901-3D54-9480-BFD8BBB95A09> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x93d59000 - 0x94388ffb com.apple.CoreGraphics (2.0 - 1129.5) <20752785-E9DA-3CC6-ACDD-5A82AD344209> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x9438a000 - 0x94600ffb com.apple.CoreImage (13.0.0 - 579.2.9) /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage 0x947f1000 - 0x947f1fff com.apple.CoreServices (822.19 - 822.19) <5BEC50B1-0B38-3237-8D48-7858156721F5> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x947f2000 - 0x94864ff3 com.apple.AE (735.1 - 735.1) <3E1B0CED-0AC3-3252-AEDD-5D8F91E3AAA7> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE 0x94865000 - 0x94b43ffb com.apple.CoreServices.CarbonCore (1178.2 - 1178.2) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x94b44000 - 0x94b78ff3 com.apple.DictionaryServices (1.2 - 284) <56BEF6B8-50D2-38A0-9EF2-D7093E9AAB56> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices 0x94b79000 - 0x94b81fff com.apple.CoreServices.FSEvents (1239 - 1239) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/FSEvents.framework/Versions/A/FSEvents 0x94b82000 - 0x94ce0fff com.apple.LaunchServices (822.19 - 822.19) <44D623FB-2F50-3322-BEEC-A6A2DD3CD9E6> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices 0x94ce1000 - 0x94d8dff7 com.apple.Metadata (10.7.0 - 1191.2.6) <6CE69880-6AF3-3A1A-A8E0-F89FC750EE4C> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata 0x94d8e000 - 0x94decff7 com.apple.CoreServices.OSServices (822.19 - 822.19) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices 0x94ded000 - 0x94e5eff3 com.apple.SearchKit (1.4.0 - 1.4.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit 0x94e5f000 - 0x94e82fff com.apple.coreservices.SharedFileList (71.4 - 71.4) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SharedFileList.framework/Versions/A/SharedFileList 0x94e83000 - 0x94fceffb com.apple.CoreText (352.0 - 578.12) <6389222B-6B26-3F46-93C2-ABE07168227F> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText 0x94fcf000 - 0x95009ff3 com.apple.CoreVideo (1.8 - 279.2) <0D75C395-3C86-3539-9206-C7A330BE3551> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo 0x9500a000 - 0x95090ff3 com.apple.framework.CoreWLAN (13.0 - 1339) /System/Library/Frameworks/CoreWLAN.framework/Versions/A/CoreWLAN 0x952e4000 - 0x952edff7 com.apple.DiskArbitration (2.7 - 2.7) /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 0x952fe000 - 0x9566dffb com.apple.Foundation (6.9 - 1450.16) <3838D116-6432-30EE-8C80-68FE79D28DE5> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x956ae000 - 0x956ddff3 com.apple.GSS (4.0 - 2.0) <78C94D11-21DF-34C6-B4E8-88564551D67E> /System/Library/Frameworks/GSS.framework/Versions/A/GSS 0x9570a000 - 0x95822ff3 com.apple.Bluetooth (6.0.2 - 6.0.2f2) <48DCB862-4D56-3D7A-83BF-F182D238090A> /System/Library/Frameworks/IOBluetooth.framework/Versions/A/IOBluetooth 0x95888000 - 0x95929ffb com.apple.framework.IOKit (2.0.2 - 1445.31.1) <22A82C10-B391-3359-B23A-053108AE9EB1> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x9592b000 - 0x95932fff com.apple.IOSurface (209.2.2 - 209.2.2) <0CCA9904-FCBB-3278-96A1-714BDB961D8A> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface 0x95987000 - 0x95b0bff3 com.apple.ImageIO.framework (3.3.0 - 1713) <3A5C1E33-7CCC-3537-819B-53F39F70F034> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x95b0c000 - 0x95b10ffb libGIF.dylib (1713) <47A6BFCC-6651-3AAE-A70C-7BA3717B13BB> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib 0x95b11000 - 0x95c02fff libJP2.dylib (1713) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib 0x95c03000 - 0x95c25ff7 libJPEG.dylib (1713) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib 0x95f06000 - 0x95f2cff7 libPng.dylib (1713) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib 0x95f2d000 - 0x95f2fffb libRadiance.dylib (1713) /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib 0x95f30000 - 0x95f7afff libTIFF.dylib (1713) <7A56E3C4-9965-3471-8E98-5F6B28D68FBF> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib 0x9686f000 - 0x96887fff com.apple.Kerberos (3.0 - 1) <8A399DB7-5440-3EC0-A241-3DD10E82DDB2> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos 0x96efd000 - 0x96f73fff com.apple.Metal (124.7 - 124.7) <30F249EE-27E6-3C0F-AD33-792A2E77D75B> /System/Library/Frameworks/Metal.framework/Versions/A/Metal 0x96f75000 - 0x96f81fff com.apple.NetFS (6.0 - 4.0) /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS 0x99c45000 - 0x99c4dff7 libcldcpuengine.dylib (2.8.7) /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libcldcpuengine.dylib 0x99c4e000 - 0x99c99fff com.apple.opencl (2.8.12 - 2.8.12) /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL 0x99c9a000 - 0x99cb6fff com.apple.CFOpenDirectory (10.13 - 207) /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory 0x99cb7000 - 0x99cc2fff com.apple.OpenDirectory (10.13 - 207) <86931646-B3A1-3200-A3CB-35005468F987> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory 0x9aecc000 - 0x9aecdfff libCVMSPluginSupport.dylib (16.4.2) <909D788E-692E-3FF1-AFF0-2AB4609C53D7> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib 0x9aece000 - 0x9aed2fff libCoreFSCache.dylib (162.4) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreFSCache.dylib 0x9aed3000 - 0x9aed7fff libCoreVMClient.dylib (162.4) <19767FEB-6A89-3892-8F18-1F9E73463050> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib 0x9aed8000 - 0x9aee0ff7 libGFXShared.dylib (16.4.2) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib 0x9aee1000 - 0x9aeedfff libGL.dylib (16.4.2) <028B909B-DD19-388B-8113-1850DFAD3DCA> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib 0x9aeee000 - 0x9af29ffb libGLImage.dylib (16.4.2) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib 0x9af2a000 - 0x9b0a2ffb libGLProgrammability.dylib (16.4.2) <141160DE-8DB1-3A9C-95CA-0167D90B0A5A> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib 0x9b0a3000 - 0x9b0e5ff7 libGLU.dylib (16.4.2) <9E1283AA-A7E0-37BA-BDEB-EE5256D677C7> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib 0x9ba8c000 - 0x9ba9afff com.apple.opengl (16.4.2 - 16.4.2) <40645026-52DC-3CFC-8308-EFA2FA79D5A0> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 0x9ba9b000 - 0x9bc28ffb GLEngine (16.4.2) /System/Library/Frameworks/OpenGL.framework/Versions/A/Resources/GLEngine.bundle/GLEngine 0x9bc29000 - 0x9bc53fff GLRendererFloat (16.4.2) /System/Library/Frameworks/OpenGL.framework/Versions/A/Resources/GLRendererFloat.bundle/GLRendererFloat 0x9c7ff000 - 0x9ca35ff7 com.apple.QuartzCore (1.11 - 584.8.94) /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore 0x9cece000 - 0x9d1faff3 com.apple.security (7.0 - 58286.31.2) /System/Library/Frameworks/Security.framework/Versions/A/Security 0x9d1fb000 - 0x9d282ff3 com.apple.securityfoundation (6.0 - 55185.30.4) <54362CD6-89D0-3328-9915-EC2F74748529> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation 0x9d2ae000 - 0x9d2b2fff com.apple.xpc.ServiceManagement (1.0 - 1) /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement 0x9d3dd000 - 0x9d44dff3 com.apple.SystemConfiguration (1.17 - 1.17) <318C287A-BB41-3F72-9095-9DFF0382CB77> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration 0x9d454000 - 0x9d517fff Tcl (8.5.9 - 8.5.9) <52C2FC7F-5020-3E3F-BEB4-78B817A09234> /System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl 0x9d518000 - 0x9d5f5ff3 Tk (8.5.9 - 8.5.9) <685D4DD3-670A-33EB-88F3-9657C167A3F1> /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk 0x9f221000 - 0x9f2b8ff7 com.apple.APFS (1.0 - 1) /System/Library/PrivateFrameworks/APFS.framework/Versions/A/APFS 0x9f8cc000 - 0x9f8f7ff3 com.apple.framework.Apple80211 (13.0 - 1345) <6805C16F-21E5-3758-B77C-29870A7C6627> /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Apple80211 0x9f8f9000 - 0x9f903fff com.apple.AppleFSCompression (96.30.2 - 1.0) /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression 0x9f9fc000 - 0x9fa39ff3 com.apple.AppleJPEG (1.0 - 1) /System/Library/PrivateFrameworks/AppleJPEG.framework/Versions/A/AppleJPEG 0x9fb8c000 - 0x9fb93fff com.apple.coreservices.BackgroundTaskManagement (1.0 - 57.1) <71FD5EA2-8D0B-3E21-94E4-6D5BD45005E7> /System/Library/PrivateFrameworks/BackgroundTaskManagement.framework/Versions/A/BackgroundTaskManagement 0x9fb94000 - 0x9fc1fff7 com.apple.backup.framework (1.9.2 - 1.9.2) <19BE4138-61BB-33C8-80C5-0309B58CA16A> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup 0x9fd63000 - 0x9fd6cffb com.apple.CommonAuth (4.0 - 2.0) <424B8D39-396A-3A78-84C1-5161B54A8F5B> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth 0xa01de000 - 0xa01eeff7 com.apple.CoreEmoji (1.0 - 69.3) <165A133F-DED4-3B24-A9BF-6EA6F3F7A152> /System/Library/PrivateFrameworks/CoreEmoji.framework/Versions/A/CoreEmoji 0xa0376000 - 0xa03a9ff7 com.apple.CoreServicesInternal (309.1 - 309.1) <1F73ECC7-F09F-3730-A290-472B89788807> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal 0xa03aa000 - 0xa0440ff3 com.apple.CoreSymbolication (63075) <6223068D-FCD8-39C1-841D-834EF0AC6445> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication 0xa0441000 - 0xa0567fe3 com.apple.coreui (2.1 - 492.2) <4B915963-6D32-3D89-B585-94094ACCF2E8> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI 0xa0568000 - 0xa0603ff3 com.apple.CoreUtils (5.3 - 530.57) <21D34447-A1FC-31C4-BE73-F61577ABB2F5> /System/Library/PrivateFrameworks/CoreUtils.framework/Versions/A/CoreUtils 0xa0654000 - 0xa06b1ff3 com.apple.framework.CoreWiFi (13.0 - 1339) <5434C7AB-A80A-3DD3-B0F1-4EFEA912B16B> /System/Library/PrivateFrameworks/CoreWiFi.framework/Versions/A/CoreWiFi 0xa06b2000 - 0xa06c2fff com.apple.CrashReporterSupport (10.13 - 1) <86DA5C7B-BA5E-3182-A787-28B6F580FF38> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport 0xa0730000 - 0xa073dfff com.apple.framework.DFRFoundation (1.0 - 191.1) <8EF25CE9-3ED3-3E20-A4A2-20743EA32265> /System/Library/PrivateFrameworks/DFRFoundation.framework/Versions/A/DFRFoundation 0xa0789000 - 0xa07fafff com.apple.datadetectorscore (7.0 - 590.3) <2210A987-9208-3E20-8425-90180C57DE8C> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore 0xa07fb000 - 0xa083bffb com.apple.DebugSymbols (141 - 141) <96BB879B-1A83-3622-BB02-1DDA5C4FD939> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols 0xa083c000 - 0xa097bff7 com.apple.desktopservices (1.12.2 - 1.12.2) /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv 0xa0c47000 - 0xa1077ff7 com.apple.vision.FaceCore (3.3.2 - 3.3.2) /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore 0xa2e23000 - 0xa2e2dfff libGPUSupportMercury.dylib (16.4.2) /System/Library/PrivateFrameworks/GPUSupport.framework/Versions/A/Libraries/libGPUSupportMercury.dylib 0xa3a1b000 - 0xa3a8eff3 com.apple.Heimdal (4.0 - 2.0) <560C8A98-E261-39C9-9862-3340EC6ABC9C> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal 0xa3a8f000 - 0xa3abefff com.apple.HelpData (2.3 - 158) <8FFBF281-4DDA-330B-898E-3E8C4D70E8F6> /System/Library/PrivateFrameworks/HelpData.framework/Versions/A/HelpData 0xa3d40000 - 0xa3d46fff com.apple.IOAccelerator (376.6 - 376.6) <4EFED596-8863-35F6-8EA3-CB11C5D9D157> /System/Library/PrivateFrameworks/IOAccelerator.framework/Versions/A/IOAccelerator 0xa3d47000 - 0xa3d5fffb com.apple.IOPresentment (1.0 - 32.1) /System/Library/PrivateFrameworks/IOPresentment.framework/Versions/A/IOPresentment 0xa3dbc000 - 0xa3ddbff3 com.apple.IconServices (97.4 - 97.4) <3F593C33-E45D-3D77-B82C-F811428C4901> /System/Library/PrivateFrameworks/IconServices.framework/Versions/A/IconServices 0xa3e13000 - 0xa3f07ff7 com.apple.LanguageModeling (1.0 - 159.3.1) /System/Library/PrivateFrameworks/LanguageModeling.framework/Versions/A/LanguageModeling 0xa3f08000 - 0xa3f49ff7 com.apple.Lexicon-framework (1.0 - 33.2) <13FAB8A2-507A-3AEA-A571-27BDDFD96B31> /System/Library/PrivateFrameworks/Lexicon.framework/Versions/A/Lexicon 0xa3f4d000 - 0xa3f53ff3 com.apple.LinguisticData (1.0 - 238.3) /System/Library/PrivateFrameworks/LinguisticData.framework/Versions/A/LinguisticData 0xa4301000 - 0xa432affb com.apple.MultitouchSupport.framework (1204.13 - 1204.13) <01BDF9A5-8C83-3611-A999-F43F9121A173> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport 0xa4449000 - 0xa4453fff com.apple.NetAuth (6.2 - 6.2) <52F67DC1-8C96-3944-8E54-C02DD51FD9FC> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth 0xa44fb000 - 0xa4537fff com.apple.PerformanceAnalysis (1.183.1 - 183.1) /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis 0xa45d6000 - 0xa45f2ff7 com.apple.ProtocolBuffer (1 - 259) /System/Library/PrivateFrameworks/ProtocolBuffer.framework/Versions/A/ProtocolBuffer 0xa46de000 - 0xa4700fff com.apple.RemoteViewServices (2.0 - 125) <5720B413-E761-3368-964F-7FEAC5535669> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices 0xa47b6000 - 0xa47e3ffb com.apple.Sharing (972.6 - 972.6) <94426AD7-4302-3870-9D7B-F5ED6900BBCE> /System/Library/PrivateFrameworks/Sharing.framework/Versions/A/Sharing 0xa47e4000 - 0xa4801ff3 com.apple.shortcut (2.16 - 98) <5AC8A175-06FF-39B8-98A9-9AD32B1D4AC5> /System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Shortcut 0xa4802000 - 0xa4803fff com.apple.performance.SignpostNotification (1.0 - 1) <9AD547F6-ED5A-3AC8-BF4C-811C69801CDF> /System/Library/PrivateFrameworks/SignpostNotification.framework/Versions/A/SignpostNotification 0xa4804000 - 0xa4889ffb com.apple.SkyLight (1.600.0 - 312.23.4) /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/SkyLight 0xa48b9000 - 0xa48c6ffb com.apple.SpeechRecognitionCore (4.0.13 - 4.0.13) /System/Library/PrivateFrameworks/SpeechRecognitionCore.framework/Versions/A/SpeechRecognitionCore 0xa4b93000 - 0xa4c14ff3 com.apple.Symbolication (9.0 - 63079.1) <97DA4973-352E-3CBA-9B4A-BC22C3AFD597> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication 0xa4c67000 - 0xa4c6efff com.apple.TCC (1.0 - 1) <4B76752A-36A0-3175-87C7-CB42E33CCB5A> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC 0xa4c6f000 - 0xa4c86ff3 com.apple.TextureIO (3.7 - 3.7) /System/Library/PrivateFrameworks/TextureIO.framework/Versions/A/TextureIO 0xa4cae000 - 0xa4caffff com.apple.TrustEvaluationAgent (2.0 - 31) <185BD5A9-5A2D-3317-B7FE-9B67F14C4D2C> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent 0xa4cb0000 - 0xa4e3afff com.apple.UIFoundation (1.0 - 546.1.1) /System/Library/PrivateFrameworks/UIFoundation.framework/Versions/A/UIFoundation 0xa5408000 - 0xa540afff com.apple.loginsupport (1.0 - 1) <086FAE1B-87E2-324A-AE76-E6EC0B5F1517> /System/Library/PrivateFrameworks/login.framework/Versions/A/Frameworks/loginsupport.framework/Versions/A/loginsupport 0xa5495000 - 0xa54c8ff7 libclosured.dylib (519.2.2) /usr/lib/closure/libclosured.dylib 0xa5518000 - 0xa554fff3 libCRFSuite.dylib (41) <7F584902-74F1-3362-935D-95F5E735F5E7> /usr/lib/libCRFSuite.dylib 0xa5550000 - 0xa555affb libChineseTokenizer.dylib (28) <1FF5A32D-E012-3E76-B738-FAC26AD2A39B> /usr/lib/libChineseTokenizer.dylib 0xa55f6000 - 0xa55f7fff libDiagnosticMessagesClient.dylib (104) <6829B180-2556-3A7E-A2E6-BD4859DF30A7> /usr/lib/libDiagnosticMessagesClient.dylib 0xa5629000 - 0xa5813ff7 libFosl_dynamic.dylib (17.7) /usr/lib/libFosl_dynamic.dylib 0xa581b000 - 0xa581bfff libOpenScriptingUtil.dylib (174) /usr/lib/libOpenScriptingUtil.dylib 0xa5865000 - 0xa5869fff libScreenReader.dylib (562.13) /usr/lib/libScreenReader.dylib 0xa586a000 - 0xa586bfff libSystem.B.dylib (1252) <334D9E12-F209-3C28-875B-77E0FD623AD7> /usr/lib/libSystem.B.dylib 0xa587a000 - 0xa588fff7 libapple_nghttp2.dylib (1.24) <480C0C04-2533-3D44-8232-006B6CBA7758> /usr/lib/libapple_nghttp2.dylib 0xa5890000 - 0xa58bbfff libarchive.2.dylib (54) /usr/lib/libarchive.2.dylib 0xa58bc000 - 0xa5a0bffb libate.dylib (1.13.1) /usr/lib/libate.dylib 0xa5a0f000 - 0xa5a0fff3 libauto.dylib (187) /usr/lib/libauto.dylib 0xa5a10000 - 0xa5a20fff libbsm.0.dylib (39) <067E9003-0673-32A3-9B40-492323182C5C> /usr/lib/libbsm.0.dylib 0xa5a21000 - 0xa5a2dff7 libbz2.1.0.dylib (38) <77C24A36-BE84-3702-A786-935C597A0A86> /usr/lib/libbz2.1.0.dylib 0xa5a2e000 - 0xa5a87ffb libc++.1.dylib (400.9) /usr/lib/libc++.1.dylib 0xa5a88000 - 0xa5aa9fff libc++abi.dylib (400.7) <41323E53-C7EA-3E9A-BD30-38E82399F843> /usr/lib/libc++abi.dylib 0xa5aab000 - 0xa5abcff7 libcmph.dylib (6) /usr/lib/libcmph.dylib 0xa5abd000 - 0xa5ad0ff7 libcompression.dylib (47) /usr/lib/libcompression.dylib 0xa5ad1000 - 0xa5ae8ffb libcoretls.dylib (155) /usr/lib/libcoretls.dylib 0xa5ae9000 - 0xa5aeafff libcoretls_cfhelpers.dylib (155) <8B8ABC2C-F251-3C80-9747-88C05A2CBE64> /usr/lib/libcoretls_cfhelpers.dylib 0xa5c6b000 - 0xa5e12fff libcrypto.35.dylib (22) /usr/lib/libcrypto.35.dylib 0xa5fd2000 - 0xa6029fff libcups.2.dylib (462.1) <0180AE97-A19F-3D49-9838-06995E73F572> /usr/lib/libcups.2.dylib 0xa613f000 - 0xa613ffff libenergytrace.dylib (16) <34FC43C7-D9B6-3C01-8B65-E49059D31279> /usr/lib/libenergytrace.dylib 0xa6173000 - 0xa6177fff libheimdal-asn1.dylib (520.30.1) /usr/lib/libheimdal-asn1.dylib 0xa61a3000 - 0xa6293ff3 libiconv.2.dylib (51) /usr/lib/libiconv.2.dylib 0xa6294000 - 0xa64b6ff7 libicucore.A.dylib (59152.0.1) <1048B064-30DD-30CA-BB7D-41F0F3159DA9> /usr/lib/libicucore.A.dylib 0xa64fe000 - 0xa64fffff liblangid.dylib (128) <120FE992-47E4-3A73-A039-1B401F5696DC> /usr/lib/liblangid.dylib 0xa6500000 - 0xa6518ff7 liblzma.5.dylib (10) <8A5C9679-430A-3A19-AF68-9D21BAC442C7> /usr/lib/liblzma.5.dylib 0xa6519000 - 0xa652efff libmarisa.dylib (9) <805453EE-B829-3DA5-8DF3-5132D03D5B74> /usr/lib/libmarisa.dylib 0xa65e3000 - 0xa6800fff libmecabra.dylib (779.7.6) <08A39874-BF80-3A92-A088-C494C518218A> /usr/lib/libmecabra.dylib 0xa69c7000 - 0xa6a9bfff libnetwork.dylib (1229.30.11) <86111B18-D03B-3F4F-ACD8-9D9C510058F3> /usr/lib/libnetwork.dylib 0xa6a9c000 - 0xa6e7c0fb libobjc.A.dylib (723) <4AF346B8-C1A8-3199-B1BB-ADEDD64D5C1A> /usr/lib/libobjc.A.dylib 0xa6e80000 - 0xa6e83fff libpam.2.dylib (22) <7106F43C-84DD-3F26-905A-B52780AFEB3E> /usr/lib/libpam.2.dylib 0xa6e86000 - 0xa6eb7fff libpcap.A.dylib (79.20.1) <154889CF-5F83-3012-953E-0FC8FEE50FF8> /usr/lib/libpcap.A.dylib 0xa6ef5000 - 0xa6f10ffb libresolv.9.dylib (65) <65A43F5B-CF88-3948-AE5C-D7CA02D814A1> /usr/lib/libresolv.9.dylib 0xa6f5b000 - 0xa70e5ff7 libsqlite3.dylib (274.5) /usr/lib/libsqlite3.dylib 0xa7289000 - 0xa72c3ffb libusrtcp.dylib (1229.30.11) <39D76669-A48B-3BAC-8F45-1D6CA87E9B4B> /usr/lib/libusrtcp.dylib 0xa72c4000 - 0xa72c7ff7 libutil.dylib (51.20.1) <86BD9675-16A2-345D-9B8D-E8A3397F2365> /usr/lib/libutil.dylib 0xa72c8000 - 0xa72d6ff7 libxar.1.dylib (400) <4B664A7E-EC05-34AD-ACC6-C879B69DBA7C> /usr/lib/libxar.1.dylib 0xa72d7000 - 0xa73b5ff7 libxml2.2.dylib (31.7) <3E1F9E3D-6C44-3437-AB2B-E5ACE1927F81> /usr/lib/libxml2.2.dylib 0xa73b6000 - 0xa73deff3 libxslt.1.dylib (15.10) <1A3DC7B8-7C92-3D73-BF82-D60E64BC3DF0> /usr/lib/libxslt.1.dylib 0xa73df000 - 0xa73eeff7 libz.1.dylib (70) <588F445F-0065-3D77-8002-BA9411DA1D70> /usr/lib/libz.1.dylib 0xa7428000 - 0xa742cfff libcache.dylib (80) <5D011637-CADA-38A1-A695-CE049657FD9D> /usr/lib/system/libcache.dylib 0xa742d000 - 0xa7437fff libcommonCrypto.dylib (60118.30.2) <38B2C15B-D27F-3106-A337-F72F29844825> /usr/lib/system/libcommonCrypto.dylib 0xa7438000 - 0xa743dfff libcompiler_rt.dylib (62) /usr/lib/system/libcompiler_rt.dylib 0xa743e000 - 0xa7447ff3 libcopyfile.dylib (146.30.2) /usr/lib/system/libcopyfile.dylib 0xa7448000 - 0xa74b0ff7 libcorecrypto.dylib (562.30.10) <0D8A61F8-2D7D-31F1-93AB-0597D80CCA85> /usr/lib/system/libcorecrypto.dylib 0xa751b000 - 0xa7550fff libdispatch.dylib (913.30.4) /usr/lib/system/libdispatch.dylib 0xa7551000 - 0xa756efff libdyld.dylib (519.2.2) /usr/lib/system/libdyld.dylib 0xa756f000 - 0xa756ffff libkeymgr.dylib (28) /usr/lib/system/libkeymgr.dylib 0xa7570000 - 0xa757cff7 libkxld.dylib (4570.31.3) <17609EC4-47F0-39C9-8F90-5F07FF52F217> /usr/lib/system/libkxld.dylib 0xa757d000 - 0xa757dfff liblaunch.dylib (1205.30.29) <0F3BF17D-FCFA-3692-8A6E-FDE5C58DB3B7> /usr/lib/system/liblaunch.dylib 0xa757e000 - 0xa7583fff libmacho.dylib (900.0.1) /usr/lib/system/libmacho.dylib 0xa7584000 - 0xa7586fff libquarantine.dylib (86) <68DE2EB2-7911-304D-89D6-1517CA689001> /usr/lib/system/libquarantine.dylib 0xa7587000 - 0xa7588fff libremovefile.dylib (45) /usr/lib/system/libremovefile.dylib 0xa7589000 - 0xa75a0ff7 libsystem_asl.dylib (356.1.1) /usr/lib/system/libsystem_asl.dylib 0xa75a1000 - 0xa75a1fff libsystem_blocks.dylib (67) <32CE9BB7-E047-3568-981E-4EA94D3DCBB5> /usr/lib/system/libsystem_blocks.dylib 0xa75a2000 - 0xa762efff libsystem_c.dylib (1244.30.3) <8BCBF89D-5CE7-3950-884A-86E37DBF2660> /usr/lib/system/libsystem_c.dylib 0xa762f000 - 0xa7632fff libsystem_configuration.dylib (963.30.1) <0F30DC5A-F39F-32C9-BA01-05AAC699713A> /usr/lib/system/libsystem_configuration.dylib 0xa7633000 - 0xa7636fff libsystem_coreservices.dylib (51) /usr/lib/system/libsystem_coreservices.dylib 0xa7637000 - 0xa7638fff libsystem_darwin.dylib (1244.30.3) <83B1D06A-9FA5-3F0B-A223-0659F4248E51> /usr/lib/system/libsystem_darwin.dylib 0xa7639000 - 0xa763fff3 libsystem_dnssd.dylib (878.30.4) <3C4400C4-C531-3653-872B-E22892D7B29A> /usr/lib/system/libsystem_dnssd.dylib 0xa7640000 - 0xa768fffb libsystem_info.dylib (517.30.1) /usr/lib/system/libsystem_info.dylib 0xa7690000 - 0xa76b3ff7 libsystem_kernel.dylib (4570.31.3) /usr/lib/system/libsystem_kernel.dylib 0xa76b4000 - 0xa7703fdb libsystem_m.dylib (3146) /usr/lib/system/libsystem_m.dylib 0xa7704000 - 0xa771efff libsystem_malloc.dylib (140.1.1) /usr/lib/system/libsystem_malloc.dylib 0xa771f000 - 0xa77bcffb libsystem_network.dylib (1229.30.11) <84B584A7-7583-31E7-8A39-64B4A5AD643B> /usr/lib/system/libsystem_network.dylib 0xa77bd000 - 0xa77c7fff libsystem_networkextension.dylib (767.30.7) /usr/lib/system/libsystem_networkextension.dylib 0xa77c8000 - 0xa77d0ff3 libsystem_notify.dylib (172) <63E3CF8C-4F15-3D45-84A6-1218352031E9> /usr/lib/system/libsystem_notify.dylib 0xa77d1000 - 0xa77d7ffb libsystem_platform.dylib (161.20.1) <82782E0E-7264-3CB4-AE69-571EDB5E7A24> /usr/lib/system/libsystem_platform.dylib 0xa77d8000 - 0xa77e2ff3 libsystem_pthread.dylib (301.30.1) <7409C1E5-F3BA-3AB3-ADC1-9DCD356C6C13> /usr/lib/system/libsystem_pthread.dylib 0xa77e3000 - 0xa77e6ff3 libsystem_sandbox.dylib (765.30.4) <8226258C-47FE-30A9-AE91-C13DE173E368> /usr/lib/system/libsystem_sandbox.dylib 0xa77e7000 - 0xa77e9fff libsystem_secinit.dylib (30) /usr/lib/system/libsystem_secinit.dylib 0xa77ea000 - 0xa77f2ff7 libsystem_symptoms.dylib (820.30.7) <0283BDB3-16A2-371E-A25C-A26F076C24A5> /usr/lib/system/libsystem_symptoms.dylib 0xa77f3000 - 0xa7805fff libsystem_trace.dylib (829.30.14) <79446DE0-89F6-3979-B14C-7B463AD70351> /usr/lib/system/libsystem_trace.dylib 0xa7807000 - 0xa780dfff libunwind.dylib (35.3) <642BBA03-0411-3FAA-A421-D79A9156AB1C> /usr/lib/system/libunwind.dylib 0xa780e000 - 0xa7836ff7 libxpc.dylib (1205.30.29) /usr/lib/system/libxpc.dylib 0xc0036000 - 0xc007bfdf dyld (519.2.2) <7B7B05B7-204A-38FF-BD32-4CBB51752DD4> /usr/lib/dyld External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 2328 thread_create: 0 thread_set_state: 0 VM Region Summary: ReadOnly portion of Libraries: Total=216.9M resident=0K(0%) swapped_out_or_unallocated=216.9M(100%) Writable regions: Total=96.3M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=96.3M(100%) VIRTUAL REGION REGION TYPE SIZE COUNT (non-coalesced) =========== ======= ======= Accelerate framework 256K 3 Activity Tracing 256K 2 CG backing stores 3384K 6 CG image 184K 2 CoreAnimation 20K 4 CoreImage 12K 4 CoreUI image data 636K 5 CoreUI image file 180K 3 Kernel Alloc Once 8K 2 MALLOC 72.0M 48 MALLOC guard page 48K 13 MALLOC_LARGE (reserved) 512K 3 reserved VM address space (unallocated) Memory Tag 242 12K 2 OpenGL GLSL 128K 3 Stack 2644K 7 Stack Guard 24K 7 VM_ALLOCATE 204K 29 __DATA 10.1M 241 __FONT_DATA 4K 2 __GLSLBUILTINS 2588K 2 __LINKEDIT 76.3M 26 __OBJC 3176K 80 __TEXT 140.6M 245 __UNICODE 560K 2 __UNIXSTACK 16.0M 2 mapped file 323.6M 193 shared memory 2728K 12 =========== ======= ======= TOTAL 655.7M 921 TOTAL, minus reserved VM space 655.2M 921 Model: MacBookPro9,2, BootROM MBP91.00D7.B00, 2 processors, Intel Core i7, 2,9 GHz, 8 GB, SMC 2.2f44 Graphics: Intel HD Graphics 4000, Intel HD Graphics 4000, Built-In Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D54333531533643465238432D50422020 Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D54333531533643465238432D50422020 AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xF5), Broadcom BCM43xx 1.0 (7.21.190.16.1a2) Bluetooth: Version 6.0.2f2, 3 services, 27 devices, 1 incoming serial ports Network Service: iPhone, Ethernet, en4 Network Service: Wi-Fi, AirPort, en1 Serial ATA Device: KINGSTON SHSS37A120G, 120,03 GB Serial ATA Device: MATSHITADVD-R UJ-8A8 USB Device: USB 2.0 Bus USB Device: Hub USB Device: FaceTime HD Camera (Built-in) USB Device: USB 2.0 Bus USB Device: Hub USB Device: Hub USB Device: Apple Internal Keyboard / Trackpad USB Device: IR Receiver USB Device: BRCM20702 Hub USB Device: Bluetooth USB Host Controller USB Device: USB 3.0 Bus USB Device: iPhone Thunderbolt Bus: MacBook Pro, Apple Inc., 25.1 ---------- messages: 309092 nosy: Felipe Filgueira Barral priority: normal severity: normal status: open title: [BUG] Python vs Macbook High Sierra 10.13.2 type: crash versions: Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 13:08:41 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 27 Dec 2017 18:08:41 +0000 Subject: [issue32431] Two bytes objects of zero length don't compare equal In-Reply-To: <1514387834.13.0.213398074469.issue32431@psf.upfronthosting.co.za> Message-ID: <1514398121.33.0.213398074469.issue32431@psf.upfronthosting.co.za> R. David Murray added the comment: I think what Py_SIZE "means" depends on the object type in the general case, not just this one, so documenting that it is mucking with the internal representation is probably the way to go. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 13:18:01 2017 From: report at bugs.python.org (Glenn Linderman) Date: Wed, 27 Dec 2017 18:18:01 +0000 Subject: [issue31639] http.server and SimpleHTTPServer hang after a few requests In-Reply-To: <1506701944.65.0.213398074469.issue31639@psf.upfronthosting.co.za> Message-ID: <1514398681.08.0.213398074469.issue31639@psf.upfronthosting.co.za> Glenn Linderman added the comment: I tried the approach in the PR "externally" (when starting the server using a test program), and I couldn't get it to work. But my test case was probably different: I was using Chrome rather than Chromium, and while they both work for me for simple HTTP file access to localhost without threading, I had tried to set up a PWA with a service worker, and maybe that does something different, so I got the hang, applied the Threading.mixIn, and it still hung. I don't know how to tell for sure if it is the same sort of hang, or something different, in the Windows environment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 13:37:02 2017 From: report at bugs.python.org (Jonathan Underwood) Date: Wed, 27 Dec 2017 18:37:02 +0000 Subject: [issue32431] Two bytes objects of zero length don't compare equal In-Reply-To: <1514387834.13.0.213398074469.issue32431@psf.upfronthosting.co.za> Message-ID: <1514399822.52.0.213398074469.issue32431@psf.upfronthosting.co.za> Jonathan Underwood added the comment: Py_SIZE is actually precisely specified and documented[1] as it stands; I don't think a change there is needed. The usage I outlined is in line with that documentation, and many other uses of that macro in the cpython sources. The documentation issues are, at least: 1. There is no documentation specifying that bytes objects should be null terminated. 2. Nothing in the documentation of PyBytes_FromStringAndSize[2] specifies that passing 0 as the size results in a singleton being returned. This is undocumented behaviour, and it would seem fragile to rely on this. But there are more implementation inconsistencies: the documentation for PyBytes_AsString()[3] returns a buffer which is one byte longer than the length of the object *in order to store a terminating null*, which implies that the object need not itself have a terminating null. I could go on with other examples, but this is very poorly defined behaviour. Question: are bytes objects defined to be null terminated, or not? Because if they're not defined to be null terminated, the fix I propose is correct even if it doesn't solve the other 100 bugs lurking in the code. [Aside: even if bytes objects are in fact defined to be null terminated, I think the change proposed amounts to an optimization in any case.] [1] https://docs.python.org/3/c-api/structures.html#c.Py_SIZE [2] https://docs.python.org/3/c-api/bytes.html?highlight=pybytes_fromstringandsize#c.PyBytes_FromStringAndSize [3] https://docs.python.org/3/c-api/bytes.html?highlight=pybytes_asstring#c.PyBytes_AsString ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 14:00:17 2017 From: report at bugs.python.org (Jonathan Underwood) Date: Wed, 27 Dec 2017 19:00:17 +0000 Subject: [issue32431] Two bytes objects of zero length don't compare equal In-Reply-To: <1514387834.13.0.213398074469.issue32431@psf.upfronthosting.co.za> Message-ID: <1514401217.59.0.213398074469.issue32431@psf.upfronthosting.co.za> Jonathan Underwood added the comment: Actually the commentary at the top of bytesobject.c for PyBytes_FromStringAndSize says: "... If `str' is NULL then PyBytes_FromStringAndSize() will allocate `size+1' bytes (setting the last byte to the null terminating character)... " So, perhaps that's as close to gospel as it gets - this does imply that bytes objects are expected to be null terminated. Why PyBytesAsString then adds an extra null terminator is a bit of a mystery. Perhaps what's needed is some documentation clarifications: 1/ State early on that bytes objects are always expected to be null terminated. 2/ As such, the string pointer returned by PyBytes_AsString will point to a null terminated string - I think the current docs could be misinterpreted to suggest that _AsString *adds* an extra byte for the null, which it doesn't. 3/ Document that using Py_SIZE to reduce the length of a bytes object is dangerous, because the null terminator will be lost, and subsequent behaviour undefined. 4/ Document that the preferred way to resize is to use PyBytes_FromStringAndSize with a new size. 5/ Indicate clearly that _PyBytes_Resize is not a public interface and its use is discouraged in favour of PyBytes_FromStringAndSize ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 14:00:28 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 27 Dec 2017 19:00:28 +0000 Subject: [issue32433] Provide optimized HMAC digest Message-ID: <1514401228.33.0.213398074469.issue32433@psf.upfronthosting.co.za> New submission from Christian Heimes : hmac.HMAC's flexibility comes with a cost. To create the MAC of a message, it has to create between three and four hash instances (inner, outer, key for long keys, result), multiple bound method objects and other temporary objects. For short messages, memory allocation, object handling and GIL release/acquire operations dominate the performance. I propose to provide a fast one-shot HMAC function: hmac.digest(key, msg, digstmod) -> bytes function. A PoC implementation based on OpenSSL's HMAC() function and a pure Python implementation as inlined HMAC showed promising performance improvements. The C implementation is 3 times faster. Standard HMAC: $ ./python -m timeit -n200000 -s "import hmac" -- "hmac.HMAC(b'key', b'message', 'sha256').digest()" 200000 loops, best of 5: 5.38 usec per loop Optimized Python code: $ ./python -m timeit -n 200000 -s "import hmac; hmac._hashopenssl = None" -- "hmac.digest(b'key', b'message', 'sha256')" 200000 loops, best of 5: 3.87 usec per loop OpenSSL HMAC() $ ./python -m timeit -n 200000 -s "import hmac" -- "hmac.digest(b'key', b'message', 'sha256')" 200000 loops, best of 5: 1.82 usec per loop ---------- components: Extension Modules messages: 309097 nosy: christian.heimes, gregory.p.smith priority: normal severity: normal stage: patch review status: open title: Provide optimized HMAC digest type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 14:11:28 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 27 Dec 2017 19:11:28 +0000 Subject: [issue32433] Provide optimized HMAC digest In-Reply-To: <1514401228.33.0.213398074469.issue32433@psf.upfronthosting.co.za> Message-ID: <1514401888.22.0.213398074469.issue32433@psf.upfronthosting.co.za> Change by Christian Heimes : ---------- keywords: +patch pull_requests: +4913 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 14:25:19 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 27 Dec 2017 19:25:19 +0000 Subject: [issue29504] blake2: compile error with -march=bdver2 In-Reply-To: <1486574963.2.0.72017577066.issue29504@psf.upfronthosting.co.za> Message-ID: <1514402719.38.0.213398074469.issue29504@psf.upfronthosting.co.za> Christian Heimes added the comment: The issue has been fixed on Nov 1st in PR https://github.com/python/cpython/pull/4173 (master) and https://github.com/python/cpython/pull/4214 (3.6.4). ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 14:31:49 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Dec 2017 19:31:49 +0000 Subject: [issue32416] Refactor and add new tests for the f_lineno setter In-Reply-To: <1514049243.28.0.213398074469.issue32416@psf.upfronthosting.co.za> Message-ID: <1514403109.21.0.213398074469.issue32416@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset ea98eba3465fff2b191610cea253d43000c84b4a by Serhiy Storchaka in branch '3.6': [3.6] bpo-32416: Refactor tests for the f_lineno setter and add new tests. (GH-4991). (#5016) https://github.com/python/cpython/commit/ea98eba3465fff2b191610cea253d43000c84b4a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 14:32:05 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Dec 2017 19:32:05 +0000 Subject: [issue32416] Refactor and add new tests for the f_lineno setter In-Reply-To: <1514049243.28.0.213398074469.issue32416@psf.upfronthosting.co.za> Message-ID: <1514403125.95.0.213398074469.issue32416@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset c60eca06adda4900e6b469d989e6082cda3a3004 by Serhiy Storchaka in branch '2.7': [2.7] bpo-32416: Refactor tests for the f_lineno setter and add new tests. (GH-4991). (#5017) https://github.com/python/cpython/commit/c60eca06adda4900e6b469d989e6082cda3a3004 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 14:37:42 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Dec 2017 19:37:42 +0000 Subject: [issue32416] Refactor and add new tests for the f_lineno setter In-Reply-To: <1514049243.28.0.213398074469.issue32416@psf.upfronthosting.co.za> Message-ID: <1514403462.18.0.213398074469.issue32416@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 14:56:08 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 27 Dec 2017 19:56:08 +0000 Subject: [issue21288] hashlib.pbkdf2_hmac Hash Constructor In-Reply-To: <1397760292.99.0.128790868195.issue21288@psf.upfronthosting.co.za> Message-ID: <1514404568.55.0.213398074469.issue21288@psf.upfronthosting.co.za> Christian Heimes added the comment: Is anybody interested still to solve the problem? I don't see a viable way to solve the issue in a correct way (*). The hashlib API is not designed to provide sufficient information from a digestmod object. I don't want to include hacks like mapping _hashlib.openssl_sha256 function to SHA256 EVP_MD. (*) correct means: don't call the function, always reuse the hasher's EVP_MD* context and never fall back to slow path silently. ---------- status: open -> pending versions: +Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 15:13:36 2017 From: report at bugs.python.org (Martin Liska) Date: Wed, 27 Dec 2017 20:13:36 +0000 Subject: [issue32434] pathlib.WindowsPath.reslove(strict=False) returns absoulte path only if at least one component exists Message-ID: <1514405616.88.0.213398074469.issue32434@psf.upfronthosting.co.za> New submission from Martin Liska : The documentation for pathlib.Path.resolve says: "Make the path absolute, resolving any symlinks." On Windows, the behavior doesn't always match the first part of the statement. Example: On a system with an existing, but empty directory C:\Test. Running the interpreter at C:\ resolve behaves like so: >>> os.path.realpath(r'Test\file') 'C:\\Test\\file' >>> WindowsPath(r'Test\file').resolve(strict=False) WindowsPath('C:/Test/file') When running the interpreter inside C:\Test it instead behaves in the following manner: >>> os.path.realpath('file') 'C:\\Test\\file' >>> WindowsPath('file').resolve(strict=False) WindowsPath('file') Resolving a path object specifying a non-existent relative path results in an identical (relative) path object. This is also inconsistent with the behavior of os.path.realpath as demonstrated. The root of the issue is in the pathlib._WindowsFlavour.resolve method at lines 193, 199 and 201. If at least one component of the path gets resolved at line 193 by the expression self._ext_to_normal(_getfinalpathname(s)), the path returned at line 201 will be joined from the absolute, resolved part and the unresolved remained. If none of the components get resolved then the path will be returned at line 199 as passed into the function. ---------- components: Library (Lib) messages: 309102 nosy: mliska priority: normal severity: normal status: open title: pathlib.WindowsPath.reslove(strict=False) returns absoulte path only if at least one component exists type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 15:17:36 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 27 Dec 2017 20:17:36 +0000 Subject: [issue17258] multiprocessing.connection challenge implicitly uses MD5 In-Reply-To: <1361391096.59.0.84157337171.issue17258@psf.upfronthosting.co.za> Message-ID: <1514405856.79.0.213398074469.issue17258@psf.upfronthosting.co.za> Christian Heimes added the comment: Dave, are you still interested to address the issue? I think it's a good idea to replace HMAC-MD5 in the long run. But instead of hard-coding another hash algorithm, I would like to see an improved handshake protocol that supports flexible authentication algorithms. You could send an algorithm indicator (e.g. HMAC_SHA256) in the request. It would be really cool to run multiprocessing protocol over TLS with support for SASL with SCRAM or EXTERNAL (TLS cert auth, AF_UNIX PEERCRED, GSSAPI)... ---------- status: open -> pending versions: +Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 15:52:54 2017 From: report at bugs.python.org (Armin Ronacher) Date: Wed, 27 Dec 2017 20:52:54 +0000 Subject: [issue21288] hashlib.pbkdf2_hmac Hash Constructor In-Reply-To: <1397760292.99.0.128790868195.issue21288@psf.upfronthosting.co.za> Message-ID: <1514407974.63.0.213398074469.issue21288@psf.upfronthosting.co.za> Armin Ronacher added the comment: Yes, I'm definitely still interested in this. I still carry this hack around. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 15:55:38 2017 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 27 Dec 2017 20:55:38 +0000 Subject: [issue8800] add threading.RWLock In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za> Message-ID: <1514408138.43.0.213398074469.issue8800@psf.upfronthosting.co.za> Change by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 16:01:48 2017 From: report at bugs.python.org (Julien Palard) Date: Wed, 27 Dec 2017 21:01:48 +0000 Subject: [issue31639] http.server and SimpleHTTPServer hang after a few requests In-Reply-To: <1506701944.65.0.213398074469.issue31639@psf.upfronthosting.co.za> Message-ID: <1514408508.83.0.213398074469.issue31639@psf.upfronthosting.co.za> Julien Palard added the comment: David you're right, I updated my patch, also added some documentation and a news entry. Glenn I can't tell if my PR fixes your issue without an strace or a test. It fixes the one I straced (pre-opening sockets leading to Python reading indefinitly on a socket which may never be used). If you could try my PR I would appreciate it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 16:56:20 2017 From: report at bugs.python.org (Sergey Petrunin) Date: Wed, 27 Dec 2017 21:56:20 +0000 Subject: [issue32435] tarfile recognizes .gz file as tar Message-ID: <1514411780.55.0.213398074469.issue32435@psf.upfronthosting.co.za> New submission from Sergey Petrunin : Library's function 'tarfile.is_tarfile' returns 'True' on GZip file (9.7 megabytes see attachment), that is a file with 10 gigabytes of '0' character compressed with 'gzip' utility (no 'tar' whatsoever). Desired result: this function should return False in this case, b.c. this file is not a tar file. ---------- components: Library (Lib) files: big_0_file_1.gz messages: 309106 nosy: spetrunin priority: normal severity: normal status: open title: tarfile recognizes .gz file as tar versions: Python 2.7, Python 3.6 Added file: https://bugs.python.org/file47353/big_0_file_1.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 17:08:54 2017 From: report at bugs.python.org (Christian Heimes) Date: Wed, 27 Dec 2017 22:08:54 +0000 Subject: [issue21288] hashlib.pbkdf2_hmac Hash Constructor In-Reply-To: <1397760292.99.0.128790868195.issue21288@psf.upfronthosting.co.za> Message-ID: <1514412534.94.0.213398074469.issue21288@psf.upfronthosting.co.za> Christian Heimes added the comment: Do you have a proper solution that works within the limits of PEP 247? I could not, hence the existing API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 17:24:14 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 27 Dec 2017 22:24:14 +0000 Subject: [issue32435] tarfile recognizes .gz file as tar In-Reply-To: <1514411780.55.0.213398074469.issue32435@psf.upfronthosting.co.za> Message-ID: <1514413454.2.0.213398074469.issue32435@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This file is a correct empty tar file. The tar utility accepts it too. $ tar tf big_0_file_1.gz; echo $? 0 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 17:59:03 2017 From: report at bugs.python.org (YoSTEALTH) Date: Wed, 27 Dec 2017 22:59:03 +0000 Subject: [issue32401] No module named '_ctypes' In-Reply-To: <1513884303.03.0.213398074469.issue32401@psf.upfronthosting.co.za> Message-ID: <1514415543.25.0.213398074469.issue32401@psf.upfronthosting.co.za> YoSTEALTH added the comment: Yes, it does work without pip. ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 18:56:05 2017 From: report at bugs.python.org (Glenn Linderman) Date: Wed, 27 Dec 2017 23:56:05 +0000 Subject: [issue31639] http.server and SimpleHTTPServer hang after a few requests In-Reply-To: <1506701944.65.0.213398074469.issue31639@psf.upfronthosting.co.za> Message-ID: <1514418965.54.0.213398074469.issue31639@psf.upfronthosting.co.za> Glenn Linderman added the comment: I don't know how to look back at the previous version of the PR, I was barely able to find the "current version" each time. The following line is in the current version: daemon_threads = True Whether it was in the previous version, I don't know, but I didn't notice it, but maybe I overlooked it due to other changes in the same area, which are now gone. This line was not in the old suggestion that I had found and tried. When I added it, my test case started working. I have no idea what the line really does, but the HTTP server is a daemon, and we are adding threading, so it sounds appropriate. I do wonder if it should somehow be put in the definition of ThreadedHTTPServer instead of "pass". And the old solution I had found had called the HTTPServer.__init__ which yours does not, which was surprising, but I'll not argue with success. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 19:01:18 2017 From: report at bugs.python.org (Armin Ronacher) Date: Thu, 28 Dec 2017 00:01:18 +0000 Subject: [issue21288] hashlib.pbkdf2_hmac Hash Constructor In-Reply-To: <1397760292.99.0.128790868195.issue21288@psf.upfronthosting.co.za> Message-ID: <1514419278.45.0.213398074469.issue21288@psf.upfronthosting.co.za> Armin Ronacher added the comment: I have no good solution. What I do so far is pretty much exactly what was originally reported here: https://github.com/pallets/werkzeug/blob/6922d883ba61c6884fa6cab5bfd280c5a60399af/werkzeug/security.py#L96-L104 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 19:19:31 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 28 Dec 2017 00:19:31 +0000 Subject: [issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass In-Reply-To: <1514313248.8.0.213398074469.issue32428@psf.upfronthosting.co.za> Message-ID: <1514420371.28.0.213398074469.issue32428@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: > I'm not sure I understand the distinction. Initially I thought about only flagging code like this: @dataclass class C: x = field() But not this: @dataclass class C: x = 42 Now I think we should probably flag both as errors. > How do we only pick out `y` and probably `prop`, and ignore the rest, without being overly fragile to new things being added? I guess ignoring dunders and things in `__annotations__`. Is that close enough? We had a similar problem while developing Protocol class (PEP 544). Currently we just a have a whitelist of names that are skipped: '__abstractmethods__', '__annotations__', '__weakref__', '__dict__', '__slots__', '__doc__', '__module__' (plus some internal typing API names) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 19:24:57 2017 From: report at bugs.python.org (Ilya Kulakov) Date: Thu, 28 Dec 2017 00:24:57 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1514420697.83.0.213398074469.issue22273@psf.upfronthosting.co.za> Ilya Kulakov added the comment: Is there anything to be done for this patch to get merged? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 20:12:23 2017 From: report at bugs.python.org (shangdahao) Date: Thu, 28 Dec 2017 01:12:23 +0000 Subject: [issue32337] Dict order is now guaranteed, so add tests and doc for it In-Reply-To: <1514287514.34.0.213398074469.issue32337@psf.upfronthosting.co.za> Message-ID: <1514423543.14.0.213398074469.issue32337@psf.upfronthosting.co.za> shangdahao added the comment: Thanks inada, I removed the tests from the PR. ---------- nosy: +shangdahao _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 22:41:34 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 28 Dec 2017 03:41:34 +0000 Subject: [issue25942] Add a new optional cleanup_timeout parameter to subprocess.call() In-Reply-To: <1451006108.23.0.113868196098.issue25942@psf.upfronthosting.co.za> Message-ID: <1514432494.54.0.213398074469.issue25942@psf.upfronthosting.co.za> Change by Gregory P. Smith : ---------- pull_requests: +4914 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 27 23:08:03 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 28 Dec 2017 04:08:03 +0000 Subject: [issue25942] Add a new optional cleanup_timeout parameter to subprocess.call() In-Reply-To: <1451006108.23.0.113868196098.issue25942@psf.upfronthosting.co.za> Message-ID: <1514434083.36.0.213398074469.issue25942@psf.upfronthosting.co.za> Gregory P. Smith added the comment: you'll notice I added an alternate PR. I don't like the complication of adding yet another knob (cleanup_timeout) to subprocesses already giant API surface. It will rarely be used. My PR tries to take a practical approach: Just wait a little while (arbitrary value of little chosen in the code) for the child after receiving SIGINT before reraising the exception and triggering a .kill() matching existing behavior. The one controversial thing in my PR (which could be undone, it is independent of the other changes) is that I also modify the context manager __exit__ behavior to not do an infinite wait() upon KeyboardInterrupt. This means context managers of Popen _will_ complete potentially leaving a dangling process around (which our existing __del__ will pick up and put in the internal subprocess._active list). Relatively harmless, but a change none-the-less. I went that far to try and better match the Python 2.7 and 3.2 behavior: On SIGINT our process sees the KeyboardInterrupt "right away" (not quite as instantaneously here given the wait timeouts, but close enough for interactive command line tool ^C happiness). It seems like an improvement all around and is IMNSHO less complicated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 00:20:05 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 Dec 2017 05:20:05 +0000 Subject: [issue32436] Implement PEP 567 Message-ID: <1514438405.44.0.213398074469.issue32436@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- assignee: yselivanov components: Interpreter Core, Library (Lib) nosy: gvanrossum, yselivanov priority: normal severity: normal stage: patch review status: open title: Implement PEP 567 type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 00:24:23 2017 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 28 Dec 2017 05:24:23 +0000 Subject: [issue32436] Implement PEP 567 Message-ID: <1514438663.11.0.213398074469.issue32436@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4915 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 02:13:26 2017 From: report at bugs.python.org (Srinivas Reddy T) Date: Thu, 28 Dec 2017 07:13:26 +0000 Subject: [issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514445206.25.0.213398074469.issue32424@psf.upfronthosting.co.za> Srinivas Reddy T added the comment: Renaming the method `copy()` to `__copy__` breaks the API. I would rather have an alias for `__copy__`. I agree that it is not documented, but some users tend to assume public methods are documented and use them. So i think it is better to not to break their code. ---------- nosy: +thatiparthy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 03:48:55 2017 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 28 Dec 2017 08:48:55 +0000 Subject: [issue32437] UnicodeError: 'IDNA does not round-trip' Message-ID: <1514450935.58.0.213398074469.issue32437@psf.upfronthosting.co.za> New submission from ???? ????????? : First: This is the bug: In [1]: 'gro?handel-shop'.encode('idna') Out[1]: b'grosshandel-shop' This lead to this: 'xn--einla-pqa'.decode('idna') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.6/encodings/idna.py", line 214, in decode result.append(ToUnicode(label)) File "/usr/lib/python3.6/encodings/idna.py", line 139, in ToUnicode raise UnicodeError("IDNA does not round-trip", label, label2) UnicodeError: ('IDNA does not round-trip', b'xn--einla-pqa', b'einlass') https://stackoverflow.com/questions/9806036/idna-does-not-round-trip xn--grohandel-shop-2fb has been correctly encoded by IDNA 2008 (which is correct in Germany/DENIC since a while). Your Python very likely tries to decode it using the old IDNA 2003, which doesn't know '?'. see denic.de/en/know-how/idn-domains ---------- components: Unicode messages: 309117 nosy: ezio.melotti, socketpair, vstinner priority: normal severity: normal status: open title: UnicodeError: 'IDNA does not round-trip' type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 04:36:21 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 28 Dec 2017 09:36:21 +0000 Subject: [issue32437] UnicodeError: 'IDNA does not round-trip' In-Reply-To: <1514450935.58.0.213398074469.issue32437@psf.upfronthosting.co.za> Message-ID: <1514453781.49.0.213398074469.issue32437@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 05:19:07 2017 From: report at bugs.python.org (Berker Peksag) Date: Thu, 28 Dec 2017 10:19:07 +0000 Subject: [issue32437] UnicodeError: 'IDNA does not round-trip' In-Reply-To: <1514450935.58.0.213398074469.issue32437@psf.upfronthosting.co.za> Message-ID: <1514456347.57.0.213398074469.issue32437@psf.upfronthosting.co.za> Berker Peksag added the comment: There is an open issue about adding IDNA 2008 support: Issue 17305. Closing this one as a duplicate of that issue. ---------- nosy: +berker.peksag resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> IDNA2008 encoding missing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 05:19:25 2017 From: report at bugs.python.org (Erik Bray) Date: Thu, 28 Dec 2017 10:19:25 +0000 Subject: [issue32438] PyLong_ API cleanup Message-ID: <1514456365.15.0.213398074469.issue32438@psf.upfronthosting.co.za> New submission from Erik Bray : Per Serhiy's comment in this thread https://mail.python.org/pipermail/python-ideas/2017-December/048413.html (which I agree with), several of the PyLong_ functions have behavior carried over from Python 2 of calling __int__ on their arguments if the input is not a PyLongObject: PyLong_AsLong PyLong_AsLongAndOverflow PyLong_AsLongLong PyLong_AsLongLongAndOverflow PyLong_AsUnsignedLongMask PyLong_AsUnsignedLongLongMask This behavior should probably be deprecated, and eventually removed. Interfaces that should accept generic number-like objects should use the PyNumber API instead. ---------- components: Interpreter Core messages: 309119 nosy: erik.bray priority: normal severity: normal status: open title: PyLong_ API cleanup type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 06:03:55 2017 From: report at bugs.python.org (Julien Palard) Date: Thu, 28 Dec 2017 11:03:55 +0000 Subject: [issue31639] http.server and SimpleHTTPServer hang after a few requests In-Reply-To: <1506701944.65.0.213398074469.issue31639@psf.upfronthosting.co.za> Message-ID: <1514459035.67.0.213398074469.issue31639@psf.upfronthosting.co.za> Julien Palard added the comment: Glenn you're right I modified my PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 06:12:01 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 28 Dec 2017 11:12:01 +0000 Subject: [issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514459521.74.0.213398074469.issue32424@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Agree with Srinivas ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 06:19:20 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 28 Dec 2017 11:19:20 +0000 Subject: [issue17305] IDNA2008 encoding missing In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za> Message-ID: <1514459960.18.0.213398074469.issue17305@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 06:19:20 2017 From: report at bugs.python.org (Julien Palard) Date: Thu, 28 Dec 2017 11:19:20 +0000 Subject: [issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514459960.66.0.213398074469.issue32424@psf.upfronthosting.co.za> Julien Palard added the comment: I don't agree with the API breakage, the C implementation of the module does not expose copy(), so code using copy() is already broken (since 2005) in cases the C implementation is used. I also expect the C implementation to be used almost anywhere, but I may be wrong on this point: in which case the Python implementation may still be used? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 06:23:41 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Dec 2017 11:23:41 +0000 Subject: [issue32439] Clean up the code for compiling comparison expressions Message-ID: <1514460221.23.0.213398074469.issue32439@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : The proposed PR cleans up the code for compiling comparison expressions. It makes it similar to specialized copy added in bpo-30501. ---------- assignee: serhiy.storchaka components: Interpreter Core messages: 309123 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Clean up the code for compiling comparison expressions versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 06:25:08 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Dec 2017 11:25:08 +0000 Subject: [issue32439] Clean up the code for compiling comparison expressions In-Reply-To: <1514460221.23.0.213398074469.issue32439@psf.upfronthosting.co.za> Message-ID: <1514460308.64.0.213398074469.issue32439@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +4916 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 06:38:40 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 28 Dec 2017 11:38:40 +0000 Subject: [issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514461120.45.0.213398074469.issue32424@psf.upfronthosting.co.za> Andrew Svetlov added the comment: pypy for example has Element.copy() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 06:41:58 2017 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 28 Dec 2017 11:41:58 +0000 Subject: [issue32432] [BUG] Python vs Macbook High Sierra 10.13.2 In-Reply-To: <1514395616.6.0.213398074469.issue32432@psf.upfronthosting.co.za> Message-ID: <1514461318.92.0.213398074469.issue32432@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Did you install ActiveState's distribution of Tk as described here: https://www.python.org/download/mac/tcltk/ ? Sadly enough the version of Tcl/Tk shipped by Apple contains a number of bugs that cause problems for Tkinter applications like IDLE. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 07:05:05 2017 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 28 Dec 2017 12:05:05 +0000 Subject: [issue22273] abort when passing certain structs by value using ctypes In-Reply-To: <1408988002.99.0.886549500758.issue22273@psf.upfronthosting.co.za> Message-ID: <1514462705.35.0.213398074469.issue22273@psf.upfronthosting.co.za> Vinay Sajip added the comment: Yes, the patch needs improving as per the suggestion in msg288493 (not had the time since to do any work on it), followed by a review of the changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 07:08:12 2017 From: report at bugs.python.org (Old K) Date: Thu, 28 Dec 2017 12:08:12 +0000 Subject: [issue32440] Use HTTPS in help() Message-ID: <1514462892.59.0.213398074469.issue32440@psf.upfronthosting.co.za> New submission from Old K : In python3, in the output of help(), there is link http://docs.python.org/3.6/tutorial/. It should be made into https. There are already some issues about changing http links to https: https://bugs.python.org/issue25910 https://bugs.python.org/issue26736 But this link is still unchanged. ---------- assignee: docs at python components: Documentation messages: 309127 nosy: Old K, docs at python priority: normal severity: normal status: open title: Use HTTPS in help() versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 07:17:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Dec 2017 12:17:26 +0000 Subject: [issue32440] Use HTTPS in help() In-Reply-To: <1514462892.59.0.213398074469.issue32440@psf.upfronthosting.co.za> Message-ID: <1514463446.92.0.213398074469.issue32440@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +4917 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 07:18:30 2017 From: report at bugs.python.org (Old K) Date: Thu, 28 Dec 2017 12:18:30 +0000 Subject: [issue32440] Use HTTPS in help() In-Reply-To: <1514462892.59.0.213398074469.issue32440@psf.upfronthosting.co.za> Message-ID: <1514463510.06.0.213398074469.issue32440@psf.upfronthosting.co.za> Old K added the comment: I have created a pull request at: https://github.com/python/cpython/pull/5030 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 07:27:06 2017 From: report at bugs.python.org (Felipe Filgueira Barral) Date: Thu, 28 Dec 2017 12:27:06 +0000 Subject: [issue32432] [BUG] Python vs Macbook High Sierra 10.13.2 In-Reply-To: <1514395616.6.0.213398074469.issue32432@psf.upfronthosting.co.za> Message-ID: <1514464026.96.0.213398074469.issue32432@psf.upfronthosting.co.za> Change by Felipe Filgueira Barral : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 07:28:08 2017 From: report at bugs.python.org (Felipe Filgueira Barral) Date: Thu, 28 Dec 2017 12:28:08 +0000 Subject: [issue32432] [BUG] Python vs Macbook High Sierra 10.13.2 In-Reply-To: <1514395616.6.0.213398074469.issue32432@psf.upfronthosting.co.za> Message-ID: <1514464088.42.0.213398074469.issue32432@psf.upfronthosting.co.za> Felipe Filgueira Barral added the comment: Tks Ronald, solve the problem! =) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 09:37:49 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 28 Dec 2017 14:37:49 +0000 Subject: [issue32440] Use HTTPS in help() In-Reply-To: <1514462892.59.0.213398074469.issue32440@psf.upfronthosting.co.za> Message-ID: <1514471869.56.0.213398074469.issue32440@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset e5681b9822c633c77ddfeb94585d58895e0ecff5 by Mariatta (oldk) in branch 'master': bpo-32440: Update the docs URL to https in help() (GH-5030) https://github.com/python/cpython/commit/e5681b9822c633c77ddfeb94585d58895e0ecff5 ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 09:38:13 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Dec 2017 14:38:13 +0000 Subject: [issue32440] Use HTTPS in help() In-Reply-To: <1514462892.59.0.213398074469.issue32440@psf.upfronthosting.co.za> Message-ID: <1514471893.76.0.213398074469.issue32440@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4918 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 10:07:42 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Thu, 28 Dec 2017 15:07:42 +0000 Subject: [issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514473662.65.0.213398074469.issue32424@psf.upfronthosting.co.za> Gordon P. Hemsley added the comment: Two notes: * It appears that pypy is based on no more recent than Python 3.5, so this wouldn't immediately break them. (3.6 support is maybe in development?) * pypy appears to have already made other adjustments due to the differences between the Python and C implementations: https://bitbucket.org/pypy/pypy/diff/lib-python/3/xml/etree/ElementTree.py?diff2=0939e3a8a08d&at=py3.5 That said, I'm neutral on the subject. I'm happy to implement whichever option you decide on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 10:16:41 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 28 Dec 2017 15:16:41 +0000 Subject: [issue32440] Use HTTPS in help() In-Reply-To: <1514462892.59.0.213398074469.issue32440@psf.upfronthosting.co.za> Message-ID: <1514474201.97.0.213398074469.issue32440@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset 6eb232c52a03e31fc47842e70fc7833198744c2b by Mariatta (Miss Islington (bot)) in branch '3.6': bpo-32440: Update the docs URL to https in help() (GH-5030) (GH-5031) https://github.com/python/cpython/commit/6eb232c52a03e31fc47842e70fc7833198744c2b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 10:17:40 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 28 Dec 2017 15:17:40 +0000 Subject: [issue32440] Use HTTPS in help() In-Reply-To: <1514462892.59.0.213398074469.issue32440@psf.upfronthosting.co.za> Message-ID: <1514474260.91.0.213398074469.issue32440@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 11:14:40 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 28 Dec 2017 16:14:40 +0000 Subject: [issue17258] multiprocessing.connection challenge implicitly uses MD5 In-Reply-To: <1361391096.59.0.84157337171.issue17258@psf.upfronthosting.co.za> Message-ID: <1514477680.0.0.213398074469.issue17258@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Indeed, we probably want a flexible handshake mechanism. This needn't be very optimized: probably a magic number followed by a JSON-encoded dict is sufficient. (of course, several years down the road, someone will engineer a downgrade attack) ---------- nosy: +pitrou status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 12:44:43 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 28 Dec 2017 17:44:43 +0000 Subject: [issue32441] os.dup2 should return the new fd Message-ID: <1514483083.55.0.213398074469.issue32441@psf.upfronthosting.co.za> New submission from Benjamin Peterson : os.dup2 currently always None. However, the underlying standard Unix function returns the new file descriptor (i.e., the second argument) on success. We should follow that convention, too. ---------- components: Extension Modules keywords: easy messages: 309135 nosy: benjamin.peterson priority: low severity: normal stage: needs patch status: open title: os.dup2 should return the new fd versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 12:59:44 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Dec 2017 17:59:44 +0000 Subject: [issue32438] PyLong_ API cleanup In-Reply-To: <1514456365.15.0.213398074469.issue32438@psf.upfronthosting.co.za> Message-ID: <1514483984.69.0.213398074469.issue32438@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue17576. And there may be other related issues. ---------- nosy: +lemburg, mark.dickinson, serhiy.storchaka, stutzbach versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 13:17:11 2017 From: report at bugs.python.org (Greg Lindahl) Date: Thu, 28 Dec 2017 18:17:11 +0000 Subject: [issue17305] IDNA2008 encoding missing In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za> Message-ID: <1514485031.27.0.213398074469.issue17305@psf.upfronthosting.co.za> Change by Greg Lindahl : ---------- nosy: +wumpus _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 13:48:56 2017 From: report at bugs.python.org (Paul Ganssle) Date: Thu, 28 Dec 2017 18:48:56 +0000 Subject: [issue10381] Add timezone support to datetime C API In-Reply-To: <1289415057.12.0.111170767809.issue10381@psf.upfronthosting.co.za> Message-ID: <1514486936.61.0.213398074469.issue10381@psf.upfronthosting.co.za> Change by Paul Ganssle : ---------- nosy: +p-ganssle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 14:09:57 2017 From: report at bugs.python.org (Tzu-ping Chung) Date: Thu, 28 Dec 2017 19:09:57 +0000 Subject: [issue32442] Result of pathlib.Path.resolve() with UNC path is not very useful Message-ID: <1514488197.55.0.213398074469.issue32442@psf.upfronthosting.co.za> New submission from Tzu-ping Chung : The behaviour of os.path.abspath() and pathlib.Path.resolve() is a different when dealing with a path on a UNC share (on Windows): >>> import os, pathlib >>> path = pathlib.Path('Z:\foo') >>> path.resolve() WindowsPath('//host/share/foo') >>> os.path.abspath(path) 'Z:\\foo' This is not necessarily a problem by itself, just a consequence of calling different APIs underneath (although it probably worths a mention in documentation). The real problem is that the UNC path is not really useful anywhere in the Python standard library (AFAIK), and there?s no way to turn the it (back) into network drive once you call resolve(). The only way to get a network drive path is to >>> pathlib.Path(os.path.abspath(path)) Some possibile solutions: 1. Change the behaviour of resolve() to return the network drive path instead. This would be the most straightforward, API-wise, but is backward-incompatible, and maybe the original implementation did this on purpose? 2. Add a as_absolute() to pathlib.Path. On Windows this would mirror the result of os.path.abspath(); on POSIX this would probably be identical to resolve(). 3. Add an argument to resolve()? This is essentially the same as 2., just interfaced differently. ---------- components: Library (Lib), Windows messages: 309137 nosy: paul.moore, steve.dower, tim.golden, uranusjr, zach.ware priority: normal severity: normal status: open title: Result of pathlib.Path.resolve() with UNC path is not very useful versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 14:39:21 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Dec 2017 19:39:21 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1514489961.2.0.213398074469.issue17611@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Results of microbenchmarks: $ ./python -m perf timeit -s 'a = list(range(1000))' -- 'for i in a: pass' Mean +- std dev: 6.31 us +- 0.09 us $ ./python -m perf timeit -s 'a = list(range(1000))' -- ' for i in a: try: pass finally: pass ' Unpatched: Mean +- std dev: 16.3 us +- 0.2 us PR 2827: Mean +- std dev: 16.2 us +- 0.2 us PR 4682: Mean +- std dev: 16.2 us +- 0.2 us PR 5006: Mean +- std dev: 14.5 us +- 0.4 us $ ./python -m perf timeit -s 'a = list(range(1000))' -- ' for i in a: try: continue finally: pass ' Unpatched: Mean +- std dev: 24.0 us +- 0.5 us PR 2827: Mean +- std dev: 11.9 us +- 0.1 us PR 4682: Mean +- std dev: 12.0 us +- 0.1 us PR 5006: Mean +- std dev: 19.0 us +- 0.3 us $ ./python -m perf timeit -s 'a = list(range(1000))' -- ' for i in a: while True: try: break finally: pass ' Unpatched: Mean +- std dev: 25.9 us +- 0.5 us PR 2827: Mean +- std dev: 11.9 us +- 0.1 us PR 4682: Mean +- std dev: 12.0 us +- 0.1 us PR 5006: Mean +- std dev: 18.9 us +- 0.1 us PR 2827 and PR 4682 have the same performance. The overhead of the finally block is smaller in PR 5006, perhaps because BEGIN_FINALLY pushes 1 NULL instead of 6 NULLs. CALL_FINALLY adds 4.5 ns in the latter too examples. This overhead could be decreased by using special cache for Python integers that represent return addresses or using separate stack for return addresses. But this looks as an overkill to me now. 4.5 ns is pretty small overhead, the simple `i = i` have the same timing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 14:41:50 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 28 Dec 2017 19:41:50 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1514490110.22.0.213398074469.issue17611@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes, those benchmarks look fine. Have you tried with the benchmarks suite? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 14:42:41 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 28 Dec 2017 19:42:41 +0000 Subject: [issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514490161.63.0.213398074469.issue32424@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I mean dropping `.copy()` breaks not only compatibility between pure python versions but also between pypy releases and pypy/CPython code. That's why I suggest to keep `.copy()` as an alias for `__copy__()`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 14:53:12 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Dec 2017 19:53:12 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1514490792.92.0.213398074469.issue17611@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't expect any differences in macrobenchamrks. try/except/finally are rarely used in tight loops. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 15:20:23 2017 From: report at bugs.python.org (Paul Ganssle) Date: Thu, 28 Dec 2017 20:20:23 +0000 Subject: [issue10381] Add timezone support to datetime C API In-Reply-To: <1289415057.12.0.111170767809.issue10381@psf.upfronthosting.co.za> Message-ID: <1514492423.08.0.213398074469.issue10381@psf.upfronthosting.co.za> Change by Paul Ganssle : ---------- keywords: +patch pull_requests: +4919 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 16:48:48 2017 From: report at bugs.python.org (Paul Ganssle) Date: Thu, 28 Dec 2017 21:48:48 +0000 Subject: [issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514497728.85.0.213398074469.issue32424@psf.upfronthosting.co.za> Paul Ganssle added the comment: > I mean dropping `.copy()` breaks not only compatibility between pure python versions but also between pypy releases and pypy/CPython code. That's why I suggest to keep `.copy()` as an alias for `__copy__()`. If the main issue is that pypy users have been using this, can't pypy just keep an alias for `copy` around, possibly with a DeprecationWarning? ---------- nosy: +p-ganssle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 17:16:35 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 28 Dec 2017 22:16:35 +0000 Subject: [issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514499395.08.0.213398074469.issue32424@psf.upfronthosting.co.za> Andrew Svetlov added the comment: For derivative Python implementation there is a standard strategy: they uses a copy of CPython standard library. Tthat's why any new module should have a pure Python implementation and that's why https://www.python.org/dev/peps/pep-0399/ exists. Jython has copy() method as well. IronPython has it. I doubt if an implementation without xml.etree.ElementTree.Element.copy exists at all. The method removal breaks backward compatibility without a reason, __copy__ alias is valuable and backward compatible change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 17:22:10 2017 From: report at bugs.python.org (Paul Ganssle) Date: Thu, 28 Dec 2017 22:22:10 +0000 Subject: [issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514499730.77.0.213398074469.issue32424@psf.upfronthosting.co.za> Paul Ganssle added the comment: @Andrew Are you suggesting that a `copy` method be *added* to the C implementation, as an alias to __copy__? Because it makes no sense to keep the pure Python and C implementations out of sync just so that it's easier for projects forking the pure Python implementation to maintain backwards compatibility with their earlier implementations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 17:25:52 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 28 Dec 2017 22:25:52 +0000 Subject: [issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514499952.03.0.213398074469.issue32424@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Yes. For designing from scratch copy() is not necessary but if we have it for decade -- better to unify pure Python and C implementation by adding missing methods. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 17:48:38 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 28 Dec 2017 22:48:38 +0000 Subject: [issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514501318.52.0.213398074469.issue32424@psf.upfronthosting.co.za> R. David Murray added the comment: Paul Ganssle: Even if Andrew were not suggesting adding copy to the C implementation (I have no opinion on that currently), it would still be correct to maintain backward compatibility in the python version in the standard library. We do not consider the standard library to be CPython specific, even though parts of it are. There is no "fork" involved in other projects using it, from our point of view. Quite the opposite, where possible. We have given commit rights to developers from other python implementations specifically so they can contribute things that improve compatibility in the standard library and standard library test suite for those other python implementations. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 18:01:32 2017 From: report at bugs.python.org (Paul Ganssle) Date: Thu, 28 Dec 2017 23:01:32 +0000 Subject: [issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514502092.76.0.213398074469.issue32424@psf.upfronthosting.co.za> Paul Ganssle added the comment: > There is no "fork" involved in other projects using it, from our point of view. I did not mean "fork" in some judgmental sense, I'm mostly just familiar with pypy, but I was under the impression that other projects were *literally* forking the standard library as a practical matter. I get the impression that other interpreters maintain a patched interpreter often for the purposes of adding fixes like the one pointed out in msg309131 which bring the behavior of the Python implementation of the standard library into line with the C implementations, since the C version is the de facto standard (since most code is written and tested only for CPython). I'd be fine with adding a C alias for `copy`, though as a purely practical matter, I strongly suspect that dropping `copy` from the pure Python implementation would not be a huge deal, but if that breaks the contract it breaks the contract. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 18:20:05 2017 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 28 Dec 2017 23:20:05 +0000 Subject: [issue32442] Result of pathlib.Path.resolve() with UNC path is not very useful In-Reply-To: <1514488197.55.0.213398074469.issue32442@psf.upfronthosting.co.za> Message-ID: <1514503205.51.0.213398074469.issue32442@psf.upfronthosting.co.za> Eric V. Smith added the comment: I'm not sure how pathlib.Path('Z:\foo') gives an answer with 'foo' in it, since '\f' is a formfeed. Is this the exact output that you're showing? Can you try with r'Z:\foo', 'Z:\\foo', or 'Z:/foo' and see what that produces? ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 18:29:43 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 28 Dec 2017 23:29:43 +0000 Subject: [issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514503783.08.0.213398074469.issue32424@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, that's why I said "from our point of view" :) I know there is usually a fork in the practical sense, but we want to make it as easy as practical to sync that fork, which includes not breaking things in the python versions without good reason. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 20:21:11 2017 From: report at bugs.python.org (Kaoru Kitamura) Date: Fri, 29 Dec 2017 01:21:11 +0000 Subject: [issue32420] LookupError : unknown encoding : [0x7FF092395AD0] ANOMALY In-Reply-To: <1514082037.96.0.213398074469.issue32420@psf.upfronthosting.co.za> Message-ID: <1514510471.66.0.213398074469.issue32420@psf.upfronthosting.co.za> Kaoru Kitamura added the comment: Does somebody know what causes above? ---------- resolution: -> remind _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 20:27:21 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 29 Dec 2017 01:27:21 +0000 Subject: [issue32443] Add Linux's signalfd() to the signal module Message-ID: <1514510840.93.0.213398074469.issue32443@psf.upfronthosting.co.za> New submission from Gregory P. Smith : We should add a wrapper for both signalfd() and a function to read and decode the structure from the fd into a dataclass. The code we need to build such a thing from appears to exist in BSD & MIT licensed form in: PyPI contains two extension module wrappers of just the system call: https://pypi.python.org/pypi/signalfd/ https://pypi.python.org/pypi/python-signalfd Why add this Linux specific API to the standard library? I believe I could use signalfd() within the subprocess module to get rid of the need to busy-loop-poll to see when children have exited on subprocess.Popen.wait() calls with a timeout. [a proof of concept using the above modules would be a good idea first] ---------- components: Library (Lib) messages: 309151 nosy: gregory.p.smith priority: normal severity: normal stage: needs patch status: open title: Add Linux's signalfd() to the signal module type: enhancement versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 20:30:32 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 29 Dec 2017 01:30:32 +0000 Subject: [issue24960] Can't use lib2to3 with embeddable zip file. In-Reply-To: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za> Message-ID: <1514511032.79.0.213398074469.issue24960@psf.upfronthosting.co.za> Change by Benjamin Peterson : ---------- pull_requests: +4920 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 20:39:44 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 29 Dec 2017 01:39:44 +0000 Subject: [issue32443] Add Linux's signalfd() to the signal module In-Reply-To: <1514510840.93.0.213398074469.issue32443@psf.upfronthosting.co.za> Message-ID: <1514511584.88.0.213398074469.issue32443@psf.upfronthosting.co.za> Gregory P. Smith added the comment: An example subprocess improvement using sigtimedwait() - https://github.com/python/cpython/pull/5035 - led me to believe that signalfd() is superior as it sounds like signalfd() does not require pthread_sigmask (sigprocmask) global state manipulation calls. I have not confirmed if that is true. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 20:54:14 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 29 Dec 2017 01:54:14 +0000 Subject: [issue24960] Can't use lib2to3 with embeddable zip file. In-Reply-To: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za> Message-ID: <1514512454.45.0.213398074469.issue24960@psf.upfronthosting.co.za> Benjamin Peterson added the comment: New changeset e5f7dccefaa8d97ab53b3051acbb4a4d49379dc4 by Benjamin Peterson in branch 'master': make PatternCompiler use the packaged grammar if possible (more bpo-24960) (#5034) https://github.com/python/cpython/commit/e5f7dccefaa8d97ab53b3051acbb4a4d49379dc4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 20:54:26 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 29 Dec 2017 01:54:26 +0000 Subject: [issue24960] Can't use lib2to3 with embeddable zip file. In-Reply-To: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za> Message-ID: <1514512466.13.0.213398074469.issue24960@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4921 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 20:55:23 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 29 Dec 2017 01:55:23 +0000 Subject: [issue24960] Can't use lib2to3 with embeddable zip file. In-Reply-To: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za> Message-ID: <1514512523.25.0.213398074469.issue24960@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4922 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 21:05:09 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 29 Dec 2017 02:05:09 +0000 Subject: [issue24960] Can't use lib2to3 with embeddable zip file. In-Reply-To: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za> Message-ID: <1514513109.74.0.213398074469.issue24960@psf.upfronthosting.co.za> Benjamin Peterson added the comment: New changeset 417f76a20e93044e422fb328a2d8e200fc6df295 by Benjamin Peterson (Miss Islington (bot)) in branch '2.7': make PatternCompiler use the packaged grammar if possible (more bpo-24960) (GH-5034) (#5037) https://github.com/python/cpython/commit/417f76a20e93044e422fb328a2d8e200fc6df295 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 21:12:43 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 29 Dec 2017 02:12:43 +0000 Subject: [issue24960] Can't use lib2to3 with embeddable zip file. In-Reply-To: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za> Message-ID: <1514513563.44.0.213398074469.issue24960@psf.upfronthosting.co.za> Benjamin Peterson added the comment: New changeset 85f71aa9d6f834c7d64e979009c8fda0f19b585d by Benjamin Peterson (Miss Islington (bot)) in branch '3.6': make PatternCompiler use the packaged grammar if possible (more bpo-24960) (GH-5034) (#5036) https://github.com/python/cpython/commit/85f71aa9d6f834c7d64e979009c8fda0f19b585d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 21:17:21 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 29 Dec 2017 02:17:21 +0000 Subject: [issue32420] LookupError : unknown encoding : [0x7FF092395AD0] ANOMALY In-Reply-To: <1514082037.96.0.213398074469.issue32420@psf.upfronthosting.co.za> Message-ID: <1514513841.87.0.213398074469.issue32420@psf.upfronthosting.co.za> R. David Murray added the comment: Well, it's not obvious that it has anything to do with CPython itself. You should probably work with the community responsible for tensorflow, whatever that is, and if they find a bug in CPython you can come back here with a report. Given the error message it looks like an invalid value is being passed to CPython as the system encoding, so most likely the bug is in tensorflow and/or your environment. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 21:48:17 2017 From: report at bugs.python.org (Corey Seliger) Date: Fri, 29 Dec 2017 02:48:17 +0000 Subject: [issue32444] python -m venv has incongruous behavor creating binaries Message-ID: <1514515697.43.0.213398074469.issue32444@psf.upfronthosting.co.za> New submission from Corey Seliger : The venv module does not evenly create the necessary binaries/symlinks when building virtualenvs. If you call venv like this: seliger at core:~/venvs$ python3 -m venv venvA seliger at core:~/venvs$ ls -l venvA/bin/ total 32 -rw-r--r-- 1 seliger seliger 2143 Dec 28 21:29 activate -rw-r--r-- 1 seliger seliger 1259 Dec 28 21:29 activate.csh -rw-r--r-- 1 seliger seliger 2397 Dec 28 21:29 activate.fish -rwxrwxr-x 1 seliger seliger 254 Dec 28 21:29 easy_install -rwxrwxr-x 1 seliger seliger 254 Dec 28 21:29 easy_install-3.5 -rwxrwxr-x 1 seliger seliger 226 Dec 28 21:29 pip -rwxrwxr-x 1 seliger seliger 226 Dec 28 21:29 pip3 -rwxrwxr-x 1 seliger seliger 226 Dec 28 21:29 pip3.5 lrwxrwxrwx 1 seliger seliger 7 Dec 28 21:29 python -> python3 lrwxrwxrwx 1 seliger seliger 16 Dec 28 21:29 python3 -> /usr/bin/python3 ...you do not end up with a "python3.5" binary. However, if you call venv like this: seliger at core:~/venvs$ python3.5 -m venv venvB seliger at core:~/venvs$ ls -l venvB/bin total 32 -rw-r--r-- 1 seliger seliger 2143 Dec 28 21:29 activate -rw-r--r-- 1 seliger seliger 1259 Dec 28 21:29 activate.csh -rw-r--r-- 1 seliger seliger 2397 Dec 28 21:29 activate.fish -rwxrwxr-x 1 seliger seliger 256 Dec 28 21:29 easy_install -rwxrwxr-x 1 seliger seliger 256 Dec 28 21:29 easy_install-3.5 -rwxrwxr-x 1 seliger seliger 228 Dec 28 21:29 pip -rwxrwxr-x 1 seliger seliger 228 Dec 28 21:29 pip3 -rwxrwxr-x 1 seliger seliger 228 Dec 28 21:29 pip3.5 lrwxrwxrwx 1 seliger seliger 9 Dec 28 21:29 python -> python3.5 lrwxrwxrwx 1 seliger seliger 9 Dec 28 21:29 python3 -> python3.5 lrwxrwxrwx 1 seliger seliger 18 Dec 28 21:29 python3.5 -> /usr/bin/python3.5 ...you DO get the necessary python3.5 binary. Some vendors are making it a requirement to call a specific pythonX.Y binary to ensure compatibility. One such example is the serverless framework when deploying to Amazon Web Services. Another example is the useful pyenv utility that manages full Python builds and virtualenvs. When it depends upon venv, it exhibits the same behavior. I submitted a patch workaround to force calling venv using pythonX.Y, but this really seems like an issue with the venv module itself. The expected behavior should be that venv generates all three binaries (python, python3, and python3.5) regardless of how the python command was invoked. I am able to reproduce this on Python 3.5 and 3.6. I could not find any other similar references in searching the bug system. ---------- components: Library (Lib) messages: 309157 nosy: seliger priority: normal severity: normal status: open title: python -m venv has incongruous behavor creating binaries type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 21:54:22 2017 From: report at bugs.python.org (Corey Seliger) Date: Fri, 29 Dec 2017 02:54:22 +0000 Subject: [issue32444] python -m venv has incongruous behavor creating binaries In-Reply-To: <1514515697.43.0.213398074469.issue32444@psf.upfronthosting.co.za> Message-ID: <1514516062.42.0.213398074469.issue32444@psf.upfronthosting.co.za> Corey Seliger added the comment: Here is the write-up I posted over on the pyenv issues page: This is apparently a behavior issue in the way venv works. Not only does this impact 3.6.x, I also confirmed that the same issue occurs with venv in general using the stock 3.5 Python that comes with Ubuntu 16.04. The trouble is at 3.6/Lib/venv/__init__.py:111. Starting at line 111: if sys.platform == 'darwin' and '__PYVENV_LAUNCHER__' in env: executable = os.environ['__PYVENV_LAUNCHER__'] else: executable = sys.executable dirname, exename = os.path.split(os.path.abspath(executable)) context.executable = executable This carries down to the setup_python method starting at line 187 (3.6/Lib/venv/__init__.py:187). It takes whatever executable that is called as the source, and then creates the others based on a hard coded list (e.g. python and python3). def setup_python(self, context): """ Set up a Python executable in the environment. :param context: The information for the environment creation request being processed. """ binpath = context.bin_path path = context.env_exe copier = self.symlink_or_copy copier(context.executable, path) dirname = context.python_dir if os.name != 'nt': if not os.path.islink(path): os.chmod(path, 0o755) for suffix in ('python', 'python3'): path = os.path.join(binpath, suffix) if not os.path.exists(path): # Issue 18807: make copies if # symlinks are not wanted copier(context.env_exe, path, relative_symlinks_ok=True) if not os.path.islink(path): os.chmod(path, 0o755) else: subdir = 'DLLs' include = self.include_binary files = [f for f in os.listdir(dirname) if include(f)] for f in files: src = os.path.join(dirname, f) dst = os.path.join(binpath, f) if dst != context.env_exe: # already done, above copier(src, dst) dirname = os.path.join(dirname, subdir) if os.path.isdir(dirname): files = [f for f in os.listdir(dirname) if include(f)] for f in files: src = os.path.join(dirname, f) dst = os.path.join(binpath, f) copier(src, dst) # copy init.tcl over for root, dirs, files in os.walk(context.python_dir): if 'init.tcl' in files: tcldir = os.path.basename(root) tcldir = os.path.join(context.env_dir, 'Lib', tcldir) if not os.path.exists(tcldir): os.makedirs(tcldir) src = os.path.join(root, 'init.tcl') dst = os.path.join(tcldir, 'init.tcl') shutil.copyfile(src, dst) break If you don't call -m venv as python3.X, you will never get that binary in the bin directory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 22:04:50 2017 From: report at bugs.python.org (Kaoru Kitamura) Date: Fri, 29 Dec 2017 03:04:50 +0000 Subject: [issue32420] LookupError : unknown encoding : [0x7FF092395AD0] ANOMALY In-Reply-To: <1514082037.96.0.213398074469.issue32420@psf.upfronthosting.co.za> Message-ID: <1514516690.62.0.213398074469.issue32420@psf.upfronthosting.co.za> Kaoru Kitamura added the comment: Understood. Thank you. ---------- resolution: remind -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 28 23:14:39 2017 From: report at bugs.python.org (Eryk Sun) Date: Fri, 29 Dec 2017 04:14:39 +0000 Subject: [issue32442] Result of pathlib.Path.resolve() with UNC path is not very useful In-Reply-To: <1514488197.55.0.213398074469.issue32442@psf.upfronthosting.co.za> Message-ID: <1514520879.57.0.213398074469.issue32442@psf.upfronthosting.co.za> Eryk Sun added the comment: > the UNC path is not really useful anywhere in the Python > standard library UNC paths can be used almost anywhere in the file API. What specifically isn't working? > there?s no way to turn the it (back) into network drive once you > call resolve() Without using ctypes or PyWin32, you could resolve the root directory on drives A-Z to find the shortest matching path. This would also work with SUBST drives. For example: def resolve_mapped(path): path = pathlib.Path(path).resolve() mapped_paths = [] for drive in 'ZYXWVUTSRQPONMLKJIHGFEDCBA': root = pathlib.Path('{}:/'.format(drive)) try: mapped_paths.append(root / path.relative_to(root.resolve())) except (ValueError, OSError): pass return min(mapped_paths, key=lambda x: len(str(x)), default=path) ---------- nosy: +eryksun type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 00:26:45 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 29 Dec 2017 05:26:45 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1514525205.86.0.213398074469.issue17611@psf.upfronthosting.co.za> Neil Schemenauer added the comment: I wonder if I should drop PR 4682. I spent some more time working on it today. I switched to the same scheme as Serhiy for the no-exception case, i.e. push a single NULL value, rather than six NULLs. In ceval, we need to handle the non-exception case specially anyhow so I think it better to avoid the "stack churn". With the micro-benchmarks that Serhiy posted, PR 4682 is as fast or slightly faster than PR 5006. Doesn't really matter in real code though. I did not push my latest changes as I did not fix the frame.f_lineno issue yet. I think it is fixable without major changes. Should I bother though? Is there some other reason to prefer duplicating the final bodies rather than using a subroutine jump (as in 5006)? A very minor speedup is not worth it I think because the compiler is a bit more complicated. The settrace logic is more complicated too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 00:46:31 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 Dec 2017 05:46:31 +0000 Subject: [issue23749] asyncio missing wrap_socket (starttls) In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1514526391.9.0.213398074469.issue23749@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- pull_requests: +4923 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 01:23:34 2017 From: report at bugs.python.org (Tzu-ping Chung) Date: Fri, 29 Dec 2017 06:23:34 +0000 Subject: [issue32442] Result of pathlib.Path.resolve() with UNC path is not very useful In-Reply-To: <1514488197.55.0.213398074469.issue32442@psf.upfronthosting.co.za> Message-ID: <1514528614.42.0.213398074469.issue32442@psf.upfronthosting.co.za> Tzu-ping Chung added the comment: @Eric You?re correct, this is not the exact output. I tested the commands with a different path, but didn?t format them correctly when I convert them to use a generic example. Sorry for the confusion. @Eryk I found my problem. I was doing some os.rename and shutil stuff that constantly fails when moving and copying things using UNC paths, but works flawlessly when I convert them to use drives. I assumed it?s because the UNC, but after a more involved debugging I find all UNC calls work by themselves, only fail when I combine them. I guess it is due to some strange Windows thing, maybe UNC file stat can?t update fast enough for the next call to get the correct state or something. The attached recipe worked very well. Thanks for the help! I?m closing this since the problem is likely not Python-related. Sorry for the disturbance. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 01:57:03 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 29 Dec 2017 06:57:03 +0000 Subject: [issue32441] os.dup2 should return the new fd In-Reply-To: <1514483083.55.0.213398074469.issue32441@psf.upfronthosting.co.za> Message-ID: <1514530623.24.0.213398074469.issue32441@psf.upfronthosting.co.za> Change by Benjamin Peterson : ---------- keywords: +patch pull_requests: +4924 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 03:23:24 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Dec 2017 08:23:24 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1514525205.86.0.213398074469.issue17611@psf.upfronthosting.co.za> Message-ID: Antoine Pitrou added the comment: Le 29/12/2017 ? 06:26, Neil Schemenauer a ?crit?: > > I wonder if I should drop PR 4682. My main criterion (apart from performance issues which don't seem to exist) for choosing between the two PRs would be implementation complexity. I find Serhiy's PR pleasantly uncomplicated (it even *simplifies* the code in frameobject.c). Your PR seems to add more complexity, so I would be inclined to choose Serhiy's PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 03:39:07 2017 From: report at bugs.python.org (Eryk Sun) Date: Fri, 29 Dec 2017 08:39:07 +0000 Subject: [issue32434] pathlib.WindowsPath.reslove(strict=False) returns absoulte path only if at least one component exists In-Reply-To: <1514405616.88.0.213398074469.issue32434@psf.upfronthosting.co.za> Message-ID: <1514536747.63.0.213398074469.issue32434@psf.upfronthosting.co.za> Eryk Sun added the comment: If none of the components of a relative path exist, then splitting off the head returns an empty string in the second-to-last pass through the while loop. In the last pass, _getfinalpathname("") raises FileNotFoundError, and ultimately resolve() ends up returning `path`. To avoid this, the empty string needs to be replaced with a ".". Then the last pass can resolve the working directory. ---------- components: +Windows nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware stage: -> needs patch versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 03:43:19 2017 From: report at bugs.python.org (Eryk Sun) Date: Fri, 29 Dec 2017 08:43:19 +0000 Subject: [issue32434] pathlib.WindowsPath.reslove(strict=False) returns absoulte path only if at least one component exists In-Reply-To: <1514405616.88.0.213398074469.issue32434@psf.upfronthosting.co.za> Message-ID: <1514536999.38.0.213398074469.issue32434@psf.upfronthosting.co.za> Eryk Sun added the comment: resolve() has additional problems, which possibly could be addressed all at once because it's a small method and the problems are closely related. For an empty path it returns os.getcwd(). I don't think this case is possible in the normal way a Path gets constructed. Anyway, returning the unresolved working directory is incorrect. Windows is not a POSIX OS. WinAPI [Set,Get]CurrentDirectory does not ensure the working directory is a resolved path. An empty path should be replaced with "." and processed normally. It fails when access is denied. _getfinalpathname needs to open a handle, and CreateFile requires at least the right to read file attributes and synchronize. For example, resolve() fails for a path in another user's profile, which grants access only to the user, system, and administrators. It doesn't keep the "\\\\?\\" extended-path prefix when the source path already has it. It should only strip the prefix if the source path doesn't have it. That said, the resolved path may actually require it (i.e. long paths, DOS device names, trailing spaces), so maybe it should never be removed. Its behavior is inconsistent for invalid paths. For example, if "C:/Temp" exists and "C:/Spam" does not, then resolving "C:/Temp/bad?" raises whereas "C:/Spam/bad?" does not. IMO, it's simpler if neither raises in non-strict mode, at least not in _WindowsFlavour.resolve. Malformed paths will slip through, but raising an exception in those cases should be the job of the constructor. It fails to handle device paths. For example, C:/Temp/nul" resolves to the "NUL" device if "C:/Temp" exists. In this case _getfinalpathname will typically fail, either due to an invalid function or an invalid parameter. These errors, along with the error for an invalid filename, get lumped into the CRT's default EINVAL error code. Also, GetFinalPathNameByHandle was added in Vista, so _getfinalpathname is always available in 3.5+. There's no need to use it conditionally. Here's a prototype that addresses these issues: import nt import os import errno def _is_extended(path): return path.startswith('\\\\?\\') def _extended_to_normal(path): if _is_extended(path): path = path[4:] if path.startswith('UNC\\'): path = '\\' + path[3:] return path def _getfinalpathname(path): if not path: path = '.' elif _is_extended(path): return nt._getfinalpathname(path) return _extended_to_normal(nt._getfinalpathname(path)) def resolve(path, strict=False): s = str(path) if strict: return _getfinalpathname(s) # Non-strict mode resolves as much as possible while retaining # tail components that cannot be resolved if they're missing, # inaccessible, or invalid. tail_parts = [] while True: try: s = _getfinalpathname(s) break except OSError as e: if not (isinstance(e, (FileNotFoundError, PermissionError)) or e.errno == errno.EINVAL): raise head, tail = os.path.split(s) if head == s: return path.absolute() s = head tail_parts.append(tail) if tail_parts: s = os.path.join(s, *reversed(tail_parts)) return s ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 04:35:07 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Dec 2017 09:35:07 +0000 Subject: [issue32443] Add Linux's signalfd() to the signal module In-Reply-To: <1514510840.93.0.213398074469.issue32443@psf.upfronthosting.co.za> Message-ID: <1514540107.52.0.213398074469.issue32443@psf.upfronthosting.co.za> Antoine Pitrou added the comment: See also https://bugs.python.org/issue12304 ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 04:45:29 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Dec 2017 09:45:29 +0000 Subject: [issue32443] Add Linux's signalfd() to the signal module In-Reply-To: <1514510840.93.0.213398074469.issue32443@psf.upfronthosting.co.za> Message-ID: <1514540729.23.0.213398074469.issue32443@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Also see how the forkserver module does without it: https://github.com/python/cpython/blob/master/Lib/multiprocessing/forkserver.py#L146 Reading Jean-Paul's messages in https://bugs.python.org/issue8407, I'm unclear what is required to take advantage of signalfd(). Jean-Paul says """In order to effectively use signalfd(), the signals in question must be blocked, though""". The signalfd man page says: """Normally, the set of signals to be received via the file descriptor should be blocked using sigprocmask(2), to prevent the signals being handled according to their default dispositions""". And it's not clear what is meant by that (what happens if you don't block those signals?). Also: """As a consequence of the read(2), the signals are consumed, so that they are no longer pending for the process (i.e., will not be caught by signal handlers, and cannot be accepted using sigwaitinfo(2)).""" But how about the converse? i.e. can a signal be consumed first by a signal handler and the fd not written to at all? Also see fork() semantics which might (or not) require special handling. Also see https://bugs.python.org/issue31489 for an issue related to fork(), signals and fds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 05:57:14 2017 From: report at bugs.python.org (Mathieu Dupuy) Date: Fri, 29 Dec 2017 10:57:14 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1514545034.5.0.213398074469.issue15873@psf.upfronthosting.co.za> Mathieu Dupuy added the comment: maybe it's worth adding an entry in python 3.7 "what's new" ? I think it was a very long awaited issue. The opposite of isoformat() is a very frequent question from python newcomers ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 06:48:50 2017 From: report at bugs.python.org (Mark Shannon) Date: Fri, 29 Dec 2017 11:48:50 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1514548130.42.0.213398074469.issue17611@psf.upfronthosting.co.za> Mark Shannon added the comment: Why all these competing pull requests? It does feel like my original patch has been hijacked. Also, before any more PRs, we need to decide whether to use subroutines or code duplication for finally blocks. Here is my attempt at an objective comparison of the two approaches. JSR style Code duplication Speed Slower Faster Interpreter More complex Simpler Bytecode generation Simpler More complex Bytecode size ~ +0.1% ~ +0.4% The increase in bytecode size is insignificant in terms of overall memory use, but the performance increase is significant (although small). Unless I have missed anything important, this says to me that the code duplication approach is better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 07:00:08 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Dec 2017 12:00:08 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1514548130.42.0.213398074469.issue17611@psf.upfronthosting.co.za> Message-ID: <80b2fcb7-2cf7-bb0e-28be-7dbdb10b3917@free.fr> Antoine Pitrou added the comment: Le 29/12/2017 ? 12:48, Mark Shannon a ?crit?: > > Why all these competing pull requests? It does feel like my original patch has been hijacked. The original patch had a number of issues which needed to be fixed (in addition to forward-port it to the latest git master), such as not fixing some cases of stack consumption calculation. > Also, before any more PRs, we need to decide whether to use subroutines or code duplication for finally blocks. > > Here is my attempt at an objective comparison of the two approaches. > > JSR style Code duplication > Speed Slower Faster > Interpreter More complex Simpler > Bytecode generation Simpler More complex > Bytecode size ~ +0.1% ~ +0.4% Actually, when looking at your original patch (https://bugs.python.org/review/17611/) vs. Serhiy's https://github.com/python/cpython/pull/5006/, it looks like interpreter complexity is the same. Speed also seems to not be significantly different. So I would rephrase it as (compared to legacy bytecode generation): Subroutine Code duplication Speed Same Insignificantly faster Interpreter Simpler Simpler Bytecode generation Slightly more complex Slightly more complex Bytecode size ~ +0.1% ~ +0.4% That said, if you want to submit an updated version of the code duplication approach (with the same amount of added tests and debugging), we could compare on more equal grounds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 08:19:30 2017 From: report at bugs.python.org (Segev Finer) Date: Fri, 29 Dec 2017 13:19:30 +0000 Subject: [issue18035] telnetlib incorrectly assumes that select.error has an errno attribute In-Reply-To: <1369244217.55.0.122247989262.issue18035@psf.upfronthosting.co.za> Message-ID: <1514553570.3.0.213398074469.issue18035@psf.upfronthosting.co.za> Change by Segev Finer : ---------- keywords: +patch pull_requests: +4925 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 08:37:44 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 29 Dec 2017 13:37:44 +0000 Subject: [issue32445] Skip creating redundant wrapper functions in ExitStack.callback Message-ID: <1514554664.91.0.213398074469.issue32445@psf.upfronthosting.co.za> New submission from Nick Coghlan : While discussing https://bugs.python.org/issue32145, I noticed that ExitStack.callback *always* adds a wrapper function, even when the `args` and `kwds` parameters are both empty. For plain callbacks that aren't receiving any extra arguments, it would be better to skip adding the redundant wrapper function. ---------- messages: 309171 nosy: barry, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Skip creating redundant wrapper functions in ExitStack.callback type: performance versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 08:40:02 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 29 Dec 2017 13:40:02 +0000 Subject: [issue32145] Wrong ExitStack Callback recipe In-Reply-To: <1511771653.67.0.213398074469.issue32145@psf.upfronthosting.co.za> Message-ID: <1514554802.65.0.213398074469.issue32145@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'm not clear on what you mean about allowing arbitrary names for the instance creation function - at that point we're back to subclasses not being able to use the default `pop_all()` implementation at all, and needing to duplicate the state transfer logic in the subclass (which we don't provide a public API to do, since the `_exit_callbacks` queue is deliberately private). However, I'm thinking we could potentially change `pop_all` *itself* to accept a target object: def pop_all(self, *, target=None): """Preserve the context stack by transferring it to a new instance If a *target* stack is given, it must be either an `ExitStack` instance, or else provide a callback registration method akin to `ExitStack.callback`. """ if target is None: target = type(self)() exit_callbacks = self._exit_callbacks self._exit_callbacks = deque() if isinstance(target, ExitStack): target._exit_callbacks = exit_callbacks else: for cb in exit_callbacks: target.callback(cb) return target The recipe fix would then be to make `Callback.cancel()` look like: def cancel(self): # We deliberately *don't* clean up the cancelled callback self.pop_all(target=ExitStack()) (Tangent: https://bugs.python.org/issue32445 suggests adding a small optimisation to `ExitStack.callback` to skip adding the wrapper when `args` and `kwds` are both empty) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 09:09:49 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 29 Dec 2017 14:09:49 +0000 Subject: [issue32444] python -m venv has incongruous behavor creating binaries In-Reply-To: <1514515697.43.0.213398074469.issue32444@psf.upfronthosting.co.za> Message-ID: <1514556589.92.0.213398074469.issue32444@psf.upfronthosting.co.za> R. David Murray added the comment: This is a feature that actually supports your use case, as well as the use cases of those who *don't* want to strap the python version: you get what you ask for. If you call venv with 'python3', you get a venv that will use your new python if you upgrade your python, but if you call it with python3.x, you will get a venv that will *not* upgrade, which is exactly what you want for your use case. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed versions: +Python 3.7 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 09:15:09 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 29 Dec 2017 14:15:09 +0000 Subject: [issue32444] python -m venv symlink dependency on how python binary is called is not documented In-Reply-To: <1514515697.43.0.213398074469.issue32444@psf.upfronthosting.co.za> Message-ID: <1514556909.17.0.213398074469.issue32444@psf.upfronthosting.co.za> R. David Murray added the comment: Actually, I'm going to reopen this as a doc issue because this behavior is not discussed by the docs that I can see, and it is important to know about when creating a venv. ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +docs at python resolution: not a bug -> stage: resolved -> needs patch status: closed -> open title: python -m venv has incongruous behavor creating binaries -> python -m venv symlink dependency on how python binary is called is not documented _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 09:50:46 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 29 Dec 2017 14:50:46 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1514559046.79.0.213398074469.issue15873@psf.upfronthosting.co.za> R. David Murray added the comment: Correct, a new feature should always get a what's new entry. You could submit a PR for it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 09:54:21 2017 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 29 Dec 2017 14:54:21 +0000 Subject: [issue32427] Rename and expose dataclasses._MISSING In-Reply-To: <1514292226.17.0.213398074469.issue32427@psf.upfronthosting.co.za> Message-ID: <1514559261.7.0.213398074469.issue32427@psf.upfronthosting.co.za> Change by Eric V. Smith : ---------- keywords: +patch pull_requests: +4926 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 10:03:31 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 29 Dec 2017 15:03:31 +0000 Subject: [issue32145] Wrong ExitStack Callback recipe In-Reply-To: <1514554802.65.0.213398074469.issue32145@psf.upfronthosting.co.za> Message-ID: Barry A. Warsaw added the comment: On Dec 29, 2017, at 08:40, Nick Coghlan wrote: > > I'm not clear on what you mean about allowing arbitrary names for the instance creation function - What I meant was that I don?t see `def _make_instance()` defined in your example, so I didn?t know if that was part of the contract between the base and derived classes, or an ?arbitrary method? that subclasses can come up with. From the example, it seems like the latter, but I could be misunderstanding your proposal. > at that point we're back to subclasses not being able to use the default `pop_all()` implementation at all, and needing to duplicate the state transfer logic in the subclass (which we don't provide a public API to do, since the `_exit_callbacks` queue is deliberately private). > > However, I'm thinking we could potentially change `pop_all` *itself* to accept a target object: > > def pop_all(self, *, target=None): > """Preserve the context stack by transferring it to a new instance > > If a *target* stack is given, it must be either an `ExitStack` > instance, or else provide a callback registration method akin to `ExitStack.callback`. > """ > if target is None: > target = type(self)() > exit_callbacks = self._exit_callbacks > self._exit_callbacks = deque() > if isinstance(target, ExitStack): > target._exit_callbacks = exit_callbacks > else: > for cb in exit_callbacks: > target.callback(cb) > return target > > The recipe fix would then be to make `Callback.cancel()` look like: > > def cancel(self): > # We deliberately *don't* clean up the cancelled callback > self.pop_all(target=ExitStack()) That?s actually not bad. I think I like that better than the (IMHO, misnamed) _clone() API. I?d quibble just a bit about the docstring, since the required API for target is exactly that it have a .callback() method that accepts a single exit callback argument. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 10:04:56 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Dec 2017 15:04:56 +0000 Subject: [issue32429] Outdated Modules/Setup warning is invisible In-Reply-To: <1514326238.69.0.213398074469.issue32429@psf.upfronthosting.co.za> Message-ID: <1514559896.74.0.213398074469.issue32429@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm ok with turning the warning into an error. Does anyone object here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 10:33:19 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 29 Dec 2017 15:33:19 +0000 Subject: [issue32446] ResourceLoader.get_data() should accept a PathLike Message-ID: <1514561599.46.0.213398074469.issue32446@psf.upfronthosting.co.za> New submission from Barry A. Warsaw : Currently get_data() only accepts a string. It should also accept a os.PathLike ---------- messages: 309178 nosy: barry, brett.cannon priority: normal severity: normal status: open title: ResourceLoader.get_data() should accept a PathLike versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 11:25:32 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Fri, 29 Dec 2017 16:25:32 +0000 Subject: [issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514564732.11.0.213398074469.issue32424@psf.upfronthosting.co.za> Change by Gordon P. Hemsley : ---------- pull_requests: +4927 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 11:26:26 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Fri, 29 Dec 2017 16:26:26 +0000 Subject: [issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514564786.24.0.213398074469.issue32424@psf.upfronthosting.co.za> Change by Gordon P. Hemsley : ---------- title: Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation -> Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 11:29:24 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Fri, 29 Dec 2017 16:29:24 +0000 Subject: [issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514564964.71.0.213398074469.issue32424@psf.upfronthosting.co.za> Gordon P. Hemsley added the comment: Given the discussion, I've gone ahead and created a new PR that synchronizes the three copy methods between implementations and deprecates Element.copy(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 11:43:59 2017 From: report at bugs.python.org (Steve Margetts) Date: Fri, 29 Dec 2017 16:43:59 +0000 Subject: [issue32447] IDLE shell won't open on Mac OS 10.13.1 Message-ID: <1514565839.68.0.213398074469.issue32447@psf.upfronthosting.co.za> New submission from Steve Margetts : I am trying to install Python on a Max running OS 10.13.1 (so my son can use a 'Coding for Beginners' book). Both 2.7 and 3.6 have the same problem: Clicking on IDLE leads to the icon bouncing a couple of times in the dock, but not opening a shell. I have tried re-installing and restarting post install. Typing python or python3.6 into the terminal seems to launch Python successfully (details below). I am as new to coding as my son, please phrase any advice accordingly! Thank you. Last login: Fri Dec 29 16:26:57 on ttys000 mkdir: /Users/Steve Margetts/.bash_sessions: Permission denied touch: /Users/Steve Margetts/.bash_sessions/79B2448C-E769-409D-A67D-7A96F8C3C348.historynew: No such file or directory iMac:~ Steve Margetts$ python Python 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 12:01:12) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> help Type help() for interactive help, or help(object) for help about object. >>> Last login: Fri Dec 29 16:30:16 on ttys000 mkdir: /Users/Steve Margetts/.bash_sessions: Permission denied touch: /Users/Steve Margetts/.bash_sessions/5A516AB8-0481-4D55-A2BD-1B1017E52147.historynew: No such file or directory iMac:~ Steve Margetts$ python3.6 Python 3.6.4 (v3.6.4:d48ecebad5, Dec 18 2017, 21:07:28) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> ---------- assignee: terry.reedy components: IDLE messages: 309180 nosy: sm1979, terry.reedy priority: normal severity: normal status: open title: IDLE shell won't open on Mac OS 10.13.1 type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 11:45:55 2017 From: report at bugs.python.org (Mark Shannon) Date: Fri, 29 Dec 2017 16:45:55 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1514565955.87.0.213398074469.issue17611@psf.upfronthosting.co.za> Mark Shannon added the comment: When I said "significant", I meant from a statistically, not as a judgement meaning "useful" or "worthwhile". The code duplication approach is significantly faster in the tests. Whether the small speed difference is worth worrying about is a different matter. Also, the comparisons were with each other, not the current interpreter. Both approaches are better than the current implementation. One point I didn't cover is jumping to a new line in the debugger. Implementing that reliably for finally blocks with code duplication is tricky and would mean adding a number of marker bytecodes. Which is a big point in favour of the JSR style. If we are going to use the JSR approach, we should do it properly. PR 5006 still has elements of the current design such as the overly complex END_FINALLY, WITH_CLEANUP_START and WITH_CLEANUP_FINISH bytecodes. None of those should be necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 12:40:01 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 29 Dec 2017 17:40:01 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1514569201.58.0.213398074469.issue17611@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Whether the small speed difference is worth worrying about is a different matter. I don't think so. Though one could run the benchmarks suite to get an idea of the impact on real-world code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 12:59:42 2017 From: report at bugs.python.org (mickey695) Date: Fri, 29 Dec 2017 17:59:42 +0000 Subject: [issue31907] Clarify error message when attempting to call function via str.format() In-Reply-To: <1509410120.18.0.213398074469.issue31907@psf.upfronthosting.co.za> Message-ID: <1514570382.95.0.213398074469.issue31907@psf.upfronthosting.co.za> mickey695 added the comment: Well, it has been more than the 2 weeks I promised however now I finally have time to look into this. I did some fuzzing to build a list quickly and the following ASCII characters can not be used as part of the argument name: exclamation mark(!) period(.) colon(:) opening square bracket([) opening/closing curly brackets({}) also, the argument name may not start with digits from zero to nine(0-9) Basically what needs to be changed is arg_name under the section "Format String Syntax" in \Doc\library\string.rst Problem is, I really don't understand the syntax of the Python/sphinx formal language. The following expression is what I came up with: arg_name ::= [^`decinteger`] [ | `integer` ]+ If anyone from the documentation team could look into it I would be grateful. Moreover, I think attribute_name should probably be changed as it does not have to be a valid identifier. In fact, it can be any text. Eric V. Smiths' example can be used with any text as the attribute name. A comment should be added to the aforementioned section explaining that normally only valid identifiers are accepted, however by implementing your own __getattr__ this can be changed. ---------- components: +Documentation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 13:03:11 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 29 Dec 2017 18:03:11 +0000 Subject: [issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514570591.55.0.213398074469.issue32424@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is an existing test for copying. No new tests are needed. Just add a case for the copy() method in test_copy. Special __deepcopy__() method for Python implementation is not needed. copy.deepcopy() already works well. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 13:08:53 2017 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 29 Dec 2017 18:08:53 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za> Message-ID: <1514570933.04.0.213398074469.issue17611@psf.upfronthosting.co.za> Neil Schemenauer added the comment: I apologize if my extra PR is causing confusion. My original intention was to merely forward port Antoine changes so they could compile with the 'master' version of Python. Over time I have made some fixes to it. I have kept it open because I'm not sure which approach is better (JSR or duplication). I did a quick test on the .pyc code size increase. It is actually tiny for the Python code in Lib/. PR 5006: 21259894 bytes PR 4682: 21263081 bytes (+0.015%) Running Serhiy's microbenchmarks: for i in a: try: pass finally: pass PR 4682: Mean +- std dev: 11.0 us +- 0.1 us PR 5006: Mean +- std dev: 10.9 us +- 0.6 us for i in a: try: continue finally: pass PR 4682: Mean +- std dev: 9.46 us +- 0.85 us PR 5006: Mean +- std dev: 14.3 us +- 0.3 us for i in a: while True: try: break finally: pass PR 4682: Mean +- std dev: 9.20 us +- 0.09 us PR 5006: Mean +- std dev: 14.3 us +- 0.6 us ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 13:55:47 2017 From: report at bugs.python.org (Marcel Widjaja) Date: Fri, 29 Dec 2017 18:55:47 +0000 Subject: [issue12706] timeout sentinel in ftplib and poplib documentation In-Reply-To: <1312705981.24.0.601234287082.issue12706@psf.upfronthosting.co.za> Message-ID: <1514573747.85.0.213398074469.issue12706@psf.upfronthosting.co.za> Marcel Widjaja added the comment: Greg, I wonder if you are planning to submit a PR for your patch? If not, I'm plan to take your patch, make some minor adjustment and submit a PR. ---------- nosy: +mawidjaj _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 13:59:48 2017 From: report at bugs.python.org (Alexander Mohr) Date: Fri, 29 Dec 2017 18:59:48 +0000 Subject: [issue32448] subscriptable Message-ID: <1514573988.38.0.213398074469.issue32448@psf.upfronthosting.co.za> New submission from Alexander Mohr : Currently subscriting a attribute that's None reports the following: >>> class Foo: pass >>> Foo.organizer = None >>> Foo.organizer['start'] Traceback (most recent call last): File "", line 1, in TypeError: 'NoneType' object is not subscriptable What would be nice is if it were to report the name of the attribute that is not subscriptable as it would greatly help in the logs, something like: Traceback (most recent call last): File "", line 1, in TypeError: 'NoneType' object of attribute 'organizer' is not subscriptable just a thought. Otherwise one would need to sprinkle their code with asserts, especially if it's a compound statement like: Foo.organizer.blah[0], you wouldn't know which attribute wasn't None ---------- components: Interpreter Core messages: 309187 nosy: thehesiod priority: normal severity: normal status: open title: subscriptable type: enhancement versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 14:00:01 2017 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 29 Dec 2017 19:00:01 +0000 Subject: [issue32427] Rename and expose dataclasses._MISSING In-Reply-To: <1514292226.17.0.213398074469.issue32427@psf.upfronthosting.co.za> Message-ID: <1514574001.05.0.213398074469.issue32427@psf.upfronthosting.co.za> Eric V. Smith added the comment: New changeset 03220fdb26c0b6a50ce5ed1fdfbf232094b66db6 by Eric V. Smith in branch 'master': bpo-32427: Expose dataclasses.MISSING object. (#5045) https://github.com/python/cpython/commit/03220fdb26c0b6a50ce5ed1fdfbf232094b66db6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 14:01:34 2017 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 29 Dec 2017 19:01:34 +0000 Subject: [issue32427] Rename and expose dataclasses._MISSING In-Reply-To: <1514292226.17.0.213398074469.issue32427@psf.upfronthosting.co.za> Message-ID: <1514574094.45.0.213398074469.issue32427@psf.upfronthosting.co.za> Change by Eric V. Smith : ---------- resolution: -> fixed stage: patch review -> resolved type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 14:20:49 2017 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 29 Dec 2017 19:20:49 +0000 Subject: [issue32428] dataclasses: make it an error to have initialized non-fields in a dataclass In-Reply-To: <1514420371.28.0.213398074469.issue32428@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I liked the original design better, where things without annotations would just be ignored. What changed? On Dec 27, 2017 5:19 PM, "Ivan Levkivskyi" wrote: > > Ivan Levkivskyi added the comment: > > > I'm not sure I understand the distinction. > > Initially I thought about only flagging code like this: > > @dataclass > class C: > x = field() > > But not this: > > @dataclass > class C: > x = 42 > > Now I think we should probably flag both as errors. > > > How do we only pick out `y` and probably `prop`, and ignore the rest, > without being overly fragile to new things being added? I guess ignoring > dunders and things in `__annotations__`. Is that close enough? > > We had a similar problem while developing Protocol class (PEP 544). > Currently we just a have a whitelist of names that are skipped: > > '__abstractmethods__', '__annotations__', '__weakref__', '__dict__', > '__slots__', '__doc__', '__module__' > > (plus some internal typing API names) > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 14:45:57 2017 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Fri, 29 Dec 2017 19:45:57 +0000 Subject: [issue32221] Converting ipv6 address to string representation using getnameinfo() is wrong. In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za> Message-ID: <1514576757.5.0.213398074469.issue32221@psf.upfronthosting.co.za> ???? ????????? added the comment: So, PR is ready. Please review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 14:52:35 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 Dec 2017 19:52:35 +0000 Subject: [issue32221] Converting ipv6 address to string representation using getnameinfo() is wrong. In-Reply-To: <1512467694.45.0.213398074469.issue32221@psf.upfronthosting.co.za> Message-ID: <1514577155.32.0.213398074469.issue32221@psf.upfronthosting.co.za> Yury Selivanov added the comment: > So, PR is ready. Please review. I understand, however I still don't have time for it at the moment. If another core dev wants to take initiative, please by all means do. I can/will take another look at this after January 15. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 15:00:00 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 29 Dec 2017 20:00:00 +0000 Subject: [issue32448] subscriptable In-Reply-To: <1514573988.38.0.213398074469.issue32448@psf.upfronthosting.co.za> Message-ID: <1514577600.95.0.213398074469.issue32448@psf.upfronthosting.co.za> R. David Murray added the comment: At the point at which that error is raised, Python doesn't know the name of the attribute, nor is attribute access the only place where that particular error report is triggered (it's in a generic subscript-this-object call). So I doubt doing this would be practical. As for Foo.organizer.blah[0], it has to be blah that is None, since '.organizer' is an attribute access and not a subscript operation. The more difficult case is something like getattr(someobject, somevar)[0], where you can't tell what somevar contains just from the traceback. Which is why some value-added systems also dump the locals from the frame in the traceback. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 15:44:09 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 29 Dec 2017 20:44:09 +0000 Subject: [issue18035] telnetlib incorrectly assumes that select.error has an errno attribute In-Reply-To: <1369244217.55.0.122247989262.issue18035@psf.upfronthosting.co.za> Message-ID: <1514580249.29.0.213398074469.issue18035@psf.upfronthosting.co.za> Gregory P. Smith added the comment: New changeset 3ceaed0dce81fd881bbaf2dbdbe827d9681887da by Gregory P. Smith (Segev Finer) in branch '2.7': bpo-18035: telnetlib: select.error doesn't have an errno attribute (#5044) https://github.com/python/cpython/commit/3ceaed0dce81fd881bbaf2dbdbe827d9681887da ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 15:46:05 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 29 Dec 2017 20:46:05 +0000 Subject: [issue18035] telnetlib incorrectly assumes that select.error has an errno attribute In-Reply-To: <1369244217.55.0.122247989262.issue18035@psf.upfronthosting.co.za> Message-ID: <1514580365.86.0.213398074469.issue18035@psf.upfronthosting.co.za> Change by Gregory P. Smith : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 15:46:22 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 29 Dec 2017 20:46:22 +0000 Subject: [issue32447] IDLE shell won't open on Mac OS 10.13.1 In-Reply-To: <1514565839.68.0.213398074469.issue32447@psf.upfronthosting.co.za> Message-ID: <1514580382.98.0.213398074469.issue32447@psf.upfronthosting.co.za> Terry J. Reedy added the comment: IDLE uses Python's tcl/tk interface module, called 'tkinter'. Tcl is a separate language and tk is its graphical user interface. This is most likely the problem. Did you follow the advice at https://www.python.org/download/mac/tcltk/ to install tcl/tk 8.5.18? Make sure you read the whole page. To test better, run 'import tkinter' at Python's interactive '>>>' prompt. Any error message? If that works, run 'python3.6 -m idlelib' and/or 'python -m idlelib.idle' at the terminal '...$' prompt. Does that display an error message? ---------- components: +Installation, macOS nosy: +ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 15:56:36 2017 From: report at bugs.python.org (Ned Deily) Date: Fri, 29 Dec 2017 20:56:36 +0000 Subject: [issue32447] IDLE shell won't open on Mac OS 10.13.1 In-Reply-To: <1514565839.68.0.213398074469.issue32447@psf.upfronthosting.co.za> Message-ID: <1514580996.94.0.213398074469.issue32447@psf.upfronthosting.co.za> Ned Deily added the comment: Those messages at the top of your terminal sessions are pretty suspicious, e.g. "Permission denied" and "No such file or directory". They suggest a home directory ownership or permissions issue which you should investigate. But definitely try running IDLE from the terminal window as Terry suggests. If nothing else, you may see more informative error messages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 15:57:52 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 29 Dec 2017 20:57:52 +0000 Subject: [issue32443] Add Linux's signalfd() to the signal module In-Reply-To: <1514510840.93.0.213398074469.issue32443@psf.upfronthosting.co.za> Message-ID: <1514581072.86.0.213398074469.issue32443@psf.upfronthosting.co.za> Gregory P. Smith added the comment: My reading of the Linux signalfd man page may be optimistic. :) Regardless, it'd be nice to have it available in the stdlib so it could be used if deemed useful. I expect this to only ever be added by someone making use of it in another stdlib module. As for what multiprocessing.forkserver does, the old manual signal handler and pipe trick is a reasonably well known one. But a forkserver is not safe to be started when threads exist. (unlike subprocess) Signals are process global state, no thread compatible library can rightfully take ownership of a one. ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 16:13:08 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 29 Dec 2017 21:13:08 +0000 Subject: [issue32441] os.dup2 should return the new fd In-Reply-To: <1514483083.55.0.213398074469.issue32441@psf.upfronthosting.co.za> Message-ID: <1514581988.48.0.213398074469.issue32441@psf.upfronthosting.co.za> Benjamin Peterson added the comment: New changeset bbdb17d19bb1d5443ca4417254e014ad64c04540 by Benjamin Peterson in branch 'master': return the new file descriptor from os.dup2 (closes bpo-32441) (#5041) https://github.com/python/cpython/commit/bbdb17d19bb1d5443ca4417254e014ad64c04540 ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 16:55:53 2017 From: report at bugs.python.org (Ilya Kulakov) Date: Fri, 29 Dec 2017 21:55:53 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() In-Reply-To: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> Message-ID: <1514584553.01.0.213398074469.issue32363@psf.upfronthosting.co.za> Ilya Kulakov added the comment: Andrew, Yury I test my lib against dev versions of Python and recently got an error in one of the tests due to the deprecation. I do not argue the reason behind removing this methods, but Task.set_exception was working for me in tests: https://github.com/Kentzo/async_app/blob/250ee7a05d2af8035806ce1d86f57d0f00283db0/tests/test_utils.py#L73-L91 My use case was outside control of otherwise unconditionally blocking task (for tests only). What replacement (if any) would you suggest? ---------- nosy: +Ilya.Kulakov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 16:58:00 2017 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 29 Dec 2017 21:58:00 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() In-Reply-To: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> Message-ID: <1514584680.74.0.213398074469.issue32363@psf.upfronthosting.co.za> Yury Selivanov added the comment: > My use case was outside control of otherwise unconditionally blocking task (for tests only). What replacement (if any) would you suggest? Use Task.cancel() or use a Queue to communicate with the task. Your test code was working, but ultimately was creating an unexpected (and not officially documented/supported) situation for the task. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 16:59:35 2017 From: report at bugs.python.org (Yahya Abou Imran) Date: Fri, 29 Dec 2017 21:59:35 +0000 Subject: [issue32449] MappingView must inherit from Collection instead of Sized Message-ID: <1514584775.87.0.213398074469.issue32449@psf.upfronthosting.co.za> New submission from Yahya Abou Imran : Quoting my own post on python-ideas: After I generate an UML diagram from collections.abc, I found very strange that MappingView inherit from Sized instead of Collection (new in python 3.6). Yes, MappingView only define __len__ and not __iter__ and __contains__, but all of its subclasses define them (KeysView, ValuesView and ItemViews). I tried to run the tests in test/test_collections.py after making this change and on only one fail : Traceback (most recent call last): File "/usr/lib/python3.6/test/test_collections.py", line 789, in test_Collection self.assertNotIsInstance(x, Collection) AssertionError: dict_values([]) is an instance of Wich is absolutely wrong, since in reality a dict_values instance has the behaviour of a Collection: >>> vals = {1:'a', 2: 'b'}.values() >>> 'a' in vals True >>> 'c' in vals False >>> len(vals) 2 >>> for val in vals: ... print(val) ... a b The only lack is that it doesn't define a __contains__ method: >>> '__contains__' in vals False It uses __iter__ to find the presence of the value. But, hey: we have register() for this cases! In fact, when MappingView inherit from Collection, dict_values is considered as a subclass of Collection since it's in the register of ValuesView, causing the above bug... So, the test have to be changed, and dict_values must be placed in the samples that pass the test, and not in the ones that fail it. ---------- messages: 309200 nosy: yahya-abou-imran at protonmail.com priority: normal severity: normal status: open title: MappingView must inherit from Collection instead of Sized type: enhancement versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 17:03:10 2017 From: report at bugs.python.org (Ilya Kulakov) Date: Fri, 29 Dec 2017 22:03:10 +0000 Subject: [issue32363] Deprecate task.set_result() and task.set_exception() In-Reply-To: <1513594763.95.0.213398074469.issue32363@psf.upfronthosting.co.za> Message-ID: <1514584990.38.0.213398074469.issue32363@psf.upfronthosting.co.za> Ilya Kulakov added the comment: cancel will work in my case, but it's somewhat limited. In other hand it's probably a job of a testing library to provide an utility function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 17:05:45 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 29 Dec 2017 22:05:45 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <1514570933.04.0.213398074469.issue17611@psf.upfronthosting.co.za> Message-ID: <2476627.uTek7ZXOIG@saraksh> Serhiy Storchaka added the comment: I consider PR 5006 as just a first step. I had two goals: 1) Fix all regressions in PR 2827. First at all the regression in the f_lineno setter. 2) Simplify the patch. This is critically important for getting the review. And it decreases the chance of regressions. All changes not directly related to the main goal (declared in the title of this issue) were removed. Other nice improvements can be made in separate PRs. Maybe finally we will came to the duplication of the code. But this will require making other small steps which can have their own value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 17:19:30 2017 From: report at bugs.python.org (Yahya Abou Imran) Date: Fri, 29 Dec 2017 22:19:30 +0000 Subject: [issue32449] MappingView must inherit from Collection instead of Sized In-Reply-To: <1514584775.87.0.213398074469.issue32449@psf.upfronthosting.co.za> Message-ID: <1514585970.62.0.213398074469.issue32449@psf.upfronthosting.co.za> Yahya Abou Imran added the comment: Quoting my own post on python-ideas: After I generate an UML diagram from collections.abc, I found very strange that MappingView inherit from Sized instead of Collection (new in python 3.6). Yes, MappingView only define __len__ and not __iter__ and __contains__, but all of its subclasses define them (KeysView, ValuesView and ItemViews). I tried to run the tests in test/test_collections.py after making this change and on only one fail : Traceback (most recent call last): File "/usr/lib/python3.6/test/test_collections.py", line 789, in test_Collection self.assertNotIsInstance(x, Collection) AssertionError: dict_values([]) is an instance of Wich is absolutely wrong, since in reality a dict_values instance has the behaviour of a Collection: >>> vals = {1:'a', 2: 'b'}.values() >>> 'a' in vals True >>> 'c' in vals False >>> len(vals) 2 >>> for val in vals: ... print(val) ... a b The only lack is that it doesn't define a __contains__ method: >>> '__contains__' in vals False It uses __iter__ to find the presence of the value. But, hey: we have register() for this cases! In fact, when MappingView inherit from Collection, dict_values is considered as a subclass of Collection since it's in the register of ValuesView, causing the above bug... So, the test have to be changed, and dict_values must be placed in the samples that pass the test, and not in the ones that fail it. Here is a patch file for this. The only problem in this is that the MappingView won't be instatiable anymore because of the lack of __contains__ and __iter__. But since - if my understanding is correct - it's just an "utilty" super class for three other views (so is Collection for Set, Mapping and Sequence), it's not a big deal IMHO. ---------- keywords: +patch Added file: https://bugs.python.org/file47354/mypatch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 17:40:00 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 29 Dec 2017 22:40:00 +0000 Subject: [issue32449] MappingView must inherit from Collection instead of Sized In-Reply-To: <1514584775.87.0.213398074469.issue32449@psf.upfronthosting.co.za> Message-ID: <1514587199.99.0.213398074469.issue32449@psf.upfronthosting.co.za> R. David Murray added the comment: Well, it would be a backward compatibility problem at a minimum. Obviously things were designed this way. Have you found out why? Is there a consensus on python-ideas that this should be changed? If so, please link to the thread. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 18:08:41 2017 From: report at bugs.python.org (Yahya Abou Imran) Date: Fri, 29 Dec 2017 23:08:41 +0000 Subject: [issue32449] MappingView must inherit from Collection instead of Sized In-Reply-To: <1514584775.87.0.213398074469.issue32449@psf.upfronthosting.co.za> Message-ID: <1514588921.82.0.213398074469.issue32449@psf.upfronthosting.co.za> Yahya Abou Imran added the comment: https://mail.python.org/pipermail/python-ideas/2017-December/048489.html Guido is waiting for objection on this... I have absolutly no idea why this decision was made. These tests (ttps://github.com/python/cpython/blame/master/Lib/test/test_collections.py#L794): non_col_iterables = [_test_gen(), iter(b''), iter(bytearray()), (x for x in []), dict().values()] for x in non_col_iterables: self.assertNotIsInstance(x, Collection) were written by Guido himself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 18:24:31 2017 From: report at bugs.python.org (Yahya Abou Imran) Date: Fri, 29 Dec 2017 23:24:31 +0000 Subject: [issue32449] MappingView must inherit from Collection instead of Sized In-Reply-To: <1514584775.87.0.213398074469.issue32449@psf.upfronthosting.co.za> Message-ID: <1514589871.83.0.213398074469.issue32449@psf.upfronthosting.co.za> Yahya Abou Imran added the comment: And I just saw that Raymon Hettinger made it inherting from Sized: https://github.com/python/cpython/blame/master/Lib/_collections_abc.py#L694 So I we were to ahve his opinion on this... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 18:42:18 2017 From: report at bugs.python.org (Christian Heimes) Date: Fri, 29 Dec 2017 23:42:18 +0000 Subject: [issue28134] socket.socket(fileno=fd) does not work as documented In-Reply-To: <1473794011.65.0.923929152137.issue28134@psf.upfronthosting.co.za> Message-ID: <1514590938.55.0.213398074469.issue28134@psf.upfronthosting.co.za> Christian Heimes added the comment: Yuri, * The patch is purely about Python's view of the socket. The actual behavior of the OS socket fd is not influenced by socket.socket()'s family, type and protocol. However the especially the family is critical for Python because a lot of socket code uses the family to decide how to format its address or the peer address. * On some platforms and/or for some socket types, it is not possible to get the address family or type unless connect() or bind() have been called. On Linux it seems to work for both new sockets and bound/connected sockets. On Windows it never works for a fresh socket. * It looks like Windows doesn't have protocol dedicated and always uses 0 as protocols. * Using the wrong type is less of an issue. Using the wrong family is really really bad, see https://bugs.python.org/issue28134#msg285972. * I don't care much about validating the values. I'm concerned to have correct values by default. Validation can be implemented in a separate PR. In that case we want to add socket.closefd(fd: int). On Windows os.close() can't be used for socket fds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 18:46:40 2017 From: report at bugs.python.org (Roundup Robot) Date: Fri, 29 Dec 2017 23:46:40 +0000 Subject: [issue32449] MappingView must inherit from Collection instead of Sized In-Reply-To: <1514584775.87.0.213398074469.issue32449@psf.upfronthosting.co.za> Message-ID: <1514591200.98.0.213398074469.issue32449@psf.upfronthosting.co.za> Change by Roundup Robot : ---------- pull_requests: +4928 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 19:00:32 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 30 Dec 2017 00:00:32 +0000 Subject: [issue32420] LookupError : unknown encoding : [0x7FF092395AD0] ANOMALY In-Reply-To: <1514082037.96.0.213398074469.issue32420@psf.upfronthosting.co.za> Message-ID: <1514592032.21.0.213398074469.issue32420@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Since there is no evident CPython bug, I am closing this. If CPython gets a bogus encoding for the std streams, it cannot output a normal traceback on sys.stderr. >From StackOverflow: "TensorFlow is an open source library for machine learning and machine intelligence. It is developed by Google and became open source in November 2015." It obviously has a python binding as there are numerous questions tagged with both. I searched SO for "[tensorflow] ANOMALY" and the 29 hits were about anomaly detection, as in detecting credit card fraud. Suspecting that the error is not tensorflow specific, I searched "[anaconda] ANOMALY" and got the following, which reports a nearly identical error message, but with scikit-learn. https://stackoverflow.com/questions/42732377/how-to-install-scikit-0-19-dev-version-in-anaconda The advice was to reinstall after rechecking instructions. ---------- nosy: +terry.reedy resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 19:04:03 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 30 Dec 2017 00:04:03 +0000 Subject: [issue32421] Keeping an exception in cache can segfault the interpreter In-Reply-To: <1514082423.32.0.213398074469.issue32421@psf.upfronthosting.co.za> Message-ID: <1514592243.6.0.213398074469.issue32421@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Yonathon, when replying by email, please delete the quoted message, except possibly for a specific line, as it is redundant noise when posted on the web page. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 19:09:14 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 30 Dec 2017 00:09:14 +0000 Subject: [issue32426] Tkinter.ttk Widget does not define wich option exists to set the cursor In-Reply-To: <1514241431.48.0.213398074469.issue32426@psf.upfronthosting.co.za> Message-ID: <1514592554.58.0.213398074469.issue32426@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The tkinter docs currently omit much, but refer one to, among other places, http://infohost.nmt.edu/tcc/help/pubs/tkinter/web/index.html, which has a page with images and names. http://infohost.nmt.edu/tcc/help/pubs/tkinter/web/cursors.html ---------- nosy: +serhiy.storchaka, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 20:03:30 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 30 Dec 2017 01:03:30 +0000 Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. In-Reply-To: <2476627.uTek7ZXOIG@saraksh> Message-ID: Nick Coghlan added the comment: Another point in favour of the JSR approach is that it should make it easier for tools like coverage.py to continue mapping opcode coverage to line coverage. I also like Serhiy's proposed strategy of separating the initial introduction of the compiler based exception handling from the subsequent simplification of the exception handling opcodes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 20:49:41 2017 From: report at bugs.python.org (Yuri Kanivetsky) Date: Sat, 30 Dec 2017 01:49:41 +0000 Subject: [issue32450] non-descriptive variable name Message-ID: <1514598581.85.0.213398074469.issue32450@psf.upfronthosting.co.za> New submission from Yuri Kanivetsky : Not a big issue, really. At some point the code switches from "ndots" name: https://github.com/python/cpython/blob/v3.7.0a3/Python/ast.c#L3385 to "level" name: https://github.com/python/cpython/blob/v3.7.0a3/Python/Python-ast.c#L1671 Be it "ndots" everywhere, it could save me some time. ---------- messages: 309212 nosy: Yuri Kanivetsky priority: normal severity: normal status: open title: non-descriptive variable name type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 22:15:32 2017 From: report at bugs.python.org (mpb) Date: Sat, 30 Dec 2017 03:15:32 +0000 Subject: [issue30449] Improve __slots__ datamodel documentation In-Reply-To: <1495587707.13.0.0998591622446.issue30449@psf.upfronthosting.co.za> Message-ID: <1514603732.02.0.213398074469.issue30449@psf.upfronthosting.co.za> mpb added the comment: Can __slots__ be assigned a string? If so, what are the consequences? I find the current docs lack clarity. For example from the docs for 3.7.0a3: https://docs.python.org/3.7/reference/datamodel.html#slots > 3.3.2.4. __slots__ > > [snip] > > object.__slots__ > This class variable can be assigned a string, > iterable, or sequence of strings [snip] However, "3.3.2.4.1. Notes on using __slots__" does not discuss what happens when a string is assigned to __slots__. The "notes" section does discuss assigning a "sequence of strings" to __slots__. The "notes" section also says: "Any non-string iterable may be assigned to __slots__." Based on quick experimentation, it appears that the string must be a single identifier. I get a TypeError if I try to assign "foo bar" to __slots__. The consequence of a string appears to be that only a single slot is created. It would be nice if this was stated clearly in the docs. The docs for 2.7 seem similar to version 3.7.0a3. So maybe all versions of the docs could be improved regarding the specifics of what happens when you assign a string to __slots__. ---------- nosy: +mpb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 22:44:58 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 30 Dec 2017 03:44:58 +0000 Subject: [issue10381] Add timezone support to datetime C API In-Reply-To: <1289415057.12.0.111170767809.issue10381@psf.upfronthosting.co.za> Message-ID: <1514605498.17.0.213398074469.issue10381@psf.upfronthosting.co.za> Nick Coghlan added the comment: Would it be possible to deprecate (or at least stop enhancing) the current datetime C API and add a new capsule based one instead? We're trying to get extension module authors to *stop* relying on C level globals, since it causes problems with: - memory usage analysis - interpreter reinitialisation - module reloading - subinterpreters Unfortunately, the current design of the datetime C API *requires* the use of C level global state. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 23:00:57 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 30 Dec 2017 04:00:57 +0000 Subject: [issue31975] Add a default filter for DeprecationWarning in __main__ In-Reply-To: <1510109709.08.0.213398074469.issue31975@psf.upfronthosting.co.za> Message-ID: <1514606457.75.0.213398074469.issue31975@psf.upfronthosting.co.za> Change by Nick Coghlan : ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 29 23:13:49 2017 From: report at bugs.python.org (Kevin) Date: Sat, 30 Dec 2017 04:13:49 +0000 Subject: [issue32451] python -m venv activation issue when using cygwin on windows Message-ID: <1514607229.33.0.213398074469.issue32451@psf.upfronthosting.co.za> New submission from Kevin : attempts from within cygwin: 1. The Posix way: $ python -m venv taco $ cd taco $ source bin/activate -bash: $'\r': command not found -bash: Scripts/activate: line 4: syntax error near unexpected token `$'{\r'' 'bash: Scripts/activate: line 4: `deactivate () { 2. The windows way: $ python -m venv taco $ cd taco $ /full/path/to/venv/taco/scripts/activate.bat $ 3. the only solution from cygwin (still not 100% functional): $ python -m venv taco $ cd taco $ cd Scripts $ cmd C:\taco\Scripts\> activate.bat (taco) C:\taco\Scripts\> HOWEVER. when running "pip freeze" in number 3 it returns the system packages despite the "include-system-site-packages = False" in pyvenv.cfg When #3 is run inside command prompt "pip freeze" returns nothing correctly. Come on guys, please don't make me use command prompt or powershell. ---------- messages: 309215 nosy: Kevin priority: normal severity: normal status: open title: python -m venv activation issue when using cygwin on windows type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 00:00:38 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 30 Dec 2017 05:00:38 +0000 Subject: [issue31975] Add a default filter for DeprecationWarning in __main__ In-Reply-To: <1510109709.08.0.213398074469.issue31975@psf.upfronthosting.co.za> Message-ID: <1514610038.49.0.213398074469.issue31975@psf.upfronthosting.co.za> Change by Nick Coghlan : ---------- keywords: +patch pull_requests: +4929 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 00:11:56 2017 From: report at bugs.python.org (kandhan) Date: Sat, 30 Dec 2017 05:11:56 +0000 Subject: [issue32452] Brackets and Parentheses used in an ambiguous way Message-ID: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za> New submission from kandhan : https://docs.python.org/3/tutorial/classes.html 9.10. Generator Expressions Some simple generators can be coded succinctly as expressions using a syntax similar to list comprehensions but with "parentheses instead of brackets" Since parentheses comes under brackets, brackets could be changed to "Square Brackets" ---------- assignee: docs at python components: Documentation messages: 309216 nosy: docs at python, kandhan priority: normal severity: normal status: open title: Brackets and Parentheses used in an ambiguous way type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 00:15:09 2017 From: report at bugs.python.org (=?utf-8?q?Niklas_Hamb=C3=BCchen?=) Date: Sat, 30 Dec 2017 05:15:09 +0000 Subject: [issue32453] shutil.rmtree can have O(n^2) performance on large dirs Message-ID: <1514610909.88.0.213398074469.issue32453@psf.upfronthosting.co.za> New submission from Niklas Hamb?chen : See http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=24412edeaf556a for the explanation and equivalent fix in coreutils. The gist ist that deleting entries in inode order can improve deletion performance dramatically. To obtain inode numbers and sort by them, one needs to `getdents()` all the entries ahead of time, but rmtree() already gets all dirents ahead of the deletion. https://bugs.python.org/issue28564 recently improved shutil.rmtree() performance by using scandir(), but nevertheless the returned generator is list()ed, so we already have all necessary informtaion in memory and would just have to perform an O(n) integer sort. I propose we check if the improvements made to `rm -r` in coreutils should be ported to shutil.rmtree(). ---------- components: Library (Lib) messages: 309217 nosy: nh2 priority: normal severity: normal status: open title: shutil.rmtree can have O(n^2) performance on large dirs type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 00:15:11 2017 From: report at bugs.python.org (kandhan) Date: Sat, 30 Dec 2017 05:15:11 +0000 Subject: [issue32452] Brackets and Parentheses used in an ambiguous way In-Reply-To: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za> Message-ID: <1514610911.98.0.213398074469.issue32452@psf.upfronthosting.co.za> kandhan added the comment: In the above comment, Line 1 is the URL where it needs improvement Line 2 and 3 are the actual content in the page that needs improvement Line 4 is the proposed solution ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 00:15:42 2017 From: report at bugs.python.org (=?utf-8?q?Niklas_Hamb=C3=BCchen?=) Date: Sat, 30 Dec 2017 05:15:42 +0000 Subject: [issue28564] shutil.rmtree is inefficient due to listdir() instead of scandir() In-Reply-To: <1477857759.23.0.231777495226.issue28564@psf.upfronthosting.co.za> Message-ID: <1514610942.13.0.213398074469.issue28564@psf.upfronthosting.co.za> Niklas Hamb?chen added the comment: I've filed https://bugs.python.org/issue32453, which is about O(n^2) deletion behaviour for large directories. ---------- nosy: +nh2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 00:35:38 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 30 Dec 2017 05:35:38 +0000 Subject: [issue23749] asyncio missing wrap_socket (starttls) In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1514612138.73.0.213398074469.issue23749@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset f111b3dcb414093a4efb9d74b69925e535ddc470 by Yury Selivanov in branch 'master': bpo-23749: Implement loop.start_tls() (#5039) https://github.com/python/cpython/commit/f111b3dcb414093a4efb9d74b69925e535ddc470 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 00:38:29 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 30 Dec 2017 05:38:29 +0000 Subject: [issue23749] asyncio missing wrap_socket (starttls) In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1514612309.08.0.213398074469.issue23749@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 01:31:35 2017 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 30 Dec 2017 06:31:35 +0000 Subject: [issue32452] Brackets and Parentheses used in an ambiguous way In-Reply-To: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za> Message-ID: <1514615495.55.0.213398074469.issue32452@psf.upfronthosting.co.za> Steven D'Aprano added the comment: In British, Australian, New Zealander, and Indian English (and sometimes Canada), at least, "bracket" on its own typically means round brackets () and is rarely if ever used for square brackets [] or curly brackets {} without the adjective. See for example https://english.stackexchange.com/questions/168762/brackets-vs-parenthesis for a discussion. Consequently, the phrase "parentheses instead of brackets" reads to us as "parentheses instead of parentheses" would to Americans. In other words, weird and requiring a moment (or three) of thought to translate. I support the suggested change to "parentheses instead of square brackets" -- it should read more naturally to people in the British Commonwealth and (I hope) shouldn't look too strange to Americans. My personal preference would be for "round brackets instead of square brackets", but I guess that will be a battle I have no hope of winning *wink* ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 02:16:12 2017 From: report at bugs.python.org (kandhan) Date: Sat, 30 Dec 2017 07:16:12 +0000 Subject: [issue32452] Brackets and Parentheses used in an ambiguous way In-Reply-To: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za> Message-ID: <1514618172.67.0.213398074469.issue32452@psf.upfronthosting.co.za> kandhan added the comment: "round brackets instead of square brackets" sounds better. Its simple and direct and doesn't require any extra operations other than the required one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 02:47:47 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 Dec 2017 07:47:47 +0000 Subject: [issue32439] Clean up the code for compiling comparison expressions In-Reply-To: <1514460221.23.0.213398074469.issue32439@psf.upfronthosting.co.za> Message-ID: <1514620067.61.0.213398074469.issue32439@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset 02b9ef27752ff4873c592ac3afe7e3410f715984 by Serhiy Storchaka in branch 'master': bpo-32439: Clean up the code for compiling comparison expressions. (#5029) https://github.com/python/cpython/commit/02b9ef27752ff4873c592ac3afe7e3410f715984 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 02:59:57 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 Dec 2017 07:59:57 +0000 Subject: [issue32439] Clean up the code for compiling comparison expressions In-Reply-To: <1514460221.23.0.213398074469.issue32439@psf.upfronthosting.co.za> Message-ID: <1514620797.85.0.213398074469.issue32439@psf.upfronthosting.co.za> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 04:37:23 2017 From: report at bugs.python.org (Christian Heimes) Date: Sat, 30 Dec 2017 09:37:23 +0000 Subject: [issue32454] Add socket.close(fd) function Message-ID: <1514626643.82.0.213398074469.issue32454@psf.upfronthosting.co.za> New submission from Christian Heimes : os.close(fd) of a socket fd does not work some platforms, e.g. Windows. In the past we have used socket.socket(fileno=fd).close() to close a socket in a platform independent way. With #28134 it may no longer work in all cases, most noticeable when the socket has neither been connected nor bound yet and auto-detection of type and family is used. Instead of adding more hacks, I propose to add a socket.close(fd) function as cross-platform way to close a socket fd. It won't be the first function that mimics an o' module function. The socket module already has the undocumented socket.dup(fd) function. ---------- messages: 309224 nosy: christian.heimes priority: normal severity: normal status: open title: Add socket.close(fd) function type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 04:42:06 2017 From: report at bugs.python.org (Christian Heimes) Date: Sat, 30 Dec 2017 09:42:06 +0000 Subject: [issue32454] Add socket.close(fd) function In-Reply-To: <1514626643.82.0.213398074469.issue32454@psf.upfronthosting.co.za> Message-ID: <1514626926.32.0.213398074469.issue32454@psf.upfronthosting.co.za> Change by Christian Heimes : ---------- keywords: +patch pull_requests: +4930 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 04:43:20 2017 From: report at bugs.python.org (Christian Heimes) Date: Sat, 30 Dec 2017 09:43:20 +0000 Subject: [issue28134] socket.socket(fileno=fd) does not work as documented In-Reply-To: <1473794011.65.0.923929152137.issue28134@psf.upfronthosting.co.za> Message-ID: <1514627000.24.0.213398074469.issue28134@psf.upfronthosting.co.za> Christian Heimes added the comment: Issue #32454 adds socket.close(fd) function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 05:53:15 2017 From: report at bugs.python.org (Steve Margetts) Date: Sat, 30 Dec 2017 10:53:15 +0000 Subject: [issue32447] IDLE shell won't open on Mac OS 10.13.1 In-Reply-To: <1514565839.68.0.213398074469.issue32447@psf.upfronthosting.co.za> Message-ID: <1514631195.24.0.213398074469.issue32447@psf.upfronthosting.co.za> Steve Margetts added the comment: Thanks for the help. I've installed ActiveTCL 8.5.18.0 as per the Python recommendation. Running from terminal: Last login: Fri Dec 29 16:46:22 on ttys001 mkdir: /Users/Steve Margetts/.bash_sessions: Permission denied touch: /Users/Steve Margetts/.bash_sessions/224C387E-8E74-4020-A5CC-F275EFB79EAE.historynew: No such file or directory iMac:~ Steve Margetts$ python3.6 Python 3.6.4 (v3.6.4:d48ecebad5, Dec 18 2017, 21:07:28) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import tkinter >>> Did not bring up any error message. However, subsequently trying to run IDLE from terminal brought up: Last login: Sat Dec 30 10:42:04 on ttys000 mkdir: /Users/Steve Margetts/.bash_sessions: Permission denied touch: /Users/Steve Margetts/.bash_sessions/58F5E574-277D-4413-9B03-4B24ED9B4C21.historynew: No such file or directory iMac:~ Steve Margetts$ python3.6 -m idlelib Warning: unable to create user config directory /Users/Steve Margetts/.idlerc Check path and permissions. Exiting! iMac:~ Steve Margetts$ Does this look like a permissions issue? If so, any idea what to try next? I'm logged on as an administrator on a home computer. Is this likely to be a security setting issue? Thanks again for any help - I'm a child of the GUI and the last time I coded anything was in BBC Basic! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 06:22:40 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 30 Dec 2017 11:22:40 +0000 Subject: [issue32453] shutil.rmtree can have O(n^2) performance on large dirs In-Reply-To: <1514610909.88.0.213398074469.issue32453@psf.upfronthosting.co.za> Message-ID: <1514632960.54.0.213398074469.issue32453@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't think filesystem-specific optimizations belong in the Python stdlib. Python is compatible with multiple operating systems, including Windows, macOS, Android, many POSIX variants. It would be much better if this were fixed in the kernel... ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 06:56:20 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 30 Dec 2017 11:56:20 +0000 Subject: [issue32454] Add socket.close(fd) function In-Reply-To: <1514626643.82.0.213398074469.issue32454@psf.upfronthosting.co.za> Message-ID: <1514634980.64.0.213398074469.issue32454@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 06:57:07 2017 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 30 Dec 2017 11:57:07 +0000 Subject: [issue32447] IDLE shell won't open on Mac OS 10.13.1 In-Reply-To: <1514565839.68.0.213398074469.issue32447@psf.upfronthosting.co.za> Message-ID: <1514635027.33.0.213398074469.issue32447@psf.upfronthosting.co.za> Ronald Oussoren added the comment: There appears to be a permission issue with the home directory. What's the output of the following commands in a terminal window: $ ls -led ~ $ id The home directory should be owned by the "uid" shown by the second command, and should be writable by the user, the output of "ls" should show something like this: drwxr-xr-x@ 336 ronald staff 10752 Dec 30 12:52 /Users/ronald 0: group:everyone deny delete In particular the mode at the start should start with "drwx". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 07:04:03 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 30 Dec 2017 12:04:03 +0000 Subject: [issue32443] Add Linux's signalfd() to the signal module In-Reply-To: <1514510840.93.0.213398074469.issue32443@psf.upfronthosting.co.za> Message-ID: <1514635443.35.0.213398074469.issue32443@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Regardless, it'd be nice to have it available in the stdlib so it could be used if deemed useful. Agreed. > Signals are process global state, no thread compatible library can rightfully take ownership of a one. But then is the signalfd() idea for subprocess doomed as well? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 07:06:12 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 Dec 2017 12:06:12 +0000 Subject: [issue32453] shutil.rmtree can have O(n^2) performance on large dirs In-Reply-To: <1514610909.88.0.213398074469.issue32453@psf.upfronthosting.co.za> Message-ID: <1514635572.48.0.213398074469.issue32453@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have tested shutil.rmtree() with a large number of files using modified benchmark from issue28564. For 400000 files it takes less than 5 seconds. From the comment to the coreutils benchmark (http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=24412edeaf556a): # Using rm -rf to remove a 400k-entry directory takes: # - 9 seconds with the patch, on a 2-yr-old system # - 350 seconds without the patch, on a high-end system (disk 20-30% faster) threshold_seconds=60 Running the coreutils benchmark gives the result 3 seconds on my computer. It seems to me that this issue have been fixed in the kernel. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 07:06:33 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 Dec 2017 12:06:33 +0000 Subject: [issue32453] shutil.rmtree can have O(n^2) performance on large dirs In-Reply-To: <1514610909.88.0.213398074469.issue32453@psf.upfronthosting.co.za> Message-ID: <1514635593.2.0.213398074469.issue32453@psf.upfronthosting.co.za> Change by Serhiy Storchaka : Added file: https://bugs.python.org/file47355/bench_rmtree.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 07:30:15 2017 From: report at bugs.python.org (Steve Margetts) Date: Sat, 30 Dec 2017 12:30:15 +0000 Subject: [issue32447] IDLE shell won't open on Mac OS 10.13.1 In-Reply-To: <1514565839.68.0.213398074469.issue32447@psf.upfronthosting.co.za> Message-ID: <1514637015.2.0.213398074469.issue32447@psf.upfronthosting.co.za> Steve Margetts added the comment: OK, those commands give: iMac:~ Steve Margetts$ ls -led drwxr-xr-x 21 501 staff 714 30 Dec 10:40 . iMac:~ Steve Margetts$ id uid=503(Steve Margetts) gid=20(staff) groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh) iMac:~ Steve Margetts$ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 09:05:46 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 Dec 2017 14:05:46 +0000 Subject: [issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are not particularly useful Message-ID: <1514642746.19.0.213398074469.issue32455@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : The information provided by PyCompile_OpcodeStackEffect() and dis.stack_effect() (added in issue19722) is not enough for practical use. 1. Some opcodes (like JUMP_IF_TRUE_OR_POP or FOR_ITER) have different stack effect when when execution is continued from the following opcode or jumped to the address specified by oparg. Thus there are two different values for stack effect of these opcodes. 2. Some opcodes (RETURN_VALUE, RAISE_VARARGS) stops execution. Their stack effect doesn't have meaning, and the following opcodes should be ignored. 3. Some opcodes (JUMP_ABSOLUTE, JUMP_RELATIVE) always jump. The opcodes following them should be ignored. 4. Some opcodes (like SETUP_FINALLY or SETUP_WITH) need additional space on the stack for raised exceptions. Their stack effect is virtual. Its value can't be used for calculating the actual position on the stack. This isn't documented. The possible solution is to add a boolean flag for distinguishing the stack effects in case of consequent execution and jumping. Return a special sentinel or raise an exception if the opcode doesn't pass execution in this direction. ---------- components: Interpreter Core, Library (Lib) messages: 309232 nosy: eric.snow, larry, ncoghlan, serhiy.storchaka priority: normal severity: normal status: open title: PyCompile_OpcodeStackEffect() and dis.stack_effect() are not particularly useful type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 09:41:16 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sat, 30 Dec 2017 14:41:16 +0000 Subject: [issue19678] smtpd.py: channel should be passed to process_message In-Reply-To: <1385031410.17.0.520349427654.issue19678@psf.upfronthosting.co.za> Message-ID: <1514644876.11.0.213398074469.issue19678@psf.upfronthosting.co.za> Change by Sanyam Khurana : ---------- keywords: +patch pull_requests: +4931 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 10:34:04 2017 From: report at bugs.python.org (Paul Ganssle) Date: Sat, 30 Dec 2017 15:34:04 +0000 Subject: [issue10381] Add timezone support to datetime C API In-Reply-To: <1289415057.12.0.111170767809.issue10381@psf.upfronthosting.co.za> Message-ID: <1514648044.84.0.213398074469.issue10381@psf.upfronthosting.co.za> Paul Ganssle added the comment: @Nick I'm certainly fine with re-configuring my PR to center around a new capsule module with deprecation of the old C API (though if you have any examples of what you have in mind that would be helpful to me). Certainly the "C global needs to be initiated" problem has bitten me in the past and I'm certain will continue to bite people in the future. That said, I think it would be really good if we could get a fast path for timezone creation and access to the UTC singleton into the Python 3.7 release. I think it's kind of a big disparity between the Python and C APIs that's existed for too long already. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 10:43:56 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 30 Dec 2017 15:43:56 +0000 Subject: [issue23749] asyncio missing wrap_socket (starttls) In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1514648636.86.0.213398074469.issue23749@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: @yselivanov - thanks for adding this, it's a huge win. I think the feature is significant enough for a What's New entry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 10:45:16 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 30 Dec 2017 15:45:16 +0000 Subject: [issue23749] asyncio missing wrap_socket (starttls) In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1514648716.5.0.213398074469.issue23749@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I think the feature is significant enough for a What's New entry. Sure, Elvis and I will go through all NEWS items when it's time for what's new ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 11:08:18 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sat, 30 Dec 2017 16:08:18 +0000 Subject: [issue15045] Make textwrap.dedent() consistent with str.splitlines(True) and str.strip() In-Reply-To: <1339421358.2.0.611530152115.issue15045@psf.upfronthosting.co.za> Message-ID: <1514650098.48.0.213398074469.issue15045@psf.upfronthosting.co.za> Change by Sanyam Khurana : ---------- pull_requests: +4932 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 11:16:15 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 30 Dec 2017 16:16:15 +0000 Subject: [issue32418] Implement Server.get_loop() method In-Reply-To: <1514056259.94.0.213398074469.issue32418@psf.upfronthosting.co.za> Message-ID: <1514650575.68.0.213398074469.issue32418@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- pull_requests: +4933 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 11:26:14 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 Dec 2017 16:26:14 +0000 Subject: [issue32456] PYTHONIOENCODING=undefined doesn't work in Python 3 Message-ID: <1514651174.11.0.213398074469.issue32456@psf.upfronthosting.co.za> New submission from Serhiy Storchaka : In Python 2.7 setting PYTHONIOENCODING=undefined mostly works as expected. $ PYTHONIOENCODING=undefined python -c 'print(123)' 123 $ PYTHONIOENCODING=undefined python -c 'print("abc")' abc $ PYTHONIOENCODING=undefined python -c 'print(u"abc")' Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/encodings/undefined.py", line 19, in encode raise UnicodeError("undefined encoding") UnicodeError: undefined encoding Most tests (except test_doctest and test_gdb) are passed with PYTHONIOENCODING=undefined. But in Python 3 setting PYTHONIOENCODING=undefined seems just silently terminates the interpreter (exited with code 1). ---------- components: IO, Interpreter Core, Unicode messages: 309237 nosy: benjamin.peterson, ezio.melotti, lemburg, ncoghlan, serhiy.storchaka, vstinner priority: normal severity: normal status: open title: PYTHONIOENCODING=undefined doesn't work in Python 3 type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 11:33:42 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 30 Dec 2017 16:33:42 +0000 Subject: [issue32447] IDLE shell won't open on Mac OS 10.13.1 In-Reply-To: <1514565839.68.0.213398074469.issue32447@psf.upfronthosting.co.za> Message-ID: <1514651622.04.0.213398074469.issue32447@psf.upfronthosting.co.za> Ned Deily added the comment: Just to be sure, please try again with the command as Ronald requested, i.e. include the tilde "~": ls -led ~ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 11:34:50 2017 From: report at bugs.python.org (Steve Margetts) Date: Sat, 30 Dec 2017 16:34:50 +0000 Subject: [issue32447] IDLE shell won't open on Mac OS 10.13.1 In-Reply-To: <1514565839.68.0.213398074469.issue32447@psf.upfronthosting.co.za> Message-ID: <1514651690.41.0.213398074469.issue32447@psf.upfronthosting.co.za> Steve Margetts added the comment: Including tilde... Last login: Sat Dec 30 10:47:07 on ttys001 mkdir: /Users/Steve Margetts/.bash_sessions: Permission denied touch: /Users/Steve Margetts/.bash_sessions/8B76B0D2-2C88-4FE0-A8F6-C7FB8C13A2A8.historynew: No such file or directory iMac:~ Steve Margetts$ ls -led ~ drwxr-xr-x 21 501 staff 714 30 Dec 10:40 /Users/Steve Margetts iMac:~ Steve Margetts$ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 11:46:24 2017 From: report at bugs.python.org (Alexander Mohr) Date: Sat, 30 Dec 2017 16:46:24 +0000 Subject: [issue32448] subscriptable In-Reply-To: <1514573988.38.0.213398074469.issue32448@psf.upfronthosting.co.za> Message-ID: <1514652384.69.0.213398074469.issue32448@psf.upfronthosting.co.za> Alexander Mohr added the comment: oh for second example I meant something like this: >>> class Foo: pass >>> Foo.organizer = None >>> Foo.blah = Foo >>> Foo.blah.organizer = None >>> Foo.blah.organizer[0] ya this is just a pie in the sky request :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 11:52:58 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 30 Dec 2017 16:52:58 +0000 Subject: [issue32418] Implement Server.get_loop() method In-Reply-To: <1514056259.94.0.213398074469.issue32418@psf.upfronthosting.co.za> Message-ID: <1514652778.58.0.213398074469.issue32418@psf.upfronthosting.co.za> Andrew Svetlov added the comment: New changeset ffcb4c0165827d0a48ea973cc88bc134c74879fb by Andrew Svetlov in branch 'master': bpo-32418: Postfix, raise NotImplementdError and close resources in tests (#5052) https://github.com/python/cpython/commit/ffcb4c0165827d0a48ea973cc88bc134c74879fb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 12:10:16 2017 From: report at bugs.python.org (Andrew Svetlov) Date: Sat, 30 Dec 2017 17:10:16 +0000 Subject: [issue32418] Implement Server.get_loop() method In-Reply-To: <1514056259.94.0.213398074469.issue32418@psf.upfronthosting.co.za> Message-ID: <1514653816.68.0.213398074469.issue32418@psf.upfronthosting.co.za> Change by Andrew Svetlov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 13:37:19 2017 From: report at bugs.python.org (John Jolly) Date: Sat, 30 Dec 2017 18:37:19 +0000 Subject: [issue28494] is_zipfile false positives In-Reply-To: <1476997729.0.0.643464084789.issue28494@psf.upfronthosting.co.za> Message-ID: <1514659039.28.0.213398074469.issue28494@psf.upfronthosting.co.za> Change by John Jolly : ---------- pull_requests: +4934 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 13:58:32 2017 From: report at bugs.python.org (Ray Donnelly) Date: Sat, 30 Dec 2017 18:58:32 +0000 Subject: [issue32457] Windows Python cannot handle an early PATH entry containing ".." and python.exe Message-ID: <1514660312.79.0.213398074469.issue32457@psf.upfronthosting.co.za> New submission from Ray Donnelly : Over on the Anaconda Distribution we received a (private) bug report about a crash when trying to use scons. I thought initially it was due to one of our patches but I tested it out with official CPython and also with WinPython and ran into the same crash. To reproduce this, from cmd.exe on CPython (here I installed CPython as part of Visual Studio 2017, then updated it to the latest 3.6.4 release): ``` set "PATH=C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\Scripts\..;%PATH%" python.exe .. python Fatal Python error: Py_Initialize: unable to load the file system codec ModuleNotFoundError: No module named 'encodings' Current thread 0x00000328 (most recent call first): ``` The trigger for this bug is the following batch code in scons.bat: https://bitbucket.org/scons/scons/src/c0172db149b1a151eeb76910d55c81746bfede05/src/script/scons.bat?at=default&fileviewer=file-view-default#scons.bat-19 My current thinking is that the best fix here is to modify get_progpath()/get_program_full_path() so that it uses PathCchCanonicalizeEx() at https://github.com/python/cpython/blob/9bee329130aae5a13050c08dab9d349b76e66835/PC/getpathp.c#L558-L559 ---------- components: Windows messages: 309242 nosy: Ray Donnelly, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows Python cannot handle an early PATH entry containing ".." and python.exe type: crash versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 14:06:58 2017 From: report at bugs.python.org (Ray Donnelly) Date: Sat, 30 Dec 2017 19:06:58 +0000 Subject: [issue32457] Windows Python cannot handle an early PATH entry containing ".." and python.exe In-Reply-To: <1514660312.79.0.213398074469.issue32457@psf.upfronthosting.co.za> Message-ID: <1514660818.84.0.213398074469.issue32457@psf.upfronthosting.co.za> Ray Donnelly added the comment: .. though I will also ask the scons people to change this to use pushd and %CD% instead. Even if you were to make Python capable of handling such bad input, who knows what other programs will fail, and build systems should be extra careful not to mess the environment up like this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 14:20:51 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 30 Dec 2017 19:20:51 +0000 Subject: [issue32458] test_asyncio failures on Windows Message-ID: <1514661650.99.0.213398074469.issue32458@psf.upfronthosting.co.za> New submission from Antoine Pitrou : It seems test_asyncio fails sporadically on AppVeyor: https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.10081#L2650 ====================================================================== ERROR: test_start_tls_server_1 (test.test_asyncio.test_sslproto.ProactorStartTLS) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\projects\cpython\lib\test\test_asyncio\test_sslproto.py", line 284, in test_start_tls_server_1 asyncio.wait_for(main(), loop=self.loop, timeout=10)) File "C:\projects\cpython\lib\asyncio\base_events.py", line 440, in run_until_complete return future.result() File "C:\projects\cpython\lib\asyncio\tasks.py", line 398, in wait_for raise futures.TimeoutError() concurrent.futures._base.TimeoutError ====================================================================== FAIL: test_start_tls_server_1 (test.test_asyncio.test_sslproto.ProactorStartTLS) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\projects\cpython\lib\test\test_asyncio\functional.py", line 43, in tearDown self.fail('unexpected calls to loop.call_exception_handler()') AssertionError: unexpected calls to loop.call_exception_handler() ---------- components: Library (Lib), Tests messages: 309244 nosy: asvetlov, giampaolo.rodola, pitrou, yselivanov priority: normal severity: normal status: open title: test_asyncio failures on Windows type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 14:28:09 2017 From: report at bugs.python.org (John Jolly) Date: Sat, 30 Dec 2017 19:28:09 +0000 Subject: [issue28494] is_zipfile false positives In-Reply-To: <1476997729.0.0.643464084789.issue28494@psf.upfronthosting.co.za> Message-ID: <1514662089.83.0.213398074469.issue28494@psf.upfronthosting.co.za> John Jolly added the comment: Fix submitted that evaluates the ECD structure and validates the first CD entry. The fix also handles empty zipfiles. IMO the purpose of this API is to *quickly* verify that the file is a valid zipfile. With this fix, the API only reads another 46 bytes of data (after a seek, of course). This should still qualify as "quick", especially after having potentially read 64k of data. Perhaps a full zip validator would be appropriate in addition to is_zipfile. That would be more appropriate as a full feature rather than in this bugfix. ---------- nosy: +jjolly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 14:42:58 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 30 Dec 2017 19:42:58 +0000 Subject: [issue32447] IDLE shell won't open on Mac OS 10.13.1 In-Reply-To: <1514565839.68.0.213398074469.issue32447@psf.upfronthosting.co.za> Message-ID: <1514662978.16.0.213398074469.issue32447@psf.upfronthosting.co.za> Ned Deily added the comment: OK, that confirms that your home directory permissions are incorrect. Not sure how that happened, possibly by an inadvertent chown command. Note that you need to be careful when using shell commands because your user name has a space character in it, so you have to be sure to enclose it in quotes in the shell ("Steve Margetts") and there may be third-party scripts that don't handle that case well; generally, it's best to avoid using spaces in the Unix login name. Anyway, there are several ways to correct the problem but it looks like the easiest might be to use a procedure that Apple provides to reset permissions. It is described here: https://www.macobserver.com/tmo/article/os-x-repair-home-folder-permissions Good luck! ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 14:55:11 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 30 Dec 2017 19:55:11 +0000 Subject: [issue8231] Unable to run IDLE without write-access to home directory In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za> Message-ID: <1514663710.99.0.213398074469.issue8231@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Another duplicate: #32411, MacOS 10.3.1, user apparently cannot write to home dir. Starting IDLE in terminal results in Warning: unable to create user config directory /Users/Steve Margetts/.idlerc Check path and permissions. Exiting! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 14:59:20 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 30 Dec 2017 19:59:20 +0000 Subject: [issue32447] IDLE shell won't open on Mac OS 10.13.1 In-Reply-To: <1514565839.68.0.213398074469.issue32447@psf.upfronthosting.co.za> Message-ID: <1514663960.63.0.213398074469.issue32447@psf.upfronthosting.co.za> Ned Deily added the comment: P.S. You might consider creating a new account without the embedded space and moving your files there; it will probably cause other problems for you in the future. I notice that the current System Preferences -> Users & Groups interface won't even let you create a login account with a space in it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 15:10:13 2017 From: report at bugs.python.org (Eryk Sun) Date: Sat, 30 Dec 2017 20:10:13 +0000 Subject: [issue32457] Windows Python cannot handle an early PATH entry containing ".." and python.exe In-Reply-To: <1514660312.79.0.213398074469.issue32457@psf.upfronthosting.co.za> Message-ID: <1514664613.26.0.213398074469.issue32457@psf.upfronthosting.co.za> Eryk Sun added the comment: Here's a way to trigger this error that's unrelated to the PATH environment variable: >>> subprocess.call('python', executable=r'C:\Program Files\Python36\.\python.exe') Fatal Python error: Py_Initialize: unable to load the file system codec ModuleNotFoundError: No module named 'encodings' [...] Apparently Windows doesn't normalize the process image path if it uses only backslash as the path separator. It normalizes it if at least one backslash is replaced with a slash. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 15:16:10 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 30 Dec 2017 20:16:10 +0000 Subject: [issue8231] Unable to run IDLE without write-access to home directory In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za> Message-ID: <1514664970.55.0.213398074469.issue8231@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ned diagnosed #32447 as likely due to the space in the user name. What matters for this issue is that a) someone can do that and b) IDLE likely could continue running anyway. There might then be problems with saving files from the editor, so any warning message should include that possibility. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 15:18:08 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 30 Dec 2017 20:18:08 +0000 Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7 In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za> Message-ID: <1514665088.67.0.213398074469.issue32248@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: New changeset deae6b451fefd5fd3143dd65051e1d341e5a5f84 by Barry Warsaw in branch 'master': bpo-32248 - Implement importlib.resources (#4911) https://github.com/python/cpython/commit/deae6b451fefd5fd3143dd65051e1d341e5a5f84 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 15:18:38 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 30 Dec 2017 20:18:38 +0000 Subject: [issue32447] IDLE shell won't open on Mac OS 10.13.1 In-Reply-To: <1514565839.68.0.213398074469.issue32447@psf.upfronthosting.co.za> Message-ID: <1514665118.43.0.213398074469.issue32447@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The Mac issue is the inability to add .xyz directories to the home directory. You can test a fix by entering 'mkdir .idlerc' at the terminal prompt. The IDLE issue is that IDLE quits when it cannot create .idlerc. In this respect, this is a duplicate of #8231. That this can happen after what seemed like a 'normal' install (on a home machine?) gives me a bit more impetus to work on that issue. ---------- assignee: terry.reedy -> superseder: -> Unable to run IDLE without write-access to home directory _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 15:19:43 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 30 Dec 2017 20:19:43 +0000 Subject: [issue32458] test_asyncio failures on Windows In-Reply-To: <1514661650.99.0.213398074469.issue32458@psf.upfronthosting.co.za> Message-ID: <1514665183.74.0.213398074469.issue32458@psf.upfronthosting.co.za> Change by Yury Selivanov : ---------- keywords: +patch pull_requests: +4935 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 15:20:49 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sat, 30 Dec 2017 20:20:49 +0000 Subject: [issue32248] Port importlib_resources (module and ABC) to Python 3.7 In-Reply-To: <1512681159.94.0.213398074469.issue32248@psf.upfronthosting.co.za> Message-ID: <1514665249.65.0.213398074469.issue32248@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Next up - implementing the ResourceReader ABC. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 15:21:38 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 30 Dec 2017 20:21:38 +0000 Subject: [issue32458] test_asyncio failures on Windows In-Reply-To: <1514661650.99.0.213398074469.issue32458@psf.upfronthosting.co.za> Message-ID: <1514665298.07.0.213398074469.issue32458@psf.upfronthosting.co.za> Yury Selivanov added the comment: I'm leaving on a two-weeks vacation today. To avoid risking breaking the workflow, I'll mask this tests on AppVeyor. I'll investigate this when I get back. ---------- assignee: -> yselivanov components: +asyncio -Library (Lib), Tests priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 15:40:22 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 30 Dec 2017 20:40:22 +0000 Subject: [issue32458] test_asyncio failures on Windows In-Reply-To: <1514661650.99.0.213398074469.issue32458@psf.upfronthosting.co.za> Message-ID: <1514666422.78.0.213398074469.issue32458@psf.upfronthosting.co.za> Yury Selivanov added the comment: New changeset 0c36bed1c46d07ef91d3e02e69e974e4f3ecd31a by Yury Selivanov in branch 'master': bpo-32458: Temporarily mask start-tls proactor test on Windows (#5054) https://github.com/python/cpython/commit/0c36bed1c46d07ef91d3e02e69e974e4f3ecd31a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 15:42:28 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 30 Dec 2017 20:42:28 +0000 Subject: [issue32458] test_asyncio failures on Windows In-Reply-To: <1514661650.99.0.213398074469.issue32458@psf.upfronthosting.co.za> Message-ID: <1514666548.16.0.213398074469.issue32458@psf.upfronthosting.co.za> Yury Selivanov added the comment: Please keep this issue open. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 15:56:29 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 30 Dec 2017 20:56:29 +0000 Subject: [issue8231] Unable to run IDLE without write-access to home directory In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za> Message-ID: <1514667389.3.0.213398074469.issue8231@psf.upfronthosting.co.za> Ned Deily added the comment: > Ned diagnosed #32447 as likely due to the space in the user name. Actually, that's not what the primary problem was. It was a severely misconfigured home directory, both permissions and groups. I'm not sure how that situation was created (possibly through inadvertent sysadmin commands from the shell) but it's not something that IDLE needs to worry about; such a configuration breaks lots of other system programs. In other words, the OP's system was broken. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 16:07:50 2017 From: report at bugs.python.org (R. David Murray) Date: Sat, 30 Dec 2017 21:07:50 +0000 Subject: [issue32451] python -m venv activation issue when using cygwin on windows In-Reply-To: <1514607229.33.0.213398074469.issue32451@psf.upfronthosting.co.za> Message-ID: <1514668070.71.0.213398074469.issue32451@psf.upfronthosting.co.za> R. David Murray added the comment: cygwin in not currently fully supported (there are people working on it, though). Can you determine if this is a bug in cygwin's bash support, or something else? It certainly works with bash shell on unix. I would presume that from cygwin one would want the posix way to work, and that it should be possible. ---------- nosy: +erik.bray, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 16:14:03 2017 From: report at bugs.python.org (R. David Murray) Date: Sat, 30 Dec 2017 21:14:03 +0000 Subject: [issue32452] Brackets and Parentheses used in an ambiguous way In-Reply-To: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za> Message-ID: <1514668443.61.0.213398074469.issue32452@psf.upfronthosting.co.za> R. David Murray added the comment: "round brackets" would require just as much thought (if not more...it's not a thing at all in American typographical language) for an American to understand as the unadorned bracket does for the rest of you, so the best compromise is "parenthesis instead of square brackets", since parenthesis is used elsewhere in the docs. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 16:30:33 2017 From: report at bugs.python.org (R. David Murray) Date: Sat, 30 Dec 2017 21:30:33 +0000 Subject: [issue32448] subscriptable In-Reply-To: <1514573988.38.0.213398074469.issue32448@psf.upfronthosting.co.za> Message-ID: <1514669433.25.0.213398074469.issue32448@psf.upfronthosting.co.za> R. David Murray added the comment: Well, in that case having 'organizer' in the error message wouldn't help you untangle your code ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 16:37:51 2017 From: report at bugs.python.org (pfreixes) Date: Sat, 30 Dec 2017 21:37:51 +0000 Subject: [issue30861] StreamReader does not return reamaing and ready data buffer before raise the Exeption In-Reply-To: <1499288108.18.0.207232280352.issue30861@psf.upfronthosting.co.za> Message-ID: <1514669871.75.0.213398074469.issue30861@psf.upfronthosting.co.za> pfreixes added the comment: Yeps, any update on this bug and the fix proposed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 16:39:24 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 30 Dec 2017 21:39:24 +0000 Subject: [issue32399] _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc.. In-Reply-To: <1513882147.82.0.213398074469.issue32399@psf.upfronthosting.co.za> Message-ID: <1514669964.0.0.213398074469.issue32399@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New changeset 0d3ccb4395cccb11a50289c84c9a0dbbac03c647 by Antoine Pitrou (Michael Felt) in branch 'master': bpo-32399: Starting with AIX6.1 there is support in libc.a for uuid (RFC4122) (#4974) https://github.com/python/cpython/commit/0d3ccb4395cccb11a50289c84c9a0dbbac03c647 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 16:40:46 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 30 Dec 2017 21:40:46 +0000 Subject: [issue32399] _uuidmodule.c cannot build on AIX - different typedefs of uuid_t, etc.. In-Reply-To: <1513882147.82.0.213398074469.issue32399@psf.upfronthosting.co.za> Message-ID: <1514670046.85.0.213398074469.issue32399@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 23:21:08 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Sun, 31 Dec 2017 04:21:08 +0000 Subject: [issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element In-Reply-To: <1514141500.33.0.213398074469.issue32424@psf.upfronthosting.co.za> Message-ID: <1514694068.08.0.579767187378.issue32424@psf.upfronthosting.co.za> Gordon P. Hemsley added the comment: As discussed above, starting with msg309074, __deepcopy__() is being added to the Python implementation because it already exists in the C implementation. And additional tests have in fact uncovered further discrepancies between the Python and C implementations with regard to copying behavior. PR 5046 has changes that I believe are ready for review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 30 23:30:12 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 31 Dec 2017 04:30:12 +0000 Subject: [issue10381] Add timezone support to datetime C API In-Reply-To: <1514648044.84.0.213398074469.issue10381@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: On 31 December 2017 at 01:34, Paul Ganssle wrote: > That said, I think it would be really good if we could get a fast path for timezone creation and access to the UTC singleton into the Python 3.7 release. I think it's kind of a big disparity between the Python and C APIs that's existed for too long already. It turns out the API already *is* exported as a capsule: https://github.com/python/cpython/blob/master/Include/datetime.h#L149 Our general guidance for capsule usage is just outdated, and the datetime API follows that dated advice: https://docs.python.org/3/extending/extending.html#providing-a-c-api-for-an-extension-module I'll file a separate issue for that docs problem later (the tracker is reporting 502 Proxy Error for me right now) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 00:07:55 2017 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 31 Dec 2017 05:07:55 +0000 Subject: [issue23859] asyncio: document behaviour of wait() cancellation In-Reply-To: <1428073997.46.0.438809738394.issue23859@psf.upfronthosting.co.za> Message-ID: <1514696875.45.0.467229070634.issue23859@psf.upfronthosting.co.za> Change by Chris Jerdonek : ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 00:09:04 2017 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 31 Dec 2017 05:09:04 +0000 Subject: [issue23859] asyncio: document behaviour of wait() cancellation In-Reply-To: <1428073997.46.0.438809738394.issue23859@psf.upfronthosting.co.za> Message-ID: <1514696944.24.0.467229070634.issue23859@psf.upfronthosting.co.za> Change by Chris Jerdonek : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 00:25:00 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 31 Dec 2017 05:25:00 +0000 Subject: [issue31530] Python 2.7 readahead feature of file objects is not thread safe In-Reply-To: <1505914032.54.0.91752475423.issue31530@psf.upfronthosting.co.za> Message-ID: <1514697900.6.0.467229070634.issue31530@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Unfortunately, it looks like this fix causes a regression. Some programs rely on being able to seek() and write to a file on multiple threads. For example, py.test captures the standard streams by redirecting them to a tmpfile and then truncating+seeking to 0 after every test. This change broke that situation when multiple threads are logging. Anyway, there's no real fundamental reason to prevent concurrent access, since the underlying stdio implementation is threadsafe. I think we'll have to resurrect my PR. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 00:27:01 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 31 Dec 2017 05:27:01 +0000 Subject: [issue32459] Capsule API usage docs are incompatible with module reloading (etc) Message-ID: <1514698021.73.0.467229070634.issue32459@psf.upfronthosting.co.za> New submission from Nick Coghlan : After commenting [1] on the fact that the current datetime module C API [2] is problematic due to its reliance on C level global variables, I discovered that this is actually the outcome of our recommended approach to using capsules to export a C API as function pointers: https://docs.python.org/3/extending/extending.html#providing-a-c-api-for-an-extension-module So we first need to fix the documentation to propose a reloading friendly way of using capsules in other extension modules, and then we can then propose updating the public datetime C API accordingly (probably by defining new macros that accept the capsule reference as their first argument). [1] https://bugs.python.org/issue10381#msg309214 [2] https://docs.python.org/3/c-api/datetime.html [3] https://docs.python.org/3/extending/extending.html#providing-a-c-api-for-an-extension-module ---------- messages: 309266 nosy: brett.cannon, eric.snow, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Capsule API usage docs are incompatible with module reloading (etc) type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 00:27:48 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 31 Dec 2017 05:27:48 +0000 Subject: [issue31530] Python 2.7 readahead feature of file objects is not thread safe In-Reply-To: <1505914032.54.0.91752475423.issue31530@psf.upfronthosting.co.za> Message-ID: <1514698068.01.0.467229070634.issue31530@psf.upfronthosting.co.za> Change by Benjamin Peterson : ---------- pull_requests: +4936 stage: resolved -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 00:28:49 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 31 Dec 2017 05:28:49 +0000 Subject: [issue10381] Add timezone support to datetime C API In-Reply-To: <1289415057.12.0.111170767809.issue10381@psf.upfronthosting.co.za> Message-ID: <1514698129.29.0.467229070634.issue10381@psf.upfronthosting.co.za> Nick Coghlan added the comment: https://bugs.python.org/issue32459 covers defining a module-reloading-friendly way of using capsules. For this issue, I now think it makes sense to just ignore that problem, and add whatever you need to the existing API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 00:31:06 2017 From: report at bugs.python.org (Marcel Widjaja) Date: Sun, 31 Dec 2017 05:31:06 +0000 Subject: [issue29237] Create enum for pstats sorting options In-Reply-To: <1484098294.24.0.117553666266.issue29237@psf.upfronthosting.co.za> Message-ID: <1514698266.7.0.467229070634.issue29237@psf.upfronthosting.co.za> Marcel Widjaja added the comment: I'd like to try to work on this one ---------- nosy: +mawidjaj _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 00:32:37 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 31 Dec 2017 05:32:37 +0000 Subject: [issue32460] don't use tentative declarations Message-ID: <1514698357.94.0.467229070634.issue32460@psf.upfronthosting.co.za> New submission from Benjamin Peterson : Tentative declarations (non-extern declarations without initializers) are legacy C-ism that we should eschew by ensuring all our declarations have initializers. ---------- components: Build messages: 309269 nosy: benjamin.peterson priority: normal severity: normal status: open title: don't use tentative declarations versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 00:33:43 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 31 Dec 2017 05:33:43 +0000 Subject: [issue32460] don't use tentative declarations In-Reply-To: <1514698357.94.0.467229070634.issue32460@psf.upfronthosting.co.za> Message-ID: <1514698423.8.0.467229070634.issue32460@psf.upfronthosting.co.za> Change by Benjamin Peterson : ---------- keywords: +patch pull_requests: +4937 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 02:07:27 2017 From: report at bugs.python.org (devurandom) Date: Sun, 31 Dec 2017 07:07:27 +0000 Subject: [issue15112] argparse: nargs='*' positional argument doesn't accept any items if preceded by an option and another positional In-Reply-To: <1340165747.87.0.563099760163.issue15112@psf.upfronthosting.co.za> Message-ID: <1514704047.44.0.467229070634.issue15112@psf.upfronthosting.co.za> Change by devurandom : ---------- nosy: +devurandom _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 02:53:32 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 31 Dec 2017 07:53:32 +0000 Subject: [issue32461] the first build after a change to Makefile.pre.in uses the old Makefile Message-ID: <1514706812.13.0.467229070634.issue32461@psf.upfronthosting.co.za> New submission from Xavier de Gaye : After applying the attached Makefile.pre.in.diff that changes the text of the message printed by the 'Makefile' target, the make command gives: $ make CONFIG_FILES=Makefile.pre CONFIG_HEADERS= /bin/sh config.status config.status: creating Makefile.pre make -f Makefile.pre Makefile make[1]: Entering directory '/path/to/master' /bin/sh ./Modules/makesetup -c ./Modules/config.c.in \ -s Modules \ Modules/Setup.local \ Modules/Setup This is the new Makefile. The Makefile was updated, you may need to re-run make. <--- new Makefile make[1]: Leaving directory '/path/to/master' /bin/sh ./Modules/makesetup -c ./Modules/config.c.in \ -s Modules \ Modules/Setup.local \ Modules/Setup The Makefile was updated, you may need to re-run make. <--- old Makefile gcc -pthread -c -Wno-unused-result -Wsign-compare -g -Og -Wall -Wstrict-prototypes -std=c99 -Wext ra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-functio n-declaration -I. -I./Include -DPy_BUILD_CORE \ -DABIFLAGS='"dm"' \ -DMULTIARCH=\"x86_64-linux-gnu\" \ -o Python/sysmodule.o ./Python/sysmodule.c .... The two messages printed by the 'Makefile' target show that make is still running the previous Makefile after completing the sub-make (i.e. after the line "make[1]: Leaving directory '/path/to/master'"). ---------- components: Build files: Makefile.pre.in.diff keywords: patch messages: 309270 nosy: xdegaye priority: normal severity: normal stage: needs patch status: open title: the first build after a change to Makefile.pre.in uses the old Makefile type: behavior versions: Python 2.7, Python 3.6, Python 3.7 Added file: https://bugs.python.org/file47356/Makefile.pre.in.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 04:39:38 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 31 Dec 2017 09:39:38 +0000 Subject: [issue32449] MappingView must inherit from Collection instead of Sized In-Reply-To: <1514584775.87.0.213398074469.issue32449@psf.upfronthosting.co.za> Message-ID: <1514713178.32.0.467229070634.issue32449@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > After I generate an UML diagram from collections.abc, I found > very strange that MappingView inherit from Sized instead > of Collection (new in python 3.6). That isn't strange at all. MappingView predates Collection, so of course it didn't inherit from collection. > Yes, MappingView only define __len__ and not __iter__ > and __contains__, but all of its subclasses define them > (KeysView, ValuesView and ItemViews). It is irrelevant what extra behaviors subclasses may or may not add. The MappingView ABC is a public API and users are free to use it in other ways (as long as they stick with the publicly document API). For example, the following is allowed (even it seems odd to you): >>> from collections.abc import MappingView >>> mv = MappingView(['a', 'b']) >>> len(mv) # guaranteed 2 >>> repr(mv) # guaranteed "MappingView(['a', 'b'])" >>> 'a' in mv # not guaranteed Traceback (most recent call last): File "", line 1, in 'a' in mv TypeError: argument of type 'MappingView' is not iterable >>> list(mv) # not guaranteed Traceback (most recent call last): File "", line 1, in list(mv) TypeError: 'MappingView' object is not iterable ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 04:57:17 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 31 Dec 2017 09:57:17 +0000 Subject: [issue32449] MappingView must inherit from Collection instead of Sized In-Reply-To: <1514584775.87.0.213398074469.issue32449@psf.upfronthosting.co.za> Message-ID: <1514714237.41.0.467229070634.issue32449@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I concur with Raymond. MappingView is a public interface, not just a concrete implementation. Changing it will make third-party implementations of this interface not conforming it. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 05:28:10 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 31 Dec 2017 10:28:10 +0000 Subject: [issue32430] Simplify Modules/Setup{,.dist,.local} In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za> Message-ID: <1514716090.05.0.467229070634.issue32430@psf.upfronthosting.co.za> Change by Xavier de Gaye : ---------- keywords: +patch pull_requests: +4938 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 05:31:29 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 31 Dec 2017 10:31:29 +0000 Subject: [issue32430] Simplify Modules/Setup{,.dist,.local} In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za> Message-ID: <1514716289.43.0.467229070634.issue32430@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The Setup files are configuration files, so their handling is different from the handling of Makefile.pre.in or the handling of the source files. The only reference to Setup.local in the Python documentation is at https://docs.python.org/3/extending/extending.html#compilation-and-linkage, so most users that need to configure the build with a Setup file are probably using Modules/Setup instead of Modules/Setup.local and the solution that implements this enhancement cannot overwrite an existing Modules/Setup file. This solution must also be robust and transparent when switching to/from a branch where the solution is not implemented yet (a bpo branch created earlier). PR 5062 adds the ``--enable-use-setup-dist`` configure option to use Modules/Setup.dist instead of Modules/Setup to build the Makefile. The build behavior is unchanged when this option is not used. ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 05:56:12 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 31 Dec 2017 10:56:12 +0000 Subject: [issue30449] Improve __slots__ datamodel documentation In-Reply-To: <1495587707.13.0.0998591622446.issue30449@psf.upfronthosting.co.za> Message-ID: <1514717772.34.0.467229070634.issue30449@psf.upfronthosting.co.za> Raymond Hettinger added the comment: mpb, I think the docs with respect to strings are fine as-is. Sometimes if too much detail is put in, it makes the docs harder to read and understand (i.e. it gets in the way of our primary purpose). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 06:07:49 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Sun, 31 Dec 2017 11:07:49 +0000 Subject: [issue32462] mimetypes.guess_type() might be return None or a tuple with (type/subtype, encoding) Message-ID: <1514718469.31.0.467229070634.issue32462@psf.upfronthosting.co.za> New submission from Cheryl Sabella : On a Windows 7 system, entering the following: >>> mime, encoding = mimetypes.guess_type('Untitled.sql') >>> mime 'text\\plain' Meaning, the return value is 'text\\plain' instead of 'text/plain'. Tracking this down, it's due to .sql being loaded from the Windows registry and the registry is using the wrong slash. The mimetypes.guess_type() documentation states: > The return value is a tuple (type, encoding) where type is None if > the type can?t be guessed (missing or unknown suffix) or a string of > the form 'type/subtype', usable for a MIME content-type header. I don't know if guess_type() (or add_types) should check for a valid types, if .sql should be added to the valid types (it's on the IANA page), or if the documentation should be fixed so it doesn't look like a guarantee. Or all three. :-) ---------- components: Library (Lib) messages: 309275 nosy: csabella priority: normal severity: normal status: open title: mimetypes.guess_type() might be return None or a tuple with (type/subtype, encoding) type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 06:08:35 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Sun, 31 Dec 2017 11:08:35 +0000 Subject: [issue32462] mimetypes.guess_type() returns incorrectly formatted type In-Reply-To: <1514718469.31.0.467229070634.issue32462@psf.upfronthosting.co.za> Message-ID: <1514718515.07.0.467229070634.issue32462@psf.upfronthosting.co.za> Change by Cheryl Sabella : ---------- title: mimetypes.guess_type() might be return None or a tuple with (type/subtype, encoding) -> mimetypes.guess_type() returns incorrectly formatted type _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 06:12:31 2017 From: report at bugs.python.org (Nick McElwaine) Date: Sun, 31 Dec 2017 11:12:31 +0000 Subject: [issue32463] problems with shutil.py and os.get_terminal_size Message-ID: <1514718751.47.0.467229070634.issue32463@psf.upfronthosting.co.za> New submission from Nick McElwaine : os.get_terminal_size() fails with () or (0) or (1) shutil.sys fails calling it with (sys.__stdout__.fileno()) because sys.__stdout__ is type None ---------- components: Windows messages: 309276 nosy: Dhruve, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: problems with shutil.py and os.get_terminal_size type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 06:27:36 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Sun, 31 Dec 2017 11:27:36 +0000 Subject: [issue32462] mimetypes.guess_type() returns incorrectly formatted type In-Reply-To: <1514718469.31.0.467229070634.issue32462@psf.upfronthosting.co.za> Message-ID: <1514719656.98.0.467229070634.issue32462@psf.upfronthosting.co.za> Change by Cheryl Sabella : ---------- keywords: +patch pull_requests: +4939 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 06:44:32 2017 From: report at bugs.python.org (Srinivas Reddy T) Date: Sun, 31 Dec 2017 11:44:32 +0000 Subject: [issue32464] raise NotImplemented vs return NotImplemented Message-ID: <1514720672.06.0.467229070634.issue32464@psf.upfronthosting.co.za> New submission from Srinivas Reddy T : I ran these queries on cpython repo. ? cpython git:(master) ? grep -r . -e return --include=\*.py | grep NotImplemented | wc -l 196 ? cpython git:(master) ? grep -r . -e raise --include=\*.py | grep NotImplemented | wc -l 295 I have always used raise NotImplemented or raise NotImplementedError. But when does it make sense to return NotImplemented? ---------- messages: 309277 nosy: thatiparthy priority: normal severity: normal status: open title: raise NotImplemented vs return NotImplemented type: resource usage versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 06:57:10 2017 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 31 Dec 2017 11:57:10 +0000 Subject: [issue32464] raise NotImplemented vs return NotImplemented In-Reply-To: <1514720672.06.0.467229070634.issue32464@psf.upfronthosting.co.za> Message-ID: <1514721430.69.0.467229070634.issue32464@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's the documentation, which I think explains all this clearly: briefly, `return NotImplemented` and `raise NotImplementedError` are the normal usages. `raise NotImplemented` doesn't make sense, and shouldn't be used: it'll end up raising a `TypeError`, sine `NotImplemented` is neither a subclass nor an instance of BaseException. NotImplemented: https://docs.python.org/3.7/library/constants.html#NotImplemented NotImplementedError: https://docs.python.org/3.7/library/exceptions.html#NotImplementedError Almost all of the grep results you're seeing do follow the expected patterns (either `return NotImplemented` or `raise NotImplementedError`, but a quick grep does show some questionable uses of `raise NotImplemented` in the standard library: MacBook-Pro:cpython mdickinson$ grep -r . -e raise --include=\*.py | grep "\bNotImplemented\b" ./Lib/asyncio/transports.py: The implementation here raises NotImplemented for every method ./Lib/idlelib/debugger_r.py: raise NotImplemented("dict_keys not public or pickleable") ./Lib/ssl.py: raise NotImplemented("Can't dup() %s instances" % The other way around also turns up an odd-looking `return NotImplementedError` (along with a false positive): MacBook-Pro:cpython mdickinson$ grep -r . -e return --include=\*.py | grep "\bNotImplementedError\b" ./Lib/ctypes/test/test_simplesubclasses.py: return NotImplementedError ./Lib/test/test_asyncio/test_transports.py: self.assertRaises(NotImplementedError, transport.get_returncode) ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 07:18:32 2017 From: report at bugs.python.org (Eryk Sun) Date: Sun, 31 Dec 2017 12:18:32 +0000 Subject: [issue32463] problems with shutil.py and os.get_terminal_size In-Reply-To: <1514718751.47.0.467229070634.issue32463@psf.upfronthosting.co.za> Message-ID: <1514722712.41.0.467229070634.issue32463@psf.upfronthosting.co.za> Eryk Sun added the comment: The 3.5 branch only gets security fixes at this point. Consider upgrading to 3.6. That said, this shouldn't be a problem with shutil.get_terminal_size() in 3.5. It handles AttributeError, ValueError, and OSError by returning the `fallback` size. And it's expected that `os.get_terminal_size(1)` will fail if there's no attached console. ---------- components: +Library (Lib) nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 07:50:25 2017 From: report at bugs.python.org (Yahya Abou Imran) Date: Sun, 31 Dec 2017 12:50:25 +0000 Subject: [issue32449] MappingView must inherit from Collection instead of Sized In-Reply-To: <1514584775.87.0.213398074469.issue32449@psf.upfronthosting.co.za> Message-ID: <1514724625.5.0.467229070634.issue32449@psf.upfronthosting.co.za> Yahya Abou Imran added the comment: Hmm... Okay, I understand. So the only objection I have left, it's that ValuesView isn't passing the is instance of Collection test whereas it should, since he has the full behavior of one. It could be passed in its register to solve this. But it's not realy the same issue. Maybe I have to open a new one? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 07:55:46 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 31 Dec 2017 12:55:46 +0000 Subject: [issue32430] Simplify Modules/Setup{,.dist,.local} In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za> Message-ID: <1514724946.89.0.467229070634.issue32430@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I would hope to simplify the build process, not to complicate it. In other words, I think the PR is a step in the wrong direction, *except* if using Setup.dist becomes the default and the other way is clearly marked deprecated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 08:03:19 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 31 Dec 2017 13:03:19 +0000 Subject: [issue32430] Simplify Modules/Setup{,.dist,.local} In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za> Message-ID: <1514725399.35.0.467229070634.issue32430@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note the use case we're trying to preserve here is probably extremely rare. I've never needed it myself, and I've never seen it done by anyone else. We're talking about a very small demographics who's probably skilled enough to handle a little complexity in their workflow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 09:01:13 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 31 Dec 2017 14:01:13 +0000 Subject: [issue32430] Simplify Modules/Setup{,.dist,.local} In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za> Message-ID: <1514728873.6.0.467229070634.issue32430@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > and I've never seen it done by anyone else In msg294174 Thomas says he intends to use it for Python at Google in order to "avoid third-party libraries even when they are available on the build system". I do not have a strong opinion about this. Implementing the reverse configure option '--enable-custom-setup' is straightforward (actually this is what I did upon the first shot at this PR), Setup.dist becomes the default then and Thomas can still use Setup.local to add the *disabled* modules. It is annoying that there is no documentation on the build process that can be modified to describe the deprecation in details. Do you think a What'sNew entry is sufficient ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 09:01:24 2017 From: report at bugs.python.org (chansol kim) Date: Sun, 31 Dec 2017 14:01:24 +0000 Subject: [issue32465] [urllib] proxy_bypass_registry - extra error handling required for ProxyOverride, Windows under proxy environment Message-ID: <1514728884.14.0.467229070634.issue32465@psf.upfronthosting.co.za> New submission from chansol kim : [Problem] - String value from registry Proxy override is read and incorrectly decides the current connection requires not to use proxy. [Setup] - Using urllib under proxy environment. - Proxy bypass settings are in place. ProxyOverride string value in registry ends with ; [Detail] https://github.com/python/cpython/blob/2.7/Lib/urllib.py proxy_bypass_registry has an issue 1. It gets registry value from HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings ProxyEnable string value. 2. Splits the string with ;. And as the registry value ends with ; the split list contains a zero length string at the end. 3. Use the split string to re.match. And as there is zero length string at the end it, and the result of re.match('', 'anystring', re.I) is always not None. 4. Afterwards connection is attempted without using the proxy, hence connection cannot be made >From line 1617 proxyOverride = proxyOverride.split(';') # now check if we match one of the registry values. for test in proxyOverride: if test == '': if '.' not in rawHost: return 1 test = test.replace(".", r"\.") # mask dots test = test.replace("*", r".*") # change glob sequence test = test.replace("?", r".") # change glob char for val in host: # print "%s <--> %s" %( test, val ) if re.match(test, val, re.I): return 1 ---------- components: Library (Lib) messages: 309284 nosy: chansol kim priority: normal severity: normal status: open title: [urllib] proxy_bypass_registry - extra error handling required for ProxyOverride, Windows under proxy environment type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 09:06:21 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 31 Dec 2017 14:06:21 +0000 Subject: [issue32430] Simplify Modules/Setup{,.dist,.local} In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za> Message-ID: <1514729181.77.0.467229070634.issue32430@psf.upfronthosting.co.za> Antoine Pitrou added the comment: First, I would count Google in the extremely skilled category :-) (cc'ing Thomas so that he can chime in) Second, if someone are doing a custom build of Python, they are very likely modifying something else than Modules/Setup (*). So they already have some kind of custom branch or fork of CPython tracking their own customizations. Why Modules/Setup can't be handled the same way I'm not sure I understand. (*) see for example the Anaconda build of Python, which modifies several files but *not* Modules/Setup: https://github.com/AnacondaRecipes/python-feedstock/ ---------- nosy: +twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 09:06:51 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 31 Dec 2017 14:06:51 +0000 Subject: [issue32430] Simplify Modules/Setup{,.dist,.local} In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za> Message-ID: <1514729211.41.0.467229070634.issue32430@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > It is annoying that there is no documentation on the build process that can be modified to describe the deprecation in details. Do you think a What'sNew entry is sufficient ? Yes, I think so. Also my hope is to remove it in 3.8 :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 09:36:44 2017 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 31 Dec 2017 14:36:44 +0000 Subject: [issue32430] Simplify Modules/Setup{,.dist,.local} In-Reply-To: <1514373303.98.0.213398074469.issue32430@psf.upfronthosting.co.za> Message-ID: <1514731004.67.0.467229070634.issue32430@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Yes 3.8 and this leaves plenty of time for writing some documentation on the build process :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 09:53:55 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Sun, 31 Dec 2017 14:53:55 +0000 Subject: [issue32466] Remove fractions._gcd() Message-ID: <1514732035.0.0.467229070634.issue32466@psf.upfronthosting.co.za> New submission from Gordon P. Hemsley : I noticed that there was a single line of Lib/fractions.py that did not have test coverage: the normalize step for fractions with non-integer numerators and/or denominators. I initially was going to implement a test for that line, but upon further reflection, I cannot envision a scenario where that would be possible. The code already requires its initial parameters to be numbers.Rational and then normalizes their numerators and denominators to be integers. So, instead, I propose to remove this check, first introduced in issue22486, and to roll the fractions._gcd() function up into the deprecated fractions.gcd(). ---------- components: Library (Lib), Tests messages: 309288 nosy: gphemsley, mark.dickinson, rhettinger priority: normal severity: normal status: open title: Remove fractions._gcd() versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 10:36:24 2017 From: report at bugs.python.org (Yahya Abou Imran) Date: Sun, 31 Dec 2017 15:36:24 +0000 Subject: [issue32467] dict_values isn't considered a Collection nor a Container Message-ID: <1514734584.09.0.467229070634.issue32467@psf.upfronthosting.co.za> New submission from Yahya Abou Imran : a `dict_values` instance behaves like a Collection (a Sized Iterable Container): >>> values = {1: 'one', 2: 'two'}.values() >>> 'two' in values True >>> 'three' in values False >>> for value in values: print(value) one two >>> len(values) 2 But... >>> isinstance(values, abc.Collection) False >>> isinstance(values, abc.Container) False The reason is the lack of __contains__(): >>> '__contains__' in dir(values) False The 'in' operator works above because it uses __iter__() to check the presence of the value. I think it's inconsistent with the fact that dict_values is in the registry of ValuesView witch passes the test: >>> issubclass(abc.ValuesView, abc.Collection) True A class passed in the registry of ValuesView should guarantee this behaviour (witch is the case here by the way, but informally). I can think about several solutions for this: 1. add a __contains__() to the dict_values class; 2. if an ABC is considered a subclass of another ABC, all the classes in the registry of the first (and recursively all of their subclasses) should be too; 3. pass dict_values in the registry of Container or Collection; 4. make ValuesView inherit from Container or Collection. IMHO: 1 is out. 2 makes sense, but may be difficult to implement since it implies that a class has to know all the registries it's been passed in. 3 and 4 are by far the easiest ways to do it. I think the inheritance from Collection is the best solution, because KeysView and ItemsView are already Collections by inheriting from Set witch inherits from Collection. The only fondamental difference between the three views (in terms of protocol and API), it's that ValuesView is not a Set. ---------- messages: 309289 nosy: yahya-abou-imran priority: normal severity: normal status: open title: dict_values isn't considered a Collection nor a Container type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 11:08:06 2017 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 31 Dec 2017 16:08:06 +0000 Subject: [issue32466] Remove fractions._gcd() In-Reply-To: <1514732035.0.0.467229070634.issue32466@psf.upfronthosting.co.za> Message-ID: <1514736486.9.0.467229070634.issue32466@psf.upfronthosting.co.za> Mark Dickinson added the comment: > [...] I cannot envision a scenario where that would be possible [...] I don't think it can be ruled out. If I'm reading the code right, it's preceded by this branch of the initial if/elif chain: elif (isinstance(numerator, numbers.Rational) and isinstance(denominator, numbers.Rational)): numerator, denominator = ( numerator.numerator * denominator.denominator, denominator.numerator * numerator.denominator ) I don't think there's any guarantee that if `numerator` is an instance of `numbers.Rational`, then `numerator.numerator` and `numerator.denominator` have exact type `int`. (Note that an instance of `numbers.Rational` is not necessarily an instance of `fractions.Fraction`.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 11:38:10 2017 From: report at bugs.python.org (R. David Murray) Date: Sun, 31 Dec 2017 16:38:10 +0000 Subject: [issue32462] mimetypes.guess_type() returns incorrectly formatted type In-Reply-To: <1514718469.31.0.467229070634.issue32462@psf.upfronthosting.co.za> Message-ID: <1514738290.34.0.467229070634.issue32462@psf.upfronthosting.co.za> R. David Murray added the comment: You can get the same "bad" behavior on a posix system by having a mimetypes file with an incorrect entry in it. That would be a system misconfiguration, as is your Windows registry case, and is outside of Python's control. I suppose we could make it clearer (ie: in that intro paragraph) that the system files are read by default (that is, the built-in tables are only *defaults* unless you specify otherwise). It is unfortunately true that the mime types in the Windows registry are less reliable than those on unix systems. This has nothing to do with the mimetypes module itself, though ;) I wonder if we should have made the default to be loading windows registry as non-strict, but that ship has sailed, I think. Checking for at least minimal validity (xxx/yyy) would at least make things a little better on Windows, so I wouldn't object to adding that. To summarize, my suggestion would be to add a note to the intro paragraph that system files/registry are read by default and override the built-in tables, and add a minimal sanity check on the mime type values read. Adding .sql to the strict list is a separate issue, and would not change the behavior here (unless I'm missing something, which is possible). There are issues around adding even a minimal validity check, though: do we backport that? Do we silently ignore strings in the wrong format? Do we "fix" a backslash to be a slash? Do we issue a warning for any problems we find? These questions should be discussed if we decide to go this route. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 12:28:56 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 31 Dec 2017 17:28:56 +0000 Subject: [issue32460] don't use tentative declarations In-Reply-To: <1514698357.94.0.467229070634.issue32460@psf.upfronthosting.co.za> Message-ID: <1514741336.98.0.467229070634.issue32460@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Sounds like good hygiene to me, though I didn't know that "tentative declarations" were legacy (don't they simply mean the variable gets an arbitrary initialization value?). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 12:41:41 2017 From: report at bugs.python.org (mpb) Date: Sun, 31 Dec 2017 17:41:41 +0000 Subject: [issue30449] Improve __slots__ datamodel documentation In-Reply-To: <1495587707.13.0.0998591622446.issue30449@psf.upfronthosting.co.za> Message-ID: <1514742101.28.0.467229070634.issue30449@psf.upfronthosting.co.za> mpb added the comment: @rhettinger I disagree (but you're the boss). If a function can take type X as a parameter, I believe docs should also say what the expected behavior is when you call the function and pass it type X, especially when type X is fundamentally different from every other type the function accepts. (And yes, __slots__ is not a function, but I still find the metaphor apt.) Cheers! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 13:02:17 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 31 Dec 2017 18:02:17 +0000 Subject: [issue32460] don't use tentative declarations In-Reply-To: <1514698357.94.0.467229070634.issue32460@psf.upfronthosting.co.za> Message-ID: <1514743337.49.0.467229070634.issue32460@psf.upfronthosting.co.za> Benjamin Peterson added the comment: If no definition provides an initializer, they'll end up initialized to 0. The legacy part is that you can have multiple tentative definitions of a symbol and most unix linkers will merge them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 13:04:16 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 31 Dec 2017 18:04:16 +0000 Subject: [issue32460] don't use tentative declarations In-Reply-To: <1514698357.94.0.467229070634.issue32460@psf.upfronthosting.co.za> Message-ID: <1514743456.29.0.467229070634.issue32460@psf.upfronthosting.co.za> Benjamin Peterson added the comment: New changeset 0a37a30037073a4a9ba45e560c8445048e5f2ba2 by Benjamin Peterson in branch 'master': closes bpo-32460: ensure all non-static globals have initializers (#5061) https://github.com/python/cpython/commit/0a37a30037073a4a9ba45e560c8445048e5f2ba2 ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 13:49:24 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sun, 31 Dec 2017 18:49:24 +0000 Subject: [issue8525] Display exception's subclasses in help() In-Reply-To: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za> Message-ID: <1514746164.14.0.467229070634.issue8525@psf.upfronthosting.co.za> Change by Sanyam Khurana : ---------- pull_requests: +4940 stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 13:52:23 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sun, 31 Dec 2017 18:52:23 +0000 Subject: [issue8525] Display exception's subclasses in help() In-Reply-To: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za> Message-ID: <1514746343.9.0.467229070634.issue8525@psf.upfronthosting.co.za> Sanyam Khurana added the comment: I've changed the version to 3.7. Not sure if this would need a backport since this is a new feature. So, I'll defer this call to a core developer. I've created a PR for the new feature. ---------- versions: +Python 3.7 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 13:53:51 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Sun, 31 Dec 2017 18:53:51 +0000 Subject: [issue32466] Remove fractions._gcd() In-Reply-To: <1514732035.0.0.467229070634.issue32466@psf.upfronthosting.co.za> Message-ID: <1514746431.73.0.467229070634.issue32466@psf.upfronthosting.co.za> Gordon P. Hemsley added the comment: Indeed, that is the code fragment I was referring to. Mathematically speaking, a rational number is one that can be expressed as a fraction of two integers, so in that regard the numerator and the denominator should both be integers. But let's assume for argument's sake that a type comes through where the numerator and the denominator are fractions: 1/2 and 2/3, respectively. This code would normalize them by cross-multiplying: numerator = 1 * 3 = 3 denominator = 2 * 3 = 6 Now they are both integers. In what scenario would the numerator and denominator be numbers.Rational but not an integer or a fraction? If someone could even come up with one, would it be worthwhile to allow as a fraction? And on the flip side, if math.gcd() only accepts integers and not, at least, numbers.Integral, wouldn't that be a bug? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 14:14:55 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 31 Dec 2017 19:14:55 +0000 Subject: [issue32468] Frame repr should be more helpful Message-ID: <1514747695.25.0.467229070634.issue32468@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Currently a frame's repr looks like this: >>> f It would be more helpful if it displayed something like: >>> f ---------- components: Interpreter Core messages: 309298 nosy: pitrou, serhiy.storchaka, yselivanov priority: normal severity: normal status: open title: Frame repr should be more helpful type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 14:33:10 2017 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 31 Dec 2017 19:33:10 +0000 Subject: [issue32466] Remove fractions._gcd() In-Reply-To: <1514732035.0.0.467229070634.issue32466@psf.upfronthosting.co.za> Message-ID: <1514748790.27.0.467229070634.issue32466@psf.upfronthosting.co.za> Mark Dickinson added the comment: > In what scenario would the numerator and denominator be numbers.Rational but not an integer or a fraction But that's not the issue here. The issue here is having an instance of `numbers.Rational` whose numerator and denominator are not specifically of concrete type `int`: the test that (IIUC) you're proposing to remove is: if type(numerator) is int is type(denominator): [...] Certainly I'd expect the numerator and denominator to be instances of `numbers.Integral`, but that's more general than being of exact type `int`. The `numbers.Integral` and `numbers.Rational` ABCs are deliberately not tied to particular concrete classes. It would be perfectly possible (and reasonable) for someone to have a `MyFraction` class that behaves like a `Fraction`, and whose numerator and denominator are instances of some other concrete class `MyInteger` that behaves like an integer. The branch in the code is necessary to support that situation, so we can't simply remove it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 14:33:57 2017 From: report at bugs.python.org (=?utf-8?q?Niklas_Hamb=C3=BCchen?=) Date: Sun, 31 Dec 2017 19:33:57 +0000 Subject: [issue32453] shutil.rmtree can have O(n^2) performance on large dirs In-Reply-To: <1514610909.88.0.213398074469.issue32453@psf.upfronthosting.co.za> Message-ID: <1514748837.06.0.467229070634.issue32453@psf.upfronthosting.co.za> Niklas Hamb?chen added the comment: Serhiy, did you run your benchmark on an SSD or a spinning disk? The coreutils bug mentions that the problem is seek times. My tests on a spinning disk with 400k files suggest that indeed rmtree() is ~30x slower than `rm -r`: # time (mkdir dirtest && cd dirtest && seq 1 100000 | xargs touch) real 0m0.722s user 0m0.032s sys 0m0.680s # time rm -rf dirtest/ real 0m0.519s user 0m0.074s sys 0m0.437s # time (mkdir dirtest && cd dirtest && seq 1 100000 | xargs touch) real 0m0.693s user 0m0.039s sys 0m0.659s # time python -c 'import shutil; shutil.rmtree("dirtest")' real 0m0.756s user 0m0.225s sys 0m0.499s # time (mkdir dirtest && cd dirtest && seq 1 100000 | xargs touch) real 0m0.685s user 0m0.032s sys 0m0.658s # time python3 -c 'import shutil; shutil.rmtree("dirtest")' real 0m0.965s user 0m0.424s sys 0m0.528s # time (mkdir dirtest && cd dirtest && seq 1 400000 | xargs touch) real 0m4.249s user 0m0.098s sys 0m2.804s # time rm -rf dirtest/ real 0m10.782s user 0m0.265s sys 0m2.213s # time (mkdir dirtest && cd dirtest && seq 1 400000 | xargs touch) real 0m5.236s user 0m0.107s sys 0m2.832s # time python -c 'import shutil; shutil.rmtree("dirtest")' real 3m8.006s user 0m1.323s sys 0m3.929s # time (mkdir dirtest && cd dirtest && seq 1 400000 | xargs touch) real 0m4.671s user 0m0.097s sys 0m2.832s # time python3 -c 'import shutil; shutil.rmtree("dirtest")' real 2m49.476s user 0m2.196s sys 0m3.695s The tests were done with coreutils rm 8.28, Python 2.7.14, Python 3.6.3, on ext4 (rw,relatime,data=ordered), on a dmraid RAID1 across 2 WDC_WD4000FYYZ disks (WD 4 TB Enterprise). Also note how deleting 100k files takes ~0.5 seconds with `rm -r` and the Pythons, but deleting 4x more files takes 20x longer with `rm -r` and ~300x longer with the Pythons. There is clearly some boundary below which we are hitting some nice cached behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 14:35:06 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 31 Dec 2017 19:35:06 +0000 Subject: [issue32468] Frame repr should be more helpful In-Reply-To: <1514747695.25.0.467229070634.issue32468@psf.upfronthosting.co.za> Message-ID: <1514748906.54.0.467229070634.issue32468@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- keywords: +patch pull_requests: +4941 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 14:35:20 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 31 Dec 2017 19:35:20 +0000 Subject: [issue32468] Frame repr should be more helpful In-Reply-To: <1514747695.25.0.467229070634.issue32468@psf.upfronthosting.co.za> Message-ID: <1514748920.56.0.467229070634.issue32468@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 14:41:31 2017 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 31 Dec 2017 19:41:31 +0000 Subject: [issue32468] Frame repr should be more helpful In-Reply-To: <1514747695.25.0.467229070634.issue32468@psf.upfronthosting.co.za> Message-ID: <1514749291.77.0.467229070634.issue32468@psf.upfronthosting.co.za> Yury Selivanov added the comment: +1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 14:53:29 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 31 Dec 2017 19:53:29 +0000 Subject: [issue32469] Generator and coroutine repr could be more helpful Message-ID: <1514750009.12.0.467229070634.issue32469@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Currently, a generator or coroutine's repr looks like this: >>> gen It could instead be something like: >>> gen (replace "suspended" with "running" or "closed" depending on the generator's status -- i.e. gi_running and gi_frame attributes) ---------- messages: 309302 nosy: benjamin.peterson, pitrou, serhiy.storchaka, yselivanov priority: normal severity: normal status: open title: Generator and coroutine repr could be more helpful versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 15:11:40 2017 From: report at bugs.python.org (=?utf-8?q?Niklas_Hamb=C3=BCchen?=) Date: Sun, 31 Dec 2017 20:11:40 +0000 Subject: [issue32453] shutil.rmtree can have O(n^2) performance on large dirs In-Reply-To: <1514610909.88.0.213398074469.issue32453@psf.upfronthosting.co.za> Message-ID: <1514751100.61.0.467229070634.issue32453@psf.upfronthosting.co.za> Niklas Hamb?chen added the comment: It turns out I was wrong when saying that there's some cache we're hitting. In fact, `rm -r` is still precisely O(n^2), even with the coreutils patch I linked. Quick overview table of the benchmark: nfiles real user sys 100000 0.51s 0.07s 0.43s 200000 2.46s 0.15s 0.89s 400000 10.78s 0.26s 2.21s 800000 44.72s 0.58s 6.03s 1600000 180.37s 1.06s 10.70s Each 2x increase of number of files results in 4x increased deletion time. Full benchmark output: # time (mkdir dirtest && cd dirtest && seq 1 100000 | xargs touch) real 0m0.722s user 0m0.032s sys 0m0.680s # time rm -rf dirtest/ real 0m0.519s user 0m0.074s sys 0m0.437s # time (mkdir dirtest && cd dirtest && seq 1 200000 | xargs touch) real 0m1.576s user 0m0.044s sys 0m1.275s # time rm -r dirtest/ real 0m2.469s user 0m0.150s sys 0m0.890s # time (mkdir dirtest && cd dirtest && seq 1 400000 | xargs touch) real 0m4.249s user 0m0.098s sys 0m2.804s # time rm -rf dirtest/ real 0m10.782s user 0m0.265s sys 0m2.213s # time (mkdir dirtest && cd dirtest && seq 1 800000 | xargs touch) real 0m10.533s user 0m0.204s sys 0m5.758s # time rm -rf dirtest/ real 0m44.725s user 0m0.589s sys 0m6.037s # time (mkdir dirtest && cd dirtest && seq 1 1600000 | xargs touch) real 0m34.480s user 0m0.382s sys 0m12.057s # time rm -r dirtest/ real 3m0.371s user 0m1.069s sys 0m10.704s ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 15:23:32 2017 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 31 Dec 2017 20:23:32 +0000 Subject: [issue32466] Remove fractions._gcd() In-Reply-To: <1514732035.0.0.467229070634.issue32466@psf.upfronthosting.co.za> Message-ID: <1514751812.75.0.467229070634.issue32466@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's a concrete example, using gmpy2 [1], that exercises the code path you're proposing to remove. I had to cheat a bit, since the gmpy2 types *don't* (currently) buy in to the numbers ABC tower (though there's no good reason that they couldn't do so), so I registered them manually. >>> import fractions, numbers >>> import gmpy2 >>> x = gmpy2.mpq(2, 3) >>> numbers.Rational.register(type(x)) >>> numbers.Integral.register(type(x.denominator)) >>> fractions.Fraction(x, x) # code path exercised here ... Fraction(1, 1) Note that the numerator and the denominator of the resulting `Fraction` object are still of type `mpz`. It _would_ be possible to remove the check and always use `math.gcd`, but it would result in a behaviour change: for the above code, we'd get a `Fraction` whose numerator and denominator were both of actual type `int` instead of `mpz`. Whether that's a desirable behaviour change or not is another question ... [1] https://gmpy2.readthedocs.io/en/latest/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 15:28:29 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 31 Dec 2017 20:28:29 +0000 Subject: [issue32453] shutil.rmtree can have O(n^2) performance on large dirs In-Reply-To: <1514610909.88.0.213398074469.issue32453@psf.upfronthosting.co.za> Message-ID: <1514752109.14.0.467229070634.issue32453@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Did you try to sync and flush caches before running `rm -r`? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 15:38:10 2017 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 31 Dec 2017 20:38:10 +0000 Subject: [issue32466] Remove fractions._gcd() In-Reply-To: <1514732035.0.0.467229070634.issue32466@psf.upfronthosting.co.za> Message-ID: <1514752690.33.0.467229070634.issue32466@psf.upfronthosting.co.za> Mark Dickinson added the comment: > if math.gcd() only accepts integers and not, at least, numbers.Integral, wouldn't that be a bug? I'd call it an enhancement opportunity rather than a bug. :-) There's no general Python-wide requirement that an instance of numbers.Integral should be acceptable anywhere an int is (though I agree that it's a nice property to have in general). But as it happens, math.gcd _does_ accept instances of numbers.Integral, since any such instance should implement the __index__ method to convert itself to a plain old int, and math.gcd passes its arguments through PyNumber_Index. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 15:44:08 2017 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 31 Dec 2017 20:44:08 +0000 Subject: [issue32466] Remove fractions._gcd() In-Reply-To: <1514732035.0.0.467229070634.issue32466@psf.upfronthosting.co.za> Message-ID: <1514753048.12.0.467229070634.issue32466@psf.upfronthosting.co.za> Mark Dickinson added the comment: > but it would result in a behaviour change: for the above code, we'd get a `Fraction` whose numerator and denominator were both of actual type `int` instead of `mpz` Ah, sorry. That's not true in this particular case. The returned gcd would be of type `int`, but then we end up dividing an `mpz` by an `int` to get an `mpz`. So I guess the problem case is where we have something that's like `mpz` but that doesn't support division by a plain `int`: I don't think there's any requirement that instances of numbers.Integral support mixed-type arithmetic with plain ints. I'd actually be happier if the `fractions.Fraction` type *did* normalise so that its numerator and denominator always had exact type `int`, but that's not the way that it was designed: it was designed to support arbitrary numbers.Integral instances. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 16:14:38 2017 From: report at bugs.python.org (=?utf-8?q?Niklas_Hamb=C3=BCchen?=) Date: Sun, 31 Dec 2017 21:14:38 +0000 Subject: [issue32453] shutil.rmtree can have O(n^2) performance on large dirs In-Reply-To: <1514610909.88.0.213398074469.issue32453@psf.upfronthosting.co.za> Message-ID: <1514754878.43.0.467229070634.issue32453@psf.upfronthosting.co.za> Niklas Hamb?chen added the comment: > Did you try to sync and flush caches before running `rm -r`? Yes, it doesn't make a difference for me, I still see the same O(n?) behaviour in `rm -r`. I've sent an email "O(n^2) performance of rm -r" to bug-coreutils at gnu.org just now, unfortunately I can't link it yet because the mailman archive doesn't show it yet. It should appear soon on http://lists.gnu.org/archive/html/bug-coreutils/2017-12/threads.html. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 16:26:31 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Sun, 31 Dec 2017 21:26:31 +0000 Subject: [issue32466] Remove fractions._gcd() In-Reply-To: <1514732035.0.0.467229070634.issue32466@psf.upfronthosting.co.za> Message-ID: <1514755591.02.0.467229070634.issue32466@psf.upfronthosting.co.za> Gordon P. Hemsley added the comment: Side note: https://github.com/aleaxit/gmpy/issues/127 suggests that the types in question were added to the numeric tower for gmpy 2.0.9 and 2.1.0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 16:31:29 2017 From: report at bugs.python.org (Gordon P. Hemsley) Date: Sun, 31 Dec 2017 21:31:29 +0000 Subject: [issue32466] Remove fractions._gcd() In-Reply-To: <1514732035.0.0.467229070634.issue32466@psf.upfronthosting.co.za> Message-ID: <1514755889.54.0.467229070634.issue32466@psf.upfronthosting.co.za> Gordon P. Hemsley added the comment: So, if I'm understanding your position correctly: * We're back to needing a test for the line in question. * We're eschewing the possibility of changing the behavior of `fractions.Fraction` to force int numerator and denominator. Is that correct? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 16:35:24 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 31 Dec 2017 21:35:24 +0000 Subject: [issue32468] Frame repr should be more helpful In-Reply-To: <1514747695.25.0.467229070634.issue32468@psf.upfronthosting.co.za> Message-ID: <1514756124.3.0.467229070634.issue32468@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New changeset 14709144b521b9916f798a43aac9dc44fd44f6ca by Antoine Pitrou in branch 'master': bpo-32468: Better frame repr() (#5067) https://github.com/python/cpython/commit/14709144b521b9916f798a43aac9dc44fd44f6ca ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 16:35:56 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 31 Dec 2017 21:35:56 +0000 Subject: [issue32468] Frame repr should be more helpful In-Reply-To: <1514747695.25.0.467229070634.issue32468@psf.upfronthosting.co.za> Message-ID: <1514756156.77.0.467229070634.issue32468@psf.upfronthosting.co.za> Change by Antoine Pitrou : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 16:56:30 2017 From: report at bugs.python.org (Luka Malisa) Date: Sun, 31 Dec 2017 21:56:30 +0000 Subject: [issue32470] Unexpected behavior of struct.pack Message-ID: <1514757390.54.0.467229070634.issue32470@psf.upfronthosting.co.za> Change by Luka Malisa : ---------- components: Library (Lib) nosy: Luka Malisa priority: normal severity: normal status: open title: Unexpected behavior of struct.pack type: behavior versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 16:57:23 2017 From: report at bugs.python.org (Luka Malisa) Date: Sun, 31 Dec 2017 21:57:23 +0000 Subject: [issue32470] Unexpected behavior of struct.pack Message-ID: <1514757443.37.0.467229070634.issue32470@psf.upfronthosting.co.za> New submission from Luka Malisa : >>> import struct >>> struct.pack("IB", 1, 1) b'\x01\x00\x00\x00\x01' >>> struct.pack("BI", 1, 1) b'\x01\x00\x00\x00\x01\x00\x00\x00' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 17:07:28 2017 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 31 Dec 2017 22:07:28 +0000 Subject: [issue32470] Unexpected behavior of struct.pack In-Reply-To: <1514757443.37.0.467229070634.issue32470@psf.upfronthosting.co.za> Message-ID: <1514758048.41.0.467229070634.issue32470@psf.upfronthosting.co.za> Benjamin Peterson added the comment: That's because of alignment. See https://docs.python.org/3/library/struct.html#struct-alignment ---------- nosy: +benjamin.peterson resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 17:13:14 2017 From: report at bugs.python.org (Taras Matsyk) Date: Sun, 31 Dec 2017 22:13:14 +0000 Subject: [issue32469] Generator and coroutine repr could be more helpful In-Reply-To: <1514750009.12.0.467229070634.issue32469@psf.upfronthosting.co.za> Message-ID: <1514758394.93.0.467229070634.issue32469@psf.upfronthosting.co.za> Change by Taras Matsyk : ---------- keywords: +patch pull_requests: +4942 stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 17:14:58 2017 From: report at bugs.python.org (Taras Matsyk) Date: Sun, 31 Dec 2017 22:14:58 +0000 Subject: [issue32469] Generator and coroutine repr could be more helpful In-Reply-To: <1514750009.12.0.467229070634.issue32469@psf.upfronthosting.co.za> Message-ID: <1514758498.63.0.467229070634.issue32469@psf.upfronthosting.co.za> Taras Matsyk added the comment: I have added a pull request. Hope it makes sense and I've done everything correctly :) Happy New Year! ---------- nosy: +tarasmatsyk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 19:11:57 2017 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 01 Jan 2018 00:11:57 +0000 Subject: [issue32445] Skip creating redundant wrapper functions in ExitStack.callback In-Reply-To: <1514554664.91.0.213398074469.issue32445@psf.upfronthosting.co.za> Message-ID: <1514765517.77.0.467229070634.issue32445@psf.upfronthosting.co.za> Pablo Galindo Salgado added the comment: I think I am missing something because the callbacks are always called with (exc_type, exc, tb) (check here https://github.com/python/cpython/blob/176baa326be4ec2dc70ca0c054b7e2ab7ca6a9cf/Lib/contextlib.py#L475) and therefore a wrapper that just drops these arguments and calls the original callback with no arguments is always needed, right? ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 31 21:44:53 2017 From: report at bugs.python.org (=?utf-8?q?Niklas_Hamb=C3=BCchen?=) Date: Mon, 01 Jan 2018 02:44:53 +0000 Subject: [issue32453] shutil.rmtree can have O(n^2) performance on large dirs In-Reply-To: <1514610909.88.0.213398074469.issue32453@psf.upfronthosting.co.za> Message-ID: <1514774693.18.0.467229070634.issue32453@psf.upfronthosting.co.za> Niklas Hamb?chen added the comment: OK, my coreutils email is at http://lists.gnu.org/archive/html/bug-coreutils/2017-12/msg00054.html ---------- _______________________________________ Python tracker _______________________________________