From report at bugs.python.org Tue Nov 1 00:41:03 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 01 Nov 2016 04:41:03 +0000 Subject: [issue28573] Python 3.6.0b3 64-bit has no sys._mercurial info Message-ID: <1477975263.28.0.609263953959.issue28573@psf.upfronthosting.co.za> New submission from Steve Dower: The release build for 3.6.0b3 64-bit is missing Mercurial info: >>> import sys >>> sys._mercurial ('CPython', '', '') >>> sys.version '3.6.0b3 (default, Nov 1 2016, 03:21:01) [MSC v.1900 64 bit (AMD64)]' The debug build and the 32-bit builds are fine. It needs further investigation, but I assume the PGO build is to blame, as we only run PGO on the 64-bit release build. ---------- assignee: steve.dower components: Windows messages: 279848 nosy: ned.deily, paul.moore, steve.dower, tim.golden, zach.ware priority: release blocker severity: normal stage: test needed status: open title: Python 3.6.0b3 64-bit has no sys._mercurial info type: compile error versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 01:08:09 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 01 Nov 2016 05:08:09 +0000 Subject: [issue28574] Update bundled pip Message-ID: <1477976889.95.0.00775228376963.issue28574@psf.upfronthosting.co.za> New submission from Steve Dower: I know you've already taken the fix I'm most concerned about (the new distlib version, https://github.com/pypa/pip/pull/4038), but this is a reminder that we really need a new release of pip to bundle with Python 3.6.0 beta 4. I'm not hugely concerned as to whether it's an 8.2 or a 9.0 (but Ned might have a preference). ---------- assignee: dstufft messages: 279849 nosy: dstufft, ned.deily, paul.moore, steve.dower priority: release blocker severity: normal stage: needs patch status: open title: Update bundled pip type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 01:08:50 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 01 Nov 2016 05:08:50 +0000 Subject: [issue28574] Update bundled pip In-Reply-To: <1477976889.95.0.00775228376963.issue28574@psf.upfronthosting.co.za> Message-ID: <1477976930.86.0.311444758604.issue28574@psf.upfronthosting.co.za> Steve Dower added the comment: Also, it can go into whatever versions you'd normally insert into. I just tagged 3.6 and 3.7 because they're the ones currently broken. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 02:02:27 2016 From: report at bugs.python.org (Nixon) Date: Tue, 01 Nov 2016 06:02:27 +0000 Subject: [issue28575] Error 0x80070643 While installing in Win 10 32 Bit Message-ID: <1477980147.77.0.242850372978.issue28575@psf.upfronthosting.co.za> New submission from Nixon: While trying to install Python Error 0x80070643 is showing. ---------- components: Windows files: Python 3.6.0b3 (32-bit)_20161101112524.log messages: 279851 nosy: nixonvarghese, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Error 0x80070643 While installing in Win 10 32 Bit type: crash versions: Python 3.6 Added file: http://bugs.python.org/file45301/Python 3.6.0b3 (32-bit)_20161101112524.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 02:34:14 2016 From: report at bugs.python.org (jcrmatos) Date: Tue, 01 Nov 2016 06:34:14 +0000 Subject: [issue28576] Uninstalling Py352 x86 with /uninstall option does not remove prepended paths Message-ID: <1477982054.01.0.242793753337.issue28576@psf.upfronthosting.co.za> New submission from jcrmatos: Hello, When uninstalling Py352 x86 with the /uninstall option, it doesn't remove the prepended paths that were added on installation (unlike the GUI uninstall which removes them). My system is a Win7ProSP1 x64. Best regards, JM ---------- components: Installation, Windows messages: 279852 nosy: jcrmatos, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Uninstalling Py352 x86 with /uninstall option does not remove prepended paths type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 02:44:49 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 Nov 2016 06:44:49 +0000 Subject: [issue28568] Build files in PC/VS9.0 contain an outdated sqlite version number In-Reply-To: <1477932189.44.0.0903388711161.issue28568@psf.upfronthosting.co.za> Message-ID: <20161101064446.34863.59774.0BB5BC43@psf.io> Roundup Robot added the comment: New changeset 8f9c54a75c3d by Zachary Ware in branch '2.7': Closes #28568: Fix VS9.0 build files to use sqlite 3.8.11.0 https://hg.python.org/cpython/rev/8f9c54a75c3d ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 02:45:17 2016 From: report at bugs.python.org (Zachary Ware) Date: Tue, 01 Nov 2016 06:45:17 +0000 Subject: [issue28568] Build files in PC/VS9.0 contain an outdated sqlite version number In-Reply-To: <1477932189.44.0.0903388711161.issue28568@psf.upfronthosting.co.za> Message-ID: <1477982717.94.0.229952525826.issue28568@psf.upfronthosting.co.za> Zachary Ware added the comment: Thanks for the report and patch! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 03:02:04 2016 From: report at bugs.python.org (era) Date: Tue, 01 Nov 2016 07:02:04 +0000 Subject: [issue28577] ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32 Message-ID: <1477983724.8.0.857875109595.issue28577@psf.upfronthosting.co.za> New submission from era: I would expect the following code to return ['10.9.8.8'] but it returns an empty list. yosemite-osx$ python3 Python 3.5.1 (default, Dec 26 2015, 18:08:53) [GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import ipaddress >>> list(ipaddress.ip_network('10.9.8.7/32').hosts()) [] This seems to happen for every /32 address. I'm guessing the logic which wants to exclude the gateway and broadcast addresses from a block should treat a /32 as a special case. I tried to look for a previous bug submission but I could not find one. As such, it seems peculiar if this has not been reported before. Is this actually expected behavior by some rule I am overlooking? I tested on Linux 3.4 and OSX Yosemite Homebrew / Python 3.5.1. ---------- components: Library (Lib) messages: 279855 nosy: era priority: normal severity: normal status: open title: ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32 versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 03:04:44 2016 From: report at bugs.python.org (era) Date: Tue, 01 Nov 2016 07:04:44 +0000 Subject: [issue28577] ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32 In-Reply-To: <1477983724.8.0.857875109595.issue28577@psf.upfronthosting.co.za> Message-ID: <1477983884.79.0.382343411496.issue28577@psf.upfronthosting.co.za> era added the comment: (Meh, silly typo, of course the expected output is ['10.9.8.7'], sorry about that!) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 03:10:10 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 01 Nov 2016 07:10:10 +0000 Subject: [issue28513] Document zipfile CLI In-Reply-To: <1477218977.25.0.95260452294.issue28513@psf.upfronthosting.co.za> Message-ID: <1477984210.37.0.735670720254.issue28513@psf.upfronthosting.co.za> SilentGhost added the comment: > Apparently (haven?t tried myself) if you put ?.. program:: zipfile? before the :option: invocations, it changes the default context and you don?t need the bit. Yes, moving program directive just after "Command Line Interface" heading works fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 03:16:34 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 01 Nov 2016 07:16:34 +0000 Subject: [issue28577] ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32 In-Reply-To: <1477983724.8.0.857875109595.issue28577@psf.upfronthosting.co.za> Message-ID: <1477984594.47.0.179146339645.issue28577@psf.upfronthosting.co.za> Xiang Zhang added the comment: hosts() won't return the network address itself and the network broadcast address. So for 10.9.8.7/32, it should return []. ---------- nosy: +xiang.zhang resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 04:16:05 2016 From: report at bugs.python.org (era) Date: Tue, 01 Nov 2016 08:16:05 +0000 Subject: [issue28577] ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32 In-Reply-To: <1477983724.8.0.857875109595.issue28577@psf.upfronthosting.co.za> Message-ID: <1477988165.75.0.901208147711.issue28577@psf.upfronthosting.co.za> era added the comment: @xiang.zhang thanks for the quick reply. I find this behavior surprising. If I process a list of addresses, like ips = ( '10.9.8.7/32' '10.11.12.8/28' ) for test in ['10.9.8.7', '10.11.12.10']: if test in [str(y) for x in ips for y in ipaddress.ip_network(x).hosts()]: print('{0} found'.format(test)) else: print('{0} not found'.format(test)) I would expect both addresses to print "found", but that's not how the current implementation works. I agree that the /28 should not include the gateway and broadcast addresses, but I would not expect the explicitly listed /32 address to completely disappear from the output. Are my expectations incorrect? For code like this, what should I use instead, if not hosts()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 04:48:28 2016 From: report at bugs.python.org (Amit Ghadge) Date: Tue, 01 Nov 2016 08:48:28 +0000 Subject: [issue28578] '\n' escape character print before the Py_GetCompiler version Message-ID: <1477990108.91.0.0604518675634.issue28578@psf.upfronthosting.co.za> Changes by Amit Ghadge : ---------- nosy: amitgb14 priority: normal severity: normal status: open title: '\n' escape character print before the Py_GetCompiler version type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 05:03:15 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 01 Nov 2016 09:03:15 +0000 Subject: [issue28577] ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32 In-Reply-To: <1477983724.8.0.857875109595.issue28577@psf.upfronthosting.co.za> Message-ID: <1477990995.38.0.544602807408.issue28577@psf.upfronthosting.co.za> Xiang Zhang added the comment: I am not sure. Actually there is a special case for mask 31, you can see #27863. Its result includes both the network and broadcast address. Add Nick to see his opinion. FYI, ipaddress ?ipaddr in Py2) always return empty for 32. But there is other library returning network address for 32, for example netaddr. ---------- nosy: +ncoghlan status: closed -> open type: -> behavior versions: +Python 3.7 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 05:07:50 2016 From: report at bugs.python.org (Amit Ghadge) Date: Tue, 01 Nov 2016 09:07:50 +0000 Subject: [issue28578] '\n' escape character print before the Py_GetCompiler version Message-ID: <1477991270.69.0.795829340529.issue28578@psf.upfronthosting.co.za> New submission from Amit Ghadge: When I hit sys.version command on Linux shell the Py_GetCompiler version print '\n' character like; '3.7.0a0 (default:7aa001a48120, Nov 1 2016, 13:53:25) \n[GCC 5.3.1 20160406 (Red Hat 5.3.1-6)]' And When I launch python, Py_GetCompiler line print to the next line, [aghadge at localhost build]$ ./python Python 3.7.0a0 (default:7aa001a48120+, Nov 1 2016, 14:05:04) [GCC 5.3.1 20160406 (Red Hat 5.3.1-6)] on linux ---------- nosy: +eric.snow, steve.dower versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 05:31:42 2016 From: report at bugs.python.org (era) Date: Tue, 01 Nov 2016 09:31:42 +0000 Subject: [issue28577] ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32 In-Reply-To: <1477983724.8.0.857875109595.issue28577@psf.upfronthosting.co.za> Message-ID: <1477992702.65.0.966469620649.issue28577@psf.upfronthosting.co.za> era added the comment: Quick googling did not turn up anything like a credible authoritative reference for this, but in actual practice, I have seen /32 used to designate a single individual IP address in CIDR notation quite a lot. I can see roughly three options: 1. Status quo. Silently surprise users who expect this to work. 2. Silently fix. Hard-code /32 to return a range of one IP address. 3. Let users choose. Similarly to the "strict=True" keyword argument in the constructor method, the code could allow for either lenient or strict semantics. By the by, I don't see how the bug you linked to is relevant here, did you mistype the bug number? #27863 is about _elementtree ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 05:37:50 2016 From: report at bugs.python.org (Sam Ferencik) Date: Tue, 01 Nov 2016 09:37:50 +0000 Subject: [issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine In-Reply-To: <1378731781.77.0.0136191125302.issue18987@psf.upfronthosting.co.za> Message-ID: <1477993070.33.0.780992875751.issue18987@psf.upfronthosting.co.za> Sam Ferencik added the comment: Michael, Thanks for reopening this. You say you're using "64-bit hardware", but what bitness is your OS and the Python interpreter? If you read my original issue description, I only had this issue with 32-bit Python on a 64-bit Linux system (on 64-bit hardware). You say you have 64-bit hardware but are both your AIX and Linux 64-bit? And what about your Python? (Can you try invoking python2.7-32 and python2.7-64 explicitly?) Please add this detail. Thanks, Sam ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 05:40:40 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 01 Nov 2016 09:40:40 +0000 Subject: [issue28578] '\n' escape character print before the Py_GetCompiler version In-Reply-To: <1477991270.69.0.795829340529.issue28578@psf.upfronthosting.co.za> Message-ID: <1477993240.92.0.784685147191.issue28578@psf.upfronthosting.co.za> SilentGhost added the comment: And how exactly are you "hitting sys.version command"? ---------- nosy: +SilentGhost versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 05:41:28 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 01 Nov 2016 09:41:28 +0000 Subject: [issue28577] ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32 In-Reply-To: <1477983724.8.0.857875109595.issue28577@psf.upfronthosting.co.za> Message-ID: <1477993288.02.0.961859381356.issue28577@psf.upfronthosting.co.za> Xiang Zhang added the comment: Sorry, it's #27683. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 05:55:55 2016 From: report at bugs.python.org (era) Date: Tue, 01 Nov 2016 09:55:55 +0000 Subject: [issue27683] ipaddress subnet slicing iterator malfunction In-Reply-To: <1470316057.21.0.151567664395.issue27683@psf.upfronthosting.co.za> Message-ID: <1477994155.32.0.168532293582.issue27683@psf.upfronthosting.co.za> era added the comment: #28577 requests a similar special case for /32 ---------- nosy: +era _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 06:03:58 2016 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 01 Nov 2016 10:03:58 +0000 Subject: [issue28577] ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32 In-Reply-To: <1477983724.8.0.857875109595.issue28577@psf.upfronthosting.co.za> Message-ID: <1477994638.52.0.837970759303.issue28577@psf.upfronthosting.co.za> Nick Coghlan added the comment: I think this is an area where ipaddress just inherited ipaddr's behaviour without challenging it. As Peter isn't currently particularly active, and I stepped back from ipaddress maintenance some time ago (since I don't work heavily enough with raw IP addresses to have the right design instincts to arbitrate edge cases like this), I'd suggest raising both this and #27683 on python-dev, pointing out that we used to have the "/31" special case (treating it the same as "/30") and inadvertently lost it in some other refactoring, but have never special cased "/32". ---------- nosy: +pmoody _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 06:14:43 2016 From: report at bugs.python.org (Amit Ghadge) Date: Tue, 01 Nov 2016 10:14:43 +0000 Subject: [issue28578] '\n' escape character print before the Py_GetCompiler version In-Reply-To: <1477991270.69.0.795829340529.issue28578@psf.upfronthosting.co.za> Message-ID: <1477995283.06.0.109729556279.issue28578@psf.upfronthosting.co.za> Amit Ghadge added the comment: Actually, I run this in Python terminal, >>> import sys >>> import sys.version I also have attached patch, Please let me that is correct or not? ---------- keywords: +patch Added file: http://bugs.python.org/file45302/getcompiler.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 06:32:05 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 01 Nov 2016 10:32:05 +0000 Subject: [issue28578] '\n' escape character print before the Py_GetCompiler version In-Reply-To: <1477991270.69.0.795829340529.issue28578@psf.upfronthosting.co.za> Message-ID: <1477996325.95.0.161086265583.issue28578@psf.upfronthosting.co.za> SilentGhost added the comment: sys.version is a string, it's intended to be printed and it needs \n to be able to output two lines. I'm not sure what exactly problem you're having, but if you want special characters like \n not to show in output, you should use >>> print(sys.version) I'm going to close this issue. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 06:42:51 2016 From: report at bugs.python.org (Donald Stufft) Date: Tue, 01 Nov 2016 10:42:51 +0000 Subject: [issue28574] Update bundled pip In-Reply-To: <1477976930.86.0.311444758604.issue28574@psf.upfronthosting.co.za> Message-ID: Donald Stufft added the comment: Yea. I worked on trying to get this done over the weekend and I was l left with one issue left. Hoping to get that done in the next day or two. Sent from my iPhone > On Nov 1, 2016, at 1:08 AM, Steve Dower wrote: > > > Steve Dower added the comment: > > Also, it can go into whatever versions you'd normally insert into. I just tagged 3.6 and 3.7 because they're the ones currently broken. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 06:55:12 2016 From: report at bugs.python.org (armando mendoza) Date: Tue, 01 Nov 2016 10:55:12 +0000 Subject: [issue28513] Document zipfile CLI In-Reply-To: <1477218977.25.0.95260452294.issue28513@psf.upfronthosting.co.za> Message-ID: <1477997712.67.0.269759488472.issue28513@psf.upfronthosting.co.za> Changes by armando mendoza : ---------- components: +XML _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 07:22:39 2016 From: report at bugs.python.org (Big Stone) Date: Tue, 01 Nov 2016 11:22:39 +0000 Subject: [issue28522] can't make IDLEX work with python._pth and python-3.6.0b2 In-Reply-To: <1477341913.28.0.0500470674993.issue28522@psf.upfronthosting.co.za> Message-ID: <1477999359.21.0.524427243318.issue28522@psf.upfronthosting.co.za> Big Stone added the comment: the suggested python._pth change makes python unhappy: python36.zip DLLs Lib . import site R?cipient d?erreurs 116251549737, type 5 Nom d??v?nement?: BEX64 R?ponse?: Non disponible ID de CAB : 0 Signature du probl?me : P1 : python.exe P2 : 3.6.112.1013 P3 : 57fc0593 P4 : ucrtbase.dll P5 : 10.0.14393.0 P6 : 578997b5 P7 : 000000000006d5b8 P8 : c0000409 P9 : 0000000000000005 P10 : Fichiers joints?: \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERF455.tmp.WERInternalMetadata.xml \\?\C:\Users\famille\AppData\Local\Temp\WERFF72.tmp.appcompat.txt Ces fichiers sont peut-?tre disponibles ici?: C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_python.exe_ec9ba1cd21c08ca3de75f183bf945ce737867af_b3b3e14f_1575008a Symbole d?analyse : Nouvelle recherche de la solution : 0 ID de rapport : 66625eb0-e311-4368-be37-4b600bcb8978 Statut du rapport : 1 R?cipient avec hachage?: 57d09a5cb4a63ab86af1e62bd270b573 ---------- Added file: http://bugs.python.org/file45303/Report.wer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 07:24:37 2016 From: report at bugs.python.org (Big Stone) Date: Tue, 01 Nov 2016 11:24:37 +0000 Subject: [issue28522] can't make IDLEX work with python._pth and python-3.6.0b2 In-Reply-To: <1477341913.28.0.0500470674993.issue28522@psf.upfronthosting.co.za> Message-ID: <1477999477.28.0.0111931436989.issue28522@psf.upfronthosting.co.za> Big Stone added the comment: oups! I may have test the old one... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 07:26:58 2016 From: report at bugs.python.org (Big Stone) Date: Tue, 01 Nov 2016 11:26:58 +0000 Subject: [issue28522] can't make IDLEX work with python._pth and python-3.6.0b2 In-Reply-To: <1477341913.28.0.0500470674993.issue28522@psf.upfronthosting.co.za> Message-ID: <1477999618.62.0.715453292566.issue28522@psf.upfronthosting.co.za> Big Stone added the comment: it looks ok with 3.6.0b3 ... sorry for the false alarm ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 07:28:39 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 01 Nov 2016 11:28:39 +0000 Subject: [issue28513] Document zipfile CLI In-Reply-To: <1477218977.25.0.95260452294.issue28513@psf.upfronthosting.co.za> Message-ID: <1477999719.8.0.304775560813.issue28513@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: -XML _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 08:16:23 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 01 Nov 2016 12:16:23 +0000 Subject: [issue28573] Python 3.6.0b3 64-bit has no sys._mercurial info In-Reply-To: <1477975263.28.0.609263953959.issue28573@psf.upfronthosting.co.za> Message-ID: <1478002583.4.0.962151168911.issue28573@psf.upfronthosting.co.za> SilentGhost added the comment: The same is on 3.5.2 on ubuntu 16.10 ---------- nosy: +SilentGhost, larry versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 09:07:54 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 01 Nov 2016 13:07:54 +0000 Subject: [issue28573] Python 3.6.0b3 64-bit has no sys._mercurial info In-Reply-To: <1477975263.28.0.609263953959.issue28573@psf.upfronthosting.co.za> Message-ID: <1478005674.41.0.993417650074.issue28573@psf.upfronthosting.co.za> Steve Dower added the comment: We're not responsible for the builds released by Linux distros. There's a good chance they didn't build from mercurial, but used the source release plus patches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 09:12:23 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 01 Nov 2016 13:12:23 +0000 Subject: [issue28575] Error 0x80070643 While installing in Win 10 32 Bit In-Reply-To: <1477980147.77.0.242850372978.issue28575@psf.upfronthosting.co.za> Message-ID: <1478005943.0.0.81962094025.issue28575@psf.upfronthosting.co.za> Steve Dower added the comment: If you look in your TEMP directory there should be a few more log files alongside the one you attached. Could you post those too? You can put them in a zip file to make it easier if you like. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 09:12:29 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 01 Nov 2016 13:12:29 +0000 Subject: [issue28575] Error 0x80070643 While installing in Win 10 32 Bit In-Reply-To: <1477980147.77.0.242850372978.issue28575@psf.upfronthosting.co.za> Message-ID: <1478005949.34.0.130205633707.issue28575@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 09:14:08 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 01 Nov 2016 13:14:08 +0000 Subject: [issue28576] Uninstalling Py352 x86 with /uninstall option does not remove prepended paths In-Reply-To: <1477982054.01.0.242793753337.issue28576@psf.upfronthosting.co.za> Message-ID: <1478006048.34.0.831228906009.issue28576@psf.upfronthosting.co.za> Steve Dower added the comment: Does it go away after restarting? It's not easy to remove a setting like that from programs that are already running. Also, can you post your log files? They'll be in %TEMP% and you can zip them up first to make it easier. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 09:14:13 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 01 Nov 2016 13:14:13 +0000 Subject: [issue28576] Uninstalling Py352 x86 with /uninstall option does not remove prepended paths In-Reply-To: <1477982054.01.0.242793753337.issue28576@psf.upfronthosting.co.za> Message-ID: <1478006053.87.0.305458212754.issue28576@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 11:00:37 2016 From: report at bugs.python.org (Liam Marsh) Date: Tue, 01 Nov 2016 15:00:37 +0000 Subject: [issue28579] nan != nan Message-ID: <1478012437.7.0.981813738405.issue28579@psf.upfronthosting.co.za> New submission from Liam Marsh: I found a really weird comportment with NANs: >>> from math import nan, isnan, inf >>> nan==nan False >>> nan!=nan True >>> a=nan # maybe get another instance would fix it (or so I thought) >>> a==nan False >>> a==a False >>> a is a True >>> # because `is` works, it could be a >>> # deliberate comportment. is it? >>> a is nan True >>> isnan(a) and isnan(nan) True >>> nan == -nan False >>> nan is -nan False >>> a < 1 False >>> a > 0 False >>> a < inf False >>> b=external_pyd_call_that_returns_nan() >>> isnan(b) True >>> b == nan False that sums what I tried up. thanks for reading this. ---------- messages: 279878 nosy: niacdoial priority: normal severity: normal status: open title: nan != nan type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 11:05:53 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 01 Nov 2016 15:05:53 +0000 Subject: [issue28579] nan != nan In-Reply-To: <1478012437.7.0.981813738405.issue28579@psf.upfronthosting.co.za> Message-ID: <1478012753.45.0.258801918573.issue28579@psf.upfronthosting.co.za> SilentGhost added the comment: That's how IEEE 754's NaN is defined. Seem to be behaving according to the standard. ---------- nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 11:17:14 2016 From: report at bugs.python.org (Tim Peters) Date: Tue, 01 Nov 2016 15:17:14 +0000 Subject: [issue28579] nan != nan In-Reply-To: <1478012437.7.0.981813738405.issue28579@psf.upfronthosting.co.za> Message-ID: <1478013434.82.0.911337746882.issue28579@psf.upfronthosting.co.za> Tim Peters added the comment: Yes, it's both intended and annoying ;-) The standard specifies that, by default, comparisons involving NANs are "unordered": a NAN is _none_ of "less than", "equal to", or "greater than" any other float, including any other NaN, and including itself. ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 11:30:30 2016 From: report at bugs.python.org (jcrmatos) Date: Tue, 01 Nov 2016 15:30:30 +0000 Subject: [issue28576] Uninstalling Py352 x86 with /uninstall option does not remove prepended paths In-Reply-To: <1477982054.01.0.242793753337.issue28576@psf.upfronthosting.co.za> Message-ID: <1478014230.39.0.722772574854.issue28576@psf.upfronthosting.co.za> jcrmatos added the comment: Hello, The GUI uninstall removes the prepended paths w/o requiring a reboot, so I see no reason why the /uninstall method shouldn't do it too. I did try to reboot afterwards, but the paths remain. I also tested on another PC, with Windows 8.1 x64, with the same results. What is strange is that the /uninstall method removes the .PY and .PYW from the PATHEXT env var, but keeps the prepended paths. I attached the logs as requested. All tries were made using using python-3.5.2.exe InstallAllUsers=1 CompileAll=1 InstallLauncherAllUsers=0 PrependPath=1 /passive for installation and python-3.5.2.exe /uninstall for uninstallation. Best regards, JM ---------- Added file: http://bugs.python.org/file45304/Temp.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 12:09:36 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 01 Nov 2016 16:09:36 +0000 Subject: [issue28199] Compact dict resizing is doing too much work In-Reply-To: <1474236829.43.0.744002065698.issue28199@psf.upfronthosting.co.za> Message-ID: <1478016576.12.0.942115372029.issue28199@psf.upfronthosting.co.za> Xiang Zhang added the comment: I use gdb to run setuptools test suite and find the assumption, split tables are always dense is broken for both dictresize3 and dictresize4. #0 0x00007ffff71171c7 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 #1 0x00007ffff7118e2a in __GI_abort () at abort.c:89 #2 0x00007ffff71100bd in __assert_fail_base (fmt=0x7ffff7271f78 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion at entry=0x5e4b90 "oldvalues[i] != ((void *)0)", file=file at entry=0x5e4aa0 "Objects/dictobject.c", line=line at entry=1270, function=function at entry=0x5e59f0 <__PRETTY_FUNCTION__.12083> "dictresize") at assert.c:92 #3 0x00007ffff7110172 in __GI___assert_fail (assertion=assertion at entry=0x5e4b90 "oldvalues[i] != ((void *)0)", file=file at entry=0x5e4aa0 "Objects/dictobject.c", line=line at entry=1270, function=function at entry=0x5e59f0 <__PRETTY_FUNCTION__.12083> "dictresize") at assert.c:101 #4 0x000000000048bddc in dictresize (mp=mp at entry=0x7ffff219d2b0, minused=) at Objects/dictobject.c:1270 #5 0x000000000048bf93 in insertion_resize (mp=mp at entry=0x7ffff219d2b0) at Objects/dictobject.c:1100 #6 0x000000000048c5fd in insertdict (mp=mp at entry=0x7ffff219d2b0, key=key at entry=0x7ffff579c3c0, hash=-3681610201421769281, value=value at entry=0x7ffff07f56e8) at Objects/dictobject.c:1136 #7 0x000000000048fdfd in PyDict_SetItem (op=op at entry=0x7ffff219d2b0, key=key at entry=0x7ffff579c3c0, value=value at entry=0x7ffff07f56e8) at Objects/dictobject.c:1572 #8 0x0000000000492cb5 in _PyObjectDict_SetItem (tp=tp at entry=0xd52548, dictptr=0x7ffff080cbd8, key=key at entry=0x7ffff579c3c0, value=value at entry=0x7ffff07f56e8) at Objects/dictobject.c:4274 #9 0x000000000049df8a in _PyObject_GenericSetAttrWithDict (obj=0x7ffff080cbb8, name=0x7ffff579c3c0, value=0x7ffff07f56e8, dict=dict at entry=0x0) at Objects/object.c:1172 #10 0x000000000049e0cf in PyObject_GenericSetAttr (obj=, name=, value=) at Objects/object.c:1194 #11 0x000000000049d80e in PyObject_SetAttr (v=v at entry=0x7ffff080cbb8, name=name at entry=0x7ffff579c3c0, value=value at entry=0x7ffff07f56e8) at Objects/object.c:932 Thanks to Victor's _PyDict_CheckConsistency, it's easy then to find even without dictresize3 and dictresize4 (the current version), the test suite still fails (#define DEBUG_PYDICT). #0 0x00007ffff71171c7 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 #1 0x00007ffff7118e2a in __GI_abort () at abort.c:89 #2 0x00007ffff71100bd in __assert_fail_base (fmt=0x7ffff7271f78 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion at entry=0x5e53a0 "mp->ma_values[i] != ((void *)0)", file=file at entry=0x5e4d00 "Objects/dictobject.c", line=line at entry=498, function=function at entry=0x5e5dd0 <__PRETTY_FUNCTION__.11869> "_PyDict_CheckConsistency") at assert.c:92 #3 0x00007ffff7110172 in __GI___assert_fail (assertion=assertion at entry=0x5e53a0 "mp->ma_values[i] != ((void *)0)", file=file at entry=0x5e4d00 "Objects/dictobject.c", line=line at entry=498, function=function at entry=0x5e5dd0 <__PRETTY_FUNCTION__.11869> "_PyDict_CheckConsistency") at assert.c:101 #4 0x000000000048ba17 in _PyDict_CheckConsistency (mp=mp at entry=0x7ffff0806e68) at Objects/dictobject.c:498 #5 0x00000000004927a3 in PyDict_SetDefault (d=d at entry=0x7ffff0806e68, key=0x7ffff2ffcdd8, defaultobj=0x8abf20 <_Py_NoneStruct>) at Objects/dictobject.c:2807 #6 0x0000000000492854 in dict_setdefault (mp=0x7ffff0806e68, args=) at Objects/dictobject.c:2824 #7 0x0000000000499469 in _PyCFunction_FastCallDict (func_obj=func_obj at entry=0x7ffff0f2f8c8, args=args at entry=0x105afe8, nargs=nargs at entry=2, kwargs=kwargs at entry=0x0) at Objects/methodobject.c:234 #8 0x0000000000499815 in _PyCFunction_FastCallKeywords (func=func at entry=0x7ffff0f2f8c8, stack=stack at entry=0x105afe8, nargs=nargs at entry=2, kwnames=kwnames at entry=0x0) at Objects/methodobject.c:295 #9 0x0000000000537b6f in call_function (pp_stack=pp_stack at entry=0x7fffffff5cd0, oparg=oparg at entry=2, kwnames=kwnames at entry=0x0) at Python/ceval.c:4793 >From the backtrace we can see PyDict_SetDefault breaks the invariant. And reading the code, yes, it doesn't handle split table separately. I simply replace the logic in PyDict_SetDefault with insertdict to make a test. It doesn't fail, even with dictresize4. An easy example to reproduce: >>> class C: ... pass ... >>> c1, c2 = C(), C() >>> c1.a, c1.b = 1, 2 >>> c2.__dict__.setdefault('b', None) python: Objects/dictobject.c:498: _PyDict_CheckConsistency: Assertion `mp->ma_values[i] != ((void *)0)' failed. Aborted (core dumped) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 13:20:14 2016 From: report at bugs.python.org (Florian Strzelecki) Date: Tue, 01 Nov 2016 17:20:14 +0000 Subject: [issue28499] Logging module documentation needs a rework. In-Reply-To: <1477070357.17.0.711656351025.issue28499@psf.upfronthosting.co.za> Message-ID: <1478020814.27.0.927119044792.issue28499@psf.upfronthosting.co.za> Florian Strzelecki added the comment: Hi! Sorry for the delay. I published my slides on speaker deck: https://speakerdeck.com/exirel/read-and-write-the-doc It contains only my main ideas and key concepts, since I prefer to talk more than just read slides to the public. I hope Pycon FR's organizers will be able to upload videos soon - it'll need translation for non-French speaker, too. Thanks for creating this issue and for all your comments. I'll try to talk more here, but I'm not sure how we should proceed - so let's start a conversation? In my talk, I rant a bit about two documentations: Django's documentation, and Python Logging's documentation. Both have, in my opinion, an issue with their organization: the Django one tend to scatter information around multiple chapters, and the Logging one, albeit properly compacted, fail to quickly answer beginner's questions and advanced user's needs. Don't get me wrong: there is a lot of content here. Most of the question one may ask have an answer, lying here or there. After all, I was able to use the Configure File Format, once I had read the reference documentation for `logging`, `logging.config`, both tutorials, and the cookbook. My point is: I value a lot this documentation, but my experience as a beginner wasn't that good, and my current experience as an advanced user could be improved. I remember the first time I read the documentation. I was reading an application's source code that used a `logging.config.dictConfig`, and I couldn't understand how it worked. How does each level in loggers and handlers work? How to change the format of each log? Does it work in multiple threads? In multiple process? Why is there a `logging.getLogger('something')`? How does it know my configuration? How can I output logs in my console and still write them? Can I call `getLogger` before I configure anything? Take the main page (https://docs.python.org/3.7/library/logging.html): * Hard to find a "How to configure logging" link, * No description of the logging flow (it can be found in the advanced tutorial), * No example of quick usage (the first one is for `Logger.debug`, and that's not a generic one), * The top-level function are documented at the end of the document, albeit they are the quickest way to use and understand `logging` * The "See also" part (which provide easy access to more content) is far far away at the bottom of the document. And I think there are many other small issues regarding content organization. I think there are (at least) 2 ways to look at these: * Rework the overall structure, * Focus on example. I didn't think a lot about a better structure, so something like that is just a quick draft: * Introduction to logging (with short example) * Logging usage (how logging works - the Advanced Tutorial talk a lot about that) * Configuration (a separated chapter to describe file format, dict schema, and stuff) * Module references (logging, logging.config, logging.handler, etc.) * Cookbook & Tutorials (Each part in a separated chapter/sub-chapter) I also think that the documentation should be able to answer these questions: * As a beginner, how do I start? How should I learn logging? * As experienced, how do I jump directly to what I want to know? (config, format, etc.) * As advanced, how do I extend logging in my application? I don't think a beginner needs to know what a LogRecord is, but they'll need to know what keys to use in their formatter in their basicConfig/dictConfig. And an advanced dev shouldn't spend minutes to fetch the documentation to finally found how to use their own LogRecord object in their logger. --- Welp. That's a lot of text for now. I'm still not sure how to help nor how to begin with that. I never tried to make a push request to Python, and I don't know if I should try to submit a diff or not. Also, there is so much more than just that (I didn't talk about the "focus on example" part). Last but not least, thanks for your attention! ---------- nosy: +Florian Strzelecki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 13:25:08 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 01 Nov 2016 17:25:08 +0000 Subject: [issue28580] Optimise _PyDict_Next for split table Message-ID: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> New submission from Xiang Zhang: Since values of split table is always dense, we can optimise the current implementation of _PyDict_Next. I think this could hardly bring much performance enhancement. More importantly, this emphasizes the invariant and make bugs easy to find and test. ---------- files: _PyDict_Next.patch keywords: patch messages: 279884 nosy: inada.naoki, serhiy.storchaka, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Optimise _PyDict_Next for split table type: behavior Added file: http://bugs.python.org/file45305/_PyDict_Next.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 13:26:19 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 01 Nov 2016 17:26:19 +0000 Subject: [issue28580] Optimize _PyDict_Next for split table In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478021179.92.0.0997927477331.issue28580@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- components: +Interpreter Core title: Optimise _PyDict_Next for split table -> Optimize _PyDict_Next for split table versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 13:51:29 2016 From: report at bugs.python.org (perilbrain) Date: Tue, 01 Nov 2016 17:51:29 +0000 Subject: [issue28581] Allow running code without explicitly saving the file. Message-ID: <1478022689.78.0.930783075071.issue28581@psf.upfronthosting.co.za> New submission from perilbrain: Current Flow:- - If you create a new file in idle and try to run it, the editor asks to save the file. However if user presses cancel button the code is not executed. Problem:- I have been using idle for over 5 years and this behavior is quite annoying(along with paste :) !!). We are often required to copy code from various sites say some tutorial or code samples which are good for one time usage. Solution:- If a user presses cancel button then set a flag in IOBinding say "optedTemp", save it to a named temporary file, execute the code and close the file. If user again runs the code, check for this flag. If it is true then there is no need to ask for saving the code and again create the temporary file, execute, close. If some one needs to save this code they can use the "save as" menu which sets off the optedTemp flag. Here is the code I propose (check for "#+++++++++++++++++++++") ==================idlelib/ScriptBinding.py=============== # At top import tempfile #+++++++++++++++++++++ # New definition of functions:- def _run_module_event(self, event): filename = self.getfilename() tempCode = None #+++++++++++++++++++++ if not filename: tempCode = tempfile.NamedTemporaryFile(suffix = ".py") #+++++++++++++++++++++ filename = tempCode.name #****Added*** self.editwin.io.writefile( filename ) #+++++++++++++++++++++ self.editwin.io.optedTemp = True #+++++++++++++++++++++ #return 'break' code = self.checksyntax(filename) ...... interp.runcode(code) if tempCode is not None: #+++++++++++++++++++++ tempCode.close() #+++++++++++++++++++++ return 'break' def getfilename(self): filename = self.editwin.io.filename if not self.editwin.get_saved(): autosave = idleConf.GetOption('main', 'General', 'autosave', type='bool') if autosave and filename: self.editwin.io.save(None) elif self.editwin.io.optedTemp: #+++++++++++++++++++++ filename = None #+++++++++++++++++++++ else: confirm = self.ask_save_dialog() self.editwin.text.focus_set() if confirm: self.editwin.io.save(None) filename = self.editwin.io.filename else: filename = None return filename ============idlelib/IOBinding.py====================== def __init__(self, editwin): #.... self.__id_print = self.text.bind("<>", self.print_window) self.optedTemp = False #+++++++++++++++++++++ def save_as(self, event): filename = self.asksavefile() if filename: if self.writefile(filename): self.set_filename(filename) self.set_saved(1) self.optedTemp = False #+++++++++++++++++++++ try: self.editwin.store_file_breaks() except AttributeError: .... ---------- assignee: terry.reedy components: IDLE messages: 279885 nosy: perilbrain, terry.reedy priority: normal severity: normal status: open title: Allow running code without explicitly saving the file. type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 14:16:53 2016 From: report at bugs.python.org (Eric Appelt) Date: Tue, 01 Nov 2016 18:16:53 +0000 Subject: [issue26163] FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet) In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za> Message-ID: <1478024213.35.0.845101182351.issue26163@psf.upfronthosting.co.za> Eric Appelt added the comment: Here are my test results - I'll re-describe the issue and test so people don't have to read through all the previous text and for completeness. ------------------------------------- The basic test case ("letter test"): Consider the set of the first seven letters - {'a', 'b', 'c', 'd', 'e', 'f', 'g'}. If one constructs frozensets of all 128 possible subsets of this set, and computes their hashes, in principle they should have good collision statistics. To check, the hashes of all 128 frozensets are computed and the last 7 bits of each hash are compared. The quality of the hashing algorithm is indicated by how many unique values of the last 7 bits are present in the set of 128 hashes. Too few unique values and the collision statistics are poor. In the python testing suite, this particular test is run and if the number of unique values is 32 or less the test fails. Since the hash of a string depends on the value of the PYTHONHASHSEED which is random by default, and the hashes of frozensets are dependent on their entries, this test is not deterministic. My earlier tests show that this will fail for one out of every few thousand seeds. -------------------------- The implementation issue and proposed fix: The hash of a frozen set is computed by taking the hash of each element, shuffling the bits in a deterministic way, and then XORing it into a hash for the frozenset (starting with zero). The size of the frozenset is then also shuffled and XORed into that result. Finally, in order to try to remove patterns incurred by XORing similar combinations of elements as with nested sets, the resulting hash is sent through a simple LCG to arrive at a final value: hash = hash * 69069U + 907133923UL; The hypothesis is that this LCG is not effective in improving collision rates for this particular test case. As an alternative, the proposal is to take the result of the XORs, and run that through the hashing algorithm set in the compiled python executable for hashing bytes (i.e. FNV or SipHash24). This rehashing may do a better job of removing patterns set up by combinations of common elements. ------------------------------------- The experiment: To more robustly check the properties of the frozenset hashing algorithm, the letter test is run many times setting different PYTHONHASHSEED values from 0 to 10000. This produces a distribution of unique sequences (u) of the last 7 hash bits in the set of 128 frozensets. To compare against the optimal case, the same distribution (u) is produced from a set of pseudorandom integers generated with "random.randint(0, 2**64)". Which is found to have be a normal distribution with a mean of ~81 and standard deviation of ~3.5. Six different test cases are considered and the results are shown in the attached figure (figure1.png) - Compile using the FNV algorithm. For control, do not shuffle the XORed result to compute the frozenset hash. (Fig 1-a) - Compile using the FNV algorithm. For the current implementation, shuffle the XORed result using the LCG to compute the frozenset hash. (Fig 1-b) - Compile using the FNV algorithm. For the current implementation, shuffle the XORed result using the FNV algorithm to compute the frozenset hash. (Fig 1-c) - Compile using the SipHash24 algorithm. For control, do not shuffle the XORed result to compute the frozenset hash. (Fig 1-d) - Compile using the SipHash24 algorithm. For the current implementation, shuffle the XORed result using the LCG to compute the frozenset hash. (Fig 1-e) - Compile using the SipHash24 algorithm. For the current implementation, shuffle the XORed result using the SipHash24 algorithm to compute the frozenset hash. (Fig 1-f) -------------------------------- Results: Using the LCG to shuffle the XORed result of the entry and size hashes to finish computing the frozenset hash did not improve the results of the letter test, and appeared to have no effect on the distribution at all. Rehashing with the configured algorithm to shuffle the XORed result of the entry and size hashes to finish computing the frozenset hash did not improve the results of the letter test, and appeared to have no effect on the distribution at all. The FNV results were odd in that specific outlying values of u were often repeated for different seeds, such as 45 and 104. There was no apparent periodic behavior in these repeated outlying results. ---------- Added file: http://bugs.python.org/file45306/fig1.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 14:18:37 2016 From: report at bugs.python.org (Eric Appelt) Date: Tue, 01 Nov 2016 18:18:37 +0000 Subject: [issue26163] FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet) In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za> Message-ID: <1478024317.08.0.985574522121.issue26163@psf.upfronthosting.co.za> Eric Appelt added the comment: I made a copy/paste error on the second to last paragraph of the previous comment, it should be: Rehashing with the configured algorithm to shuffle the XORed result of the entry and size hashes to finish computing the frozenset hash resulted in an ideal distribution matching that of the pseudorandom numbers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 14:23:42 2016 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 01 Nov 2016 18:23:42 +0000 Subject: [issue28582] Invalid backslash syntax errors are not always accurate as to the location on the line where the error occurs Message-ID: <1478024622.67.0.848531208626.issue28582@psf.upfronthosting.co.za> New submission from Eric V. Smith: See msg279799 from issue28128, repeated here: Seems the ^ pointer is not always correct. For example, in the function scope it's correct: $ cat test.py def foo(): s = 'C:\Program Files\Microsoft' $ python3.7 -W error test.py File "test.py", line 2 s = 'C:\Program Files\Microsoft' ^ SyntaxError: invalid escape sequence \P On the other hand, top-level literals confuses the pointer: $ cat test.py s = 'C:\Program Files\Microsoft' $ python3.7 -W error test.py File "test.py", line 1 s = 'C:\Program Files\Microsoft' ^ SyntaxError: invalid escape sequence \P Is that expected? ---------- components: Interpreter Core messages: 279888 nosy: Chi Hsuan Yen, eric.smith priority: normal severity: normal status: open title: Invalid backslash syntax errors are not always accurate as to the location on the line where the error occurs type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 14:33:44 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 01 Nov 2016 18:33:44 +0000 Subject: [issue28583] PyDict_SetDefault doesn't combine split table when needed Message-ID: <1478025224.61.0.330385360884.issue28583@psf.upfronthosting.co.za> New submission from Xiang Zhang: PyDict_SetDefault doesn't combine split table when needed. This could lead to loss of order or crash. This is a follow up of #28199. ---------- components: Interpreter Core messages: 279889 nosy: inada.naoki, serhiy.storchaka, xiang.zhang priority: normal severity: normal status: open title: PyDict_SetDefault doesn't combine split table when needed type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 14:37:41 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 01 Nov 2016 18:37:41 +0000 Subject: [issue28199] Compact dict resizing is doing too much work In-Reply-To: <1474236829.43.0.744002065698.issue28199@psf.upfronthosting.co.za> Message-ID: <1478025461.3.0.0160436979359.issue28199@psf.upfronthosting.co.za> Xiang Zhang added the comment: Open #28583 and #28580 to tackle this. ---------- dependencies: +Optimize _PyDict_Next for split table, PyDict_SetDefault doesn't combine split table when needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 14:58:57 2016 From: report at bugs.python.org (Amit Ghadge) Date: Tue, 01 Nov 2016 18:58:57 +0000 Subject: [issue28578] '\n' escape character print before the Py_GetCompiler version In-Reply-To: <1477991270.69.0.795829340529.issue28578@psf.upfronthosting.co.za> Message-ID: <1478026737.33.0.758750196282.issue28578@psf.upfronthosting.co.za> Amit Ghadge added the comment: SilentGhost, Thanks for your response. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 15:54:26 2016 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 01 Nov 2016 19:54:26 +0000 Subject: [issue28499] Logging module documentation needs a rework. In-Reply-To: <1477070357.17.0.711656351025.issue28499@psf.upfronthosting.co.za> Message-ID: <1478030066.27.0.770192815865.issue28499@psf.upfronthosting.co.za> Vinay Sajip added the comment: I'm not sure this issue tracker is the best place to have an extended discussion about documentation - perhaps we should move this to a mailing list such as python-list. I'm not sure what you read first, but the logging documentation main page has a box marked "Important" right at the top, which says: "This page contains the API reference information. For tutorial information and discussion of more advanced topics, see ..." and then links to the basic and advanced tutorials and cookbook. The basic tutorial starts with information on when to use logging (including links to the convenient-for-beginners logging.XXX() functions), discusses the different logging levels, and then gives a simple example: import logging logging.warning('Watch out!') # will print a message to the console logging.info('I told you so') # will not print anything So I don't see where your statement "No example of quick usage (the first one is for `Logger.debug`, and that's not a generic one)" comes from, nor "The top-level function are documented at the end of the document, albeit they are the quickest way to use and understand `logging`". Although they are *listed* low down, there are *links* to them very early in the basic tutorial - in the very first paragraph of "When to use logging". With reference to your rough proposed structure, "Introduction to logging (with short example)" - the beginning of the basic tutorial does this. "Configuration (a separated chapter to describe file format, dict schema, and stuff)" - outline is described in the advanced tutorial, details are found in the specific page on the API reference for the logging.config module. "Module references (logging, logging.config, logging.handler, etc.)" - this is as it is now. "Cookbook & Tutorials" - these are separated from the reference documentation but otherwise seem to broadly follow what you're referring to here. Bear in mind that opinions on (and reactions to) documentation are fairly subjective. For example, you seem to find the Django documentation problematic, but I don't, and it's widely regarded as one of the best documentation sets for any Python project, and has contributed a lot to Django's success. If you really want to take this on, I don't think a patch is the best way to proceed, because there will be a *lot* of changes due to things moving around, etc. and one would need to build the documentation from the changed sources to get the full effect of the changes, unlike when reviewing source code. Instead, you could create a project on ReadTheDocs which takes copies of the logging documentation source pages and changes them to provide your alternative vision of how the documentation should look. This will allow easier side-by-side comparison for anyone who wants to review and compare the alternatives. If it's generally felt (e.g. by people on python-dev) that the new version is better than the current, then bringing the changes back shouldn't be too hard. What do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 17:22:46 2016 From: report at bugs.python.org (Carmelo Piccione) Date: Tue, 01 Nov 2016 21:22:46 +0000 Subject: [issue28584] ICC compiler check is too permissive Message-ID: <1478035366.63.0.90573648053.issue28584@psf.upfronthosting.co.za> New submission from Carmelo Piccione: if the ${CC} variable has an encoded path which contains "icc" anywhere in the string, it will be interpreted by the configure script as an icc compiler rather than gcc. This is due to matching on *icc* in various places. Example: "/home/cpiccion/.linuxbrew/bin/gcc" will match because of the "cpiccion". This is also true for the other patterns, including "gcc". Proposed fix is to take the basename of the ${CC} variable first. ---------- components: Installation files: icc-pattern-check-fix.patch keywords: patch messages: 279893 nosy: struktured priority: normal severity: normal status: open title: ICC compiler check is too permissive type: compile error versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45307/icc-pattern-check-fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 17:44:02 2016 From: report at bugs.python.org (Carmelo Piccione) Date: Tue, 01 Nov 2016 21:44:02 +0000 Subject: [issue28584] ICC compiler check is too permissive In-Reply-To: <1478035366.63.0.90573648053.issue28584@psf.upfronthosting.co.za> Message-ID: <1478036642.03.0.752818854827.issue28584@psf.upfronthosting.co.za> Changes by Carmelo Piccione : ---------- versions: +Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 17:51:57 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 Nov 2016 21:51:57 +0000 Subject: [issue28582] Invalid backslash syntax errors are not always accurate as to the location on the line where the error occurs In-Reply-To: <1478024622.67.0.848531208626.issue28582@psf.upfronthosting.co.za> Message-ID: <1478037117.54.0.82096669716.issue28582@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is known issue. See issue25677. ---------- nosy: +serhiy.storchaka resolution: -> duplicate superseder: -> Syntax error caret confused by indentation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 17:56:58 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Tue, 01 Nov 2016 21:56:58 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1478037418.79.0.859872333348.issue25677@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 21:47:42 2016 From: report at bugs.python.org (Zachary Ware) Date: Wed, 02 Nov 2016 01:47:42 +0000 Subject: [issue28584] ICC compiler check is too permissive In-Reply-To: <1478035366.63.0.90573648053.issue28584@psf.upfronthosting.co.za> Message-ID: <1478051262.26.0.511815655882.issue28584@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware stage: -> patch review versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 1 23:55:59 2016 From: report at bugs.python.org (Lisa Roach) Date: Wed, 02 Nov 2016 03:55:59 +0000 Subject: [issue27779] Sync-up docstrings in C version of the the decimal module In-Reply-To: <1471375735.77.0.977501297817.issue27779@psf.upfronthosting.co.za> Message-ID: <1478058959.41.0.841884646105.issue27779@psf.upfronthosting.co.za> Lisa Roach added the comment: Thanks for taking a look Stefan! I agree, it is definitely not as easy as it sounds. Your review and comments are helpful, I will make adjustments to the docstrings. If you want, I can continue to try to sync-up the docstrings and submit them for you and Raymond to review? I've been checking the docstrings against the general decimal specification: http://speleotrove.com/decimal/decarith.html, and with additional eyes on readability and best practices hopefully we can write updated, synchronized docstrings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 00:29:08 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 02 Nov 2016 04:29:08 +0000 Subject: [issue28581] Allow running code without explicitly saving the file. In-Reply-To: <1478022689.78.0.930783075071.issue28581@psf.upfronthosting.co.za> Message-ID: <1478060948.05.0.883105758089.issue28581@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree that this is a problem that needs a solution. Your post gives the justification very well. I already opened #19042 for this issue, so as is our usual policy, I am merging this duplicate into that one. Thank you for submitting a patch. To apply it, we need a Contributor Agreement. One can be signed electronically. See https://www.python.org/psf/contrib/. An '*' will appear after your name once a CA has been received and registered. I will take a good look once this happens. I the meanwhile, I will add a reference to this issue and patch, as well as additional comments, to #19042. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Idle: add option to autosave 'Untitled' edit window versions: +Python 3.6, Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 01:02:43 2016 From: report at bugs.python.org (perilbrain) Date: Wed, 02 Nov 2016 05:02:43 +0000 Subject: [issue28581] Allow running code without explicitly saving the file. In-Reply-To: <1478022689.78.0.930783075071.issue28581@psf.upfronthosting.co.za> Message-ID: <1478062963.58.0.841145366332.issue28581@psf.upfronthosting.co.za> perilbrain added the comment: Thanks Terry, I tried searching for a similar issue but failed. Feels like signing contributor form will take a while. Meantime please feel free to tweak/improve and implement code in your way (Mine is a bit rough solution not even abiding by naming convention), if this is some licensing issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 01:16:56 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 02 Nov 2016 05:16:56 +0000 Subject: [issue19042] Idle: add option to autosave 'Untitled' edit window In-Reply-To: <1379438454.05.0.402533666166.issue19042@psf.upfronthosting.co.za> Message-ID: <1478063815.99.0.239033029188.issue19042@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Duplicate #28581 has a autosave patch in the initial post, which points out that "We are often required to copy code from various sites say some tutorial or code samples which are good for one time usage." It prompted me to think more about the idea to 'add a mechanism to truly run without saving [to disk]', which I mentioned in my first post above. To run editor code, IDLE retrieves the code from the Text widget as a single strings; runs compile(code, 'filename', 'exec'), ships the code object to the user process, and runs exec(code, fakemain). (I understand this much better now than 3 years ago.) The only use of the disk copy is for tracebacks. But is it *needed*? I believe not. Here is standard interactive Python (3.5.2): >>> def f(): 1/0 >>> f() Traceback (most recent call last): File "", line 1, in File "", line 2, in f ZeroDivisionError: division by zero >>> Here is the same traceback in IDLE's Shell: Traceback (most recent call last): File "", line 1, in f() File "", line 2, in f 1/0 ZeroDivisionError: division by zero IDLE has filled in the missing lines from Shell's text. I have not yet tracked where this is done (in pyshell.py, I believe), but I presume it could do the same for Untitled editor windows. For this to work, the window titles should be Untitled-0, Untitled-1, ... . The specific name used in the compile call would appear in the traceback, to be used to lookup the window the code came from. With the ability to run the whole buffer without saving, it would be easy to run a selection. (There have been multiple requests for this.) IDLE already asks about saving when one tried to close a window with unsaved text, so there is no need to force saving when running for this purpose. ---------- versions: +Python 3.6, Python 3.7 -Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 01:18:42 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 02 Nov 2016 05:18:42 +0000 Subject: [issue28581] Allow running code without explicitly saving the file. In-Reply-To: <1478022689.78.0.930783075071.issue28581@psf.upfronthosting.co.za> Message-ID: <1478063922.09.0.0260417673234.issue28581@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In my additional comment, I explored the idea of running without saving, not even to a temp file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 03:16:43 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 02 Nov 2016 07:16:43 +0000 Subject: [issue28583] PyDict_SetDefault doesn't combine split table when needed In-Reply-To: <1478025224.61.0.330385360884.issue28583@psf.upfronthosting.co.za> Message-ID: <1478071003.43.0.183111964982.issue28583@psf.upfronthosting.co.za> Xiang Zhang added the comment: Here is a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file45308/PyDict_SetDefault.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 03:26:51 2016 From: report at bugs.python.org (Nixon) Date: Wed, 02 Nov 2016 07:26:51 +0000 Subject: [issue28575] Error 0x80070643 While installing in Win 10 32 Bit In-Reply-To: <1478005943.0.0.81962094025.issue28575@psf.upfronthosting.co.za> Message-ID: Nixon added the comment: Hi Steve, Thanks for the fast reply. Issue has been solved. That yesterday I was trying to install but couldn't tried different troubleshoots like restarting,clearing temp files, changing permission etc. But same error so I raised a issue. Now while installing it get installed without any error. Anyway thanks ya. On 1 November 2016 at 18:42, Steve Dower wrote: > > Steve Dower added the comment: > > If you look in your TEMP directory there should be a few more log files > alongside the one you attached. Could you post those too? You can put them > in a zip file to make it easier if you like. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > -- With Regards, Nixon Varghese, *"*Ability is of little account without opportunity.*."* ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 03:59:22 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 02 Nov 2016 07:59:22 +0000 Subject: [issue28583] PyDict_SetDefault doesn't combine split table when needed In-Reply-To: <1478025224.61.0.330385360884.issue28583@psf.upfronthosting.co.za> Message-ID: <1478073562.57.0.41796963617.issue28583@psf.upfronthosting.co.za> INADA Naoki added the comment: LGTM ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 04:00:02 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 02 Nov 2016 08:00:02 +0000 Subject: [issue28583] PyDict_SetDefault doesn't combine split table when needed In-Reply-To: <1478025224.61.0.330385360884.issue28583@psf.upfronthosting.co.za> Message-ID: <1478073602.76.0.602166611872.issue28583@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- nosy: +ned.deily priority: normal -> release blocker stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 04:01:48 2016 From: report at bugs.python.org (perilbrain) Date: Wed, 02 Nov 2016 08:01:48 +0000 Subject: [issue19042] Idle: add option to autosave 'Untitled' edit window In-Reply-To: <1379438454.05.0.402533666166.issue19042@psf.upfronthosting.co.za> Message-ID: <1478073708.02.0.343179191562.issue19042@psf.upfronthosting.co.za> perilbrain added the comment: "To run without saving" was the first idea I got, but it was difficult to pursue in first phase. After your hints I think I have achieved what you have described. I have done a few fixes(luckily in a single file ScriptBinding.py) which are giving satisfactory result. I am attaching the original, modified and the diff version of files named ScriptBindingOriginal.py, ScriptBinding.py and ScriptBinding.diff respectively. Here is what I am getting with the new code Traceback (most recent call last): File "*Untitled*", line 3, in File "*Untitled*", line 2, in f ZeroDivisionError: division by zero This is the summary of the patch (idle-python3.4) +import io .... #====== One member in class for reducing annoyance ==== self.no_save = False #====== New definition for function tabnanny====== - def tabnanny(self, filename): + def tabnanny(self, source): + f = io.StringIO(source)# , os.linesep *****Maybe***** - with tokenize.open(filename) as f: #====== Added 2 functions ========= def source_from_file(self, filename): with open(filename, 'rb') as f: source = f.read() if b'\r' in source: source = source.replace(b'\r\n', b'\n') source = source.replace(b'\r', b'\n') if source and source[-1] != ord(b'\n'): source = source + b'\n' return source def source_from_editor(self): self.editwin.io.fixlastline() source = self.editwin.text.get("1.0", "end-1c") return source #====== New definition for function checksyntax====== - def checksyntax(self, filename): + def checksyntax(self, source, filename): #====== Changes in function run_module_event (Main) ========== def _run_module_event(self, event): filename = self.getfilename() filename = self.getfilename() if not filename: self.no_save = True source = self.source_from_editor() filename = self.editwin.top.wm_title() else: source = self.source_from_file(filename) self.no_save = False code = self.checksyntax(source, filename) if not code: return 'break' if not self.tabnanny(source): return 'break' interp = self.shell.interp if PyShell.use_subprocess: interp.restart_subprocess(with_cwd=False) if not self.no_save: .... interp.runcode(code) return 'break' #====== Finally suppressing the annoyance ====== if autosave and filename: self.editwin.io.save(None) elif self.no_save: filename = None else: confirm = self.ask_save_dialog() Please have a review and let me know if it can solve this issue. ---------- nosy: +perilbrain Added file: http://bugs.python.org/file45309/ScriptBinding.diff.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 04:16:46 2016 From: report at bugs.python.org (Christian Heimes) Date: Wed, 02 Nov 2016 08:16:46 +0000 Subject: [issue17305] IDNA2008 encoding missing In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za> Message-ID: <1478074605.99.0.205985801946.issue17305@psf.upfronthosting.co.za> Christian Heimes added the comment: I reported the issue for curl, CVE-2016-8625 https://curl.haxx.se/docs/adv_20161102K.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 04:31:16 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Nov 2016 08:31:16 +0000 Subject: [issue28585] Restore docstring of os._isdir Message-ID: <1478075476.63.0.19722756431.issue28585@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: When converted to Argument Clinic in 3.5 the docstring of os._isdir() was lost. Proposed patch restores it. ---------- components: Argument Clinic, Extension Modules, Windows files: os-_isdir-docstring.patch keywords: patch messages: 279905 nosy: larry, paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: patch review status: open title: Restore docstring of os._isdir type: behavior versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45310/os-_isdir-docstring.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 04:32:02 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 02 Nov 2016 08:32:02 +0000 Subject: [issue28199] Compact dict resizing is doing too much work In-Reply-To: <1474236829.43.0.744002065698.issue28199@psf.upfronthosting.co.za> Message-ID: <1478075522.37.0.642810655009.issue28199@psf.upfronthosting.co.za> INADA Naoki added the comment: Thanks, Xiang. Shard-key dict is very hard to maintain... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 04:33:16 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Nov 2016 08:33:16 +0000 Subject: [issue28586] Convert os.scandir to Argument Clinic Message-ID: <1478075596.56.0.454562353142.issue28586@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch converts os.scandir and DirEntry methods to Argument Clinic. ---------- components: Argument Clinic, Extension Modules files: clinic-scandir.patch keywords: patch messages: 279907 nosy: larry, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Convert os.scandir to Argument Clinic type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45311/clinic-scandir.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 04:34:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Nov 2016 08:34:13 +0000 Subject: [issue25996] Add support of file descriptor in os.scandir() In-Reply-To: <1451758238.49.0.729670752807.issue25996@psf.upfronthosting.co.za> Message-ID: <1478075653.71.0.627738204824.issue25996@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka dependencies: +Convert os.scandir to Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 05:09:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Nov 2016 09:09:13 +0000 Subject: [issue28580] Optimize _PyDict_Next for split table In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478077753.81.0.0568656149429.issue28580@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I agree that this unlikely could cause visible effect, but this patch simplifies the code. LGTM. Similar changes can be applied to other iteration code. dictiter_iternextkey, dict_keys, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 05:10:10 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Nov 2016 09:10:10 +0000 Subject: [issue28580] Optimize _PyDict_Next for split table In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478077810.04.0.582146848557.issue28580@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think this is too late for 3.6. ---------- type: behavior -> enhancement versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 05:19:36 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 02 Nov 2016 09:19:36 +0000 Subject: [issue28580] Optimize _PyDict_Next for split table In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478078376.01.0.712862282635.issue28580@psf.upfronthosting.co.za> INADA Naoki added the comment: LGTM, too. > Similar changes can be applied to other iteration code. dictiter_iternextkey, dict_keys, etc. I agree. Xiang, would you update patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 05:23:49 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Nov 2016 09:23:49 +0000 Subject: [issue28583] PyDict_SetDefault doesn't combine split table when needed In-Reply-To: <1478025224.61.0.330385360884.issue28583@psf.upfronthosting.co.za> Message-ID: <1478078629.91.0.169213030541.issue28583@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Besides the patch is a little hard to understanding due to changes that are not directly related to the issue, it LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 05:28:19 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 02 Nov 2016 09:28:19 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478078899.93.0.205476670559.issue28580@psf.upfronthosting.co.za> Xiang Zhang added the comment: > Xiang, would you update patch? Working on it. ---------- title: Optimize _PyDict_Next for split table -> Optimize iterating split table values _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 05:32:23 2016 From: report at bugs.python.org (ChrisRands) Date: Wed, 02 Nov 2016 09:32:23 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments Message-ID: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> New submission from ChrisRands: In Python 3 and 2 docs https://docs.python.org/3.5/tutorial/datastructures.html, list.index only mentions the first argument: list.index(x) Return the index in the list of the first item whose value is x. It is an error if there is no such item. However, in reality list.index can take further arguments: index(...) L.index(value, [start, [stop]]) -> integer -- return first index of value. Raises ValueError if the value is not present. ---------- assignee: docs at python components: Documentation messages: 279913 nosy: ChrisRands, docs at python priority: normal severity: normal status: open title: list.index documentation missing start and stop arguments _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 05:32:37 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 02 Nov 2016 09:32:37 +0000 Subject: [issue28583] PyDict_SetDefault doesn't combine split table when needed In-Reply-To: <1478025224.61.0.330385360884.issue28583@psf.upfronthosting.co.za> Message-ID: <1478079157.41.0.192653963805.issue28583@psf.upfronthosting.co.za> INADA Naoki added the comment: I'll commit. ---------- assignee: -> inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 05:47:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Nov 2016 09:47:19 +0000 Subject: [issue28513] Document zipfile CLI In-Reply-To: <1477218977.25.0.95260452294.issue28513@psf.upfronthosting.co.za> Message-ID: <1478080039.34.0.720980622373.issue28513@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: docs at python -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 05:47:34 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Nov 2016 09:47:34 +0000 Subject: [issue28583] PyDict_SetDefault doesn't combine split table when needed In-Reply-To: <1478025224.61.0.330385360884.issue28583@psf.upfronthosting.co.za> Message-ID: <20161102094731.34630.29275.33B84BE3@psf.io> Roundup Robot added the comment: New changeset 4e9c7704f373 by INADA Naoki in branch '3.6': Issue #28583: PyDict_SetDefault didn't combine split table when needed. https://hg.python.org/cpython/rev/4e9c7704f373 New changeset a6a79053aec4 by INADA Naoki in branch 'default': Issue #28583: PyDict_SetDefault didn't combine split table when needed. https://hg.python.org/cpython/rev/a6a79053aec4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 05:47:57 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 02 Nov 2016 09:47:57 +0000 Subject: [issue28583] PyDict_SetDefault doesn't combine split table when needed In-Reply-To: <1478025224.61.0.330385360884.issue28583@psf.upfronthosting.co.za> Message-ID: <1478080077.37.0.336828583211.issue28583@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 06:00:03 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 02 Nov 2016 10:00:03 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478080803.87.0.585684236387.issue28580@psf.upfronthosting.co.za> Xiang Zhang added the comment: Here is the new patch to apply the optimization to more places. ---------- Added file: http://bugs.python.org/file45312/iterate_splittable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 06:14:10 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Nov 2016 10:14:10 +0000 Subject: [issue28513] Document zipfile CLI In-Reply-To: <1477218977.25.0.95260452294.issue28513@psf.upfronthosting.co.za> Message-ID: <20161102101407.3656.24330.7B1DA08B@psf.io> Roundup Robot added the comment: New changeset feb6e8678512 by Serhiy Storchaka in branch '2.7': Issue #28513: Documented command-line interface of zipfile. https://hg.python.org/cpython/rev/feb6e8678512 New changeset b51bf32defb1 by Serhiy Storchaka in branch '3.5': Issue #28513: Documented command-line interface of zipfile. https://hg.python.org/cpython/rev/b51bf32defb1 New changeset 843538a4094b by Serhiy Storchaka in branch '3.6': Issue #28513: Documented command-line interface of zipfile. https://hg.python.org/cpython/rev/843538a4094b New changeset 0c8ffa562f3a by Serhiy Storchaka in branch 'default': Issue #28513: Documented command-line interface of zipfile. https://hg.python.org/cpython/rev/0c8ffa562f3a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 06:16:03 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Nov 2016 10:16:03 +0000 Subject: [issue28513] Document zipfile CLI In-Reply-To: <1477218977.25.0.95260452294.issue28513@psf.upfronthosting.co.za> Message-ID: <1478081763.73.0.139386930797.issue28513@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Applied both Martin's suggestion. Thank you all! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 06:56:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Nov 2016 10:56:17 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478084177.64.0.149571296902.issue28580@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 07:02:28 2016 From: report at bugs.python.org (Christian Heimes) Date: Wed, 02 Nov 2016 11:02:28 +0000 Subject: [issue28414] SSL match_hostname fails for internationalized domain names In-Reply-To: <1476172956.13.0.85556243538.issue28414@psf.upfronthosting.co.za> Message-ID: <1478084548.13.0.957140607991.issue28414@psf.upfronthosting.co.za> Christian Heimes added the comment: It's a big, complicated mess. I can't implement IDN support correctly because Python lacks UTS#46 and IDNA2008 support. I just found out that IDNA 2008 is not enough because it does not provide a case mapping. Lack of case mapping broke my fix for curl CVE-2016-8625. At the moment IDN support is broken in a sane way: it just doesn't work and fails. A partial fix will introduce security issues. http://unicode.org/reports/tr46/#Processing lists "www.sparkasse-gie?en.de" as a critical example. It's the domain of a German savings and loan bank. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 07:49:46 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 02 Nov 2016 11:49:46 +0000 Subject: [issue19042] Idle: add option to autosave 'Untitled' edit window In-Reply-To: <1379438454.05.0.402533666166.issue19042@psf.upfronthosting.co.za> Message-ID: <1478087386.46.0.844009661256.issue19042@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Looks promising. The second half of a patch would be to fill in the missing lines. Before I review, please sign a CA. The online form at https://www.python.org/psf/contrib/contrib-form/ takes about 5 minutes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 08:01:30 2016 From: report at bugs.python.org (Christian Heimes) Date: Wed, 02 Nov 2016 12:01:30 +0000 Subject: [issue28588] Memory leak in OpenSSL thread state Message-ID: <1478088089.97.0.896254141092.issue28588@psf.upfronthosting.co.za> New submission from Christian Heimes: Quote from https://github.com/curl/curl/issues/964 --- I wrote to Matt Caswell from openssl.org about this memleah, and he answered: OpenSSL maintains a separate error queue for each thread. On each queue there can be multiple errors. ERR_get_state() does not add any errors to the queue it merely returns the ERR_STATE (i.e. the queue) for the current thread. If the current thread has no queue then ERR_get_state() will create one. ERR_clear_error() removes all the errors that are on the current thread's queue. It does not deallocate the current thread's queue. ERR_remove_thread_state() deallocates the specified thread's queue. The mem leaks you are seeing are almost certainly because the queues for your app's threads have not been deallocated. --- The memory leak only affects OpenSSL 1.0.2 and older. OpenSSL 1.1.0 takes care of threading, locking and thread local resources itself. ---------- assignee: christian.heimes components: Extension Modules, SSL messages: 279922 nosy: christian.heimes priority: normal severity: normal stage: test needed status: open title: Memory leak in OpenSSL thread state type: resource usage versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 08:47:45 2016 From: report at bugs.python.org (Florian Strzelecki) Date: Wed, 02 Nov 2016 12:47:45 +0000 Subject: [issue28499] Logging module documentation needs a rework. In-Reply-To: <1477070357.17.0.711656351025.issue28499@psf.upfronthosting.co.za> Message-ID: <1478090865.67.0.718004801358.issue28499@psf.upfronthosting.co.za> Florian Strzelecki added the comment: A project published on RTD looks like a very good idea. I'll give it a try! Thanks for your feedback. I think we don't have the same opinion on how to organize parts and details, so it's on me to show something worth our times. > you seem to find the Django documentation problematic Yes, yet I found it to be one of the best out there too. I can enjoy something and still be critical about it. Even if I'm critical of the current logging documentation, there are plenty of good things here to keep, and if we want to compare, it's still far better than most documentation out there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 09:02:52 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 02 Nov 2016 13:02:52 +0000 Subject: [issue28575] Error 0x80070643 While installing in Win 10 32 Bit In-Reply-To: <1477980147.77.0.242850372978.issue28575@psf.upfronthosting.co.za> Message-ID: <1478091772.97.0.544000431487.issue28575@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 09:05:58 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 02 Nov 2016 13:05:58 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <1478091958.92.0.216323335788.issue28587@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Attached is the patch to update the documentation. Please review. Thanks :) ---------- keywords: +patch nosy: +Mariatta Added file: http://bugs.python.org/file45313/issue28587.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 09:18:16 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Nov 2016 13:18:16 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <1478092696.9.0.695044764303.issue28587@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 09:24:18 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 02 Nov 2016 13:24:18 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <1478093058.96.0.197708384088.issue28587@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Hmm, I did not mean to replace the documentation example like that. Here's another update. ---------- Added file: http://bugs.python.org/file45314/issue28587.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 10:14:05 2016 From: report at bugs.python.org (DiazSoho) Date: Wed, 02 Nov 2016 14:14:05 +0000 Subject: [issue28589] get error when compile .py file during install stage if cross compile Message-ID: <1478096045.86.0.191357002406.issue28589@psf.upfronthosting.co.za> New submission from DiazSoho: when I try to do cross compile Python-2.7.12, it gets error when trying install. because the command is using compile host python to compile .py file with *.so files, but the *.so are built by cross platform toolchain already, then it will say "cannot open shared object file: No such file or directory" the log is below: PYTHONPATH=/home/real_users/avs_py/Python/py_install/usr/local/lib/python2.7 \ _PYTHON_PROJECT_BASE=/home/real_users/avs_py/Python/Python-2.7.12 _PYTHON_HOST_PLATFORM=linux2-mips PYTHONPATH=/home/real_users/avs_py/Python/Python-2.7.12/build/lib.linux2-mips-2.7:/home/real_users/avs_py/Python/Python-2.7.12/Lib:/home/real_users/avs_py/Python/Python-2.7.12/Lib/plat-linux2 python2.7 -Wi -tt /home/real_users/avs_py/Python/py_install/usr/local/lib/python2.7/compileall.py \ -d /home/real_users/avs_py/Python/py_install/usr/local/lib/python2.7 -f \ -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \ /home/real_users/avs_py/Python/py_install/usr/local/lib/python2.7 Traceback (most recent call last): File "/home/real_users/avs_py/Python/py_install/usr/local/lib/python2.7/compileall.py", line 16, in import struct File "/home/real_users/avs_py/Python/py_install/usr/local/lib/python2.7/struct.py", line 1, in from _struct import * ImportError: /home/real_users/avs_py/Python/Python-2.7.12/build/lib.linux2-mips-2.7/_struct.so: cannot open shared object file: No such file or directory make[5]: *** [libinstall] Error 1 ---------- components: Cross-Build messages: 279926 nosy: Alex.Willmer, DiazSoho priority: normal severity: normal status: open title: get error when compile .py file during install stage if cross compile type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 10:15:02 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Nov 2016 14:15:02 +0000 Subject: [issue28589] get error when compile .py file during install stage if cross compile In-Reply-To: <1478096045.86.0.191357002406.issue28589@psf.upfronthosting.co.za> Message-ID: <1478096102.53.0.316511301297.issue28589@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +doko, xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 10:56:18 2016 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 02 Nov 2016 14:56:18 +0000 Subject: [issue28582] Invalid backslash syntax errors are not always accurate as to the location on the line where the error occurs In-Reply-To: <1478024622.67.0.848531208626.issue28582@psf.upfronthosting.co.za> Message-ID: <1478098578.42.0.778977688887.issue28582@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 10:58:03 2016 From: report at bugs.python.org (=?utf-8?b?5bCk56uL5a6H?=) Date: Wed, 02 Nov 2016 14:58:03 +0000 Subject: [issue28590] fstring's '{' from escape sequences does not start an expression Message-ID: <1478098683.95.0.617891142218.issue28590@psf.upfronthosting.co.za> New submission from ???: PEP 498 says: (https://www.python.org/dev/peps/pep-0498/#escape-sequences) Scanning an f-string for expressions happens after escape sequences are decoded. Because hex(ord('{')) == 0x7b , the f-string f'\u007b4*10}' is decoded to f'{4*10}' , which evaluates as the integer 40: >>> f'\u007b4*10}' '40' However, in python3.6.0b3, the '{' from '\u007b4' does not start an expression, making the remaining '}' invalid: >>> f'\u007b4*10}' File "", line 1 SyntaxError: f-string: single '}' is not allowed There's even a test case for it: (Lib/test/test_fstring.py:383) def test_no_escapes_for_braces(self): # \x7b is '{'. Make sure it doesn't start an expression. self.assertEqual(f'\x7b2}}', '{2}') self.assertEqual(f'\x7b2', '{2') self.assertEqual(f'\u007b2', '{2') self.assertEqual(f'\N{LEFT CURLY BRACKET}2\N{RIGHT CURLY BRACKET}', '{2}') ---------- components: Interpreter Core messages: 279927 nosy: ??? priority: normal severity: normal status: open title: fstring's '{' from escape sequences does not start an expression type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 11:10:14 2016 From: report at bugs.python.org (SilentGhost) Date: Wed, 02 Nov 2016 15:10:14 +0000 Subject: [issue28590] fstring's '{' from escape sequences does not start an expression In-Reply-To: <1478098683.95.0.617891142218.issue28590@psf.upfronthosting.co.za> Message-ID: <1478099414.52.0.353893324749.issue28590@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 11:14:08 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Nov 2016 15:14:08 +0000 Subject: [issue28590] fstring's '{' from escape sequences does not start an expression In-Reply-To: <1478098683.95.0.617891142218.issue28590@psf.upfronthosting.co.za> Message-ID: <1478099648.72.0.236575207635.issue28590@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> docs at python components: +Documentation -Interpreter Core nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 11:17:29 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 02 Nov 2016 15:17:29 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478099849.66.0.461766375005.issue28580@psf.upfronthosting.co.za> Xiang Zhang added the comment: Update the patch to use more obvious comparison way. This uses INADA's suggestion and make the code more like other places. I think the performance issue is better to be discussed in #28397. It doesn't have a significant impact on this patch. Hope we can move forward and not block on it. ---------- nosy: +haypo Added file: http://bugs.python.org/file45315/iterate_splittable_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 11:21:22 2016 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 02 Nov 2016 15:21:22 +0000 Subject: [issue28590] fstring's '{' from escape sequences does not start an expression In-Reply-To: <1478098683.95.0.617891142218.issue28590@psf.upfronthosting.co.za> Message-ID: <1478100082.87.0.640767894322.issue28590@psf.upfronthosting.co.za> Eric V. Smith added the comment: I'm currently working on an update to PEP-498 to address this. I hope to have it completed after a sprint this weekend. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 11:22:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Nov 2016 15:22:37 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478100157.88.0.676354205008.issue28580@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please check how this change affects the performance? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 12:31:00 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 02 Nov 2016 16:31:00 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478104260.01.0.797665822045.issue28580@psf.upfronthosting.co.za> Xiang Zhang added the comment: python -> unpatched, python3 -> patched iterkeys: (split) ./python3 -m perf timeit --compare-to /home/angwer/cpython/python -s 'from argparse import Namespace; ns = Namespace(); [setattr(ns, str(i), str(i)) for i in range(10000)]' 'list(iter(ns.__dict__))' python: ..................... 112 us +- 1 us python3: ..................... 109 us +- 1 us Median +- std dev: [python] 112 us +- 1 us -> [python3] 109 us +- 1 us: 1.03x faster (combined) ./python3 -m perf timeit --compare-to /home/angwer/cpython/python -s 'd = {x:x for x in range(10000)}' 'list(iter(d))'python: ..................... 84.3 us +- 2.4 us python3: ..................... 86.0 us +- 3.5 us Median +- std dev: [python] 84.3 us +- 2.4 us -> [python3] 86.0 us +- 3.5 us: 1.02x slower pydict_next: (split) ./python3 -m perf timeit --compare-to /home/angwer/cpython/python -s 'from argparse import Namespace; ns = Namespace(); [setattr(ns, str(i), str(i)) for i in range(10000)]' 'repr(ns.__dict__)' python: ..................... 1.85 ms +- 0.01 ms python3: ..................... 1.85 ms +- 0.11 ms Median +- std dev: [python] 1.85 ms +- 0.01 ms -> [python3] 1.85 ms +- 0.11 ms: 1.00x faster (combined) ./python3 -m perf timeit --compare-to /home/angwer/cpython/python -s 'd = {x:x for x in range(10000)}' 'repr(d)' python: ..................... 1.99 ms +- 0.01 ms python3: ..................... 1.87 ms +- 0.01 ms Median +- std dev: [python] 1.99 ms +- 0.01 ms -> [python3] 1.87 ms +- 0.01 ms: 1.06x faster ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 12:43:29 2016 From: report at bugs.python.org (Charalampos Stratakis) Date: Wed, 02 Nov 2016 16:43:29 +0000 Subject: [issue21590] Systemtap and DTrace support In-Reply-To: <1401195995.8.0.935339035852.issue21590@psf.upfronthosting.co.za> Message-ID: <1478105009.91.0.880076144261.issue21590@psf.upfronthosting.co.za> Charalampos Stratakis added the comment: Fedora so far has been using the systemtap patch downstream from dmalcolm [0]. So for 3.6 by removing the systemtap patch (it cannot be applied anymore cleanly) and by enabling the --with-dtrace configure flag I get this error [1]: make: *** [Makefile:884: Include/pydtrace_probes.h] Error 1 If however I touch the pydtrace_probes.h file I get various undefined references [2] and also: make: *** [Makefile:724: Programs/_freeze_importlib] Error 1 [0] http://pkgs.fedoraproject.org/cgit/rpms/python3.git/tree/00055-systemtap.patch [1] https://kojipkgs.fedoraproject.org//work/tasks/9656/16279656/build.log [2] https://kojipkgs.fedoraproject.org//work/tasks/9670/16279670/build.log ---------- nosy: +cstratak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 13:21:41 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Nov 2016 17:21:41 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478107301.35.0.360709560594.issue28580@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is not easy to benchmark PyDict_Next. dict.__repr__ does much hard work (calling repr() for keys and values, formatting strings). Using _testcapi.test_dict_iteration perhaps is the easiest way to measure the performance of pure PyDict_Next, but it includes creating and deallocating of dicts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 13:30:28 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 02 Nov 2016 17:30:28 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478107828.96.0.941934767973.issue28580@psf.upfronthosting.co.za> Xiang Zhang added the comment: Yes, that's the point. I thought to expose an API in testcapimodule for test, but actually I am not willing to do that since I don't believe this patch could bring any visible performance change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 14:18:12 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 02 Nov 2016 18:18:12 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478107828.96.0.941934767973.issue28580@psf.upfronthosting.co.za> Message-ID: INADA Naoki added the comment: > Xiang Zhang added the comment: > > Yes, that's the point. I thought to expose an API in testcapimodule for test, but actually I am not willing to do that since I don't believe this patch could bring any visible performance change. > I agree with you. I feel this patch is cleanup rather than optimization. * Removing redundant loop which always break at first * Adding very useful assertion to find potential bugs ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 14:26:56 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 02 Nov 2016 18:26:56 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478111216.05.0.802950290814.issue28580@psf.upfronthosting.co.za> INADA Naoki added the comment: LGTM again for iterate_splittable_v2.patch. How about issue title (and commit message) to "Cleanup iterating split table"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 14:27:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Nov 2016 18:27:34 +0000 Subject: [issue28115] Use argparse for the zipfile module In-Reply-To: <1473750423.74.0.95052105427.issue28115@psf.upfronthosting.co.za> Message-ID: <1478111254.63.0.212870990999.issue28115@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: SilentGhost suggested to pass required=True to add_mutually_exclusive_group(). This makes the last "else" not needed. Proposed patch implements this suggestion. ---------- assignee: -> serhiy.storchaka Added file: http://bugs.python.org/file45316/zipfile-cli-required.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 14:37:14 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Nov 2016 18:37:14 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478111834.83.0.324913532793.issue28580@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I believe the patch doesn't makes iterating split table slower and likely makes it a little faster. The patch adds one additional check, but it removes other checks. Thus this still is an optimization. But the last patch has an undefined behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 15:38:01 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 02 Nov 2016 19:38:01 +0000 Subject: [issue28589] get error when compile .py file during install stage if cross compile In-Reply-To: <1478096045.86.0.191357002406.issue28589@psf.upfronthosting.co.za> Message-ID: <1478115481.0.0.866670109979.issue28589@psf.upfronthosting.co.za> Xavier de Gaye added the comment: msg269617 details how this problem can also be reproduced on 3.6 by cross-building for Android before the issue 27917 that added platform triplets for Android had been fixed. Since the changes in issue 23968 have not be retrofited to 3.5, the same problem must also exist on 3.5. Closing this issue as a duplicate of issue 22724. ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 16:06:18 2016 From: report at bugs.python.org (Raul) Date: Wed, 02 Nov 2016 20:06:18 +0000 Subject: [issue28591] imghdr doesn't recognize some jpeg formats Message-ID: <1478117178.16.0.265494893112.issue28591@psf.upfronthosting.co.za> New submission from Raul: Some valid JPEG images are not detected by the imghdr lib. ---------- components: Library (Lib) files: 1.jpg messages: 279940 nosy: 4simple-org, Claudiu.Popa, ezio.melotti, haypo, intgr, jcea, joril, kovid, mvignali, r.david.murray priority: normal severity: normal status: open title: imghdr doesn't recognize some jpeg formats type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45317/1.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 16:10:14 2016 From: report at bugs.python.org (Raul) Date: Wed, 02 Nov 2016 20:10:14 +0000 Subject: [issue28591] imghdr doesn't recognize some jpeg formats In-Reply-To: <1478117178.16.0.265494893112.issue28591@psf.upfronthosting.co.za> Message-ID: <1478117414.49.0.585149228046.issue28591@psf.upfronthosting.co.za> Raul added the comment: Other valid jpeg image not detected. ---------- Added file: http://bugs.python.org/file45318/2.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 16:24:43 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 02 Nov 2016 20:24:43 +0000 Subject: [issue28542] document cross compilation In-Reply-To: <1477563460.46.0.569265292251.issue28542@psf.upfronthosting.co.za> Message-ID: <1478118283.44.0.701770410599.issue28542@psf.upfronthosting.co.za> Xavier de Gaye added the comment: About 2.7, this is a list of the issues I am aware of, that may have to be fixed also in 2.7 (and 3.5 for some of them): issues #26884 #27434 #28444 and #22724. Issue #28589 was entered today and is a duplicate of the previous one. > FWIW, DESTDIR, --prefix, etc are not specific to cross compilation or Android. I must be seeing everything through my little Android hammer these days :) This new patch removes the last paragraph. ---------- Added file: http://bugs.python.org/file45319/readme_5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 16:49:39 2016 From: report at bugs.python.org (Alex Samuel) Date: Wed, 02 Nov 2016 20:49:39 +0000 Subject: [issue19948] POSIX semantics of PATH search in execvpe is not respected In-Reply-To: <1386687325.82.0.275504904763.issue19948@psf.upfronthosting.co.za> Message-ID: <1478119779.95.0.414245713397.issue19948@psf.upfronthosting.co.za> Alex Samuel added the comment: Here's a real-world case where this can cause unexpected results: A shell script has a typo in the shebang ("#/!bin/bash") but the execute bit set. It still runs via the C library's execvp() and also via bash (which uses execve() but reimplements the behavior) but not with Python's os.execvp(). Would there be interest in a patch that fixes this? ---------- nosy: +Alex Samuel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 16:53:10 2016 From: report at bugs.python.org (Pierre Bousquie) Date: Wed, 02 Nov 2016 20:53:10 +0000 Subject: [issue28499] Logging module documentation needs a rework. In-Reply-To: <1478090865.67.0.718004801358.issue28499@psf.upfronthosting.co.za> Message-ID: Pierre Bousquie added the comment: Thank you Vinay for your feedback. RTD seems a very good start to me. Florian thanks for joining :). I'm not leaving you alone on this! I don't mind closing the "bug" request. It was mainly for St?phane Wirtel :)... but it's still "committing" :) 2016-11-02 13:47 GMT+01:00 Florian Strzelecki : > > Florian Strzelecki added the comment: > > A project published on RTD looks like a very good idea. I'll give it a try! > > Thanks for your feedback. I think we don't have the same opinion on how to > organize parts and details, so it's on me to show something worth our times. > > > you seem to find the Django documentation problematic > > Yes, yet I found it to be one of the best out there too. I can enjoy > something and still be critical about it. Even if I'm critical of the > current logging documentation, there are plenty of good things here to > keep, and if we want to compare, it's still far better than most > documentation out there. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 17:01:20 2016 From: report at bugs.python.org (Raul) Date: Wed, 02 Nov 2016 21:01:20 +0000 Subject: [issue28228] imghdr does not support pathlib In-Reply-To: <1474489313.4.0.716838576472.issue28228@psf.upfronthosting.co.za> Message-ID: <1478120480.31.0.432099324146.issue28228@psf.upfronthosting.co.za> Raul added the comment: patch for python 2.7 ---------- nosy: +4simple-org Added file: http://bugs.python.org/file45320/imghdr27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 17:01:46 2016 From: report at bugs.python.org (Raul) Date: Wed, 02 Nov 2016 21:01:46 +0000 Subject: [issue28228] imghdr does not support pathlib In-Reply-To: <1474489313.4.0.716838576472.issue28228@psf.upfronthosting.co.za> Message-ID: <1478120506.89.0.713387969754.issue28228@psf.upfronthosting.co.za> Changes by Raul : Removed file: http://bugs.python.org/file45320/imghdr27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 17:02:37 2016 From: report at bugs.python.org (Raul) Date: Wed, 02 Nov 2016 21:02:37 +0000 Subject: [issue28591] imghdr doesn't recognize some jpeg formats In-Reply-To: <1478117178.16.0.265494893112.issue28591@psf.upfronthosting.co.za> Message-ID: <1478120557.97.0.562733087544.issue28591@psf.upfronthosting.co.za> Raul added the comment: patch for python 2.7 ---------- keywords: +patch Added file: http://bugs.python.org/file45321/imghdr27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 17:03:11 2016 From: report at bugs.python.org (Raul) Date: Wed, 02 Nov 2016 21:03:11 +0000 Subject: [issue28591] imghdr doesn't recognize some jpeg formats In-Reply-To: <1478117178.16.0.265494893112.issue28591@psf.upfronthosting.co.za> Message-ID: <1478120591.78.0.864142127097.issue28591@psf.upfronthosting.co.za> Raul added the comment: patch for python 3.X ---------- Added file: http://bugs.python.org/file45322/imghdr35.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 17:03:53 2016 From: report at bugs.python.org (Raul) Date: Wed, 02 Nov 2016 21:03:53 +0000 Subject: [issue28591] imghdr doesn't recognize some jpeg formats In-Reply-To: <1478117178.16.0.265494893112.issue28591@psf.upfronthosting.co.za> Message-ID: <1478120633.08.0.37581877925.issue28591@psf.upfronthosting.co.za> Changes by Raul : Removed file: http://bugs.python.org/file45322/imghdr35.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 17:05:12 2016 From: report at bugs.python.org (Raul) Date: Wed, 02 Nov 2016 21:05:12 +0000 Subject: [issue28591] imghdr doesn't recognize some jpeg formats In-Reply-To: <1478117178.16.0.265494893112.issue28591@psf.upfronthosting.co.za> Message-ID: <1478120712.0.0.981435858362.issue28591@psf.upfronthosting.co.za> Raul added the comment: patch for python 3.X ---------- Added file: http://bugs.python.org/file45323/imghdr35.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 17:07:43 2016 From: report at bugs.python.org (Raul) Date: Wed, 02 Nov 2016 21:07:43 +0000 Subject: [issue28591] imghdr doesn't recognize some jpeg formats In-Reply-To: <1478117178.16.0.265494893112.issue28591@psf.upfronthosting.co.za> Message-ID: <1478120863.79.0.826392941961.issue28591@psf.upfronthosting.co.za> Raul added the comment: Working imghdr lib for python 2.7.X ---------- Added file: http://bugs.python.org/file45324/imghdr_py27.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 17:08:26 2016 From: report at bugs.python.org (Raul) Date: Wed, 02 Nov 2016 21:08:26 +0000 Subject: [issue28591] imghdr doesn't recognize some jpeg formats In-Reply-To: <1478117178.16.0.265494893112.issue28591@psf.upfronthosting.co.za> Message-ID: <1478120906.3.0.789436759414.issue28591@psf.upfronthosting.co.za> Raul added the comment: Working imghdr lib for python 3.X ---------- Added file: http://bugs.python.org/file45325/imghdr_py3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 17:22:34 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Nov 2016 21:22:34 +0000 Subject: [issue28088] Document Transport.set_protocol and get_protocol In-Reply-To: <1475369173.63.0.247466795846.issue28088@psf.upfronthosting.co.za> Message-ID: <1478121754.8.0.697123972532.issue28088@psf.upfronthosting.co.za> Guido van Rossum added the comment: LGTM too. Can someone add this to the asyncio docs (starting at the 3.5 branch please)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 17:28:11 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 02 Nov 2016 21:28:11 +0000 Subject: [issue20847] asyncio docs should call out that network logging is a no-no In-Reply-To: <1393877540.32.0.826428021059.issue20847@psf.upfronthosting.co.za> Message-ID: <1478122091.97.0.38307414277.issue20847@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : Removed file: http://bugs.python.org/file45182/issue20847.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 17:40:45 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 02 Nov 2016 21:40:45 +0000 Subject: [issue28591] imghdr doesn't recognize some jpeg formats In-Reply-To: <1478117178.16.0.265494893112.issue28591@psf.upfronthosting.co.za> Message-ID: <1478122845.04.0.844765938009.issue28591@psf.upfronthosting.co.za> R. David Murray added the comment: There seem to be unrelated changes in your patches, and we'll want tests as well before committing. See also issue 16512 and the issues linked from it. (I haven't reviewed to see if there is any overlap.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 19:28:16 2016 From: report at bugs.python.org (Ex Tracheese) Date: Wed, 02 Nov 2016 23:28:16 +0000 Subject: [issue28592] Installation freezes on C Runtime Install Message-ID: <1478129295.09.0.95134744404.issue28592@psf.upfronthosting.co.za> New submission from Ex Tracheese: When trying to install Python 3.5.2 on my Windows 7 computer after getting a new SSD, the installer freezes on the C Runtime portion and never progresses past it. I have attached the log file which is full of some errors that don't really mean anything to me. ---------- components: Build, Windows files: Python 3.5.2 (32-bit)_20161102192326.log messages: 279953 nosy: Ex Tracheese, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Installation freezes on C Runtime Install type: crash versions: Python 3.5 Added file: http://bugs.python.org/file45326/Python 3.5.2 (32-bit)_20161102192326.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 19:38:07 2016 From: report at bugs.python.org (Ex Tracheese) Date: Wed, 02 Nov 2016 23:38:07 +0000 Subject: [issue28592] Installation freezes on C Runtime Install In-Reply-To: <1478129295.09.0.95134744404.issue28592@psf.upfronthosting.co.za> Message-ID: <1478129887.73.0.302053189469.issue28592@psf.upfronthosting.co.za> Ex Tracheese added the comment: Nevermind, I found the problem. Windows Update shortcut got deleted from Start Menu. Thank god there was a stack overflow question. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 19:41:28 2016 From: report at bugs.python.org (Ex Tracheese) Date: Wed, 02 Nov 2016 23:41:28 +0000 Subject: [issue28592] Installation freezes on C Runtime Install In-Reply-To: <1478129295.09.0.95134744404.issue28592@psf.upfronthosting.co.za> Message-ID: <1478130088.47.0.253482383294.issue28592@psf.upfronthosting.co.za> Ex Tracheese added the comment: Nevermind *again*, turns out the install wasn't successful despite appearances. When I try to actually run python it complains that there's no C Runtime dll. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 21:04:37 2016 From: report at bugs.python.org (Eryk Sun) Date: Thu, 03 Nov 2016 01:04:37 +0000 Subject: [issue28592] Installation freezes on C Runtime Install In-Reply-To: <1478129295.09.0.95134744404.issue28592@psf.upfronthosting.co.za> Message-ID: <1478135077.64.0.913568929163.issue28592@psf.upfronthosting.co.za> Eryk Sun added the comment: Supported versions of Windows Vista and later should have the CRT update [1] installed via Windows Update. (3.5.2 is bundled with the older KB2999226 update [2].) A Windows 7 system that I checked had this automatically installed last March. But maybe for some reason it's not getting pushed to all systems. Try manually installing the KB3118401 update for x64-based Windows 7. Steve, do you think it's a good idea to continue bundling the CRT update with the 3.6 installer? When 3.5 was released last year the Universal CRT was new and IIRC not conveniently available as a recommended update in Windows Update, but that's no longer the case AFAIK. [1]: https://support.microsoft.com/en-us/kb/3118401 [2]: https://support.microsoft.com/en-us/kb/2999226 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 21:08:23 2016 From: report at bugs.python.org (Eryk Sun) Date: Thu, 03 Nov 2016 01:08:23 +0000 Subject: [issue28592] Installation freezes on C Runtime Install In-Reply-To: <1478129295.09.0.95134744404.issue28592@psf.upfronthosting.co.za> Message-ID: <1478135303.79.0.177950158276.issue28592@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- components: +Installation -Build _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 21:24:05 2016 From: report at bugs.python.org (Masayuki Yamamoto) Date: Thu, 03 Nov 2016 01:24:05 +0000 Subject: [issue28441] Change sys.executable to include executable suffix In-Reply-To: <1476452085.73.0.180033377767.issue28441@psf.upfronthosting.co.za> Message-ID: <1478136245.95.0.737008579829.issue28441@psf.upfronthosting.co.za> Masayuki Yamamoto added the comment: I have missed a case of empty progpath. I updated the patch to avoid calling add_exe_suffix() at that case. ---------- Added file: http://bugs.python.org/file45327/sys-executable-suffix-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 21:49:05 2016 From: report at bugs.python.org (INADA Naoki) Date: Thu, 03 Nov 2016 01:49:05 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478137745.04.0.953790213509.issue28580@psf.upfronthosting.co.za> INADA Naoki added the comment: (Off topic note) For readability, I prefer this style: PyDictKeyEntry *entries = DK_ENTRIES(mp->ma_keys); while (i < n && entries[i].me_value == NULL) i++; But because sizeof(PyDictKeyEntry) is not 2^n, entries[i].me_value, i++ may be slower than entry_ptr->me_value, i++, entry_ptr++. So we should prefer i++, entry_ptr++ style in case of iterating dict entries. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 21:59:53 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Nov 2016 01:59:53 +0000 Subject: [issue23693] timeit accuracy could be better In-Reply-To: <1426631677.96.0.782828300886.issue23693@psf.upfronthosting.co.za> Message-ID: <1478138393.56.0.348646870992.issue23693@psf.upfronthosting.co.za> STINNER Victor added the comment: I wrote a whole new project "perf" to fix root issues of this issue. It includes a timeit command. I suggest you to use "perf timeit" rather than "timeit" because perf is more reliable: http://perf.readthedocs.io/en/latest/cli.html#timeit ---------- resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 22:38:15 2016 From: report at bugs.python.org (Francisco Couzo) Date: Thu, 03 Nov 2016 02:38:15 +0000 Subject: [issue28593] Inconsistent itertools' predicate behaviour Message-ID: <1478140695.8.0.674711100728.issue28593@psf.upfronthosting.co.za> New submission from Francisco Couzo: As per Terry's recommendation https://mail.python.org/pipermail/python-dev/2016-November/146791.html Currently some functions in itertools (dropwhile and takewhile), don't accept None as a predicate, but filterfalse and groupby do. I'd like your input, and I'm interested in writing a patch. ---------- messages: 279960 nosy: franciscouzo, rhettinger priority: normal severity: normal status: open title: Inconsistent itertools' predicate behaviour type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 23:11:40 2016 From: report at bugs.python.org (perilbrain) Date: Thu, 03 Nov 2016 03:11:40 +0000 Subject: [issue19042] Idle: add option to autosave 'Untitled' edit window In-Reply-To: <1379438454.05.0.402533666166.issue19042@psf.upfronthosting.co.za> Message-ID: <1478142700.47.0.742146859721.issue19042@psf.upfronthosting.co.za> perilbrain added the comment: I have signed the CA. Meantime a came across one more problem in function tabnanny(encoding issue) so I am attaching the new version of ScriptBinding.py. Summary:- def tabnanny(self, source, encoding = None): # XXX: tabnanny should work on binary files as well #print(encoding) f = io.StringIO(source.decode(encoding) if encoding else source) def source_from_file(self, filename): with open(filename, 'rb') as f: source = f.read() encoding = tokenize.detect_encoding(f.readline)[0] .... return source, encoding def _run_module_event(self, event): ... if not filename: self.no_save = True source = self.source_from_editor() filename = self.editwin.top.wm_title() else: source, encoding = self.source_from_file(filename) self.no_save = False code = self.checksyntax(source, filename) if not code: return 'break' if not self.tabnanny(source, encoding): return 'break' .... ---------- Added file: http://bugs.python.org/file45328/ScriptBinding.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 2 23:31:08 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 03 Nov 2016 03:31:08 +0000 Subject: [issue26980] The path argument of asyncio.BaseEventLoop.create_unix_connection is not documented In-Reply-To: <1462743548.86.0.976035936413.issue26980@psf.upfronthosting.co.za> Message-ID: <1478143868.54.0.609949359743.issue26980@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Hi, I updated the documentation explaining the path argument. Let me know if this works. Thanks :) ---------- keywords: +patch nosy: +Mariatta Added file: http://bugs.python.org/file45329/issue26980.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 00:06:09 2016 From: report at bugs.python.org (Kovid Goyal) Date: Thu, 03 Nov 2016 04:06:09 +0000 Subject: [issue28591] imghdr doesn't recognize some jpeg formats In-Reply-To: <1478117178.16.0.265494893112.issue28591@psf.upfronthosting.co.za> Message-ID: <1478145969.29.0.845939895645.issue28591@psf.upfronthosting.co.za> Kovid Goyal added the comment: FYI, the uptodate version of imghdr I maintain is here: https://github.com/kovidgoyal/calibre/blob/master/src/calibre/utils/imghdr.py It uses memoryview for performance and can also also read image sizes from file headers for jpeg, png, gif and jpeg2000. Note that is is only tested on python 2.7 I'm afraid I dont have the time to shepherd it through your review process, but feel free to take code from it if you want to. It is licensed GPLv3 but I am willing to re-license to another license if needed, as I am the sole contributor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 00:25:52 2016 From: report at bugs.python.org (Steve Dower) Date: Thu, 03 Nov 2016 04:25:52 +0000 Subject: [issue28592] Installation freezes on C Runtime Install In-Reply-To: <1478129295.09.0.95134744404.issue28592@psf.upfronthosting.co.za> Message-ID: <1478147152.06.0.731247475795.issue28592@psf.upfronthosting.co.za> Steve Dower added the comment: This looks like a corrupted download to me - the update was aborted because none of the other packages were "found", which should be impossible since they are embedded in that executable. It may also be an antivirus program interfering though, as I'd expect a corrupt installer to fail earlier than this. We definitely need to keep the update in there. If there's a superseding update already installed then we won't install it (or for the web installer even download it), and it may still be necessary for offline installs. As I said, it's not the issue here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 00:53:56 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 03 Nov 2016 04:53:56 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478148836.22.0.742999764808.issue28580@psf.upfronthosting.co.za> Changes by Xiang Zhang : Added file: http://bugs.python.org/file45330/iterate_splittable_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 01:02:25 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 03 Nov 2016 05:02:25 +0000 Subject: [issue28591] imghdr doesn't recognize some jpeg formats In-Reply-To: <1478117178.16.0.265494893112.issue28591@psf.upfronthosting.co.za> Message-ID: <1478149345.81.0.070208235721.issue28591@psf.upfronthosting.co.za> Xiang Zhang added the comment: There is also #27121 reporting similar problem. ---------- nosy: +xiang.zhang versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 02:50:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Nov 2016 06:50:12 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478155812.55.0.313495878633.issue28580@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Following example causes a crash in debug build: d = dict.fromkeys(range(100)) for k in range(99): del d[k] it = iter(d) assert next(it) == 99 d.clear() d[0] = None next(it) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 03:23:18 2016 From: report at bugs.python.org (saeed) Date: Thu, 03 Nov 2016 07:23:18 +0000 Subject: [issue28594] List define and Change result Message-ID: <1478157798.51.0.0317356859068.issue28594@psf.upfronthosting.co.za> New submission from saeed: Hi, I define multi List in a line such as this: smoke= exercise = cholesterol = angina = stroke = attack = [0] * 2 and This work bad! if I define later line such this, problem has been solve: smoke=[0]*2 exercise = [0]*2 cholesterol = [0]*2 angina = [0]*2 stroke = [0]*2 I just change this line in my project but result changed! Is this a bug? ***************************************** ***************************************** notice to "Smoke" change in follow, "Smoke" changed from [0, 1] to [0 ,6] in a one state, for what??!! ***************************************** out put before change: > $ python3.5 ./my.py smoke= [0, 0] before income: [0, 0, 0, 0, 0, 0, 0, 0] income[ 5 ] += 1 after income: [0, 0, 0, 0, 0, 1, 0, 0] before smoke: [0, 0] 2 smoke[ 1 ] += 1 after smoke: [0, 1] stop in step before income: [0, 0, 0, 0, 0, 1, 0, 0] income[ 1 ] += 1 after income: [0, 1, 0, 0, 0, 1, 0, 0] before smoke: [0, 6] 2 smoke[ 1 ] += 1 after smoke: [0, 7] stop in step before income: [0, 1, 0, 0, 0, 1, 0, 0] income[ 5 ] += 1 after income: [0, 1, 0, 0, 0, 2, 0, 0] before smoke: [2, 10] 1 smoke[ 0 ] += 1 after smoke: [3, 10] stop in step ***************************************** out put after change: >$ python3.5 my1.py smoke= [0, 0] before income: [0, 0, 0, 0, 0, 0, 0, 0] income[ 5 ] += 1 after income: [0, 0, 0, 0, 0, 1, 0, 0] before smoke: [0, 0] 2 smoke[ 1 ] += 1 after smoke: [0, 1] stop in step before income: [0, 0, 0, 0, 0, 1, 0, 0] income[ 1 ] += 1 after income: [0, 1, 0, 0, 0, 1, 0, 0] before smoke: [0, 1] 2 smoke[ 1 ] += 1 after smoke: [0, 2] stop in step before income: [0, 1, 0, 0, 0, 1, 0, 0] income[ 5 ] += 1 after income: [0, 1, 0, 0, 0, 2, 0, 0] before smoke: [0, 2] 1 smoke[ 0 ] += 1 after smoke: [1, 2] stop in step ***************************************** :/ Thanks ---------- files: my.tar.7z messages: 279967 nosy: ezio.melotti, saeed priority: normal severity: normal status: open title: List define and Change result type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file45331/my.tar.7z _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 03:26:58 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 03 Nov 2016 07:26:58 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478158018.07.0.180192921791.issue28580@psf.upfronthosting.co.za> Xiang Zhang added the comment: Hmm, the resolution could be simple. But how about >>> d = dict.fromkeys(range(100)) >>> for k in range(98): ... del d[k] ... >>> it = iter(d) >>> next(it) 98 >>> d.clear() >>> d[0] = 1 >>> d[1] = 2 >>> next(it) Traceback (most recent call last): File "", line 1, in StopIteration Actually we haven't exhaust the dict yet. Is it reasonable for me to expect the second next returning 0? I actually mean is it reasonable for me to expect len(dict) elements returned before StopIteration raised even if the dict is changed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 03:51:28 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 03 Nov 2016 07:51:28 +0000 Subject: [issue28594] List define and Change result In-Reply-To: <1478157798.51.0.0317356859068.issue28594@psf.upfronthosting.co.za> Message-ID: <1478159488.71.0.352234557625.issue28594@psf.upfronthosting.co.za> Martin Panter added the comment: I haven?t looked at your code, but I think you may have misunderstood how variable assignments work in Python. See . When you assign an object such as [0, 0] to a variable name, the name is ?bound? to the object. When you assign to a second name, the second name is bound to exactly the same object. When you alter the object through one name, the change is visible from any of the bound names. Closing this, but let me know if I got it wrong. ---------- nosy: +martin.panter resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 04:08:28 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Nov 2016 08:08:28 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478160508.48.0.380439357653.issue28580@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It is appropriate if iterating modifying dict raises RuntimeError, produces less items or even produce some items multiple times. What is not appropriate -- crash, hang and infinite iteration. There was a proposition about making this behavior more consistent (issue19332), but it was rejected. I would suggest just remove assert() from your patch and address undefined behavior in other issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 04:08:39 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 03 Nov 2016 08:08:39 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478160519.71.0.817038064717.issue28580@psf.upfronthosting.co.za> Xiang Zhang added the comment: Currently dict iterator does not allow size changed during iteration. This is more strict than list iterator but still allow modification during iteration. Maybe we could deny all modification by checking dict->ma_version_tag. But that's irrelevant to this issue. Serhiy, this means the iternext* functions all get UB. These codes existed even in 3.3. Do we really need to eliminate them now? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 04:10:38 2016 From: report at bugs.python.org (saeed) Date: Thu, 03 Nov 2016 08:10:38 +0000 Subject: [issue28594] List define and Change result In-Reply-To: <1478157798.51.0.0317356859068.issue28594@psf.upfronthosting.co.za> Message-ID: <1478160638.36.0.213969367313.issue28594@psf.upfronthosting.co.za> saeed added the comment: Thank for attention,but see this: >>> x=y=[] >>> x=y=[0]*3 >>> x [0, 0, 0] >>> y [0, 0, 0] >>> y=[0, 1, 1] >>> x [0, 0, 0] >>> y [0, 1, 1] >>> y[1]+=1 >>> y [0, 2, 1] >>> x [0, 0, 0] >>> x[0]+=5 >>> x [5, 0, 0] >>> y [0, 2, 1] then must my code work and there is another problem :/ ********************************* notice: I don't write like this: >>> x=[] >>> y=x ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 04:12:41 2016 From: report at bugs.python.org (saeed) Date: Thu, 03 Nov 2016 08:12:41 +0000 Subject: [issue28594] List define and Change result In-Reply-To: <1478157798.51.0.0317356859068.issue28594@psf.upfronthosting.co.za> Message-ID: <1478160761.51.0.0532541970613.issue28594@psf.upfronthosting.co.za> Changes by saeed : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 04:14:31 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 03 Nov 2016 08:14:31 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478160871.76.0.466679607207.issue28580@psf.upfronthosting.co.za> Xiang Zhang added the comment: > I would suggest just remove assert() from your patch and address undefined behavior in other issue. That's what v2 does. If there is another issue, let's also leave _PyDict_Next to it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 04:21:43 2016 From: report at bugs.python.org (Sam Miller) Date: Thu, 03 Nov 2016 08:21:43 +0000 Subject: [issue25251] Unknown MS Compiler version 1900 In-Reply-To: <1443392264.43.0.443478210283.issue25251@psf.upfronthosting.co.za> Message-ID: <1478161303.63.0.317424791093.issue25251@psf.upfronthosting.co.za> Sam Miller added the comment: Hi disutils. I got this bug when trying to pip install pomegranate to python 3.5. There is now a m2w64-toolchain (https://github.com/ContinuumIO/anaconda-issues/issues/561)that allows installing the notoriously windows-challenged theano, so I thought this error could be resolved with a new class m2w64Compiler(CygwinCCompiler) or maybe just updating the old Mingw32CCompiler(CygwinCCompiler) class. ---------- nosy: +Sam Miller _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 04:27:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Nov 2016 08:27:17 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478161637.35.0.340579914598.issue28580@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In current code there is no UB in _PyDict_Next(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 04:36:49 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 03 Nov 2016 08:36:49 +0000 Subject: [issue28594] List define and Change result In-Reply-To: <1478157798.51.0.0317356859068.issue28594@psf.upfronthosting.co.za> Message-ID: <1478162209.07.0.941465523014.issue28594@psf.upfronthosting.co.za> Xiang Zhang added the comment: In your last example, after x=y=[], you reassign a new list to y, so x and y are different. In your my.py, you are altering the same list. Please read the link Martin gives. ---------- nosy: +xiang.zhang status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 04:40:24 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 03 Nov 2016 08:40:24 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478162424.83.0.95285605703.issue28580@psf.upfronthosting.co.za> Changes by Xiang Zhang : Added file: http://bugs.python.org/file45332/iterate_splittable_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 04:49:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Nov 2016 08:49:19 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478162959.65.0.235452648683.issue28580@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: v4 LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 05:17:53 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Nov 2016 09:17:53 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1478164673.85.0.564814425802.issue25677@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- stage: patch review -> commit review versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 05:32:16 2016 From: report at bugs.python.org (saeed) Date: Thu, 03 Nov 2016 09:32:16 +0000 Subject: [issue28594] List define and Change result In-Reply-To: <1478157798.51.0.0317356859068.issue28594@psf.upfronthosting.co.za> Message-ID: <1478165536.36.0.745693583305.issue28594@psf.upfronthosting.co.za> saeed added the comment: OK, I found My problem, Thank so much, There is any way to define them shortly?? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 05:42:17 2016 From: report at bugs.python.org (Evan) Date: Thu, 03 Nov 2016 09:42:17 +0000 Subject: [issue28595] shlex.split should not augment wordchars Message-ID: <1478166136.94.0.995190174918.issue28595@psf.upfronthosting.co.za> New submission from Evan: The changes to shlex due to land in 3.6 use a predefined set of characters to "augment" wordchars, however this set is incomplete. For example, 'foo,bar' should be parsed as a single token, but it is split on the comma: $ echo foo,bar foo,bar >>> import shlex >>> list(shlex.shlex('foo,bar', punctuation_chars=True)) ['foo', ',', 'bar'] (For context on where this was encountered, see https://github.com/kislyuk/argcomplete/issues/161) Instead of trying to enumerate all possible wordchars, I think a more robust solution is to use whitespace_split to include *all* characters not otherwise considered special. Ideally this would be fixed before 3.6 is released to avoid needing to maintain backwards compatibility with the current behaviour, although I understand the timeline may make this difficult. I've attached a patch with proposed changes, including updates to the tests to demonstrate the effective difference. I can make the corresponding documentation changes if we want this merged. (I've added everyone to the nosy list from http://bugs.python.org/issue1521950 where these changes originated.) ---------- components: Library (Lib) files: without_augmenting_chars.diff keywords: patch messages: 279980 nosy: Andrey.Kislyuk, cvrebert, eric.araujo, eric.smith, evan_, ezio.melotti, python-dev, r.david.murray, robodan, vinay.sajip priority: normal severity: normal status: open title: shlex.split should not augment wordchars type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file45333/without_augmenting_chars.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 05:48:40 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 03 Nov 2016 09:48:40 +0000 Subject: [issue28596] on Android _bootlocale on startup relies on too many library modules Message-ID: <1478166520.26.0.975749703987.issue28596@psf.upfronthosting.co.za> New submission from Xavier de Gaye: Android does not have langinfo.h and this results in _bootlocale importing locale on startup (see issue 26928). IMHO it is not acceptable to fallback to locale.py if CODESET is not available (in answer to Victor question in msg199367), because there are now two code paths to investigate weird bugs such as the one described by Antoine in issue 9548. Also note that Android platforms have a slow processor and limited RAM size, so they would strongly benefit from a startup sequence avoiding the imports made by the locale module. Since there is already a _bootlocale module, what are now the objections to implement the patch Antoine has proposed in issue 9548 ? Nosying people from issue 9548. ---------- components: Interpreter Core messages: 279981 nosy: Arfrever, barry, benjamin.peterson, brett.cannon, christian.heimes, eric.araujo, eric.snow, flox, haypo, lemburg, mark.dickinson, ncoghlan, orsenthil, pitrou, python-dev, rhettinger, xdegaye priority: normal severity: normal stage: needs patch status: open title: on Android _bootlocale on startup relies on too many library modules type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 05:55:52 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 03 Nov 2016 09:55:52 +0000 Subject: [issue26928] _bootlocale imports locale at startup on Android, causing test_site to fail In-Reply-To: <1462284365.5.0.819379627022.issue26928@psf.upfronthosting.co.za> Message-ID: <1478166952.75.0.46605713405.issue26928@psf.upfronthosting.co.za> Xavier de Gaye added the comment: This patch fixes test_startup_imports when the platform does not have langinfo.h. Entered new issue 28596: "on Android _bootlocale on startup relies on too many library modules". ---------- assignee: -> xdegaye components: +Tests -Cross-Build, Library (Lib) stage: -> patch review versions: +Python 3.7 Added file: http://bugs.python.org/file45334/skip_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 05:59:11 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 03 Nov 2016 09:59:11 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1478167151.09.0.583517935403.issue26865@psf.upfronthosting.co.za> Xavier de Gaye added the comment: issue #28596: on Android _bootlocale on startup relies on too many library modules ---------- dependencies: +on Android _bootlocale on startup relies on too many library modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 06:43:39 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 03 Nov 2016 10:43:39 +0000 Subject: [issue26935] android: test_os fails In-Reply-To: <1462287800.22.0.0769666286965.issue26935@psf.upfronthosting.co.za> Message-ID: <1478169819.09.0.864574557522.issue26935@psf.upfronthosting.co.za> Xavier de Gaye added the comment: This new patch takes into account Martin comment in msg265099 and fixes a call to getpwall() as Android does not have getpwall(). ---------- assignee: -> xdegaye stage: patch review -> commit review versions: +Python 3.7 Added file: http://bugs.python.org/file45335/test_urandom_fd_reopened_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 07:11:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Nov 2016 11:11:13 +0000 Subject: [issue28123] _PyDict_GetItem_KnownHash ignores DKIX_ERROR return In-Reply-To: <1473760278.9.0.335020145509.issue28123@psf.upfronthosting.co.za> Message-ID: <1478171473.24.0.100911883367.issue28123@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If _PyDict_GetItem_KnownHash() returns an error, it is very likely that following insertdict() with same key will return an error. I would prefer to return an error right after _PyDict_GetItem_KnownHash() is failed. This would look more straightforward. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 07:36:21 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Nov 2016 11:36:21 +0000 Subject: [issue28385] Bytes objects should reject all formatting codes with an error message In-Reply-To: <1475850520.09.0.230705784029.issue28385@psf.upfronthosting.co.za> Message-ID: <1478172981.43.0.738525715568.issue28385@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The proposition of making default __format__ equivalent to str() will be addressed in separate issue. Python-Dev thread: https://mail.python.org/pipermail/python-dev/2016-October/146765.html. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 07:38:11 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 03 Nov 2016 11:38:11 +0000 Subject: [issue28123] _PyDict_GetItem_KnownHash ignores DKIX_ERROR return In-Reply-To: <1473760278.9.0.335020145509.issue28123@psf.upfronthosting.co.za> Message-ID: <1478173091.03.0.0396620525018.issue28123@psf.upfronthosting.co.za> Xiang Zhang added the comment: > If _PyDict_GetItem_KnownHash() returns an error, it is very likely that following insertdict() with same key will return an error. Make sense. ---------- assignee: haypo -> serhiy.storchaka Added file: http://bugs.python.org/file45336/issue28123_v6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 07:46:07 2016 From: report at bugs.python.org (Stefan Krah) Date: Thu, 03 Nov 2016 11:46:07 +0000 Subject: [issue27779] Sync-up docstrings in C version of the the decimal module In-Reply-To: <1471375735.77.0.977501297817.issue27779@psf.upfronthosting.co.za> Message-ID: <1478173567.95.0.254318782065.issue27779@psf.upfronthosting.co.za> Stefan Krah added the comment: Okay great. I think it's probably best to produce an initial patch with the verbatim Python docstrings (you can of course address the comments that I already made), then we mark the passages that are clearly not valid for _decimal or outdated for _pydecimal, then we go for extra clarity. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 07:46:53 2016 From: report at bugs.python.org (Stefan Krah) Date: Thu, 03 Nov 2016 11:46:53 +0000 Subject: [issue27779] Sync-up docstrings in C version of the the decimal module In-Reply-To: <1471375735.77.0.977501297817.issue27779@psf.upfronthosting.co.za> Message-ID: <1478173613.85.0.0849949215215.issue27779@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- keywords: -easy, patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 07:47:10 2016 From: report at bugs.python.org (Stefan Krah) Date: Thu, 03 Nov 2016 11:47:10 +0000 Subject: [issue27779] Sync-up docstrings in C version of the the decimal module In-Reply-To: <1471375735.77.0.977501297817.issue27779@psf.upfronthosting.co.za> Message-ID: <1478173630.57.0.230146972465.issue27779@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- keywords: +patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 07:53:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Nov 2016 11:53:20 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1478174000.56.0.0467828527323.issue23262@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't understand with what you disagree. I can imagine old Python 2.7 with old browser, old Python 2.7 with new browser, new Python 2.7 with new browser, and even new Python 2.7 with old browser on the same computer (but the latter is very unlikely). Old Python 2.7 don't work with new browser and we can't do anything with this. We can make new Python 2.7.12 working with new browser. But I'm not sure that we can break the compatibility with old browser that could be installed when Python 2.7 was first installed on the same computer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 08:12:36 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Nov 2016 12:12:36 +0000 Subject: [issue28498] tk busy command In-Reply-To: <1477069423.12.0.229038359578.issue28498@psf.upfronthosting.co.za> Message-ID: <1478175156.24.0.473958112222.issue28498@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch skips tests with the cursor option on OSX/Aqua. ---------- Added file: http://bugs.python.org/file45337/tk_busy_6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 08:46:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Nov 2016 12:46:20 +0000 Subject: [issue28123] _PyDict_GetItem_KnownHash ignores DKIX_ERROR return In-Reply-To: <1473760278.9.0.335020145509.issue28123@psf.upfronthosting.co.za> Message-ID: <1478177180.76.0.852793716768.issue28123@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. I'll commit the patch soon if there are no comments from other core developers. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 09:30:54 2016 From: report at bugs.python.org (Fabio Zadrozny) Date: Thu, 03 Nov 2016 13:30:54 +0000 Subject: [issue28597] f-string behavior is conflicting with its documentation Message-ID: <1478179854.9.0.231732113134.issue28597@psf.upfronthosting.co.za> New submission from Fabio Zadrozny: The file: /Doc/reference/lexical_analysis.rst says that things as: f"abc {a[\"x\"]} def" # workaround: escape the inner quotes f"newline: {ord('\\n')}" # workaround: double escaping fr"newline: {ord('\n')}" # workaround: raw outer string are accepted in f-strings, yet, all those examples raise a: SyntaxError: f-string expression part cannot include a backslash The current Python version where this was tested is: 3.6.0b4 So, either those cases should be supported or lexical_analysis.rst should be updated to say that '\' is not valid in the expression part of f-strings. ---------- components: Interpreter Core messages: 279992 nosy: fabioz priority: normal severity: normal status: open title: f-string behavior is conflicting with its documentation versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 09:36:04 2016 From: report at bugs.python.org (Martijn Pieters) Date: Thu, 03 Nov 2016 13:36:04 +0000 Subject: [issue28598] RHS not consulted in `str % subclass_of_str` case. Message-ID: <1478180164.76.0.63576586286.issue28598@psf.upfronthosting.co.za> New submission from Martijn Pieters: The `BINARY_MODULO` operator hardcodes a test for `PyUnicode`: TARGET(BINARY_MODULO) { PyObject *divisor = POP(); PyObject *dividend = TOP(); PyObject *res = PyUnicode_CheckExact(dividend) ? PyUnicode_Format(dividend, divisor) : PyNumber_Remainder(dividend, divisor); This means that a RHS subclass of str can't override the operator: >>> class Foo(str): ... def __rmod__(self, other): ... return self % other ... >>> "Bar: %s" % Foo("Foo: %s") 'Bar: Foo %s' The expected output there is "Foo: Bar %s". This works correctly for `bytes`: >>> class FooBytes(bytes): ... def __rmod__(self, other): ... return self % other ... >>> b"Bar: %s" % FooBytes(b"Foo: %s") b'Foo: Bar: %s' and for all other types where the RHS is a subclass. Perhaps there should be a test to see if `divisor` is a subclass, and in that case take the slow path? ---------- components: Interpreter Core messages: 279993 nosy: mjpieters priority: normal severity: normal status: open title: RHS not consulted in `str % subclass_of_str` case. type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 09:39:21 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Nov 2016 13:39:21 +0000 Subject: [issue28387] double free in io.TextIOWrapper In-Reply-To: <1475868777.61.0.59647562301.issue28387@psf.upfronthosting.co.za> Message-ID: <20161103133918.25285.50851.32717301@psf.io> Roundup Robot added the comment: New changeset 91f024fc9b3a by Serhiy Storchaka in branch '2.7': Issue #28387: Fixed possible crash in _io.TextIOWrapper deallocator when https://hg.python.org/cpython/rev/91f024fc9b3a New changeset 89f7386104e2 by Serhiy Storchaka in branch '3.5': Issue #28387: Fixed possible crash in _io.TextIOWrapper deallocator when https://hg.python.org/cpython/rev/89f7386104e2 New changeset c4319c0d0131 by Serhiy Storchaka in branch '3.6': Issue #28387: Fixed possible crash in _io.TextIOWrapper deallocator when https://hg.python.org/cpython/rev/c4319c0d0131 New changeset 36af3566b67a by Serhiy Storchaka in branch 'default': Issue #28387: Fixed possible crash in _io.TextIOWrapper deallocator when https://hg.python.org/cpython/rev/36af3566b67a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 09:41:50 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Nov 2016 13:41:50 +0000 Subject: [issue28387] double free in io.TextIOWrapper In-Reply-To: <1475868777.61.0.59647562301.issue28387@psf.upfronthosting.co.za> Message-ID: <1478180510.33.0.645379607119.issue28387@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 09:43:31 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Nov 2016 13:43:31 +0000 Subject: [issue28597] f-string behavior is conflicting with its documentation In-Reply-To: <1478179854.9.0.231732113134.issue28597@psf.upfronthosting.co.za> Message-ID: <1478180611.26.0.504421114837.issue28597@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> docs at python components: +Documentation -Interpreter Core nosy: +docs at python, eric.smith type: -> behavior versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 09:47:14 2016 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 03 Nov 2016 13:47:14 +0000 Subject: [issue28597] f-string behavior is conflicting with its documentation In-Reply-To: <1478179854.9.0.231732113134.issue28597@psf.upfronthosting.co.za> Message-ID: <1478180834.5.0.401541919417.issue28597@psf.upfronthosting.co.za> Eric V. Smith added the comment: This is a duplicate of issue 28590. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> fstring's '{' from escape sequences does not start an expression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 09:47:15 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Nov 2016 13:47:15 +0000 Subject: [issue28494] is_zipfile false positives In-Reply-To: <1476997729.0.0.643464084789.issue28494@psf.upfronthosting.co.za> Message-ID: <1478180835.44.0.969362005863.issue28494@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 10:24:03 2016 From: report at bugs.python.org (INADA Naoki) Date: Thu, 03 Nov 2016 14:24:03 +0000 Subject: [issue28123] _PyDict_GetItem_KnownHash ignores DKIX_ERROR return In-Reply-To: <1473760278.9.0.335020145509.issue28123@psf.upfronthosting.co.za> Message-ID: <1478183043.21.0.764290355174.issue28123@psf.upfronthosting.co.za> INADA Naoki added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 11:45:02 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 03 Nov 2016 15:45:02 +0000 Subject: [issue28598] RHS not consulted in `str % subclass_of_str` case. In-Reply-To: <1478180164.76.0.63576586286.issue28598@psf.upfronthosting.co.za> Message-ID: <1478187902.68.0.426505532696.issue28598@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 11:46:58 2016 From: report at bugs.python.org (Steve Dower) Date: Thu, 03 Nov 2016 15:46:58 +0000 Subject: [issue25251] Unknown MS Compiler version 1900 In-Reply-To: <1443392264.43.0.443478210283.issue25251@psf.upfronthosting.co.za> Message-ID: <1478188018.83.0.0997070215495.issue25251@psf.upfronthosting.co.za> Steve Dower added the comment: That sounds like a great feature for setuptools. Core distutils is highly focused on what is needed for the core product, and we are very much trying to avoid bloating it, whereas setuptools is free to add extensions wherever necessary and make them available on earlier versions of Python. The setuptools issue tracker is at https://github.com/pypa/setuptools ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 11:47:58 2016 From: report at bugs.python.org (rebelxt) Date: Thu, 03 Nov 2016 15:47:58 +0000 Subject: [issue28599] AboutDialog set_name is ignored Message-ID: <1478188078.5.0.322982866117.issue28599@psf.upfronthosting.co.za> New submission from rebelxt: Python 3.5.2 (default, Sep 10 2016, 08:21:44) [GCC 5.4.0 20160609] on linux Mint 18 and Gtk 3. I run a python3 script that includes these statements: import gi gi.require_version('Gtk', '3.0') from gi.repository import Gtk, GObject aboutdialog = Gtk.AboutDialog() aboutdialog.set_name('arbitrary') aboutdialog.run() aboutdialog.destroy() The script name is displayed in the About dialog, while the 'arbitrary' name is ignored. This is inconsistent with python2/gtk2. If the set_name method/function exists, it should do something. I have no way of testing this on any later version of python. ---------- messages: 279998 nosy: rebelxt priority: normal severity: normal status: open title: AboutDialog set_name is ignored type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 11:53:39 2016 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Nov 2016 15:53:39 +0000 Subject: [issue28599] AboutDialog set_name is ignored In-Reply-To: <1478188078.5.0.322982866117.issue28599@psf.upfronthosting.co.za> Message-ID: <1478188419.5.0.837936941315.issue28599@psf.upfronthosting.co.za> Zachary Ware added the comment: That appears to be an issue with the third-party PyGObject project, please open an issue on the PyGObject issue tracker: https://bugzilla.gnome.org/page.cgi?id=browse.html&product=pygobject ---------- nosy: +zach.ware resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 11:54:43 2016 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Nov 2016 15:54:43 +0000 Subject: [issue28599] AboutDialog set_name is ignored In-Reply-To: <1478188078.5.0.322982866117.issue28599@psf.upfronthosting.co.za> Message-ID: <1478188483.35.0.133972389252.issue28599@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- resolution: not a bug -> third party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 11:59:47 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Nov 2016 15:59:47 +0000 Subject: [issue25652] collections.UserString.__rmod__() raises NameError In-Reply-To: <1447823769.89.0.495006915909.issue25652@psf.upfronthosting.co.za> Message-ID: <1478188787.73.0.800788810573.issue25652@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Issue28598 may be related. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 13:44:55 2016 From: report at bugs.python.org (Martijn Pieters) Date: Thu, 03 Nov 2016 17:44:55 +0000 Subject: [issue28598] RHS not consulted in `str % subclass_of_str` case. In-Reply-To: <1478180164.76.0.63576586286.issue28598@psf.upfronthosting.co.za> Message-ID: <1478195095.0.0.0529200764228.issue28598@psf.upfronthosting.co.za> Martijn Pieters added the comment: Here's a proposed patch for tip; what versions would it be worth backporting this to? (Note, there's no NEWS update in this patch). ---------- keywords: +patch Added file: http://bugs.python.org/file45338/issue28598.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 14:29:01 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 03 Nov 2016 18:29:01 +0000 Subject: [issue28600] asyncio: Optimize loop.call_soon Message-ID: <1478197741.66.0.256167531264.issue28600@psf.upfronthosting.co.za> New submission from Yury Selivanov: loop.call_soon is the central function of asyncio. Everything goes through it. Current design of asyncio.loop.call_soon makes the following checks: 1. [debug mode] check that the loop is not closed 2. [debug mode] check that we are calling call_soon from the proper thread 3. [always] check that callback is not a coroutine or a coroutine function Check #3 is very expensive, because it uses an 'isinstance' check. Moreover, isinstance checks against an ABC, which makes the call even slower. Attached patch makes check #3 optional and run only in debug mode. This is a very safe patch to merge. This makes asyncio another 17% (sic!) faster. In fact it becomes as fast as curio for realistic streams benchmarks. ---------- assignee: yselivanov components: asyncio messages: 280002 nosy: asvetlov, gvanrossum, haypo, inada.naoki, ned.deily, yselivanov priority: normal severity: normal status: open title: asyncio: Optimize loop.call_soon versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 14:35:20 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 03 Nov 2016 18:35:20 +0000 Subject: [issue28600] asyncio: Optimize loop.call_soon In-Reply-To: <1478197741.66.0.256167531264.issue28600@psf.upfronthosting.co.za> Message-ID: <1478198120.56.0.738476672865.issue28600@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- keywords: +patch Added file: http://bugs.python.org/file45339/call_soon.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 14:37:19 2016 From: report at bugs.python.org (Paul G) Date: Thu, 03 Nov 2016 18:37:19 +0000 Subject: [issue28601] Ambiguous datetime comparisons should use == rather than 'is' for tzinfo comparison Message-ID: <1478198239.55.0.291052836435.issue28601@psf.upfronthosting.co.za> New submission from Paul G: According to PEP495 (https://www.python.org/dev/peps/pep-0495/#aware-datetime-equality-comparison) datetimes are considered not equal if they are an ambiguous time and have different zones. However, currently "interzone comparison" is defined / implemented as the zones being the same object rather than the zones comparing equal. One issue with this is that it actually breaks backwards compatibility of the language, because there doesn't seem to be a way to provide a (backwards-compatible) class that implements folding behavior and has equivalent dates compare equal. An example using python-dateutil: ``` from datetime import datetime from dateutil import tz NYC = tz.gettz('America/New_York') ET = tz.gettz('US/Eastern') dt = datetime(2011, 11, 6, 5, 30, tzinfo=tz.tzutc()) # This is 2011-11-06 01:30 EDT-4 dt_edt = dt.astimezone(ET) dt_nyc = dt.astimezone(NYC) print(dt_nyc == dt_edt) ``` In Python 3.5 that will return True, in Python 3.6 it will return False, even though 'US/Eastern' and 'America/New_York' are the same zone. In this case, I might be able to enforce that these time zones are singletons so that `is` always returns True (though this may have other negative consequences for utility), but even that solution would fall apart for things like `tzrange` and `tzstr`, where you can know that the `dt.utcoffset()`s are going to be identical for ALL values of `dt`, but you can't force the objects to be identical. I would suggest that it be changed to use `__eq__` to determine whether two `tzinfo` objects are the same zone, as this will allow tzinfo providers to create `tzinfo` objects with a consistent behavior between versions in this edge case. ---------- components: Library (Lib) messages: 280003 nosy: belopolsky, p-ganssle priority: normal severity: normal status: open title: Ambiguous datetime comparisons should use == rather than 'is' for tzinfo comparison type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 14:42:12 2016 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 03 Nov 2016 18:42:12 +0000 Subject: [issue28600] asyncio: Optimize loop.call_soon In-Reply-To: <1478197741.66.0.256167531264.issue28600@psf.upfronthosting.co.za> Message-ID: <1478198532.43.0.326119335956.issue28600@psf.upfronthosting.co.za> Andrew Svetlov added the comment: The patch looks good. IIRC haypo added the check because people called `.call_later()` with coroutine instead of callback very often. But checking in debug mode looks very reasonable to me if it is so expensive. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 14:46:38 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 03 Nov 2016 18:46:38 +0000 Subject: [issue28601] Ambiguous datetime comparisons should use == rather than 'is' for tzinfo comparison In-Reply-To: <1478198239.55.0.291052836435.issue28601@psf.upfronthosting.co.za> Message-ID: <1478198798.68.0.294393414573.issue28601@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: See Datetime-SIG thread . ---------- assignee: -> belopolsky nosy: +tim.peters stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 14:48:01 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 03 Nov 2016 18:48:01 +0000 Subject: [issue28600] asyncio: Optimize loop.call_soon In-Reply-To: <1478197741.66.0.256167531264.issue28600@psf.upfronthosting.co.za> Message-ID: <1478198881.67.0.76897186043.issue28600@psf.upfronthosting.co.za> Yury Selivanov added the comment: > IIRC haypo added the check because people called `.call_later()` with coroutine instead of callback very often. We'll update asyncio docs in 3.6 with a tutorial to focus on coroutines (not on low-level event loop). This should leave the loop API to advanced users. > But checking in debug mode looks very reasonable to me if it is so expensive. Exactly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 14:55:50 2016 From: report at bugs.python.org (Paul G) Date: Thu, 03 Nov 2016 18:55:50 +0000 Subject: [issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation Message-ID: <1478199350.04.0.93782925147.issue28602@psf.upfronthosting.co.za> New submission from Paul G: After PEP-495, the default value for non-fold-aware datetimes is that they return the DST side, not the STD side (as was the assumption before PEP-495). This invalidates an assumption made in `tz.fromutc()`. See lines 991-1000 of datetime.py: dtdst = dt.dst() if dtdst is None: raise ValueError("fromutc() requires a non-None dst() result") delta = dtoff - dtdst if delta: dt += delta dtdst = dt.dst() if dtdst is None: raise ValueError("fromutc(): dt.dst gave inconsistent " "results; cannot convert") Line 997 (https://github.com/python/cpython/blob/be8de928e5d2f1cd4d4c9c3e6545b170f2b02f1b/Lib/datetime.py#L997) assumes that an ambiguous datetime will return the STD side, not the DST side, and as a result, if you feed it a date in UTC that should resolve to the STD side, it will actually return 1 hour (or whatever the DST offset is) AFTER the ambiguous date that should be returned. If 997 is changed to: dtdst = dt.replace(fold=1).dst() That will not affect fold-naive zones (which are instructed to ignore the `fold` parameter) and restore the original behavior. This will allow fold-aware timezones to be implemented as a wrapper around `fromutc()` rather than a complete re-implementation, e.g.: class FoldAwareTzInfo(datetime.tzinfo): def fromutc(self, dt): dt_wall = super(FoldAwareTzInfo, self).fromutc(dt) is_fold = self._get_fold_status(dt, dt_wall) return dt_wall.replace(fold=is_fold) ---------- messages: 280007 nosy: belopolsky, p-ganssle, tim.peters priority: normal severity: normal status: open title: `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 15:04:38 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 03 Nov 2016 19:04:38 +0000 Subject: [issue28600] asyncio: Optimize loop.call_soon In-Reply-To: <1478197741.66.0.256167531264.issue28600@psf.upfronthosting.co.za> Message-ID: <1478199878.26.0.338850447466.issue28600@psf.upfronthosting.co.za> Changes by Yury Selivanov : Added file: http://bugs.python.org/file45340/call_soon2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 15:06:21 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Nov 2016 19:06:21 +0000 Subject: [issue25264] test_marshal always crashs on "AMD64 Windows10 2.7" buildbot In-Reply-To: <1443513708.82.0.964856310612.issue25264@psf.upfronthosting.co.za> Message-ID: <1478199981.06.0.757330768892.issue25264@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Crashes seems was fixed in issue22734 and issue27019. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> marshal needs a lower stack depth for debug builds on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 15:16:17 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 03 Nov 2016 19:16:17 +0000 Subject: [issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation In-Reply-To: <1478199350.04.0.93782925147.issue28602@psf.upfronthosting.co.za> Message-ID: <1478200577.6.0.0773640243729.issue28602@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I don't think timezones that satisfy the invariant expected by the default fromutc() is common enough that we need to provide special support for them. Note that in most cases it is the UTC to local conversion that is straightforward while Local to UTC is tricky, so the code that reduces a simple task to a harder one has questionable utility. ---------- assignee: -> belopolsky type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 15:21:02 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 03 Nov 2016 19:21:02 +0000 Subject: [issue28600] asyncio: Optimize loop.call_soon In-Reply-To: <1478197741.66.0.256167531264.issue28600@psf.upfronthosting.co.za> Message-ID: <1478200862.82.0.393507807865.issue28600@psf.upfronthosting.co.za> Changes by Yury Selivanov : Added file: http://bugs.python.org/file45341/call_soon3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 15:23:01 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Nov 2016 19:23:01 +0000 Subject: [issue10408] Denser dicts and linear probing In-Reply-To: <1289659692.61.0.467153013048.issue10408@psf.upfronthosting.co.za> Message-ID: <1478200981.7.0.666726762258.issue10408@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is the status of this issue in the light of compact dict implementation? ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 15:26:01 2016 From: report at bugs.python.org (Paul G) Date: Thu, 03 Nov 2016 19:26:01 +0000 Subject: [issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation In-Reply-To: <1478199350.04.0.93782925147.issue28602@psf.upfronthosting.co.za> Message-ID: <1478201161.54.0.761679089449.issue28602@psf.upfronthosting.co.za> Paul G added the comment: Of the `tzinfo` implementations provided by `python-dateutil`, `tzrange`, `tzstr` (GNU TZ strings), `tzwin` (Windows style time zones) and `tzlocal` all satisfy this condition. These are basically all implementations of default system time zone information. With current implementations `tzfile` and `tzical` also use the invariant algorithm, though theoretically there are edge cases where this will cause problems, and those should have their `fromutc()` adjusted. In any case, I can't think of a single actual downside to this change - all it does is preserve the original behavior of `fromutc()`. As currently implemented, the algorithm is simply wrong when `dst()` is affected by `fold`, and this change would have no effect on zones where `dst()` is *not* affected by fold. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 15:31:14 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 03 Nov 2016 19:31:14 +0000 Subject: [issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation In-Reply-To: <1478199350.04.0.93782925147.issue28602@psf.upfronthosting.co.za> Message-ID: <1478201474.74.0.11924809031.issue28602@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Paul G at Github: """ To be clear, I'm just saying that fromutc() goes from returning something meaningful (the correct date and time, with no indication of what side of the fold it's on) to something useless (an incorrect date and time) in the case where you're on the STD side of the divide. That change would restore the original behavior. For most of the tzinfo implementations I'm providing (tzrange, tzwin, etc), there's no problem with an invariant standard time offset, so I'd prefer to fall back on the default algorithm in those cases. Another advantage with using the standard algorithm as a starting point is that it all the type checking and such that's done in fromutc is done at that level, and I don't have to keep track of handling that. All that said, it's not a huge deal either way. """ Since it is not a big issue for you, I would rather not reopen this can of worms. It may be better to return a clearly erroneous result on fold-aware tzinfos to push the developers like you in the right direction. :-) After all, how much effort would it save for you in dateutil if you could reuse the base class fromutc? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 15:31:52 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Nov 2016 19:31:52 +0000 Subject: [issue28600] asyncio: Optimize loop.call_soon In-Reply-To: <1478197741.66.0.256167531264.issue28600@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I didn't review the patch, but I agree with the overall approach: expensive checks can be made only in debug mode. If people are concerned by the removal of the check by default, we should repeat everywhere in the doc that async programming is hard and that the debug mode saves a lot of time ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 15:43:23 2016 From: report at bugs.python.org (Paul G) Date: Thu, 03 Nov 2016 19:43:23 +0000 Subject: [issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation In-Reply-To: <1478199350.04.0.93782925147.issue28602@psf.upfronthosting.co.za> Message-ID: <1478202203.73.0.15338175617.issue28602@psf.upfronthosting.co.za> Paul G added the comment: > After all, how much effort would it save for you in dateutil if you could reuse the base class fromutc? Realistically, this saves me nothing since I have to re-implement it anyway in in all versions <= Python 3.6 (basically just the exact same algorithm with line 997 replaced with enfold(dt, fold=1) rather than dt.replace(fold=1), but I'd rather it fall back to the standard `fromutc()` in fold-aware versions of Python 3.6. That said, I don't see how it's a big can of worms to open. If you're going to provide `fromutc()` functionality, it should not be deliberately broken. As I mentioned above, I see no actual downside in having `fromutc()` actually work as advertised and as intended. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 15:49:50 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 03 Nov 2016 19:49:50 +0000 Subject: [issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation In-Reply-To: <1478199350.04.0.93782925147.issue28602@psf.upfronthosting.co.za> Message-ID: <1478202590.48.0.710445651127.issue28602@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > I can't think of a single actual downside to this change - all it does is preserve the original behavior of `fromutc()`. You've got me on the fence here. If what you are saying is correct, it would make sense to make this change and better do it before 3.6 is out, but it would take me some effort to convince myself that an implementation that reuses patched fromutc() is indeed correct. Why don't you implement tzrange.fromutc() in terms of say tzrange.simple_fromutc() which is your own patched version of tzinfo.fromutc(). If this passes your tests and is simpler than a straightforward fromutc() that does not have to look at tzinfo through the needle hole of utcoffset()/dst() pair but knows the internals of your timezone object, we can consider promoting your simple_fromutc() to default stdlib implementation. Alternatively, you can just convince Tim. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 15:52:19 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Nov 2016 19:52:19 +0000 Subject: [issue28600] asyncio: Optimize loop.call_soon In-Reply-To: <1478197741.66.0.256167531264.issue28600@psf.upfronthosting.co.za> Message-ID: <1478202739.66.0.949337210691.issue28600@psf.upfronthosting.co.za> Guido van Rossum added the comment: Patch 3 LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 16:16:39 2016 From: report at bugs.python.org (Ned Deily) Date: Thu, 03 Nov 2016 20:16:39 +0000 Subject: [issue28600] asyncio: Optimize loop.call_soon In-Reply-To: <1478197741.66.0.256167531264.issue28600@psf.upfronthosting.co.za> Message-ID: <1478204199.59.0.114139509187.issue28600@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 16:42:05 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Nov 2016 20:42:05 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1478205725.29.0.56958505861.issue23996@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- type: crash -> behavior versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 16:51:38 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Nov 2016 20:51:38 +0000 Subject: [issue28600] asyncio: Optimize loop.call_soon In-Reply-To: <1478197741.66.0.256167531264.issue28600@psf.upfronthosting.co.za> Message-ID: <1478206298.98.0.860094270281.issue28600@psf.upfronthosting.co.za> STINNER Victor added the comment: call_soon3.patch: LGTM. It enhances error messages (fix the method name) and should make asyncio faster. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 17:07:27 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 03 Nov 2016 21:07:27 +0000 Subject: [issue28600] asyncio: Optimize loop.call_soon In-Reply-To: <1478197741.66.0.256167531264.issue28600@psf.upfronthosting.co.za> Message-ID: <1478207247.29.0.0984424227167.issue28600@psf.upfronthosting.co.za> ???? ????????? added the comment: > haypo added the check because people called `.call_later()` with coroutine instead of callback very often maybe make dirty hack and check hasattr(callback, 'send') ? ---------- nosy: +mmarkk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 17:11:34 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 03 Nov 2016 21:11:34 +0000 Subject: [issue28600] asyncio: Optimize loop.call_soon In-Reply-To: <1478197741.66.0.256167531264.issue28600@psf.upfronthosting.co.za> Message-ID: <1478207494.95.0.37522739434.issue28600@psf.upfronthosting.co.za> Yury Selivanov added the comment: > LGTM Will commit this soon. > maybe make dirty hack and check hasattr(callback, 'send') ? If you schedule a coroutine object it will fail anyways, because it's not callable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 17:15:17 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Nov 2016 21:15:17 +0000 Subject: [issue26980] The path argument of asyncio.BaseEventLoop.create_unix_connection is not documented In-Reply-To: <1462743548.86.0.976035936413.issue26980@psf.upfronthosting.co.za> Message-ID: <1478207717.33.0.583717070907.issue26980@psf.upfronthosting.co.za> Guido van Rossum added the comment: LGTM, will apply shortly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 17:18:49 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Nov 2016 21:18:49 +0000 Subject: [issue26980] The path argument of asyncio.BaseEventLoop.create_unix_connection is not documented In-Reply-To: <1462743548.86.0.976035936413.issue26980@psf.upfronthosting.co.za> Message-ID: <20161103211847.7195.36366.D35C60A1@psf.io> Roundup Robot added the comment: New changeset b97b0201c2f4 by Guido van Rossum in branch '3.5': Issue #26980: Improve docs for create_unix_connection(). By Mariatta. https://hg.python.org/cpython/rev/b97b0201c2f4 New changeset ddbba4739ef4 by Guido van Rossum in branch '3.6': Issue #26980: Improve docs for create_unix_connection(). By Mariatta. (3.5->3.6) https://hg.python.org/cpython/rev/ddbba4739ef4 New changeset d6f4c1b864e6 by Guido van Rossum in branch 'default': Issue #26980: Improve docs for create_unix_connection(). By Mariatta. (3.6->3.7) https://hg.python.org/cpython/rev/d6f4c1b864e6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 17:19:32 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Nov 2016 21:19:32 +0000 Subject: [issue26980] The path argument of asyncio.BaseEventLoop.create_unix_connection is not documented In-Reply-To: <1462743548.86.0.976035936413.issue26980@psf.upfronthosting.co.za> Message-ID: <1478207972.54.0.840289950975.issue26980@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 17:22:14 2016 From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=) Date: Thu, 03 Nov 2016 21:22:14 +0000 Subject: [issue28603] traceback module can't format/print unhashable exceptions Message-ID: <1478208134.4.0.220857012408.issue28603@psf.upfronthosting.co.za> New submission from Andreas St?hrk: The traceback module tries to handle loops caused by an exception's __cause__ or __context__ attributes when printing tracebacks. To do so, it adds already seen exceptions to a set. Unfortunately, it doesn't handle unhashable exceptions: >>> class E(Exception): __hash__ = None ... >>> traceback.print_exception(E, E(), None) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.5/traceback.py", line 100, in print_exception type(value), value, tb, limit=limit).format(chain=chain): File "/usr/lib/python3.5/traceback.py", line 439, in __init__ _seen.add(exc_value) TypeError: unhashable type: 'E' CPython's internal exception printing pretty much does the same, except it ignores any exception while operating on the seen set (see https://hg.python.org/cpython/file/8ee4ed577c03/Python/pythonrun.c#l813 ff). Attached is a patch that makes the traceback module ignore TypeErrors while operating on the seen set. It also adds a (minimal) test. ---------- components: Library (Lib) files: unhashable_exceptions.diff keywords: patch messages: 280022 nosy: Trundle priority: normal severity: normal status: open title: traceback module can't format/print unhashable exceptions Added file: http://bugs.python.org/file45342/unhashable_exceptions.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 17:26:34 2016 From: report at bugs.python.org (Guillaume Pasquet (Etenil)) Date: Thu, 03 Nov 2016 21:26:34 +0000 Subject: [issue28604] Exception raised by python3.5 when using en_GB locale Message-ID: <1478208394.68.0.721396484587.issue28604@psf.upfronthosting.co.za> New submission from Guillaume Pasquet (Etenil): This issue was originally reported on Fedora's Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1391280 Description of problem: After switching the monetary locale to en_GB, python then raises an exception when calling locale.localeconv() Version-Release number of selected component (if applicable): 3.5.2-4.fc25 How reproducible: Every time Steps to Reproduce: 1. Write a python3 script or open the interactive interpreter with "python3" 2. Enter the following import locale locale.setlocale(locale.LC_MONETARY, 'en_GB') locale.localeconv() 3. Observe that python raises an encoding exception Actual results: Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.5/locale.py", line 110, in localeconv d = _localeconv() UnicodeDecodeError: 'locale' codec can't decode byte 0xa3 in position 0: Invalid or incomplete multibyte or wide character Expected results: A dictionary of locale data similar to (for en_US): {'mon_thousands_sep': ',', 'currency_symbol': '$', 'negative_sign': '-', 'p_sep_by_space': 0, 'frac_digits': 2, 'int_frac_digits': 2, 'decimal_point': '.', 'mon_decimal_point': '.', 'positive_sign': '', 'p_cs_precedes': 1, 'p_sign_posn': 1, 'mon_grouping': [3, 3, 0], 'n_cs_precedes': 1, 'n_sign_posn': 1, 'grouping': [3, 3, 0], 'thousands_sep': ',', 'int_curr_symbol': 'USD ', 'n_sep_by_space': 0} Note: This was reproduced on Linux Mint 18 (python 3.5.2), and also on Fedora with python 3.4 and python 3.6 (compiled). ---------- components: Interpreter Core messages: 280023 nosy: Guillaume Pasquet (Etenil) priority: normal severity: normal status: open title: Exception raised by python3.5 when using en_GB locale type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 17:36:25 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 03 Nov 2016 21:36:25 +0000 Subject: [issue28605] Remove mention of LTO when referencing --with-optimization in What's New Message-ID: <1478208985.26.0.595350965033.issue28605@psf.upfronthosting.co.za> New submission from Brett Cannon: The What's New doc for Python 3.6 mentions that --with-optimizations turns on LTO which is no longer true. ---------- assignee: brett.cannon components: Documentation messages: 280024 nosy: brett.cannon, gregory.p.smith priority: deferred blocker severity: normal status: open title: Remove mention of LTO when referencing --with-optimization in What's New versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 17:49:41 2016 From: report at bugs.python.org (Brian Smith) Date: Thu, 03 Nov 2016 21:49:41 +0000 Subject: [issue28606] Suspected bug in python optimizer with decorators Message-ID: <1478209781.37.0.548776330041.issue28606@psf.upfronthosting.co.za> New submission from Brian Smith: While using decorators in python 3.5.2, I ran into a surprising bug where the decorator sometimes lost context of the outer scope. The attached file demonstrates this problem. In this file, we have 2 decorators. They are identical, except that the first has one line (at line 11) commented out. When I run the program, I get the following output: dev:~/dev/route105/workspace/ir/play$ python bug.py Trying dec1: in dec1: {'tags': ['foo:1'], 'name': 'foo'} inside dec1.decorator: {'tags': {'tags': ['foo:1', ['name:subsystem']], 'name': 'foo'}, 'func': } Trying dec2: in dec2: {'tags': ['foo:1'], 'name': 'foo'} inside dec2.decorator: {'func': } Traceback (most recent call last): File "bug.py", line 42, in @dec2(name="foo", tags=["foo:1"]) File "bug.py", line 27, in decorator name = tags["name"] UnboundLocalError: local variable 'tags' referenced before assignment There are two issues here: 1) In dec1, the keyword argument 'name' exists in the outer scope, but not in the inner scope. For some reason, the keyword argument 'tags' exists in both scopes. 2) In dec2, Adding the line tags=tags["tags"] causes the keyword argument 'tags' to disappear from the inner scope. The only thing I could think of was a compiler or optimizer bug. ---------- components: Interpreter Core files: bug.py messages: 280025 nosy: Brian Smith priority: normal severity: normal status: open title: Suspected bug in python optimizer with decorators type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file45343/bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 18:11:04 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Nov 2016 22:11:04 +0000 Subject: [issue28600] asyncio: Optimize loop.call_soon In-Reply-To: <1478197741.66.0.256167531264.issue28600@psf.upfronthosting.co.za> Message-ID: <20161103221101.17076.8074.75E9CC11@psf.io> Roundup Robot added the comment: New changeset 128ffe3c3eb9 by Yury Selivanov in branch '3.5': Issue #28600: Optimize loop.call_soon(). https://hg.python.org/cpython/rev/128ffe3c3eb9 New changeset 4f570a612aec by Yury Selivanov in branch '3.6': Merge 3.5 (issue #28600) https://hg.python.org/cpython/rev/4f570a612aec New changeset 46c3eede41a6 by Yury Selivanov in branch 'default': Merge 3.6 (issue #28600) https://hg.python.org/cpython/rev/46c3eede41a6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 18:12:18 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 03 Nov 2016 22:12:18 +0000 Subject: [issue28600] asyncio: Optimize loop.call_soon In-Reply-To: <1478197741.66.0.256167531264.issue28600@psf.upfronthosting.co.za> Message-ID: <1478211138.95.0.906300359304.issue28600@psf.upfronthosting.co.za> Yury Selivanov added the comment: Guido, Andrew, thanks for reviews! I've fixed some unittests before committing the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 18:12:50 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 03 Nov 2016 22:12:50 +0000 Subject: [issue28600] asyncio: Optimize loop.call_soon In-Reply-To: <1478197741.66.0.256167531264.issue28600@psf.upfronthosting.co.za> Message-ID: <1478211170.22.0.962817263914.issue28600@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed type: -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 18:21:49 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Nov 2016 22:21:49 +0000 Subject: [issue28604] Exception raised by python3.5 when using en_GB locale In-Reply-To: <1478208394.68.0.721396484587.issue28604@psf.upfronthosting.co.za> Message-ID: <1478211709.6.0.881010105646.issue28604@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I suspect this issue is similar to issue25812. en_GB has non-ut8 encoding (likely iso8859-1). Currency symbol ? is encoded with this encoding as b'\xa3'. But Python tries to decode b'\xa3' with an encoding determined by other locale setting (LC_CTYPE). ---------- nosy: +lemburg, loewis, serhiy.storchaka versions: +Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 18:24:51 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 03 Nov 2016 22:24:51 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1478211891.23.0.997125186638.issue23996@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Looks like I forgot about this. My final fix still hasn't been applied, so the code in Py3.4+ is incorrect now. Left a question in code review ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 18:26:39 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Nov 2016 22:26:39 +0000 Subject: [issue28600] asyncio: Optimize loop.call_soon In-Reply-To: <1478211170.28.0.645416180274.issue28600@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: PS. I noticed there are a few lines different between the "upstream" repo and the 3.5 stdlib: + # Wake up the loop if the finalizer was called from + # a different thread. + self._write_to_self() On Thu, Nov 3, 2016 at 3:12 PM, Yury Selivanov wrote: > > Changes by Yury Selivanov : > > > ---------- > resolution: -> fixed > stage: commit review -> resolved > status: open -> closed > type: -> performance > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 18:29:46 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 03 Nov 2016 22:29:46 +0000 Subject: [issue28600] asyncio: Optimize loop.call_soon In-Reply-To: <1478197741.66.0.256167531264.issue28600@psf.upfronthosting.co.za> Message-ID: <1478212186.88.0.878524331558.issue28600@psf.upfronthosting.co.za> Yury Selivanov added the comment: + # Wake up the loop if the finalizer was called from + # a different thread. + self._write_to_self() Yeah, looks like shutdown_asyncgens somehow ended up in 3.5 branch (there's no harm in it being there). I'll sync the branches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 19:11:36 2016 From: report at bugs.python.org (Rasmus Villemoes) Date: Thu, 03 Nov 2016 23:11:36 +0000 Subject: [issue28607] C implementation of parts of copy.deepcopy Message-ID: <1478214696.15.0.845599612142.issue28607@psf.upfronthosting.co.za> New submission from Rasmus Villemoes: This is mostly an RFC patch. It compiles and passes the test suite. A somewhat silly microbenchmark such as ./python -m timeit -s 'import copy; x = dict([(str(x), x) for x in range(10000)]);' 'copy.deepcopy(x)' runs about 30x faster. In the (2.7 only) application which motivated this, the part of its initialization that does a lot of deepcopying drops from 11s to 3s. That it's so much less is presumably because the application holds on to the deepcopies, so there's much more allocation going on than in the microbenchmark, but I haven't investigated thoroughly. In any case, a 3.5x speedup is also nice. ---------- components: Library (Lib) files: deepcopy.patch keywords: patch messages: 280032 nosy: villemoes priority: normal severity: normal status: open title: C implementation of parts of copy.deepcopy type: performance versions: Python 3.7 Added file: http://bugs.python.org/file45344/deepcopy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 19:13:58 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 03 Nov 2016 23:13:58 +0000 Subject: [issue28607] C implementation of parts of copy.deepcopy In-Reply-To: <1478214696.15.0.845599612142.issue28607@psf.upfronthosting.co.za> Message-ID: <1478214838.7.0.952295198073.issue28607@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- components: +Extension Modules -Library (Lib) stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 19:21:19 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Nov 2016 23:21:19 +0000 Subject: [issue28605] Remove mention of LTO when referencing --with-optimization in What's New In-Reply-To: <1478208985.26.0.595350965033.issue28605@psf.upfronthosting.co.za> Message-ID: <20161103232116.31907.58675.2AA2BA64@psf.io> Roundup Robot added the comment: New changeset 1f750fff788e by Brett Cannon in branch '3.6': Issue #28605: Fix the help and What's New entry for --with-optimizations. https://hg.python.org/cpython/rev/1f750fff788e New changeset 4000de2dcd24 by Brett Cannon in branch 'default': Merge for issue #28605 https://hg.python.org/cpython/rev/4000de2dcd24 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 19:21:30 2016 From: report at bugs.python.org (Brett Cannon) Date: Thu, 03 Nov 2016 23:21:30 +0000 Subject: [issue28605] Remove mention of LTO when referencing --with-optimization in What's New In-Reply-To: <1478208985.26.0.595350965033.issue28605@psf.upfronthosting.co.za> Message-ID: <1478215290.38.0.95617615047.issue28605@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 19:31:04 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Nov 2016 23:31:04 +0000 Subject: [issue28605] Remove mention of LTO when referencing --with-optimization in What's New In-Reply-To: <1478208985.26.0.595350965033.issue28605@psf.upfronthosting.co.za> Message-ID: <1478215864.59.0.0431029128596.issue28605@psf.upfronthosting.co.za> STINNER Victor added the comment: LTO was excluded of --with-optimization by the issue #28032. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 20:08:13 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Nov 2016 00:08:13 +0000 Subject: [issue28606] Suspected bug in python optimizer with decorators In-Reply-To: <1478209781.37.0.548776330041.issue28606@psf.upfronthosting.co.za> Message-ID: <1478218093.92.0.102323531462.issue28606@psf.upfronthosting.co.za> R. David Murray added the comment: The statement in question causes the compiler to make 'tags' a local variable in the function, and thus you get the error on the assignment. See https://docs.python.org/3/faq/programming.html#id8. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 3 23:16:30 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 04 Nov 2016 03:16:30 +0000 Subject: [issue10408] Denser dicts and linear probing In-Reply-To: <1289659692.61.0.467153013048.issue10408@psf.upfronthosting.co.za> Message-ID: <1478229390.84.0.0839885093816.issue10408@psf.upfronthosting.co.za> INADA Naoki added the comment: > - make dicts denser by making the resize factor 2 instead of 4 for small dicts This had been implemented already when I start compact dict. > - improve cache locality on collisions by using linear probing set does this. But dict doesn't do it for now. In case of compact dict, liner probing only affects index table (dk_indices). dk_indices is small (64byte when dk_size==64). One or two cache line can contain whole dk_indices of small dicts. So performance benefit of linear probing will be smaller than previous dict implementation. I'll re-evaluate it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 02:50:57 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 04 Nov 2016 06:50:57 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478242257.91.0.557775363271.issue28563@psf.upfronthosting.co.za> Xiang Zhang added the comment: gettext_c2py.patch tries to avoid the problem. It still uses eval but manually parse the expression using tokens extracted from gettext. Tests are passed. But there is still a problem. Both patched and original c2py fail to handle nested ternary operator. They respect the right associative but fails to handle expressions like '1?2?3:4:5'. ---------- keywords: +patch Added file: http://bugs.python.org/file45345/gettext_c2py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 03:35:42 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Nov 2016 07:35:42 +0000 Subject: [issue28088] Document Transport.set_protocol and get_protocol In-Reply-To: <1475369173.63.0.247466795846.issue28088@psf.upfronthosting.co.za> Message-ID: <20161104073538.7662.61338.7AE381BF@psf.io> Roundup Robot added the comment: New changeset 3f5af4a25995 by INADA Naoki in branch '3.5': Issue #28088: Document Transport.set_protocol and get_protocol https://hg.python.org/cpython/rev/3f5af4a25995 New changeset a5e52b7be71f by INADA Naoki in branch '3.6': Issue #28088: Document Transport.set_protocol and get_protocol. https://hg.python.org/cpython/rev/a5e52b7be71f New changeset a0299574a733 by INADA Naoki in branch 'default': Issue #28088: Document Transport.set_protocol and get_protocol. https://hg.python.org/cpython/rev/a0299574a733 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 03:36:18 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 04 Nov 2016 07:36:18 +0000 Subject: [issue28088] Document Transport.set_protocol and get_protocol In-Reply-To: <1475369173.63.0.247466795846.issue28088@psf.upfronthosting.co.za> Message-ID: <1478244978.74.0.933602434224.issue28088@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 03:50:04 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 04 Nov 2016 07:50:04 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478245804.64.0.108429227526.issue28580@psf.upfronthosting.co.za> INADA Naoki added the comment: LGTM. I'll commit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 03:54:44 2016 From: report at bugs.python.org (Ram Rachum) Date: Fri, 04 Nov 2016 07:54:44 +0000 Subject: [issue28608] Support creating hardlink using `pathlib` Message-ID: <1478246084.59.0.89358913642.issue28608@psf.upfronthosting.co.za> Changes by Ram Rachum : ---------- components: Library (Lib) nosy: cool-RR priority: normal severity: normal status: open title: Support creating hardlink using `pathlib` type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 03:59:26 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Nov 2016 07:59:26 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <20161104075923.25505.62989.876398E5@psf.io> Roundup Robot added the comment: New changeset 3904194d06e6 by INADA Naoki in branch 'default': Issue #28580: Optimize iterating split table values. https://hg.python.org/cpython/rev/3904194d06e6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 04:00:15 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 04 Nov 2016 08:00:15 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478246415.97.0.686373420959.issue28580@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 04:02:59 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 04 Nov 2016 08:02:59 +0000 Subject: [issue28580] Optimize iterating split table values In-Reply-To: <1478021108.69.0.490757358279.issue28580@psf.upfronthosting.co.za> Message-ID: <1478246579.17.0.00266881991436.issue28580@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 04:06:55 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 04 Nov 2016 08:06:55 +0000 Subject: [issue28199] Compact dict resizing is doing too much work In-Reply-To: <1474236829.43.0.744002065698.issue28199@psf.upfronthosting.co.za> Message-ID: <1478246815.4.0.796783236353.issue28199@psf.upfronthosting.co.za> Xiang Zhang added the comment: #28580 and #28583 are resolved now. I think dictresize4 can be recommited now. ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 04:15:24 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 04 Nov 2016 08:15:24 +0000 Subject: [issue26931] android: test_distutils fails In-Reply-To: <1462285501.44.0.0195995288955.issue26931@psf.upfronthosting.co.za> Message-ID: <1478247324.8.0.371471544852.issue26931@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The problem raised in msg264946 has been fixed at changeset 15835311b5e6. This new cross-compiled-skip_2.patch is not specific to Android and fixes test_distutils when the executables used to build the interpreter do not exist on the platform where the test is run. The patch also does: * Fix a bug in test_run of Lib/distutils/tests/test_build_clib.py that was using the values of the 'compiler.executables' dictionary instead of the attributes of 'compiler'. * Removes test_get_python_inc from test_sysconfig.py as Python.h may not be installed on systems where extension modules are not expected to be built (BTW the comment in the test points out: "This is not much of a test" :). With this patch, test_distutils runs fine on the Android emulator. ---------- components: +Tests -Cross-Build, Library (Lib) dependencies: -add the 'is_android' attribute to test.support stage: -> patch review versions: +Python 3.7 Added file: http://bugs.python.org/file45346/cross-compiled-skip_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 06:50:41 2016 From: report at bugs.python.org (Charalampos Stratakis) Date: Fri, 04 Nov 2016 10:50:41 +0000 Subject: [issue28604] Exception raised by python3.5 when using en_GB locale In-Reply-To: <1478208394.68.0.721396484587.issue28604@psf.upfronthosting.co.za> Message-ID: <1478256641.0.0.88579530005.issue28604@psf.upfronthosting.co.za> Changes by Charalampos Stratakis : ---------- nosy: +cstratak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 07:01:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Nov 2016 11:01:12 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1478257272.78.0.159530279008.issue23996@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a test that passed with current code but will fail with the patch. I don't know whether it make much sense. If yes, then perhaps aiter_wrapper_iternext needs the same workaround as other invocations of PyErr_SetObject(PyExc_StopIteration, ...). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 07:34:26 2016 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 04 Nov 2016 11:34:26 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1478259266.69.0.393102620221.issue23996@psf.upfronthosting.co.za> Yury Selivanov added the comment: Serhiy, I think you forgot to attach the patch. aiter_wrapper shouldn't ever receive tuples, so it should be fine with PyErr_SetObject. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 07:59:27 2016 From: report at bugs.python.org (Evan) Date: Fri, 04 Nov 2016 11:59:27 +0000 Subject: [issue28595] shlex.shlex should not augment wordchars In-Reply-To: <1478166136.94.0.995190174918.issue28595@psf.upfronthosting.co.za> Message-ID: <1478260767.18.0.542350423704.issue28595@psf.upfronthosting.co.za> Changes by Evan : ---------- title: shlex.split should not augment wordchars -> shlex.shlex should not augment wordchars _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 08:16:44 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Nov 2016 12:16:44 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1478261804.15.0.0845233316063.issue23996@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file45347/test_stopiteration_tuple_value.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 08:30:29 2016 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 04 Nov 2016 12:30:29 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1478262629.31.0.729920306265.issue23996@psf.upfronthosting.co.za> Yury Selivanov added the comment: > No, this cannot be tested from the Python level. Stefan, could you please upload a C program that showcases the bug you're trying to fix? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 10:37:52 2016 From: report at bugs.python.org (Charlie Proctor) Date: Fri, 04 Nov 2016 14:37:52 +0000 Subject: [issue19899] No test for thread.interrupt_main() In-Reply-To: <1386256832.82.0.17906161504.issue19899@psf.upfronthosting.co.za> Message-ID: <1478270272.11.0.0340125195776.issue19899@psf.upfronthosting.co.za> Charlie Proctor added the comment: Found this through the "Random Issue" button -- I've uploaded a simple test case for thread.interrupt_main(). This is my first patch :) So let me know if there's something else I should do and I'd love to hear any feedback... ---------- keywords: +patch nosy: +charlie.proctor Added file: http://bugs.python.org/file45348/test_interrupt_main.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 11:05:47 2016 From: report at bugs.python.org (Carl Ekerot) Date: Fri, 04 Nov 2016 15:05:47 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478271947.28.0.595157506036.issue28563@psf.upfronthosting.co.za> Carl Ekerot added the comment: It doesn't solve the case when an identifier or number is used as a function: >>> import os >>> gettext.c2py("n()")(lambda: os.system("sh")) $ 0 >>> gettext.c2py("1()")(0) Traceback (most recent call last): File "", line 1, in File "", line 1, in TypeError: 'int' object is not callable This is more of an unintended behavior than a security issue. Xiang Zhang: I've created a patch based on yours which handles the above case. I've also added a corresponding test case. Imo it would be even better if we could avoid eval. One possible (and safe) way would be to construct a safe subset of Python using the ast module. This would however still require that the C-style syntax is translated to Python. As you mention, there are issues parsing and translating nested ternary operators, and I doubt it will be possible to cover all cases with the regex replace utilized today. ---------- Added file: http://bugs.python.org/file45349/gettext_c2py_func.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 11:07:12 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 04 Nov 2016 15:07:12 +0000 Subject: [issue28584] ICC compiler check is too permissive In-Reply-To: <1478035366.63.0.90573648053.issue28584@psf.upfronthosting.co.za> Message-ID: <1478272032.53.0.0869532372491.issue28584@psf.upfronthosting.co.za> Josh Rosenberg added the comment: It's probably bad form, but I've seen people set CC to name/path to compiler followed by switches, e.g.: export CC='gcc -march=native -O3' or the like (usually because they want to keep the build tool's default CFLAGS, and setting CFLAGS causes them to be replaced, not supplemented). basename seems to strip the leading path components, but if someone shoved in other switches, they aren't removed, so if they happen to have "icc" in them, this would still have issues. Perhaps a basename followed by splitting on whitespace and only keeping the first component? Not a configure expert, not sure what's possible. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 11:07:30 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Nov 2016 15:07:30 +0000 Subject: [issue19899] No test for thread.interrupt_main() In-Reply-To: <1386256832.82.0.17906161504.issue19899@psf.upfronthosting.co.za> Message-ID: <1478272050.64.0.466213639478.issue19899@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Charlie. You should use addCleanup to handle the resetting of the state, so that it gets cleaned up no matter what happens in the test. IMO the comments should either be omitted or be more descriptive about what exactly is being tested. For example "If this timer goes off, then interrupt_main did not work, so fail the test". I don't really understand what exactly is being tested in the body...it looks like two tests, one for calling it from the main thread (I suppose it makes sense to test that, but I don't know what behavior is expedted) and one from a subthread, which I would think was the real test. I would expect the main thread to be catching KeyboardInterrupt, based on the description of interrupt_main, so I'm not even sure what the sigalrm is for. Can you explain? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 11:16:22 2016 From: report at bugs.python.org (Gabriel Devenyi) Date: Fri, 04 Nov 2016 15:16:22 +0000 Subject: [issue24564] shutil.copytree fails when copying NFS to NFS In-Reply-To: <1436040350.32.0.650425735541.issue24564@psf.upfronthosting.co.za> Message-ID: <1478272582.86.0.129791573919.issue24564@psf.upfronthosting.co.za> Gabriel Devenyi added the comment: I'm running into this issue with python 3.5 and a ZFS-backed NFS4 mount. Strace of a setuptools install: chmod("/opt/quarantine/pydpiper/2.0/build/lib/python3.4/site-packages/pydpiper-2.0-py3.4.egg", 0644) = 0 listxattr("dist/pydpiper-2.0-py3.4.egg", "system.nfs4_acl\0", 256) = 16 getxattr("dist/pydpiper-2.0-py3.4.egg", "system.nfs4_acl", "\x00\x00\x00\x03\x00\x00\x00\x00\x00\x00\x00\x00\x00\x16\x01\x87\x00\x00\x00\x06OWNER@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x12\x00\x81\x00\x00\x00\x06GROUP@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x12\x00\x81\x00\x00\x00\x09EVERYONE@\x00\x00", 128) = 80 setxattr("/opt/quarantine/pydpiper/2.0/build/lib/python3.4/site-packages/pydpiper-2.0-py3.4.egg", "system.nfs4_acl", "\x00\x00\x00\x03\x00\x00\x00\x00\x00\x00\x00\x00\x00\x16\x01\x87\x00\x00\x00\x06OWNER@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x12\x00\x81\x00\x00\x00\x06GROUP@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x12\x00\x81\x00\x00\x00\x09EVERYONE@\x00\x00", 80, 0) = -1 EIO (Input/output error) stat("/tmp/easy_install-41z79x8r", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 openat(AT_FDCWD, "/tmp/easy_install-41z79x8r", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4 getdents(4, /* 2 entries */, 32768) = 48 getdents(4, /* 0 entries */, 32768) = 0 close(4) = 0 rmdir("/tmp/easy_install-41z79x8r") = 0 write(2, "error: [Errno 5] Input/output er"..., 125error: [Errno 5] Input/output error: '/opt/quarantine/pydpiper/2.0/build/lib/python3.4/site-packages/pydpiper-2.0-py3.4.egg' ) = 125 ---------- nosy: +Gabriel Devenyi versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 11:19:23 2016 From: report at bugs.python.org (Reuben Thomas) Date: Fri, 04 Nov 2016 15:19:23 +0000 Subject: [issue28609] argparse claims '*' positional argument is required in error output Message-ID: <1478272763.12.0.609109547521.issue28609@psf.upfronthosting.co.za> New submission from Reuben Thomas: In Python 3.5.2, with a positional argument with nargs='*', running the program with no arguments gives an error like this: usage: caffeinate [-h] [-V] COMMAND [ARGUMENT [ARGUMENT ...]] caffeinate: error: the following arguments are required: COMMAND, ARGUMENT Here it is clear from the (correct, though redundant) syntax that "ARGUMENT" is optional, but the error message claims, incorrectly, that it is required. The add_argument calls used were: parser.add_argument('COMMAND', help='command to run') parser.add_argument('ARGUMENT', nargs='*', help='arguments to COMMAND') parser.add_argument('-V', '--version', action='version', version=PROGRAM_NAME + ' ' + VERSION) ---------- components: Library (Lib) messages: 280052 nosy: rrt priority: normal severity: normal status: open title: argparse claims '*' positional argument is required in error output type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 11:47:23 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 04 Nov 2016 15:47:23 +0000 Subject: [issue26926] test_io large file test failure on 32 bits Android platforms In-Reply-To: <1462283737.14.0.888848894928.issue26926@psf.upfronthosting.co.za> Message-ID: <1478274443.77.0.0752638411169.issue26926@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The tests are run on an ext4 file system. test_large_file_ops does not fail on the x86_64 and arm64 (aka aarch64) Android 64 bits platforms. test_large_file_ops still fails on x86 with the latest Android API level 24 (i.e. the latest released libc). FWIW, the second item in https://android.googlesource.com/platform/bionic.git/#32_bit-ABI-bugs may explain why there is still no large file support on Android 32 bits platforms. HAVE_LARGEFILE_SUPPORT cannot be used to skip the test since it is also undefined on the Android 64 bits platforms and on linux x86_64. This new patch is not specific to Android and uses the same method as the one used in test_mmap to skip the test on platforms that do not support large files. ---------- assignee: -> xdegaye components: +Tests -Cross-Build, Library (Lib) dependencies: -add the 'is_android' attribute to test.support stage: -> patch review title: Large files are not supported on Android -> test_io large file test failure on 32 bits Android platforms versions: +Python 3.7 Added file: http://bugs.python.org/file45350/skip-large-file_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 12:02:42 2016 From: report at bugs.python.org (Charlie Proctor) Date: Fri, 04 Nov 2016 16:02:42 +0000 Subject: [issue19899] No test for thread.interrupt_main() In-Reply-To: <1386256832.82.0.17906161504.issue19899@psf.upfronthosting.co.za> Message-ID: <1478275362.96.0.154533839276.issue19899@psf.upfronthosting.co.za> Charlie Proctor added the comment: Thanks for the feedback David! I've posted a revised patch with more descriptive comments and the restoration code moved into addCleanup. As described in the comments, in the context of this test, the "main" thread is the one running the test suite... so rather than self.assertRaises(KeyboardInterrupt), I assert that appropriate SIGINTS are received. The lock is used to facilitate these assertions, since signals are asynchronous. ---------- Added file: http://bugs.python.org/file45351/test_interrupt_main.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 12:06:00 2016 From: report at bugs.python.org (Charlie Proctor) Date: Fri, 04 Nov 2016 16:06:00 +0000 Subject: [issue19899] No test for thread.interrupt_main() In-Reply-To: <1386256832.82.0.17906161504.issue19899@psf.upfronthosting.co.za> Message-ID: <1478275560.84.0.851793491332.issue19899@psf.upfronthosting.co.za> Charlie Proctor added the comment: To clarify further, the SIGALRM handler catches the timeout sent by the ITIMER_REAL... whereas the SIGINT handler catches the interrupt_main() signals. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 12:18:28 2016 From: report at bugs.python.org (Pinku Surana) Date: Fri, 04 Nov 2016 16:18:28 +0000 Subject: [issue28610] Provide PDB hook to customize how to find source files Message-ID: <1478276308.14.0.744834650748.issue28610@psf.upfronthosting.co.za> New submission from Pinku Surana: I am using Python as a hosted scripting runtime for a product. All the user scripts are stored in a database. I use "compile" and "exec" to run the scripts. I'd like to use PDB to debug scripts. Unfortunately, PDB makes a call to linecache, which calls tokenize.open assuming the code is in a file. I'd like to pass in a function that takes a filename and returns the source code in a string. At the very least, moving the call to "linecache.getline" into a separate method in PDB ("self.get_lines") would allow me to override that method with my own. ---------- components: Demos and Tools, Library (Lib) messages: 280056 nosy: Pinku Surana priority: normal severity: normal status: open title: Provide PDB hook to customize how to find source files type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 12:27:01 2016 From: report at bugs.python.org (Mallow) Date: Fri, 04 Nov 2016 16:27:01 +0000 Subject: [issue28611] Syntax error when using raw strings ending with a backslash. Message-ID: <1478276821.6.0.581730112081.issue28611@psf.upfronthosting.co.za> New submission from Mallow: I'm not sure if this is a bug or not but I've noticed a behavior that seems incorrect. The use of raw strings, when used for directory paths ending with a back slash (/) creates a syntax error. How to reproduce ---------------- Code: print (r"C:\path\to\a\dir\" + "file.ext") Result: Syntax Error Why is this an error, (in my perspective) ----------------------------------------- One could attempt to be storing the directory information in a variable to write to file that is composed later but would be forced to use a cumbersome normal string having to escape all backslashes. Example: outputdir = r"C:\path\to\dir\" filename = r"file.ext" writetofile(outputdir + filename) Argument for why the workaround is not a fix -------------------------------------------- I believe I read somewhere that python is smart enough to deal with filepaths correctly on linux and windows if you were to switch the slashes. So technically outputdir = r"C:/path/to/dir/" would work however this is hard on the workflow since I find it easier to copy and paste paths within windows. I guess it wouldn't be too unreasonable to do something like: r"C:\path\to\dir/" ---------- files: Capture.PNG messages: 280057 nosy: princemallow priority: normal severity: normal status: open title: Syntax error when using raw strings ending with a backslash. type: compile error versions: Python 3.5 Added file: http://bugs.python.org/file45352/Capture.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 12:35:45 2016 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 04 Nov 2016 16:35:45 +0000 Subject: [issue28611] Syntax error when using raw strings ending with a backslash. In-Reply-To: <1478276821.6.0.581730112081.issue28611@psf.upfronthosting.co.za> Message-ID: <1478277345.11.0.797220049021.issue28611@psf.upfronthosting.co.za> Emanuel Barry added the comment: That's how strings work, unfortunately. You can't end any string (raw or not) with an odd number of backslashes. You could do the following to get around this limitation: >>> r"C:\Folder" "\\" 'C:\\Folder\\' As a side note, please don't upload screenshots if what you're capturing consists only of text (you can paste it directly in your message). This makes it impossible to copy-paste input in the interpreter to try to replicate the issue, and makes it harder/impossible for the blind and visually-impaired to contribute. Thanks! ---------- nosy: +ebarry resolution: -> not a bug stage: -> resolved status: open -> closed type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 12:43:37 2016 From: report at bugs.python.org (Ned Deily) Date: Fri, 04 Nov 2016 16:43:37 +0000 Subject: [issue28611] Syntax error when using raw strings ending with a backslash. In-Reply-To: <1478276821.6.0.581730112081.issue28611@psf.upfronthosting.co.za> Message-ID: <1478277817.02.0.486750270114.issue28611@psf.upfronthosting.co.za> Ned Deily added the comment: To expand a bit, the "Python Language Reference" section on "String and Byte Literals" explains: "Even in a raw literal, quotes can be escaped with a backslash, but the backslash remains in the result; for example, r"\"" is a valid string literal consisting of two characters: a backslash and a double quote; r"\" is not a valid string literal (even a raw string cannot end in an odd number of backslashes). Specifically, a raw literal cannot end in a single backslash (since the backslash would escape the following quote character). Note also that a single backslash followed by a newline is interpreted as those two characters as part of the literal, not as a line continuation." https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals Because of the difference between Posix- and Windows-style paths and the potential conflicts in the use of `\` (such as you ran into), Python provides the older os.path and the newer pathlib modules, both of which allow you to deal with path manipulations in a more platform-independent manner. https://docs.python.org/dev/library/pathlib.html https://docs.python.org/dev/library/os.path.html ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 12:46:27 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Nov 2016 16:46:27 +0000 Subject: [issue19899] No test for thread.interrupt_main() In-Reply-To: <1386256832.82.0.17906161504.issue19899@psf.upfronthosting.co.za> Message-ID: <1478277987.71.0.840971313386.issue19899@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, of course. The revised comments look good. I think I'd rather see the two cases tested separately, but if they are kept as one another comment ("lock was successfully released; reacquire the lock and test that it also works from a sub-thread") might be helpful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 13:02:34 2016 From: report at bugs.python.org (Jim Jewett) Date: Fri, 04 Nov 2016 17:02:34 +0000 Subject: [issue28612] str.translate needs a mapping example Message-ID: <1478278954.92.0.793705359912.issue28612@psf.upfronthosting.co.za> New submission from Jim Jewett: One commonly needed string transformation is stripping out certain characters (or only keeping certain characters). This is common enough that it might be worth a dedicated method, except, that, as Stephen J. Turnbull wrote in https://mail.python.org/pipermail/python-ideas/2016-November/043501.html """ So really translate with defaultdict is a specialized loop that marries an algorithmic body (which could do things like look up the original script or other character properties to decide on the replacement for the generic case) with a (usually "small") table of exceptions. That seems like inspired design to me. """ Alas, while inspired, it isn't obvious to someone who isn't yet used to the power of python custom classes. The documentation (such as https://docs.python.org/3/library/stdtypes.html?highlight=translate#str.translate ) should include such an example. One possible example would be a defaultdict that says to discard any characters except lower case ASCII lettersI. ---------- assignee: docs at python components: Documentation keywords: easy messages: 280061 nosy: Jim.Jewett, docs at python priority: normal severity: normal stage: needs patch status: open title: str.translate needs a mapping example type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 14:06:42 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Nov 2016 18:06:42 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1478282802.22.0.341100702312.issue23996@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yet one special case -- if asynchronous iterator in aiter_wrapper is an instance of StopIteration. Proposed patch adds the function _PyGen_SetStopIterationValue() that raises StopIteration with correctly wrapped value (exception is normalized only if needed) and replaces 4 code duplications with it. The patch also includes Yury's variant of Stefan's patch and additional tests. ---------- stage: test needed -> patch review Added file: http://bugs.python.org/file45353/gen_set_stopiteration_value.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 14:20:23 2016 From: report at bugs.python.org (Jim Jewett) Date: Fri, 04 Nov 2016 18:20:23 +0000 Subject: [issue28612] str.translate needs a mapping example In-Reply-To: <1478278954.92.0.793705359912.issue28612@psf.upfronthosting.co.za> Message-ID: <1478283623.98.0.774355713545.issue28612@psf.upfronthosting.co.za> Jim Jewett added the comment: https://mail.python.org/pipermail/python-ideas/2016-November/043539.html by Chris Barker points out that a custom object (which doesn't ever store the missing "keys") may be better still... though I'm not sure it is better enough to complicate the docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 14:28:00 2016 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 04 Nov 2016 18:28:00 +0000 Subject: [issue28613] Make get_event_loop() return the current loop if called from coroutines Message-ID: <1478284080.22.0.444495685289.issue28613@psf.upfronthosting.co.za> New submission from Yury Selivanov: Proxy for https://github.com/python/asyncio/pull/452 ---------- assignee: yselivanov components: asyncio messages: 280064 nosy: gvanrossum, yselivanov priority: normal severity: normal stage: resolved status: open title: Make get_event_loop() return the current loop if called from coroutines type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 14:28:09 2016 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 04 Nov 2016 18:28:09 +0000 Subject: [issue28613] Make get_event_loop() return the current loop if called from coroutines In-Reply-To: <1478284080.22.0.444495685289.issue28613@psf.upfronthosting.co.za> Message-ID: <1478284089.91.0.140558027729.issue28613@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 14:30:51 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Nov 2016 18:30:51 +0000 Subject: [issue28613] Make get_event_loop() return the current loop if called from coroutines In-Reply-To: <1478284080.22.0.444495685289.issue28613@psf.upfronthosting.co.za> Message-ID: <20161104183048.22241.26094.8312EFB3@psf.io> Roundup Robot added the comment: New changeset aa37f3859462 by Yury Selivanov in branch '3.5': Issue #28613: Fix get_event_loop() to return the current loop https://hg.python.org/cpython/rev/aa37f3859462 New changeset 1473b9a17a91 by Yury Selivanov in branch '3.6': Merge 3.5 (issue #28613) https://hg.python.org/cpython/rev/1473b9a17a91 New changeset af4ac4e4b188 by Yury Selivanov in branch 'default': Merge 3.6 (issue #28613) https://hg.python.org/cpython/rev/af4ac4e4b188 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 14:39:23 2016 From: report at bugs.python.org (Charlie Proctor) Date: Fri, 04 Nov 2016 18:39:23 +0000 Subject: [issue19899] No test for thread.interrupt_main() In-Reply-To: <1386256832.82.0.17906161504.issue19899@psf.upfronthosting.co.za> Message-ID: <1478284763.56.0.149370180363.issue19899@psf.upfronthosting.co.za> Charlie Proctor added the comment: I broke the two cases (interrupt_main from test thread and from sub-thread) into two separate tests, using an "expect_sigint" helper. Let me know what you think -- thanks! ---------- Added file: http://bugs.python.org/file45354/test_interrupt_main.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 14:52:08 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Nov 2016 18:52:08 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1478285528.72.0.949930459072.issue23996@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added comments. ---------- Added file: http://bugs.python.org/file45355/gen_set_stopiteration_value_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 15:04:44 2016 From: report at bugs.python.org (airwin) Date: Fri, 04 Nov 2016 19:04:44 +0000 Subject: [issue28614] Slice limit documentation is incorrect Message-ID: <1478286284.13.0.895417928613.issue28614@psf.upfronthosting.co.za> New submission from airwin: Note 5 (at for Python 2 and at for Python 3) concerning s[i:j:k] (the slice of s from i to j with step k) contains the following two sentences: "The slice of s from i to j with step k is defined as the sequence of items with index x = i + n*k such that 0 <= n < (j-i)/k. In other words, the indices are i, i+k, i+2*k, i+3*k and so on, stopping when j is reached (but never including j)." That limit, "(j-i)/k" is demonstrably wrong when the integer division has a non-zero remainder. For example, for i=0, j=3, and k=2, n must be less than int(3/2) = 1 (i.e., the slice only has one element) according to that limit, but in fact the slice has two elements in agreement with the second sentence and which can be seen from the following python (2 or 3) code example: >>> x = [0,1,2,3,4,5] >>> x[0:3:2] [0, 2] The following Python result is also instructive for negative steps. >>> y=[5,4,3,2,1,0] >>> y[-1:-4:-2] [0, 2] For this case as well the result is consistent with the second sentence of the documentation but inconsistent with the first sentence since according to that limit = int((len-4 - (len-1))/-2) = int(3/2) = 1 implying only one element in the slice in contradiction to the above result. Therefore, I suggest removing the incorrect mathematical limit "(j-i)/k" from note 5 by replacing the above two sentences as follows: "The slice of s from i to j with positive or negative step k is defined as the sequence of items with index x = i + n*k such that the indices are i, i+k, i+2*k, i+3*k and so on, stopping when j is reached (but never including j)." Alternatively, one could replace the current incorrect limit by the correct mathmatical expression. My guess is the limit should be "(j-i)/k" when there is a zero remainder for that division, and "(j-i)/k + 1" when there is a non-zero remainder. That limit works for the above two examples, but I don't know how to prove that in general for this integer limit case. Furthermore, even if somebody else can provide that proof, I still think the above single sentence documents the slice limits exactly, is simpler, and therefore is preferred. N.B. I am formally reporting this issue as a Python 3 bug but as shown above the same two sentences occur in the Python 2 documentation so when this bug is fixed for the Python 3 documentation it should also be consistently fixed for Python 2. ---------- assignee: docs at python components: Documentation messages: 280068 nosy: airwin, docs at python priority: normal severity: normal status: open title: Slice limit documentation is incorrect versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 15:09:32 2016 From: report at bugs.python.org (David.Johnston) Date: Fri, 04 Nov 2016 19:09:32 +0000 Subject: [issue28615] Document clarification: Section 5.4 Complex Number Message-ID: <1478286572.26.0.816720776987.issue28615@psf.upfronthosting.co.za> New submission from David.Johnston: Section 5.4: Numeric Types Second paragraph reads: Appending 'j' or 'J' to a numeric literal yields a complex number with a zero real part. After reading the table following the paragraphs I thought that the sentence needed revised to the following: Appending 'j' or 'J' to a numeric literal yields a complex number with a zero imaginary part. Table in same section for complex(re, im) indicates possible required doc change. But after testing the use of J and complex I see there is no error here, but perhaps a little better clarification would help others reading the information without access to an editor to test against. ---------- assignee: docs at python components: Documentation messages: 280069 nosy: David.Johnston, docs at python priority: normal severity: normal status: open title: Document clarification: Section 5.4 Complex Number _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 15:12:27 2016 From: report at bugs.python.org (Chris Barker) Date: Fri, 04 Nov 2016 19:12:27 +0000 Subject: [issue28612] str.translate needs a mapping example In-Reply-To: <1478278954.92.0.793705359912.issue28612@psf.upfronthosting.co.za> Message-ID: <1478286747.38.0.731751607278.issue28612@psf.upfronthosting.co.za> Chris Barker added the comment: Agreed: the custom dict type would be nice for a recipe or blog post or... but not for the docs. I'll note that the other trick to this recipe is that you need to know to use lambda to make a "None factory" for defaultdict -- though maybe that's a ToDo for the defaultdict docs... ---------- nosy: +ChrisBarker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 15:17:58 2016 From: report at bugs.python.org (Anish Tambe) Date: Fri, 04 Nov 2016 19:17:58 +0000 Subject: [issue28616] sys.version_info.releaselevel - 'final' or 'release' Message-ID: <1478287078.75.0.465203808408.issue28616@psf.upfronthosting.co.za> New submission from Anish Tambe: help(sys.version_info) suggests releaselevel is one among - | releaselevel | 'alpha', 'beta', 'candidate', or 'release' Notice that the last one is 'release'. But the implementation says current value is - 'final'. $ python Python 2.7.12 (default, Oct 11 2016, 05:24:00) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.version_info sys.version_info(major=2, minor=7, micro=12, releaselevel='final', serial=0) >>> $ python3 Python 3.5.2 (default, Oct 11 2016, 05:05:28) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.version_info sys.version_info(major=3, minor=5, micro=2, releaselevel='final', serial=0) >>> The documentation (https://docs.python.org/3/library/sys.html#sys.version_info or Doc/library/sys.rst) agrees with the implementation. The tests also agree with the implementation. grep for releaselevel and see - Lib/test/test_sys.py:504: self.assertIn(vi.releaselevel, ("alpha", "beta", "candidate", "final")) Hence, submitting a patch to change the help documentaion to reflect the correct value for releaselevel. [Motivation - I tried to print a warning to the user in case my app was not being run on a final release, and I tried to do that by equating releaselevel with 'release' as the help suggested.] ---------- assignee: docs at python components: Documentation files: releaselevel.patch keywords: patch messages: 280071 nosy: anish.tambe, docs at python priority: normal severity: normal status: open title: sys.version_info.releaselevel - 'final' or 'release' versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45356/releaselevel.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 15:22:12 2016 From: report at bugs.python.org (Charlie Proctor) Date: Fri, 04 Nov 2016 19:22:12 +0000 Subject: [issue28609] argparse claims '*' positional argument is required in error output In-Reply-To: <1478272763.12.0.609109547521.issue28609@psf.upfronthosting.co.za> Message-ID: <1478287332.26.0.455633274435.issue28609@psf.upfronthosting.co.za> Charlie Proctor added the comment: I agree that the message is slightly misleading. Uploading one possible solution. I'm sure someone more familiar with the library might have a better approach... ---------- keywords: +patch nosy: +charlie.proctor Added file: http://bugs.python.org/file45357/optional_arguments.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 15:29:16 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Nov 2016 19:29:16 +0000 Subject: [issue28614] Slice limit documentation is incorrect In-Reply-To: <1478286284.13.0.895417928613.issue28614@psf.upfronthosting.co.za> Message-ID: <1478287756.92.0.145666388396.issue28614@psf.upfronthosting.co.za> R. David Murray added the comment: My guess is that the formula is not using integer division. There are two elements, n=0, and n=1. 1 is less than 1.5. In python2 it would be a natural assumption that that formula was referring to python2 division, and that should be clarified if I'm right. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 15:34:18 2016 From: report at bugs.python.org (Reuben Thomas) Date: Fri, 04 Nov 2016 19:34:18 +0000 Subject: [issue28609] argparse claims '*' positional argument is required in error output In-Reply-To: <1478272763.12.0.609109547521.issue28609@psf.upfronthosting.co.za> Message-ID: <1478288058.29.0.927966638087.issue28609@psf.upfronthosting.co.za> Reuben Thomas added the comment: Thanks very much for this. It would be great if the redundancy I referred to in the usage message could also be removed, so that instead of "[ARGUMENT [ARGUMENT ...]]" it just said "[ARGUMENT ...]". (Similarly, for a '+' argument, it could say just ARGUMENT ... ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 15:38:57 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Nov 2016 19:38:57 +0000 Subject: [issue28615] Document clarification: Section 5.4 Complex Number In-Reply-To: <1478286572.26.0.816720776987.issue28615@psf.upfronthosting.co.za> Message-ID: <1478288337.68.0.552673018541.issue28615@psf.upfronthosting.co.za> R. David Murray added the comment: For anyone who wants to work on this: this is 5.4 of the python2.7 docs. The wording in the python3 docs (https://docs.python.org/3/library/stdtypes.html#numeric-types-int-float-complex) is much clearer, if someone wants to prepare a backport patch. ---------- keywords: +easy nosy: +r.david.murray stage: -> needs patch status: open -> closed versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 16:13:31 2016 From: report at bugs.python.org (airwin) Date: Fri, 04 Nov 2016 20:13:31 +0000 Subject: [issue28614] Slice limit documentation is incorrect In-Reply-To: <1478286284.13.0.895417928613.issue28614@psf.upfronthosting.co.za> Message-ID: <1478290411.43.0.465418337088.issue28614@psf.upfronthosting.co.za> airwin added the comment: You can easily prove the limit is correct for real numbers. So I would be willing to accept as a resolution of this issue that the type of division that is going on here is real. However, that is a bit disquieting since if you try a real slice index you get "TypeError: slice indices must be integers or None or have an __index__ method". Thus, m < real limit test is a comparison of an integer and real which implies m gets changed to real before the comparison. Which obviously gives the correct result in the 1.5 case, but in general I dislike real comparisons where the distinction between < and <=, for example, can get blurred because of potential roundoff issues with reals. So I think my suggested one-sentence resolution to the issue is better then updating the documentation to clarify what kind of division is occurring in the limit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 16:18:26 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 04 Nov 2016 20:18:26 +0000 Subject: [issue28610] Provide PDB hook to customize how to find source files In-Reply-To: <1478276308.14.0.744834650748.issue28610@psf.upfronthosting.co.za> Message-ID: <1478290706.09.0.222484474745.issue28610@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The lazycache() function of the linecache module meets your request, I think. See the following debugging session using the attached script: $ python -m pdb debug_script.py > /path/to/cwd/debug_script.py(1)() -> def debug_script(script): (Pdb) n > /path/to/cwd/debug_script.py(19)() -> """ (Pdb) n > /path/to/cwd/debug_script.py(20)() -> code, globs = debug_script(s) (Pdb) n > /path/to/cwd/debug_script.py(21)() -> exec(code, globs) (Pdb) s --Call-- > /path/to/cwd/script_name(2)() -> x = 1 (Pdb) s > /path/to/cwd/script_name(2)() -> x = 1 (Pdb) s > /path/to/cwd/script_name(3)() -> y = 'blabla' (Pdb) s --Return-- > /path/to/cwd/script_name(3)()->None -> y = 'blabla' (Pdb) s --Return-- > /path/to/cwd/debug_script.py(21)()->None -> exec(code, globs) (Pdb) ---------- nosy: +xdegaye Added file: http://bugs.python.org/file45358/debug_script.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 16:20:20 2016 From: report at bugs.python.org (Sohaib Ahmad) Date: Fri, 04 Nov 2016 20:20:20 +0000 Subject: [issue27973] urllib.urlretrieve() fails on second ftp transfer In-Reply-To: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za> Message-ID: <1478290820.19.0.467624663272.issue27973@psf.upfronthosting.co.za> Sohaib Ahmad added the comment: Can someone please review this patch so that it would be in 2.7.13 when it comes out? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 16:30:22 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Nov 2016 20:30:22 +0000 Subject: [issue28614] Slice limit documentation is incorrect In-Reply-To: <1478286284.13.0.895417928613.issue28614@psf.upfronthosting.co.za> Message-ID: <1478291422.39.0.52298988518.issue28614@psf.upfronthosting.co.za> R. David Murray added the comment: The formula is documenting the behavior, not the implementation. So the formula is a mathematical formula that assumes infinite precision, not a floating point calculation. I always thought that was clear by context and phrasing, but perhaps I'm wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 16:36:00 2016 From: report at bugs.python.org (wim glenn) Date: Fri, 04 Nov 2016 20:36:00 +0000 Subject: [issue28617] Why isn't "in" called a comparison operation? Message-ID: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za> New submission from wim glenn: Regarding https://docs.python.org/3/library/stdtypes.html#comparisons There is a line at the bottom claiming: > Two more operations with the same syntactic priority, in and not in, are supported only by sequence types (below). The claim is incorrect because `in` and `not in` are also supported by non-sequence types such as sets, mappings, etc for membership testing. Is there any good reason why we don't include them in the table of comparison operations, and say that there are ten comparison operations in python? They do support comparison chaining in the same way: >>> 'x' in 'xy' in 'xyz' True >>> 0 in {0} in [{0}] True ---------- assignee: docs at python components: Documentation files: patch.diff keywords: patch messages: 280080 nosy: docs at python, wim.glenn priority: normal severity: normal status: open title: Why isn't "in" called a comparison operation? type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45359/patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 16:44:22 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Nov 2016 20:44:22 +0000 Subject: [issue19899] No test for thread.interrupt_main() In-Reply-To: <1386256832.82.0.17906161504.issue19899@psf.upfronthosting.co.za> Message-ID: <1478292262.02.0.929111519164.issue19899@psf.upfronthosting.co.za> R. David Murray added the comment: This looks great, thanks. ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 16:47:51 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Nov 2016 20:47:51 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478292471.1.0.508642114604.issue28563@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > But there is still a problem. Both patched and original c2py fail to handle nested ternary operator. They respect the right associative but fails to handle expressions like '1?2?3:4:5'. What if make repeated replacements with regular expression r'([^?:]*?)\?([^?:]*?):([^?:]*)'? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 16:56:44 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Nov 2016 20:56:44 +0000 Subject: [issue28617] Why isn't "in" called a comparison operation? In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za> Message-ID: <1478293004.11.0.645195205089.issue28617@psf.upfronthosting.co.za> R. David Murray added the comment: It should really say "only by types that support iteration". They are not comparison operations, they are containment predicates. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 16:58:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Nov 2016 20:58:07 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478293087.39.0.576792095851.issue28563@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > It doesn't solve the case when an identifier or number is used as a function: In the first case we should convert an argument to integer. ns = {} exec('''if True: def func(arg): n = int(arg) return {} '''.format(plural), ns) return ns['func'] Or raise an exception if argument is not integer. In the second case I think we can just left it as is. This is not valid C expression. Or we can add try/except in above code and convert TypeError to ValueError if this is more preferable exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 17:00:21 2016 From: report at bugs.python.org (wim glenn) Date: Fri, 04 Nov 2016 21:00:21 +0000 Subject: [issue28617] Why isn't "in" called a comparison operation? In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za> Message-ID: <1478293221.06.0.672372925414.issue28617@psf.upfronthosting.co.za> wim glenn added the comment: Well, that wouldn't be true either. Because you can easily implement objects which support membership tests but don't support iteration. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 17:02:00 2016 From: report at bugs.python.org (wim glenn) Date: Fri, 04 Nov 2016 21:02:00 +0000 Subject: [issue28617] Why isn't "in" called a comparison operation? In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za> Message-ID: <1478293320.19.0.0507614526588.issue28617@psf.upfronthosting.co.za> wim glenn added the comment: I want to add that the grammar explicitly mentions them as comparisons https://docs.python.org/3/reference/grammar.html And they are also listed in the comparisons section of the expressions documentation https://docs.python.org/3/reference/expressions.html#comparisons So the docs seem to be contradicting themselves here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 17:08:44 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Nov 2016 21:08:44 +0000 Subject: [issue28616] sys.version_info.releaselevel - 'final' or 'release' In-Reply-To: <1478287078.75.0.465203808408.issue28616@psf.upfronthosting.co.za> Message-ID: <20161104210841.7144.3998.0C94896E@psf.io> Roundup Robot added the comment: New changeset 0b4bcd954554 by Ned Deily in branch '2.7': Issue #28616: Correct help for sys.version_info releaselevel component. https://hg.python.org/cpython/rev/0b4bcd954554 New changeset 1390bde4b768 by Ned Deily in branch '3.5': Issue #28616: Correct help for sys.version_info releaselevel component. https://hg.python.org/cpython/rev/1390bde4b768 New changeset 048870daf397 by Ned Deily in branch '3.6': Issue #28616: merge from 3.5 https://hg.python.org/cpython/rev/048870daf397 New changeset 87d76ce01217 by Ned Deily in branch 'default': Issue #28616: merge from 3.6 https://hg.python.org/cpython/rev/87d76ce01217 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 17:10:17 2016 From: report at bugs.python.org (Ned Deily) Date: Fri, 04 Nov 2016 21:10:17 +0000 Subject: [issue28616] sys.version_info.releaselevel - 'final' or 'release' In-Reply-To: <1478287078.75.0.465203808408.issue28616@psf.upfronthosting.co.za> Message-ID: <1478293817.42.0.703512110004.issue28616@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the patch! ---------- nosy: +ned.deily resolution: -> fixed stage: -> resolved status: open -> closed versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 17:10:30 2016 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Nov 2016 21:10:30 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1478293830.72.0.116685967742.issue23996@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 17:11:38 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 04 Nov 2016 21:11:38 +0000 Subject: [issue27973] urllib.urlretrieve() fails on second ftp transfer In-Reply-To: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za> Message-ID: <1478293898.66.0.117399699186.issue27973@psf.upfronthosting.co.za> Senthil Kumaran added the comment: @Sohaib, Thanks for the ping. Yeah, I will act on it. Your analysis in msg276795 seems plausible, On the patch itself, I will try to reproduce this and see if I can avoid introducing this clear_buffer function. If no other go, then it should just be a private method (_clear_buffer). That's my update and we will have it included by 2.7.13 and in 3.x versions if have a similar fate. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 17:11:43 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 04 Nov 2016 21:11:43 +0000 Subject: [issue28617] Why isn't "in" called a comparison operation? In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za> Message-ID: <1478293903.43.0.0831854835326.issue28617@psf.upfronthosting.co.za> Raymond Hettinger added the comment: At a grammar and implementation level, the "in" and "not in" operators are treated like comparisons (same precedence and opcodes), but at a semantic level, I concur with David Murray and don't think of these as being comparisons at all. Accordingly, I prefer the current presentation and agree with David that the note should be revised to say "only by types that support iteration". ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 17:47:01 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 04 Nov 2016 21:47:01 +0000 Subject: [issue28593] Inconsistent itertools' predicate behaviour In-Reply-To: <1478140695.8.0.674711100728.issue28593@psf.upfronthosting.co.za> Message-ID: <1478296021.99.0.196839500385.issue28593@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think that the simpler signature is better, that the None argument isn't clear, and that there aren't use cases that warrant and API churn. On your last post, I seemed that you were withdrawing the request. Can this tracker item be closed now? ---------- assignee: -> rhettinger components: +Extension Modules versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 17:54:27 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 04 Nov 2016 21:54:27 +0000 Subject: [issue28593] Inconsistent itertools' predicate behaviour In-Reply-To: <1478140695.8.0.674711100728.issue28593@psf.upfronthosting.co.za> Message-ID: <1478296467.6.0.775688284834.issue28593@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- Removed message: http://bugs.python.org/msg280091 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 17:54:36 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 04 Nov 2016 21:54:36 +0000 Subject: [issue28593] Inconsistent itertools' predicate behaviour In-Reply-To: <1478140695.8.0.674711100728.issue28593@psf.upfronthosting.co.za> Message-ID: <1478296476.17.0.911900017585.issue28593@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think that the simpler signature is better, that the None argument isn't clear, and that there aren't use cases that warrant and API churn. On your last post, it seemed that you were withdrawing the request. Can this tracker item be closed now? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 18:08:35 2016 From: report at bugs.python.org (wim glenn) Date: Fri, 04 Nov 2016 22:08:35 +0000 Subject: [issue28617] Why isn't "in" called a comparison operation? In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za> Message-ID: <1478297315.93.0.153424004861.issue28617@psf.upfronthosting.co.za> wim glenn added the comment: Perhaps it's better to call a spade a spade here - if they're implemented as comparisons, then why not document them as comparisons? A colleague has mentioned one point that sets `in` and `not in` apart from the other comparisons in the table: comparisons are generally made between objects of the same type (with the exception of numbers). But membership "comparisons" are made between different types (with the exception of substring checks). Here is an alternate patch which leaves the table alone, but corrects the inaccuracy in the note. ---------- Added file: http://bugs.python.org/file45360/newpatch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 18:17:24 2016 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Fri, 04 Nov 2016 22:17:24 +0000 Subject: [issue28617] Why isn't "in" called a comparison operation? In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za> Message-ID: <1478297844.51.0.465330327613.issue28617@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: "in" and "not in" are not comparisons, regardless of implementation mechanics (which could change). They aren't really dependent on iteration, though they often correlate with iteration. I'd rather see them described as "containment tests" or something similar. ---------- nosy: +fdrake _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 18:29:29 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Nov 2016 22:29:29 +0000 Subject: [issue28593] Inconsistent itertools' predicate behaviour In-Reply-To: <1478140695.8.0.674711100728.issue28593@psf.upfronthosting.co.za> Message-ID: <1478298569.58.0.598106637502.issue28593@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Note that the predicate is optional argument in groupby but mandatory in dropwhile and takewhile. I suppose that filter and filterfalse accept None for historical reason (they precede bool). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 19:10:34 2016 From: report at bugs.python.org (Francisco Couzo) Date: Fri, 04 Nov 2016 23:10:34 +0000 Subject: [issue28593] Inconsistent itertools' predicate behaviour In-Reply-To: <1478140695.8.0.674711100728.issue28593@psf.upfronthosting.co.za> Message-ID: <1478301034.35.0.271610057187.issue28593@psf.upfronthosting.co.za> Francisco Couzo added the comment: I think removing None as a valid predicate to filterfalse would make the API simpler, but I don't know if it's worth the API change, please do close the issue if you think it's not worth it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 20:29:04 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 05 Nov 2016 00:29:04 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python Message-ID: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> New submission from STINNER Victor: When analyzing results of Python performance benchmarks, I noticed that call_method was 70% slower (!) between revisions 83877018ef97 (Oct 18) and 3e073e7b4460 (Oct 22), including these revisions, on the speed-python server. On these revisions, the CPU L1 instruction cache is less efficient: 8% cache misses, whereas it was only 0.06% before and after these revisions. Since the two mentioned revisions have no obvious impact on the call_method() benchmark, I understand that the performance difference by a different layout of the machine code, maybe the exact location of functions. IMO the best solution to such compilation issue is to use PGO compilation. Problem: PGO doesn't work on Ubuntu 14.04, the OS used by speed-python (the server runining benchmarks for http://speed.python.org/). I propose to decorate manually the "hot" functions using the GCC __attribute__((hot)) decorator: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes (search for "hot") Attached patch adds Py_HOT_FUNCTION and decorates the following functions: * _PyEval_EvalFrameDefault() * PyFrame_New() * call_function() * lookdict_unicode_nodummy() * _PyFunction_FastCall() * frame_dealloc() These functions are the top 6 according to the Linux perf tool when running the call_simple benchmark of the performance project: 32,66%: _PyEval_EvalFrameDefault 13,09%: PyFrame_New 12,78%: call_function 12,24%: lookdict_unicode_nodummy 9,85%: _PyFunction_FastCall 8,47%: frame_dealloc ---------- components: Interpreter Core files: hot_function.patch keywords: patch messages: 280097 nosy: haypo priority: normal severity: normal status: open title: Decorate hot functions using __attribute__((hot)) to optimize Python type: performance versions: Python 3.7 Added file: http://bugs.python.org/file45361/hot_function.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 20:31:27 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 05 Nov 2016 00:31:27 +0000 Subject: [issue28542] document cross compilation In-Reply-To: <1477563460.46.0.569265292251.issue28542@psf.upfronthosting.co.za> Message-ID: <1478305887.91.0.747214971907.issue28542@psf.upfronthosting.co.za> Martin Panter added the comment: Actually I think it is good to document DESTDIR (you weren?t seem aware of it before?). I was just pointing out that it is useful to more than just Android. Perhaps Guido shouldn?t have trimmed it from the 2.7 readme (original text: https://hg.python.org/cpython/diff/988b3e807043/README). On the other hand, --prefix etc are already mentioned in ?./configure --help?, and more people already seem to know about it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 22:23:46 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 05 Nov 2016 02:23:46 +0000 Subject: [issue28485] compileall.compile_dir(workers=) does not raise ValueError if multithreading disabled In-Reply-To: <1476949159.83.0.8638287974.issue28485@psf.upfronthosting.co.za> Message-ID: <20161105022342.3171.83958.6C1E05D7@psf.io> Roundup Robot added the comment: New changeset 532b0b9f41e0 by Martin Panter in branch '3.5': Issue #28485: Check for negative workers even without ProcessPoolExecutor https://hg.python.org/cpython/rev/532b0b9f41e0 New changeset a7c76c3843af by Martin Panter in branch '3.6': Issue #28485: Merge single-threading fix from 3.5 into 3.6 https://hg.python.org/cpython/rev/a7c76c3843af New changeset 7d9885fd6777 by Martin Panter in branch 'default': Issue #28485: Merge single-threading fix from 3.6 https://hg.python.org/cpython/rev/7d9885fd6777 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 22:26:19 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 05 Nov 2016 02:26:19 +0000 Subject: [issue25868] test_eintr.test_sigwaitinfo() hangs on "AMD64 FreeBSD CURRENT 3.x" buildbot In-Reply-To: <1450174856.95.0.354294896083.issue25868@psf.upfronthosting.co.za> Message-ID: <1478312779.88.0.848289595064.issue25868@psf.upfronthosting.co.za> Martin Panter added the comment: My patch doesn?t help answer the question of why this only fails on BSD, so I will hold off on committing it. However v2 has a minor update to skip the test when pthread_sigmask() is unavailable. ---------- versions: +Python 3.7 Added file: http://bugs.python.org/file45362/sigwaitinfo-block.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 22:57:11 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 05 Nov 2016 02:57:11 +0000 Subject: [issue4347] Circular dependency causes SystemError when adding new syntax In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za> Message-ID: <1478314631.12.0.0802386320824.issue4347@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch for Python 3 implementing my idea. There is already code conditionally compiled out for the pgen build, so my patch just expands that to avoid the "graminit.h" include and derived functions. ---------- stage: needs patch -> patch review status: closed -> open versions: +Python 3.5, Python 3.6, Python 3.7 -Python 2.6 Added file: http://bugs.python.org/file45363/graminit-dep.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 4 23:05:33 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 05 Nov 2016 03:05:33 +0000 Subject: [issue28485] compileall.compile_dir(workers=) does not raise ValueError if multithreading disabled In-Reply-To: <1476949159.83.0.8638287974.issue28485@psf.upfronthosting.co.za> Message-ID: <1478315133.4.0.186538371389.issue28485@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 01:28:05 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 05 Nov 2016 05:28:05 +0000 Subject: [issue28593] Inconsistent itertools' predicate behaviour In-Reply-To: <1478140695.8.0.674711100728.issue28593@psf.upfronthosting.co.za> Message-ID: <1478323685.94.0.0423048627801.issue28593@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 01:39:44 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 Nov 2016 05:39:44 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za> Message-ID: <1478324384.81.0.480316498724.issue19569@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: FYI I used Py_DEPRECATED for marking PyUnicode_AsDecodedObject, PyUnicode_AsDecodedUnicode, PyUnicode_AsEncodedObject and PyUnicode_AsEncodedUnicode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 03:37:11 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 05 Nov 2016 07:37:11 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478331431.71.0.243836105417.issue28563@psf.upfronthosting.co.za> Xiang Zhang added the comment: > gettext.c2py("n()")(lambda: os.system("sh")) > gettext.c2py("1()")(0) Empty parentheses should be disallowed. Function calls are not allowed in plural expression. And non-integer argument should be disallowed either, just as Serhiy's example shows. > What if make repeated replacements with regular expression r'([^?:]*?)\?([^?:]*?):([^?:]*)'? How does it work for '1?2:3?4:5'? :-( I am considering a parser. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 04:29:03 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 Nov 2016 08:29:03 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478334543.94.0.311240729243.issue28563@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > How does it work for '1?2:3?4:5'? '1?2:3?4:5' -> '(2 if 1 else 3)?4:5' -> '(4 if (2 if 1 else 3) else 5' But there are other problems. Precedence of some operators is different in C and Python. Chained comparison in Python cause different result that in C (e.g. '2 == 2 == 2'). Seems there is no other way besides a simple parser. gettext_c2py.patch itself LGTM for fixing security issue, but tests are needed. It would be nice to make c2py() working with any expressions, but if this is too hard, this can be left for other issue. I'm going to commit a variant of gettext_c2py.patch before 3.6 release if there will be not better patches. ---------- priority: high -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 05:07:45 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 05 Nov 2016 09:07:45 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1478336865.71.0.400107417809.issue28618@psf.upfronthosting.co.za> STINNER Victor added the comment: I ran benchmarks. Globally, it seems like the impact of the patch is positive. regex_v8 and call_simple are slower, but these benchmarks are microbenchmarks impacted by low level stuff like CPU L1 cache. Well, my patch was supposed to optimize CPython for call_simple :-/ I should maybe investigate a little bit more. Performance comparison (performance 0.3.2): haypo at smithers$ python3 -m perf compare_to orig.json hot.json -G Slower (6): - regex_v8: 40.6 ms +- 5.7 ms -> 47.1 ms +- 0.3 ms: 1.16x slower - call_simple: 12.6 ms +- 0.2 ms -> 13.2 ms +- 1.3 ms: 1.05x slower - regex_effbot: 4.58 ms +- 0.07 ms -> 4.70 ms +- 0.05 ms: 1.03x slower - sympy_integrate: 43.4 ms +- 0.3 ms -> 44.0 ms +- 0.2 ms: 1.01x slower - nqueens: 239 ms +- 2 ms -> 241 ms +- 1 ms: 1.01x slower - scimark_fft: 674 ms +- 12 ms -> 680 ms +- 75 ms: 1.01x slower Faster (32): - scimark_monte_carlo: 255 ms +- 4 ms -> 234 ms +- 7 ms: 1.09x faster - chameleon: 28.4 ms +- 3.1 ms -> 27.0 ms +- 0.4 ms: 1.05x faster - scimark_sor: 488 ms +- 27 ms -> 467 ms +- 10 ms: 1.05x faster - sqlite_synth: 9.16 us +- 1.03 us -> 8.82 us +- 0.23 us: 1.04x faster - scimark_lu: 485 ms +- 20 ms -> 469 ms +- 14 ms: 1.03x faster - xml_etree_process: 226 ms +- 30 ms -> 219 ms +- 4 ms: 1.03x faster - logging_simple: 29.7 us +- 0.4 us -> 28.9 us +- 0.3 us: 1.03x faster - pickle_list: 7.99 us +- 0.88 us -> 7.78 us +- 0.05 us: 1.03x faster - raytrace: 1.26 sec +- 0.08 sec -> 1.23 sec +- 0.01 sec: 1.03x faster - sympy_expand: 995 ms +- 31 ms -> 971 ms +- 35 ms: 1.03x faster - deltablue: 17.0 ms +- 0.1 ms -> 16.6 ms +- 0.2 ms: 1.02x faster - call_method_slots: 16.0 ms +- 0.1 ms -> 15.6 ms +- 0.2 ms: 1.02x faster - fannkuch: 983 ms +- 12 ms -> 962 ms +- 29 ms: 1.02x faster - pickle_pure_python: 1.25 ms +- 0.14 ms -> 1.22 ms +- 0.01 ms: 1.02x faster - logging_format: 34.0 us +- 0.3 us -> 33.4 us +- 1.5 us: 1.02x faster - xml_etree_parse: 274 ms +- 9 ms -> 270 ms +- 5 ms: 1.02x faster - sympy_str: 441 ms +- 3 ms -> 433 ms +- 3 ms: 1.02x faster - genshi_text: 87.6 ms +- 9.2 ms -> 86.0 ms +- 1.4 ms: 1.02x faster - genshi_xml: 187 ms +- 17 ms -> 184 ms +- 1 ms: 1.02x faster - django_template: 376 ms +- 4 ms -> 370 ms +- 2 ms: 1.02x faster - json_dumps: 27.1 ms +- 0.4 ms -> 26.7 ms +- 0.4 ms: 1.02x faster - sqlalchemy_declarative: 295 ms +- 3 ms -> 291 ms +- 3 ms: 1.01x faster - call_method_unknown: 18.1 ms +- 0.1 ms -> 17.8 ms +- 0.1 ms: 1.01x faster - nbody: 218 ms +- 4 ms -> 216 ms +- 2 ms: 1.01x faster - regex_dna: 250 ms +- 24 ms -> 247 ms +- 2 ms: 1.01x faster - go: 573 ms +- 2 ms -> 566 ms +- 3 ms: 1.01x faster - richards: 173 ms +- 4 ms -> 171 ms +- 4 ms: 1.01x faster - python_startup: 24.6 ms +- 0.1 ms -> 24.5 ms +- 0.1 ms: 1.00x faster - regex_compile: 404 ms +- 6 ms -> 403 ms +- 5 ms: 1.00x faster - dulwich_log: 143 ms +- 11 ms -> 143 ms +- 1 ms: 1.00x faster - pidigits: 290 ms +- 1 ms -> 289 ms +- 0 ms: 1.00x faster - pickle_dict: 58.3 us +- 6.5 us -> 58.3 us +- 0.7 us: 1.00x faster Benchmark hidden because not significant (26): 2to3, call_method, chaos, crypto_pyaes, float, hexiom, html5lib, json_loads, logging_silent, mako, meteor_contest, pathlib, pickle, python_startup_no_site, scimark_sparse_mat_mult, spectral_norm, sqlalchemy_imperative, sympy_sum, telco, tornado_http, unpack_sequence, unpickle, unpickle_list, unpickle_pure_python, xml_etree_generate, xml_etree_iterparse -- More readable output, only display differences >= 5%: haypo at smithers$ python3 -m perf compare_to orig.json hot.json -G --min-speed=5 Slower (1): - regex_v8: 40.6 ms +- 5.7 ms -> 47.1 ms +- 0.3 ms: 1.16x slower Faster (2): - scimark_monte_carlo: 255 ms +- 4 ms -> 234 ms +- 7 ms: 1.09x faster - chameleon: 28.4 ms +- 3.1 ms -> 27.0 ms +- 0.4 ms: 1.05x faster Benchmark hidden because not significant (61): 2to3, call_method, call_method_slots, call_method_unknown, call_simple, chaos, crypto_pyaes, deltablue, django_template, dulwich_log, fannkuch, float, genshi_text, genshi_xml, go, hexiom, html5lib, json_dumps, json_loads, logging_format, logging_silent, logging_simple, mako, meteor_contest, nbody, nqueens, pathlib, pickle, pickle_dict, pickle_list, pickle_pure_python, pidigits, python_startup, python_startup_no_site, raytrace, regex_compile, regex_dna, regex_effbot, richards, scimark_fft, scimark_lu, scimark_sor, scimark_sparse_mat_mult, spectral_norm, sqlalchemy_declarative, sqlalchemy_imperative, sqlite_synth, sympy_expand, sympy_integrate, sympy_str, sympy_sum, telco, tornado_http, unpack_sequence, unpickle, unpickle_list, unpickle_pure_python, xml_etree_generate, xml_etree_iterparse, xml_etree_parse, xml_etree_process ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 05:08:51 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 05 Nov 2016 09:08:51 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1478336931.79.0.0553659723368.issue28618@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I forgot to mention that I compiled Python with "./configure -C". The purpose of the patch is to optimize Python when LTO and/or PGO compilation are not explicitly used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 05:56:13 2016 From: report at bugs.python.org (Carl Ekerot) Date: Sat, 05 Nov 2016 09:56:13 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478339773.43.0.956237336394.issue28563@psf.upfronthosting.co.za> Carl Ekerot added the comment: Verified gettext.c2py with gettext_c2py.patch applied agains the plural forms actually used in localization, listed over at http://docs.translatehouse.org/projects/localization-guide/en/latest/l10n/pluralforms.html. I tested all of the none-trivial forms, and from what I can tell they generate valid syntax and are correct. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 05:59:20 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 05 Nov 2016 09:59:20 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1478339960.12.0.758742857374.issue28618@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Can you compare against a PGO build? Ubuntu 14.04 is old, and I don't think this is something we should worry about. Overall I think this manual approach is really the wrong way to look at it. Compilers can do better than us. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 07:37:21 2016 From: report at bugs.python.org (Ed Schouten) Date: Sat, 05 Nov 2016 11:37:21 +0000 Subject: [issue28619] [Patch] Stop using inet_ntoa() when possible. Message-ID: <1478345841.6.0.691091432417.issue28619@psf.upfronthosting.co.za> New submission from Ed Schouten: Modern C code should use inet_ntop()/inet_pton() as opposed to inet_addr()/inet_aton()/inet_ntoa(). Though the former functions may typically act as drop-in replacements for the latter, the inet_addr()/inet_aton() functions still have the advantage over inet_pton() of allowing you to parse IPv4 addresses that don't use the dotted quad notation (e.g. '0x0a000001' for 10.0.0.1). There is no difference between inet_ntop() and inet_ntoa(), as they both always print the address in dotted quad form. inet_ntop() does have the advantage of being thread-safe, as inet_ntoa() uses internal storage for the return value. In other words, we'd better not use inet_ntoa() at all. Attached is a patch for Python's socketmodule that changes the existing call to inet_ntoa() to use inet_ntop() when available. This has the advantage of fixing the build on CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), which intentionally omits any APIs that are thread-unsafe. ---------- components: Extension Modules files: patch-inet_ntoa.diff keywords: patch messages: 280109 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Stop using inet_ntoa() when possible. versions: Python 3.7 Added file: http://bugs.python.org/file45364/patch-inet_ntoa.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 08:05:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 Nov 2016 12:05:13 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za> Message-ID: <1478347513.39.0.0550070893208.issue19569@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch marks most deprecated functions. Code is rewritten for using non-deprecated functions if possible. Unfortunately some deprecated function still are used in the code and can't be easier replaced. They are left not marked. * PyEval_ReleaseLock() is used in Python/pystate.c. It can't be replaced with PyEval_ReleaseThread() since the latter don't accept NULL. * Py_UNICODE (currently an alias of wchar_t) is used in a number of deprecated functions and bridges between deprecated and new APIs. Maybe it can be just replaced with wchar_t. * Macros PyUnicode_GET_SIZE, PyUnicode_GET_DATA_SIZE, PyUnicode_AS_UNICODE, PyUnicode_AS_DATA, functions PyUnicode_AsUnicode and PyUnicode_AsUnicodeAndSize are used in a number of places. They can't be easily replaced with wchar-based functions since they return a borrowed reference to cached representation. * PyUnicode_FromUnicode, PyUnicode_EncodeDecimal and PyUnicode_TransformDecimalToASCII are used only in Modules/_testcapimodule.c. I think we should write tests for modern APIs and eliminate tests for deprecated APIs. Or temporary silence compiler warning in test functions. * _PyUnicode_ToLowercase, _PyUnicode_ToUppercase and corresponding public macros Py_UNICODE_TOLOWER and Py_UNICODE_TOUPPER are used in Modules/_sre.c (this is a bug in regex implementation). The problem is that more modern functions _PyUnicode_ToLowerFull and _PyUnicode_ToUpperFull is a private API. All these cases needs separate issues. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file45365/mark-deprecated-functions.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 08:50:06 2016 From: report at bugs.python.org (Honor) Date: Sat, 05 Nov 2016 12:50:06 +0000 Subject: [issue28620] Build Memory Leak Message-ID: New submission from Honor: Hi, I am compiling python from source code with clang compiler. as follows result: ==5284==ERROR: LeakSanitizer: detected memory leaks Direct leak of 11776 byte(s) in 8 object(s) allocated from: #0 0x49ccbe (/home/y/Downloads/Python-3.5.2/Parser/pgen+0x49ccbe) #1 0x4c86ca (/home/y/Downloads/Python-3.5.2/Parser/pgen+0x4c86ca) Indirect leak of 2000 byte(s) in 3 object(s) allocated from: #0 0x49ccbe (/home/y/Downloads/Python-3.5.2/Parser/pgen+0x49ccbe) #1 0x4c86ca (/home/y/Downloads/Python-3.5.2/Parser/pgen+0x4c86ca) Indirect leak of 898 byte(s) in 86 object(s) allocated from: #0 0x49c9cb (/home/y/Downloads/Python-3.5.2/Parser/pgen+0x49c9cb) #1 0x2ad0d5405679 (/lib/x86_64-linux-gnu/libc.so.6+0x89679) Indirect leak of 520 byte(s) in 1 object(s) allocated from: #0 0x49c9cb (/home/y/Downloads/Python-3.5.2/Parser/pgen+0x49c9cb) #1 0x4cb549 (/home/y/Downloads/Python-3.5.2/Parser/pgen+0x4cb549) Indirect leak of 178 byte(s) in 33 object(s) allocated from: #0 0x49c9cb (/home/y/Downloads/Python-3.5.2/Parser/pgen+0x49c9cb) #1 0x4c14d4 (/home/y/Downloads/Python-3.5.2/Parser/pgen+0x4c14d4) SUMMARY: AddressSanitizer: 15372 byte(s) leaked in 131 allocation(s). Python version 3.5.2 Operating System: Linux y 3.13.0-24-generic 14.04 ubuntu gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ---------- messages: 280111 nosy: Stone priority: normal severity: normal status: open title: Build Memory Leak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 09:36:53 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 05 Nov 2016 13:36:53 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478353013.63.0.505798838823.issue28563@psf.upfronthosting.co.za> Xiang Zhang added the comment: > '1?2:3?4:5' -> '(2 if 1 else 3)?4:5' -> '(4 if (2 if 1 else 3) else 5' This is not right. It's right associative so it should be 1?2:(3?4:5) -> 1?2:(4 if 3 else 5) -> 2 if 1 else (4 if 3 else 5) > It would be nice to make c2py() working with any expressions, but if this is too hard, this can be left for other issue. Agree. But I am interested in trying. > gettext_c2py.patch itself LGTM for fixing security issue, but tests are needed. It gets drawbacks so I don't include tests. I'll add in next try. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 09:50:45 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 05 Nov 2016 13:50:45 +0000 Subject: [issue28620] Build Memory Leak In-Reply-To: Message-ID: <1478353845.19.0.314932581105.issue28620@psf.upfronthosting.co.za> Xiang Zhang added the comment: This seems a same problem as in #27780. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 10:10:32 2016 From: report at bugs.python.org (Honor) Date: Sat, 05 Nov 2016 14:10:32 +0000 Subject: [issue28620] Build Memory Leak In-Reply-To: <1478353845.19.0.314932581105.issue28620@psf.upfronthosting.co.za> Message-ID: Honor added the comment: Hmmm, Ok. Thanks a lot. On Sat, Nov 5, 2016 at 4:50 PM, Xiang Zhang wrote: > > Xiang Zhang added the comment: > > This seems a same problem as in #27780. > > ---------- > nosy: +xiang.zhang > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 10:23:33 2016 From: report at bugs.python.org (irdb) Date: Sat, 05 Nov 2016 14:23:33 +0000 Subject: [issue1647489] zero-length match confuses re.finditer() Message-ID: <1478355813.38.0.540689432556.issue1647489@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 10:56:14 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 05 Nov 2016 14:56:14 +0000 Subject: [issue28620] Build Memory Leak In-Reply-To: Message-ID: <1478357774.75.0.132890824672.issue28620@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> memory leaks in pgen build step abort build with address sanitizer enabled _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 11:37:45 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 05 Nov 2016 15:37:45 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478339960.12.0.758742857374.issue28618@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Antoine Pitrou added the comment: > Can you compare against a PGO build? Do you mean comparison between current Python with PGO and patched Python without PGO? The hot attribute is ignored by GCC when PGO compilation is used. > Ubuntu 14.04 is old, and I don't think this is something we should worry about. Well, it's a practical issue for me to run benchmarks for speed.python.org. Moreover, I like the idea of getting a fast(er) Python even when no advanced optimization techniques like LTO or PGO is used. At least, it's common to build quickly Python using "./configure && make" for a quick benchmark. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 12:14:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 Nov 2016 16:14:07 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1478362447.76.0.459514678099.issue28618@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Moreover, I like the idea of getting a fast(er) Python even when no advanced optimization techniques like LTO or PGO is used. Seconded. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 12:51:50 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 05 Nov 2016 16:51:50 +0000 Subject: [issue28610] Provide PDB hook to customize how to find source files In-Reply-To: <1478276308.14.0.744834650748.issue28610@psf.upfronthosting.co.za> Message-ID: <1478364710.17.0.397025971918.issue28610@psf.upfronthosting.co.za> Xavier de Gaye added the comment: This patch is an attempt at allowing the source debugging of scripts executed by the Python exec() function. It misses tests and documentation. You may use it using the idiom given in the following example to avoid stepping into the pdb code on the first invocation of pdb.exec_script() (see the exec_script() doc string): import sys def main(): foo = 123 s = """if 1: x = foo x = 555 """ exec_script(s) if __name__ == '__main__': if '--debug' in sys.argv[1:]: import pdb exec_script = pdb.exec_script pdb.Pdb(skip=['pdb']).set_trace() else: exec_script = exec main() ---------- components: -Demos and Tools keywords: +patch stage: -> needs patch versions: +Python 3.7 -Python 3.5 Added file: http://bugs.python.org/file45366/debug_script.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 13:49:56 2016 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Nov 2016 17:49:56 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478368196.83.0.746911296579.issue28563@psf.upfronthosting.co.za> Christian Heimes added the comment: The gettext module might be vulnerable to f-string attacks, too. Also see #18317. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 13:51:35 2016 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 05 Nov 2016 17:51:35 +0000 Subject: [issue1647489] zero-length match confuses re.finditer() Message-ID: <1478368295.97.0.714143244155.issue1647489@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 14:00:31 2016 From: report at bugs.python.org (Carl Ekerot) Date: Sat, 05 Nov 2016 18:00:31 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478368831.96.0.692466556365.issue28563@psf.upfronthosting.co.za> Carl Ekerot added the comment: > The gettext module might be vulnerable to f-string attacks It is. See the example in the first comment: gettext.c2py('f"{os.system(\'sh\')}"')(0) This vulnerability seems to be solved in Xiang's patch. The DoS aspect is interesting though, since there's no constraints against malicious use of the power-operator, say "9**9**9**..**9". This too would be solved by implementing a parser with only simple arithmetics. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 14:17:49 2016 From: report at bugs.python.org (Christian Heimes) Date: Sat, 05 Nov 2016 18:17:49 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478369869.43.0.375278797825.issue28563@psf.upfronthosting.co.za> Christian Heimes added the comment: Argh, sorry. I meant to write "The gettext module might be vulnerable to more than f-string attacks.". May I suggest that you have a look at my old patch? It uses an AST visitor to inspect the AST of a gettext plural expression. It allows only a limited set of AST types as well as limited amount of expressions. I consider it a superior solution and a fix for more generic attacks. I haven't tested my patch with f-strings yet. It either refuses f-strings FormattedValue already or can be easily modified to reject it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 15:18:50 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 05 Nov 2016 19:18:50 +0000 Subject: [issue28542] document cross compilation In-Reply-To: <1477563460.46.0.569265292251.issue28542@psf.upfronthosting.co.za> Message-ID: <1478373530.89.0.786491841264.issue28542@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Yes, I was not aware of DESTDIR. The 2.7 README contains also useful information on the build process, for example about some use cases of the '*shared*' entries in the Setup files (for when setup.py cannot detect/build an extension module) or about the '*static' entries (to be able to profile extension modules). It also explains Setup.local whereas the only information on Setup.local in the Python3 documentation, is restricted to https://docs.python.org/3/extending/extending.html#compilation-and-linkage :( There is also a lot of noise in the 2.7 README, this possibly explains the trimming. Maybe the cross-build section in the 3.6 README could be a link to a new build section in the documentation ? > --prefix etc are already mentioned in ?./configure --help? The documentation on sys.prefix and sys.exec_prefix gives details about where go which files which is useful when trying to figure out where to copy the files on the target after a cross-build. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 15:21:44 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 05 Nov 2016 19:21:44 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478373704.93.0.465961593963.issue28563@psf.upfronthosting.co.za> Xiang Zhang added the comment: Christian, I think our patches are quite similar in function. They only allow limited tokens. > I consider it a superior solution and a fix for more generic attacks Mine now still allows **. But it can be easily fixed. But both our patches still translate a C expression to Python and still suffer from nested ternary operator and different semantics between C and Python, e.g. (2==2==2 as Serhiy notes). :-( I plan to try a simple parser. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 15:37:28 2016 From: report at bugs.python.org (Adrian Wielgosik) Date: Sat, 05 Nov 2016 19:37:28 +0000 Subject: [issue28621] Refactor duplicate code calculating digit's bit length Message-ID: <1478374648.81.0.502575461924.issue28621@psf.upfronthosting.co.za> New submission from Adrian Wielgosik: The attached patch uses an existing function bits_in_digit() in two other functions: - in long_bit_length() - it already had identical logic - in _PyLong_NumBits() - it used a naive, slower way of calculating bit length, so as an added bonus the patch speeds it up a bit. It's visible in float-long comparison microbenchmark: $ ./old -m timeit "1 == 1.0" 5000000 loops, best of 5: 55 nsec per loop $ ./new -m timeit "1 == 1.0" 5000000 loops, best of 5: 52.3 nsec per loop $ ./old -m timeit "12345678 == 12345678.0" 5000000 loops, best of 5: 70.4 nsec per loop $ ./new -m timeit "12345678 == 12345678.0" 5000000 loops, best of 5: 53.5 nsec per loop ---------- components: Interpreter Core messages: 280123 nosy: Adrian Wielgosik priority: normal severity: normal status: open title: Refactor duplicate code calculating digit's bit length type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 15:38:13 2016 From: report at bugs.python.org (Adrian Wielgosik) Date: Sat, 05 Nov 2016 19:38:13 +0000 Subject: [issue28621] Refactor duplicate code calculating digit's bit length In-Reply-To: <1478374648.81.0.502575461924.issue28621@psf.upfronthosting.co.za> Message-ID: <1478374693.9.0.804866825309.issue28621@psf.upfronthosting.co.za> Changes by Adrian Wielgosik : ---------- keywords: +patch Added file: http://bugs.python.org/file45367/bit_length.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 15:38:46 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 05 Nov 2016 19:38:46 +0000 Subject: [issue26935] android: test_os fails In-Reply-To: <1462287800.22.0.0769666286965.issue26935@psf.upfronthosting.co.za> Message-ID: <1478374726.8.0.0546422753518.issue26935@psf.upfronthosting.co.za> Xavier de Gaye added the comment: New patch. Thanks for the review Martin! ---------- Added file: http://bugs.python.org/file45368/test_urandom_fd_reopened_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 16:02:31 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 05 Nov 2016 20:02:31 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: Message-ID: <28b5dbd8-5271-af43-599b-9cf952390ef7@free.fr> Antoine Pitrou added the comment: Le 05/11/2016 ? 16:37, STINNER Victor a ?crit : > > Antoine Pitrou added the comment: >> Can you compare against a PGO build? > > Do you mean comparison between current Python with PGO and patched > Python without PGO? Yes. >> Ubuntu 14.04 is old, and I don't think this is something we should worry about. > > Well, it's a practical issue for me to run benchmarks for speed.python.org. Why isn't the OS updated on that machine? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 17:42:48 2016 From: report at bugs.python.org (SilentGhost) Date: Sat, 05 Nov 2016 21:42:48 +0000 Subject: [issue28621] Refactor duplicate code calculating digit's bit length In-Reply-To: <1478374648.81.0.502575461924.issue28621@psf.upfronthosting.co.za> Message-ID: <1478382168.09.0.323824744564.issue28621@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +mark.dickinson stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 18:53:19 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 05 Nov 2016 22:53:19 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <28b5dbd8-5271-af43-599b-9cf952390ef7@free.fr> Message-ID: STINNER Victor added the comment: Antoine Pitrou added the comment: >> Do you mean comparison between current Python with PGO and patched >> Python without PGO? > > Yes. Oh ok, sure. I will try to run these 2 benchmarks. >>> Ubuntu 14.04 is old, and I don't think this is something we should worry about. >> >> Well, it's a practical issue for me to run benchmarks for speed.python.org. > > Why isn't the OS updated on that machine? I am not sure that I want to use PGO compilation to run benchmarks. Last time I checked, I noticed performance differences between two compilations. PGO compilation doesn't seem 100% deterministic. Maybe PGO compilation is fine when you build Python to create a Linux package. But to get reliable benchmarks, I'm not sure that it's a good idea. I'm still running benchmarks on Python recompiled many times using different compiler options, to measure the impact of the compiler options (especially LTO and/or PGO) on the benchmark stability. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 22:19:04 2016 From: report at bugs.python.org (Al Sweigart) Date: Sun, 06 Nov 2016 02:19:04 +0000 Subject: [issue28524] Set default argument of logging.disable() to logging.CRITICAL In-Reply-To: <1477345510.5.0.68336976066.issue28524@psf.upfronthosting.co.za> Message-ID: <1478398744.94.0.812083339917.issue28524@psf.upfronthosting.co.za> Al Sweigart added the comment: Setting up different configurations for dev/prod is a bit more complicated than I'd like for most projects. I'd instead just call logging.disable(logging.CRITICAL). The entire point of this is just for the convenience of being able to disable logging messages by calling logging.disable() instead of logging.disable(logging.CRITICAL). It's a two-line change, backwards compatible, and (imo) a sensible default. You call logging.disable() expecting it to disable logging. You might want to disable a lower level, but as the Google search shows, most people just want to disable all logging period. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 23:17:01 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 06 Nov 2016 03:17:01 +0000 Subject: [issue28617] Why isn't "in" called a comparison operation? In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za> Message-ID: <1478402221.68.0.739845117949.issue28617@psf.upfronthosting.co.za> Raymond Hettinger added the comment: newpatch.diff looks fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 5 23:22:29 2016 From: report at bugs.python.org (Al Sweigart) Date: Sun, 06 Nov 2016 03:22:29 +0000 Subject: [issue23218] Modernize the IDLE Find/Replace/Find in Files dialogs In-Reply-To: <1420884051.8.0.416866319984.issue23218@psf.upfronthosting.co.za> Message-ID: <1478402549.3.0.104807496787.issue23218@psf.upfronthosting.co.za> Al Sweigart added the comment: *Bump* Just wanted to bring attention to this issue. We could keep "Regular expression" instead of "Regex" for the label (Sublime Text and other editors have "Regular expression") I think Mark's patch would be better over mine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 00:38:21 2016 From: report at bugs.python.org (Oleg Broytman) Date: Sun, 06 Nov 2016 04:38:21 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1478407101.26.0.295448790533.issue23262@psf.upfronthosting.co.za> Oleg Broytman added the comment: > I'm not sure that we can break the compatibility with old browser I agree with this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 02:45:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Nov 2016 07:45:12 +0000 Subject: [issue28621] Refactor duplicate code calculating digit's bit length In-Reply-To: <1478374648.81.0.502575461924.issue28621@psf.upfronthosting.co.za> Message-ID: <1478418312.47.0.00781431242057.issue28621@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- nosy: +serhiy.storchaka stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 04:11:51 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sun, 06 Nov 2016 09:11:51 +0000 Subject: [issue28622] Remove redundant variable annotation test from test_grammar Message-ID: <1478423511.13.0.191601822692.issue28622@psf.upfronthosting.co.za> New submission from Ivan Levkivskyi: This will remove one test from test_grammar that depends on typing module API (this test case is already covered in test_typing). ---------- components: Tests files: test-grammar-patch.diff keywords: patch messages: 280132 nosy: gvanrossum, levkivskyi priority: normal severity: normal status: open title: Remove redundant variable annotation test from test_grammar versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45369/test-grammar-patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 04:44:36 2016 From: report at bugs.python.org (Ram Rachum) Date: Sun, 06 Nov 2016 09:44:36 +0000 Subject: [issue28623] Let `shlex.quote` accept a `PathLike` object Message-ID: <1478425476.42.0.524210940005.issue28623@psf.upfronthosting.co.za> New submission from Ram Rachum: Currently it complains that you haven't fed it a string-like object. ---------- components: Library (Lib) messages: 280133 nosy: cool-RR priority: normal severity: normal status: open title: Let `shlex.quote` accept a `PathLike` object type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 05:49:39 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Nov 2016 10:49:39 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za> Message-ID: <1478429379.73.0.302798277975.issue19569@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated documentation. This part should be backported to all maintained 3.x versions. ---------- Added file: http://bugs.python.org/file45370/mark-deprecated-functions-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 06:19:59 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 Nov 2016 11:19:59 +0000 Subject: [issue28123] _PyDict_GetItem_KnownHash ignores DKIX_ERROR return In-Reply-To: <1473760278.9.0.335020145509.issue28123@psf.upfronthosting.co.za> Message-ID: <20161106111956.31027.9534.12A2CC78@psf.io> Roundup Robot added the comment: New changeset d06a6b0fd992 by Serhiy Storchaka in branch '3.6': Issue #28123: _PyDict_GetItem_KnownHash() now can raise an exception as https://hg.python.org/cpython/rev/d06a6b0fd992 New changeset 805467de22fc by Serhiy Storchaka in branch 'default': Issue #28123: _PyDict_GetItem_KnownHash() now can raise an exception as https://hg.python.org/cpython/rev/805467de22fc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 06:20:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Nov 2016 11:20:24 +0000 Subject: [issue28123] _PyDict_GetItem_KnownHash ignores DKIX_ERROR return In-Reply-To: <1473760278.9.0.335020145509.issue28123@psf.upfronthosting.co.za> Message-ID: <1478431224.66.0.504344740249.issue28123@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 06:45:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 Nov 2016 11:45:56 +0000 Subject: [issue28586] Convert os.scandir to Argument Clinic In-Reply-To: <1478075596.56.0.454562353142.issue28586@psf.upfronthosting.co.za> Message-ID: <20161106114553.22214.60508.07A2B6F6@psf.io> Roundup Robot added the comment: New changeset 0590b9c5a18e by Serhiy Storchaka in branch 'default': Issue #28586: Converted os.scandir() to Argument Clinic. https://hg.python.org/cpython/rev/0590b9c5a18e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 07:45:19 2016 From: report at bugs.python.org (Ram Rachum) Date: Sun, 06 Nov 2016 12:45:19 +0000 Subject: [issue28624] Make the `cwd` argument to `subprocess.Popen` accept a `PathLike` Message-ID: <1478436319.41.0.610397193616.issue28624@psf.upfronthosting.co.za> Changes by Ram Rachum : ---------- components: Library (Lib) nosy: cool-RR priority: normal severity: normal status: open title: Make the `cwd` argument to `subprocess.Popen` accept a `PathLike` versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 07:45:35 2016 From: report at bugs.python.org (Ram Rachum) Date: Sun, 06 Nov 2016 12:45:35 +0000 Subject: [issue28624] Make the `cwd` argument to `subprocess.Popen` accept a `PathLike` Message-ID: <1478436335.46.0.731141924672.issue28624@psf.upfronthosting.co.za> Changes by Ram Rachum : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 07:55:48 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 06 Nov 2016 12:55:48 +0000 Subject: [issue28543] Incomplete fast path codecs aliases in codecs doc In-Reply-To: <1477578000.23.0.835433953777.issue28543@psf.upfronthosting.co.za> Message-ID: <1478436948.66.0.563696968239.issue28543@psf.upfronthosting.co.za> Berker Peksag added the comment: This is a duplicate of issue 28393. ---------- nosy: +berker.peksag resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> Update encoding lookup docs wrt #27938 type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 08:15:14 2016 From: report at bugs.python.org (STINNER Victor) Date: Sun, 06 Nov 2016 13:15:14 +0000 Subject: [issue28123] _PyDict_GetItem_KnownHash ignores DKIX_ERROR return In-Reply-To: <1478431224.72.0.061438279561.issue28123@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Sorry, I didn't have time to review this issue :-( Thanks Xiang and Serhiy for fixing the issue! I prefer the new API (don't ignore the error). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 10:24:08 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 Nov 2016 15:24:08 +0000 Subject: [issue28199] Compact dict resizing is doing too much work In-Reply-To: <1474236829.43.0.744002065698.issue28199@psf.upfronthosting.co.za> Message-ID: <20161106152405.7144.86193.AFA72996@psf.io> Roundup Robot added the comment: New changeset 39f33c15243b by Serhiy Storchaka in branch 'default': Issue #28199: Microoptimized dict resizing. Based on patch by Naoki Inada. https://hg.python.org/cpython/rev/39f33c15243b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 10:26:21 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Nov 2016 15:26:21 +0000 Subject: [issue28199] Compact dict resizing is doing too much work In-Reply-To: <1474236829.43.0.744002065698.issue28199@psf.upfronthosting.co.za> Message-ID: <1478445981.86.0.924118577229.issue28199@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Re-committed. It might be dangerous to commit this in 3.6 at that stage. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 10:28:46 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Nov 2016 15:28:46 +0000 Subject: [issue28147] Unbounded memory growth resizing split-table dicts In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za> Message-ID: <1478446126.16.0.847409345398.issue28147@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 10:44:18 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Nov 2016 15:44:18 +0000 Subject: [issue28398] Return singleton empty string in _PyUnicode_FromASCII In-Reply-To: <1476028146.3.0.529072270103.issue28398@psf.upfronthosting.co.za> Message-ID: <1478447058.92.0.204370890213.issue28398@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The case for size=0 often is handled before calling _PyUnicode_FromASCII. In what circumstances _PyUnicode_FromASCII is called with size=0? Is this case covered by tests? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 10:45:57 2016 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 06 Nov 2016 15:45:57 +0000 Subject: [issue28590] fstring's '{' from escape sequences does not start an expression In-Reply-To: <1478098683.95.0.617891142218.issue28590@psf.upfronthosting.co.za> Message-ID: <1478447157.26.0.437226831382.issue28590@psf.upfronthosting.co.za> Jason R. Coombs added the comment: I've got a patch ready for this and will be applying it shortly after we update the spec. ---------- assignee: docs at python -> jason.coombs nosy: +jason.coombs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 10:51:57 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 06 Nov 2016 15:51:57 +0000 Subject: [issue26934] android: test_faulthandler fails In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za> Message-ID: <1478447517.54.0.112111328276.issue26934@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The problem: raise() does not cause the program to exit in a Python interactive session and a spawned Python process exits with 0. Android fixed this problem at API level 24 (Android 6.0 aka Marshmallow). The attached patch fixes this (tested at API levels 21 et 24). ---------- assignee: -> xdegaye components: +Tests -Cross-Build, Library (Lib) keywords: +patch stage: -> patch review versions: +Python 3.7 Added file: http://bugs.python.org/file45371/buggy_raise.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 11:10:37 2016 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 06 Nov 2016 16:10:37 +0000 Subject: [issue28590] fstring's '{' from escape sequences does not start an expression In-Reply-To: <1478098683.95.0.617891142218.issue28590@psf.upfronthosting.co.za> Message-ID: <1478448637.07.0.548823447952.issue28590@psf.upfronthosting.co.za> Jason R. Coombs added the comment: The reason that those test_no_escapes_for_braces assertions pass is because they're only dealing with opening curly braces and in an f-string, they're treated as literal opening braces. In the example you've given, the error occurs when the f-string handler encounters the closing curly brace without an opening one. It's the same as if you had written: >>> f'{{4*10}' SyntaxError: f-string: single '}' is not allowed I will add a test to capture this specific case (backslash-escaped unicode opening bracken). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 11:15:02 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 Nov 2016 16:15:02 +0000 Subject: [issue28590] fstring's '{' from escape sequences does not start an expression In-Reply-To: <1478098683.95.0.617891142218.issue28590@psf.upfronthosting.co.za> Message-ID: <20161106161459.83417.34884.5274DBC5@psf.io> Roundup Robot added the comment: New changeset 1d8b8a67b657 by Jason R. Coombs in branch '3.6': Additionally show that a backslash-escaped opening brace is treated as a literal and thus triggers the single closing brace error, clarifying #28590. https://hg.python.org/cpython/rev/1d8b8a67b657 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 11:16:43 2016 From: report at bugs.python.org (Elias Zamaria) Date: Sun, 06 Nov 2016 16:16:43 +0000 Subject: [issue28625] multiprocessing.Pool.imap swallows exceptions thrown by generators Message-ID: <1478449003.58.0.0873174644967.issue28625@psf.upfronthosting.co.za> New submission from Elias Zamaria: I have the following code: from multiprocessing import Pool def double(x): return 2 * x def get_numbers(): raise Exception("oops") yield 1 yield 2 print(list(Pool(processes=2).imap(double, get_numbers()))) I would expect it to raise an exception, but instead it just prints "[]", seeming to indicate that imap ran fine and produced no values. This seems similar to the behavior described in bugs 23051 and 26333, but this happens if the iterator directly raises an exception before yielding anything. If I move the raise statement below one or both of the yields, I get an exception from imap as expected. I am experiencing this with Python 3.5.2 on OS X 10.11.6. I haven't tried it with any other versions. ---------- components: Library (Lib) messages: 280146 nosy: elias priority: normal severity: normal status: open title: multiprocessing.Pool.imap swallows exceptions thrown by generators type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 11:25:14 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sun, 06 Nov 2016 16:25:14 +0000 Subject: [issue26855] android: add platform.android_ver() In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za> Message-ID: <1478449514.26.0.422554981102.issue26855@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: I see Xavier de Gaye uses sysconfig.get_config_var('ANDROID_API_LEVEL') is various patches. That's OK if the build-time target API level of CPython matches runtime Android API level. Does CPython force API level matching? If so this issue is no longer necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 11:40:20 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 06 Nov 2016 16:40:20 +0000 Subject: [issue21501] submitting mmap example for use in documentation In-Reply-To: <1400008733.4.0.146542624997.issue21501@psf.upfronthosting.co.za> Message-ID: <1478450420.49.0.759965851601.issue21501@psf.upfronthosting.co.za> Guido van Rossum added the comment: Can you say it in the form of a patch? ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 11:48:05 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 Nov 2016 16:48:05 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <20161106164802.83636.6215.D8DB9AE1@psf.io> Roundup Robot added the comment: New changeset bce18f5c0bc4 by Serhiy Storchaka in branch '3.5': Issue #23996: Added _PyGen_SetStopIterationValue for safe raising https://hg.python.org/cpython/rev/bce18f5c0bc4 New changeset a2c9f06ada28 by Serhiy Storchaka in branch '3.6': Issue #23996: Added _PyGen_SetStopIterationValue for safe raising https://hg.python.org/cpython/rev/a2c9f06ada28 New changeset d33b9fd46cef by Serhiy Storchaka in branch 'default': Issue #23996: Added _PyGen_SetStopIterationValue for safe raising https://hg.python.org/cpython/rev/d33b9fd46cef ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 11:52:49 2016 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 06 Nov 2016 16:52:49 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za> Message-ID: <1478451169.54.0.215521431033.issue19569@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: GCC supports pragmas to locally control warnings. https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Diagnostic-Pragmas.html Example: ==================================== __attribute__((__deprecated__)) int some_deprecated_function(void) { return 0; }; void some_function(void) { int x, y; #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wdeprecated-declarations" x = some_deprecated_function(); #pragma GCC diagnostic pop y = x + 1; } int main(int argc, char** argv) { return 0; } ==================================== In the above example, call to some_deprecated_function() does not trigger deprecation warning. '#pragma GCC diagnostic push' and '#pragma GCC diagnostic pop' are supported since GCC 4.6.0. https://gcc.gnu.org/gcc-4.6/changes.html '#pragma GCC diagnostic ignored' is documented in documentation of GCC since 4.2.0. Clang supposedly supports both '#pragma GCC diagnostic ...' and '#pragma clang diagnostic ...': http://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-pragmas ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 12:04:26 2016 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 06 Nov 2016 17:04:26 +0000 Subject: [issue28590] fstring's '{' from escape sequences does not start an expression In-Reply-To: <1478098683.95.0.617891142218.issue28590@psf.upfronthosting.co.za> Message-ID: <1478451866.35.0.130192629104.issue28590@psf.upfronthosting.co.za> Eric V. Smith added the comment: Thanks, Jason. I updated the PEP, so now I think the docs and PEP match the implementation. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 12:14:53 2016 From: report at bugs.python.org (STINNER Victor) Date: Sun, 06 Nov 2016 17:14:53 +0000 Subject: [issue26934] android: test_faulthandler fails In-Reply-To: <1478447517.54.0.112111328276.issue26934@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Can you try to write a decorator to not suplicate the same long skipIf()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 12:20:55 2016 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 06 Nov 2016 17:20:55 +0000 Subject: [issue28626] Tutorial: rearrange discussion of output formatting to encourage f-strings Message-ID: <1478452855.22.0.932657206329.issue28626@psf.upfronthosting.co.za> New submission from A.M. Kuchling: The 'output formatting' section of the tutorial talks a lot about manual formatting with things like .rjust() and .zfill(), with only a passing reference to 3.6's new f-strings. The attached patch doesn't drop all of the old material, but it does rearrange the topics into a more modern order: f-strings first, featuring the discussion of formatting specifiers; then calling .format(); finally manual formatting with .ljust(). Open question: ---------- assignee: docs at python components: Documentation files: tutorial-patch.txt keywords: needs review, patch messages: 280153 nosy: akuchling, docs at python priority: normal severity: normal stage: patch review status: open title: Tutorial: rearrange discussion of output formatting to encourage f-strings type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file45372/tutorial-patch.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 12:21:38 2016 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 06 Nov 2016 17:21:38 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za> Message-ID: <1478452898.14.0.386697606463.issue19569@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: _Pragma syntax would be more suitable since it could be used with macros: https://gcc.gnu.org/onlinedocs/gcc-6.2.0/cpp/Pragmas.html Then Include/pyport.h (which defines Py_DEPRECATED) could also define: #if defined(__GNUC__) && ((__GNUC__ >= 5) || (__GNUC__ == 4) && (__GNUC_MINOR__ >= 6)) #define Py_COMPILER_DIAGNOSTIC_PUSH _Pragma("GCC diagnostic push") #define Py_COMPILER_DIAGNOSTIC_IGNORE_DEPRECATED_DECLARATIONS _Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"") #define Py_COMPILER_DIAGNOSTIC_POP _Pragma("GCC diagnostic pop") #else #define Py_COMPILER_DIAGNOSTIC_PUSH #define Py_COMPILER_DIAGNOSTIC_IGNORE_DEPRECATED_DECLARATIONS #define Py_COMPILER_DIAGNOSTIC_POP #endif These macros would be used in this way: void some_function(void) { int x, y; Py_COMPILER_DIAGNOSTIC_PUSH Py_COMPILER_DIAGNOSTIC_IGNORE_DEPRECATED_DECLARATIONS x = some_deprecated_function(); Py_COMPILER_DIAGNOSTIC_POP y = x + 1; } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 12:26:25 2016 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 06 Nov 2016 17:26:25 +0000 Subject: [issue28626] Tutorial: rearrange discussion of output formatting to encourage f-strings In-Reply-To: <1478452855.22.0.932657206329.issue28626@psf.upfronthosting.co.za> Message-ID: <1478453185.6.0.599576465338.issue28626@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Oh, I didn't finish my thought on open questions: should we just drop the discussion of .ljust(), .zfill(), or should it be there so users are aware of it? Similarly, is it still worth mentioning string.Template? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 12:32:35 2016 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 06 Nov 2016 17:32:35 +0000 Subject: [issue21864] Error in documentation of point 9.8 'Exceptions are classes too' In-Reply-To: <1403653260.15.0.739232303856.issue21864@psf.upfronthosting.co.za> Message-ID: <1478453555.53.0.0394685408368.issue21864@psf.upfronthosting.co.za> A.M. Kuchling added the comment: The patch looks good to me; I think it should just be applied. ---------- nosy: +akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 12:37:47 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 06 Nov 2016 17:37:47 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478453867.49.0.625885045849.issue28563@psf.upfronthosting.co.za> Xiang Zhang added the comment: gettext_c2py_v2.patch implements a simple C expression parser. More tests are included. Carl, hope you are willing to test it. ---------- Added file: http://bugs.python.org/file45373/gettext_c2py_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 12:40:57 2016 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 06 Nov 2016 17:40:57 +0000 Subject: [issue12913] Add a debugging howto In-Reply-To: <1315323088.65.0.459623812563.issue12913@psf.upfronthosting.co.za> Message-ID: <1478454057.6.0.304237297197.issue12913@psf.upfronthosting.co.za> A.M. Kuchling added the comment: ?ric Araujo: did you ever make any progress on this, such as producing a draft version? ---------- nosy: +akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 13:01:02 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 Nov 2016 18:01:02 +0000 Subject: [issue21864] Error in documentation of point 9.8 'Exceptions are classes too' In-Reply-To: <1403653260.15.0.739232303856.issue21864@psf.upfronthosting.co.za> Message-ID: <20161106180059.111593.88899.FFCA15E6@psf.io> Roundup Robot added the comment: New changeset db6d556365d7 by Berker Peksag in branch '3.5': Issue #21864: Remove outdated section about exceptions from the tutorial https://hg.python.org/cpython/rev/db6d556365d7 New changeset f82e348946e3 by Berker Peksag in branch '3.6': Issue #21864: Merge from 3.5 https://hg.python.org/cpython/rev/f82e348946e3 New changeset 6ec669efeea5 by Berker Peksag in branch 'default': Issue #21864: Merge from 3.6 https://hg.python.org/cpython/rev/6ec669efeea5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 13:02:38 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 06 Nov 2016 18:02:38 +0000 Subject: [issue21864] Error in documentation of point 9.8 'Exceptions are classes too' In-Reply-To: <1403653260.15.0.739232303856.issue21864@psf.upfronthosting.co.za> Message-ID: <1478455358.0.0.993256920735.issue21864@psf.upfronthosting.co.za> Berker Peksag added the comment: Thank you for the review, Andrew! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 13:15:13 2016 From: report at bugs.python.org (paul j3) Date: Sun, 06 Nov 2016 18:15:13 +0000 Subject: [issue28609] argparse claims '*' positional argument is required in error output In-Reply-To: <1478272763.12.0.609109547521.issue28609@psf.upfronthosting.co.za> Message-ID: <1478456113.24.0.337071569136.issue28609@psf.upfronthosting.co.za> paul j3 added the comment: The current error message is the result of http://bugs.python.org/issue10424 and http://bugs.python.org/issue12776 Before the test was just: if positionals: self.error(_('too few arguments')) The 2nd patch reworked the test to include the revised handling of defaults. So the current error message just lists all the positionals which haven't been consumed. ARGUMENT wasn't consumed because COMMAND wasn't consumed. And technically that would be true even if ARGUMENT required arguments. Well, to be pickier, it as a 're' pattern like 'AA*' that failed. The proposed patch looks like it would work, but I haven't tested or looked at the unittests. But I wonder if such a patch is really needed. Are users really misled by the the current message? =============== As for the usage, the current version allows you to give a tuple METAVAR, producing lines like: In [359]: a.metavar=('A','B') In [360]: parser.print_usage() usage: ipython3 [-h] [A [B ...]] In [361]: a.nargs='+' In [362]: parser.print_usage() usage: ipython3 [-h] A [B ...] This display pattern is generated in HelpFormater._format_args, with these lines elif action.nargs == ZERO_OR_MORE: result = '[%s [%s ...]]' % get_metavar(2) elif action.nargs == ONE_OR_MORE: result = '%s [%s ...]' % get_metavar(2) elif action.nargs == REMAINDER: result = '...' You could subclass HelpFormatter, and replace this method with one that performs as you want, (I just tried this) result = '[%s ...]' % get_metavar(1) I wouldn't recommend this as default change, but if there was a enough demand it could added as another HelpFormatter subclass. METAVAR lets me approximate your shorter version: In [4]: p.print_usage() usage: ipython3 [-h] [pos [pos ...]] In [5]: a.metavar=('pos','') In [6]: p.print_usage() usage: ipython3 [-h] [pos [...]] In [7]: a.nargs='+' In [8]: p.print_usage() usage: ipython3 [-h] pos [...] It still has the [], but the name is gone. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 13:30:27 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 Nov 2016 18:30:27 +0000 Subject: [issue21590] Systemtap and DTrace support In-Reply-To: <1401195995.8.0.935339035852.issue21590@psf.upfronthosting.co.za> Message-ID: <20161106183024.111739.33385.46FFABF0@psf.io> Roundup Robot added the comment: New changeset d05d312161f2 by Berker Peksag in branch '3.6': Issue #21590: Silence Sphinx warnings in instrumentation.rst https://hg.python.org/cpython/rev/d05d312161f2 New changeset 442453fa3370 by Berker Peksag in branch 'default': Issue #21590: Merge from 3.6 https://hg.python.org/cpython/rev/442453fa3370 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 13:32:25 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 06 Nov 2016 18:32:25 +0000 Subject: [issue21590] Systemtap and DTrace support In-Reply-To: <1401195995.8.0.935339035852.issue21590@psf.upfronthosting.co.za> Message-ID: <1478457145.7.0.785121670381.issue21590@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks. SilentGhost. I went with ".. highlight:: shell-session" to simplify the patch a bit. ?ukasz, can we close this one and create new issues for further improvements now? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 13:57:44 2016 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 06 Nov 2016 18:57:44 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <1478458664.84.0.0360629276989.issue28587@psf.upfronthosting.co.za> A.M. Kuchling added the comment: The patch looks fine, though I suggest clarifying the example for a.index(333, 2) by adding a comment such as '# begin searching at index 2' to explain what's going on. ---------- nosy: +akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 14:07:18 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 06 Nov 2016 19:07:18 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <1478459238.64.0.18158908659.issue28587@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks for the feedback :) Makes sense, I'll work on another patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 14:42:12 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 06 Nov 2016 19:42:12 +0000 Subject: [issue26855] android: add platform.android_ver() In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za> Message-ID: <1478461332.9.0.671059497538.issue26855@psf.upfronthosting.co.za> Xavier de Gaye added the comment: ANDROID_API_LEVEL can only be used in the Python test suite and platform.android_ver() must be used in the standard library. The reason why ANDROID_API_LEVEL can be used in the tests instead of using the runtime API level is that the Python test suite purpose is not to test the compatibilities betweeen all the possible subjacent bionic libc(s) and the tests need only be run on the platform for which they have been built. platform.android_ver() is a welcome enhancement, and since we are at 3.6 beta now it's too late for 3.6 and it will be implemented in 3.7. Sorry about this delay. ---------- assignee: -> xdegaye components: +Library (Lib) stage: -> patch review versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 14:44:51 2016 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 06 Nov 2016 19:44:51 +0000 Subject: [issue6519] Reorder 'with' statement for files in Python Tutorial In-Reply-To: <1247966369.75.0.40232300258.issue6519@psf.upfronthosting.co.za> Message-ID: <1478461491.21.0.130125007177.issue6519@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Good suggestion -- here's a patch that moves it and rewrites a little. ---------- nosy: +akuchling Added file: http://bugs.python.org/file45374/issue6519.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 15:28:31 2016 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 06 Nov 2016 20:28:31 +0000 Subject: [issue8840] truncate() semantics changed in 3.1.2 In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za> Message-ID: <1478464111.49.0.621045669787.issue8840@psf.upfronthosting.co.za> A.M. Kuchling added the comment: "Why, this is a simple docstring change. How difficult can it be?", I thought. Ah ha ha ha. Here's a patch against the 3.5 branch. It should also apply cleanly to 3.6 or 3.7, except for a little Argument Clinic noise. The patch changes 3 occurrences of the truncate() docstring in Lib/_pyio.py, and 1 each in Modules/_io/{bytesio.c,fileio.c,iobase.c,stringio.c}. Whew! Do we want to change all of these occurrences, or just the one specific case of StringIO? It seemed to me that we want to change them all. ---------- nosy: +akuchling Added file: http://bugs.python.org/file45375/issue8840.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 15:35:18 2016 From: report at bugs.python.org (paul j3) Date: Sun, 06 Nov 2016 20:35:18 +0000 Subject: [issue28609] argparse claims '*' positional argument is required in error output In-Reply-To: <1478272763.12.0.609109547521.issue28609@psf.upfronthosting.co.za> Message-ID: <1478464518.53.0.973389389782.issue28609@psf.upfronthosting.co.za> paul j3 added the comment: Try `nargs='?'` or try providing a `default` along with the '*'. Including your ARGUMENT action in the error message is intentional. The test for this error message is: required_actions = [] for action in self._actions: if action not in seen_actions: if action.required: Originally the code just checked if `positionals` was empty. That was the list of positional Actions. Actions were popped as they were parsed. Now it maintains a set `seen_actions`, and checks the `required` attribute. This test applies to both positionals and optionals. For optionals, `required` is set by the programmer. But for positionals it is set with: def _get_positional_kwargs ... # mark positional arguments as required if at least one is # always required if kwargs.get('nargs') not in [OPTIONAL, ZERO_OR_MORE]: kwargs['required'] = True if kwargs.get('nargs') == ZERO_OR_MORE and 'default' not in kwargs: kwargs['required'] = True So for '?' argument, required is False. But for '*', it must also have a 'default' parameter (not just the default None). So the proposed patch is overriding the 'required' value that was set during 'add_argument'. And issuing this error message is the main purpose of the 'required' attribute. I would not implement this patch. But it would be a good idea to check if this method of setting the required attribute has been discussed in other bug/issues. (There is an open issue concerning how the 'required' is set/or not for the subparsers positional.) Off hand I don't see anything about this in the documentation. Maybe that's what needs to be patched. (It's easier and safer to change the documentation than the working code. Backward compatibility is a major concern when changing the code.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 15:42:49 2016 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 06 Nov 2016 20:42:49 +0000 Subject: [issue1778] SyntaxError.offset sometimes wrong In-Reply-To: <1199920786.95.0.62807405199.issue1778@psf.upfronthosting.co.za> Message-ID: <1478464969.33.0.104252626038.issue1778@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Fixed in Python 3.2 alpha 3, so there's no longer any work to be done for this issue. Closing. ---------- nosy: +akuchling resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 15:55:46 2016 From: report at bugs.python.org (Reuben Thomas) Date: Sun, 06 Nov 2016 20:55:46 +0000 Subject: [issue28609] argparse claims '*' positional argument is required in error output In-Reply-To: <1478272763.12.0.609109547521.issue28609@psf.upfronthosting.co.za> Message-ID: <1478465746.7.0.134589554021.issue28609@psf.upfronthosting.co.za> Reuben Thomas added the comment: > Try `nargs='?'` or try providing a `default` along with the '*'. Why would I do that? I want 0 or more arguments, and there's no default value. > Including your ARGUMENT action in the error message is intentional. It will likely confuse the user. The syntax message says that it's optional, the error suggests (wrongly) that it is required. Patching the Python documentation will not help in this case, because the user of my program will not be reading the Python documentation to understand how it works, only the program's own documentation. Note that I did not suggest that the behavior be changed, only the message that is output. The analysis of why the message is output is useful, but it does not demonstrate that the error message is correct; the error message, as I've already demonstrated, is undeniably wrong. In no sense is "ARGUMENT" missing, because 0 occurrences are entirely legal. Therefore although in terms of the API the argument is "required", it makes no sense to tell the user this (the user will assume that "required" has its colloquial sense, not a technical sense). I entirely sympathise with the argument that the behavior of argparse should not change; I see nothing wrong with the behavior, in any case. The problems are purely cosmetic: 1. The syntax message says, redundantly and confusingly, "[ARGUMENT [ARGUMENT ...]]" where it should say just "[ARGUMENT ...]". 2. The error message says that ARGUMENT is "required", whereas, from the user's point of view, it clearly is not. These are serious annoyances from the developer's point of view (in this case, from my point of view), because they mean that in order to release a production-quality tool, I have to hack around argparse's shortcomings. So in fact, you're quite right that the documentation should be fixed; only in this case it is the documentation generated by argparse, not the documentation of argparse (which, again, is fine as far as I can see). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 15:57:44 2016 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 06 Nov 2016 20:57:44 +0000 Subject: [issue4713] Installing sgmlop causes xmlrpclib error In-Reply-To: <1229895007.0.0.481278630748.issue4713@psf.upfronthosting.co.za> Message-ID: <1478465864.32.0.195719154511.issue4713@psf.upfronthosting.co.za> A.M. Kuchling added the comment: I don't believe this bug is still present in Python 2.7. Issue #5767 removed sgmlop support from xmlrpclib in 2.7 alpha 1, and trying the test program succeeds. Closing. ---------- nosy: +akuchling resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 16:11:39 2016 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 06 Nov 2016 21:11:39 +0000 Subject: [issue11368] Document why xml.etree.ElementTree.Element has no reference to parent In-Reply-To: <1299031116.52.0.175842807219.issue11368@psf.upfronthosting.co.za> Message-ID: <1478466699.83.0.920092713312.issue11368@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Closing this old issue. ---------- nosy: +akuchling status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 16:14:53 2016 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 06 Nov 2016 21:14:53 +0000 Subject: [issue9621] Graphviz output for 2to3 fixer patterns In-Reply-To: <1281973199.06.0.194769344976.issue9621@psf.upfronthosting.co.za> Message-ID: <1478466893.52.0.35831602711.issue9621@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Matt, do you just want to drop the issue or provide a new patch? Your code might well still be useful, but it's been 6 years, so you may not even have the code any longer. ---------- nosy: +akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 16:21:12 2016 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 06 Nov 2016 21:21:12 +0000 Subject: [issue10605] ElementTree documentation In-Reply-To: <1291301477.25.0.932243074052.issue10605@psf.upfronthosting.co.za> Message-ID: <1478467272.35.0.0156432189253.issue10605@psf.upfronthosting.co.za> A.M. Kuchling added the comment: I don't see an 'entity' argument or attribute for TreeBuilder either. XMLParser has a .entity attribute, though. Perhaps this was simple confusion? Adrian: please feel free to re-open and provide a patch if there's actually a bug here. ---------- nosy: +akuchling resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 16:26:56 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 06 Nov 2016 21:26:56 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <1478467616.17.0.799892648202.issue28587@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Here is an updated patch. Please review :) Thanks. ---------- Added file: http://bugs.python.org/file45376/issue28587v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 16:53:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Nov 2016 21:53:54 +0000 Subject: [issue25996] Add support of file descriptor in os.scandir() In-Reply-To: <1451758238.49.0.729670752807.issue25996@psf.upfronthosting.co.za> Message-ID: <1478469234.59.0.00287175870654.issue25996@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch adds support for file descriptors in os.scandir() and implements os.fwalk() with os.scandir(). The effect of using os.scandir() in os.fwalk(): $ ./python -m timeit -n1 -r5 -s 'import os' -- 'list(os.walk("/usr/lib"))' 1 loop, best of 5: 934 msec per loop $ ./python -m timeit -n1 -r5 -s 'import os' -- 'list(os.walk("/usr/lib", topdown=False))' 1 loop, best of 5: 718 msec per loop $ ./python -m timeit -n1 -r5 -s 'import os' -- 'list(os.fwalk("/usr/lib"))' Unpatched: 1 loops, best of 5: 1.78 sec per loop Patched: 1 loop, best of 5: 934 msec per loop $ ./python -m timeit -n1 -r5 -s 'import os' -- 'list(os.fwalk("/usr/lib", topdown=False))' Unpatched: 1 loops, best of 5: 1.76 sec per loop Patched: 1 loop, best of 5: 947 msec per loop ---------- keywords: +patch stage: -> patch review versions: +Python 3.7 -Python 3.6 Added file: http://bugs.python.org/file45377/os-scandir-fd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 16:54:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Nov 2016 21:54:24 +0000 Subject: [issue28586] Convert os.scandir to Argument Clinic In-Reply-To: <1478075596.56.0.454562353142.issue28586@psf.upfronthosting.co.za> Message-ID: <1478469264.07.0.553277851108.issue28586@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 16:55:53 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Nov 2016 21:55:53 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478469353.53.0.0928084448195.issue28563@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 17:34:31 2016 From: report at bugs.python.org (Israel Fruchter) Date: Sun, 06 Nov 2016 22:34:31 +0000 Subject: [issue28627] [alpine] shutil.copytree fail to copy a direcotry with broken symlinks Message-ID: <1478471671.65.0.611428361622.issue28627@psf.upfronthosting.co.za> New submission from Israel Fruchter: this fails on python3.5-alpine and python3.6-alpine (works as fine in python2.7-alpine) cd /bug && ln -s /broken_path/to_nowhere broken python -c "import shutil; shutil.copytree('/bug', '/temp', symlinks=True)" Dockerfile example here: https://github.com/docker-library/python/issues/155 https://github.com/python/cpython/blob/c30098c8c6014f3340a369a31df9c74bdbacc269/Lib/shutil.py#L198 seem like its suppressing NotImplementedError, and in our case OsError with ENOSUP was raised ---------- components: Library (Lib) messages: 280178 nosy: fruch priority: normal severity: normal status: open title: [alpine] shutil.copytree fail to copy a direcotry with broken symlinks type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 17:36:28 2016 From: report at bugs.python.org (Israel Fruchter) Date: Sun, 06 Nov 2016 22:36:28 +0000 Subject: [issue28627] [alpine] shutil.copytree fail to copy a direcotry with broken symlinks In-Reply-To: <1478471671.65.0.611428361622.issue28627@psf.upfronthosting.co.za> Message-ID: <1478471788.41.0.478164293495.issue28627@psf.upfronthosting.co.za> Israel Fruchter added the comment: the failure looks like that: Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python3.5/shutil.py", line 359, in copytree raise Error(errors) shutil.Error: [('/bug/broken', '/temp/broken', "[Errno 95] Not supported: '/temp/broken'")] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 18:27:24 2016 From: report at bugs.python.org (Harry Li) Date: Sun, 06 Nov 2016 23:27:24 +0000 Subject: [issue24658] open().write() fails on 2 GB+ data (OS X) In-Reply-To: <1437188368.42.0.0977367912313.issue24658@psf.upfronthosting.co.za> Message-ID: <1478474844.16.0.659106562834.issue24658@psf.upfronthosting.co.za> Changes by Harry Li : ---------- nosy: +Harry Li _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 20:00:15 2016 From: report at bugs.python.org (paul j3) Date: Mon, 07 Nov 2016 01:00:15 +0000 Subject: [issue28609] argparse claims '*' positional argument is required in error output In-Reply-To: <1478272763.12.0.609109547521.issue28609@psf.upfronthosting.co.za> Message-ID: <1478480415.47.0.991180559955.issue28609@psf.upfronthosting.co.za> paul j3 added the comment: Simply including a `default` parameter, even with the default default None, changes the error message In [395]: parser=argparse.ArgumentParser() In [396]: parser.add_argument('cmd'); In [397]: a=parser.add_argument('args',nargs='*',default=None) In [398]: a.required Out[398]: False In [399]: parser.parse_args([]) usage: ipython3 [-h] cmd [args [args ...]] ipython3: error: the following arguments are required: cmd You shouldn't see any other changes in behavior (except maybe if the positional is in a mutually_exclusive_group). The code that sets 'required' for positionals only looks for the presence of the parameter in kwargs, not its value: `'default' not in kwargs`. An alternative is to change the value of 'required' after creation: a.required = False Anyways I remain convinced that changing the 'required' attribute is the correct way to change the error message, not adding more tests to the message generator. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 20:19:33 2016 From: report at bugs.python.org (paul j3) Date: Mon, 07 Nov 2016 01:19:33 +0000 Subject: [issue28609] argparse claims '*' positional argument is required in error output In-Reply-To: <1478272763.12.0.609109547521.issue28609@psf.upfronthosting.co.za> Message-ID: <1478481573.03.0.222586884925.issue28609@psf.upfronthosting.co.za> paul j3 added the comment: My suggestion to use `metavar=('A','')` to streamline the usage creates problems with the help code http://bugs.python.org/issue14074 The tuple metavar does not work right for positionals. That's a old issue that should have been fixed long ago. So streamlining the usage has to be done with a custom HelpFormatter subclass. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 20:43:19 2016 From: report at bugs.python.org (brotherBox) Date: Mon, 07 Nov 2016 01:43:19 +0000 Subject: [issue28628] Failure to add Message-ID: <1478482999.04.0.832898524101.issue28628@psf.upfronthosting.co.za> New submission from brotherBox: This is the first bug that I file, so please bear with me here. I was advised to file this after running into a strange situation with asyncio 3.4.3. Adding signal handlers for any other signal but SIGINT throws strange exceptions. The attached source code produces the following traceback: Exception ignored in: > Traceback (most recent call last): File "/usr/lib/python3.5/asyncio/base_events.py", line 501, in __del__ File "/usr/lib/python3.5/asyncio/unix_events.py", line 58, in close File "/usr/lib/python3.5/asyncio/unix_events.py", line 139, in remove_signal_handler File "/usr/lib/python3.5/signal.py", line 47, in signal TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, or a callable object I asked in #python on freenode and was asked to file this bug. Thank you for your consideration ---------- components: asyncio files: signal_bug.py messages: 280182 nosy: brotherBox, gvanrossum, yselivanov priority: normal severity: normal status: open title: Failure to add type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file45378/signal_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 21:04:36 2016 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 07 Nov 2016 02:04:36 +0000 Subject: [issue28628] Failure to add signal handlers for any signal but SIGINT In-Reply-To: <1478482999.04.0.832898524101.issue28628@psf.upfronthosting.co.za> Message-ID: <1478484276.8.0.207429844086.issue28628@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- title: Failure to add -> Failure to add signal handlers for any signal but SIGINT _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 21:26:28 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Nov 2016 02:26:28 +0000 Subject: [issue28622] Remove redundant variable annotation test from test_grammar In-Reply-To: <1478423511.13.0.191601822692.issue28622@psf.upfronthosting.co.za> Message-ID: <20161107022625.29886.89234.6C35F11F@psf.io> Roundup Robot added the comment: New changeset 048f82c86928 by Guido van Rossum in branch '3.6': issue #28622: Remove redundant variable annotation test from test_grammar. Ivan L. https://hg.python.org/cpython/rev/048f82c86928 New changeset e60c1aef639a by Guido van Rossum in branch 'default': issue #28622: Remove redundant variable annotation test from test_grammar. Ivan L. (3.6->3.7) https://hg.python.org/cpython/rev/e60c1aef639a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 21:27:14 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Nov 2016 02:27:14 +0000 Subject: [issue28622] Remove redundant variable annotation test from test_grammar In-Reply-To: <1478423511.13.0.191601822692.issue28622@psf.upfronthosting.co.za> Message-ID: <1478485634.64.0.0746313264377.issue28622@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 21:34:00 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Nov 2016 02:34:00 +0000 Subject: [issue28628] Failure to add signal handlers for any signal but SIGINT In-Reply-To: <1478482999.04.0.832898524101.issue28628@psf.upfronthosting.co.za> Message-ID: <1478486040.71.0.701268479134.issue28628@psf.upfronthosting.co.za> Guido van Rossum added the comment: Hm... We've seen this exact same crash reported several times before, and it was closed without a fix AFAICT each time. - https://github.com/python/asyncio/issues/396 - http://bugs.python.org/issue23548 IIUC the conclusion in the latter was that this is due to a bug in the user code (forgetting to close() the event loop). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 21:50:31 2016 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 07 Nov 2016 02:50:31 +0000 Subject: [issue28629] Emit ResourceWarning when implicitly terminating a suspended frame? Message-ID: <1478487031.39.0.63356302946.issue28629@psf.upfronthosting.co.za> New submission from Nick Coghlan: There have been a few discussions recently regarding the fact that generator and coroutine cleanup can suppress ResourceWarnings from other components. For example: def mygen(fname): with open(fname) as f: yield from f print(next(mygen("README.md"))) Here, the opened file is actually being cleaned up by __del__ on the generator-iterator instance (when it throws GeneratorExit into the suspended frame), but there's no ResourceWarning as the *file itself* is being cleaned up by the file's __exit__ method. I've been thinking about how we might be able to help developers better manage this, and one conclusion I've come to is that it means we need to start thinking about suspended frames that don't terminate naturally during the course of program execution as resources to be managed - their locals can and do reference scarce system resources, and folks are expecting "with" and "try-finally" statements to provide reliable management of those resources, even when there's a "yield", "yield from" or "await" in the nested suite. So what do folks think of the idea of making __del__ on generator-iterator objects emit ResourceWarning in cases where: - gi_frame is not None (i.e. the frame hasn't completed execution) - gi_frame.f_lasti isn't -1 (i.e. the frame has started execution) and similarly for coroutines and cr_frame? ---------- messages: 280185 nosy: haypo, ncoghlan, njs, yselivanov priority: normal severity: normal status: open title: Emit ResourceWarning when implicitly terminating a suspended frame? type: resource usage versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 22:36:05 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Nov 2016 03:36:05 +0000 Subject: [issue27781] Change sys.getfilesystemencoding() on Windows to UTF-8 In-Reply-To: <1471405781.01.0.933321108026.issue27781@psf.upfronthosting.co.za> Message-ID: <20161107033602.30882.81321.87FAE4C2@psf.io> Roundup Robot added the comment: New changeset b26c8104e54f by Steve Dower in branch '3.6': Closes #27781: Removes special cases for the experimental aspect of PEP 529 https://hg.python.org/cpython/rev/b26c8104e54f New changeset b8233c779ff7 by Steve Dower in branch 'default': Closes #27781: Removes special cases for the experimental aspect of PEP 529 https://hg.python.org/cpython/rev/b8233c779ff7 ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 6 23:05:37 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 07 Nov 2016 04:05:37 +0000 Subject: [issue28623] Let `shlex.quote` accept a `PathLike` object In-Reply-To: <1478425476.42.0.524210940005.issue28623@psf.upfronthosting.co.za> Message-ID: <1478491537.65.0.0926571318699.issue28623@psf.upfronthosting.co.za> R. David Murray added the comment: Which IMO is correct. shlex.quote takes an arbitrary string, not a filename. I'm -1 on this proposal. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 00:23:31 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 07 Nov 2016 05:23:31 +0000 Subject: [issue28398] Return singleton empty string in _PyUnicode_FromASCII In-Reply-To: <1476028146.3.0.529072270103.issue28398@psf.upfronthosting.co.za> Message-ID: <1478496211.53.0.81904914489.issue28398@psf.upfronthosting.co.za> Xiang Zhang added the comment: IMHO, _PyUnicode_FromASCII is a private API and could be used in other places in future. We should not rely on the caller to check and return the singleton empty string. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 01:06:55 2016 From: report at bugs.python.org (Nathaniel Smith) Date: Mon, 07 Nov 2016 06:06:55 +0000 Subject: [issue28629] Emit ResourceWarning when implicitly terminating a suspended frame? In-Reply-To: <1478487031.39.0.63356302946.issue28629@psf.upfronthosting.co.za> Message-ID: <1478498815.31.0.932784161658.issue28629@psf.upfronthosting.co.za> Nathaniel Smith added the comment: +1 to the change for generators. This is actually in the PEP 533 draft: https://www.python.org/dev/peps/pep-0533/#modifications-to-basic-iterator-types For coroutines, doesn't this overlap with the existing "coroutine not awaited" warning? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 03:21:23 2016 From: report at bugs.python.org (Daisuke Miyakawa) Date: Mon, 07 Nov 2016 08:21:23 +0000 Subject: [issue28630] setup.py bdist_egg --without-source-files does not allow console_script to run as expected Message-ID: <1478506883.78.0.576279801129.issue28630@psf.upfronthosting.co.za> New submission from Daisuke Miyakawa: I'm trying to prepare an egg file "without source code". I works mostly, while console_script does not. Here's a sample project for it, in which the function "greeting.greeting.greeting()" prints "Greeting!". https://github.com/dmiyakawa/python_greeting First, I tried creating an egg with source code, which worked perfectly as a standalone script (console_script). -- $ python --version Python 3.5.2 $ python setup.py bdist_egg .. $ easy_install dist/greeting-1.0.0-py3.5.egg .. $ greeting Greeting! $ pip unistnall greeting (it uninstalls, but with some exception..) -- Next, I tried creating an egg without source code, which is what I want to do. The package was installed but did not work as a standalone script (console_script). Note that I can use it from interactive shell. -- $ python setup.py bdist_egg --exclude-source-files .. $ easy_install dist/greeting-1.0.0-py3.5.egg .. $ greeting Traceback (most recent call last): File "/Users/dmiyakawa/.pyenv/versions/3.5.2/bin/greeting", line 9, in load_entry_point('greeting==1.0.0', 'console_scripts', 'greeting')() File "/Users/dmiyakawa/.pyenv/versions/3.5.2/lib/python3.5/site-packages/pkg_resources/__init__.py", line 542, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/Users/dmiyakawa/.pyenv/versions/3.5.2/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2569, in load_entry_point return ep.load() File "/Users/dmiyakawa/.pyenv/versions/3.5.2/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2229, in load return self.resolve() File "/Users/dmiyakawa/.pyenv/versions/3.5.2/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2235, in resolve module = __import__(self.module_name, fromlist=['__name__'], level=0) ImportError: No module named 'greeting' $ python Python 3.5.2 (default, Oct 24 2016, 21:47:12) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from greeting.greeting import greeting >>> greeting() Greeting! -- I saw this behavior both on Mac (Siera), Windows (64bits), and Linux (Debian Jessie). With pyenv, I tried the same thing with Python 3.6.0b3 (on Mac). Same there. ---------- components: Build messages: 280190 nosy: Daisuke Miyakawa priority: normal severity: normal status: open title: setup.py bdist_egg --without-source-files does not allow console_script to run as expected type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 03:37:15 2016 From: report at bugs.python.org (Carl Ekerot) Date: Mon, 07 Nov 2016 08:37:15 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478507835.52.0.094942098159.issue28563@psf.upfronthosting.co.za> Carl Ekerot added the comment: Judging by the code, this seems to be a much more rigid implementation. I've only run the unit tests and some variations of my initial examples, and everything seems to work as intended. Will look at it more closely this afternoon. One thing that caught my attention in the patch is that gettext.c2py is removed entirely. I know that this function is not exposed in the docs or in __all__, but it still has "public scope" and it's likely used directly in the wild (googling the signature confirms this). Perhaps it should give a DeprectationWarning and delegate to _Plural? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 03:40:17 2016 From: report at bugs.python.org (Michael Felt) Date: Mon, 07 Nov 2016 08:40:17 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za> Message-ID: <1478508017.41.0.101570068458.issue19569@psf.upfronthosting.co.za> Michael Felt added the comment: I am not compiler specialist, but as I do not use GCC (it adds extra run-time environment (support) requirements when not in a GNU environment such as Linux - I am just wondering what effect this has (e.g., no deprecated message) when not using GCC. Or, is this a "statement of direction" that only GCC (syntax) compilers are (going to be) supported? (FYI: there are OSS projects that only accept GCC, and those tend to be non-portable (imho). The "solution" in those cases is to build an additional run-time environment. Personally, I consider that non-portable as I do not want the role of having to maintain security patches for a "non-native" runtime environment (i.e., the maintenance of the (native) rte is performed by the OS supplier, not by me). ---------- nosy: +Michael.Felt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 03:56:04 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Nov 2016 08:56:04 +0000 Subject: [issue28629] Emit ResourceWarning when implicitly terminating a suspended frame? In-Reply-To: <1478487031.39.0.63356302946.issue28629@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: To take a decision, I would suggest to implement the warning, run the Python test suite, and run the test suite of a few applications like Twisted and Django, to see how much code needs to be modified. Well, let's say that my code consumes a generator but emits the warning because it doesn't consume completely the warning. What am I supposed to do? Let's say the the generator is an infine suite like (2**i for i in itertools.count()). Should I call gen.close()? If a generator holds a resource like a file, does gen.close() immediately release the resource? Or does it rely on the garbage collector? I'm curious to see if using source=frame when emitting the warning helps to identify quickly the origin of the bug. I added the source parameter in Python 3.6. It requires the usage of tracemalloc to log where the source object (the frame in this case) was allocated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 04:04:40 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 07 Nov 2016 09:04:40 +0000 Subject: [issue26934] android: test_faulthandler fails In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za> Message-ID: <1478509480.27.0.81567461983.issue26934@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Thanks for the suggestion Victor. The decorator may be used in other tests as well, and referring to the concern raised by Chi Hsuan in msg280147 and my answer, it makes it more clear that the build time _android_api_level should not be used in the standard library itself. New patch. ---------- Added file: http://bugs.python.org/file45379/buggy_raise_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 04:05:30 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Nov 2016 09:05:30 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za> Message-ID: <1478509530.96.0.107771287808.issue19569@psf.upfronthosting.co.za> STINNER Victor added the comment: > Proposed patch marks most deprecated functions. Code is rewritten for using non-deprecated functions if possible. Unfortunately some deprecated function still are used in the code and can't be easier replaced. They are left not marked. Hum, I suggest to first update these functions instead of using compiler tricks to ignore deprecation warnings. Once CPython code base doesn't use deprecated functions anymore, deprecate functions (emit a warning). > All these cases needs separate issues. I agree :-) * PyEval_ReleaseLock() is used in Python/pystate.c. It can't be replaced with PyEval_ReleaseThread() since the latter don't accept NULL. Does this feature (accept NULL) make sense outside CPython core? If not, add a private function exposing the feature. > * Py_UNICODE (currently an alias of wchar_t) is used in a number of deprecated functions and bridges between deprecated and new APIs. Maybe it can be just replaced with wchar_t. Which functions are bridges? Would it be possible to split these bridges into two functions: a private function which doesn't emit a warning, and a public deprecated function which calls the private function? I dislike the idea of replacing Py_UNICODE* with wchar_t*. > * Macros PyUnicode_GET_SIZE, PyUnicode_GET_DATA_SIZE, PyUnicode_AS_UNICODE, PyUnicode_AS_DATA, functions PyUnicode_AsUnicode and PyUnicode_AsUnicodeAndSize are used in a number of places. They can't be easily replaced with wchar-based functions since they return a borrowed reference to cached representation. We must not used these functions in CPython core, except to develop the "bridges" you mentionned before. Please open a separated issue to discuss how to handle the deprecation of the functions using Py_UNICODE*. * PyUnicode_FromUnicode, PyUnicode_EncodeDecimal and PyUnicode_TransformDecimalToASCII are used only in Modules/_testcapimodule.c. I think we should write tests for modern APIs and eliminate tests for deprecated APIs. Or temporary silence compiler warning in test functions. * _PyUnicode_ToLowercase, _PyUnicode_ToUppercase and corresponding public macros Py_UNICODE_TOLOWER and Py_UNICODE_TOUPPER are used in Modules/_sre.c (this is a bug in regex implementation). The problem is that more modern functions _PyUnicode_ToLowerFull and _PyUnicode_ToUpperFull is a private API. "Py_UCS4 _PyUnicode_ToLowercase(Py_UCS4 ch)" doesn't use Py_UNICODE, what is the issue? "#define Py_UNICODE_ISDECIMAL(ch) _PyUnicode_IsDecimalDigit(ch)" this macro doesn't use the Py_UNICODE type, so we don't have to deprecate it. Do you want to deprecate functions like Py_UNICODE_ISDECIMAL(ch)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 04:13:09 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 07 Nov 2016 09:13:09 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478509989.18.0.668676687251.issue28563@psf.upfronthosting.co.za> Xiang Zhang added the comment: > Perhaps it should give a DeprectationWarning and delegate to _Plural? I hold a conservative opinion about this. c2py in my mind should be a inner help method. It's not documented so if there are users using it, they are risking changes. And as reported here, it's buggy and dangerous. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 07:09:11 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 07 Nov 2016 12:09:11 +0000 Subject: [issue26934] android: test_faulthandler fails In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za> Message-ID: <1478520551.32.0.967192066535.issue26934@psf.upfronthosting.co.za> Xavier de Gaye added the comment: New patch following Victor code review. ---------- Added file: http://bugs.python.org/file45380/buggy_raise_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 07:16:00 2016 From: report at bugs.python.org (Michael Foord) Date: Mon, 07 Nov 2016 12:16:00 +0000 Subject: [issue28569] mock.attach_mock should work with any return value of patch() In-Reply-To: <1477935134.31.0.733482108189.issue28569@psf.upfronthosting.co.za> Message-ID: <1478520960.73.0.0894520911168.issue28569@psf.upfronthosting.co.za> Michael Foord added the comment: attach_mock should use function.mock when it is passed a function created by autospec. It should also *probably* fail if given a non-mock object (although that would prevent people duck-typing and attaching a mock-like object so I'm open to discussion on that). ---------- stage: -> needs patch versions: -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 08:29:34 2016 From: report at bugs.python.org (Syed Suhail Ahmed) Date: Mon, 07 Nov 2016 13:29:34 +0000 Subject: [issue28569] mock.attach_mock should work with any return value of patch() In-Reply-To: <1477935134.31.0.733482108189.issue28569@psf.upfronthosting.co.za> Message-ID: <1478525374.82.0.688543085462.issue28569@psf.upfronthosting.co.za> Syed Suhail Ahmed added the comment: I would like to work on this issue. ---------- nosy: +Syed Suhail Ahmed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 08:46:49 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 07 Nov 2016 13:46:49 +0000 Subject: [issue27860] Improvements to ipaddress module In-Reply-To: <1472138068.64.0.756560879111.issue27860@psf.upfronthosting.co.za> Message-ID: <1478526409.67.0.561648995293.issue27860@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 08:59:02 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 07 Nov 2016 13:59:02 +0000 Subject: [issue28555] provid also sha-1 and sha-256 also on download links In-Reply-To: <1477732467.71.0.578620687465.issue28555@psf.upfronthosting.co.za> Message-ID: <1478527142.91.0.295168833372.issue28555@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 09:29:24 2016 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 07 Nov 2016 14:29:24 +0000 Subject: [issue28629] Emit ResourceWarning when implicitly terminating a suspended frame? In-Reply-To: <1478487031.39.0.63356302946.issue28629@psf.upfronthosting.co.za> Message-ID: <1478528964.54.0.995188265471.issue28629@psf.upfronthosting.co.za> Nick Coghlan added the comment: As Victor suggests, the reason I ended the issue title with a question mark is because I'm worried that doing this by default is likely to be too noisy to be useful. It's worth trying out though, even if it ends up being something we have to hide behind a -X flag. If that concern does prove well-founded, another possible way to go would be to change the way generators interact with the context management protocol. In order to ensure a clear exception when you accidentally leave out `contextlib.contextmanager`, they currently simply don't implement it, so you have to use `contextlib.closing` instead. However, you can't wrap an existing generator in that unconditionally, as you'll break direct calls (`closing` relies on `__enter__` to give callers transparent access to the original object). One way to thread that needle would be to offer a `contextlib.managed_generator` alternative decorator that tweaked the behaviour of that particular generator-iterator instance to: - emit a ResourceWarning in __del__ - support the context management protocol Unfortunately, I haven't been able to think of a particularly clean implementation strategy that wouldn't introduce undesirable runtime performance overheads. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 09:51:29 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 07 Nov 2016 14:51:29 +0000 Subject: [issue28574] Update bundled pip In-Reply-To: <1477976889.95.0.00775228376963.issue28574@psf.upfronthosting.co.za> Message-ID: <1478530289.45.0.568326793908.issue28574@psf.upfronthosting.co.za> Berker Peksag added the comment: It looks like this is now done in 0e69d97a408e (3.6) and be8b133d5d3e (default). Please reopen if I'm missing something here. ---------- nosy: +berker.peksag resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 09:55:23 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 07 Nov 2016 14:55:23 +0000 Subject: [issue28585] Restore docstring of os._isdir In-Reply-To: <1478075476.63.0.19722756431.issue28585@psf.upfronthosting.co.za> Message-ID: <1478530523.8.0.546755604337.issue28585@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 10:06:34 2016 From: report at bugs.python.org (Matthias Klose) Date: Mon, 07 Nov 2016 15:06:34 +0000 Subject: [issue28631] [2.7/3.5/3.6 Regression] crash using ctypes Message-ID: <1478531194.3.0.136911442919.issue28631@psf.upfronthosting.co.za> New submission from Matthias Klose: the following example started to segfault with the 2.7 branch 20161103, last working one 20160901, on 3.5 branch 20161103, last working one 20160922. from __future__ import print_function import ctypes import ctypes.util lib_location = ctypes.util.find_library('gettextpo') gpo = ctypes.cdll.LoadLibrary(lib_location) gpo_message = gpo.po_message_create() source = "foo" print("calling po_message_set_msgid") gpo.po_message_set_msgid(gpo_message, source.encode('utf-8')) print("success") #0 0x00007ffff5e74906 in po_message_set_msgid () from /usr/lib/x86_64-linux-gnu/libgettextpo.so.0 #1 0x00007ffff6a4b038 in ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6 #2 0x00007ffff6a4aa9a in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6 #3 0x00007ffff6c662ec in _call_function_pointer (flags=4353, pProc=0x7ffff5e74900 , avalues=0x7fffffffd9c0, atypes=0x7fffffffd9a0, restype=0x7ffff6e9c530, resmem=0x7fffffffd9e0, argcount=2) at ./Modules/_ctypes/callproc.c:841 #4 0x00007ffff6c66f61 in _ctypes_callproc ( pProc=0x7ffff5e74900 , argtuple=(1439158016, 'foo'), flags=4353, argtypes=0x0, restype=<_ctypes.PyCSimpleType at remote 0x555555c43d70>, checker=0x0) at ./Modules/_ctypes/callproc.c:1184 #5 0x00007ffff6c5f7e2 in PyCFuncPtr_call (self=0x7ffff6ea6a60, inargs=(1439158016, 'foo'), kwds=0x0) at ./Modules/_ctypes/_ctypes.c:3973 #6 0x00005555555b3151 in PyObject_Call ( func=<_FuncPtr(__name__='po_message_set_msgid') at remote 0x7ffff6ea6a60>, arg=(1439158016, 'foo'), kw=0x0) at ../Objects/abstract.c:2547 #7 0x00005555556c5cef in do_call ( func=<_FuncPtr(__name__='po_message_set_msgid') at remote 0x7ffff6ea6a60>, pp_stack=0x7fffffffde70, na=2, nk=0) at ../Python/ceval.c:4569 #8 0x00005555556c5082 in call_function (pp_stack=0x7fffffffde70, oparg=2) at ../Python/ceval.c:4374 #9 0x00005555556bf492 in PyEval_EvalFrameEx ( f=Frame 0x7ffff7e3bc00, for file foo.py, line 12, in (), throwflag=0) at ../Python/ceval.c:2989 ---------- components: Extension Modules keywords: 3.5regression messages: 280202 nosy: doko priority: high severity: normal status: open title: [2.7/3.5/3.6 Regression] crash using ctypes type: crash versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 10:25:03 2016 From: report at bugs.python.org (Erik Bray) Date: Mon, 07 Nov 2016 15:25:03 +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: <1478532303.15.0.214729604834.issue28459@psf.upfronthosting.co.za> Erik Bray added the comment: Hi Masayuki, thanks for the response (I thought I replied to this earlier but maybe I only imagined it--I've been on vacation). I agree with just about everything you write here. I'm aware of the FreeBSD setmode(), but I figured os.setmode() could do different things on different platforms as applicable. But that would also be very confusing. Your patch using ctypes looks fine to me--I considered doing the same, but what I'm not sure is if it's kosher to use ctypes here, given that it's techically an optional module. Since _pyio is, as I understand it, mainly used for testing it's probably fine? But I think we'll need some core maintainers' comments here... Implementing a cygwin module would be really nice, actually, even if it isn't included in the stdlib. There are a few other cygwin-specific APIs that it is useful to have wrappers around: https://cygwin.com/cygwin-api/cygwin-functions.html But that would be outside the scope of fixing this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 10:29:03 2016 From: report at bugs.python.org (Erik Bray) Date: Mon, 07 Nov 2016 15:29:03 +0000 Subject: [issue28441] Change sys.executable to include executable suffix In-Reply-To: <1476452085.73.0.180033377767.issue28441@psf.upfronthosting.co.za> Message-ID: <1478532543.78.0.920948877817.issue28441@psf.upfronthosting.co.za> Erik Bray added the comment: Thanks! Setting EXE_SUFFIX from the Makefile is much better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 10:29:33 2016 From: report at bugs.python.org (Erik Bray) Date: Mon, 07 Nov 2016 15:29:33 +0000 Subject: [issue28441] Change sys.executable to include executable suffix In-Reply-To: <1476452085.73.0.180033377767.issue28441@psf.upfronthosting.co.za> Message-ID: <1478532573.76.0.717730990096.issue28441@psf.upfronthosting.co.za> Changes by Erik Bray : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 10:56:24 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 07 Nov 2016 15:56:24 +0000 Subject: [issue28615] Document clarification: Section 5.4 Complex Number In-Reply-To: <1478286572.26.0.816720776987.issue28615@psf.upfronthosting.co.za> Message-ID: <1478534184.64.0.7091791628.issue28615@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- status: closed -> open type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 11:03:40 2016 From: report at bugs.python.org (Michael Layzell) Date: Mon, 07 Nov 2016 16:03:40 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1478534620.07.0.460223837619.issue25677@psf.upfronthosting.co.za> Michael Layzell added the comment: Is there something I should be doing to push this patch forward? I am not familiar with the contribution process for cpython unfortunately. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 11:22:48 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 07 Nov 2016 16:22:48 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1478535768.66.0.419432230926.issue25677@psf.upfronthosting.co.za> Berker Peksag added the comment: FWIW, I don't think the patch fixes the actual problem. With the patch applied, the caret still placed at the wrong place. I'd prefer avoid pushing a patch that fixes a bug by introducing another bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 11:26:06 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 07 Nov 2016 16:26:06 +0000 Subject: [issue28624] Make the `cwd` argument to `subprocess.Popen` accept a `PathLike` Message-ID: <1478535966.36.0.806225020252.issue28624@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 11:26:43 2016 From: report at bugs.python.org (Michael Layzell) Date: Mon, 07 Nov 2016 16:26:43 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1478536003.44.0.282612670131.issue25677@psf.upfronthosting.co.za> Michael Layzell added the comment: This patch fixes a problem, which is that the caret was not placed where the source location information for the node is, but instead in a random position based on the indentation level. The problem that the caret is not placed under the `=` sign, but instead at the front of the expression, feels like a different bug related to how source location information is computed throughout cpython for infix operators. I don't think it should be fixed in this bug, but rather in a follow-up. Specifically, this fix (to make the printing actually respect the source location information) will also be required in order to fix the placement of the caret to under the = sign. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 11:41:11 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 07 Nov 2016 16:41:11 +0000 Subject: [issue6519] Reorder 'with' statement for files in Python Tutorial In-Reply-To: <1247966369.75.0.40232300258.issue6519@psf.upfronthosting.co.za> Message-ID: <1478536871.99.0.0556288666964.issue6519@psf.upfronthosting.co.za> Berker Peksag added the comment: The patch looks good to me. I think we can tweak the content a bit. I left some comments on Rietveld. Thanks! ---------- nosy: +berker.peksag stage: needs patch -> patch review versions: +Python 3.5, Python 3.6, Python 3.7 -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 11:41:34 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 07 Nov 2016 16:41:34 +0000 Subject: [issue6519] Reorder 'with' statement for files in Python Tutorial In-Reply-To: <1247966369.75.0.40232300258.issue6519@psf.upfronthosting.co.za> Message-ID: <1478536894.51.0.00975744570214.issue6519@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 11:49:02 2016 From: report at bugs.python.org (Petr) Date: Mon, 07 Nov 2016 16:49:02 +0000 Subject: [issue28632] configparser does not close files in read Message-ID: <1478537342.33.0.595722710962.issue28632@psf.upfronthosting.co.za> New submission from Petr: When using configparser read method, the file(s) remains opened and cannot be closed, causing ResourceWarning: unclosed file. For example in the following code: config = configparser.ConfigParser() config.read(cfg_fn) ... the file cfg_fn remains opened and is only closed upon destruction of the underlying file object. At some point in history the method read used to close the file, but this has been changed for some reason. ---------- components: Library (Lib) messages: 280209 nosy: PetrPy priority: normal severity: normal status: open title: configparser does not close files in read type: resource usage versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 11:54:41 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 07 Nov 2016 16:54:41 +0000 Subject: [issue8840] truncate() semantics changed in 3.1.2 In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za> Message-ID: <1478537681.21.0.166200438013.issue8840@psf.upfronthosting.co.za> Berker Peksag added the comment: The patch looks good to me, but perhaps we should make these docstrings shorter and refer people to the actual documentation for details? We recently did this in subprocess and venv modules. ---------- nosy: +berker.peksag, martin.panter stage: needs patch -> patch review versions: +Python 3.6, Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 12:14:33 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Nov 2016 17:14:33 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478538873.74.0.197709756594.issue28563@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry Xiang, but your patch looks overcomplicated to me. Too much methods, decorators, classes, too much strange names. Here is simpler implementation with using only one recursive function. ---------- Added file: http://bugs.python.org/file45381/gettext-parse-plural.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 12:28:40 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 07 Nov 2016 17:28:40 +0000 Subject: [issue28623] Let `shlex.quote` accept a `PathLike` object In-Reply-To: <1478425476.42.0.524210940005.issue28623@psf.upfronthosting.co.za> Message-ID: <1478539720.32.0.991012858246.issue28623@psf.upfronthosting.co.za> Berker Peksag added the comment: Agreed with David. Closing this as 'rejected'. Thanks for the report. ---------- nosy: +berker.peksag resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 12:29:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Nov 2016 17:29:17 +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: <1478539757.42.0.570624434031.issue28564@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch implements shutil.rmtree using os.scandir. Needed file descriptors support in os.scandir (issue25996). I did not test how this affects the performance of shutil.rmtree. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file45382/shutil-rmtree-scandir.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 12:35:06 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 07 Nov 2016 17:35:06 +0000 Subject: [issue28630] setup.py bdist_egg --without-source-files does not allow console_script to run as expected In-Reply-To: <1478506883.78.0.576279801129.issue28630@psf.upfronthosting.co.za> Message-ID: <1478540106.26.0.89706069066.issue28630@psf.upfronthosting.co.za> Berker Peksag added the comment: console_script is a feature of setuptools. I'd suggest reporting this to https://github.com/pypa/setuptools We can reopen this if the problem is really in distutils. Thanks! ---------- nosy: +berker.peksag resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 12:39:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Nov 2016 17:39:35 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1478540375.23.0.19010516861.issue25677@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch fixes one bug, and I'm going to push it. There is other bug here. If add "1;" before the original example (so the line becomes "1;1 + 1 = 2"), the caret will be under ";". In some SyntaxErrors the caret points one position left before the start of incorrect expression. But this bug deserves separate issue. The fact that in "1 + 1 = 2" the caret points to the first "1" instead of "=" can be considered as yet one different bug (but this is questionable). ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 12:42:29 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Nov 2016 17:42:29 +0000 Subject: [issue28585] Restore docstring of os._isdir In-Reply-To: <1478075476.63.0.19722756431.issue28585@psf.upfronthosting.co.za> Message-ID: <1478540549.22.0.603369293583.issue28585@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is Windows specific issue. I'm unable to test the patch myself. Could anybody with access to Windows computer please test it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 12:43:14 2016 From: report at bugs.python.org (Eryk Sun) Date: Mon, 07 Nov 2016 17:43:14 +0000 Subject: [issue28631] [2.7/3.5/3.6 Regression] crash using ctypes In-Reply-To: <1478531194.3.0.136911442919.issue28631@psf.upfronthosting.co.za> Message-ID: <1478540594.27.0.291428991779.issue28631@psf.upfronthosting.co.za> Eryk Sun added the comment: po_message_create() returns a po_message_t pointer: /* A po_message_t represents a message in a PO file. */ typedef struct po_message *po_message_t; /* Return a freshly constructed message. To finish initializing the message, you must set the msgid and msgstr. */ extern po_message_t po_message_create (void); You're casting a pointer as a 32-bit C int, which isn't reliable in 64-bit Python. The value 0x55c7cf00 (1439158016) may be truncated. Try it using a po_message_t pointer type. For example: gpo = ctypes.CDLL(lib_location) class po_message_t(ctypes._Pointer): """A po_message_t represents a message in a PO file.""" class po_message(ctypes.Structure): pass _type_ = po_message gpo.po_message_create.restype = po_message_t ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 12:43:40 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Nov 2016 17:43:40 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1478540620.85.0.907697191124.issue25677@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: -haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 12:46:08 2016 From: report at bugs.python.org (Honor) Date: Mon, 07 Nov 2016 17:46:08 +0000 Subject: [issue28633] eval() Function - Segmentation Fault Message-ID: New submission from Honor: Hello, Python version : 3.7.0a0 OS : Ubunt - Linux x 3.13.0-24-generic Test Script: >>> a="B\'\'F\'\'" >>> eval(a) Program received signal SIGSEGV, Segmentation fault. 0x0000000000531c5a in parsestrplus (n=0x7ffff7ee0b20, c=0x7fffffffd730) at Python/ast.c:5150 5150 Py_DECREF(s); (gdb) info reg rax 0x0 0 rbx 0x0 0 rcx 0x7ffff7e9bab0 140737352678064 rdx 0x0 0 rsi 0x7ffff7e9ba88 140737352678024 rdi 0x7ffff7f74670 140737353565808 rbp 0x1 0x1 rsp 0x7fffffffd350 0x7fffffffd350 r8 0x0 0 r9 0x7fffffffd328 140737488343848 r10 0x7ffff7e9bab0 140737352678064 r11 0x7fffffffd2e0 140737488343776 r12 0x7ffff7ee0b20 140737352960800 r13 0x7fffffffd730 140737488344880 r14 0x0 0 r15 0x7ffff7f8557a 140737353635194 rip 0x531c5a 0x531c5a eflags 0x10246 [ PF ZF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) bt #0 0x0000000000531c5a in parsestrplus (n=0x7ffff7ee0b20, c=0x7fffffffd730) at Python/ast.c:5150 #1 ast_for_atom (c=c at entry=0x7fffffffd730, n=0x7ffff7ee0b20) at Python/ast.c:2110 #2 0x000000000053221a in ast_for_atom_expr (n=0x7ffff7ee0d78, c=0x7fffffffd730) at Python/ast.c:2465 #3 ast_for_power (n=0x7ffff7ee0d50, c=0x7fffffffd730) at Python/ast.c:2502 #4 ast_for_expr (c=c at entry=0x7fffffffd730, n=0x7ffff7ee0d50) at Python/ast.c:2690 #5 0x0000000000537446 in ast_for_testlist (n=0x7ffff7e8f0d0, c=0x7fffffffd730) at Python/ast.c:2881 #6 PyAST_FromNodeObject (n=0x7ffff7ee0ad0, n at entry=0x7ffff7ee0af8, flags=, filename=filename at entry=0x7ffff7e9be30, arena=arena at entry=0x7ffff7f751e0) at Python/ast.c:815 #7 0x000000000042649f in PyParser_ASTFromStringObject (arena=0x7ffff7f751e0, flags=, start=258, filename=0x7ffff7e9be30, s=0x7ffff7e9be30 "\003") at Python/pythonrun.c:1124 #8 PyRun_StringFlags (str=str at entry=0x7ffff7e9bae0 "B''F''", start=start at entry=258, globals=globals at entry=0x7ffff7f5d168, locals=locals at entry=0x7ffff7f5d168, flags=flags at entry=0x7fffffffd840) at Python/pythonrun.c:902 #9 0x000000000053a9fe in builtin_eval_impl (module=, locals=0x7ffff7f5d168, globals=0x7ffff7f5d168, source=0x7ffff7e9bab0) at Python/bltinmodule.c:875 #10 builtin_eval (module=, args=) at Python/clinic/bltinmodule.c.h:243 #11 0x00000000004a7869 in _PyCFunction_FastCallDict (kwargs=0x0, nargs=1, args=0x53a8b0 , func_obj=0x7ffff7fda990) at Objects/methodobject.c:234 #12 _PyCFunction_FastCallKeywords (func=func at entry=0x7ffff7fda990, stack=stack at entry=0x7ffff7fa2ca8, nargs=1, kwnames=kwnames at entry=0x0) at Objects/methodobject.c:295 #13 0x000000000053c954 in call_function (pp_stack=pp_stack at entry=0x7fffffffda50, oparg=oparg at entry=1, kwnames=kwnames at entry=0x0) at Python/ceval.c:4793 #14 0x000000000054032c in _PyEval_EvalFrameDefault (f=, throwflag=) at Python/ceval.c:3277 #15 0x000000000053c571 in PyEval_EvalFrameEx (throwflag=0, f=0x7ffff7fa2b28) at Python/ceval.c:718 #16 _PyEval_EvalCodeWithName (_co=_co at entry=0x7ffff7ed7270, globals=globals at entry=0x7ffff7f5d168, locals=locals at entry=0x7ffff7f5d168, args=args at entry=0x0, argcount=argcount at entry=0, kwnames=kwnames at entry=0x0, kwargs=kwargs at entry=0x8, kwcount=kwcount at entry=0, kwstep=kwstep at entry=2, defs=defs at entry=0x0, defcount=defcount at entry=0, kwdefs=kwdefs at entry=0x0, closure=closure at entry=0x0, name=name at entry=0x0, qualname=qualname at entry=0x0) at Python/ceval.c:4121 #17 0x000000000053d380 in PyEval_EvalCodeEx (closure=0x0, kwdefs=0x0, defcount=0, defs=0x0, kwcount=0, kws=0x0, argcount=0, args=0x0, locals=locals at entry=0x7ffff7f5d168, globals=globals at entry=0x7ffff7f5d168, _co=_co at entry=0x7ffff7ed7270) at Python/ceval.c:4142 #18 PyEval_EvalCode (co=co at entry=0x7ffff7ed7270, globals=globals at entry =0x7ffff7f5d168, locals=locals at entry=0x7ffff7f5d168) at Python/ceval.c:695 #19 0x0000000000427bc4 in run_mod (arena=0x7ffff7f75180, flags=0x7fffffffdd40, locals=0x7ffff7f5d168, globals=0x7ffff7f5d168, filename=0x7ffff7f14ae8, mod=0x936ab0) at Python/pythonrun.c:980 #20 PyRun_InteractiveOneObject (fp=fp at entry=0x7ffff74a9640 <_IO_2_1_stdin_>, filename=filename at entry=0x7ffff7f14ae8, flags=flags at entry=0x7fffffffdd40) at Python/pythonrun.c:233 #21 0x0000000000427e8e in PyRun_InteractiveLoopFlags (fp=fp at entry=0x7ffff74a9640 <_IO_2_1_stdin_>, filename_str=filename_str at entry=0x5d0f05 "", flags=flags at entry=0x7fffffffdd40) at Python/pythonrun.c:112 #22 0x0000000000427f9c in PyRun_AnyFileExFlags (fp=0x7ffff74a9640 <_IO_2_1_stdin_>, filename=0x5d0f05 "", closeit=0, flags=0x7fffffffdd40) at Python/pythonrun.c:74 #23 0x0000000000439b31 in run_file (p_cf=0x7fffffffdd40, filename=0x0, fp=0x7ffff74a9640 <_IO_2_1_stdin_>) at Modules/main.c:319 #24 Py_Main (argc=argc at entry=1, argv=argv at entry=0x8fe010) at Modules/main.c:779 #25 0x000000000041d964 in main (argc=1, argv=) at ./Programs/python.c:69 ---------- messages: 280218 nosy: Stone priority: normal severity: normal status: open title: eval() Function - Segmentation Fault _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 12:49:17 2016 From: report at bugs.python.org (Zachary Ware) Date: Mon, 07 Nov 2016 17:49:17 +0000 Subject: [issue28585] Restore docstring of os._isdir In-Reply-To: <1478075476.63.0.19722756431.issue28585@psf.upfronthosting.co.za> Message-ID: <1478540957.47.0.362232512406.issue28585@psf.upfronthosting.co.za> Zachary Ware added the comment: LGTM. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 12:52:51 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 07 Nov 2016 17:52:51 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1478541171.47.0.228607433283.issue25677@psf.upfronthosting.co.za> Berker Peksag added the comment: With patch applied: File "x.py", line 2 1 + 1 = 2 ^ SyntaxError: can't assign to operator Without patch: File "x.py", line 2 1 + 1 = 2 ^ SyntaxError: can't assign to operator The caret is located at the wrong place in both examples (which is the actual bug that needs to be fixed here.) This isn't a high priority bug and I think people can live with the current behavior until this is properly fixed. Pushing a premature patch will only introduce more code churn. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 13:02:47 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Nov 2016 18:02:47 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za> Message-ID: <1478541767.36.0.299191677187.issue19569@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Or, is this a "statement of direction" that only GCC (syntax) compilers are (going to be) supported? This is only the first step. Since this feature is compiler specific, we should add the support for every compiler separately. Arfrever suggested the syntax for supporting this on Microsoft compiler. But I don't know how to silence warnings on this compiler. Other compilers can support GCC syntax. We should check and switch on this. > Which functions are bridges? All deprecated Py_UNICODE related functions use Py_UNICODE. Most of them are bridges to new APIs. Py_UNICODE also is used in implementation of format codes 'u' and 'Z' of PyArg_Parse*. It also is used in many functions that are bridges to Windows API. > "Py_UCS4 _PyUnicode_ToLowercase(Py_UCS4 ch)" doesn't use Py_UNICODE, what is the issue? The problem with this function is not related to Py_UNICODE, but that correct Unicode mapping can return multiple characters. > Do you want to deprecate functions like Py_UNICODE_ISDECIMAL(ch)? No. It works correctly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 13:05:19 2016 From: report at bugs.python.org (Zachary Ware) Date: Mon, 07 Nov 2016 18:05:19 +0000 Subject: [issue28633] eval() Function - Segmentation Fault In-Reply-To: Message-ID: <1478541919.49.0.723257642494.issue28633@psf.upfronthosting.co.za> Zachary Ware added the comment: Reproduced on macOS: $ ./python.exe Python 3.6.0b4+ (3.6:b26c8104e54f, Nov 7 2016, 12:01:37) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin Type help, copyright, credits or license for more information. >>> B''F'' Segmentation fault: 11 Looks like `f''b''` is handled correctly, but `b''f''` is not. ---------- components: +Interpreter Core nosy: +eric.smith, ned.deily, zach.ware priority: normal -> release blocker stage: -> needs patch type: -> crash versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 13:13:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Nov 2016 18:13:07 +0000 Subject: [issue25677] Syntax error caret confused by indentation In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za> Message-ID: <1478542387.35.0.248811757288.issue25677@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This may be just bad example that it looks contradictorily to you. Is the example "None = 0" looks good to you? Without patch the caret is located at the middle of None (depending on the size of the indentation of this line). With patch applied it is located at the start of None independently of the indentation. The original bug is that the location of the caret depends on the indentation. The patch fixes this bug (and only this bug). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 13:14:47 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Nov 2016 18:14:47 +0000 Subject: [issue28633] eval() Function - Segmentation Fault In-Reply-To: Message-ID: <1478542487.75.0.75433966939.issue28633@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 13:15:37 2016 From: report at bugs.python.org (Honor) Date: Mon, 07 Nov 2016 18:15:37 +0000 Subject: [issue28633] eval() Function - Segmentation Fault In-Reply-To: <1478542487.77.0.326946684921.issue28633@psf.upfronthosting.co.za> Message-ID: Honor added the comment: Why not? I have tested it. Different payload : '%%-'%B'4--'F'' Again crashed. Can you try? On Mon, Nov 7, 2016 at 9:14 PM, Serhiy Storchaka wrote: > > Changes by Serhiy Storchaka : > > > ---------- > nosy: +serhiy.storchaka > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 13:21:56 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Nov 2016 18:21:56 +0000 Subject: [issue28633] Concatenating bytes literal and f-string causes segmentation fault In-Reply-To: Message-ID: <1478542916.89.0.571511475034.issue28633@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- title: eval() Function - Segmentation Fault -> Concatenating bytes literal and f-string causes segmentation fault _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 13:42:59 2016 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 07 Nov 2016 18:42:59 +0000 Subject: [issue28633] Concatenating bytes literal and f-string causes segmentation fault In-Reply-To: Message-ID: <1478544179.82.0.80529514027.issue28633@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- assignee: -> eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 14:08:17 2016 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 07 Nov 2016 19:08:17 +0000 Subject: [issue28633] Concatenating bytes literal and f-string causes segmentation fault In-Reply-To: Message-ID: <1478545697.37.0.207457401429.issue28633@psf.upfronthosting.co.za> Eric V. Smith added the comment: Works: >>> f'' b'' File "", line 1 SyntaxError: cannot mix bytes and nonbytes literals Fails: >>> b'' f'' Segmentation fault $ Regular strings work: >>> '' b'' File "", line 1 SyntaxError: cannot mix bytes and nonbytes literals >>> b'' '' File "", line 1 SyntaxError: cannot mix bytes and nonbytes literals >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 14:21:40 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 07 Nov 2016 19:21:40 +0000 Subject: [issue27854] Installed 2.7: IDLE Help disabled because help.html is missing In-Reply-To: <1472078066.3.0.116550230826.issue27854@psf.upfronthosting.co.za> Message-ID: <1478546500.3.0.100055662686.issue27854@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Irv, could you check on any 2.7.11/12 installations you have access to? ---------- nosy: +IrvKalb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 14:33:39 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 07 Nov 2016 19:33:39 +0000 Subject: [issue23218] Modernize the IDLE Find/Replace/Find in Files dialogs In-Reply-To: <1420884051.8.0.416866319984.issue23218@psf.upfronthosting.co.za> Message-ID: <1478547219.17.0.579201867946.issue23218@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Al, thanks for the honest comparison. For 3.6, we can just import and use ttk with no fuss. When I get to this, I will review tests and responses to and (see #27621). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 14:45:28 2016 From: report at bugs.python.org (Honor) Date: Mon, 07 Nov 2016 19:45:28 +0000 Subject: [issue28633] Concatenating bytes literal and f-string causes segmentation fault In-Reply-To: <1478545697.37.0.207457401429.issue28633@psf.upfronthosting.co.za> Message-ID: Honor added the comment: Another: >>> 9,'''??%''(r'''%b''''"r''''' File "", line 1 SyntaxError: cannot mix bytes and nonbytes literals >>> 9,'B''??%''(r'''%b''''"r''' Traceback (most recent call last): File "", line 1, in ValueError: incomplete format key >>> 9,'B''??%''(r'''%b''''"r'''F File "", line 1 9,'B''??%''(r'''%b''''"r'''F ^ SyntaxError: invalid syntax >>> 9,'B''??%''(r'''%b''''"r'''F' File "", line 1 9,'B''??%''(r'''%b''''"r'''F' ^ SyntaxError: EOL while scanning string literal >>> On Mon, Nov 7, 2016 at 10:08 PM, Eric V. Smith wrote: > > Eric V. Smith added the comment: > > Works: > > >>> f'' b'' > File "", line 1 > SyntaxError: cannot mix bytes and nonbytes literals > > Fails: > > >>> b'' f'' > Segmentation fault > $ > > Regular strings work: > >>> '' b'' > File "", line 1 > SyntaxError: cannot mix bytes and nonbytes literals > >>> b'' '' > File "", line 1 > SyntaxError: cannot mix bytes and nonbytes literals > >>> > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 14:52:09 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 07 Nov 2016 19:52:09 +0000 Subject: [issue28632] configparser does not close files in read In-Reply-To: <1478537342.33.0.595722710962.issue28632@psf.upfronthosting.co.za> Message-ID: <1478548329.31.0.413118804009.issue28632@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 14:55:40 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 07 Nov 2016 19:55:40 +0000 Subject: [issue28628] Failure to add signal handlers for any signal but SIGINT In-Reply-To: <1478482999.04.0.832898524101.issue28628@psf.upfronthosting.co.za> Message-ID: <1478548540.06.0.591059169352.issue28628@psf.upfronthosting.co.za> Yury Selivanov added the comment: I think I have a patch for this here: https://github.com/python/asyncio/pull/456 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 14:59:42 2016 From: report at bugs.python.org (Reuben Thomas) Date: Mon, 07 Nov 2016 19:59:42 +0000 Subject: [issue28609] argparse claims '*' positional argument is required in error output In-Reply-To: <1478272763.12.0.609109547521.issue28609@psf.upfronthosting.co.za> Message-ID: <1478548782.88.0.196836722895.issue28609@psf.upfronthosting.co.za> Reuben Thomas added the comment: Thanks, that's a simple, robust workaround. I'll duck out now and leave the Python experts to sort out the underlying problem, if they can; I think it's still well worth sorting out, though documenting the problem and workaround would be much better than nothing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 15:21:42 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Nov 2016 20:21:42 +0000 Subject: [issue28088] Document Transport.set_protocol and get_protocol In-Reply-To: <1475369173.63.0.247466795846.issue28088@psf.upfronthosting.co.za> Message-ID: <20161107202139.22336.68539.3364CB6D@psf.io> Roundup Robot added the comment: New changeset f4e86b1b051e by Berker Peksag in branch '3.5': Issue #28088: Don't include self in method signature https://hg.python.org/cpython/rev/f4e86b1b051e New changeset f2858945c058 by Berker Peksag in branch '3.6': Issue #28088: Merge from 3.5 https://hg.python.org/cpython/rev/f2858945c058 New changeset 62b7614970bd by Berker Peksag in branch 'default': Issue #28088: Merge from 3.6 https://hg.python.org/cpython/rev/62b7614970bd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 15:25:21 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 07 Nov 2016 20:25:21 +0000 Subject: [issue28088] Document Transport.set_protocol and get_protocol In-Reply-To: <1475369173.63.0.247466795846.issue28088@psf.upfronthosting.co.za> Message-ID: <1478550321.24.0.73009494674.issue28088@psf.upfronthosting.co.za> Berker Peksag added the comment: I just removed self from method signatures (we don't usually include it) and updated the versionadded directives to 3.5.3 since it was also backported to 3.5 in f12a59311885. Please let me know if got the 3.5 version wrong, thanks! ---------- nosy: +berker.peksag, larry versions: +Python 3.5, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 15:25:49 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 07 Nov 2016 20:25:49 +0000 Subject: [issue28088] Document Transport.set_protocol and get_protocol In-Reply-To: <1475369173.63.0.247466795846.issue28088@psf.upfronthosting.co.za> Message-ID: <1478550349.09.0.865857238808.issue28088@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: -larry priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 15:31:27 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 07 Nov 2016 20:31:27 +0000 Subject: [issue28603] traceback module can't format/print unhashable exceptions In-Reply-To: <1478208134.4.0.220857012408.issue28603@psf.upfronthosting.co.za> Message-ID: <1478550687.36.0.0602205312378.issue28603@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch. Out of curiosity, how did you get an unhashable exception? Is there a way to reproduce this without creating a custom exception and set __hash__ to None? In other words, what's your use case? ---------- nosy: +berker.peksag stage: -> patch review type: -> behavior versions: +Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 15:32:09 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Nov 2016 20:32:09 +0000 Subject: [issue28632] configparser does not close files in read In-Reply-To: <1478537342.33.0.595722710962.issue28632@psf.upfronthosting.co.za> Message-ID: <1478550729.22.0.998564690988.issue28632@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I can't reproduce the issue. Looking at the code it seems to me that the file is always closed. Could you please provide more information Petr? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 15:34:23 2016 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 07 Nov 2016 20:34:23 +0000 Subject: [issue28633] Concatenating bytes literal and f-string causes segmentation fault In-Reply-To: Message-ID: <1478550863.05.0.295008997884.issue28633@psf.upfronthosting.co.za> Eric V. Smith added the comment: The ones in msg280228 give correct error messages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 15:36:12 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Nov 2016 20:36:12 +0000 Subject: [issue27392] Add a server_side keyword parameter to create_connection In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: <20161107203608.30992.29125.66A1B775@psf.io> Roundup Robot added the comment: New changeset 3e6570231c80 by Yury Selivanov in branch '3.5': Issue #27392: Document loop.connect_accepted_socket() https://hg.python.org/cpython/rev/3e6570231c80 New changeset 6811df9e9797 by Yury Selivanov in branch '3.6': Merge 3.5 (issue #27392) https://hg.python.org/cpython/rev/6811df9e9797 New changeset 573bc1f9900e by Yury Selivanov in branch 'default': Merge 3.6 (issue #27392) https://hg.python.org/cpython/rev/573bc1f9900e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 15:36:55 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 07 Nov 2016 20:36:55 +0000 Subject: [issue27392] Add loop.connect_accepted_socket In-Reply-To: <1466957117.0.0.423625085233.issue27392@psf.upfronthosting.co.za> Message-ID: <1478551015.28.0.508868640952.issue27392@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- title: Add a server_side keyword parameter to create_connection -> Add loop.connect_accepted_socket _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 15:40:32 2016 From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=) Date: Mon, 07 Nov 2016 20:40:32 +0000 Subject: [issue28603] traceback module can't format/print unhashable exceptions In-Reply-To: <1478208134.4.0.220857012408.issue28603@psf.upfronthosting.co.za> Message-ID: <1478551232.91.0.352408405284.issue28603@psf.upfronthosting.co.za> Andreas St?hrk added the comment: It was reported as bug to a project that uses the traceback module (https://github.com/bpython/bpython/issues/651). Parsley (https://pypi.python.org/pypi/Parsley) is at least one library that uses unhashable exceptions, although I guess it's by accident: it defines __eq__, but not __hash__ and that makes the exception unhashable under Python 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 15:49:36 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 07 Nov 2016 20:49:36 +0000 Subject: [issue28559] Unclear error message when raising wrong type of exceptions In-Reply-To: <1477764991.61.0.67228056749.issue28559@psf.upfronthosting.co.za> Message-ID: <1478551776.07.0.306260095829.issue28559@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, but I find your proposed message less clearer (including NoneType adds unnecessary confusion and people may ask "where did NoneType come from?") Python 2 is different because of historical reasons (pre-BaseException era) so I don't think we should look at it in this case. If other core developers give their +1s, the patch needs to be updated to add a test case (it can be added to Lib/test/test_exceptions.py) and use the Py_TYPE() macro instead of accessing exc->ob_type directly. ---------- nosy: +berker.peksag stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 15:53:34 2016 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 07 Nov 2016 20:53:34 +0000 Subject: [issue28633] Concatenating bytes literal and f-string causes segmentation fault In-Reply-To: Message-ID: <1478552014.78.0.848876969571.issue28633@psf.upfronthosting.co.za> Eric V. Smith added the comment: It's a decref of a NULL pointer. Patch with test is attached. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file45383/28633-0.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 15:58:51 2016 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 Nov 2016 20:58:51 +0000 Subject: [issue28621] Refactor duplicate code calculating digit's bit length In-Reply-To: <1478374648.81.0.502575461924.issue28621@psf.upfronthosting.co.za> Message-ID: <1478552331.55.0.0230758943476.issue28621@psf.upfronthosting.co.za> Mark Dickinson added the comment: LGTM, too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 16:00:19 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 07 Nov 2016 21:00:19 +0000 Subject: [issue28634] asyncio.isfuture() should support Mocks Message-ID: <1478552419.52.0.976301550008.issue28634@psf.upfronthosting.co.za> New submission from Yury Selivanov: In short: isfuture(unittest.mock.Mock()) should be False isfuture(unittest.mock.Mock(Future)) should be True This issue is a proxy for https://github.com/python/asyncio/pull/455 ---------- assignee: yselivanov components: asyncio messages: 280241 nosy: gvanrossum, yselivanov priority: normal severity: normal stage: resolved status: open title: asyncio.isfuture() should support Mocks type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 16:00:31 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 07 Nov 2016 21:00:31 +0000 Subject: [issue28634] asyncio.isfuture() should support Mocks In-Reply-To: <1478552419.52.0.976301550008.issue28634@psf.upfronthosting.co.za> Message-ID: <1478552431.71.0.994868071787.issue28634@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 16:08:05 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Nov 2016 21:08:05 +0000 Subject: [issue28634] asyncio.isfuture() should support Mocks In-Reply-To: <1478552419.52.0.976301550008.issue28634@psf.upfronthosting.co.za> Message-ID: <20161107210802.38935.61887.CDA9E1F0@psf.io> Roundup Robot added the comment: New changeset 0669dcf1eb36 by Yury Selivanov in branch '3.5': Issue #28634: Fix asyncio.isfuture() to support mocks https://hg.python.org/cpython/rev/0669dcf1eb36 New changeset a02915e4c165 by Yury Selivanov in branch '3.6': Merge 3.5 (issue #28634) https://hg.python.org/cpython/rev/a02915e4c165 New changeset 44c1ec7689e5 by Yury Selivanov in branch 'default': Merge 3.6 (issue #28634) https://hg.python.org/cpython/rev/44c1ec7689e5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 16:10:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Nov 2016 21:10:32 +0000 Subject: [issue28633] Concatenating bytes literal and f-string causes segmentation fault In-Reply-To: Message-ID: <1478553032.86.0.59320913509.issue28633@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. I added comments about other asserts. Not related, but would be nice to fix them too while we are here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 16:12:37 2016 From: report at bugs.python.org (Elvis Pranskevichus) Date: Mon, 07 Nov 2016 21:12:37 +0000 Subject: [issue28635] Update What's New for 3.6 Message-ID: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> New submission from Elvis Pranskevichus: Issue to track edits to "What's New in Python 3.6" ---------- assignee: docs at python components: Documentation files: 0001-Inital-pass-on-What-s-New-in-Python-3.6.patch keywords: patch messages: 280244 nosy: Elvis.Pranskevichus, docs at python, yselivanov priority: normal severity: normal status: open title: Update What's New for 3.6 type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file45384/0001-Inital-pass-on-What-s-New-in-Python-3.6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 16:15:34 2016 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 07 Nov 2016 21:15:34 +0000 Subject: [issue28633] Concatenating bytes literal and f-string causes segmentation fault In-Reply-To: Message-ID: <1478553334.6.0.546279834709.issue28633@psf.upfronthosting.co.za> Eric V. Smith added the comment: Thanks, Serhiy. I updated the patch. ---------- Added file: http://bugs.python.org/file45385/28633-1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 16:16:57 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 07 Nov 2016 21:16:57 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1478553417.44.0.218888857729.issue28635@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- assignee: docs at python -> yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 16:22:10 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Nov 2016 21:22:10 +0000 Subject: [issue28088] Document Transport.set_protocol and get_protocol In-Reply-To: <1475369173.63.0.247466795846.issue28088@psf.upfronthosting.co.za> Message-ID: <1478553730.84.0.57485527834.issue28088@psf.upfronthosting.co.za> Guido van Rossum added the comment: Good point. Thanks Berker! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 16:25:52 2016 From: report at bugs.python.org (Big Stone) Date: Mon, 07 Nov 2016 21:25:52 +0000 Subject: [issue28636] strange issue with Pandas-0.19.1 on Python-3.6.0b3 Message-ID: <1478553952.22.0.478578005761.issue28636@psf.upfronthosting.co.za> New submission from Big Stone: hi, we detect a strange issue on Pandas-0.19.1/Python-3.6.0b3/Windows that may or may not be a Python-3.6 bug. As it was for the glory of Python-3.6.0b3 testing, we signal the incident here. https://github.com/pandas-dev/pandas/issues/14561 ---------- messages: 280247 nosy: Big Stone priority: normal severity: normal status: open title: strange issue with Pandas-0.19.1 on Python-3.6.0b3 versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 16:34:52 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Nov 2016 21:34:52 +0000 Subject: [issue28636] strange issue with Pandas-0.19.1 on Python-3.6.0b3 In-Reply-To: <1478553952.22.0.478578005761.issue28636@psf.upfronthosting.co.za> Message-ID: <1478554492.58.0.407984589645.issue28636@psf.upfronthosting.co.za> STINNER Victor added the comment: Extract of the bug report: > ... > pandas/tslib.pyx in pandas.tslib.convert_str_to_tsobject (pandas/tslib.c:26851)() > pandas/src/datetime.pxd in datetime._string_to_dts (pandas/tslib.c:87106)() > SystemError: returned a result with an error set It looks like a bug in a C extension, I mean in the third party code. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 16:44:34 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Nov 2016 21:44:34 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <20161107214431.22961.93015.643CBE2C@psf.io> Roundup Robot added the comment: New changeset 38c806f0943b by Yury Selivanov in branch 'default': Merge 3.6 (issue #28635) https://hg.python.org/cpython/rev/38c806f0943b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 16:44:53 2016 From: report at bugs.python.org (Big Stone) Date: Mon, 07 Nov 2016 21:44:53 +0000 Subject: [issue28636] strange issue with Pandas-0.19.1 on Python-3.6.0b3 In-Reply-To: <1478553952.22.0.478578005761.issue28636@psf.upfronthosting.co.za> Message-ID: <1478555093.18.0.280983619023.issue28636@psf.upfronthosting.co.za> Big Stone added the comment: the curiosity is the error message, different (and uncaught) under Python 3.6 "SystemError", while with python < 3.6, you get a "ValueError" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 17:15:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Nov 2016 22:15:33 +0000 Subject: [issue28572] IDLE: add tests for config dialog. In-Reply-To: <1477948919.57.0.703261528011.issue28572@psf.upfronthosting.co.za> Message-ID: <20161107221530.30750.52546.36CDD0DF@psf.io> Roundup Robot added the comment: New changeset d6440718eb30 by Terry Jan Reedy in branch '3.6': Issue #28572: Add 10% to coverage of IDLE's test_configdialog. https://hg.python.org/cpython/rev/d6440718eb30 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 17:24:20 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Nov 2016 22:24:20 +0000 Subject: [issue28636] strange issue with Pandas-0.19.1 on Python-3.6.0b3 In-Reply-To: <1478555093.18.0.280983619023.issue28636@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > while with python < 3.6, you get a "ValueError" It's because Python 3.6 is more strict. Python 3.5 doesn't catch the bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 17:28:37 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 07 Nov 2016 22:28:37 +0000 Subject: [issue28632] configparser does not close files in read In-Reply-To: <1478537342.33.0.595722710962.issue28632@psf.upfronthosting.co.za> Message-ID: <1478557717.02.0.768558869295.issue28632@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Cannot repro: ``` $ python3 Python 3.5.2 (default, Jul 28 2016, 21:28:00) >>> with open('/tmp/someconfig.py', 'w') as w: ... w.write("""[section] ... option=value ... """) ... 23 >>> import configparser >>> cp = configparser.ConfigParser() >>> cp.read('/tmp/someconfig.py') ['/tmp/someconfig.py'] >>> [CTRL+D] $ ``` If I leave a file unclosed, I get warning: ``` $ python3 Python 3.5.2 (default, Jul 28 2016, 21:28:00) >>> open('/tmp/someconfig.py') <_io.TextIOWrapper name='/tmp/someconfig.py' mode='r' encoding='UTF-8'> >>> [CTRL+D] sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/someconfig.py' mode='r' encoding='UTF-8'> $ ``` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 17:33:49 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 07 Nov 2016 22:33:49 +0000 Subject: [issue21590] Systemtap and DTrace support In-Reply-To: <1401195995.8.0.935339035852.issue21590@psf.upfronthosting.co.za> Message-ID: <1478558029.41.0.0867534721215.issue21590@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Yes, let's close this. @Charalampos, the error in your build comes from the /usr/bin/dtrace wrapper: Traceback (most recent call last): File "/usr/bin/dtrace", line 440, in sys.exit(main()) File "/usr/bin/dtrace", line 385, in main providers.probe_write(s_filename, filename + suffix) File "/usr/bin/dtrace", line 181, in probe_write hdr = open(header, mode='w') FileNotFoundError: [Errno 2] No such file or directory: 'Include/pydtrace_probes.h' For some reason the path Include/pydtrace_probes.h is not writable. Maybe this is RPM-specific? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 17:33:56 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 07 Nov 2016 22:33:56 +0000 Subject: [issue21590] Systemtap and DTrace support In-Reply-To: <1401195995.8.0.935339035852.issue21590@psf.upfronthosting.co.za> Message-ID: <1478558036.55.0.215995070344.issue21590@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 17:55:51 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 07 Nov 2016 22:55:51 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1478559351.16.0.250335683969.issue28635@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 17:58:11 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Nov 2016 22:58:11 +0000 Subject: [issue28633] Concatenating bytes literal and f-string causes segmentation fault In-Reply-To: Message-ID: <20161107225808.31120.53445.4F11E26A@psf.io> Roundup Robot added the comment: New changeset 31543f7cbdf4 by Eric V. Smith in branch '3.6': Fixed issue #28633: segfault when concatenating bytes literal and f-string. https://hg.python.org/cpython/rev/31543f7cbdf4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 18:00:30 2016 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 07 Nov 2016 23:00:30 +0000 Subject: [issue28633] Concatenating bytes literal and f-string causes segmentation fault In-Reply-To: Message-ID: <1478559630.04.0.770567410641.issue28633@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 18:08:21 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Nov 2016 23:08:21 +0000 Subject: [issue28637] Python startup performance regression Message-ID: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> New submission from STINNER Victor: The changeset 223731925d06 of the issue issue #28082 "use IntFlag for re constants" made Python startup 34% slower: - rev 5637c9b4dd4c: Median +- std dev: 19.5 ms +- 0.0 ms - rev 223731925d06: Median +- std dev: 26.2 ms +- 0.0 ms The change adds "import enum" in Lib/re.py, so the enum module is imported, whereas it wasn't before. It seems like importing enum takes 6.7 ms. I propose to revert the change 223731925d06 in Python 3.6 and reopen the issue #28082 to try to find another solution for the re module which doesn't impact Python startup performance. ---------- messages: 280256 nosy: ethan.furman, haypo priority: normal severity: normal status: open title: Python startup performance regression type: performance versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 18:08:51 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Nov 2016 23:08:51 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478560131.89.0.435990491521.issue28637@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +ned.deily priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 18:17:43 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Nov 2016 23:17:43 +0000 Subject: [issue28082] re: convert re flags to (much friendlier) IntFlag constants In-Reply-To: <1473625770.04.0.107359046953.issue28082@psf.upfronthosting.co.za> Message-ID: <1478560663.32.0.258191707053.issue28082@psf.upfronthosting.co.za> STINNER Victor added the comment: The changeset 223731925d06 caused a performance regression: see issue #28637. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 18:20:32 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Nov 2016 23:20:32 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478560832.01.0.395194963596.issue28637@psf.upfronthosting.co.za> Guido van Rossum added the comment: Reverting is reasonable, though it may break some code that started using this in 3.6b1. Such is the life of beta testers. The benefit of using Enum for re constants doesn't seem worth such a big increase in startup time. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 18:27:43 2016 From: report at bugs.python.org (Ethan Furman) Date: Mon, 07 Nov 2016 23:27:43 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478561263.23.0.545609206313.issue28637@psf.upfronthosting.co.za> Ethan Furman added the comment: Ouch, that's a lot slower! Victor, can you add the commands you are using for timing so I can work on making enum imports faster? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 18:31:02 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Nov 2016 23:31:02 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478561263.23.0.545609206313.issue28637@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Ethan Furman added the comment: > Victor, can you add the commands you are using for timing so I can work on making enum imports faster? Results of the python_startup benchmark: https://speed.python.org/timeline/#/?exe=4&ben=python_startup&env=1&revs=50&equid=off&quarts=on&extr=on This website uses the following benchmark suite: https://github.com/python/performance You can run the benchmark using: python3 -m performance run -b python_startup ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 18:38:35 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Nov 2016 23:38:35 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478561915.6.0.220678128256.issue28637@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I understood why I had issues to reproduce the startup performance slowdown. When Python is run from the source code using ./python, the re module is not imported. When Python is installed, the re is not imported by default neither: haypo at speed-python$ prefix/bin/python3 -c 'import sys; print("re" in sys.modules)' False BUT when Python is started from a virtual environment (created by the "venv" module), the re module is important by default. haypo at speed-python$ venv/bin/python3 -c 'import sys; print("re" in sys.modules)' True If the site module is not imported, the re module is not imported: haypo at speed-python$ venv/bin/python3 -S -c 'import sys; print("re" in sys.modules)' False The /home/haypo/benchmarks/prefix/lib/python3.6/site.py file is generated by the venv module and contains: def venv(...): ... if candidate_confs: import re config_line = re.compile(CONFIG_LINE) ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 18:46:30 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Nov 2016 23:46:30 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <20161107234627.29810.26552.0B4E4664@psf.io> Roundup Robot added the comment: New changeset d903a243c281 by Victor Stinner in branch '3.6': Issue #28637: Revert issue #28082, don't import enum in re https://hg.python.org/cpython/rev/d903a243c281 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 18:46:30 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Nov 2016 23:46:30 +0000 Subject: [issue28082] re: convert re flags to (much friendlier) IntFlag constants In-Reply-To: <1473625770.04.0.107359046953.issue28082@psf.upfronthosting.co.za> Message-ID: <20161107234627.29810.7535.B5A5916E@psf.io> Roundup Robot added the comment: New changeset d903a243c281 by Victor Stinner in branch '3.6': Issue #28637: Revert issue #28082, don't import enum in re https://hg.python.org/cpython/rev/d903a243c281 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 19:01:35 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Nov 2016 00:01:35 +0000 Subject: [issue28613] Make get_event_loop() return the current loop if called from coroutines In-Reply-To: <1478284080.22.0.444495685289.issue28613@psf.upfronthosting.co.za> Message-ID: <20161108000132.29810.27978.1A5DAC01@psf.io> Roundup Robot added the comment: New changeset abad0b9a35b3 by Yury Selivanov in branch '3.5': Issue #28613: Expose asyncio._get_running_loop() and _set_running_loop() https://hg.python.org/cpython/rev/abad0b9a35b3 New changeset 61a237f3bb07 by Yury Selivanov in branch '3.6': Merge 3.5 (issue #28613) https://hg.python.org/cpython/rev/61a237f3bb07 New changeset cf7711887b4a by Yury Selivanov in branch 'default': Merge 3.6 (issue #28613) https://hg.python.org/cpython/rev/cf7711887b4a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 19:09:21 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 08 Nov 2016 00:09:21 +0000 Subject: [issue28572] IDLE: add tests for config dialog. In-Reply-To: <1477948919.57.0.703261528011.issue28572@psf.upfronthosting.co.za> Message-ID: <1478563761.31.0.458124587638.issue28572@psf.upfronthosting.co.za> Ned Deily added the comment: test_idle now fails (macOS 10.12, Tcl/Tk 8.6): test test_idle failed -- Traceback (most recent call last): File "./lib/python3.7/idlelib/idle_test/test_configdialog.py", line 62, in test_font self.assertEqual(changes, expected) AssertionError: Lists differ: [('ma[70 chars]ont-size', '11'), ('main', 'EditorWindow', 'font-bold', False)] != [('ma[70 chars]ont-size', '10'), ('main', 'EditorWindow', 'font-bold', False)] First differing element 1: ('main', 'EditorWindow', 'font-size', '11') ('main', 'EditorWindow', 'font-size', '10') [('main', 'EditorWindow', 'font', 'Test Font'), - ('main', 'EditorWindow', 'font-size', '11'), ? ^ + ('main', 'EditorWindow', 'font-size', '10'), ? ^ ('main', 'EditorWindow', 'font-bold', False)] ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 19:35:17 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 08 Nov 2016 00:35:17 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478565317.87.0.715172567187.issue28637@psf.upfronthosting.co.za> Ned Deily added the comment: With being this close to release and with two weeks to go until the final beta, it seems a bit premature to immediately revert this without exploring all the alternatives especially since it seems the effects are limited to venvs. In any case, we do need to have a final answer well before the b4 cutoff (2016-11-21). Possible options: 1. leave the re contents reverted (current status) 2. find a way to mitigate the performance impact of importing re and enum (perhaps making them builtins in Setup.dist?) 3. avoid the use of re in site.py venv 4. others? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 19:49:15 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Nov 2016 00:49:15 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478566155.49.0.880085765461.issue28637@psf.upfronthosting.co.za> STINNER Victor added the comment: Possible options: > 3. avoid the use of re in site.py venv That would be a tiny but nice enhancement. re is a commonly used module. I would prefer to not make its import time slower. Python 3 startup is already something like 3x slower than Python 2. Please don't make it even slower :-( We worked on optimizing Python 3 startup time. > 2. find a way to mitigate the performance impact of importing re and enum (perhaps making them builtins in Setup.dist?) I reverted the change, because Guido and Ethan seem to be in favor of a revert, and I don't expect any simple solution for this issue. I'm quite sure that importing enum.py is slow. Optimizing enum.py import time is a large task. Another option to explore is to delay the creation/instanciation of the re flags, something like lazy module import... but at the module attribute level :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 19:49:34 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Nov 2016 00:49:34 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478566174.91.0.0136979334831.issue28637@psf.upfronthosting.co.za> STINNER Victor added the comment: I remove the release blocker flag since the change was reverted. ---------- priority: release blocker -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 20:01:53 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 08 Nov 2016 01:01:53 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478566913.46.0.109003575721.issue28637@psf.upfronthosting.co.za> Ned Deily added the comment: Please leave this as a "release blocker" until we have had a chance to explore all the options for 3.6.0b4. We may still very well decide that reverting is the least bad option but I don't want to rule out other options without some further investigation. We have time and the reverting could be a fairly significant change. ---------- priority: -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 20:04:15 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 08 Nov 2016 01:04:15 +0000 Subject: [issue26969] ascynio should provide a policy to address pass-loop-everywhere problem In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za> Message-ID: <1478567055.54.0.112894466007.issue26969@psf.upfronthosting.co.za> Yury Selivanov added the comment: See https://github.com/python/asyncio/pull/452. I believe that the issue is not resolved (almost). What's left is documenting how to use get_event_loop and when to use explicit/implicit loop passing. Closing this issue. Will open a new one for the documentation update. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 20:18:14 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Nov 2016 01:18:14 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478567894.55.0.739658487625.issue28637@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum strange, the changeset d903a243c281 (the revert) optimized regex_compile: 480 ms (rev 573bc1f9900e) => 403 ms (rev cf7711887b4a). But it didn't restore python_startup performance: 26.ms (rev 573bc1f9900e) => 24.6 ms (rev cf7711887b4a). Another change made re import slower: revision 88110cfbf4dc of issue #28193. If I also revert this change locally, python_startup performance is restored to 19.6 ms. By the way, regex_compile performance is the same with and without the revision 88110cfbf4dc, but the benchmark purges the re cache at each iteration of the benchmark. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 20:19:46 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Nov 2016 01:19:46 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478566913.46.0.109003575721.issue28637@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Agreed. --Guido (mobile) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 20:40:29 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Nov 2016 01:40:29 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: Message-ID: STINNER Victor added the comment: python_startup: * 2.7: 7.74 ms +- 0.28 ms * 3.4: 18.7 ms +- 0.4 ms * 3.5: 20.3 ms +- 0.7 ms * 3.6: 26.9 ms +- 0.6 ms (rev c4319c0d0131, before the revert) * 3.7: 26.6 ms +- 0.5 ms (rev 36af3566b67a, before the revert) * 3.7: 24.6 ms +- 0.0 ms (rev cf7711887b4a, after the revert) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 20:50:08 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Nov 2016 01:50:08 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: Message-ID: Guido van Rossum added the comment: So what does that benchmark measure? For me, python 3.6 startup is 44 ms and python 2.7 startup is 78 ms (real time; user time is proportionally less). On Mon, Nov 7, 2016 at 5:40 PM, STINNER Victor wrote: > > STINNER Victor added the comment: > > python_startup: > > * 2.7: 7.74 ms +- 0.28 ms > * 3.4: 18.7 ms +- 0.4 ms > * 3.5: 20.3 ms +- 0.7 ms > * 3.6: 26.9 ms +- 0.6 ms (rev c4319c0d0131, before the revert) > * 3.7: 26.6 ms +- 0.5 ms (rev 36af3566b67a, before the revert) > * 3.7: 24.6 ms +- 0.0 ms (rev cf7711887b4a, after the revert) > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 21:04:58 2016 From: report at bugs.python.org (Ilya Kulakov) Date: Tue, 08 Nov 2016 02:04:58 +0000 Subject: [issue26969] ascynio should provide a policy to address pass-loop-everywhere problem In-Reply-To: <1478567055.54.0.112894466007.issue26969@psf.upfronthosting.co.za> Message-ID: <5349C15A-1D7B-4F97-8F32-77CCDD0976C6@gmail.com> Ilya Kulakov added the comment: I'm very happy that the issue is finally resolved. But a bit offended that it took Andrew only 4 days to push it :) > On 07 Nov 2016, at 17:04, Yury Selivanov wrote: > > > Yury Selivanov added the comment: > > See https://github.com/python/asyncio/pull/452. I believe that the issue is not resolved (almost). > > What's left is documenting how to use get_event_loop and when to use explicit/implicit loop passing. > > Closing this issue. Will open a new one for the documentation update. > > ---------- > resolution: -> fixed > stage: -> resolved > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 22:06:10 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 08 Nov 2016 03:06:10 +0000 Subject: [issue28023] python-gdb.py must be updated for the new Python 3.6 compact dict In-Reply-To: <1473351940.28.0.277088210884.issue28023@psf.upfronthosting.co.za> Message-ID: <1478574370.61.0.90219314394.issue28023@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- nosy: +ned.deily priority: high -> release blocker stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 22:40:07 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 08 Nov 2016 03:40:07 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478576407.0.0.389553091969.issue28563@psf.upfronthosting.co.za> Xiang Zhang added the comment: > Sorry Xiang, but your patch looks overcomplicated to me. Too much methods, decorators, classes, too much strange names. It's fine. That's a Pratt parser. Yes, the names are strange. Your patch looks more simpler. I left several comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 23:07:24 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 08 Nov 2016 04:07:24 +0000 Subject: [issue28638] Creating namedtuple is too slow Message-ID: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> New submission from INADA Naoki: I surprised how functools make import time slower. And I find namedtuple makes it slower. When I replaced _CacheInfo = namedtuple("CacheInfo", ["hits", "misses", "maxsize", "currsize"]) this line with `_CachedInfo._source`: (before) $ ~/local/py37/bin/python3 -m perf timeit -s 'import importlib, functools' -- 'importlib.reload(functools)' ..................... Median +- std dev: 1.21 ms +- 0.01 ms (replaced) $ ~/local/py37/bin/python3 -m perf timeit -s 'import importlib, functools' -- 'importlib.reload(functools)' ..................... Median +- std dev: 615 us +- 12 us ---------- messages: 280277 nosy: inada.naoki priority: normal severity: normal status: open title: Creating namedtuple is too slow type: performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 23:08:39 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 08 Nov 2016 04:08:39 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1478578119.54.0.626572092759.issue28638@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- components: +Library (Lib) title: Creating namedtuple is too slow -> Creating namedtuple is too slow to be used in common stdlib (e.g. functools) versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 23:15:27 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Nov 2016 04:15:27 +0000 Subject: [issue28572] IDLE: add tests for config dialog. In-Reply-To: <1477948919.57.0.703261528011.issue28572@psf.upfronthosting.co.za> Message-ID: <20161108041524.111636.54218.90130ED6@psf.io> Roundup Robot added the comment: New changeset f604b6ebd802 by Terry Jan Reedy in branch '3.6': Issue #28572: Use system-specific values for configdialog font test https://hg.python.org/cpython/rev/f604b6ebd802 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 7 23:21:11 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 08 Nov 2016 04:21:11 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1478578871.54.0.723721046761.issue28638@psf.upfronthosting.co.za> INADA Naoki added the comment: I feel this patch is safe enough to be landed in 3.6. ---------- keywords: +patch Added file: http://bugs.python.org/file45386/28638-functools-no-namedtuple.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 00:20:16 2016 From: report at bugs.python.org (Justin Mayfield) Date: Tue, 08 Nov 2016 05:20:16 +0000 Subject: [issue28639] inspect.isawaitable(native_coro) returns int Message-ID: <1478582416.14.0.848083143848.issue28639@psf.upfronthosting.co.za> New submission from Justin Mayfield: Patch available on my github fork.. https://github.com/mayfield/cpython/commit/8d50cc61f42fa280d380e9c10c420c949a619bef ---------- components: asyncio messages: 280280 nosy: Justin Mayfield, gvanrossum, yselivanov priority: normal severity: normal status: open title: inspect.isawaitable(native_coro) returns int type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 00:22:20 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 08 Nov 2016 05:22:20 +0000 Subject: [issue28639] inspect.isawaitable(native_coro) returns int In-Reply-To: <1478582416.14.0.848083143848.issue28639@psf.upfronthosting.co.za> Message-ID: <1478582540.26.0.554251498961.issue28639@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thank you! Will merge it tomorrow. ---------- assignee: -> yselivanov components: +Library (Lib) -asyncio nosy: -gvanrossum versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 00:45:07 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 08 Nov 2016 05:45:07 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1478583907.48.0.713537222803.issue28638@psf.upfronthosting.co.za> Xiang Zhang added the comment: I doubt this deserves a change. The slow import is the case only the first time functools is imported. Later imports will just use the cache (sys.modules). And if this is gonna change, maybe we don't have to copy the entire namedtuple structure? ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 00:45:50 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 08 Nov 2016 05:45:50 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1478583950.41.0.460301698204.issue28638@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +ncoghlan, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 01:09:16 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 08 Nov 2016 06:09:16 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1478585356.61.0.00899987235569.issue28638@psf.upfronthosting.co.za> INADA Naoki added the comment: > The slow import is the case only the first time functools is imported. Later imports will just use the cache (sys.modules). Yes. But first import time is also important for CLI applications. That's why mercurial and Bazaar has lazy import system. Since many stdlib uses functools, many applications may be suffered from slow functools import even if we remove it from site.py. > maybe we don't have to copy the entire namedtuple structure? https://docs.python.org/3.5/library/functools.html#functools.lru_cache The doc says it's a namedtuple. So it should be namedtuple compatible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 01:41:02 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 08 Nov 2016 06:41:02 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1478587262.76.0.995527983513.issue28638@psf.upfronthosting.co.za> Xiang Zhang added the comment: > Yes. But first import time is also important for CLI applications. That's why mercurial and Bazaar has lazy import system. The lazy import system could benefit many libs so the result could be impressive. But here only functools is enhanced, half a millisecond is reduced. Performance of course is important, but replicating code sounds not good. It means you have to maintain two pieces. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 01:43:27 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 08 Nov 2016 06:43:27 +0000 Subject: [issue21590] Systemtap and DTrace support In-Reply-To: <1401195995.8.0.935339035852.issue21590@psf.upfronthosting.co.za> Message-ID: <1478587407.63.0.908201231511.issue21590@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 02:16:41 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 08 Nov 2016 07:16:41 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1478589401.03.0.640198550007.issue28638@psf.upfronthosting.co.za> INADA Naoki added the comment: > The lazy import system could benefit many libs so the result could be impressive. But here only functools is enhanced, half a millisecond is reduced. On the other hand, implementing lazy import makes application complex. This patch only enhance functools, but it is very important one module. Even if we remove functools from site.py, most applications relies on it, especially for functools.wraps(). This patch can optimize startup time of them. Half milliseconds is small, but it isn't negligible on some situation. Some people loves tools quickly starts. For example, there are many people maintain their vimrc to keep <50~100ms startup time. And Python is common language to implement vim plugins. Additionally, it make noise when profiling startup time. I've very confused when I saw PyParse_AddToken() in profile. Less noise make it easy to optimize startup time. > Performance of course is important, but replicating code sounds not good. It means you have to maintain two pieces. Yes. Balance is important. I want to hear more opinions from more other devs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 02:33:06 2016 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 08 Nov 2016 07:33:06 +0000 Subject: [issue28555] provid also sha-1 and sha-256 also on download links In-Reply-To: <1477732467.71.0.578620687465.issue28555@psf.upfronthosting.co.za> Message-ID: <1478590386.73.0.716406332128.issue28555@psf.upfronthosting.co.za> Benjamin Peterson added the comment: md5 is provided to verify the integrity of the download only. Use the GPG signatures to verify authenticity if the fact that all the downloads are served over HTTPS is insufficient. ---------- nosy: +benjamin.peterson resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 03:58:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Nov 2016 08:58:07 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478595487.54.0.572577188957.issue28563@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Just for reference: https://www.gnu.org/software/gettext/manual/gettext.html#Plural-forms http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/intl/plural.y Yet one security issue is that too deep recursion can cause MemoryError or even a crash in Python compiler. My patch creates too much nested parenthesis. Updated patch minimize using parenthesis to minimum and adds guards against too deep recursion. ---------- Added file: http://bugs.python.org/file45387/gettext-parse-plural-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 04:01:30 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Nov 2016 09:01:30 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1478595690.42.0.0932581294687.issue28638@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is the main culprit, importing the collections module or compiling a named tuple? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 05:01:30 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 08 Nov 2016 10:01:30 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478599290.9.0.539629016046.issue28563@psf.upfronthosting.co.za> Xiang Zhang added the comment: LGTM. And I expect there could be a comment about the special decimal number. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 05:59:27 2016 From: report at bugs.python.org (Armin Ronacher) Date: Tue, 08 Nov 2016 10:59:27 +0000 Subject: [issue27589] asyncio doc: issue in as_completed() doc In-Reply-To: <1469182105.52.0.303554063448.issue27589@psf.upfronthosting.co.za> Message-ID: <1478602767.58.0.664147113322.issue27589@psf.upfronthosting.co.za> Armin Ronacher added the comment: I am not even sure what the function is supposed to tell me. The documentation is very unclear and the example code does not help. What is "fs" for instance? And why would it return things that are not from fs? ---------- nosy: +aronacher _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 06:17:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Nov 2016 11:17:32 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1478603852.84.0.581460224268.issue28638@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Using namedtuple is not new in 3.6, thus this is not a regression that can be fixed at beta stage. Inlining the source of a named tuple class looks ugly solution. It would be better to write the source in separate file and import it. Makefile can have a rule for recreating this source file if collections.py is changed. More general solution would be to make namedtuple() using cached precompiled class and update the cache if it doesn't match namedtuple arguments. Yet one solution is to make namedtuple() not using compiling, but return patched local class. But Raymond is against this. ---------- assignee: -> rhettinger versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 06:18:15 2016 From: report at bugs.python.org (Petr) Date: Tue, 08 Nov 2016 11:18:15 +0000 Subject: [issue28632] configparser does not close files in read In-Reply-To: <1478537342.33.0.595722710962.issue28632@psf.upfronthosting.co.za> Message-ID: <1478603895.33.0.901956057367.issue28632@psf.upfronthosting.co.za> Petr added the comment: I am sorry, I can only reproduce it in the production environment so far, it does only occur on Ubuntu Linux (Python 3.5.1) and I am developing on Windows. So right now I cannot narrow it down (it does not occur with simple code, unfortunately). This is what I get after some experimentation: Exception ignored in: <_io.FileIO name='config.ini' mode='rb' closefd=True> ResourceWarning: unclosed file <_io.TextIOWrapper name='config.ini' mode='r' encoding='UTF-8'> The only place when I work with config.ini is the read method of ConfigParser, so it definitely should be an issue in ConfigParser. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 06:18:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Nov 2016 11:18:34 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478603914.44.0.881200952077.issue28563@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What a comment you need Xiang? Isn't existing comment enough? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 06:43:56 2016 From: report at bugs.python.org (Martin Wagner) Date: Tue, 08 Nov 2016 11:43:56 +0000 Subject: [issue19717] resolve() fails when the path doesn't exist In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za> Message-ID: <1478605436.43.0.599560124896.issue19717@psf.upfronthosting.co.za> Martin Wagner added the comment: i have a use-case that requires a behavior that is referenced above as --canonicalize-missing. essentially i need to get rid of relative parts in a path representation regardless the actual filesystem. my conclusion was that PurePath could provide that with a 'normpath' method, reflecting os.path.normpath's functionality. (that's from a user perspective, i haven't looked at any implementation details of the pathlib module.) ---------- nosy: +mwagner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 07:08:14 2016 From: report at bugs.python.org (Matthieu S) Date: Tue, 08 Nov 2016 12:08:14 +0000 Subject: [issue28000] Build fails on AIX with _LINUX_SOURCE_COMPAT flag In-Reply-To: <1473261703.53.0.692891859324.issue28000@psf.upfronthosting.co.za> Message-ID: <1478606894.53.0.113145531974.issue28000@psf.upfronthosting.co.za> Matthieu S added the comment: Sorry for the very late reply... Using _LINUX_SOURCE_COMPAT is sometimes preferable, as it greatly improves compatibility with code intended for Linux and improves XPG specs compliance. But I am not sure it should always be enabled. In our case, we use it as there where issues with AIX malloc and hotshot when building without it, but Python seems to globally work fine without, and we did not compare performances. Like you, I don't know why this was overridden, so it might be safer to keep the override and just add the #ifdef _LINUX_SOURCE_COMPAT. This also applies to Python 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 07:08:24 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Tue, 08 Nov 2016 12:08:24 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478606904.2.0.389274801192.issue28637@psf.upfronthosting.co.za> Wolfgang Maier added the comment: STINNER Victor added the comment: >BUT when Python is started from a virtual environment (created by the >"venv" module), the re module is important by default. > >haypo at speed-python$ venv/bin/python3 -c 'import sys; print("re" in sys.modules)' >True Exciting, I just verified that this is true and running python3 from a venv really seems to be the only situation, in which the re module gets imported during startup (at least it's only this one branch in site.py that uses it). If adding a single enum import to re causes such a big startup time difference I wonder how much more could be gained for the venv case by not importing re at all! Turns out that the complete code block in site.py that is used by venvs and that was partially shown by @haypo is: CONFIG_LINE = r'^(?P(\w|[-_])+)\s*=\s*(?P.*)\s*$' def venv(known_paths): global PREFIXES, ENABLE_USER_SITE env = os.environ if sys.platform == 'darwin' and '__PYVENV_LAUNCHER__' in env: executable = os.environ['__PYVENV_LAUNCHER__'] else: executable = sys.executable exe_dir, _ = os.path.split(os.path.abspath(executable)) site_prefix = os.path.dirname(exe_dir) sys._home = None conf_basename = 'pyvenv.cfg' candidate_confs = [ conffile for conffile in ( os.path.join(exe_dir, conf_basename), os.path.join(site_prefix, conf_basename) ) if os.path.isfile(conffile) ] if candidate_confs: import re config_line = re.compile(CONFIG_LINE) virtual_conf = candidate_confs[0] system_site = "true" # Issue 25185: Use UTF-8, as that's what the venv module uses when # writing the file. with open(virtual_conf, encoding='utf-8') as f: for line in f: line = line.strip() m = config_line.match(line) if m: d = m.groupdict() key, value = d['key'].lower(), d['value'] if key == 'include-system-site-packages': system_site = value.lower() elif key == 'home': sys._home = value sys.prefix = sys.exec_prefix = site_prefix # Doing this here ensures venv takes precedence over user-site addsitepackages(known_paths, [sys.prefix]) # addsitepackages will process site_prefix again if its in PREFIXES, # but that's ok; known_paths will prevent anything being added twice if system_site == "true": PREFIXES.insert(0, sys.prefix) else: PREFIXES = [sys.prefix] ENABLE_USER_SITE = False return known_paths So all the re module is good for here is to parse simple config file records with key/value pairs separated by '='. ?Shouldn't it be straightforward to implement that logic right inside that block directly without requiring a giant import? This should easily be doable for 3.6 still, seems as if it would solve the whole issue and probably speed up the performance tests much more than any reverted changesets could. What do you think? ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 07:16:08 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 08 Nov 2016 12:16:08 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1478607368.52.0.435721278319.issue28638@psf.upfronthosting.co.za> INADA Naoki added the comment: > What is the main culprit, importing the collections module or compiling a named tuple? In this time, later. But collections module takes 1+ ms to import too. I'll try to optimize it. > Using namedtuple is not new in 3.6, thus this is not a regression that can be fixed at beta stage. Make sense. > More general solution would be to make namedtuple() using cached precompiled class and update the cache if it doesn't match namedtuple arguments. What "precompiled class" means? pyc file? or source string to be executed? > Yet one solution is to make namedtuple() not using compiling, but return patched local class. But Raymond is against this. I'll search the discussion. I think anther solution is reimplement namedtuple by C. As far as I remember, attrs [1] does it. [1] https://pypi.python.org/pypi/attrs ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 07:36:59 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Nov 2016 12:36:59 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1478608619.03.0.90924376308.issue28638@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a sample patch that make namedtuple() not using dynamic compilation. It has rough the same performance effect as inlining the named tuple source, but affects all named tuples. ---------- Added file: http://bugs.python.org/file45388/namedtuple-no-compile.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 07:37:38 2016 From: report at bugs.python.org (Carl Ekerot) Date: Tue, 08 Nov 2016 12:37:38 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478608658.31.0.366981078561.issue28563@psf.upfronthosting.co.za> Carl Ekerot added the comment: Looks good to me. It behaves as intended on every input I can think of. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 07:47:58 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 08 Nov 2016 12:47:58 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1478609278.1.0.746842145086.issue28638@psf.upfronthosting.co.za> INADA Naoki added the comment: (tip) $ ~/local/py37/bin/python3 -m perf timeit -s 'import importlib, functools' -- 'importlib.reload(functools)' ..................... Median +- std dev: 1.21 ms +- 0.01 ms (namedtuple-no-compile.patch) $ ~/local/py37/bin/python3 -m perf timeit -s 'import importlib, functools' -- 'importlib.reload(functools)' ..................... Median +- std dev: 677 us +- 8 us Nice! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 07:48:57 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Nov 2016 12:48:57 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478609337.94.0.667956023028.issue28637@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch removes the use of re from site.py. ---------- keywords: +patch nosy: +serhiy.storchaka Added file: http://bugs.python.org/file45389/site-not-use-re.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 07:53:04 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Nov 2016 12:53:04 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478609584.26.0.490231960638.issue28637@psf.upfronthosting.co.za> STINNER Victor added the comment: site-not-use-re.patch: The change on site.py LGTM. I don't see why re was used in the first place for such simple text format ;-) I suggest to push the fix into Python 3.6 and 3.7. But what is the change in Lib/collections/__init__.py? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 07:55:03 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Nov 2016 12:55:03 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1478609703.52.0.608470073659.issue28638@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: One of problems with this patch is that it make instantiating a namedtuple much slower (due to parsing arguments by Python code). This can be solved by using eval() for creating only the __new__ method (see commented out line "result.__new__ = eval(...)"). This increases the time of creating named tuple class, but it still is faster than with current code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 07:57:02 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Nov 2016 12:57:02 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478609822.23.0.252565454965.issue28637@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, please ignore it. This is a sample code from other issue (issue28638). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 07:58:01 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Tue, 08 Nov 2016 12:58:01 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478609881.95.0.873512946072.issue28637@psf.upfronthosting.co.za> Wolfgang Maier added the comment: @serhiy.storchaka you've beaten me by a few minutes (still waiting for the test suite to finish). Your patch is "contaminated" by an additional change in collections/__init__.py though so I'm still uploading my version (which also tries to stick as close as possible to the existing behaviour though that probably won't matter much) ---------- Added file: http://bugs.python.org/file45390/no_use_re_in_site_py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 07:58:08 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Nov 2016 12:58:08 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478609888.16.0.546245583638.issue28637@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file45391/site-not-use-re.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 08:12:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Nov 2016 13:12:32 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478610752.69.0.85437814922.issue28637@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It seems to me that current regular expression is not correct. It can keep trailing whitespaces it a value. I'm not experienced with venv and don't know what tests are needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 08:13:36 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 08 Nov 2016 13:13:36 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478610816.09.0.545736563811.issue28563@psf.upfronthosting.co.za> Xiang Zhang added the comment: > What a comment you need Xiang? Isn't existing comment enough? Serhiy, I mean the case a number starting with 0, e.g. 0123. The plural form is a C expression and in C 0123 is an octal number. c2py now interprets it as a decimal number. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 09:17:56 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Tue, 08 Nov 2016 14:17:56 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478614676.02.0.206804357043.issue28637@psf.upfronthosting.co.za> Changes by Wolfgang Maier : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 09:37:49 2016 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 08 Nov 2016 14:37:49 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1478615869.28.0.728533263032.issue28635@psf.upfronthosting.co.za> Mark Dickinson added the comment: What no mention of math.tau? It's a PEP-level change! ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 09:41:36 2016 From: report at bugs.python.org (Elvis Pranskevichus) Date: Tue, 08 Nov 2016 14:41:36 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1478616096.98.0.179236920525.issue28635@psf.upfronthosting.co.za> Elvis Pranskevichus added the comment: The page is a work-in-progress. We'll surely capture all notable changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 09:45:23 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Nov 2016 14:45:23 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1478616323.92.0.315122235416.issue28635@psf.upfronthosting.co.za> STINNER Victor added the comment: Holy cow, I missed the PEP 628. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 09:50:40 2016 From: report at bugs.python.org (Elvis Pranskevichus) Date: Tue, 08 Nov 2016 14:50:40 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1478616640.76.0.872189630481.issue28635@psf.upfronthosting.co.za> Elvis Pranskevichus added the comment: I'm actually working on a tool that parses Misc/NEWS, cpython and peps repos, and roundup to gather and organize the changes to make the news editor's job easier. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 10:11:25 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 08 Nov 2016 15:11:25 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478617885.19.0.141688746734.issue28637@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The effect is limited to venv only in a narrow sense. The startup time for running programs from an IDLE editor is also affected. Many other programs also import re either directly or indirectly on startup. For instance, importing argparse imports re. Running Python from Command Prompt: Python 3.6.0b3 (default, Nov 1 2016, 03:21:01) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys; 're' in sys.modules False >>> import argparse >>> import sys; 're' in sys.modules True ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 11:09:05 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Nov 2016 16:09:05 +0000 Subject: [issue19717] resolve() fails when the path doesn't exist In-Reply-To: <1478605436.43.0.599560124896.issue19717@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Please make sure this lands in beta 4! --Guido (mobile) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 11:12:10 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Nov 2016 16:12:10 +0000 Subject: [issue27589] asyncio doc: issue in as_completed() doc In-Reply-To: <1478602767.58.0.664147113322.issue27589@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: However, in general you should use a different pattern. Wrap each future in a coroutine that does whatever you want to do to the first one ready and maybe cancel the others. Then gather() all coroutines with the flag that keeps errors. --Guido (mobile) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 11:26:18 2016 From: report at bugs.python.org (Hynek Schlawack) Date: Tue, 08 Nov 2016 16:26:18 +0000 Subject: [issue27589] asyncio doc: issue in as_completed() doc In-Reply-To: <1469182105.52.0.303554063448.issue27589@psf.upfronthosting.co.za> Message-ID: <1478622378.55.0.352245281074.issue27589@psf.upfronthosting.co.za> Hynek Schlawack added the comment: Such an idiom is IMHO not the main usefulness of this function tho. As an (untested) example, something like async def f(n): await asyncio.sleep(n) return n for f in asyncio.as_completed([f(3), f(2), f(1)]): print(await f) will print: 1 2 3 That?s *super* useful if you?re coordinating multiple independent external systems and need to process their results as soon as they arrive (and not once they?re *all* done). Maybe it always worked by accident for me but it?s my understanding, that that is what this function is for (and I haven?t found another way to achieve it). That?s why it would be nice if there?d be authoritative docs on what it?s supposed to do. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 11:30:27 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Nov 2016 16:30:27 +0000 Subject: [issue27589] asyncio doc: issue in as_completed() doc In-Reply-To: <1478622378.55.0.352245281074.issue27589@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Well, in that case the idiom will be even simpler: wrap each one in a coroutine that awaits it and prints the result and then gather() all the coroutine wrappers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 11:42:48 2016 From: report at bugs.python.org (Hojung An) Date: Tue, 08 Nov 2016 16:42:48 +0000 Subject: [issue28640] UnicodeDecodeError: 'cp949' Message-ID: <1478623368.83.0.979535851472.issue28640@psf.upfronthosting.co.za> New submission from Hojung An: I have Python3.6 and when I try to install pyinstaller using (pip install pyinstaller) I receive error messages for: 1) UnicodeDecodeError: 'cp949' 2) Command 'python setup.py egg_info' failed with error code 1 When I inquired about this to webmaster at python.org they asked me to post it here as it seemed like a bug. ---------- components: Windows files: unicode_error.jpg messages: 280317 nosy: Hojung An, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: UnicodeDecodeError: 'cp949' versions: Python 3.6 Added file: http://bugs.python.org/file45392/unicode_error.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 11:43:58 2016 From: report at bugs.python.org (Charalampos Stratakis) Date: Tue, 08 Nov 2016 16:43:58 +0000 Subject: [issue21590] Systemtap and DTrace support In-Reply-To: <1401195995.8.0.935339035852.issue21590@psf.upfronthosting.co.za> Message-ID: <1478623438.98.0.31306276097.issue21590@psf.upfronthosting.co.za> Charalampos Stratakis added the comment: @?ukasz Dug a bit more to it. Yes it is RPM specific for that case, in the sense that we create different subfolders for the debug and the normal(optimized) builds under the build/ dir, where the Include directory does not exist. the dtrace wrapper assumes that the directory already exists. The issue of course can be reproduced with any packaging system (or ways to compile python) that follow this approach, although I am not aware currently if this can happen or might be happening anywhere else. By creating the directory (if it doesn't exist) at the Makefile rule for generating pydtrace_probes.h, this can be circumvented. Attaching a patch that fixes this issue for consideration. ---------- Added file: http://bugs.python.org/file45393/create-Include-dir-to-properly-generate-pydtrace_probes.h-file.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 12:04:49 2016 From: report at bugs.python.org (Michael Foord) Date: Tue, 08 Nov 2016 17:04:49 +0000 Subject: [issue28569] mock.attach_mock should work with any return value of patch() In-Reply-To: <1477935134.31.0.733482108189.issue28569@psf.upfronthosting.co.za> Message-ID: <1478624689.7.0.677642642146.issue28569@psf.upfronthosting.co.za> Michael Foord added the comment: Sure, go ahead Syed. Feel free to ask any questions you may have. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 12:10:46 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 08 Nov 2016 17:10:46 +0000 Subject: [issue28641] Describe PEP 495 features in "What's New in Python 3.6" document Message-ID: <1478625046.84.0.866752786385.issue28641@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: See also #27595. ---------- assignee: belopolsky components: Documentation messages: 280320 nosy: belopolsky, p-ganssle, tim.peters priority: normal severity: normal stage: needs patch status: open title: Describe PEP 495 features in "What's New in Python 3.6" document versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 12:14:53 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 08 Nov 2016 17:14:53 +0000 Subject: [issue28641] Describe PEP 495 features in "What's New in Python 3.6" document In-Reply-To: <1478625046.84.0.866752786385.issue28641@psf.upfronthosting.co.za> Message-ID: <1478625293.4.0.398534750781.issue28641@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Paul (p-ganssle), based on your recent experience implementing PEP 495, what are the main points that we should cover in What's New? Also, any comments/criticism on the recent changes to the datetime module documentation are welcome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 12:16:29 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 08 Nov 2016 17:16:29 +0000 Subject: [issue28640] UnicodeDecodeError: 'cp949' In-Reply-To: <1478623368.83.0.979535851472.issue28640@psf.upfronthosting.co.za> Message-ID: <1478625389.63.0.245336447376.issue28640@psf.upfronthosting.co.za> Steve Dower added the comment: Firstly, welcome to the tracker, and thanks for helping test the early releases of Python 3.6. For future reference, it's much preferred if you can copy-paste error messages into the text of the message. Attaching large log files is okay, but screenshots should only really be used for things that are not text. In this case, it would seem to be an issue with the pefile package. It is reading a file with a default encoding as part of its setup.py, but since the file appears to be part of its own package it really should specify the encoding of the file. It's likely that the file "works" under US English encoding, but obviously not for other encodings such as CP949. If the authors of pefile specify the encoding when they open the file, then this problem will go away. (As it happens, I investigated the possibility of changing Python to handle this situation better, and unfortunately it is not feasible. We've provided the tools for authors to avoid these issues on their own, but we can't reasonably change how they work without breaking a lot of existing code. So it really needs to be fixed by the pefile authors here.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 12:16:57 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 08 Nov 2016 17:16:57 +0000 Subject: [issue28640] UnicodeDecodeError: 'cp949' In-Reply-To: <1478623368.83.0.979535851472.issue28640@psf.upfronthosting.co.za> Message-ID: <1478625417.85.0.324858526772.issue28640@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 12:21:21 2016 From: report at bugs.python.org (Marc Garcia) Date: Tue, 08 Nov 2016 17:21:21 +0000 Subject: [issue28642] csv reader loosing rows with big files and tab delimiter Message-ID: <1478625681.85.0.319156602721.issue28642@psf.upfronthosting.co.za> New submission from Marc Garcia: I'm using the csv module from Python standard library, to read a 1.4Gb file with 11,157,064 of rows. The file is the Geonames dataset for all countries, which can be freely downloaded [1]. I'm using this code to read it: import csv with open('allCountries.txt', 'r') as fd: reader = csv.reader(fd, delimiter='\t') for i, row in enumerate(reader): pass print(i + 1) # prints 10381963 print(reader.line_num) # prints 11157064 For some reason, there are around 7% of the rows in the files, that are skipped. The rows doesn't have anything special (most of them are all ascii characters, even if the file is in utf-8). If I create a new file with all the skipped files, and I read it again in the same way, around 30% of the rows are skipped. So many of them weren't returned by the iterator when being a part of a bigger file, but now they are. Note that the attribute line_num has the right number. Also note that if I remove the delimiter parameter (tab) from the reader, and it uses the default comma, the iteration on the reader doesn't skip any row. I checked what I think it's the relevant part of the code [2], but I couldn't see anything that could cause this bug. 1. http://download.geonames.org/export/dump/allCountries.zip 2. https://hg.python.org/cpython/file/tip/Modules/_csv.c#l787 ---------- components: Library (Lib) messages: 280323 nosy: datapythonista priority: normal severity: normal status: open title: csv reader loosing rows with big files and tab delimiter versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 12:28:22 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 08 Nov 2016 17:28:22 +0000 Subject: [issue28642] csv reader loosing rows with big files and tab delimiter In-Reply-To: <1478625681.85.0.319156602721.issue28642@psf.upfronthosting.co.za> Message-ID: <1478626102.09.0.673596469059.issue28642@psf.upfronthosting.co.za> SilentGhost added the comment: Could you perhaps make the smaller file make available somewhere? ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 12:39:33 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Nov 2016 17:39:33 +0000 Subject: [issue28642] csv reader loosing rows with big files and tab delimiter In-Reply-To: <1478625681.85.0.319156602721.issue28642@psf.upfronthosting.co.za> Message-ID: <1478626773.92.0.865327243976.issue28642@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > If I create a new file with all the skipped files, and I read it again in the same way, around 30% of the rows are skipped. Could you please provide this smaller file? Or better make yet few iterations of keeping only skipped lines until the file will decrease to just few lines. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 12:42:25 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Nov 2016 17:42:25 +0000 Subject: [issue28642] csv reader loosing rows with big files and tab delimiter In-Reply-To: <1478625681.85.0.319156602721.issue28642@psf.upfronthosting.co.za> Message-ID: <1478626945.89.0.355930481791.issue28642@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is the average number of columns on the file? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 12:54:49 2016 From: report at bugs.python.org (Irv Kalb) Date: Tue, 08 Nov 2016 17:54:49 +0000 Subject: [issue27854] Installed 2.7: IDLE Help disabled because help.html is missing In-Reply-To: <1472078066.3.0.116550230826.issue27854@psf.upfronthosting.co.za> Message-ID: <1478627689.92.0.591397101118.issue27854@psf.upfronthosting.co.za> Irv Kalb added the comment: On my Mac (with version 2.7.12), selecting Help -> IDLE Help brings up a window titled "IDLE Help", it has a pop down with "TOC" selected and many pages of text documentation. On my Windows system (also with version 2.7.12), selecting help -> IDLE help does nothing. I tried it from both the Shell window and from an editor window, and no documentation window appeared. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 13:18:45 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Nov 2016 18:18:45 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <20161108181833.31838.46729.9A4E5D48@psf.io> Roundup Robot added the comment: New changeset a822818ec74e by Serhiy Storchaka in branch '3.6': Issue #28637: No longer use re in site.py. https://hg.python.org/cpython/rev/a822818ec74e New changeset a4ea837a7f84 by Serhiy Storchaka in branch 'default': Issue #28637: No longer use re in site.py. https://hg.python.org/cpython/rev/a4ea837a7f84 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 13:28:13 2016 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 08 Nov 2016 18:28:13 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za> Message-ID: <1478629693.63.0.804250546116.issue19569@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: About MSVC compiler: https://msdn.microsoft.com/en-us/library/044swk7y.aspx https://msdn.microsoft.com/en-us/library/2c8f766e.aspx https://msdn.microsoft.com/en-us/library/d9x1s805.aspx So both: #pragma warning(push) #pragma warning(disable: 4996) /* Some code */ #pragma warning(pop) And: __pragma(warning(push)) __pragma(warning(disable: 4996)) /* Some code */ __pragma(warning(pop)) Would generally work, but only the second form is suitable for usage inside macros. Updated proposition of Py_COMPILER_DIAGNOSTIC_* macros: #if defined(__GNUC__) && ((__GNUC__ >= 5) || (__GNUC__ == 4) && (__GNUC_MINOR__ >= 6)) #define Py_COMPILER_DIAGNOSTIC_PUSH _Pragma("GCC diagnostic push") #define Py_COMPILER_DIAGNOSTIC_IGNORE_DEPRECATED_DECLARATIONS _Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"") #define Py_COMPILER_DIAGNOSTIC_POP _Pragma("GCC diagnostic pop") #elif defined(_MSC_VER) && _MSC_VER >= 1300 #define Py_COMPILER_DIAGNOSTIC_PUSH __pragma(warning(push)) #define Py_COMPILER_DIAGNOSTIC_IGNORE_DEPRECATED_DECLARATIONS __pragma(warning(disable: 4996)) #define Py_COMPILER_DIAGNOSTIC_POP __pragma(warning(pop)) #else #define Py_COMPILER_DIAGNOSTIC_PUSH #define Py_COMPILER_DIAGNOSTIC_IGNORE_DEPRECATED_DECLARATIONS #define Py_COMPILER_DIAGNOSTIC_POP #endif ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 13:29:13 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Nov 2016 18:29:13 +0000 Subject: [issue28585] Restore docstring of os._isdir In-Reply-To: <1478075476.63.0.19722756431.issue28585@psf.upfronthosting.co.za> Message-ID: <20161108182903.32315.21486.8A014AEC@psf.io> Roundup Robot added the comment: New changeset 5b4fa92dac43 by Serhiy Storchaka in branch '3.5': Issue #28585: Restored docstring of os._isdir(). https://hg.python.org/cpython/rev/5b4fa92dac43 New changeset 3da89b1678da by Serhiy Storchaka in branch '3.6': Issue #28585: Restored docstring of os._isdir(). https://hg.python.org/cpython/rev/3da89b1678da New changeset d77fe603cded by Serhiy Storchaka in branch 'default': Issue #28585: Restored docstring of os._isdir(). https://hg.python.org/cpython/rev/d77fe603cded ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 13:34:46 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Nov 2016 18:34:46 +0000 Subject: [issue28621] Refactor duplicate code calculating digit's bit length In-Reply-To: <1478374648.81.0.502575461924.issue28621@psf.upfronthosting.co.za> Message-ID: <20161108183434.22316.91720.15E2C52D@psf.io> Roundup Robot added the comment: New changeset 1940b72b0a02 by Serhiy Storchaka in branch 'default': Issue #28621: Sped up converting int to float by reusing faster bits counting https://hg.python.org/cpython/rev/1940b72b0a02 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 13:35:18 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Nov 2016 18:35:18 +0000 Subject: [issue28585] Restore docstring of os._isdir In-Reply-To: <1478075476.63.0.19722756431.issue28585@psf.upfronthosting.co.za> Message-ID: <1478630118.76.0.460211442829.issue28585@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Zachary. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 13:36:05 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Nov 2016 18:36:05 +0000 Subject: [issue28621] Refactor duplicate code calculating digit's bit length In-Reply-To: <1478374648.81.0.502575461924.issue28621@psf.upfronthosting.co.za> Message-ID: <1478630165.52.0.988702898442.issue28621@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Adrian for your contribution. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 13:48:09 2016 From: report at bugs.python.org (Big Stone) Date: Tue, 08 Nov 2016 18:48:09 +0000 Subject: [issue28636] strange issue with Pandas-0.19.1 on Python-3.6.0b3 In-Reply-To: <1478553952.22.0.478578005761.issue28636@psf.upfronthosting.co.za> Message-ID: <1478630889.63.0.343728602691.issue28636@psf.upfronthosting.co.za> Big Stone added the comment: Thank you, Victor. So I guess I should close the issue. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 14:12:02 2016 From: report at bugs.python.org (Pinku Surana) Date: Tue, 08 Nov 2016 19:12:02 +0000 Subject: [issue28610] Provide PDB hook to customize how to find source files In-Reply-To: <1478276308.14.0.744834650748.issue28610@psf.upfronthosting.co.za> Message-ID: <1478632322.69.0.47200697889.issue28610@psf.upfronthosting.co.za> Pinku Surana added the comment: Thanks. This is clever. I've tried it out and it works. Would it be more appropriate to use "importlib" and "importlib.abc" to implement a custom loader for a string script? It looks like importlib.abc.InspectLoader does the right thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 14:17:32 2016 From: report at bugs.python.org (Big Stone) Date: Tue, 08 Nov 2016 19:17:32 +0000 Subject: [issue28555] provid also sha-1 and sha-256 also on download links In-Reply-To: <1477732467.71.0.578620687465.issue28555@psf.upfronthosting.co.za> Message-ID: <1478632652.87.0.0585710912588.issue28555@psf.upfronthosting.co.za> Big Stone added the comment: I fear GPG is not easy stuff for Windows users. I fear a bunch of people on this network can circomvent DNS and make python.org points to the wrong place. sha-1 instead of md5 would have been an improvement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 14:28:55 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Nov 2016 19:28:55 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <20161108192851.66352.90178.3870693A@psf.io> Roundup Robot added the comment: New changeset e0cc3fadd7b3 by Serhiy Storchaka in branch '2.7': Issue #28563: Fixed possible DoS and arbitrary code execution when handle https://hg.python.org/cpython/rev/e0cc3fadd7b3 New changeset 7e66c5dc4218 by Serhiy Storchaka in branch '3.3': Issue #28563: Fixed possible DoS and arbitrary code execution when handle https://hg.python.org/cpython/rev/7e66c5dc4218 New changeset 730cf8cdf02c by Serhiy Storchaka in branch '3.4': Issue #28563: Fixed possible DoS and arbitrary code execution when handle https://hg.python.org/cpython/rev/730cf8cdf02c New changeset e0dd4cc9661a by Serhiy Storchaka in branch '3.5': Issue #28563: Fixed possible DoS and arbitrary code execution when handle https://hg.python.org/cpython/rev/e0dd4cc9661a New changeset 7ea64ab9a5c8 by Serhiy Storchaka in branch '3.6': Issue #28563: Fixed possible DoS and arbitrary code execution when handle https://hg.python.org/cpython/rev/7ea64ab9a5c8 New changeset 4ca9a4f96edc by Serhiy Storchaka in branch 'default': Issue #28563: Fixed possible DoS and arbitrary code execution when handle https://hg.python.org/cpython/rev/4ca9a4f96edc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 14:29:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Nov 2016 19:29:34 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1478633374.19.0.590539627864.issue28563@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 14:32:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Nov 2016 19:32:58 +0000 Subject: [issue18317] gettext: DoS via crafted Plural-Forms In-Reply-To: <1372370486.3.0.302841036863.issue18317@psf.upfronthosting.co.za> Message-ID: <1478633578.52.0.109989351827.issue18317@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The DoS as well as other flaws is fixed in issue28563 by implementing a complete parser for GNU gettext plural form expressions. ---------- nosy: +serhiy.storchaka resolution: -> fixed stage: test needed -> resolved status: open -> closed superseder: -> Arbitrary code execution in gettext.c2py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 14:33:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Nov 2016 19:33:58 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1478633638.68.0.489766421002.issue23996@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think that's all with this issue. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 14:35:53 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 08 Nov 2016 19:35:53 +0000 Subject: [issue28538] _socket module cross-compilation error on android-24 In-Reply-To: <1477474733.85.0.0781476042155.issue28538@psf.upfronthosting.co.za> Message-ID: <1478633753.5.0.437676546607.issue28538@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Patch attached. ---------- components: +Cross-Build keywords: +patch nosy: +Alex.Willmer, doko stage: needs patch -> patch review Added file: http://bugs.python.org/file45394/if_nameindex.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 14:45:16 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Nov 2016 19:45:16 +0000 Subject: [issue28494] is_zipfile false positives In-Reply-To: <1476997729.0.0.643464084789.issue28494@psf.upfronthosting.co.za> Message-ID: <1478634316.79.0.75238301625.issue28494@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The problem is that the zipfile module supports even not well-formed archives, with a data appended past a comment, and with truncated comment. There are special tests for this, and the proposed patch breaks these tests: test_comments, test_ignores_newline_at_end, test_ignores_stuff_appended_past_comments. See issue10694 and issue1622. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 14:56:35 2016 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 08 Nov 2016 19:56:35 +0000 Subject: [issue28643] Broken makefile depends for profile-opt target Message-ID: <1478634995.26.0.389156722395.issue28643@psf.upfronthosting.co.za> New submission from Neil Schemenauer: I notice that after running "make" then running "make install", the build will go through the whole compile/profile/compile process again. This is really infuriating behaviour, given the extremely long make time for the profiled optimized build. The problem appears to me to be that the "profile-opt" target does not have proper dependencies. I think changing it to: profile-opt: $(BUILDPYTHON) should fix it. If my "make install" ever finishes, maybe I will test it. ;-) ---------- components: Build messages: 280342 nosy: nascheme priority: normal severity: normal stage: needs patch status: open title: Broken makefile depends for profile-opt target type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 15:15:49 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Nov 2016 20:15:49 +0000 Subject: [issue27243] __aiter__ should return async iterator instead of awaitable In-Reply-To: <1465240896.52.0.994549894653.issue27243@psf.upfronthosting.co.za> Message-ID: <20161108201546.1932.29467.5FC3BDF9@psf.io> Roundup Robot added the comment: New changeset a0d50aad7b02 by Yury Selivanov in branch '3.6': Issue #27243: Change PendingDeprecationWarning -> DeprecationWarning. https://hg.python.org/cpython/rev/a0d50aad7b02 New changeset 9550f0d22d27 by Yury Selivanov in branch 'default': Merge 3.6 (issue #27243) https://hg.python.org/cpython/rev/9550f0d22d27 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 15:33:34 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 08 Nov 2016 20:33:34 +0000 Subject: [issue28610] Provide PDB hook to customize how to find source files In-Reply-To: <1478276308.14.0.744834650748.issue28610@psf.upfronthosting.co.za> Message-ID: <1478637214.91.0.681924697121.issue28610@psf.upfronthosting.co.za> Xavier de Gaye added the comment: This is a simple code object compiled from a source (the string), a module is quite different and more complex. The patch uses a fake module Loader to use linecache, there is no gain in going any further and pulling from the importlib machinery, I think. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 15:52:14 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Nov 2016 20:52:14 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478616640.76.0.872189630481.issue28635@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Elvis Pranskevichus added the comment: > I'm actually working on a tool that parses Misc/NEWS, cpython and peps repos, and roundup to gather and organize the changes to make the news editor's job easier. I don't understand why developers don't do it during the cycle :-/ I'm trying to keep What's Up In Python X.Y? up to date. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 15:55:04 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Nov 2016 20:55:04 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <20161108181833.31838.46729.9A4E5D48@psf.io> Message-ID: STINNER Victor added the comment: Cool, thanks Serhiy for the site enhancement :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 15:57:01 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Nov 2016 20:57:01 +0000 Subject: [issue26934] android: test_faulthandler fails In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za> Message-ID: <1478638621.58.0.159722186567.issue26934@psf.upfronthosting.co.za> STINNER Victor added the comment: buggy_raise_3.patch LGTM but I don't think that it's worth it to add @requires_raise to support directly. I suggest to only add it to test_faulthandler.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 16:05:57 2016 From: report at bugs.python.org (Mariusz Masztalerczuk) Date: Tue, 08 Nov 2016 21:05:57 +0000 Subject: [issue18233] SSLSocket.getpeercertchain() In-Reply-To: <1371415195.44.0.636993698614.issue18233@psf.upfronthosting.co.za> Message-ID: <1478639157.96.0.275523234445.issue18233@psf.upfronthosting.co.za> Mariusz Masztalerczuk added the comment: ping! :) Could someone look at my changes? :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 16:07:51 2016 From: report at bugs.python.org (Matthew Barnett) Date: Tue, 08 Nov 2016 21:07:51 +0000 Subject: [issue28642] csv reader loosing rows with big files and tab delimiter In-Reply-To: <1478625681.85.0.319156602721.issue28642@psf.upfronthosting.co.za> Message-ID: <1478639271.91.0.849147582982.issue28642@psf.upfronthosting.co.za> Matthew Barnett added the comment: I split the file into sections, each containing no more 1000 lines, and tried reading each section. Attached is a zip file of those that didn't return the expected number of rows. The problem appears to be due to unclosed quotes, which cause following lines to be consumed as part of the field. It looks a little strange, so I wonder if the file has got corrupted somewhere. ---------- nosy: +mrabarnett Added file: http://bugs.python.org/file45395/allCountries_sections.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 16:09:28 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Nov 2016 21:09:28 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1478639368.81.0.29633403588.issue28618@psf.upfronthosting.co.za> STINNER Victor added the comment: >> Do you mean comparison between current Python with PGO and patched >> Python without PGO? > > Yes. Ok, here you have. As expected, PGO compilation is faster than default compilation with my patch. PGO implements more optimization than just __attribute__((hot)), it also optimizes branches for example. haypo at smithers$ python3 -m perf compare_to pgo.json.gz patch.json.gz -G --min-speed=5 Slower (56): - regex_effbot: 4.30 ms +- 0.26 ms -> 5.77 ms +- 0.33 ms: 1.34x slower - telco: 16.0 ms +- 1.1 ms -> 20.6 ms +- 0.4 ms: 1.29x slower - xml_etree_process: 174 ms +- 15 ms -> 218 ms +- 29 ms: 1.25x slower - xml_etree_generate: 205 ms +- 16 ms -> 254 ms +- 4 ms: 1.24x slower - unpickle_list: 6.04 us +- 1.12 us -> 7.47 us +- 0.18 us: 1.24x slower - call_simple: 10.6 ms +- 1.4 ms -> 13.1 ms +- 0.3 ms: 1.24x slower - mako: 33.5 ms +- 0.3 ms -> 41.3 ms +- 0.9 ms: 1.23x slower - pathlib: 37.0 ms +- 2.3 ms -> 44.7 ms +- 2.0 ms: 1.21x slower - sqlite_synth: 7.56 us +- 0.20 us -> 8.97 us +- 0.18 us: 1.19x slower - unpickle: 24.2 us +- 3.9 us -> 28.7 us +- 0.3 us: 1.18x slower - chameleon: 23.4 ms +- 2.6 ms -> 27.4 ms +- 1.5 ms: 1.17x slower - spectral_norm: 214 ms +- 7 ms -> 249 ms +- 9 ms: 1.17x slower - nqueens: 210 ms +- 2 ms -> 244 ms +- 36 ms: 1.16x slower - unpickle_pure_python: 717 us +- 10 us -> 831 us +- 66 us: 1.16x slower - pickle: 18.7 us +- 4.3 us -> 21.6 us +- 3.3 us: 1.15x slower - sympy_expand: 829 ms +- 39 ms -> 957 ms +- 28 ms: 1.15x slower - genshi_text: 73.1 ms +- 3.2 ms -> 84.3 ms +- 1.1 ms: 1.15x slower - pickle_list: 6.82 us +- 0.20 us -> 7.86 us +- 0.05 us: 1.15x slower - sympy_str: 372 ms +- 28 ms -> 428 ms +- 3 ms: 1.15x slower - xml_etree_parse: 231 ms +- 7 ms -> 266 ms +- 9 ms: 1.15x slower - call_method_slots: 14.0 ms +- 1.3 ms -> 16.1 ms +- 1.2 ms: 1.15x slower - sympy_sum: 169 ms +- 6 ms -> 194 ms +- 19 ms: 1.15x slower - logging_format: 29.3 us +- 2.5 us -> 33.7 us +- 1.6 us: 1.15x slower - logging_simple: 25.7 us +- 2.1 us -> 29.3 us +- 0.4 us: 1.14x slower - genshi_xml: 159 ms +- 15 ms -> 182 ms +- 1 ms: 1.14x slower - xml_etree_iterparse: 178 ms +- 3 ms -> 203 ms +- 5 ms: 1.14x slower - pickle_pure_python: 1.06 ms +- 0.17 ms -> 1.21 ms +- 0.16 ms: 1.14x slower - logging_silent: 618 ns +- 11 ns -> 705 ns +- 62 ns: 1.14x slower - hexiom: 19.0 ms +- 0.2 ms -> 21.7 ms +- 0.2 ms: 1.14x slower - html5lib: 184 ms +- 11 ms -> 209 ms +- 31 ms: 1.14x slower - call_method: 14.3 ms +- 0.7 ms -> 16.3 ms +- 0.1 ms: 1.14x slower - django_template: 324 ms +- 18 ms -> 368 ms +- 3 ms: 1.14x slower - sympy_integrate: 37.9 ms +- 0.3 ms -> 43.0 ms +- 2.7 ms: 1.13x slower - deltablue: 15.0 ms +- 2.0 ms -> 16.9 ms +- 1.0 ms: 1.12x slower - call_method_unknown: 16.0 ms +- 0.4 ms -> 17.9 ms +- 0.2 ms: 1.12x slower - 2to3: 611 ms +- 12 ms -> 677 ms +- 57 ms: 1.11x slower - regex_compile: 300 ms +- 3 ms -> 332 ms +- 21 ms: 1.11x slower - json_loads: 50.5 us +- 2.5 us -> 55.8 us +- 1.2 us: 1.10x slower - unpack_sequence: 111 ns +- 5 ns -> 122 ns +- 1 ns: 1.10x slower - pickle_dict: 53.2 us +- 3.7 us -> 58.1 us +- 3.7 us: 1.09x slower - scimark_sor: 420 ms +- 60 ms -> 458 ms +- 12 ms: 1.09x slower - scimark_lu: 398 ms +- 74 ms -> 434 ms +- 18 ms: 1.09x slower - regex_dna: 227 ms +- 1 ms -> 247 ms +- 9 ms: 1.09x slower - pidigits: 266 ms +- 33 ms -> 290 ms +- 10 ms: 1.09x slower - chaos: 243 ms +- 2 ms -> 265 ms +- 3 ms: 1.09x slower - crypto_pyaes: 197 ms +- 16 ms -> 215 ms +- 28 ms: 1.09x slower - dulwich_log: 129 ms +- 15 ms -> 140 ms +- 8 ms: 1.08x slower - sqlalchemy_imperative: 50.8 ms +- 0.9 ms -> 55.0 ms +- 1.8 ms: 1.08x slower - meteor_contest: 173 ms +- 22 ms -> 187 ms +- 5 ms: 1.08x slower - sqlalchemy_declarative: 268 ms +- 11 ms -> 290 ms +- 3 ms: 1.08x slower - tornado_http: 335 ms +- 4 ms -> 361 ms +- 3 ms: 1.08x slower - python_startup: 20.6 ms +- 0.6 ms -> 22.1 ms +- 0.9 ms: 1.08x slower - python_startup_no_site: 8.37 ms +- 0.08 ms -> 9.00 ms +- 0.07 ms: 1.08x slower - go: 518 ms +- 36 ms -> 557 ms +- 39 ms: 1.07x slower - raytrace: 1.14 sec +- 0.08 sec -> 1.22 sec +- 0.02 sec: 1.07x slower - scimark_fft: 594 ms +- 29 ms -> 627 ms +- 13 ms: 1.06x slower Benchmark hidden because not significant (8): fannkuch, float, json_dumps, nbody, regex_v8, richards, scimark_monte_carlo, scimark_sparse_mat_mult ---------- Added file: http://bugs.python.org/file45396/pgo.json.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 16:09:38 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Nov 2016 21:09:38 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1478639378.61.0.521206354479.issue28618@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file45397/patch.json.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 16:21:24 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 08 Nov 2016 21:21:24 +0000 Subject: [issue28642] csv reader loosing rows with big files and tab delimiter In-Reply-To: <1478625681.85.0.319156602721.issue28642@psf.upfronthosting.co.za> Message-ID: <1478640084.24.0.454409625453.issue28642@psf.upfronthosting.co.za> SilentGhost added the comment: so using quoting=csv.QUOTE_NONE should solve the immediate problem of "losing" lines then, I'm not sure csv module ever supported dealing with corrupted files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 16:37:16 2016 From: report at bugs.python.org (Marc Garcia) Date: Tue, 08 Nov 2016 21:37:16 +0000 Subject: [issue28642] csv reader losing rows with big files and tab delimiter In-Reply-To: <1478625681.85.0.319156602721.issue28642@psf.upfronthosting.co.za> Message-ID: <1478641036.79.0.607314945909.issue28642@psf.upfronthosting.co.za> Marc Garcia added the comment: Sorry, my fault. It looks like having quotes in the file was the problem. As mentioned, adding the quoting parameter fixes the problem. I'd assume that if quotes are not paired, csv should raise an exception. And I don't think that all the different chunks of the file I tested, had always an even number of quotes. Also, I don't understand why using the default delimiter worked well, and with tab delimiter the problem happened. I'll take a look in more detail, but I'm closing this issue. Thank you all a lot for the help! ---------- resolution: -> not a bug status: open -> closed title: csv reader loosing rows with big files and tab delimiter -> csv reader losing rows with big files and tab delimiter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 16:40:08 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Nov 2016 21:40:08 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478641208.55.0.326238722365.issue28637@psf.upfronthosting.co.za> STINNER Victor added the comment: Guido: "So what does that benchmark measure? For me, python 3.6 startup is 44 ms and python 2.7 startup is 78 ms (real time; user time is proportionally less)." It measures something like "time python -c pass". The performance module creates a virtual environment to run benchmarks to get reproductible timings. If you benchmark the Python startup time using your system Python, the timing depends on the number of installed .pth files. The code of python_startup benchmark: https://github.com/python/performance/blob/master/performance/benchmarks/bm_python_startup.py Note: I didn't write the benchmark, it comes from the old benchmark suite. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 16:44:44 2016 From: report at bugs.python.org (Neil Schemenauer) Date: Tue, 08 Nov 2016 21:44:44 +0000 Subject: [issue28643] Broken makefile depends for profile-opt target In-Reply-To: <1478634995.26.0.389156722395.issue28643@psf.upfronthosting.co.za> Message-ID: <1478641484.94.0.72950171781.issue28643@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Okay, my initial idea was wrong (I blame years of not having to look at Makefiles). I think the attached patch works. It uses a "stamp" file to record the fact that the profiled build is complete. The fix is sub-optimal because changing some source code and re-running "make" will not rebuild as needed. That would require proper dependencies in the Makefile, rather than treating "make" as an imperative scripting language (e.g. recursively calling make to sequence things). Given that the profile optimised build is unlikely to be used during development, I guess that's not so bad. ---------- Added file: http://bugs.python.org/file45398/profile-opt-stamp.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 16:54:46 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Nov 2016 21:54:46 +0000 Subject: [issue26182] Deprecation warnings for the future async and await keywords in Python 3.6 In-Reply-To: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za> Message-ID: <20161108215443.2099.53841.D7B27D94@psf.io> Roundup Robot added the comment: New changeset 7a996e826f83 by Yury Selivanov in branch '3.6': Issue #26182: Fix ia refleak in code that raises DeprecationWarning. https://hg.python.org/cpython/rev/7a996e826f83 New changeset 7b0e79e7f567 by Yury Selivanov in branch 'default': Merge 3.6 (issue #26182) https://hg.python.org/cpython/rev/7b0e79e7f567 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 17:17:14 2016 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 08 Nov 2016 22:17:14 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1478643434.38.0.266750331876.issue28638@psf.upfronthosting.co.za> Eric V. Smith added the comment: This file is derived from my namedlist project on PyPI. I've stripped out the namedlist stuff, and just left namedtuple. I've also removed the Python 2 support, and I've removed support for default parameters. After that surgery, I have not tested it very well. Those are my excuses for why the code is more complex that it would be if I were writing it from scratch. Anyway, instead of using eval() of a string to create the new() function, I use ast manipulations to generate a function that does all of the correct type checking. It calls eval() too, of course, but with a code object. I originally wrote this as an exercise in learning how to generate AST's. I can't say it's the best way to solve this problem, and I haven't benchmarked it ever. So just consider it as a proof of concept, or ignore it if you're not interested. ---------- nosy: +eric.smith Added file: http://bugs.python.org/file45399/namedtuple1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 17:20:50 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 08 Nov 2016 22:20:50 +0000 Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za> Message-ID: <1478643650.41.0.535207244526.issue26801@psf.upfronthosting.co.za> Yury Selivanov added the comment: This patch introduced multiple refleaks in test_asyncgen. ---------- nosy: +yselivanov resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 17:20:59 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 08 Nov 2016 22:20:59 +0000 Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za> Message-ID: <1478643659.29.0.0524421673924.issue26801@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +larry, ned.deily priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 17:22:45 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 08 Nov 2016 22:22:45 +0000 Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za> Message-ID: <1478643765.55.0.33655921339.issue26801@psf.upfronthosting.co.za> Yury Selivanov added the comment: Ah, never mind, the commit message has a wrong issue number: Issue #26801: Added C implementation of asyncio.Future. Closing this one, will re-open #26081. ---------- priority: release blocker -> normal resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 17:24:00 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 08 Nov 2016 22:24:00 +0000 Subject: [issue26081] Implement asyncio Future in C to improve performance In-Reply-To: <1452533022.97.0.443242974791.issue26081@psf.upfronthosting.co.za> Message-ID: <1478643840.91.0.623611992716.issue26081@psf.upfronthosting.co.za> Yury Selivanov added the comment: This patch introduced multiple refleaks in test_asyncgen. ---------- priority: normal -> release blocker resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 18:12:38 2016 From: report at bugs.python.org (Rasmus Villemoes) Date: Tue, 08 Nov 2016 23:12:38 +0000 Subject: [issue28607] C implementation of parts of copy.deepcopy In-Reply-To: <1478214696.15.0.845599612142.issue28607@psf.upfronthosting.co.za> Message-ID: <1478646758.49.0.84649507162.issue28607@psf.upfronthosting.co.za> Rasmus Villemoes added the comment: New version, addressing (hopefully) all review comments. ---------- Added file: http://bugs.python.org/file45400/deepcopy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 18:22:44 2016 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 08 Nov 2016 23:22:44 +0000 Subject: [issue28555] provid also sha-1 and sha-256 also on download links In-Reply-To: <1478632652.87.0.0585710912588.issue28555@psf.upfronthosting.co.za> Message-ID: <1478647361.2090545.781745657.1C0F5FAA@webmail.messagingengine.com> Benjamin Peterson added the comment: If python.org can be MITMed, it doesn't matter how secure the hash is. On Tue, Nov 8, 2016, at 11:17, Big Stone wrote: > > Big Stone added the comment: > > I fear GPG is not easy stuff for Windows users. > > I fear a bunch of people on this network can circomvent DNS and make > python.org points to the wrong place. > > sha-1 instead of md5 would have been an improvement. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 18:37:29 2016 From: report at bugs.python.org (Ethan Furman) Date: Tue, 08 Nov 2016 23:37:29 +0000 Subject: [issue28637] Python startup performance regression due to enum in re In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478648249.71.0.812390015026.issue28637@psf.upfronthosting.co.za> Ethan Furman added the comment: Does this mean we can put enum back in re? ---------- title: Python startup performance regression -> Python startup performance regression due to enum in re _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 19:05:50 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Nov 2016 00:05:50 +0000 Subject: [issue26081] Implement asyncio Future in C to improve performance In-Reply-To: <1452533022.97.0.443242974791.issue26081@psf.upfronthosting.co.za> Message-ID: <20161109000546.6084.53009.C99B1562@psf.io> Roundup Robot added the comment: New changeset 345904bd0456 by Yury Selivanov in branch '3.6': Issue #26081: Fix refleak in _asyncio.Future.__iter__().throw. https://hg.python.org/cpython/rev/345904bd0456 New changeset b977775aa07d by Yury Selivanov in branch 'default': Merge 3.6 (issue #26081) https://hg.python.org/cpython/rev/b977775aa07d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 19:06:18 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 00:06:18 +0000 Subject: [issue26081] Implement asyncio Future in C to improve performance In-Reply-To: <1452533022.97.0.443242974791.issue26081@psf.upfronthosting.co.za> Message-ID: <1478649978.13.0.64003682707.issue26081@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- priority: release blocker -> normal resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 19:38:11 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 09 Nov 2016 00:38:11 +0000 Subject: [issue28644] Document recen changes in typing.py Message-ID: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za> New submission from Ivan Levkivskyi: Here is the patch with recent additions/changes in typing.py Summary: Tuple and Callable are now classes, generic type aliases, added Coroutine, extended docs for get_type_hints. ---------- assignee: docs at python components: Documentation files: recent-typing-docs.diff keywords: patch messages: 280364 nosy: docs at python, gvanrossum, levkivskyi priority: normal severity: normal status: open title: Document recen changes in typing.py type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45401/recent-typing-docs.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 19:46:48 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Nov 2016 00:46:48 +0000 Subject: [issue28003] PEP 525 asynchronous generators implementation In-Reply-To: <1473269374.39.0.509274285807.issue28003@psf.upfronthosting.co.za> Message-ID: <20161109004645.111390.46604.6B88EDF0@psf.io> Roundup Robot added the comment: New changeset 9f32ef6b210b by Yury Selivanov in branch '3.6': Issue #28003: Make WrappedVal, ASend and AThrow GC types https://hg.python.org/cpython/rev/9f32ef6b210b New changeset 6f51b495656c by Yury Selivanov in branch 'default': Merge 3.6 (issue #28003) https://hg.python.org/cpython/rev/6f51b495656c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 19:47:23 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 09 Nov 2016 00:47:23 +0000 Subject: [issue28644] Document recen changes in typing.py In-Reply-To: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za> Message-ID: <1478652443.19.0.566296935855.issue28644@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Sorry, here is the patch with corrected formatting and base classes for Coroutine. ---------- Added file: http://bugs.python.org/file45402/recent-typing-docs-v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 20:00:14 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Nov 2016 01:00:14 +0000 Subject: [issue28639] inspect.isawaitable(native_coro) returns int In-Reply-To: <1478582416.14.0.848083143848.issue28639@psf.upfronthosting.co.za> Message-ID: <20161109010011.85600.86257.E575A0C8@psf.io> Roundup Robot added the comment: New changeset bb6ad816a43c by Yury Selivanov in branch '3.5': Issue #28639: Fix inspect.isawaitable to always return bool https://hg.python.org/cpython/rev/bb6ad816a43c New changeset 6540adb8722a by Yury Selivanov in branch '3.6': Merge 3.5 (issue #28639) https://hg.python.org/cpython/rev/6540adb8722a New changeset 8e3d359cc73b by Yury Selivanov in branch 'default': Merge 3.6 (issue #28639) https://hg.python.org/cpython/rev/8e3d359cc73b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 20:00:44 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 01:00:44 +0000 Subject: [issue28639] inspect.isawaitable(native_coro) returns int In-Reply-To: <1478582416.14.0.848083143848.issue28639@psf.upfronthosting.co.za> Message-ID: <1478653244.0.0.518356444767.issue28639@psf.upfronthosting.co.za> Yury Selivanov added the comment: Merged! Thank you, Justin. ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 20:09:18 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 01:09:18 +0000 Subject: [issue28645] Drop __aiter__ compatibility layer from 3.7 Message-ID: <1478653758.13.0.607802284068.issue28645@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- assignee: yselivanov components: Interpreter Core nosy: haypo, serhiy.storchaka, yselivanov priority: normal severity: normal stage: patch review status: open title: Drop __aiter__ compatibility layer from 3.7 type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 20:11:27 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 01:11:27 +0000 Subject: [issue28645] Drop __aiter__ compatibility layer from 3.7 Message-ID: <1478653887.8.0.479967053131.issue28645@psf.upfronthosting.co.za> New submission from Yury Selivanov: As discussed in issue #27243, we want to drop __aiter__ compatibility layer in Python 3.7. Please take a look at the attached patch (I'll inc importlib's magic before committing). ---------- keywords: +patch Added file: http://bugs.python.org/file45403/aiter.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 20:24:59 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Nov 2016 01:24:59 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478641208.55.0.326238722365.issue28637@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: OK. I believe we also found that the extra slowdown is only in a virtualenv so that may explain that I saw something different. ---------- title: Python startup performance regression due to enum in re -> Python startup performance regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 21:28:40 2016 From: report at bugs.python.org (Michael Rolle) Date: Wed, 09 Nov 2016 02:28:40 +0000 Subject: [issue20629] Python ctypes BigEndianStructure bitfield assignment misbehavior in Linux In-Reply-To: <1392414202.99.0.0705946156557.issue20629@psf.upfronthosting.co.za> Message-ID: <1478658520.43.0.930332573529.issue20629@psf.upfronthosting.co.za> Michael Rolle added the comment: Similar problem with 2.7.8 with cygwin. My example is: Python 2.7.8 (default, Jul 25 2014, 14:04:36) [GCC 4.8.3] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import * >>> class C (BigEndianStructure): _fields_ = (('rva', c_uint, 31), ('fl', c_uint, 1)) ... >>> buffer(x)[:]; x.rva; x.fl '\x00\x00\x00\x00' 0L 0L >>> x.rva = 256 >>> buffer(x)[:]; x.rva; x.fl '\x00\x00\x02\x00' 256L 0L >>> x.rva = 256 >>> buffer(x)[:]; x.rva; x.fl '\x00\x00\x02\x00' 256L 0L >>> x.fl = 1 >>> buffer(x)[:]; x.rva; x.fl '\x00\x02\x00\x01' 65536L 1L >>> x.fl = 1 >>> buffer(x)[:]; x.rva; x.fl '\x01\x00\x02\x01' 8388864L 1L >>> x.fl = 1 >>> buffer(x)[:]; x.rva; x.fl '\x01\x02\x00\x01' 8454144L 1L >>> x.fl = 1 >>> buffer(x)[:]; x.rva; x.fl '\x01\x00\x02\x01' 8388864L 1L >>> x.rva = 256 >>> buffer(x)[:]; x.rva; x.fl '\x00\x00\x02\x01' 256L 1L >>> x.rva = 256 >>> buffer(x)[:]; x.rva; x.fl '\x00\x00\x02\x00' 256L 0L >>> x.rva = 256 >>> buffer(x)[:]; x.rva; x.fl '\x00\x00\x02\x00' 256L 0L I'm disappointed that this bug hasn't been fixed after two years! I understand that ctypes might not be portable across different platforms. However, the above behavior is clearly wrong. BTW, I also have Python 2.7.8 (default, Jun 30 2014, 16:08:48) [MSC v.1500 64 bit (AMD64)] on win32, and this version works fine. ---------- nosy: +mrolle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 21:40:25 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 09 Nov 2016 02:40:25 +0000 Subject: [issue27854] Installed 2.7: IDLE Help disabled because help.html is missing In-Reply-To: <1472078066.3.0.116550230826.issue27854@psf.upfronthosting.co.za> Message-ID: <1478659225.69.0.0278044312942.issue27854@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thanks Irv: Windows specific it appears to be. Benjamin, Martin, Steve: the 2.7 Windows .msi installer should be fixed to include idlelib/help.html before its next release. Does it use an explicit list of file glob patterns to include? ---------- nosy: +loewis priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 22:19:19 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 09 Nov 2016 03:19:19 +0000 Subject: [issue28644] Document recen changes in typing.py In-Reply-To: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za> Message-ID: <1478661559.25.0.460610773182.issue28644@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Hi Ivan, I noticed you used two space indentation in your docs patch. Can you use 3 spaces instead? More guidelines here: https://docs.python.org/devguide/documenting.html?#use-of-whitespace Thanks :) ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 22:43:19 2016 From: report at bugs.python.org (Michael Rolle) Date: Wed, 09 Nov 2016 03:43:19 +0000 Subject: [issue20629] Python ctypes BigEndianStructure bitfield assignment misbehavior in Linux In-Reply-To: <1392414202.99.0.0705946156557.issue20629@psf.upfronthosting.co.za> Message-ID: <1478662999.0.0.596292252422.issue20629@psf.upfronthosting.co.za> Michael Rolle added the comment: As a separate issue, I'd like to find an appropriate package, other than ctypes, for interpreting data bytes in a consistently defined manner, independent of the platform I'm running on. The struct package is perfect where there are no bitfields involved, i.e., where each item occupies whole bytes. But it doesn't support packing/unpacking bitfields. Actually, ctypes could fit the bill if you specified that bitfields be allocated from MSB to LSB for BigEndianStructure, and from LSB to MSB for LittleEndianStructure. This way, for instance, it wouldn't matter if a sequence of 4-bit fields were based on c_ubyte or c_ushort, etc. Each pair of fields would be allocated to the next consecutive byte. And if the platform native compiler for some strange reason doesn't follow either of these rules, then Structure would follow the platform compiler. differs from both Big and Little ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 23:04:52 2016 From: report at bugs.python.org (Michael Rolle) Date: Wed, 09 Nov 2016 04:04:52 +0000 Subject: [issue28646] Using a read-only buffer. Message-ID: <1478664292.05.0.145705220958.issue28646@psf.upfronthosting.co.za> New submission from Michael Rolle: Suggest that the _CData.from_buffer (source) method allow a read-only source as an argument, in which case any assignments to the object would raise some type of exception. If the source is shared with some writable object, then changes to said object would be reflected in the _CData object. If this behavior is not what you want, then you could just make a new method called, say, from_buffer_shared (source). ---------- components: ctypes messages: 280375 nosy: mrolle priority: normal severity: normal status: open title: Using a read-only buffer. type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 8 23:52:35 2016 From: report at bugs.python.org (SilentGhost) Date: Wed, 09 Nov 2016 04:52:35 +0000 Subject: [issue28642] csv reader losing rows with big files and tab delimiter In-Reply-To: <1478625681.85.0.319156602721.issue28642@psf.upfronthosting.co.za> Message-ID: <1478667155.64.0.312205297244.issue28642@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 02:12:38 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Nov 2016 07:12:38 +0000 Subject: [issue28645] Drop __aiter__ compatibility layer from 3.7 In-Reply-To: <1478653887.8.0.479967053131.issue28645@psf.upfronthosting.co.za> Message-ID: <1478675558.61.0.96993960588.issue28645@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > I'll inc importlib's magic before committing. Please left good gap for possible bugfixes between current number and 3.7 number. Set it to 3390. I'm not experienced with async protocols, but at first glance the patch looks technically correct. Please update the documentation. I have the only question about tests. Some tests test the behavior with "async __aiter__". With the patch them test the behavior with just "__aiter__". Shouldn't these tests be duplicated in 3.5-3.6 for __aiter__ without async? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 02:17:33 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 09 Nov 2016 07:17:33 +0000 Subject: [issue20629] Python ctypes BigEndianStructure bitfield assignment misbehavior in Linux In-Reply-To: <1392414202.99.0.0705946156557.issue20629@psf.upfronthosting.co.za> Message-ID: <1478675853.83.0.301313813634.issue20629@psf.upfronthosting.co.za> Xiang Zhang added the comment: The bug is fixed in #23319. More recent Py2.7 and Py3.4+ should get rid of it. ---------- nosy: +xiang.zhang resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 02:30:29 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 09 Nov 2016 07:30:29 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478676629.76.0.270371536837.issue28637@psf.upfronthosting.co.za> Gregory P. Smith added the comment: re: Ethan's question - I think the enum use should be restored in re. I realize issue28082 (yay palindrome number) is not an urgent change but we created IntEnum for the purpose of more identifiable integer constants. So a microbenchmark of "import re" slows down. so what? I don't find this to be a big deal. Other standard library modules also use enum and I expect more to do so in the future. In realistic size programs other things use enum as well so there isn't a hit. PS thanks for the site.py improvements! ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 03:48:31 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 09 Nov 2016 08:48:31 +0000 Subject: [issue26934] android: test_faulthandler fails In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za> Message-ID: <1478681311.22.0.774884110676.issue26934@psf.upfronthosting.co.za> Xavier de Gaye added the comment: New patch. ---------- Added file: http://bugs.python.org/file45404/buggy_raise_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 03:49:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Nov 2016 08:49:35 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478681375.18.0.155777473728.issue28637@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: On my computer: Importing empty module: 160 us Creating empty class: 30 us Creating empty function: 0.16 us Creating empty Enum/IntEnum: 125/150 us Creating Enum/IntEnum member: 25/27 us Creating empty namedtuple: 600 us Creating namedtuple member: 50 us Importing the itertools module: 40 us Importing the io module: 900 us Importing the os module: 1600 us Importing the functools module: 2100 us Importing the re module (with all sre submodules): 3300 us Python startup time: 43000 us ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 04:00:43 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 09 Nov 2016 09:00:43 +0000 Subject: [issue28644] Document recen changes in typing.py In-Reply-To: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za> Message-ID: <1478682043.69.0.43956626667.issue28644@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Thanks Mariatta, here is a new version of patch with indentation fixed. ---------- Added file: http://bugs.python.org/file45405/recent-typing-docs-v3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 04:01:52 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Nov 2016 09:01:52 +0000 Subject: [issue26934] android: test_faulthandler fails In-Reply-To: <1478681311.22.0.774884110676.issue26934@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: buggy_raise_4.patch LGTM. Thanks for your patience :-) Maybe later you can also modify existing tests to use the new @requires_android_level? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 04:05:18 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Nov 2016 09:05:18 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: Message-ID: STINNER Victor added the comment: About the re module, there is still a regression on the performance of the import time: see my msg280271. We may also revert the changeset 88110cfbf4dc (issue #28193) if we want to keep "import re" as fast as Python 3.5. The question is if we consider that the re module is part of the Python core modules which must be blasing fast to import. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 04:11:41 2016 From: report at bugs.python.org (Marc Garcia) Date: Wed, 09 Nov 2016 09:11:41 +0000 Subject: [issue28642] csv reader losing rows with big files and tab delimiter In-Reply-To: <1478625681.85.0.319156602721.issue28642@psf.upfronthosting.co.za> Message-ID: <1478682701.16.0.0888531163473.issue28642@psf.upfronthosting.co.za> Marc Garcia added the comment: I could research a bit more on the problem. This is a minimal code that reproduces what happened: from io import StringIO import csv csv_file = StringIO('''1\t"A 2\tB''') reader = csv.reader(csv_file, delimiter='\t') for i, row in enumerate(reader): pass print(reader.line_num) # 2 print(i + 1) # 1 The reason to return the right number of rows with the default delimiter, is because the quote needs to be immediately after the delimiter to be considered the opening of a quoted text. If the file contains an opening quote, and the EOF is reached without its closing quote, the reader considers all the text until EOF to be that field. This would work as expected in a line like: 1,"well quoted text","this one has a missing quote But it'd fail silently with unexpected results in all other cases. I'd expect csv to raise an exception, more than the current behavior. Do you agree? Should I create another issue to address this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 04:28:22 2016 From: report at bugs.python.org (SilentGhost) Date: Wed, 09 Nov 2016 09:28:22 +0000 Subject: [issue28642] csv reader losing rows with big files and tab delimiter In-Reply-To: <1478625681.85.0.319156602721.issue28642@psf.upfronthosting.co.za> Message-ID: <1478683702.81.0.694100183395.issue28642@psf.upfronthosting.co.za> SilentGhost added the comment: No, the module works exactly as advertised. The default value of quoting parameter might not be suitable for this file, but it suits majority of files out there. The fields in csv can contain line feed, so the line in your example does not have a "missing" quote, it's that you're using wrong (the default) quoting parameter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 04:38:23 2016 From: report at bugs.python.org (Marc Garcia) Date: Wed, 09 Nov 2016 09:38:23 +0000 Subject: [issue28642] csv reader losing rows with big files and tab delimiter In-Reply-To: <1478625681.85.0.319156602721.issue28642@psf.upfronthosting.co.za> Message-ID: <1478684303.95.0.0892178941368.issue28642@psf.upfronthosting.co.za> Marc Garcia added the comment: I agree that for my case, I was using the wrong quoting parameter, and if I specify that my file has no quotes, it works as expected. But I still think that in a different case, when a file do have quotes, but they are not paired, it'd be better to raise an exception, than to ignore the error and assume there is just a missing quote at the end. >From the Zen of Python: "Errors should never pass silently", and I think it's clear that there is an error in the file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 04:49:15 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 09 Nov 2016 09:49:15 +0000 Subject: [issue26934] android: test_faulthandler fails In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za> Message-ID: <1478684955.21.0.18428909721.issue26934@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > Thanks for your patience :-) No problem, your suggestions and code reviews are always very much welcome :) I will push this patch with the other Android patches after 3.6 is released. The patch at issue 26936 will also use @requires_android_level. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 04:52:15 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 09 Nov 2016 09:52:15 +0000 Subject: [issue26929] android: test_strptime fails In-Reply-To: <1462284711.76.0.324696843297.issue26929@psf.upfronthosting.co.za> Message-ID: <1478685135.49.0.363298079848.issue26929@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Patch attached. ---------- assignee: -> xdegaye components: -Cross-Build keywords: +patch stage: -> patch review versions: +Python 3.7 Added file: http://bugs.python.org/file45406/exclude_ymd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 05:05:10 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 09 Nov 2016 10:05:10 +0000 Subject: [issue26929] android: test_strptime fails In-Reply-To: <1462284711.76.0.324696843297.issue26929@psf.upfronthosting.co.za> Message-ID: <1478685910.09.0.675901024042.issue26929@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Entered new issue https://code.google.com/p/android/issues/detail?id=227388 on the AOSP issue tracker. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 05:26:05 2016 From: report at bugs.python.org (Armin Rigo) Date: Wed, 09 Nov 2016 10:26:05 +0000 Subject: [issue28647] python --help: -u is misdocumented as binary mode Message-ID: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za> New submission from Armin Rigo: ``python3.5 --help`` gives this information: -u : unbuffered binary stdout and stderr, stdin always buffered However, stdout and stderr are actually always opened in text mode, and print() always expects a string and never a bytes object. This usage of "binary" in the --help is in contradiction with the usage of "binary" in the description of files (e.g. ``help(open)``). ---------- components: Interpreter Core messages: 280390 nosy: arigo priority: normal severity: normal status: open title: python --help: -u is misdocumented as binary mode versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 05:30:40 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Nov 2016 10:30:40 +0000 Subject: [issue28647] python --help: -u is misdocumented as binary mode In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za> Message-ID: <1478687440.46.0.0380584473587.issue28647@psf.upfronthosting.co.za> STINNER Victor added the comment: Right. Moreover, "unbuffered" is wrong. It's line buffered: sys.stdout.buffer is directly a io.FileIO object, but TextIOWrapper only calls buffer.write() when the message contains a newline character. It's not (currently) possible to have a fully unbuffered stdout. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 06:04:55 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 09 Nov 2016 11:04:55 +0000 Subject: [issue28647] python --help: -u is misdocumented as binary mode In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za> Message-ID: <1478689495.34.0.44796898647.issue28647@psf.upfronthosting.co.za> Eryk Sun added the comment: > It's not (currently) possible to have a fully unbuffered stdout. Why doesn't create_stdio also pass `write_through = Py_True` when Py_UnbufferedStdioFlag is set? This would immediately pass writes through to the FileIO object, even without containing a newline (i.e. it sets text_needflush in _io_TextIOWrapper_write_impl). ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 07:47:02 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Nov 2016 12:47:02 +0000 Subject: [issue28647] python --help: -u is misdocumented as binary mode In-Reply-To: <1478689495.34.0.44796898647.issue28647@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I don't recall, I would have to search in old issues for the rationale. But the explanation is probably performance, reduce the number of syscalls. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 08:18:28 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Nov 2016 13:18:28 +0000 Subject: [issue28647] python --help: -u is misdocumented as binary mode In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za> Message-ID: <1478697508.34.0.760825331991.issue28647@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The write_through argument was added only in 3.3. I think this is a good idea to pass `write_through = Py_True` when Py_UnbufferedStdioFlag is set. Using -u means that performance is not important (that is why this is not default behavior). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 08:47:20 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 13:47:20 +0000 Subject: [issue27942] Default value identity regression In-Reply-To: <1472834737.57.0.822205168917.issue27942@psf.upfronthosting.co.za> Message-ID: <1478699240.35.0.814535305828.issue27942@psf.upfronthosting.co.za> Yury Selivanov added the comment: The patch is causing refleaks: test_ast leaked [98, 98, 98] references, sum=294 test_code leaked [2, 2, 2] references, sum=6 Please review the attached patch fixing that. Please review. ---------- nosy: +benjamin.peterson, larry, ned.deily, yselivanov priority: normal -> release blocker resolution: fixed -> status: closed -> open Added file: http://bugs.python.org/file45407/refleak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 09:02:15 2016 From: report at bugs.python.org (Paul G) Date: Wed, 09 Nov 2016 14:02:15 +0000 Subject: [issue28641] Describe PEP 495 features in "What's New in Python 3.6" document In-Reply-To: <1478625046.84.0.866752786385.issue28641@psf.upfronthosting.co.za> Message-ID: <1478700135.48.0.763754122907.issue28641@psf.upfronthosting.co.za> Paul G added the comment: I've never written a "What's New" before, but here are the main things I took away from implementing a PEP 495-compliant tzinfo class: - The `fold` attribute is the SECOND occurrence of the time, not the first occurrence of the time. In my first pass solution of this, I had this inverted, so I would say it's worth making it very clear which is which, maybe with an example (I'm using full zone names here like those returned by `dateutil.tz.tzwin`): >>> datetime(2011, 11, 6, 1, 30, fold=0, tzinfo=US_EASTERN).tzname() 'Eastern Daylight Time' >>> datetime(2011, 11, 6, 1, 30, fold=1, tzinfo=US_EASTERN).tzname() 'Eastern Standard Time' - Because the default for "fold" is 0, the default for "unspecified" fold has changed from being on the STD side to being on the DST side: >>> datetime(2011, 11, 6, 1, 30, tzinfo=US_EASTERN_NO495).tzname() 'EST' >>> datetime(2011, 11, 6, 1, 30, tzinfo=US_EASTERN_PEP495).tzname() 'EDT' - It is now best practices to implement your own `fromutc()` (I got the impression that in the past it was encouraged that you generally just wrote a `utcoffset()` and `dst()` function. - Comparisons of datetimes have changed such that inter-zone comparisons representing the same wall time and offset will now fail during ambiguous times (depending on the resolution of #28601, the exact semantics of what is an inter-zone comparison should be clarified): >>> dt1 = datetime(2016, 11, 6, 1, 30, fold=1, tzinfo=US_EASTERN) >>> dt2 = datetime(2016, 11, 6, 1, 30, fold=0, tzinfo=US_CENTRAL) >>> dt1 == dt2 False I think the remainder of my insights would have to do with backwards-compatibility and I'm not sure how much relevance they have to "What's New". With regards to the documentation, here are my notes: - One thing that should be made more clear is that arithmetic operations wipe out the `fold` attribute - this behavior and the reasoning behind it should probably be clear in the section on datetime operations, because I think people will be confused by this: >>> from datetime import datetime, timedelta >>> from dateutil import tz >>> dt = datetime(2011, 11, 6, 1, 30, fold=1, tz=gettz('US/Eastern') >>> dt.tzname() 'EST' >>> (dt + timedelta(minutes=1)).tzname() 'EDT' - Not related to the changes in 3.6, but it might also be worth clarifying that `datetime.astimezone()` with no arguments returns a datetime with a fixed offset zone, NOT the local zone (it's somewhat clear, but it could be more explicit): >>> dt.astimezone().tzname() 2011-11-06 01:30:00-5:00 >>> dt.astimezone() - timedelta(hours=5) 2011-11-05 20:30:00-05:00 >>> dt.astimezone(tz.tzlocal()) 2011-11-06 01:30:00-5:00 >>> dt.astimezone(tz.tzlocal()) - timedelta(hours=5) 2011-11-05 20:30:00-04:00 - In the section on "working with datetime objects", GMT1 and GMT2 objects don't support the `fold` attribute. That might be confusing (though there are fold-aware tzinfo objects later in the documentation). - In the section on time.tzname(), the example defines its own GMT1 time zone. It might be clearer to just define GMT1 = datetime.timezone(timedelta(hours=1), "Europe/Prague') rather than create a new fixed offset tzinfo. - The "most implementations of dst() will probably look like one of these two" section should be updated to reflect `fold`, maybe something like this: def dst(self, dt): # Code to set dston and dstoff to the time zone's DST # transition times based on the input dt.year, and expressed # in standard local time. dt_naive = dt.replace(tzinfo=None) if dston <= dt_naive < dstoff: if dt_naive < dston + timedelta(hours=1) and dt.fold: return timedelta(0) else: return timedelta(hours=1) else: return timedelta(0) - The tzinfo.fromutc(dt) documentation suggests that this method is capable of handling non-fixed offset zones. Per #28602, it seems that it should be made clear that all zones implementing `fold` support should implement their own `fromutc` method, as there is a deliberate bug in the algorithm when folds are supported. - This may be slightly confusing: "Note that the datetime instances that differ only by the value of the fold attribute are considered equal in comparisons.", because when I first read this, I assumed it meant that datetime(2011, 11, 6, 1, 30, tzinfo=US_EASTERN) == datetime(2011, 11, 6, 1, 30, fold=1, tzinfo=US_EASTERN), but in fact it either means that *unambiguous* datetimes that differ only by their `fold` attribute are equal, ambiguous datetimes with a fold-aware tzinfo attached will return a different utcoffset() and thus not compare equal. - I found this slightly confusing, under the "dateutil.tz" heading: "The standard library has timezone class for handling arbitrary fixed offsets from UTC and timezone.utc as UTC timezone instance." Since dateutil.tz does not provide a `timezone` class, I thought it was a mistake, but I think that that text should actually be *above* the "dateutil.tz" header, since it refers to the Python standard library. - On the subject of the dateutil.tz callout (thanks for that, by the way), it may be worth noting that while pytz only provides IANA zones, dateutil.tz also provides other zones, such as zones parsed from GNU TZ strings and a wrapper around the Windows time zone interface. (This latter is useful, by the way, because of a bug in Microsoft CRT that makes it so that time.localtime will not reflect changes in system time zone without a new instance of Python - see #10634. dateutil.tz.tzwinlocal() uses the native Windows interface and is not subject to this bug, though dateutil.tz.tzlocal(), as a wrapper around time, is). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 09:36:30 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 14:36:30 +0000 Subject: [issue28641] Describe PEP 495 features in "What's New in Python 3.6" document In-Reply-To: <1478625046.84.0.866752786385.issue28641@psf.upfronthosting.co.za> Message-ID: <1478702190.75.0.519576688138.issue28641@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks, Paul. I'm adding Elvis to the nosy list, he's the main editor of What's New in 3.6. ---------- nosy: +Elvis.Pranskevichus, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 09:36:48 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 14:36:48 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1478702208.28.0.064676198234.issue28635@psf.upfronthosting.co.za> Yury Selivanov added the comment: Elvis, please take a look at http://bugs.python.org/issue28641 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 09:37:18 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 14:37:18 +0000 Subject: [issue27942] Default value identity regression In-Reply-To: <1472834737.57.0.822205168917.issue27942@psf.upfronthosting.co.za> Message-ID: <1478702238.56.0.100239038362.issue27942@psf.upfronthosting.co.za> Yury Selivanov added the comment: Looks like the attached patch also fixes test_trace leaked [12, 12, 12] references, sum=36 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 09:37:18 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Nov 2016 14:37:18 +0000 Subject: [issue27942] Default value identity regression In-Reply-To: <1472834737.57.0.822205168917.issue27942@psf.upfronthosting.co.za> Message-ID: <1478702238.95.0.709436387525.issue27942@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Good catch! The patch LGTM, thanks Yury. Interesting, what tests in test_ast leak? I expected that this branch is executed in rare circumstances. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 09:38:49 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 14:38:49 +0000 Subject: [issue27942] Default value identity regression In-Reply-To: <1472834737.57.0.822205168917.issue27942@psf.upfronthosting.co.za> Message-ID: <1478702329.54.0.993571102872.issue27942@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Interesting, what tests in test_ast leak? I expected that this branch is executed in rare circumstances. The test that tests it all :) test_stdlib_validates ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 09:43:46 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Nov 2016 14:43:46 +0000 Subject: [issue27942] Default value identity regression In-Reply-To: <1472834737.57.0.822205168917.issue27942@psf.upfronthosting.co.za> Message-ID: <20161109144343.28693.5421.1AE50F69@psf.io> Roundup Robot added the comment: New changeset 41613bb27f80 by Yury Selivanov in branch '2.7': Issue #27942: Fix memory leak in codeobject.c https://hg.python.org/cpython/rev/41613bb27f80 New changeset 2c6825c9ecfd by Yury Selivanov in branch '3.5': ssue #27942: Fix memory leak in codeobject.c https://hg.python.org/cpython/rev/2c6825c9ecfd New changeset b671ac7ae620 by Yury Selivanov in branch '3.6': Merge 3.5 (issue #27942) https://hg.python.org/cpython/rev/b671ac7ae620 New changeset c27269c0d619 by Yury Selivanov in branch 'default': Merge 3.6 (issue #27942) https://hg.python.org/cpython/rev/c27269c0d619 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 09:44:24 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 14:44:24 +0000 Subject: [issue27942] Default value identity regression In-Reply-To: <1472834737.57.0.822205168917.issue27942@psf.upfronthosting.co.za> Message-ID: <1478702664.71.0.952810204309.issue27942@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks for the review, Serhiy! ---------- priority: release blocker -> normal resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 09:53:59 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Nov 2016 14:53:59 +0000 Subject: [issue27942] Default value identity regression In-Reply-To: <1472834737.57.0.822205168917.issue27942@psf.upfronthosting.co.za> Message-ID: <1478703239.5.0.338519770336.issue27942@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > The test that tests it all :) test_stdlib_validates :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 09:58:38 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Nov 2016 14:58:38 +0000 Subject: [issue28647] python --help: -u is misdocumented as binary mode In-Reply-To: <1478697508.34.0.760825331991.issue28647@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Would it make sense to have two modes: line buferred and unbuffered, as the C function setvbuf() for stdout? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 10:42:06 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 09 Nov 2016 15:42:06 +0000 Subject: [issue28648] False assert in _Py_DecodeUTF8_surrogateescape Message-ID: <1478706126.26.0.281529783684.issue28648@psf.upfronthosting.co.za> New submission from Xiang Zhang: The assert statement `assert(Py_UNICODE_IS_SURROGATE(ch));` in _Py_DecodeUTF8_surrogateescape is wrong. Code points > 0xffff could reach it and fail. ---------- files: false_assert.patch keywords: patch messages: 280406 nosy: serhiy.storchaka, xiang.zhang priority: normal severity: normal stage: patch review status: open title: False assert in _Py_DecodeUTF8_surrogateescape type: crash versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45408/false_assert.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 11:00:08 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 16:00:08 +0000 Subject: [issue28649] refleak in typing.py Message-ID: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> New submission from Yury Selivanov: Looks like we have a refleak somewhere in the system that typing.py is exposing. The following code exposes the refleak: def test_refleak(self): T = typing.TypeVar('T') class C(typing.Generic[T], typing.Mapping[int, str]): ... The change that first triggered the leak is 8f0df4db2b06. I'm not an expert in typing.py, but I suspect that the real bug must be somewhere in CPython core. Guido, do you have any idea how 8f0df4db2b06 could trigger this? ---------- components: Library (Lib) messages: 280407 nosy: gvanrossum, ned.deily, serhiy.storchaka, yselivanov priority: release blocker severity: normal stage: needs patch status: open title: refleak in typing.py type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 11:04:09 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 09 Nov 2016 16:04:09 +0000 Subject: [issue27854] Installed 2.7: IDLE Help disabled because help.html is missing In-Reply-To: <1472078066.3.0.116550230826.issue27854@psf.upfronthosting.co.za> Message-ID: <1478707449.61.0.400088418323.issue27854@psf.upfronthosting.co.za> Steve Dower added the comment: Tools/msi/msi.py has a whole lot of code to explicitly include certain files. Probably just needs a line (or a glob) added into the idlelib section ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 11:04:51 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Nov 2016 16:04:51 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: Message-ID: Guido van Rossum added the comment: Honestly now the basic startup time is under control I am fine with restoring the re enum. We can optimize that later. --Guido (mobile) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 11:05:49 2016 From: report at bugs.python.org (pyfm) Date: Wed, 09 Nov 2016 16:05:49 +0000 Subject: [issue28650] concurrent.futures.ThreadPoolExecutor: tasks in queue not marked as done Message-ID: <1478707549.73.0.316930637654.issue28650@psf.upfronthosting.co.za> New submission from pyfm: Hi, I just realized that the ThreadPoolExecutor's workers do not call task_done() on the work_queue from which they took their task. Or is there a reason for not calling task_done that I am missing? Calling task_done decrements the queue's unfinished_tasks counter which could be used to improve the reuse of idle threads (see bquinlan's comment, Lib/concurrent/futures/thread.py:l124). I am thinking of something like if self._work_queue.unfinished_tasks > len(self._threads) and len(self._threads) < self._max_workers: One could still construct cases in which threads are created unnecessarily but it should improve the situation in most cases. (proposed patch is based on Python-3.6.0b3) ---------- files: thread.py.patch keywords: patch messages: 280410 nosy: pyfm priority: normal severity: normal status: open title: concurrent.futures.ThreadPoolExecutor: tasks in queue not marked as done type: behavior versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file45409/thread.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 11:08:05 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Nov 2016 16:08:05 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478707685.36.0.0338235135712.issue28649@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could it be related to leaks in objects with empty __slots__? See issue24379 for details. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 11:10:49 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 16:10:49 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478707849.04.0.717115811538.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Could it be related to leaks in objects with empty __slots__? See issue24379 for details. Not sure... Do we have a test/patch for objects-with-empty-slots bug? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 11:15:05 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Nov 2016 16:15:05 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478708105.83.0.104434187842.issue28649@psf.upfronthosting.co.za> Guido van Rossum added the comment: Ivan, this was an early typing.py update (merged into CPython on Sept. 27). But the refleak is still with us. Do you have any intuition on what could be going on here? My own intuition here is lacking, other than thinking there's a lot of metaclass magic going on in this code... ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 11:21:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Nov 2016 16:21:20 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478708480.49.0.163446498186.issue28649@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: >>> import gc >>> gc.collect() 23 >>> gc.collect() 0 >>> class A: ... __slots__ = () ... >>> del A >>> gc.collect() 2 ^ leak ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 11:24:10 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Nov 2016 16:24:10 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478708650.2.0.578262083696.issue28649@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also https://mail.python.org/pipermail/python-dev/2015-October/141993.html. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 12:00:52 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 09 Nov 2016 17:00:52 +0000 Subject: [issue28643] Broken makefile depends for profile-opt target In-Reply-To: <1478634995.26.0.389156722395.issue28643@psf.upfronthosting.co.za> Message-ID: <1478710852.45.0.80058009606.issue28643@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon, gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 12:01:00 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 09 Nov 2016 17:01:00 +0000 Subject: [issue28643] Broken makefile depends for profile-opt target In-Reply-To: <1478634995.26.0.389156722395.issue28643@psf.upfronthosting.co.za> Message-ID: <1478710860.45.0.838175129828.issue28643@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 12:03:04 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 17:03:04 +0000 Subject: [issue24329] __qualname__ and __slots__ In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za> Message-ID: <1478710984.88.0.770903157856.issue24329@psf.upfronthosting.co.za> Yury Selivanov added the comment: Serhiy, maybe you know how to fix this? ---------- nosy: +serhiy.storchaka versions: +Python 3.7 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 12:13:28 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Nov 2016 17:13:28 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478708650.2.0.578262083696.issue28649@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Serhiy, why is `gc.collect()` returning 2 after `del A` proof of a leak? Yes, there's a cycle, but it's being GC'ed -- isn't that fine? Without the slots the collect() call returns a larger number. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 12:19:06 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 09 Nov 2016 17:19:06 +0000 Subject: [issue24329] __qualname__ and __slots__ In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za> Message-ID: <1478711946.18.0.547093965322.issue24329@psf.upfronthosting.co.za> Xiang Zhang added the comment: Why should it work Yury? __qualname__ and __doc__(if exists) are inserted into the dict when creating a class. >>> class Foo: ... """bar""" ... __slots__ = ('__doc__',) ... Traceback (most recent call last): File "", line 1, in ValueError: '__doc__' in __slots__ conflicts with class variable ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 12:21:29 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 17:21:29 +0000 Subject: [issue24329] __qualname__ and __slots__ In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za> Message-ID: <1478712089.71.0.15248707323.issue24329@psf.upfronthosting.co.za> Yury Selivanov added the comment: Because the following works without a problem: class F: __slots__ = ('__name__', ) f = F() f.__name__ = 'aaaa' This bug with __qualname__ is why _GeneratorWrapper in types.py doesn't have __slots__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 12:50:57 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 17:50:57 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478713857.77.0.345161590569.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: Attached patch (slots_gc.patch) makes objects with empty slots tracked by GC: class A: __slots__ = () gc.is_tracked(A()) == False # before gc.is_tracked(A()) == True # with the patch This doesn't fix the refleak though. ---------- keywords: +patch Added file: http://bugs.python.org/file45410/slots_gc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 12:58:16 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 17:58:16 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478714296.89.0.108279167193.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: I removed all slots from typing.py, the refleak is still there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 13:05:23 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 18:05:23 +0000 Subject: [issue24379] Add operator.subscript as a convenience for creating slices In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1478714723.29.0.900120060016.issue24379@psf.upfronthosting.co.za> Yury Selivanov added the comment: Even more reduced test case: def test_refleak(self): T = typing.TypeVar('T') typing.Generic[T] ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 13:07:21 2016 From: report at bugs.python.org (Cathy Avery) Date: Wed, 09 Nov 2016 18:07:21 +0000 Subject: [issue27584] New addition of vSockets to the python socket module In-Reply-To: <1469115390.74.0.838831983223.issue27584@psf.upfronthosting.co.za> Message-ID: <1478714841.8.0.568792460327.issue27584@psf.upfronthosting.co.za> Cathy Avery added the comment: Please forgive the long delay in providing this update. I got a little sidetracked. Attached is the patch for Python 3.7. It includes fixes suggested in rev 1 plus VSOCK tests in test_socket.py. Thanks, Cathy ---------- versions: +Python 3.7 -Python 3.6 Added file: http://bugs.python.org/file45411/vsock_rev2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 13:11:15 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 18:11:15 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478715075.72.0.607367709655.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: Wow. In default CPython branch, with no modifications, test_typing.py simply crashes in debug mode: yury at ysmbp ~/dev/py/cpython $ ./python.exe -m test -R3:3 test_typing Run tests sequentially 0:00:00 [1/1] test_typing beginning 6 repetitions 123456 .test test_typing failed -- Traceback (most recent call last): File "/Users/yury/dev/py/cpython/Lib/test/test_typing.py", line 739, in test_generic_forvard_ref self.assertEqual(get_type_hints(foobar, globals(), locals()), {'x': List[List[T]]}) AssertionError: {'x': typing.List[typing.List[~T]]} != {'x': typing.List[typing.List[~T]]} {'x': typing.List[typing.List[~T]]} test_typing failed 1 test failed: test_typing Total duration: 1 sec Tests result: FAILURE ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 13:13:39 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 18:13:39 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478715219.27.0.158230859329.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: The problem is that functools.lru_cache is used in _tp_cache. If I remove type caching, the original "refleak" is fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 13:29:25 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 09 Nov 2016 18:29:25 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478716165.41.0.315990762361.issue28649@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Serhiy: I think you forgot to make a global instance of the type for your demonstration. You mentioned in msg253899 that the loop is: global instance -> type -> method -> module globals -> global instance The example you gave doesn't instantiate class A, and it's the instance of A that doesn't participate in GC and causes the problem, right? ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 13:31:45 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 18:31:45 +0000 Subject: [issue28651] Make objects with empty __slots__ GC types Message-ID: <1478716305.57.0.745057898966.issue28651@psf.upfronthosting.co.za> New submission from Yury Selivanov: The attached patch does the trick. I'm not sure if this should be fixed in 3.6. ---------- components: Interpreter Core files: slots_gc.patch keywords: patch messages: 280427 nosy: gvanrossum, serhiy.storchaka, yselivanov priority: normal severity: normal status: open title: Make objects with empty __slots__ GC types versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45412/slots_gc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 13:33:25 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 18:33:25 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478716405.73.0.619066388646.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: Josh, Serhiy, I've created an issue for tracking empty slots types: #28651. This issue is about typing.py using functools.lru_cache for internal cache That is what causing the refleaks, and inability of test_typing.py to be run in refleak hunting mode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 13:35:54 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 09 Nov 2016 18:35:54 +0000 Subject: [issue19717] resolve() fails when the path doesn't exist In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za> Message-ID: <1478716554.44.0.224264264985.issue19717@psf.upfronthosting.co.za> Steve Dower added the comment: Anyone have any major concerns with add_non_strict_resolve_pathlib_v4.patch? I'd be quite happy without adding the extra parameter to Path.resolve(), but I'm not strongly offended. >From Guido's email we should default to strict=False (i.e. don't throw if the file doesn't exist) rather than True. ---------- versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 13:37:56 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Nov 2016 18:37:56 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478713857.77.0.345161590569.issue28649@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I could use a hint on a complete program that establishes whether there is or is not a refleak. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 13:48:07 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Nov 2016 18:48:07 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: Message-ID: Guido van Rossum added the comment: Good sleuthing! So the bug is in _lru_cache? On Wed, Nov 9, 2016 at 10:37 AM, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > I could use a hint on a complete program that establishes whether there is > or is not a refleak. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 13:49:31 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Nov 2016 18:49:31 +0000 Subject: [issue19717] resolve() fails when the path doesn't exist In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za> Message-ID: <1478717371.89.0.00896579200911.issue19717@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'd be very happy if that landed in 3.6 with the default strict=False. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 13:51:11 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Nov 2016 18:51:11 +0000 Subject: [issue23839] Clear caches after every test In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za> Message-ID: <1478717471.06.0.207195287461.issue23839@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Synchronized with current code and added clearing typing caches. ---------- Added file: http://bugs.python.org/file45413/regrtest_clear_caches_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 13:52:57 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Nov 2016 18:52:57 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478717577.32.0.139477334282.issue28649@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Serhiy, why is `gc.collect()` returning 2 after `del A` proof of a leak? Sorry, it was bad example. I don't remember all details. > The problem is that functools.lru_cache is used in _tp_cache. If I remove type caching, the original "refleak" is fixed. Proposed patch clears caches when search for reference leaks. This decreases the number of leaks. Unpatched: test_typing leaked [3125, 3089, 2897] references, sum=9111 test_typing leaked [1189, 1179, 1103] memory blocks, sum=3471 Patched: test_typing leaked [125, 125, 125] references, sum=375 test_typing leaked [49, 51, 51] memory blocks, sum=151 See also issue23839. ---------- Added file: http://bugs.python.org/file45414/typing-clear-caches.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 13:59:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Nov 2016 18:59:23 +0000 Subject: [issue28651] Make objects with empty __slots__ GC types In-Reply-To: <1478716305.57.0.745057898966.issue28651@psf.upfronthosting.co.za> Message-ID: <1478717963.28.0.839032836709.issue28651@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Needed tests. If an example with typing causes a leak (msg280422) this should be fixed in all versions that have typing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 14:03:26 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Nov 2016 19:03:26 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478718206.68.0.773153908142.issue28649@psf.upfronthosting.co.za> Guido van Rossum added the comment: I have no objections against typing-clear-caches.patch (though we'll have to make sure to apply it to the GitHub upstream as well -- I can take care of that once you merge it to CPython). Does that patch fix the refleak completely or only partially? I have no opinion on empty slots. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 14:06:31 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 19:06:31 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478718391.32.0.326880949325.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Good sleuthing! So the bug is in _lru_cache? I don't think it's a bug of lru_cache. It stores strong references for arguments and return value of the decorated function (which btw isn't documented). I don't think it's possible to write efficient generic lru_cache that would just use weakrefs. The problem is that because _tp_cache helper uses it, the lifetime of some typing classes becomes indefinite. Which shouldn't be a problem for a typical user of typing, since most of the time it is used on the module level. We have two potential solutions to this problem: 1. Add a weak-ref type cache and refactor _tp_cache to use it; 2. Cleanup lru-cache before/adter running each typing test. [1] is the ideal solution, [2] should work good enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 14:06:52 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 09 Nov 2016 19:06:52 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478718412.63.0.667175510713.issue28649@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Yury, Guido, I think I understand why test_typing crashes in refleak hunting mode. The test relies on caching, namely type variables are compared by id, so that if cache is cleared between those two lines, then test fails. I think we should just update those test to use a usual class in forward reference. The patch is attached. (Patch fixes the crash in refleak hunting mode, but the refleak is still there) ---------- Added file: http://bugs.python.org/file45415/fix-typing-test.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 14:10:28 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 19:10:28 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478718628.66.0.549035719501.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Does that patch fix the refleak completely or only partially? I tried to empty the cache in test_typing.BaseTestCase.setUp and tearDown; this doesn't fix all refleaks. Do we have some other caches in typing.py? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 14:14:31 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Nov 2016 19:14:31 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478718871.31.0.146679329306.issue28649@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Does that patch fix the refleak completely or only partially? It fixes 96% of refleaks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 14:15:16 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 09 Nov 2016 19:15:16 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478718916.06.0.0667873942807.issue28649@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Yury, _tp_cache should be the only one (of course most generic classes have _abc_cache since GenericMeta inherits from ABCMeta) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 14:18:25 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Nov 2016 19:18:25 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478719105.79.0.794356797196.issue28649@psf.upfronthosting.co.za> Guido van Rossum added the comment: FYI I've opened https://github.com/python/typing/issues/323 to track this upstream. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 14:19:03 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Nov 2016 19:19:03 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478719143.8.0.970144813224.issue28649@psf.upfronthosting.co.za> Guido van Rossum added the comment: > It fixes 96% of refleaks. In typing.py? Or generally? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 14:20:49 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 19:20:49 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478719249.95.0.239986661208.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Yury, _tp_cache should be the only one (of course most generic classes have _abc_cache since GenericMeta inherits from ABCMeta) Then there is at least one more bug not related to lru_cache (or any kind of cache in typing). And it's not classes-with-empty-slots bug either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 14:26:00 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 19:26:00 +0000 Subject: [issue28651] Make objects with empty __slots__ GC types In-Reply-To: <1478716305.57.0.745057898966.issue28651@psf.upfronthosting.co.za> Message-ID: <1478719560.86.0.855092891624.issue28651@psf.upfronthosting.co.za> Yury Selivanov added the comment: So this patch has no impact on typing.py. Moreover, it's incomplete and fails test_gc tests, which can be fixed but not in 3.6. ---------- versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 14:28:27 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 19:28:27 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478719707.75.0.0162016854699.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: Serhiy's patch typing-clear-caches.patch looks good, we should apply it (fixing the code style a little bit). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 14:29:14 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 09 Nov 2016 19:29:14 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478719754.95.0.021462506775.issue28649@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Here is the corrected patch to avoid crash. ---------- Added file: http://bugs.python.org/file45416/fix-typing-test-v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 15:44:36 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 20:44:36 +0000 Subject: [issue28652] Make loop methods reject socket kinds they do not support. Message-ID: <1478724276.61.0.52953250975.issue28652@psf.upfronthosting.co.za> New submission from Yury Selivanov: Proxy for https://github.com/python/asyncio/pull/453 ---------- assignee: yselivanov components: asyncio messages: 280448 nosy: gvanrossum, yselivanov priority: normal severity: normal stage: resolved status: open title: Make loop methods reject socket kinds they do not support. type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 15:44:42 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 20:44:42 +0000 Subject: [issue28652] Make loop methods reject socket kinds they do not support. In-Reply-To: <1478724276.61.0.52953250975.issue28652@psf.upfronthosting.co.za> Message-ID: <1478724282.23.0.451632971132.issue28652@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 15:48:31 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Nov 2016 20:48:31 +0000 Subject: [issue28652] Make loop methods reject socket kinds they do not support. In-Reply-To: <1478724276.61.0.52953250975.issue28652@psf.upfronthosting.co.za> Message-ID: <20161109204828.85796.73092.205B99D5@psf.io> Roundup Robot added the comment: New changeset 85022978d900 by Yury Selivanov in branch '3.5': Issue #28652: Make loop methods reject socket kinds they do not support. https://hg.python.org/cpython/rev/85022978d900 New changeset 1273f1a3ddf7 by Yury Selivanov in branch '3.6': Merge 3.5 (issue #28652) https://hg.python.org/cpython/rev/1273f1a3ddf7 New changeset 719da54652c5 by Yury Selivanov in branch 'default': Merge 3.6 (issue #28652) https://hg.python.org/cpython/rev/719da54652c5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 15:52:40 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 20:52:40 +0000 Subject: [issue24379] Add operator.subscript as a convenience for creating slices In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1478724760.9.0.16360222852.issue24379@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- Removed message: http://bugs.python.org/msg280422 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 15:59:37 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Nov 2016 20:59:37 +0000 Subject: [issue19717] resolve() fails when the path doesn't exist In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za> Message-ID: <20161109205934.66229.70234.6441675E@psf.io> Roundup Robot added the comment: New changeset 03bbee2b0d28 by Steve Dower in branch '3.6': Issue #19717: Makes Path.resolve() succeed on paths that do not exist (patch by Vajrasky Kok) https://hg.python.org/cpython/rev/03bbee2b0d28 New changeset 445415e402be by Steve Dower in branch 'default': Issue #19717: Makes Path.resolve() succeed on paths that do not exist (patch by Vajrasky Kok) https://hg.python.org/cpython/rev/445415e402be ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 16:00:13 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 09 Nov 2016 21:00:13 +0000 Subject: [issue19717] resolve() fails when the path doesn't exist In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za> Message-ID: <1478725213.53.0.711500176063.issue19717@psf.upfronthosting.co.za> Steve Dower added the comment: Applied. I changed the default for the parameter and updated the docs, but the rest is as in the patch. ---------- assignee: -> steve.dower resolution: -> fixed stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 16:09:09 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Nov 2016 21:09:09 +0000 Subject: [issue19717] resolve() fails when the path doesn't exist In-Reply-To: <1478725213.53.0.711500176063.issue19717@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 16:13:57 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Nov 2016 21:13:57 +0000 Subject: [issue28556] typing.py upgrades In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za> Message-ID: <20161109211349.122359.22383.1CB92FA8@psf.io> Roundup Robot added the comment: New changeset 9c0df5f51baa by Guido van Rossum in branch '3.5': Issue #28556: More typing.py updates from upstream. https://hg.python.org/cpython/rev/9c0df5f51baa New changeset 9e65bc305a24 by Guido van Rossum in branch '3.6': Issue #28556: More typing.py updates from upstream. (3.5->3.6) https://hg.python.org/cpython/rev/9e65bc305a24 New changeset 00e386ac7b95 by Guido van Rossum in branch 'default': Issue #28556: More typing.py updates from upstream. (3.6->3.7) https://hg.python.org/cpython/rev/00e386ac7b95 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 16:19:59 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Nov 2016 21:19:59 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <20161109211956.96080.24021.AC67F094@psf.io> Roundup Robot added the comment: New changeset d790078797bd by Guido van Rossum in branch '3.5': Issue #28649: fix-typing-test-v2.diff https://hg.python.org/cpython/rev/d790078797bd New changeset 43be7891b1f5 by Guido van Rossum in branch '3.6': Issue #28649: fix-typing-test-v2.diff (3.5->3.6) https://hg.python.org/cpython/rev/43be7891b1f5 New changeset fd47a9d791b9 by Guido van Rossum in branch 'default': Issue #28649: fix-typing-test-v2.diff (3.6->3.7) https://hg.python.org/cpython/rev/fd47a9d791b9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 16:23:58 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Nov 2016 21:23:58 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <20161109212354.66469.96856.1ADAA496@psf.io> Roundup Robot added the comment: New changeset d920bfa5a71a by Guido van Rossum in branch '3.5': Issue #28649: typing-clear-caches.patch https://hg.python.org/cpython/rev/d920bfa5a71a New changeset bd2ec9965f47 by Guido van Rossum in branch '3.6': Issue #28649: typing-clear-caches.patch (3.5->3.6) https://hg.python.org/cpython/rev/bd2ec9965f47 New changeset 08f76f89d199 by Guido van Rossum in branch 'default': Issue #28649: typing-clear-caches.patch (3.6->3.7) https://hg.python.org/cpython/rev/08f76f89d199 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 16:30:50 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 09 Nov 2016 21:30:50 +0000 Subject: [issue24379] Add operator.subscript as a convenience for creating slices In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1478727050.54.0.886691506343.issue24379@psf.upfronthosting.co.za> Josh Rosenberg added the comment: #28651 opened for the general problem with empty __slots__ and gc failures. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 16:32:04 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Nov 2016 21:32:04 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478727124.86.0.979515677991.issue28649@psf.upfronthosting.co.za> Guido van Rossum added the comment: Serhiy can you apply the non-typing.py part of typing-clear-caches.patch? The diff I applied only has the typing.py part (because I've done this upstream first). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 16:53:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Nov 2016 21:53:24 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <20161109215321.122493.19445.61F3FCC2@psf.io> Roundup Robot added the comment: New changeset d926b484d33a by Serhiy Storchaka in branch '3.5': Issue #28649: Clear the typing module caches when search for reference leaks. https://hg.python.org/cpython/rev/d926b484d33a New changeset caf3ceb93307 by Serhiy Storchaka in branch '3.6': Issue #28649: Clear the typing module caches when search for reference leaks. https://hg.python.org/cpython/rev/caf3ceb93307 New changeset 437564294e6c by Serhiy Storchaka in branch 'default': Issue #28649: Clear the typing module caches when search for reference leaks. https://hg.python.org/cpython/rev/437564294e6c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 17:55:06 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 22:55:06 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478732106.91.0.757763825989.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: With all commits pushed, test_typing still seems to leak. Ivan, do you have time to see what's going on? test_typing leaked [125, 125, 125] references, sum=375 test_typing leaked [49, 49, 49] memory blocks, sum=147 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 17:59:13 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 22:59:13 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478732353.77.0.0894600599927.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: The specific test that leaks is test_extended_generic_rules_eq ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 18:01:03 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 09 Nov 2016 23:01:03 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478732463.03.0.963925510104.issue28649@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Yury, yes I will take a look at this now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 18:01:51 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 23:01:51 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478732511.2.0.093534878561.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: Ivan, this is the part of the test that leaks: def test_extended_generic_rules_eq(self): T = TypeVar('T') U = TypeVar('U') with self.assertRaises(TypeError): Callable[[T], U][[], int] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 18:03:17 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 23:03:17 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478732597.45.0.0118985944314.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: Oh. This is a bug in C implementation of functools.lru_cache. I'll take a look. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 18:04:57 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 09 Nov 2016 23:04:57 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478732697.35.0.379539507174.issue28649@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: My impression is like something wrong happens when TypeError is raised by a cached function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 18:23:10 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 09 Nov 2016 23:23:10 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478733790.61.0.286485128959.issue28649@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: A very simple repro: with self.assertRaises(TypeError): Union[[]] It looks like the problem happens when a non-hashable argument is passed to cached function ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 18:37:26 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 23:37:26 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478734646.86.0.954061647552.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: reflesk with only functools: def test_lru_type_error(self): @functools.lru_cache(maxsize=None) def foo(o): raise TypeError with self.assertRaises(TypeError): foo([]) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 18:44:57 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 23:44:57 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478735097.96.0.967550617967.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: Found it, will open a separate issue. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 18:47:28 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 23:47:28 +0000 Subject: [issue28653] refleak in functools.lru_cache Message-ID: <1478735248.86.0.50213229618.issue28653@psf.upfronthosting.co.za> New submission from Yury Selivanov: The attached patch fixes a refleak in functools.lru_cache. ---------- components: Library (Lib) files: refleak.patch keywords: patch messages: 280468 nosy: gvanrossum, larry, ned.deily, serhiy.storchaka, yselivanov priority: release blocker severity: normal stage: patch review status: open title: refleak in functools.lru_cache type: resource usage versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45417/refleak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 18:47:57 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 09 Nov 2016 23:47:57 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478735277.33.0.381420356008.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: See http://bugs.python.org/issue28653 for details. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 18:49:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Nov 2016 23:49:34 +0000 Subject: [issue28653] refleak in functools.lru_cache In-Reply-To: <1478735248.86.0.50213229618.issue28653@psf.upfronthosting.co.za> Message-ID: <1478735374.55.0.467704444998.issue28653@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- assignee: -> yselivanov stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 18:51:37 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 09 Nov 2016 23:51:37 +0000 Subject: [issue28653] refleak in functools.lru_cache In-Reply-To: <1478735248.86.0.50213229618.issue28653@psf.upfronthosting.co.za> Message-ID: <1478735497.68.0.86418265007.issue28653@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: FWIW, if I comment out this code try: from _functools import _lru_cache_wrapper except ImportError: pass in functools.py to use the pure Python version, then I get much larger numbers: $ ./python -m test -R : test_typing Run tests sequentially 0:00:00 [1/1] test_typing beginning 9 repetitions 123456789 ......... test_typing leaked [25003, 25003, 25003, 25003] references, sum=100012 test_typing leaked [9350, 9352, 9352, 9352] memory blocks, sum=37406 test_typing failed ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 18:57:17 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Nov 2016 23:57:17 +0000 Subject: [issue28653] refleak in functools.lru_cache In-Reply-To: <1478735248.86.0.50213229618.issue28653@psf.upfronthosting.co.za> Message-ID: <20161109235714.2214.44007.FE48FF2E@psf.io> Roundup Robot added the comment: New changeset ba59f3328032 by Yury Selivanov in branch '3.5': Issue #28653: Fix a refleak in functools.lru_cache. https://hg.python.org/cpython/rev/ba59f3328032 New changeset 5b253d641826 by Yury Selivanov in branch '3.6': Merge 3.6 (issue #28653) https://hg.python.org/cpython/rev/5b253d641826 New changeset 784fea019cab by Yury Selivanov in branch 'default': Merge 3.6 (issue #28653) https://hg.python.org/cpython/rev/784fea019cab ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 19:03:00 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 10 Nov 2016 00:03:00 +0000 Subject: [issue28653] refleak in functools.lru_cache In-Reply-To: <1478735248.86.0.50213229618.issue28653@psf.upfronthosting.co.za> Message-ID: <1478736180.38.0.540054231365.issue28653@psf.upfronthosting.co.za> Yury Selivanov added the comment: > FWIW, if I comment out this code Oh boy... This is something else. Please re-open #28649 explaining that it now leaks with pure-Python lru_cache. Could you please take a look at it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 19:10:29 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 10 Nov 2016 00:10:29 +0000 Subject: [issue28653] refleak in functools.lru_cache In-Reply-To: <1478735248.86.0.50213229618.issue28653@psf.upfronthosting.co.za> Message-ID: <1478736629.72.0.976040634061.issue28653@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: It seems to be unrelated to typing.py With your test from test_functools: def test_lru_type_error(self): @functools.lru_cache(maxsize=None) def infinite_cache(o): pass with self.assertRaises(TypeError): infinite_cache([]) I get [2, 2, 2, 2] for unpatched C version (this is now fixed) and [24764, 24764, 24764, 24764] for Python version. Should I maybe open a separate issue for this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 19:13:16 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 10 Nov 2016 00:13:16 +0000 Subject: [issue28653] refleak in functools.lru_cache In-Reply-To: <1478735248.86.0.50213229618.issue28653@psf.upfronthosting.co.za> Message-ID: <1478736796.41.0.908977652553.issue28653@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Anyway, this is not urgent, typing.py uses the default version, which is the C version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 19:13:35 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 10 Nov 2016 00:13:35 +0000 Subject: [issue28653] refleak in functools.lru_cache In-Reply-To: <1478735248.86.0.50213229618.issue28653@psf.upfronthosting.co.za> Message-ID: <1478736815.93.0.481296838191.issue28653@psf.upfronthosting.co.za> Yury Selivanov added the comment: > It seems to be unrelated to typing.py Wow. I can reproduce refleaks in test_typing, but not in test_functools. This is weird. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 19:14:26 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 10 Nov 2016 00:14:26 +0000 Subject: [issue28653] refleak in functools.lru_cache In-Reply-To: <1478735248.86.0.50213229618.issue28653@psf.upfronthosting.co.za> Message-ID: <1478736866.27.0.951002397844.issue28653@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- stage: commit review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 19:17:26 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 10 Nov 2016 00:17:26 +0000 Subject: [issue28653] refleak in functools.lru_cache In-Reply-To: <1478735248.86.0.50213229618.issue28653@psf.upfronthosting.co.za> Message-ID: <1478737046.14.0.62228895781.issue28653@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Anyway, this is not urgent Not so sure, a refleak in pure-python version kind of scares me. It can be a bug in the core. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 19:26:52 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 10 Nov 2016 00:26:52 +0000 Subject: [issue28653] refleak in functools.lru_cache In-Reply-To: <1478735248.86.0.50213229618.issue28653@psf.upfronthosting.co.za> Message-ID: <1478737612.22.0.977666173745.issue28653@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: > Wow. I can reproduce refleaks in test_typing, but not in test_functools. This is weird. Indeed, I copied the new test from test_functools to test_typing, but now I see that pure Python version of lru_cache fails even if I remove this test and test that was previously failing with C version (test_extended_generic_rules_eq). > Not so sure, a refleak in pure-python version kind of scares me. It can be a bug in the core. Indeed. Now we need to figure out what it so special about typing that triggers the leak. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 19:43:18 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 10 Nov 2016 00:43:18 +0000 Subject: [issue28653] refleak in functools.lru_cache In-Reply-To: <1478735248.86.0.50213229618.issue28653@psf.upfronthosting.co.za> Message-ID: <1478738598.47.0.790866420866.issue28653@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: I am not sure what does this mean, but when I remove __slots__ = () from some classes, numbers of leaked references change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 20:11:57 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 10 Nov 2016 01:11:57 +0000 Subject: [issue28653] refleak in C functools.lru_cache In-Reply-To: <1478735248.86.0.50213229618.issue28653@psf.upfronthosting.co.za> Message-ID: <1478740317.35.0.221559793811.issue28653@psf.upfronthosting.co.za> Yury Selivanov added the comment: Ivan, I think I figured it out, I'll close this one and reopen the typing one. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed title: refleak in functools.lru_cache -> refleak in C functools.lru_cache _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 20:20:12 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 10 Nov 2016 01:20:12 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478740812.04.0.0226526644551.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: So Ivan made an interesting observation: if we use Python version of functools.lru_cache, typing tests start to leak like crazy: beginning 6 repetitions 123456 ...... test_typing leaked [24980, 24980, 24980] references, sum=74940 I experimented a bit, and I *think* I know what's happening: * typing uses an lru cache for types. * It looks like that some types in the cache are being *reused* by different tests. * Because typing doesn't set the size of the lru cache, it's set to 128 (default). * When many typing tests execute, the cache invalidates some entries, but because types in test_typing are so complex, I believe that the resulting graph of objects it too complex for the GC to go through (10s of thousands of cross-linked objects). A simple fix that removes fixes the refleak with Python version of lru_cache is to add a 'tearDown' method to 'test_typing.BaseTestCase': class BaseTestCase(TestCase): def tearDown(self): for f in typing._cleanups: f() Now this all of this is just my guess of what's going on here. It might be something that has to be fixed in typing, or maybe we should just add tearDown. Guido, Ivan, what do you think? ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 20:24:30 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Nov 2016 01:24:30 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478740812.04.0.0226526644551.issue28649@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: But why is this so different from the C implementation of lru_cache? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 20:27:22 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 10 Nov 2016 01:27:22 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478741242.78.0.95879863336.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: > But why is this so different from the C implementation of lru_cache? I don't know. Maybe C version of lru cache creates a bit less pressure on GC. BTW, if I set maxsize=100000 for typing lru_cache, test_generic_forward_ref crashes in refleak-test mode. Maybe this is another bug... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 20:35:58 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 10 Nov 2016 01:35:58 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478741758.15.0.607076267395.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: >> But why is this so different from the C implementation of lru_cache? > I don't know. Maybe C version of lru cache creates a bit less pressure on GC. Actually test/refleak.py now cleans up typing's lru cache & calls "gc.collect()". It seems that the typing cycles aren't collectable by the GC when Python lru cache is used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 20:38:25 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 10 Nov 2016 01:38:25 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478741905.46.0.303237963856.issue28649@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: > * It looks like that some types in the cache are being *reused* by different tests. I also noticed this some time ago, ideally we need to make all tests more isolated between each other. > Now this all of this is just my guess of what's going on here. It might be something that has to be fixed in typing, or maybe we should just add tearDown. adding tearDown is a good intermediate solution, while I could go through tests and try to make them more isolated from each other where necessary. > BTW, if I set maxsize=100000 for typing lru_cache, test_generic_forward_ref crashes in refleak-test mode. Maybe this is another bug... I also noticed this today, and this is something that I don't understand yet. This test should not depend on caching, but it looks like it does. I will think more about this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 20:39:04 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Nov 2016 01:39:04 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478741242.78.0.95879863336.issue28649@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Segfault or traceback? Anyway, it implements a doubly-linked list where each node is implemented as a list of 4 items... Maybe there's something in the GC code that recurses down at the C level??? I'm not sure a crash the Python version of lru_cache with maxsize=100000 is high on my list of worries. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 20:46:28 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 10 Nov 2016 01:46:28 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478742388.82.0.992934901513.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Segfault or traceback? Traceback. I should have said failed, not crashed :( > I'm not sure a crash the Python version of lru_cache with maxsize=100000 is high on my list of worries. The problem is that the test fails depending on cache size, and caching code shouldn't really do that ever. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 20:51:03 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 10 Nov 2016 01:51:03 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478742663.67.0.794584778241.issue28649@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: It looks like the tearDown() works really well. It also somehow fixes the problem with test_generic_forward_ref ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 9 20:56:24 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 10 Nov 2016 01:56:24 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478742984.31.0.103975769794.issue28649@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: I think Yury is right here. The good plan would be to add the tearDown(), but also fix the problem with test_generic_forward_ref. I could work on it tomorrow (really don't have time today, sorry). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 01:45:01 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 10 Nov 2016 06:45:01 +0000 Subject: [issue28615] Document clarification: Section 5.4 Complex Number In-Reply-To: <1478286572.26.0.816720776987.issue28615@psf.upfronthosting.co.za> Message-ID: <1478760301.79.0.220195836766.issue28615@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Hi, here is the doc update, to be applied to 2.7 branch. Please review. Thanks :) ---------- keywords: +patch nosy: +Mariatta Added file: http://bugs.python.org/file45418/issue28615.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 01:53:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Nov 2016 06:53:54 +0000 Subject: [issue23839] Clear caches after every test In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za> Message-ID: <1478760834.22.0.359125274442.issue23839@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file45419/regrtest_clear_caches_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 02:03:50 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 10 Nov 2016 07:03:50 +0000 Subject: [issue24329] __qualname__ and __slots__ In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za> Message-ID: <1478761430.04.0.915478562293.issue24329@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- keywords: +patch stage: -> patch review type: -> behavior Added file: http://bugs.python.org/file45420/slots_qualname.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 03:05:38 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Nov 2016 08:05:38 +0000 Subject: [issue24329] __qualname__ and __slots__ In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za> Message-ID: <1478765138.2.0.171223552436.issue24329@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What about other names set when creating a class? __module__, __class__, __classcell__? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 03:11:35 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 10 Nov 2016 08:11:35 +0000 Subject: [issue24329] __qualname__ and __slots__ In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za> Message-ID: <1478765495.88.0.920478335426.issue24329@psf.upfronthosting.co.za> Xiang Zhang added the comment: I think of them but currently they don't pose a problem for practical codes like __qualname__. Maybe leaving them until there comes a real need? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 03:13:42 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 10 Nov 2016 08:13:42 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478765622.83.0.737684232682.issue28649@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Guido, Yury, it looks like I solved the puzzle. All the remaining problems are because of forward references. In particular, _ForwardRef keeps a reference to the frame where it was defined: typing_globals = globals() frame = sys._getframe(1) while frame is not None and frame.f_globals is typing_globals: frame = frame.f_back assert frame is not None self.__forward_frame__ = frame This is old code from 2015 introduced to support __isinstance__ for forward refs. The latter is no more supported anyway, so that I believe this code should be removed. I will make a PR upstream soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 03:18:38 2016 From: report at bugs.python.org (Kuno Meyer) Date: Thu, 10 Nov 2016 08:18:38 +0000 Subject: [issue28654] sys.stdout.isatty() returns True even if redirected to NUL Message-ID: <1478765918.44.0.71383121228.issue28654@psf.upfronthosting.co.za> New submission from Kuno Meyer: [Python 3.5.2 on Windows] >py -c "import sys; print(sys.stdout.isatty(), file=sys.stderr)" > NUL True NUL is the Windows equivalent of /dev/nul, so the result should probably be False. Under Cygwin, the result is as expected: $ python3 -c "import sys; print(sys.stdout.isatty(), file=sys.stderr)" > /dev/nul False ---------- components: Windows messages: 280494 nosy: kmeyer, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: sys.stdout.isatty() returns True even if redirected to NUL versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 03:27:48 2016 From: report at bugs.python.org (Matthieu S) Date: Thu, 10 Nov 2016 08:27:48 +0000 Subject: [issue28016] test_fileio fails on AIX In-Reply-To: <1473323328.73.0.215988699422.issue28016@psf.upfronthosting.co.za> Message-ID: <1478766468.49.0.278101747923.issue28016@psf.upfronthosting.co.za> Matthieu S added the comment: Sorry for the late reply. I did some additional testing, and I can confirm that this assertion should also be skipped in Python 2.7 on AIX. And the test does not fail when run without a tty, so we can assume that this is what happens on the builbots. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 03:34:33 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 10 Nov 2016 08:34:33 +0000 Subject: [issue24329] __qualname__ and __slots__ In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za> Message-ID: <1478766873.07.0.45955714876.issue24329@psf.upfronthosting.co.za> Changes by Xiang Zhang : Added file: http://bugs.python.org/file45421/slots_qualname_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 03:43:50 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 10 Nov 2016 08:43:50 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478767430.57.0.585055104869.issue28649@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: > BTW, if I set maxsize=100000 for typing lru_cache, test_generic_forward_ref crashes in refleak-test mode. Maybe this is another bug... This one is also related to the mentioned in my previous message. Namely, forward references are only evaluated once. However, in refleak hunting mode tests are repeated multiple times, and every time test_generic_forward_ref is called, this code: class CC: ... creates a new local class, while forward ref is still pointing to an old one. There are two options: * keep this behaviour and update the test to use a globally defined class; * change this and re-evaluate forward refs every times. However I would vote for a compromise solution: if the ``locals`` argument is not given, just use the evaluated value. But if a user gives non-None ``locals`` argument then that user most probably wants to re-evaluate the forward ref locally. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 03:46:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Nov 2016 08:46:58 +0000 Subject: [issue28655] Tests altered the execution environment in isolated mode Message-ID: <1478767618.32.0.527967950395.issue28655@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Following tests altered the execution environment in isolated mode: test_asyncio test_ctypes test_email test_idle test_import test_importlib test_json test_lib2to3 $ ./python -I -S -m test.regrtest -vv test_asyncio test_ctypes test_email test_idle test_import test_importlib test_json test_lib2to3 >/dev/null Warning -- sys.path was modified by test_asyncio Before: (3071075980, ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug'], ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug']) After: (3071075980, ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug'], ['/home/serhiy/py/cpython3.6-debug/Lib', '/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug']) Warning -- sys.path was modified by test_ctypes Before: (3071075980, ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug'], ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug']) After: (3071075980, ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug'], ['/home/serhiy/py/cpython3.6-debug/Lib', '/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug']) Warning -- sys.path was modified by test_email Before: (3071075980, ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug'], ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug']) After: (3071075980, ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug'], ['/home/serhiy/py/cpython3.6-debug/Lib', '/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug']) Warning -- sys.path was modified by test_idle Before: (3071075980, ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug'], ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug']) After: (3071075980, ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug'], ['/home/serhiy/py/cpython3.6-debug/Lib', '/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug']) Warning -- files was modified by test_import Before: [] After: ['@test_30748_tmp.pyc'] Warning -- sys.path was modified by test_importlib Before: (3071075980, ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug'], ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug']) After: (3071075980, ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug'], ['/home/serhiy/py/cpython3.6-debug/Lib', '/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug']) Warning -- sys.path was modified by test_json Before: (3071075980, ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug'], ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug']) After: (3071075980, ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug'], ['/home/serhiy/py/cpython3.6-debug/Lib', '/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug']) /home/serhiy/py/cpython3.6-debug/Lib/lib2to3/tests/test_parser.py:393: UserWarning: ParseError on file /home/serhiy/py/cpython3.6-debug/Lib/lib2to3/main.py (bad input: type=22, value='=', context=('', (130, 38))) warnings.warn('ParseError on file %s (%s)' % (filepath, err)) /home/serhiy/py/cpython3.6-debug/Lib/lib2to3/tests/test_parser.py:393: UserWarning: ParseError on file /home/serhiy/py/cpython3.6-debug/Lib/lib2to3/tests/pytree_idempotency.py (bad input: type=22, value='=', context=('', (49, 33))) warnings.warn('ParseError on file %s (%s)' % (filepath, err)) Warning -- sys.path was modified by test_lib2to3 Before: (3071075980, ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug'], ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug']) After: (3071075980, ['/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug'], ['/home/serhiy/py/cpython3.6-debug/Lib', '/usr/local/lib/python36.zip', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/Lib/', '/home/serhiy/py/cpython3.6-debug/build/lib.linux-i686-3.6-pydebug']) ---------- components: Tests messages: 280497 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: Tests altered the execution environment in isolated mode type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 04:00:23 2016 From: report at bugs.python.org (Eryk Sun) Date: Thu, 10 Nov 2016 09:00:23 +0000 Subject: [issue28654] sys.stdout.isatty() returns True even if redirected to NUL In-Reply-To: <1478765918.44.0.71383121228.issue28654@psf.upfronthosting.co.za> Message-ID: <1478768423.34.0.247597760462.issue28654@psf.upfronthosting.co.za> Eryk Sun added the comment: Windows doesn't have terminal devices, so the C runtime's isatty() function just checks for a character device, which includes NUL among others. This can lead to hanging the REPL, albeit with a contrived example such as redirecting stdin to COM3: C:\>python < COM3 Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> ^C Ctrl+C doesn't work because the main thread is blocked (we'd have to call CancelSynchronousIo in the C signal handler). I killed the process using the default Ctrl+Break handler. "^C" was printed by the cmd shell's Ctrl+Break handler. I don't think the CRT's check for a character device is generally useful. It could be replaced with a check that specifically looks for a console handle (e.g. by calling GetConsoleMode), which is what someone calling isatty() generally wants to know. ---------- components: +IO nosy: +eryksun versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 04:33:06 2016 From: report at bugs.python.org (muzhong) Date: Thu, 10 Nov 2016 09:33:06 +0000 Subject: [issue28656] build error in cygwin64 ,because pthread_key_t Message-ID: <1478770386.64.0.617374517567.issue28656@psf.upfronthosting.co.za> New submission from muzhong: ENV: CYGWIN_NT-6.1 2.6.0(0.304/5/3) 2016-08-31 14:32 x86_64 Cygwin gcc (GCC) 5.4.0 g++ (GCC) 5.4.0 Error Msg: Fatal Python error: Could not allocate TLS entry Cause: /usr/include/machine/types.h:typedef struct __pthread_key_t {char __dummy;} *pthread_key_t; but convert pthread_key_t to int or compare with int in thread_pthread.h/thread.c/pythread.h/pystate.c/pylifecycle.c ---------- components: Cross-Build messages: 280499 nosy: Alex.Willmer, muzhong priority: normal severity: normal status: open title: build error in cygwin64 ,because pthread_key_t type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 05:16:27 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Nov 2016 10:16:27 +0000 Subject: [issue19398] test_trace fails with -S In-Reply-To: <1382730233.11.0.30990585871.issue19398@psf.upfronthosting.co.za> Message-ID: <1478772987.65.0.732708474397.issue19398@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The separator is needed if the relative path is not empty and the prefix doesn't end with the separator. This patch seems also fixes most problems of issue28655. ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka versions: +Python 3.5, Python 3.6, Python 3.7 -Python 3.4 Added file: http://bugs.python.org/file45422/remove_extra_slash_from_sys_path_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 05:31:12 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 10 Nov 2016 10:31:12 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478773872.3.0.334596874724.issue28649@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: OK, here are the PRs: https://github.com/python/typing/pull/327 https://github.com/python/typing/pull/328 Those two seem to fix everything, I tried various cache sizes with both C and Python versions of lru_cache and found no refleaks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 06:14:10 2016 From: report at bugs.python.org (=?utf-8?b?QsWCYcW8ZWogTWljaGFsaWs=?=) Date: Thu, 10 Nov 2016 11:14:10 +0000 Subject: [issue28657] cmd.Cmd.get_help() implementation can't see do_*() methods added dynamically by setattr() Message-ID: <1478776450.68.0.870801686772.issue28657@psf.upfronthosting.co.za> New submission from B?a?ej Michalik: The issue here seems to originate from the implementation of Cmd.get_names(): def get_names(self): # This method used to pull in base class attributes # at a time dir() didn't do it yet. return dir(self.__class__) Changing it to dir(self) would make dynamical adding helpstrings for commands possible. ---------- components: Library (Lib) messages: 280502 nosy: B?a?ej Michalik priority: normal severity: normal status: open title: cmd.Cmd.get_help() implementation can't see do_*() methods added dynamically by setattr() type: behavior versions: 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 Thu Nov 10 06:51:25 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Nov 2016 11:51:25 +0000 Subject: [issue28656] build error in cygwin64 ,because pthread_key_t In-Reply-To: <1478770386.64.0.617374517567.issue28656@psf.upfronthosting.co.za> Message-ID: <1478778685.04.0.373190237776.issue28656@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue25658. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 07:57:45 2016 From: report at bugs.python.org (Kuno Meyer) Date: Thu, 10 Nov 2016 12:57:45 +0000 Subject: [issue28654] sys.stdout.isatty() returns True even if redirected to NUL In-Reply-To: <1478765918.44.0.71383121228.issue28654@psf.upfronthosting.co.za> Message-ID: <1478782665.66.0.0543387264486.issue28654@psf.upfronthosting.co.za> Kuno Meyer added the comment: http://stackoverflow.com/questions/3648711/detect-nul-file-descriptor-isatty-is-bogus, although a bit convoluted, might also help. It mentions GetConsoleMode() for stdin and GetConsoleScreenBufferInfo() for stdout. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 08:48:03 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 10 Nov 2016 13:48:03 +0000 Subject: [issue24329] __qualname__ and __slots__ In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za> Message-ID: <1478785683.06.0.98241669702.issue24329@psf.upfronthosting.co.za> Xiang Zhang added the comment: > What about other names set when creating a class? __module__, __class__, __classcell__? __module__ remains in the class dict so I think it's a class variable. Will __class__ be set? It's inserted into the function scope. __classcell__ I think has the same situation with __qualname__. New patch also adds __classcell__. ---------- Added file: http://bugs.python.org/file45423/slots_special.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 09:00:15 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 10 Nov 2016 14:00:15 +0000 Subject: [issue28644] Document recen changes in typing.py In-Reply-To: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za> Message-ID: <1478786415.9.0.94956210514.issue28644@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Guido, here is a new patch with your comments implemented. ---------- Added file: http://bugs.python.org/file45424/recent-typing-docs-v4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 09:24:07 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 10 Nov 2016 14:24:07 +0000 Subject: [issue24329] __qualname__ and __slots__ In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za> Message-ID: <1478787847.83.0.757783414214.issue24329@psf.upfronthosting.co.za> Xiang Zhang added the comment: slots_special_v2 fixes a bug in the previous patch. ---------- Added file: http://bugs.python.org/file45425/slots_special_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 09:25:23 2016 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Thu, 10 Nov 2016 14:25:23 +0000 Subject: [issue28654] sys.stdout.isatty() returns True even if redirected to NUL In-Reply-To: <1478765918.44.0.71383121228.issue28654@psf.upfronthosting.co.za> Message-ID: <1478787923.63.0.559637849717.issue28654@psf.upfronthosting.co.za> ???? ????????? added the comment: 1. I think, that is not a bug. 2. It seems, that for Cygwin, `> /dev/nul` is a bug, it should be `/dev/null` does not it ? ---------- nosy: +mmarkk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 09:32:06 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 Nov 2016 14:32:06 +0000 Subject: [issue24329] __qualname__ and __slots__ In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za> Message-ID: <1478788326.12.0.0920039392804.issue24329@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 09:35:00 2016 From: report at bugs.python.org (Andrew Kontokanis) Date: Thu, 10 Nov 2016 14:35:00 +0000 Subject: [issue28658] MacOsX idle don't run Message-ID: <1478788500.94.0.845802145571.issue28658@psf.upfronthosting.co.za> New submission from Andrew Kontokanis: When I try and launch IDLE, the icon appears on the dock for a second and then disappears and the application doesn't run. I was trying to install new themes but when I managed to do find .idlerc folder I had messed up with some idle folder. I tried to uninstall and install but it didn't work. Trying to find solution I read some hints to check through terminal and I took these messages in attachment. I didn't find the same solution with the previous problems so I opened an question ---------- files: error.log.pdf messages: 280509 nosy: Andrew Kontokanis priority: normal severity: normal status: open title: MacOsX idle don't run type: crash versions: Python 3.5 Added file: http://bugs.python.org/file45426/error.log.pdf _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 09:43:18 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Nov 2016 14:43:18 +0000 Subject: [issue24329] __qualname__ and __slots__ In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za> Message-ID: <1478788998.35.0.684536575606.issue24329@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: __qualname__ doesn't makes much sense if it doesn't match __module__. If _GeneratorWrapper patches __qualname__, I think it should patch __module__ too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 10:37:10 2016 From: report at bugs.python.org (Masayuki Yamamoto) Date: Thu, 10 Nov 2016 15:37:10 +0000 Subject: [issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX In-Reply-To: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za> Message-ID: <1478792230.3.0.259543497042.issue25658@psf.upfronthosting.co.za> Masayuki Yamamoto added the comment: Hi, I came from #28656. I have read past discussions, And I've understood the pthread_key_t has possible of either integer or pointer. So I think there is a simple solution that replaces key type to intptr_t. Thus I wrote a patch, but it maybe need configure check for intptr_t if CPytyhon still be supporting for before C99 compilers. I confirmed patch on Cygwin x86. Would you be able to confirm for other platforms? ---------- nosy: +masamoto type: -> compile error versions: +Python 3.7 Added file: http://bugs.python.org/file45427/pythread-key-intptr_t.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 10:55:16 2016 From: report at bugs.python.org (Ed Schouten) Date: Thu, 10 Nov 2016 15:55:16 +0000 Subject: [issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX In-Reply-To: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za> Message-ID: <1478793316.28.0.376527269474.issue25658@psf.upfronthosting.co.za> Ed Schouten added the comment: It can also be a structure or a union. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 10:59:08 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 10 Nov 2016 15:59:08 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478793548.84.0.831779817338.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: Good work, Ivan! > Those two seem to fix everything, I tried various cache sizes with both C and Python versions of lru_cache and found no refleaks. Speaking of lru_cache: typing currently doesn't configure maxsize, which means that the cache is limited to 128 items. Is that OK? Should maxsize be set to None to make the cache unlimited, or, maybe, a higher number like 1024 is more appropriate? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 11:03:14 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Nov 2016 16:03:14 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478793548.84.0.831779817338.issue28649@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: We discussed cache size previously and 128 is fine. --Guido (mobile) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 11:11:15 2016 From: report at bugs.python.org (Stelios) Date: Thu, 10 Nov 2016 16:11:15 +0000 Subject: [issue28659] xml.etree.cElementTree.write misses opening tag Message-ID: <1478794275.76.0.0715708391082.issue28659@psf.upfronthosting.co.za> New submission from Stelios: import xml.etree.cElementTree as ET events = ET.Element('Events') tree = ET.ElementTree(events) tree.write('test.xml', xml_declaration=True, encoding='UTF-8') writes to file: Where opening tag is missing Python version: Python 3.5.2 ---------- components: XML messages: 280515 nosy: chefarov priority: normal severity: normal status: open title: xml.etree.cElementTree.write misses opening tag type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 11:20:02 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 10 Nov 2016 16:20:02 +0000 Subject: [issue28659] xml.etree.cElementTree.write misses opening tag In-Reply-To: <1478794275.76.0.0715708391082.issue28659@psf.upfronthosting.co.za> Message-ID: <1478794802.26.0.478709392532.issue28659@psf.upfronthosting.co.za> Xiang Zhang added the comment: is an empty tag. It closes it self, not '/>'. With some content, you can see it has start and end tag. >>> import xml.etree.cElementTree as ET >>> events = ET.Element('Events') >>> events.text = 'abc' >>> tree = ET.ElementTree(events) >>> tree.write('/tmp/a.xml', xml_declaration=True, encoding='UTF-8') abc ---------- nosy: +xiang.zhang resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 11:20:26 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 10 Nov 2016 16:20:26 +0000 Subject: [issue28659] xml.etree.cElementTree.write misses opening tag In-Reply-To: <1478794275.76.0.0715708391082.issue28659@psf.upfronthosting.co.za> Message-ID: <1478794826.04.0.0869285185153.issue28659@psf.upfronthosting.co.za> Xiang Zhang added the comment: s/not/note ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 11:28:20 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Nov 2016 16:28:20 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <20161110162812.85859.55160.8990983A@psf.io> Roundup Robot added the comment: New changeset 0da2e381ad71 by Guido van Rossum in branch '3.5': Issue #28649: fix first issue with _ForwardRef (#327) https://hg.python.org/cpython/rev/0da2e381ad71 New changeset 249a1f0b2857 by Guido van Rossum in branch '3.6': Issue #28649: fix first issue with _ForwardRef (#327) (3.5->3.6) https://hg.python.org/cpython/rev/249a1f0b2857 New changeset 304f017462e4 by Guido van Rossum in branch 'default': Issue #28649: fix first issue with _ForwardRef (#327) (3.6->3.7) https://hg.python.org/cpython/rev/304f017462e4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 11:29:51 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Nov 2016 16:29:51 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <20161110162944.20330.20341.E37EF091@psf.io> Roundup Robot added the comment: New changeset 555f0ca31587 by Guido van Rossum in branch '3.5': Issue #28649: fix second issue with _ForwardRef (#328) https://hg.python.org/cpython/rev/555f0ca31587 New changeset 0f863906cf2e by Guido van Rossum in branch '3.6': Issue #28649: fix second issue with _ForwardRef (#328) (3.5->3.6) https://hg.python.org/cpython/rev/0f863906cf2e New changeset 84b4ac243508 by Guido van Rossum in branch 'default': Issue #28649: fix second issue with _ForwardRef (#328) (3.6->3.7) https://hg.python.org/cpython/rev/84b4ac243508 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 11:31:01 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Nov 2016 16:31:01 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478795461.88.0.468846924722.issue28649@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks a bundle, Ivan! I've merged those two into CPython 3.5, 3.6, 3.7. We can now watch the build bots for a while and double-check the refleaks. Yury, when you're happy with the situation can you close this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 11:32:47 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 10 Nov 2016 16:32:47 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478795567.22.0.958766944233.issue28649@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thank you Guido and Ivan! > Yury, when you're happy with the situation can you close this issue? I'll close it now, will reopen if something comes up. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 11:35:01 2016 From: report at bugs.python.org (Peter) Date: Thu, 10 Nov 2016 16:35:01 +0000 Subject: [issue28660] TextWrapper break_long_words=True, break_on_hyphens=True on long words Message-ID: <1478795701.76.0.659915154246.issue28660@psf.upfronthosting.co.za> New submission from Peter: Quoting https://docs.python.org/2/library/textwrap.html width (default: 70) The maximum length of wrapped lines. As long as there are no individual words in the input text longer than width, TextWrapper guarantees that no output line will be longer than width characters. It appears that with break_long_words=True and break_on_hyphens=True, any hyphenated term longer than the specified width does not get preferentially broken at a hyphen. Example input: We used the enyzme 2-succinyl-6-hydroxy-2,4-cyclohexadiene-1-carboxylate synthase. Using break_long_words=True, break_on_hyphens=True ================================================== We used the enyzme 2-succinyl-6-hydroxy-2,4-cycloh exadiene-1-carboxylate synthase. ================================================== Expected result using break_long_words=True, break_on_hyphens=True ================================================== We used the enyzme 2-succinyl-6-hydroxy-2,4- cyclohexadiene-1-carboxylate synthase. ================================================== Given a width=50, then the 53 character long "word" of "2-succinyl-6-hydroxy-2,4-cyclohexadiene-1-carboxylate" must be split somewhere, and since break_on_hyphens=True it should break at a hyphen as shown above as the desired output. Sample code: import textwrap w = 50 text = "We used the enyzme 2-succinyl-6-hydroxy-2,4-cyclohexadiene-1-carboxylate synthase." print("Input:") print("=" * w) print(text) print("=" * w) print("Using break_long_words=True, break_on_hyphens=True") print("=" * w) print(textwrap.fill(text, width=w, break_long_words=True, break_on_hyphens=True)) print("=" * w) ---------- messages: 280522 nosy: maubp priority: normal severity: normal status: open title: TextWrapper break_long_words=True, break_on_hyphens=True on long words versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 11:35:38 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Nov 2016 16:35:38 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478795738.03.0.315613115452.issue28649@psf.upfronthosting.co.za> Guido van Rossum added the comment: BTW, do we still want the tearDown()? Or is that no longer necessary? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 11:45:07 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 10 Nov 2016 16:45:07 +0000 Subject: [issue28649] refleak in typing.py In-Reply-To: <1478707208.62.0.656911294058.issue28649@psf.upfronthosting.co.za> Message-ID: <1478796307.94.0.473065636226.issue28649@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: I think tearDown() is not necessary. But on the other hand it could be nice to have a method in tests to force cache clear. I would propose it not as a default, but as an opt-in to check that cache works well, or that a certain tested feature is "cache independent", etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 11:49:08 2016 From: report at bugs.python.org (Masayuki Yamamoto) Date: Thu, 10 Nov 2016 16:49:08 +0000 Subject: [issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX In-Reply-To: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za> Message-ID: <1478796548.88.0.102656321817.issue25658@psf.upfronthosting.co.za> Masayuki Yamamoto added the comment: Umm, API seems a design that is passing into function by integer or pointer because the users don't need type detail. I think the implementation of complex type is not realistic. Actually, CouldABI and Cygwin are used pointer, and type detail is hided. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 11:56:58 2016 From: report at bugs.python.org (Ed Schouten) Date: Thu, 10 Nov 2016 16:56:58 +0000 Subject: [issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX In-Reply-To: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za> Message-ID: <1478797018.57.0.204556465988.issue25658@psf.upfronthosting.co.za> Ed Schouten added the comment: CloudABI uses a structure type, which is exactly why I filed this bug report. Instead of speculating about what kind of type existing implementations use, please just focus on the specification to which we're trying to stick: POSIX. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html "All of the types shall be defined as arithmetic types of an appropriate length, with the following exceptions: [...] pthread_key_t [...]" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 12:05:25 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Nov 2016 17:05:25 +0000 Subject: [issue28656] build error in cygwin64 ,because pthread_key_t In-Reply-To: <1478770386.64.0.617374517567.issue28656@psf.upfronthosting.co.za> Message-ID: <1478797525.97.0.98054030331.issue28656@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> PyThread assumes pthread_key_t is an integer, which is against POSIX _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 12:07:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Nov 2016 17:07:13 +0000 Subject: [issue28660] TextWrapper break_long_words=True, break_on_hyphens=True on long words In-Reply-To: <1478795701.76.0.659915154246.issue28660@psf.upfronthosting.co.za> Message-ID: <1478797633.64.0.90599340523.issue28660@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Library (Lib) nosy: +georg.brandl, serhiy.storchaka type: -> behavior versions: +Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 12:14:59 2016 From: report at bugs.python.org (Masayuki Yamamoto) Date: Thu, 10 Nov 2016 17:14:59 +0000 Subject: [issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX In-Reply-To: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za> Message-ID: <1478798099.64.0.828917028259.issue25658@psf.upfronthosting.co.za> Masayuki Yamamoto added the comment: On, I got complex type in cloudABI. I see my patch doesn't solve it. https://github.com/NuxiNL/cloudlibc/blob/master/src/include/sys/types.h#L94 https://github.com/NuxiNL/cloudlibc/blob/master/src/include/_/types.h#L209 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 13:21:28 2016 From: report at bugs.python.org (Elvis Pranskevichus) Date: Thu, 10 Nov 2016 18:21:28 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1478802088.91.0.367100465945.issue28635@psf.upfronthosting.co.za> Changes by Elvis Pranskevichus : Added file: http://bugs.python.org/file45428/0001-Issue-28635-Fix-a-couple-of-missing-incorrect-versio.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 13:21:36 2016 From: report at bugs.python.org (Elvis Pranskevichus) Date: Thu, 10 Nov 2016 18:21:36 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1478802096.87.0.49177395803.issue28635@psf.upfronthosting.co.za> Changes by Elvis Pranskevichus : Added file: http://bugs.python.org/file45429/0002-Issue-28635-What-s-New-in-Python-3.6-updates.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 13:22:20 2016 From: report at bugs.python.org (Elvis Pranskevichus) Date: Thu, 10 Nov 2016 18:22:20 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1478802140.76.0.858666042216.issue28635@psf.upfronthosting.co.za> Elvis Pranskevichus added the comment: Attached patch for another pass on what's new. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 13:23:05 2016 From: report at bugs.python.org (Elvis Pranskevichus) Date: Thu, 10 Nov 2016 18:23:05 +0000 Subject: [issue28641] Describe PEP 495 features in "What's New in Python 3.6" document In-Reply-To: <1478625046.84.0.866752786385.issue28641@psf.upfronthosting.co.za> Message-ID: <1478802185.68.0.306287111452.issue28641@psf.upfronthosting.co.za> Elvis Pranskevichus added the comment: This should now be covered in #28635. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 13:23:58 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 10 Nov 2016 18:23:58 +0000 Subject: [issue28641] Describe PEP 495 features in "What's New in Python 3.6" document In-Reply-To: <1478625046.84.0.866752786385.issue28641@psf.upfronthosting.co.za> Message-ID: <1478802238.25.0.144295668504.issue28641@psf.upfronthosting.co.za> Yury Selivanov added the comment: Closing this one. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 13:26:14 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Nov 2016 18:26:14 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <20161110182611.124271.98940.BB26F85E@psf.io> Roundup Robot added the comment: New changeset bcd4ab982429 by Yury Selivanov in branch '3.6': Issue #28635: Fix a couple of missing/incorrect versionchanged tags https://hg.python.org/cpython/rev/bcd4ab982429 New changeset 5c4ce500dd35 by Yury Selivanov in branch 'default': Merge 3.6 (issue #28635) https://hg.python.org/cpython/rev/5c4ce500dd35 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 13:28:10 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Nov 2016 18:28:10 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <20161110182807.26426.79184.98099EB6@psf.io> Roundup Robot added the comment: New changeset c0060567f35d by Yury Selivanov in branch '3.6': Issue #28635: What's New in Python 3.6 updates https://hg.python.org/cpython/rev/c0060567f35d New changeset 69bdf8bdfd61 by Yury Selivanov in branch 'default': Merge 3.6 (issue #28635) https://hg.python.org/cpython/rev/69bdf8bdfd61 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 13:48:09 2016 From: report at bugs.python.org (=?utf-8?q?Cristian_M=C4=83gheru=C8=99an-Stanciu?=) Date: Thu, 10 Nov 2016 18:48:09 +0000 Subject: [issue557704] netrc module can't handle all passwords Message-ID: <1478803689.42.0.551618409329.issue557704@psf.upfronthosting.co.za> Cristian M?gheru?an-Stanciu added the comment: Is there anything blocking this from being really fixed? It's still broken on 3.5. The patch added two years ago works well for quoted passwords, I think that's good enough, anyway having some support is much better than the current out of the box situation. ---------- versions: +Python 3.5 -Python 2.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 13:48:57 2016 From: report at bugs.python.org (Carl Meyer) Date: Thu, 10 Nov 2016 18:48:57 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1478803737.58.0.193843867248.issue21145@psf.upfronthosting.co.za> Carl Meyer added the comment: I've used the cached_property pattern across many different projects, and never yet wanted a TTL. The simple "cache for the lifetime of the instance" behavior is easy to implement, easy to understand, and useful for a wide range of scenarios where instances are effectively immutable. +1 for adding this to the stdlib (not just as a docs recipe); I'll see about providing a patch. ---------- nosy: +carljm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 14:15:25 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Nov 2016 19:15:25 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1478805325.91.0.345787854614.issue28635@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patches for following issues was applied in 3.5. They may be bug fixes, not new features. #13248 #16113 #20476 #22115 #23517 #24764 #25590 #25593 #25913 #26470 #26733 #26754 #26801 #27040 #27041 #27243 #27392 #27598 #27691 #27766 #27850 #27932 #28370 #28613 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 14:16:31 2016 From: report at bugs.python.org (Ivan Tomilov) Date: Thu, 10 Nov 2016 19:16:31 +0000 Subject: [issue28661] Fix code example in Python 3.5 telnetlib documentation Message-ID: <1478805391.59.0.11862034954.issue28661@psf.upfronthosting.co.za> New submission from Ivan Tomilov: The code sample on page https://docs.python.org/3/library/telnetlib.html is a little confusing. The extra space in string "Password: " before the second quote basically hangs the example program when you try to run it. Please, check my answer on Stack Overflow for more details: http://stackoverflow.com/questions/28345839/python3-telnet-code-stays-quiet-after-launching-does-not-initiate-the-command-t/40535049#40535049 I'm sorry if I get something wrong. Thanks, Ivan. ---------- assignee: docs at python components: Documentation messages: 280536 nosy: docs at python, tiabc priority: normal severity: normal status: open title: Fix code example in Python 3.5 telnetlib documentation type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 14:41:55 2016 From: report at bugs.python.org (Sohaib Ahmad) Date: Thu, 10 Nov 2016 19:41:55 +0000 Subject: [issue27973] urllib.urlretrieve() fails on second ftp transfer In-Reply-To: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za> Message-ID: <1478806915.08.0.0834635692191.issue27973@psf.upfronthosting.co.za> Sohaib Ahmad added the comment: @Senthil, thanks for looking into this. Looking forward to your commit. Regards. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 14:42:58 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 10 Nov 2016 19:42:58 +0000 Subject: [issue27973] urllib.urlretrieve() fails on second ftp transfer In-Reply-To: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za> Message-ID: <1478806978.72.0.164320011776.issue27973@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- assignee: -> orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 15:10:30 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Nov 2016 20:10:30 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1478808630.26.0.548993224853.issue28635@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: +The disassembler now decodes ``FORMAT_VALUE`` argument. +(Contributed by Serhiy Storchaka in :issue:`28317`.) FORMAT_VALUE is new in 3.6. This change should be considered as a part of PEP 498 and is not deserve special mentioning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 15:35:43 2016 From: report at bugs.python.org (Elvis Pranskevichus) Date: Thu, 10 Nov 2016 20:35:43 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1478810143.75.0.835941846308.issue28635@psf.upfronthosting.co.za> Elvis Pranskevichus added the comment: Thanks Serhiy. I removed mentions of things that were indeed fixes backported to 3.5. Other issue references are valid news, including new features to provisional modules backported to 3.5. It is customary to include these in the news for the major release. ---------- Added file: http://bugs.python.org/file45430/0001-Issue-28635-what-s-new-in-3.6-remove-mentions-of-bac.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 15:39:53 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Nov 2016 20:39:53 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <20161110203950.96974.41355.28EF733E@psf.io> Roundup Robot added the comment: New changeset 4c81a107ccab by Yury Selivanov in branch '3.6': Issue #28635: what's new in 3.6: remove mentions of backported fixes. https://hg.python.org/cpython/rev/4c81a107ccab New changeset 8ebaa546a033 by Yury Selivanov in branch 'default': Merge 3.6 (issue #28635) https://hg.python.org/cpython/rev/8ebaa546a033 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 15:46:49 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Nov 2016 20:46:49 +0000 Subject: [issue28644] Document recent changes in typing.py In-Reply-To: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za> Message-ID: <1478810809.96.0.181424024583.issue28644@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- title: Document recen changes in typing.py -> Document recent changes in typing.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 16:17:19 2016 From: report at bugs.python.org (Carl Meyer) Date: Thu, 10 Nov 2016 21:17:19 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1478812639.3.0.921584329028.issue21145@psf.upfronthosting.co.za> Carl Meyer added the comment: Attaching a patch with the simplest version of cached_property (tehnique is not original, similar code is found in Django, Bottle, Flask, the cached_property lib, and many other places). ---------- components: +Library (Lib) keywords: +patch versions: +Python 3.7 -Python 3.6 Added file: http://bugs.python.org/file45431/cached_property.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 16:20:50 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Nov 2016 21:20:50 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1478812850.94.0.191613336468.issue21145@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The decorator should support classes with __slots__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 16:31:05 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 10 Nov 2016 21:31:05 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1478813465.95.0.481037933719.issue28638@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > half a millisecond is reduced. I would like to caution against any significant changes to save microscopic amounts of time. Twisting the code into knots for minor time savings is rarely worth it and it not what Python is all about. > Half milliseconds is small, but it isn't negligible on some situation. I would say that it is almost always negligible and reflects a need for a better sense of proportion and perspective. Also, in the past we've found that efforts to speed start-up time were measurable only in trivial cases. Tools like mercurial end-up importing and using a substantial chunk of the standard library anyway, so those tools got zero benefit from the contortions we did to move _collections_abc.py from underneath the collections module. In the case of functools, if the was a real need (and I don't believe there is), I would be willing to accept INADA's original patch replacing the namedtuple call with its source. That said, I don't think half millisecond is worth the increase in code volume and the double maintenance problem keeping it in-sync with any future changes to namedtuple. In my opinion, accumulating technical debt in this fashion is a poor software design practice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 16:32:26 2016 From: report at bugs.python.org (Raul) Date: Thu, 10 Nov 2016 21:32:26 +0000 Subject: [issue28591] imghdr doesn't recognize some jpeg formats In-Reply-To: <1478117178.16.0.265494893112.issue28591@psf.upfronthosting.co.za> Message-ID: <1478813546.57.0.0853008908037.issue28591@psf.upfronthosting.co.za> Raul added the comment: New patch for imghdr bug, including unittets. This patch works on python 3.x ---------- Added file: http://bugs.python.org/file45432/imghdr_py3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 16:35:27 2016 From: report at bugs.python.org (Raul) Date: Thu, 10 Nov 2016 21:35:27 +0000 Subject: [issue28591] imghdr doesn't recognize some jpeg formats In-Reply-To: <1478117178.16.0.265494893112.issue28591@psf.upfronthosting.co.za> Message-ID: <1478813727.07.0.654611597357.issue28591@psf.upfronthosting.co.za> Raul added the comment: Image used in the unit-tests of previous patch. Add it under Lib/test/imghdrdata/python1.jpg ---------- Added file: http://bugs.python.org/file45433/python1.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 16:37:41 2016 From: report at bugs.python.org (Raul) Date: Thu, 10 Nov 2016 21:37:41 +0000 Subject: [issue28591] imghdr doesn't recognize some jpeg formats In-Reply-To: <1478117178.16.0.265494893112.issue28591@psf.upfronthosting.co.za> Message-ID: <1478813861.5.0.821010209498.issue28591@psf.upfronthosting.co.za> Raul added the comment: The issue16512 don't solve the problem, note how the patch it provide fails to detect all the valid JPEG images attached in this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 16:50:19 2016 From: report at bugs.python.org (Carl Meyer) Date: Thu, 10 Nov 2016 21:50:19 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1478814619.47.0.0660407889892.issue21145@psf.upfronthosting.co.za> Carl Meyer added the comment: How do you propose that slots should be supported? Part of the value of cached_property is that cached access is a normal Python attribute access with no function call overhead. I am not interested in adding support for slots if it loses that benefit. I would not use such an implementation myself. I may be missing some option, but I can't see how to add slots support without losing that benefit, because it requires the ability to store an instance attribute under the same name as the descriptor, taking advantage of the fact that instance dict overrides a non-data descriptor. This implementation of cached_property has been in wide use in multiple very popular projects for many years. The fact that none of those implementations have ever needed to add slots support suggests that it isn't actually that important. If you have an idea for how to support slots without making cached_property less valuable for the common case, please share it and I am willing to implement it. Otherwise, I propose that this implementation which is already proved in wide usage should be added to the stdlib; I can add a documentation note that objects with slots are not supported. If there is demand for cached_property_with_slots, it can be added separately. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 16:59:14 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 10 Nov 2016 21:59:14 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1478815154.4.0.723462373042.issue28635@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I spotted a small typo in the "PEP 495: Local Time Disambiguation" section: "The values of the fold attribute have the value 0 all instances ..." should be "The values of the fold attribute have the value 0 *for* all instances ..." ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 18:05:04 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 10 Nov 2016 23:05:04 +0000 Subject: [issue28661] Fix code example in Python 3.5 telnetlib documentation In-Reply-To: <1478805391.59.0.11862034954.issue28661@psf.upfronthosting.co.za> Message-ID: <1478819104.14.0.122163731272.issue28661@psf.upfronthosting.co.za> R. David Murray added the comment: Well, the example code is correct for a typical telnet service running on a unix variant. That will output a space after the colon, so that the user's input is separated from the colon when they start to type. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 18:13:37 2016 From: report at bugs.python.org (Raul) Date: Thu, 10 Nov 2016 23:13:37 +0000 Subject: [issue28591] imghdr doesn't recognize some jpeg formats In-Reply-To: <1478117178.16.0.265494893112.issue28591@psf.upfronthosting.co.za> Message-ID: <1478819617.53.0.650321196292.issue28591@psf.upfronthosting.co.za> Raul added the comment: New patch for imghdr bug, including unittets. This patch works on python 2.7 ---------- Added file: http://bugs.python.org/file45434/imghdr_py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 18:17:51 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 10 Nov 2016 23:17:51 +0000 Subject: [issue28662] catch also PermissionError in tests when spawning a non existent program Message-ID: <1478819871.94.0.069145146671.issue28662@psf.upfronthosting.co.za> New submission from Xavier de Gaye: This is yet another idiosyncrasy of Android, the /sbin directory is in the $PATH of the adb shell used for running the tests on the emulator or on a device connected with usb to the build platform, and /sbin is readable and searchable only by root. For a plain user, the loop over exec_array[] in child_exec() at _posixsubprocess.c sets saved_errno to EACCES after failing to exec /sbin/some_non_existent_program. The patch fixes these failing tests on Android API 24: test_dtrace test_shutil test_subprocess. ---------- components: Tests files: catch_PermissionError.patch keywords: patch messages: 280551 nosy: xdegaye priority: normal severity: normal stage: patch review status: open title: catch also PermissionError in tests when spawning a non existent program type: behavior versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45435/catch_PermissionError.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 18:28:11 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 10 Nov 2016 23:28:11 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478820491.4.0.669105632628.issue28637@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh nice, python_startup benchmark at Nov 10 (rev at 8ebaa546a033) is now faster than python_startup at Feb 29 (rev dfeadfb4c8cc): new 16.8 ms, old 19.5. And it's much before when I opened the issue: 26.6 ms. Thanks. https://speed.python.org/timeline/#/?exe=4&ben=python_startup&env=1&revs=50&equid=off&quarts=on&extr=on The main difference is the removal of "import re" from Lib/site.py. If I added back "import re", python_startup comes back to 24.2 ms +- 0.0 ms. I understand that "import re" adds 7.4 ms. Any additional import has an important cost of python startup performance :-/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 18:43:16 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Nov 2016 23:43:16 +0000 Subject: [issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za> Message-ID: <20161110234313.13668.75470.BE080D50@psf.io> Roundup Robot added the comment: New changeset 137c7b92360e by Terry Jan Reedy in branch '2.7': Issue #25507: Add back import needed for 2.x encoding warning box. https://hg.python.org/cpython/rev/137c7b92360e ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 19:09:03 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Nov 2016 00:09:03 +0000 Subject: [issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za> Message-ID: <1478822943.82.0.695203001658.issue25507@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Import is only needed for the warning issued when someone using IDLE 2.x puts a non-ascii character into code being edited and tries to save without adding an encoding declaration. https://stackoverflow.com/questions/40523932/idle-2-7-11-12-nameerror-global-name-toplevel-is-not-defined ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 19:10:20 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Nov 2016 00:10:20 +0000 Subject: [issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za> Message-ID: <1478823020.41.0.89534212876.issue25507@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 19:55:13 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Nov 2016 00:55:13 +0000 Subject: [issue27854] Installed 2.7: IDLE Help disabled because help.html is missing In-Reply-To: <1472078066.3.0.116550230826.issue27854@psf.upfronthosting.co.za> Message-ID: <1478825713.82.0.784069206308.issue27854@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Does attached file look correct? ---------- keywords: +patch stage: -> commit review Added file: http://bugs.python.org/file45436/add_idle_help.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 20:14:23 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Nov 2016 01:14:23 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <20161111011420.11902.54930.0D1F573A@psf.io> Roundup Robot added the comment: New changeset 59b91b4e9506 by Victor Stinner in branch 'default': Issue #28618: Make hot functions using __attribute__((hot)) https://hg.python.org/cpython/rev/59b91b4e9506 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 20:30:55 2016 From: report at bugs.python.org (Andrew Kontokanis) Date: Fri, 11 Nov 2016 01:30:55 +0000 Subject: [issue28658] MacOsX idle don't run In-Reply-To: <1478788500.94.0.845802145571.issue28658@psf.upfronthosting.co.za> Message-ID: <1478827855.12.0.909999065262.issue28658@psf.upfronthosting.co.za> Changes by Andrew Kontokanis : ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 20:49:03 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 11 Nov 2016 01:49:03 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1478828943.79.0.566367046273.issue28618@psf.upfronthosting.co.za> STINNER Victor added the comment: I tried different patches and ran many quick & dirty benchmarks. I tried to use likely/unlikely macros (using GCC __builtin__expect): the effect is not significant on call_simple microbenchmark. I gave up on this part. __attribute__((hot)) on a few Python core functions fixes the major slowdown on call_method on the revision 83877018ef97 (described in the initial message). I noticed tiny differences when using __attribute__((hot)), speedup in most cases. I noticed sometimes slowdown, but very small (ex: 1%, but 1% on a microbenchmark doesn't mean anything). I pushed my patch to try to keep stable performance when Python is not compiled with PGO. If you would like to know more about the crazy effect of code placement in modern Intel CPUs, I suggest you to see the slides of this recent talk from an Intel engineer: https://llvmdevelopersmeetingbay2016.sched.org/event/8YzY/causes-of-performance-instability-due-to-code-placement-in-x86 "Causes of Performance Swings Due to Code Placement in IA by Zia Ansari (Intel), November 2016" -- About PGO or not PGO: this question is not simple, I suggest to discuss it in a different place to not flood this issue ;-) For my use case, I'm not convinced yet that PGO with our current build system produce reliable performance. Not all Linux distributions compile Python using PGO: Fedora and RHEL don't compile Python using PGO for example. Bugzilla for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=613045 I guess that there also some developers running benchmarks on Python compiled with "./configure && make". I'm trying to enhance documentation and tools around Python benchmarks to advice developers to use LTO and/or PGO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 21:43:18 2016 From: report at bugs.python.org (Ethan Furman) Date: Fri, 11 Nov 2016 02:43:18 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478832198.78.0.659884059657.issue28637@psf.upfronthosting.co.za> Ethan Furman added the comment: Leaving `re` out of site.py is fine; the current question is whether to add `enum` back to `re`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 21:46:44 2016 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 11 Nov 2016 02:46:44 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478832198.78.0.659884059657.issue28637@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I think it's okay to add `enum` back into `re`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 10 23:40:20 2016 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 11 Nov 2016 04:40:20 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1478839220.04.0.365328865304.issue28638@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'll echo Raymond's concerns here, as we simply don't have the collective maintenance capacity to sustain a plethora of special case micro-optimisations aimed at avoiding importing common standard library modules. I will note however, that there has been relatively little work done on optimising CPython's code generator, as the use of pyc files and the fact namedtuples are typically only defined at start-up already keeps it out of the critical path in most applications. While work invested there would technically still be a micro-optimisation at the language level, it would benefit more cases than just avoiding the use of namedtuple in functools would. Alternatively, rather than manually duplicating the namedtuple code and having to keep it in sync by hand, you could investigate the work Larry Hastings has already done for Argument Clinic in Python's C files: https://docs.python.org/3/howto/clinic.html Argument Clinic already includes the machinery necessary to assist with automated maintenance of generated code (at least in C), and hence could potentially be adapted to the task of "named tuple inlining". If Victor's AST transformation pipeline and function guard proposals in PEP's 511 and 510 are accepted at some point in the future, then such inlining could potentially even be performed implicitly some day. Caring about start-up performance is certainly a good thing, but when considering potential ways to improve the situation, structural enhancements to the underlying systems are preferable to ad hoc special cases that complicate future development efforts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 00:51:22 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 11 Nov 2016 05:51:22 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1478843482.45.0.580264916849.issue28638@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks Nick. I'm going to mark this as closed, as the proposal to microscopic to warrant incurring technical debt. If someone comes forward with more fully formed idea for code generation or overall structural enchancement, that can be put in another tracker item. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 00:52:41 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 11 Nov 2016 05:52:41 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1478843561.68.0.254957442577.issue21145@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 01:32:46 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 11 Nov 2016 06:32:46 +0000 Subject: [issue23839] Clear caches after every test In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za> Message-ID: <1478845966.4.0.0780586282657.issue23839@psf.upfronthosting.co.za> Raymond Hettinger added the comment: LGTM. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 01:34:37 2016 From: report at bugs.python.org (Ivan Tomilov) Date: Fri, 11 Nov 2016 06:34:37 +0000 Subject: [issue28661] Fix code example in Python 3.5 telnetlib documentation In-Reply-To: <1478819104.14.0.122163731272.issue28661@psf.upfronthosting.co.za> Message-ID: Ivan Tomilov added the comment: I see, thanks for the clarification. But in my OS X the things are different and I spent about 1 hour trying this code to take off. Maybe it's better to change this code to avoid spending time for such subtle bugs? Say: tn.read_until(b"Password:") tn.read_eager() Or just add a comment. It's confusing when one takes code from the official website and it doesn't work. What do you think? On 11 November 2016 at 02:05, R. David Murray wrote: > > R. David Murray added the comment: > > Well, the example code is correct for a typical telnet service running on > a unix variant. That will output a space after the colon, so that the > user's input is separated from the colon when they start to type. > > ---------- > nosy: +r.david.murray > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 01:41:47 2016 From: report at bugs.python.org (Ivan Pozdeev) Date: Fri, 11 Nov 2016 06:41:47 +0000 Subject: [issue26786] bdist_msi duplicates directories with names in ALL CAPS to a bogus location In-Reply-To: <1460844390.43.0.520967711704.issue26786@psf.upfronthosting.co.za> Message-ID: <1478846507.37.0.599579278351.issue26786@psf.upfronthosting.co.za> Changes by Ivan Pozdeev : Added file: http://bugs.python.org/file45437/bdist_msi.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 01:42:34 2016 From: report at bugs.python.org (Ivan Pozdeev) Date: Fri, 11 Nov 2016 06:42:34 +0000 Subject: [issue26786] bdist_msi duplicates directories with names in ALL CAPS to a bogus location In-Reply-To: <1460844390.43.0.520967711704.issue26786@psf.upfronthosting.co.za> Message-ID: <1478846554.83.0.957024138843.issue26786@psf.upfronthosting.co.za> Changes by Ivan Pozdeev : Removed file: http://bugs.python.org/file42496/bdist_msi.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 02:02:40 2016 From: report at bugs.python.org (Kuno Meyer) Date: Fri, 11 Nov 2016 07:02:40 +0000 Subject: [issue28654] sys.stdout.isatty() returns True even if redirected to NUL In-Reply-To: <1478765918.44.0.71383121228.issue28654@psf.upfronthosting.co.za> Message-ID: <1478847760.67.0.814646945577.issue28654@psf.upfronthosting.co.za> Kuno Meyer added the comment: 2) Yes, it should be `> /dev/null` instead of `> /dev/nul` (my bad). The output remains the same. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 02:26:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Nov 2016 07:26:34 +0000 Subject: [issue28662] catch also PermissionError in tests when spawning a non existent program In-Reply-To: <1478819871.94.0.069145146671.issue28662@psf.upfronthosting.co.za> Message-ID: <1478849194.34.0.972425260262.issue28662@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- assignee: -> xdegaye nosy: +serhiy.storchaka stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 03:33:53 2016 From: report at bugs.python.org (ProgVal) Date: Fri, 11 Nov 2016 08:33:53 +0000 Subject: [issue28663] Higher virtual memory usage on recent Linux versions Message-ID: <1478853233.74.0.582487882076.issue28663@psf.upfronthosting.co.za> New submission from ProgVal: Hi, I use `resource.setrlimit(resource.RLIMIT_DATA, ...)` to limit the memory usage of a child process. I noticed that on recent Linux versions, my processes are much more likely to raise MemoryError or behave inconsistently (which I believe is caused by a MemoryError being silently ignored somewhere). With Linux 4.7 under Python 3.4 (tested on a Debian 8.0 chroot) and 3.5 (tested on Debian Testing and Unstable), the attached script crashes on the `assert False`, which it should not encounter since all execution paths go through a `q.put`. With Linux 3.16 under Python 3.4 (tested on a Debian 8.0 virtual machine), the attached script terminates without an error. Even when restricting the memory to 1MB instead of 10MB, it still works. It may look like I just have to increase the limit to a larger value, eg. 20MB. However, when there is more imported modules in the parent process, the required value gets incredibly high (eg. 1GB). ---------- components: Interpreter Core files: rlimit_difference_linux_versions.py messages: 280566 nosy: Valentin.Lorentz priority: normal severity: normal status: open title: Higher virtual memory usage on recent Linux versions versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file45438/rlimit_difference_linux_versions.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 04:09:48 2016 From: report at bugs.python.org (Kubilay Kocak) Date: Fri, 11 Nov 2016 09:09:48 +0000 Subject: [issue27838] test_os.test_chown() failure on koobs-freebsd-current In-Reply-To: <1471959658.26.0.0626423066304.issue27838@psf.upfronthosting.co.za> Message-ID: <1478855388.2.0.941446449596.issue27838@psf.upfronthosting.co.za> Kubilay Kocak added the comment: It appears something has changed in the past few weeks (with no changes made to the buildbot worker). Now only 3.5 branch (both debug and non-debug) builders are failing, except there are now many failing tests, many different errors, and test clean is also failing. Among others errors: FileExistsError: [Errno 17] File exists: '@test_42517_tmp/TEST1/SUB1/SUB11' PermissionError: [Errno 1] Operation not permitted: '@test_42517_tmp' IsADirectoryError: [Errno 21] Is a directory: '@test_42517_tmp' PermissionError: [Errno 13] Permission denied: 'SUB21' Attached is the full log. Looking into some of the test_xxxxx_tmp directories referenced, I see a SUB21 directory created with no permissions [root at CURRENT-amd64:/usr/home/buildbot/python/3.5.koobs-freebsd-current/build/build/test_python_85793/@test_85793_tmp/TEST1/SUB2.new] ls -la total 5 drwx------ 3 buildbot buildbot 5 Nov 11 16:44 . drwx------ 3 buildbot buildbot 4 Nov 11 16:44 .. lrwx------ 1 buildbot buildbot 11 Nov 11 16:44 broken_link2 -> tmp3/broken lrwx------ 1 buildbot buildbot 103 Nov 11 16:44 link -> /usr/home/buildbot/python/3.5.koobs-freebsd-current/build/build/test_python_85793/@test_85793_tmp/TEST2 d--------- 2 buildbot buildbot 3 Nov 11 16:44 SUB21 This is observed across all test_python_xxxx directories: [root at CURRENT-amd64:/usr/home/buildbot/python/3.5.koobs-freebsd-current/build/build] find . -perm 000 ./test_python_85793/@test_85793_tmp/TEST1/SUB2.new/SUB21 ./test_python_96334/@test_96334_tmp/TEST1/SUB2.new/SUB21 ./test_python_53788/@test_53788_tmp/TEST1/SUB2.new/SUB21 ./test_python_56622/@test_56622_tmp/TEST1/SUB2.new/SUB21 ./test_python_38482/@test_38482_tmp/TEST1/SUB2.new/SUB21 ./test_python_58380/@test_58380_tmp/TEST1/SUB2.new/SUB21 ./test_python_42517/@test_42517_tmp/TEST1/SUB2.new/SUB21 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 04:10:13 2016 From: report at bugs.python.org (Kubilay Kocak) Date: Fri, 11 Nov 2016 09:10:13 +0000 Subject: [issue27838] test_os.test_chown() failure on koobs-freebsd-current In-Reply-To: <1471959658.26.0.0626423066304.issue27838@psf.upfronthosting.co.za> Message-ID: <1478855413.78.0.423134938285.issue27838@psf.upfronthosting.co.za> Changes by Kubilay Kocak : Added file: http://bugs.python.org/file45439/koobs-freebsd-current-python-3.5-debug-build-773.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 04:10:40 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 11 Nov 2016 09:10:40 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1478855440.76.0.0481264916652.issue28618@psf.upfronthosting.co.za> STINNER Victor added the comment: Final result on speed-python: haypo at speed-python$ python3 -m perf compare_to json_8nov/2016-11-10_15-39-default-8ebaa546a033.json 2016-11-11_02-13-default-59b91b4e9506.json -G Slower (12): - scimark_sparse_mat_mult: 8.71 ms +- 0.19 ms -> 9.28 ms +- 0.12 ms: 1.07x slower - nbody: 244 ms +- 2 ms -> 252 ms +- 4 ms: 1.03x slower - json_loads: 71.4 us +- 0.8 us -> 72.9 us +- 1.4 us: 1.02x slower - fannkuch: 1.07 sec +- 0.01 sec -> 1.09 sec +- 0.01 sec: 1.01x slower - scimark_lu: 502 ms +- 19 ms -> 509 ms +- 12 ms: 1.01x slower - chaos: 302 ms +- 3 ms -> 305 ms +- 3 ms: 1.01x slower - xml_etree_iterparse: 224 ms +- 3 ms -> 226 ms +- 6 ms: 1.01x slower - regex_dna: 299 ms +- 1 ms -> 300 ms +- 1 ms: 1.00x slower - pickle_list: 9.21 us +- 0.33 us -> 9.24 us +- 0.56 us: 1.00x slower - crypto_pyaes: 245 ms +- 1 ms -> 246 ms +- 2 ms: 1.00x slower - meteor_contest: 219 ms +- 1 ms -> 219 ms +- 1 ms: 1.00x slower - unpack_sequence: 128 ns +- 2 ns -> 128 ns +- 0 ns: 1.00x slower Faster (39): - logging_silent: 997 ns +- 40 ns -> 803 ns +- 13 ns: 1.24x faster - regex_effbot: 6.16 ms +- 0.24 ms -> 5.17 ms +- 0.27 ms: 1.19x faster - mako: 45.9 ms +- 0.7 ms -> 42.9 ms +- 0.6 ms: 1.07x faster - xml_etree_process: 253 ms +- 4 ms -> 237 ms +- 4 ms: 1.07x faster - call_simple: 13.9 ms +- 0.3 ms -> 13.1 ms +- 0.4 ms: 1.06x faster - spectral_norm: 274 ms +- 2 ms -> 260 ms +- 2 ms: 1.05x faster - xml_etree_generate: 300 ms +- 4 ms -> 285 ms +- 5 ms: 1.05x faster - call_method_slots: 17.1 ms +- 0.2 ms -> 16.2 ms +- 0.3 ms: 1.05x faster - telco: 21.8 ms +- 0.5 ms -> 20.7 ms +- 0.3 ms: 1.05x faster - call_method: 17.3 ms +- 0.3 ms -> 16.5 ms +- 0.2 ms: 1.05x faster - pickle_pure_python: 1.42 ms +- 0.02 ms -> 1.36 ms +- 0.03 ms: 1.04x faster - pathlib: 51.9 ms +- 0.8 ms -> 50.6 ms +- 0.4 ms: 1.03x faster - xml_etree_parse: 295 ms +- 8 ms -> 287 ms +- 7 ms: 1.03x faster - chameleon: 31.0 ms +- 0.3 ms -> 30.2 ms +- 0.2 ms: 1.03x faster - deltablue: 19.3 ms +- 0.3 ms -> 18.8 ms +- 0.2 ms: 1.02x faster - django_template: 484 ms +- 4 ms -> 472 ms +- 5 ms: 1.02x faster - call_method_unknown: 18.7 ms +- 0.2 ms -> 18.3 ms +- 0.2 ms: 1.02x faster - html5lib: 261 ms +- 6 ms -> 256 ms +- 6 ms: 1.02x faster - unpickle_pure_python: 973 us +- 12 us -> 954 us +- 15 us: 1.02x faster - regex_v8: 47.6 ms +- 0.8 ms -> 46.7 ms +- 0.4 ms: 1.02x faster - richards: 202 ms +- 4 ms -> 198 ms +- 5 ms: 1.02x faster - logging_simple: 37.8 us +- 0.6 us -> 37.1 us +- 0.4 us: 1.02x faster - sympy_integrate: 50.8 ms +- 0.9 ms -> 49.9 ms +- 1.4 ms: 1.02x faster - dulwich_log: 189 ms +- 2 ms -> 186 ms +- 1 ms: 1.02x faster - sqlalchemy_declarative: 343 ms +- 3 ms -> 339 ms +- 3 ms: 1.01x faster - hexiom: 25.0 ms +- 0.1 ms -> 24.7 ms +- 0.1 ms: 1.01x faster - logging_format: 44.6 us +- 0.6 us -> 44.1 us +- 0.6 us: 1.01x faster - 2to3: 787 ms +- 4 ms -> 777 ms +- 4 ms: 1.01x faster - tornado_http: 440 ms +- 4 ms -> 435 ms +- 4 ms: 1.01x faster - json_dumps: 30.7 ms +- 0.4 ms -> 30.5 ms +- 0.3 ms: 1.01x faster - go: 637 ms +- 10 ms -> 632 ms +- 8 ms: 1.01x faster - regex_compile: 397 ms +- 2 ms -> 394 ms +- 3 ms: 1.01x faster - nqueens: 266 ms +- 2 ms -> 264 ms +- 2 ms: 1.01x faster - python_startup: 16.8 ms +- 0.0 ms -> 16.7 ms +- 0.0 ms: 1.01x faster - python_startup_no_site: 9.91 ms +- 0.01 ms -> 9.86 ms +- 0.01 ms: 1.01x faster - scimark_sor: 513 ms +- 13 ms -> 510 ms +- 8 ms: 1.01x faster - raytrace: 1.41 sec +- 0.02 sec -> 1.40 sec +- 0.02 sec: 1.00x faster - genshi_text: 95.2 ms +- 1.1 ms -> 94.7 ms +- 0.8 ms: 1.00x faster - sympy_str: 529 ms +- 5 ms -> 528 ms +- 4 ms: 1.00x faster Benchmark hidden because not significant (13): float, genshi_xml, pickle, pickle_dict, pidigits, scimark_fft, scimark_monte_carlo, sqlalchemy_imperative, sqlite_synth, sympy_expand, sympy_sum, unpickle, unpickle_list ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 04:14:31 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 11 Nov 2016 09:14:31 +0000 Subject: [issue28664] test_bz2 fails with BrokenPipeError when bunzip2 is missing Message-ID: <1478855671.84.0.916406598974.issue28664@psf.upfronthosting.co.za> New submission from Xavier de Gaye: bunzip2 is missing on Android and the following tests of test_bz2 fail randomly: test_implicit_binary_modes, test_binary_modes and testAppend, with the following backtrace: ERROR: testAppend (test.test_bz2.BZ2FileTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sdcard/org.bitbucket.pyona/lib/python3.7/test/test_bz2.py", line 302, in testAppend self.assertEqual(self.decompress(f.read()), self.TEXT * 2) File "/sdcard/org.bitbucket.pyona/lib/python3.7/test/test_bz2.py", line 88, in decompress pop.stdin.close() BrokenPipeError: [Errno 32] Broken pipe Patch attached. ---------- components: Tests files: decompress.patch keywords: patch messages: 280569 nosy: nadeem.vawda, xdegaye priority: normal severity: normal stage: patch review status: open title: test_bz2 fails with BrokenPipeError when bunzip2 is missing type: behavior versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45440/decompress.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 04:19:07 2016 From: report at bugs.python.org (Kubilay Kocak) Date: Fri, 11 Nov 2016 09:19:07 +0000 Subject: [issue27838] test_os.test_chown() failure on koobs-freebsd-{current, 9} In-Reply-To: <1471959658.26.0.0626423066304.issue27838@psf.upfronthosting.co.za> Message-ID: <1478855947.09.0.626454921249.issue27838@psf.upfronthosting.co.za> Kubilay Kocak added the comment: I also note *one* failure on koobs-freebsd-9 on 3.x and 3.6 branches, identical errors: Nov 09 14:53 c27269c0d619... failure AMD64 FreeBSD 9.x 3.x #5304 Failed test Nov 09 14:53 b671ac7ae620... failure AMD64 FreeBSD 9.x 3.6 #282 Failed test ====================================================================== ERROR: test_chown (test.test_os.ChownFileTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/3.6.koobs-freebsd9/build/Lib/test/test_os.py", line 1200, in test_chown os.chown(support.TESTFN, uid, gid_1) PermissionError: [Errno 1] Operation not permitted: '@test_83654_tmp' ---------------------------------------------------------------------- ====================================================================== ERROR: test_chown (test.test_os.ChownFileTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_os.py", line 1200, in test_chown os.chown(support.TESTFN, uid, gid_1) PermissionError: [Errno 1] Operation not permitted: '@test_93884_tmp' ---------------------------------------------------------------------- I cannot explain what would cause persistent failure on one host and intermittent failure on another, except perhaps different host resources (cpu/mem) creating favourable conditions on one, but not the other. ---------- title: test_os.test_chown() failure on koobs-freebsd-current -> test_os.test_chown() failure on koobs-freebsd-{current,9} _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 04:49:20 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Nov 2016 09:49:20 +0000 Subject: [issue23839] Clear caches after every test In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za> Message-ID: <20161111094917.6983.30440.B8EBCE55@psf.io> Roundup Robot added the comment: New changeset bc81f2137706 by Serhiy Storchaka in branch '2.7': Issue #23839: Various caches now are cleared before running every test file. https://hg.python.org/cpython/rev/bc81f2137706 New changeset 89776a40e0ec by Serhiy Storchaka in branch '3.5': Issue #23839: Various caches now are cleared before running every test file. https://hg.python.org/cpython/rev/89776a40e0ec New changeset c89f213b21e8 by Serhiy Storchaka in branch '3.6': Issue #23839: Various caches now are cleared before running every test file. https://hg.python.org/cpython/rev/c89f213b21e8 New changeset 5d1067e89717 by Serhiy Storchaka in branch 'default': Issue #23839: Various caches now are cleared before running every test file. https://hg.python.org/cpython/rev/5d1067e89717 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 05:06:15 2016 From: report at bugs.python.org (ProgVal) Date: Fri, 11 Nov 2016 10:06:15 +0000 Subject: [issue28663] Higher virtual memory usage on recent Linux versions In-Reply-To: <1478853233.74.0.582487882076.issue28663@psf.upfronthosting.co.za> Message-ID: <1478858775.35.0.237971643939.issue28663@psf.upfronthosting.co.za> Changes by ProgVal : ---------- versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 05:12:27 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Nov 2016 10:12:27 +0000 Subject: [issue19398] test_trace fails with -S In-Reply-To: <1382730233.11.0.30990585871.issue19398@psf.upfronthosting.co.za> Message-ID: <20161111101224.11981.20283.80645DFA@psf.io> Roundup Robot added the comment: New changeset db220f2df5a9 by Serhiy Storchaka in branch '3.5': Issue #19398: Extra slash no longer added to sys.path components in case of https://hg.python.org/cpython/rev/db220f2df5a9 New changeset 1a88baaed7a0 by Serhiy Storchaka in branch '3.6': Issue #19398: Extra slash no longer added to sys.path components in case of https://hg.python.org/cpython/rev/1a88baaed7a0 New changeset 82607e7c24c7 by Serhiy Storchaka in branch 'default': Issue #19398: Extra slash no longer added to sys.path components in case of https://hg.python.org/cpython/rev/82607e7c24c7 New changeset 237ef36fb1bb by Serhiy Storchaka in branch '2.7': Issue #19398: Extra slash no longer added to sys.path components in case of https://hg.python.org/cpython/rev/237ef36fb1bb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 05:40:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Nov 2016 10:40:23 +0000 Subject: [issue28664] test_bz2 fails with BrokenPipeError when bunzip2 is missing In-Reply-To: <1478855671.84.0.916406598974.issue28664@psf.upfronthosting.co.za> Message-ID: <1478860823.88.0.689357563235.issue28664@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Wouldn't be better to check once the existence of the bunzip2 executable? Proposed patch also simplifies invocation of the bunzip2 command. ---------- nosy: +serhiy.storchaka versions: +Python 3.5 Added file: http://bugs.python.org/file45441/test_bz2-cmdline-bunzip2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 07:02:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Nov 2016 12:02:17 +0000 Subject: [issue19398] test_trace fails with -S In-Reply-To: <1382730233.11.0.30990585871.issue19398@psf.upfronthosting.co.za> Message-ID: <1478865737.47.0.81822885233.issue19398@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 07:10:41 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 11 Nov 2016 12:10:41 +0000 Subject: [issue28665] Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF Message-ID: <1478866241.77.0.0742898329944.issue28665@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The STORE_FAST, LOAD_FAST, and LOAD_DEREF opcodes all use fast macros for variable access. This patch harmonizes STORE_DEREF to follow the same pattern. Both the C code and the generated assembly look nicer. Gives an approx 40% speed-up (using both Clang and GCC-6) on the "store_nonlocal" portion of the variable access benchmark at http://code.activestate.com/recipes/577834 The eliminates the nonlocal speed penalty, making cell variable updates run nearly as fast as updates to locals. ---------- assignee: serhiy.storchaka components: Interpreter Core files: fastcell.diff keywords: patch messages: 280574 nosy: rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF type: performance versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45442/fastcell.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 07:12:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Nov 2016 12:12:35 +0000 Subject: [issue28666] Make test.support.rmtree() able to remove non-writable directories Message-ID: <1478866355.91.0.707083472132.issue28666@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Some tests create directories with disabled writing or even reading and listing. If them fail test.support.rmtree() can't remove such directories. This cause failures in other tests. Proposed patch makes test.support.rmtree() able to remove such directories. If some operation fails it try to change the mode of corresponding directory and repeat the try. ---------- components: Tests files: test-support-rmtree.patch keywords: patch messages: 280575 nosy: ezio.melotti, michael.foord, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Make test.support.rmtree() able to remove non-writable directories type: enhancement versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45443/test-support-rmtree.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 07:23:31 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Nov 2016 12:23:31 +0000 Subject: [issue28665] Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF In-Reply-To: <1478866241.77.0.0742898329944.issue28665@psf.upfronthosting.co.za> Message-ID: <1478867011.8.0.996159731032.issue28665@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. This saves function call and INCREF/DECREF pair. What about DELETE_DEREF? PyCell_Set() also is used in unicode_concatenate(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 07:32:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Nov 2016 12:32:24 +0000 Subject: [issue28665] Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF In-Reply-To: <1478866241.77.0.0742898329944.issue28665@psf.upfronthosting.co.za> Message-ID: <20161111123221.101999.13172.FF48624C@psf.io> Roundup Robot added the comment: New changeset d78d45436753 by Raymond Hettinger in branch '3.6': Issue #28665: Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF giving a 40% speedup. https://hg.python.org/cpython/rev/d78d45436753 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 07:33:20 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 11 Nov 2016 12:33:20 +0000 Subject: [issue28665] Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF In-Reply-To: <1478866241.77.0.0742898329944.issue28665@psf.upfronthosting.co.za> Message-ID: <1478867600.26.0.458359095665.issue28665@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks for the quick review. I'll look at the other two cases when I get a chance. ---------- assignee: serhiy.storchaka -> rhettinger priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 07:51:26 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Nov 2016 12:51:26 +0000 Subject: [issue23839] Clear caches after every test In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za> Message-ID: <1478868686.48.0.0267626707694.issue23839@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks for the review Raymond. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 08:18:42 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 11 Nov 2016 13:18:42 +0000 Subject: [issue24329] __qualname__ and __slots__ In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za> Message-ID: <1478870322.33.0.884676691053.issue24329@psf.upfronthosting.co.za> Xiang Zhang added the comment: v3 updates the test cases. ---------- Added file: http://bugs.python.org/file45444/slots_special_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 09:03:10 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Nov 2016 14:03:10 +0000 Subject: [issue28667] FD_SETSIZE is unsigned on FreeBSD Message-ID: <1478872990.6.0.256289601446.issue28667@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Seems FreeBSD is the only platforms with unsigned FD_SETSIZE. On NetBSD, Linux, and OpenBSD it is defined as just int. [1] This causes compiler warnings on FreeBSD. [2] Modules/selectmodule.c:72: warning: comparison between signed and unsigned Modules/selectmodule.c:112: warning: comparison between signed and unsigned Modules/selectmodule.c:123: warning: comparison between signed and unsigned Modules/ossaudiodev.c:476: warning: comparison between signed and unsigned Proposed patch silences warnings. [1] https://lists.freebsd.org/pipermail/freebsd-standards/2012-July/002410.html [2] http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.x/builds/5310/steps/compile/logs/warnings%20%2817%29 ---------- components: FreeBSD files: FD_SETSIZE.patch keywords: patch messages: 280581 nosy: koobs, serhiy.storchaka, skrah priority: normal severity: normal stage: patch review status: open title: FD_SETSIZE is unsigned on FreeBSD type: compile error versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45445/FD_SETSIZE.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 09:29:04 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 11 Nov 2016 14:29:04 +0000 Subject: [issue28664] test_bz2 fails with BrokenPipeError when bunzip2 is missing In-Reply-To: <1478855671.84.0.916406598974.issue28664@psf.upfronthosting.co.za> Message-ID: <1478874544.67.0.718707818224.issue28664@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Much better indeed :) With this patch, the test runs fine on Android. I left some minor comments on rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 09:32:11 2016 From: report at bugs.python.org (Steve Dower) Date: Fri, 11 Nov 2016 14:32:11 +0000 Subject: [issue27854] Installed 2.7: IDLE Help disabled because help.html is missing In-Reply-To: <1472078066.3.0.116550230826.issue27854@psf.upfronthosting.co.za> Message-ID: <1478874731.81.0.208891070094.issue27854@psf.upfronthosting.co.za> Steve Dower added the comment: I think so. I don't remember if anything else is needed to make it work. Were you able to test it? Or I'll give it a quick go on the build machine once you've committed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 09:50:40 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Nov 2016 14:50:40 +0000 Subject: [issue28665] Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF In-Reply-To: <1478866241.77.0.0742898329944.issue28665@psf.upfronthosting.co.za> Message-ID: <20161111145037.11902.81175.ABD8B9BD@psf.io> Roundup Robot added the comment: New changeset 7ec45e7d2194 by Serhiy Storchaka in branch 'default': Merge from 3.6 (issue #28665). https://hg.python.org/cpython/rev/7ec45e7d2194 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 09:51:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Nov 2016 14:51:32 +0000 Subject: [issue28665] Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF In-Reply-To: <1478866241.77.0.0742898329944.issue28665@psf.upfronthosting.co.za> Message-ID: <1478875892.97.0.613735432737.issue28665@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You forgot to merge and created new head. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 09:55:45 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 11 Nov 2016 14:55:45 +0000 Subject: [issue28661] Fix code example in Python 3.5 telnetlib documentation In-Reply-To: <1478805391.59.0.11862034954.issue28661@psf.upfronthosting.co.za> Message-ID: <1478876145.13.0.602332688515.issue28661@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. I'm surprised that OSX would be different. I didn't actually experiment to confirm it on linux, either. I could be taken as a "teaching opportunity" to talk about exact match vs read_eager, in a comment before or after the example, if someone wants to propose a doc patch. I'm not opposed to changing the example, but an explanation would probably be good either way. Maybe Jack will have an opinion. ---------- assignee: docs at python -> nosy: +jackdied versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 10:02:04 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Fri, 11 Nov 2016 15:02:04 +0000 Subject: [issue28644] Document recent changes in typing.py In-Reply-To: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za> Message-ID: <1478876524.27.0.427646989366.issue28644@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Guido, here is the new patch with your corrections. I have some questions in Rietveld, but those are about mypy, you could apply the patch now. ---------- Added file: http://bugs.python.org/file45446/recent-typing-docs-v5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 10:03:49 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Fri, 11 Nov 2016 15:03:49 +0000 Subject: [issue28644] Document recent changes in typing.py In-Reply-To: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za> Message-ID: <1478876629.88.0.205948466237.issue28644@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : Added file: http://bugs.python.org/file45447/recent-typing-docs-v6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 10:12:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Nov 2016 15:12:24 +0000 Subject: [issue28664] test_bz2 fails with BrokenPipeError when bunzip2 is missing In-Reply-To: <1478855671.84.0.916406598974.issue28664@psf.upfronthosting.co.za> Message-ID: <20161111151221.13772.84509.1EFA87C4@psf.io> Roundup Robot added the comment: New changeset 648cd8450f4f by Serhiy Storchaka in branch '3.5': Issue #28664: test_bz2 now works on non-Windows platforms without bunzip2 https://hg.python.org/cpython/rev/648cd8450f4f New changeset 9184f7f11b30 by Serhiy Storchaka in branch '3.6': Issue #28664: test_bz2 now works on non-Windows platforms without bunzip2 https://hg.python.org/cpython/rev/9184f7f11b30 New changeset 969e85a7a943 by Serhiy Storchaka in branch 'default': Issue #28664: test_bz2 now works on non-Windows platforms without bunzip2 https://hg.python.org/cpython/rev/969e85a7a943 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 10:48:00 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 11 Nov 2016 15:48:00 +0000 Subject: [issue28668] instanciation of multiprocessing.Queue raises ImportError in test_logging Message-ID: <1478879280.84.0.810360820826.issue28668@psf.upfronthosting.co.za> New submission from Xavier de Gaye: Occurs on Android that has a broken shared semaphore implementation (issue 26924). Patch attached. One of the backtraces: ====================================================================== ERROR: test_handle_called_with_mp_queue (test.test_logging.QueueListenerTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sdcard/org.bitbucket.pyona/lib/python3.7/multiprocessing/synchronize.py", line 29, in from _multiprocessing import SemLock, sem_unlink ImportError: cannot import name 'sem_unlink' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/sdcard/org.bitbucket.pyona/lib/python3.7/unittest/mock.py", line 1179, in patched return func(*args, **keywargs) File "/sdcard/org.bitbucket.pyona/lib/python3.7/test/test_logging.py", line 3130, in test_handle_c alled_with_mp_queue log_queue = multiprocessing.Queue() File "/sdcard/org.bitbucket.pyona/lib/python3.7/multiprocessing/context.py", line 102, in Queue return Queue(maxsize, ctx=self.get_context()) File "/sdcard/org.bitbucket.pyona/lib/python3.7/multiprocessing/queues.py", line 39, in __init__ from .synchronize import SEM_VALUE_MAX as maxsize File "/sdcard/org.bitbucket.pyona/lib/python3.7/multiprocessing/synchronize.py", line 34, in " function, see issue 3770.") ImportError: This platform lacks a functioning sem_open implementation, therefore, the required sync hronization primitives needed will not function, see issue 3770. ---------- components: Tests files: test__multiprocessing_queue.patch keywords: patch messages: 280589 nosy: vinay.sajip, xdegaye priority: normal severity: normal stage: patch review status: open title: instanciation of multiprocessing.Queue raises ImportError in test_logging type: behavior versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45448/test__multiprocessing_queue.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 11:03:07 2016 From: report at bugs.python.org (Honor) Date: Fri, 11 Nov 2016 16:03:07 +0000 Subject: [issue28669] Math Library Dos Attack Message-ID: New submission from Honor: Hello EveryOne, Payload : 12**62**6 Test script: import math math.log10(12**62**6) Program is looping. I tested apache server and flask web framework. Result: Frozen in frost. Cpu usage : %90-99 , system runs but server shutdowns. Author : Onur TA?LIO?LU ---------- messages: 280590 nosy: Stone priority: normal severity: normal status: open title: Math Library Dos Attack _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 11:08:03 2016 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 11 Nov 2016 16:08:03 +0000 Subject: [issue28669] Math Library Dos Attack In-Reply-To: Message-ID: <1478880483.35.0.140406293006.issue28669@psf.upfronthosting.co.za> Mark Dickinson added the comment: Please can you give more details about why you consider this a problem? Yes, some computations take a long time. I fail to see why this is an issue. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 11:13:45 2016 From: report at bugs.python.org (Honor) Date: Fri, 11 Nov 2016 16:13:45 +0000 Subject: [issue28669] Math Library Dos Attack In-Reply-To: <1478880483.35.0.140406293006.issue28669@psf.upfronthosting.co.za> Message-ID: Honor added the comment: Very very very long and the server unreachable all path. On Fri, Nov 11, 2016 at 7:08 PM, Mark Dickinson wrote: > > Mark Dickinson added the comment: > > Please can you give more details about why you consider this a problem? > > Yes, some computations take a long time. I fail to see why this is an > issue. > > ---------- > nosy: +mark.dickinson > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 11:16:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Nov 2016 16:16:17 +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: <1478880977.63.0.203500644321.issue28668@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The decorator doesn't need arguments. I would make it similar to skip_unless_symlink. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 11:18:06 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Nov 2016 16:18:06 +0000 Subject: [issue28664] test_bz2 fails with BrokenPipeError when bunzip2 is missing In-Reply-To: <1478855671.84.0.916406598974.issue28664@psf.upfronthosting.co.za> Message-ID: <1478881086.09.0.738517070865.issue28664@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 11:22:38 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 11 Nov 2016 16:22:38 +0000 Subject: [issue26929] android: test_strptime fails In-Reply-To: <1462284711.76.0.324696843297.issue26929@psf.upfronthosting.co.za> Message-ID: <1478881358.68.0.182535399419.issue26929@psf.upfronthosting.co.za> Xavier de Gaye added the comment: New patch following Serhiy comments. ---------- Added file: http://bugs.python.org/file45449/exclude_ymd_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 11:27:45 2016 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 11 Nov 2016 16:27:45 +0000 Subject: [issue28669] Math Library Dos Attack In-Reply-To: Message-ID: <1478881665.38.0.300123921781.issue28669@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks. The solution here is "Don't do that, then." That is, don't allow this code to execute on your server in the first place. At a guess, you've got a multithreaded server that's executing the given code on one thread, while continuing to listen for connections on another. Now the problem is not only that the power computation takes a long time, but also that the slow part all happens in a single bytecode instruction, so the GIL never gets released while the power operation is in progress, and no other threads can run. In theory it might be possible to rework the power operation to release the GIL now and then, but even if we did that there are plenty of other examples in the language that are going to have a similar effect (running for a long time without releasing the GIL). Changing all those isn't particularly practical. IOW, I'm afraid this isn't a problem with the core Python language; it's a problem with how you're using it: you want to think very carefully before allowing arbitrary untrusted code to execute on your server (if that's what you're doing), for reasons exactly like this one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 11:33:53 2016 From: report at bugs.python.org (Ned Deily) Date: Fri, 11 Nov 2016 16:33:53 +0000 Subject: [issue28658] MacOsX idle don't run In-Reply-To: <1478788500.94.0.845802145571.issue28658@psf.upfronthosting.co.za> Message-ID: <1478882033.89.0.237847326276.issue28658@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- assignee: -> terry.reedy components: +IDLE nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 11:40:12 2016 From: report at bugs.python.org (Honor) Date: Fri, 11 Nov 2016 16:40:12 +0000 Subject: [issue28669] Math Library Dos Attack In-Reply-To: <1478881665.38.0.300123921781.issue28669@psf.upfronthosting.co.za> Message-ID: Honor added the comment: I will take a video on this subject. Then I will say the end result. Thanks a lot. On Fri, Nov 11, 2016 at 7:27 PM, Mark Dickinson wrote: > > Mark Dickinson added the comment: > > Thanks. The solution here is "Don't do that, then." That is, don't allow > this code to execute on your server in the first place. > > At a guess, you've got a multithreaded server that's executing the given > code on one thread, while continuing to listen for connections on another. > Now the problem is not only that the power computation takes a long time, > but also that the slow part all happens in a single bytecode instruction, > so the GIL never gets released while the power operation is in progress, > and no other threads can run. > > In theory it might be possible to rework the power operation to release > the GIL now and then, but even if we did that there are plenty of other > examples in the language that are going to have a similar effect (running > for a long time without releasing the GIL). Changing all those isn't > particularly practical. > > IOW, I'm afraid this isn't a problem with the core Python language; it's a > problem with how you're using it: you want to think very carefully before > allowing arbitrary untrusted code to execute on your server (if that's what > you're doing), for reasons exactly like this one. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 11:55:50 2016 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 11 Nov 2016 16:55:50 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1478883350.84.0.801600523568.issue21145@psf.upfronthosting.co.za> Nick Coghlan added the comment: Carl's patch looks good to me, but my one request in relation to the __slots__ situation would be to give it a custom error message better indicating that lazy initialization of pre-assigned instance slots isn't supported. Currently that case just lets the underlying AttributeError escape, which is going to be thoroughly cryptic for folks that try it and may look like an accidental oversight rather than a deliberate design decision: >>> class NoDict: ... __slots__ = () ... >>> NoDict().__dict__ Traceback (most recent call last): File "", line 1, in AttributeError: 'NoDict' object has no attribute '__dict__' Suggested error message: TypeError: No '__dict__' attribute on 'objtype' instance to cache 'attrname' property. Essentially, this line: val = instance.__dict__[self.func.__name__] = self.func(instance) would become: attrname = self.func.__name__ try: cache = instance.__dict__ except AttributeError: msg = f"No '__dict__' attribute on {type(instance).__name__!r} instance to cache {attrname!r} property." raise TypeError(msg) from None val = cache[attrname] = self.func(instance) I believe a future C implementation could potentially be reworked to be __slots__ compatible, but I'd have to go read the source code to be sure, and I don't think that's necessary. Note: the class machinery itself already detects actual name conflicts between slot and method definitions: >>> class SlotConflict: ... __slots__ = ("attr") ... @property ... def attr(self): ... return 42 ... Traceback (most recent call last): File "", line 1, in ValueError: 'attr' in __slots__ conflicts with class variable The requested runtime check for the `__dict__` AttributeError covers the case where __slots__ is defined, and the cached property *isn't* listed as one of the instance attributes, but neither is __dict__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 12:03:25 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Nov 2016 17:03:25 +0000 Subject: [issue27854] Installed 2.7: IDLE Help disabled because help.html is missing In-Reply-To: <1472078066.3.0.116550230826.issue27854@psf.upfronthosting.co.za> Message-ID: <20161111170321.25122.59289.69A9765A@psf.io> Roundup Robot added the comment: New changeset 2776720f549c by Terry Jan Reedy in branch '2.7': Issue #27854: Include idlelib/help.html in 2.7 Windows installer. https://hg.python.org/cpython/rev/2776720f549c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 12:08:08 2016 From: report at bugs.python.org (Syed Suhail Ahmed) Date: Fri, 11 Nov 2016 17:08:08 +0000 Subject: [issue28569] mock.attach_mock should work with any return value of patch() In-Reply-To: <1477935134.31.0.733482108189.issue28569@psf.upfronthosting.co.za> Message-ID: <1478884088.82.0.173051232391.issue28569@psf.upfronthosting.co.za> Syed Suhail Ahmed added the comment: So from what I have understood, manager.attach_mock must raise an Exception when it is called with a wrong attribute, since the patch is called with autospec=True and you cannot call a mock with non existing attributes.Is that correct? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 12:08:24 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Nov 2016 17:08:24 +0000 Subject: [issue27854] Installed 2.7: IDLE Help disabled because help.html is missing In-Reply-To: <1472078066.3.0.116550230826.issue27854@psf.upfronthosting.co.za> Message-ID: <1478884104.87.0.462769603794.issue27854@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Done. I plan to test by downloading and installing the release candidate. If you can first test now, that would be great. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 12:09:08 2016 From: report at bugs.python.org (Carl Meyer) Date: Fri, 11 Nov 2016 17:09:08 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1478884148.31.0.591816804222.issue21145@psf.upfronthosting.co.za> Carl Meyer added the comment: Makes sense, Nick, thanks. The current error message for that situation is pretty cryptic indeed. I'll update the patch with your suggestion. Do you think a documentation note about slots is also warranted? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 12:45:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 11 Nov 2016 17:45:07 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1478886307.62.0.506447783012.issue21145@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Please no need to rush. We have 1.5 years to do this right. I believe supporting __slots__ is very important. But this is not easy task. Seems this requires C implementation. We should also design the behavior in case of setting or deleting cached property. How about just methods without arguments? Some APIs use methods without arguments instead of properties. Wouldn't be better to design a decorator that memoizes both properties and methods without arguments? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 13:50:42 2016 From: report at bugs.python.org (James Lu) Date: Fri, 11 Nov 2016 18:50:42 +0000 Subject: [issue28663] Higher virtual memory usage on recent Linux versions In-Reply-To: <1478853233.74.0.582487882076.issue28663@psf.upfronthosting.co.za> Message-ID: <1478890242.36.0.302169120679.issue28663@psf.upfronthosting.co.za> Changes by James Lu : ---------- nosy: +James Lu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 13:56:31 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Nov 2016 18:56:31 +0000 Subject: [issue28658] IDLE: catch user cfg file error and improve error message In-Reply-To: <1478788500.94.0.845802145571.issue28658@psf.upfronthosting.co.za> Message-ID: <1478890591.83.0.719293446954.issue28658@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The exception message says that your problem is a bad byte in one of the config files. The most likely culprit is the one you edited, which I presume is ~/.idlerc/config-highlight.cfg. "Invalid start byte' suggests that it tried to decode as utf-8, but you used a non-ascii char and saved with some other encoding. I suggest you stick with ascii only for theme names. The set of theme item names should match the all-ascii set used in idlelib/config-highlight.def. For future reference: a crash is a segfault or Mac equivalent, without a python traceback. Uploaded text files should be plain ascii or utf-8 text, uncompressed and not wrapped. "I have a problem. Help me" requests should normally go to python-list or other forums. The tracker is for bug reports and enhancement requests. In this case, I decided to make this a bug and enhancement issue and changed the title accordingly. The bug is that IDLE stopped instead of continuing without the user configuration, the same as it would if there were no file. I propose to catch the exception and replace the traceback with the file name and error (the enhancement). At least for user config files, IDLE should then continue (the bugfix). The revised message will be something like the following. "Unable to read .../.idlerc/config-highlight.cfg. UnicodeDecodeError: ... IDLE will continue without this user config file." ---------- stage: -> test needed title: MacOsX idle don't run -> IDLE: catch user cfg file error and improve error message type: crash -> behavior versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 14:00:55 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 11 Nov 2016 19:00:55 +0000 Subject: [issue28669] Math Library Dos Attack In-Reply-To: Message-ID: <1478890855.76.0.815983046609.issue28669@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think this should be marked as "not a bug" as closed. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 14:36:49 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 11 Nov 2016 19:36:49 +0000 Subject: [issue28669] Math Library Dos Attack In-Reply-To: Message-ID: <1478893009.68.0.683839840384.issue28669@psf.upfronthosting.co.za> STINNER Victor added the comment: > Very very very long and the server unreachable all path. If a server wants to allow users to run arbitrary code, a sandbox protecting the server must be used: limit CPU usage, limit total duration (time), etc. "while 1: pass" is another simple snippet to eat server resources. I agree, it's not a bug, it's a feature. ---------- nosy: +haypo resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 14:52:54 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 11 Nov 2016 19:52:54 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1478893974.16.0.589800273572.issue28618@psf.upfronthosting.co.za> STINNER Victor added the comment: > - json_loads: 71.4 us +- 0.8 us -> 72.9 us +- 1.4 us: 1.02x slower Hum, sadly this benchmark is still unstable after my change 59b91b4e9506 ("Mark hot functions using __attribute__((hot))", oops, I wanted to write Mark, not Make :-/). This benchmark is around 63.4 us during many months, whereas it reached 72.9 us at rev 59b91b4e9506, and the new run (also using hot attribute) gone back to 63.0 us... I understand that json_loads depends on the code placement of some other functions which are not currently marked with the hot attribute. https://speed.python.org/timeline/#/?exe=4&ben=json_loads&env=1&revs=50&equid=off&quarts=on&extr=on ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 14:58:32 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 11 Nov 2016 19:58:32 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1478894312.94.0.227038915594.issue28618@psf.upfronthosting.co.za> STINNER Victor added the comment: > - scimark_sparse_mat_mult: 8.71 ms +- 0.19 ms -> 9.28 ms +- 0.12 ms: 1.07x slower Same issue on this benchmark: * average on one year: 8.8 ms * peak at rev 59b91b4e9506: 9.3 ms * run after rev 59b91b4e9506: 9.0 ms The benchmark is unstable, but the difference is small, especially compared to the difference of call_method without the hot attribute. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 15:01:41 2016 From: report at bugs.python.org (Davin Potts) Date: Fri, 11 Nov 2016 20:01:41 +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: <1478894501.87.0.74570425521.issue28668@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 15:01:47 2016 From: report at bugs.python.org (Davin Potts) Date: Fri, 11 Nov 2016 20:01:47 +0000 Subject: [issue26924] android: test_concurrent_futures fails In-Reply-To: <1462282676.16.0.612748828.issue26924@psf.upfronthosting.co.za> Message-ID: <1478894507.85.0.893913341262.issue26924@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 15:18:43 2016 From: report at bugs.python.org (Carl Meyer) Date: Fri, 11 Nov 2016 20:18:43 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1478895523.04.0.0748864225458.issue21145@psf.upfronthosting.co.za> Changes by Carl Meyer : Added file: http://bugs.python.org/file45450/cached_property.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 15:25:31 2016 From: report at bugs.python.org (Carl Meyer) Date: Fri, 11 Nov 2016 20:25:31 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1478895931.42.0.893669835632.issue21145@psf.upfronthosting.co.za> Carl Meyer added the comment: Uploaded a patch updated per Nick's comment. Not opposed to waiting to see if someone is motivated to implement a version in C that supports __slots__, but if that doesn't happen by the Python 3.7 feature deadline, I don't think it should block this proven version. It also occurred to me that we could probably support __slots__ in pure Python without harming the non-slots case by implementing a fallback cache in the descriptor itself, keyed by instance in a WeakKeyDictionary. I don't love having the behavior differ so much between the slots and non-slots case, but maybe it's better than not supporting slots at all. Re setting and deleting: under the current patch, if you set or delete a cached property, you set or delete the cached value. I think this is fine and useful behavior, but it could perhaps be added explicitly to the documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 15:26:16 2016 From: report at bugs.python.org (Carl Meyer) Date: Fri, 11 Nov 2016 20:26:16 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1478895976.2.0.716039338411.issue21145@psf.upfronthosting.co.za> Carl Meyer added the comment: (We wouldn't be able to match the set/delete behavior in a slots-supporting fallback implemented in Python.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 15:28:39 2016 From: report at bugs.python.org (Daniel Greenfeld) Date: Fri, 11 Nov 2016 20:28:39 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1478896119.47.0.197185379063.issue21145@psf.upfronthosting.co.za> Daniel Greenfeld added the comment: I'm delighted to see a patch submitted, but I'm concerned that it isn't thread safe. This was implemented in the cached-property package I maintain: * https://github.com/pydanny/cached-property/issues/6 * https://github.com/pydanny/cached-property/pull/9 * https://github.com/pydanny/cached-property#working-with-threads ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 15:56:12 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Nov 2016 20:56:12 +0000 Subject: [issue28658] IDLE: catch user cfg file error and improve error message In-Reply-To: <1478788500.94.0.845802145571.issue28658@psf.upfronthosting.co.za> Message-ID: <1478897772.84.0.433232545691.issue28658@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This is effectively a duplicate of #21973. In both issues, an error in the file causes an exception that is not caught, but should be. ---------- resolution: -> duplicate stage: test needed -> resolved status: open -> closed superseder: -> Idle should not quit on corrupted user config files _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 16:17:40 2016 From: report at bugs.python.org (Lee Garrett) Date: Fri, 11 Nov 2016 21:17:40 +0000 Subject: [issue27542] Segfault in gcmodule.c:360 visit_decref In-Reply-To: <1468755086.8.0.27245311458.issue27542@psf.upfronthosting.co.za> Message-ID: <1478899060.8.0.0746984392227.issue27542@psf.upfronthosting.co.za> Lee Garrett added the comment: In case someone reaches this bug report via search engine: apt-get remove python-cffi-backend fixed this problem for me. ---------- nosy: +lgarrett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 16:18:32 2016 From: report at bugs.python.org (Michael Witten) Date: Fri, 11 Nov 2016 21:18:32 +0000 Subject: [issue28670] PEP 235: Implement on every POSIX system, and clean up the C code for `import' Message-ID: <1478899111.69.0.0154952768919.issue28670@psf.upfronthosting.co.za> New submission from Michael Witten: The attached file, `pep-235-on-posix.export', contains 3 patches; the file includes the intended commit messages and authorship information. To apply these patches, save the file to: /path/to/pep-235-on-posix.export and then run the following from within your Mercurial repository: hg import /path/to/pep-235-on-posix.export I ran `make test' or `./python -m test.regrtest' multiple times, and all but one attempt succeeded: There was a transient and probably unrelated error that occured whilst running `test_thread'. Only the initial patch alters functionality; the other patches, though structurally useful, are a matter of essentially opportunistic aesthetic reconstruction. Here is the commit message of the initial patch (the formatting of which may be mangled here): ----8<------8<------8<------8<---- PEP 235: Extend to every POSIX system the case-sensitivity semantics for `import' (Note: As per PEP 235, this explicit checking of case may be effectively disabled by defining the environment variable `PYTHONCASEOK'.) >From time to time, even a user of a sane system has been known [to be forced] to use an insane file system; the semantics of PEP 235 need to be implemented in this case as well. On a sane system, mount an insane file system at "$mount", and then run this example: $ cd "$mount" $ touch Insane.py $ python -c 'import Insane; import insane; print(dir())' Before this revision, the resulting output is: ['Insane', '__builtins__', '__doc__', '__name__', '__package__', 'insane'] After this commit, the resulting output is sane: Traceback (most recent call last): File "", line 1, in ImportError: No module named insane Because POSIX systems may be a subset of sane systems, this is only a partial fix to the overall problem; as much as possible, *every* system should implement the same semantics. ----8<------8<------8<------8<---- The one irritation of this patch is that it arguably adds overhead to "sane" systems, which will almost never run into this corner case. However, there are at least 4 replies to this criticism: 1) As per PEP 235, the overhead can be virtually removed by setting the `PYTHONCASEOK' environment variable. 2) It's probably most important for Python to present consistent behavior across systems; if one needs every cycle, then one can hack the source for oneself (and if imports are a major bottleneck for some program, then there is probably something seriously wrong with the design of that program, anyway). 3) Ultimately, I can say that while working on a supposedly sane system, I *did* run into this corner case: The program I was trying to run was located on an HFS+ file system; I didn't even know that this program employed Python for one of its components, but it failed with strange, nearly inscrutable errors, which turned out to be the result of the sane system's `python' knowing nothing about PEP 235. Once fixed, that program ran without any problems; the sole pain in the arse was `python'. 4) Come on! Come on, man! Come on; I did a good job here. Come on! As an aside, I believe that Python 3 is not affected by this problem. ---------- components: Interpreter Core files: pep-235-on-posix.export messages: 280613 nosy: brett.cannon, eric.snow, mfwitten, ncoghlan, tim.peters priority: normal severity: normal status: open title: PEP 235: Implement on every POSIX system, and clean up the C code for `import' type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file45451/pep-235-on-posix.export _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 16:26:49 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Nov 2016 21:26:49 +0000 Subject: [issue21973] IDLE: catch user cfg file error, better error message, continue In-Reply-To: <1405252905.33.0.296703763462.issue21973@psf.upfronthosting.co.za> Message-ID: <1478899609.01.0.46756924707.issue21973@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I closed #28658 in favor of this. For that issue, the exception was a UnicodeDecodeError instead of a configparser.Error. Both should be caught. Ingrid, sorry I never got back to this. A few months ago, Serhiy wrote a warning function for the config(Handler) function that was included in a larger patch for the module. I wrote a test_config that test both the warning function and the other new code. This was for 3.6 only. I am going to patch the lowest level IDLE function, IDLEConfigParser.Load, which currently calls ConfigParser.read, and catch exceptions and call the warning function right there. For 2.7 and 3.5, I will make a minimal change, and test by hand (by editing errors into one of my user config files). For 3.6/7, I will try replacing .read (which reads a list of files) with .read_file (which reads one file). ---------- assignee: -> terry.reedy title: Idle should not quit on corrupted user config files -> IDLE: catch user cfg file error, better error message, continue versions: +Python 3.6, Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 16:52:12 2016 From: report at bugs.python.org (Carl Meyer) Date: Fri, 11 Nov 2016 21:52:12 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1478901132.36.0.308733133386.issue21145@psf.upfronthosting.co.za> Carl Meyer added the comment: Thanks, Danny. Uploaded a version of the patch that adds thread-safety (with a test). Unlike in your lib, I didn't make it a separate version of the decorator; since the lock is not checked on cached access, its slight overhead on the initial computation is probably not an issue, likely outweighed by the cost of the computation itself. If someone decides to pursue a C version with slots support, hopefully at least these tests are still useful :-) ---------- Added file: http://bugs.python.org/file45452/cached_property.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 16:53:41 2016 From: report at bugs.python.org (Carl Meyer) Date: Fri, 11 Nov 2016 21:53:41 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1478901221.07.0.985657653217.issue21145@psf.upfronthosting.co.za> Carl Meyer added the comment: Speaking of this hypothetical C version, what's the current policy on shipping stdlib C code that can't be emulated in pure Python? (I'm thinking of e.g. PyPy). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 17:04:05 2016 From: report at bugs.python.org (Michael Witten) Date: Fri, 11 Nov 2016 22:04:05 +0000 Subject: [issue28670] PEP 235: Implement on every POSIX system, and clean up the C code for `import' In-Reply-To: <1478899111.69.0.0154952768919.issue28670@psf.upfronthosting.co.za> Message-ID: <1478901845.86.0.0309483701688.issue28670@psf.upfronthosting.co.za> Michael Witten added the comment: I've attached as `pep-235-on-posix.patch' a copy of `pep-235-on-posix.export', in order to see whether that helps the system recognize the content as a patch. I'm loath to rename the original upload, because I'm not able to edit my original comment to reflect a new name. ---------- keywords: +patch Added file: http://bugs.python.org/file45453/pep-235-on-posix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 17:16:47 2016 From: report at bugs.python.org (Andrey Fedorov) Date: Fri, 11 Nov 2016 22:16:47 +0000 Subject: [issue28569] mock.attach_mock should work with any return value of patch() In-Reply-To: <1478884088.82.0.173051232391.issue28569@psf.upfronthosting.co.za> Message-ID: Andrey Fedorov added the comment: There's some vagueness on how this is implemented, but I would prefer manager.attach_mock to also work with whatever the return value of patch() is. On Fri, Nov 11, 2016 at 12:08 PM, Syed Suhail Ahmed wrote: > > Syed Suhail Ahmed added the comment: > > So from what I have understood, manager.attach_mock must raise an > Exception when it is called with a wrong attribute, since the patch is > called with autospec=True and you cannot call a mock with non existing > attributes.Is that correct? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 17:27:20 2016 From: report at bugs.python.org (Andrew Kontokanis) Date: Fri, 11 Nov 2016 22:27:20 +0000 Subject: [issue28658] IDLE: catch user cfg file error and improve error message In-Reply-To: <1478788500.94.0.845802145571.issue28658@psf.upfronthosting.co.za> Message-ID: <1478903240.87.0.965216614222.issue28658@psf.upfronthosting.co.za> Andrew Kontokanis added the comment: Thank you very much. The actual problem was that on copy paste it made an alias and not a real copy of the file that you mentioned. So It really helped me to solve the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 18:30:24 2016 From: report at bugs.python.org (Kevin Chen) Date: Fri, 11 Nov 2016 23:30:24 +0000 Subject: [issue28671] SSL server requesting client certificates should send CA list Message-ID: <1478907024.8.0.970370695387.issue28671@psf.upfronthosting.co.za> New submission from Kevin Chen: When a Python HTTPS server requests client certificates, it should send a CA list so the client knows which certificates are acceptable. It looks like right now Python calls SSL_CTX_load_verify_locations, so once the client certificate is sent, Python can verify whether the client against the specify CAs. However, it looks like Python should also call SSL_CTX_set_client_CA_list so the client knows which certificates to send. ---------- assignee: christian.heimes components: SSL messages: 280620 nosy: christian.heimes, kchen priority: normal severity: normal status: open title: SSL server requesting client certificates should send CA list type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 18:45:53 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Nov 2016 23:45:53 +0000 Subject: [issue28614] Slice limit documentation could be interpreted in Python 2. In-Reply-To: <1478286284.13.0.895417928613.issue28614@psf.upfronthosting.co.za> Message-ID: <1478907953.94.0.157081699576.issue28614@psf.upfronthosting.co.za> Terry J. Reedy added the comment: n < (j-i)/k is a straightforward translation of i + n*k < j, and vice verse, where / is rational division. It is incorrect to integerize the result and the doc does not say to do so. In Python 3, there is no ambiguity, and the doc is *not* incorrect, and does not need to be changed. In Python 2, I think it still clear enough, but we could add "(where / indicates rational division)'. However, I also think this might be too nitpicky. I am inclined to think that this should be closed. ---------- nosy: +terry.reedy title: Slice limit documentation is incorrect -> Slice limit documentation could be interpreted in Python 2. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 18:57:58 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Nov 2016 23:57:58 +0000 Subject: [issue28615] Document clarification: Section 5.4 Complex Number In-Reply-To: <1478286572.26.0.816720776987.issue28615@psf.upfronthosting.co.za> Message-ID: <1478908678.94.0.657818965987.issue28615@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I don't like the term 'imaginary number' but the usage is standard, and python does not have 'complex literals' (I checked 2.7 chapter 2 on number literals). So I will apply this. ---------- assignee: docs at python -> terry.reedy nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 18:58:07 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Nov 2016 23:58:07 +0000 Subject: [issue28615] Document clarification: Section 5.4 Complex Number In-Reply-To: <1478286572.26.0.816720776987.issue28615@psf.upfronthosting.co.za> Message-ID: <1478908687.98.0.0444512966774.issue28615@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 18:58:39 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Nov 2016 23:58:39 +0000 Subject: [issue28644] Document recent changes in typing.py In-Reply-To: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za> Message-ID: <20161111235836.5016.81043.1552344B@psf.io> Roundup Robot added the comment: New changeset 5bf2ea0d3830 by Guido van Rossum in branch '3.5': Issue 28644: Document recent changes in typing.py (Ivan L) https://hg.python.org/cpython/rev/5bf2ea0d3830 New changeset 72a2c90abdec by Guido van Rossum in branch '3.6': Issue 28644: Document recent changes in typing.py (Ivan L) (3.5->3.6) https://hg.python.org/cpython/rev/72a2c90abdec New changeset c4394da344b7 by Guido van Rossum in branch 'default': Issue 28644: Document recent changes in typing.py (Ivan L) (3.6->3.7) https://hg.python.org/cpython/rev/c4394da344b7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 18:59:06 2016 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 11 Nov 2016 23:59:06 +0000 Subject: [issue28644] Document recent changes in typing.py In-Reply-To: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za> Message-ID: <1478908746.88.0.608168619698.issue28644@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 19:10:04 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Nov 2016 00:10:04 +0000 Subject: [issue28615] Document clarification: Section 5.4 Complex Number In-Reply-To: <1478286572.26.0.816720776987.issue28615@psf.upfronthosting.co.za> Message-ID: <20161112001001.60889.25367.A61BD338@psf.io> Roundup Robot added the comment: New changeset f8d12cb7d0fd by Terry Jan Reedy in branch '2.7': Issue #28615: Backport imaginary/complex number text from 3.x. https://hg.python.org/cpython/rev/f8d12cb7d0fd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 19:10:41 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Nov 2016 00:10:41 +0000 Subject: [issue28615] Document clarification: Section 5.4 Complex Number In-Reply-To: <1478286572.26.0.816720776987.issue28615@psf.upfronthosting.co.za> Message-ID: <1478909441.0.0.0706953914031.issue28615@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 19:45:55 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Nov 2016 00:45:55 +0000 Subject: [issue28617] Why isn't "in" called a comparison operation? In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za> Message-ID: <1478911555.24.0.75307751299.issue28617@psf.upfronthosting.co.za> Terry J. Reedy added the comment: "Two more operations with the same syntactic priority, in and not in, are supported ..." could be changed to The containment tests in and not in have the same priority as comparisons and are supported ..." ---------- nosy: +terry.reedy stage: -> commit review versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 20:00:03 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Nov 2016 01:00:03 +0000 Subject: [issue28614] Slice limit documentation could be misinterpreted in Python 2. In-Reply-To: <1478286284.13.0.895417928613.issue28614@psf.upfronthosting.co.za> Message-ID: <1478912403.39.0.841335284495.issue28614@psf.upfronthosting.co.za> Terry J. Reedy added the comment: n < (j-i)/k is a straightforward translation of i + n*k < j, and vice verse, where / is rational division. It is incorrect to integerize the result and the doc does not say to do so. In Python 3, there is no ambiguity, and the doc is *not* incorrect, and does not need to be changed. In Python 2, I think it still clear enough, but we could add "(where / indicates rational division)'. However, I also think this might be too nitpicky. I am inclined to think that this should be closed. ---------- title: Slice limit documentation could be interpreted in Python 2. -> Slice limit documentation could be misinterpreted in Python 2. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 20:00:22 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Nov 2016 01:00:22 +0000 Subject: [issue28614] Slice limit documentation could be misinterpreted in Python 2. In-Reply-To: <1478286284.13.0.895417928613.issue28614@psf.upfronthosting.co.za> Message-ID: <1478912422.52.0.0591508264789.issue28614@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- Removed message: http://bugs.python.org/msg280626 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 20:12:00 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Nov 2016 01:12:00 +0000 Subject: [issue28632] configparser does not close files in read In-Reply-To: <1478537342.33.0.595722710962.issue28632@psf.upfronthosting.co.za> Message-ID: <1478913120.57.0.987697157001.issue28632@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Given that the open is context managed with open(filename, encoding=encoding) as fp: self._read(fp, filename) how could fp not be closed? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 22:22:53 2016 From: report at bugs.python.org (Andrey Fedorov) Date: Sat, 12 Nov 2016 03:22:53 +0000 Subject: [issue28569] mock.attach_mock should work with any return value of patch() In-Reply-To: Message-ID: Andrey Fedorov added the comment: To clarify, this is how I would expect these two functions to work together "out of the box" patches = { 'requests_get': 'requests.get', ... } root_mock = mock.Mock() for name, path in patches.items(): m = mock.patch(path, auto_spec=True) root_mock.attach_mock(m, name) This works when `path` is referring to a class, and it would be great if it also worked with functions like `requests.get`, as well. On Fri, Nov 11, 2016 at 5:16 PM, Andrey Fedorov wrote: > There's some vagueness on how this is implemented, but I would prefer > manager.attach_mock to also work with whatever the return value of patch() > is. > > On Fri, Nov 11, 2016 at 12:08 PM, Syed Suhail Ahmed < > report at bugs.python.org> wrote: > >> >> Syed Suhail Ahmed added the comment: >> >> So from what I have understood, manager.attach_mock must raise an >> Exception when it is called with a wrong attribute, since the patch is >> called with autospec=True and you cannot call a mock with non existing >> attributes.Is that correct? >> >> ---------- >> >> _______________________________________ >> Python tracker >> >> _______________________________________ >> > > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 23:33:07 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Nov 2016 04:33:07 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478925187.04.0.0904040727692.issue28637@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Serhiy, thanks for your work. By isolating the few easily rewritten lines in site.py, you saved us from endless contortions trying to avoid using our own batteries. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 23:33:58 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Nov 2016 04:33:58 +0000 Subject: [issue28665] Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF In-Reply-To: <1478866241.77.0.0742898329944.issue28665@psf.upfronthosting.co.za> Message-ID: <1478925238.69.0.708732621014.issue28665@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file45454/delete_deref.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 11 23:34:37 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Nov 2016 04:34:37 +0000 Subject: [issue28665] Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF In-Reply-To: <1478866241.77.0.0742898329944.issue28665@psf.upfronthosting.co.za> Message-ID: <1478925277.07.0.000254946010037.issue28665@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> serhiy.storchaka Added file: http://bugs.python.org/file45455/concat_deref.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 00:15:28 2016 From: report at bugs.python.org (Kubilay Kocak) Date: Sat, 12 Nov 2016 05:15:28 +0000 Subject: [issue28032] --with-lto builds segfault in many situations In-Reply-To: <1473370352.47.0.536997029042.issue28032@psf.upfronthosting.co.za> Message-ID: <1478927728.89.0.276868904691.issue28032@psf.upfronthosting.co.za> Kubilay Kocak added the comment: Could we please: a) Rename 'optimizations' to 'pgo' or 'profiled' b) Use enable/disable instead of with/without. The former is used for toggling program features, the latter is used for external dependencies [1][2][3] Yes Python's configure / autofoo isn't the paragon of conventions, consistency or elegance, but it would be fantastic to make the job of bringing it to (or arguing for) a more standards-oriented state moving forward easier rather than harder. [1] https://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node/Package-Options.html [2] https://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node/External-Software.html [3] https://autotools.io/autoconf/arguments.html ---------- nosy: +koobs resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 00:16:32 2016 From: report at bugs.python.org (Kubilay Kocak) Date: Sat, 12 Nov 2016 05:16:32 +0000 Subject: [issue28032] --with-lto builds segfault in many situations In-Reply-To: <1473370352.47.0.536997029042.issue28032@psf.upfronthosting.co.za> Message-ID: <1478927792.97.0.7457259857.issue28032@psf.upfronthosting.co.za> Kubilay Kocak added the comment: I also invoke PEP20 (explicit > implicit) in favour of renaming the option :] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 00:44:52 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Nov 2016 05:44:52 +0000 Subject: [issue28614] Slice limit documentation could be misinterpreted in Python 2. In-Reply-To: <1478286284.13.0.895417928613.issue28614@psf.upfronthosting.co.za> Message-ID: <1478929492.38.0.498840034945.issue28614@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > I am inclined to think that this should be closed. I concur. The problem with the nitpick and word-smithing is that over-explaining tends to make the docs harder to read and understand by getting in the way of the basic message. Given that this passage has worked well enough for users for a very long time, it is likely best to leave in alone. ---------- nosy: +rhettinger resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 00:50:12 2016 From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Sebasti=C3=A3o_de_Oliveira_Bueno?=) Date: Sat, 12 Nov 2016 05:50:12 +0000 Subject: [issue28672] Explain in the "Data Model" document why arguments to __init__ are ok when __new__ is not defined Message-ID: <1478929812.24.0.930722962265.issue28672@psf.upfronthosting.co.za> New submission from Jo?o Sebasti?o de Oliveira Bueno: There is an specific Python behavior on object instantiation that is "expected" but not explicit, even for avanced users: When a custom class defines `__init__` with extra parameters, but do not overrides `__new__`, it simply works. But if `__new__`is defined it has to match `__init__`s signature. This behavior is not documented anywhere. I could found this issue was discussed in this thread earlier this year, starting with this e-mail: https://mail.python.org/pipermail/python-list/2016-March/704013.html I propose the following paragraph from a follow up e-mail by "eryksun at gmail.com" to be added to the description of "__new__" in the Data Model documentation page: """ [The implementation] knows whether a type overrides the __new__ or __init__ methods. You're expected to consume additional arguments in this case. However, excess arguments are ignored in object.__new__ if a type overrides __init__ without overriding __new__ (i.e. your second example). Excess arguments are also ignored in object.__init__ if a type overrides __new__ without overriding __init__. """ (Source: https://mail.python.org/pipermail/python-list/2016-March/704024.html) ---------- assignee: docs at python components: Documentation messages: 280633 nosy: Jo?o.Sebasti?o.de.Oliveira.Bueno, docs at python priority: normal severity: normal status: open title: Explain in the "Data Model" document why arguments to __init__ are ok when __new__ is not defined type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 01:00:57 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Nov 2016 06:00:57 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <1478930457.61.0.387270784664.issue28587@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This patch looks very good and I especially like the example. One nit. It may be insufficient to say that the start/end arguments are interpreted the same as the slice notation. While that clear indicates the range being searched, it is silent on whether the index result is relative to index zero or relative to the start argument. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 02:03:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Nov 2016 07:03:24 +0000 Subject: [issue28665] Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF In-Reply-To: <1478866241.77.0.0742898329944.issue28665@psf.upfronthosting.co.za> Message-ID: <1478934204.59.0.137740138763.issue28665@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please measure the performance effect of these changes? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 02:09:08 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Nov 2016 07:09:08 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1478934548.89.0.0977207876681.issue28637@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks to Wolfgang. This is his idea, I just faster wrote the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 02:27:46 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Nov 2016 07:27:46 +0000 Subject: [issue28665] Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF In-Reply-To: <1478866241.77.0.0742898329944.issue28665@psf.upfronthosting.co.za> Message-ID: <1478935666.24.0.713154119968.issue28665@psf.upfronthosting.co.za> Raymond Hettinger added the comment: No thanks. These aren't really important opcodes. While there may be a modest speed improvement for the same reasons as the previous patch (avoiding unnecessary work), the main reason to do these two patches is because you had suggested it and because it makes the code follow the same patterns used elsewhere. In general, the short opcodes consistently try to use the macro form of calls where ever it is possible or convenient. Also, to my eyes, the patched code looks cleaner because it is easier to see the refcount effects. That said, I don't care about these two very much, so if you want the improvement and think it is correct, please say so; otherwise, close this and we can leave the code inconsistent in its approach and having it do work that is known to be unnecessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 03:15:12 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Nov 2016 08:15:12 +0000 Subject: [issue28626] Tutorial: rearrange discussion of output formatting to encourage f-strings In-Reply-To: <1478452855.22.0.932657206329.issue28626@psf.upfronthosting.co.za> Message-ID: <1478938512.87.0.917854406566.issue28626@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It makes sense to drop zfill() and ljust(). If there is any mention of string.Template, it could be limited to mentioning why you would want to use it (i.e. is a great format to expose to non-programmer end-users) and include a reference to the string.Template docs. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 03:23:45 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Nov 2016 08:23:45 +0000 Subject: [issue24379] Add operator.subscript as a convenience for creating slices In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1478939025.58.0.313690477504.issue24379@psf.upfronthosting.co.za> Raymond Hettinger added the comment: When I first looked at this a year ago, I thought it seemed like a reasonable idea and might be useful. Since that time, I've haven't encountered any situations whether this would have improved my or someone else's code. And now, I can't even dream up any scenarios where ``operator.subscript[3:7:2]`` would be better than ``slice(3, 7, 2)``. Accordingly, I think we should re-evaluate whether there is any real benefit to be had by adding this to the standard library. Perhaps, we're better off without it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 03:31:38 2016 From: report at bugs.python.org (Michael Hu) Date: Sat, 12 Nov 2016 08:31:38 +0000 Subject: [issue28673] When using pyro4 with more than 15 threads, python 2.7.12 cores frequently Message-ID: <1478939498.33.0.0967391900201.issue28673@psf.upfronthosting.co.za> New submission from Michael Hu: When using pyro4 with more than 15 threads, python 2.7.12 cores frequently (>60% time) Note "v" (op in frame 1) in frame 2 is NULL which has some value in frame 3. So some other thread cleans it. === gdb === Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `python /etc/remoting/remoting_agent.zip run --system'. Program terminated with signal SIGSEGV, Segmentation fault. #0 PyDict_SetItem (op=op at entry=0x0, key=key at entry=0x7f0aa11cd420, value=value at entry=0x920ce0 <_PyExc_AttributeError.12478>) at ../Objects/dictobject.c:832 warning: Source file is more recent than executable. 832 if (!PyDict_Check(op)) { (gdb) bt #0 PyDict_SetItem (op=op at entry=0x0, key=key at entry='exc_type', value=value at entry=) at ../Objects/dictobject.c:832 #1 0x0000000000529e86 in PyDict_SetItemString (item=, key=0x61d02a "exc_type", v=0x0) at ../Objects/dictobject.c:2469 #2 PySys_SetObject (name=name at entry=0x61d02a "exc_type", v=v at entry=) at ../Python/sysmodule.c:83 #3 0x000000000055acc0 in set_exc_info (tb=, value=exceptions.AttributeError("'NoneType' object has no attribute 'SHUT_RDWR'",), type=, tstate=0x95ad10) at ../Python/ceval.c:3736 #4 PyEval_EvalFrameEx (f=f at entry=Frame 0x7f0a9e929b60, for file /etc/remoting/remoting_agent.zip/Pyro4/socketutil.py, line 463, in close (self=), throwflag=throwflag at entry=0) at ../Python/ceval.c:3251 #5 0x0000000000559c27 in fast_function (nk=, na=, n=1, pp_stack=0x7ffce435ab00, func=) at ../Python/ceval.c:4435 #6 call_function (oparg=, pp_stack=0x7ffce435ab00) at ../Python/ceval.c:4370 #7 PyEval_EvalFrameEx (f=f at entry=Frame 0x7f0a40000b50, for file /etc/remoting/remoting_agent.zip/Pyro4/socketutil.py, line 453, in __del__ (self=), throwflag=throwflag at entry=0) at ../Python/ceval.c:2987 #8 0x000000000056aa8a in PyEval_EvalCodeEx (closure=, defcount=, defs=0x0, kwcount=, kws=, argcount=1073744720, args=, locals=0x0, globals=, co=) at ../Python/ceval.c:3582 #9 function_call (func=func at entry=, arg=arg at entry=(,), kw=kw at entry=0x0) at ../Objects/funcobject.c:523 #10 0x00000000004be724 in PyObject_Call (kw=0x0, arg=(,), func=) at ../Objects/abstract.c:2546 #11 instancemethod_call.8803 (func=, arg=(,), kw=0x0) at ../Objects/classobject.c:2602 #12 0x00000000004c4683 in PyObject_Call (kw=0x0, arg=(), func=) at ../Objects/abstract.c:2546 #13 PyEval_CallObjectWithKeywords (kw=0x0, arg=(), func=) at ../Python/ceval.c:4219 #14 slot_tp_del.25647 (self=self at entry=) at ../Objects/typeobject.c:5844 #15 0x00000000004c5880 in subtype_dealloc.25650 (self=) at ../Objects/typeobject.c:1002 #16 0x00000000005336cf in dict_dealloc.18423 (mp=0x7f0a9e93c398) at ../Objects/dictobject.c:1040 #17 0x00000000004c56e7 in subtype_dealloc.25650 ( self=, acquire=, _Condition__waiters=[], release=) at remote 0x7f0a9e9241d0>) at remote 0x7f0a9e924190>, objectsById={'root': , _operations={'cookie_9de0e8d93ed84452a1ce8cc92268979e': , _lock=<_RLock(_Verbose__verbose=False, _RLock__owner=None, _RLock__block=, _RLock__count=0) at remote 0x7f0a9e936190>, _started_at=, cookie='cookie_9de0e8d93ed84452a1ce8cc92268979e', _complete=<_Condition(_Condition__lock=...(truncated)) at ../Objects/typeobject.c:1035 #18 0x0000000000534b93 in frame_dealloc.14921 (f=Frame 0x7f0a9f6d49d8, for file /etc/remoting/remoting_agent.zip/Pyro4/socketserver/threadpool.py, line 39, in run ()) at ../Objects/frameobject.c:458 #19 0x00000000004d86c6 in tb_dealloc.46270 (tb=0x7f0aa1278f38) at ../Python/traceback.c:28 #20 0x00000000004d87e1 in tb_dealloc.46270 (tb=0x7f0aa1278ea8) at ../Python/traceback.c:27 #21 0x00000000005336cf in dict_dealloc.18423 (mp=0x7f0aa1277280) at ../Objects/dictobject.c:1040 #22 0x00000000005a52db in PyInterpreterState_Clear (interp=0x95ac80) at ../Python/pystate.c:111 #23 0x0000000000423aea in Py_Finalize () at ../Python/pythonrun.c:500 #24 0x00000000004672c5 in Py_Main (argc=, argv=0x7ffce435b2d8) at ../Modules/main.c:665 #25 0x00007f0aa0aa7f45 in __libc_start_main (main=0x4672f4
, argc=4, argv=0x7ffce435b2d8, init=, fini=, rtld_fini=, stack_end=0x7ffce435b2c8) at libc-start.c:287 #26 0x000000000057c581 in _start () ==== Google shows similar trace has been reported back in 2009 for python 2.6 https://bugs.launchpad.net/ubuntu/+source/system-config-printer/+bug/478071 ---------- components: Interpreter Core messages: 280640 nosy: pwp333 priority: normal severity: normal status: open title: When using pyro4 with more than 15 threads, python 2.7.12 cores frequently type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 03:32:10 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Nov 2016 08:32:10 +0000 Subject: [issue28665] Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF In-Reply-To: <1478866241.77.0.0742898329944.issue28665@psf.upfronthosting.co.za> Message-ID: <1478939530.72.0.776810542721.issue28665@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- Removed message: http://bugs.python.org/msg280637 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 03:33:39 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 12 Nov 2016 08:33:39 +0000 Subject: [issue26929] android: test_strptime fails In-Reply-To: <1462284711.76.0.324696843297.issue26929@psf.upfronthosting.co.za> Message-ID: <1478939619.01.0.217837125806.issue26929@psf.upfronthosting.co.za> Changes by Xavier de Gaye : Added file: http://bugs.python.org/file45456/exclude_ymd_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 03:34:17 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Nov 2016 08:34:17 +0000 Subject: [issue28665] Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF In-Reply-To: <1478866241.77.0.0742898329944.issue28665@psf.upfronthosting.co.za> Message-ID: <1478939657.47.0.363483243276.issue28665@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think to speed benefit for the last two patches is likely too modest to care about. The main reason I did the work was because you suggested it and because it seemed like a reasonable idea (the patched code looks nice, it does only work that is necessary, and it is more consistent with the other opcodes). Let me know if you want to go forward with it or leave it in the current state (the current juxtaposition of PyCell_GET with PyCell_Set looks a little weird but it does get the job done). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 03:34:33 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Nov 2016 08:34:33 +0000 Subject: [issue28665] Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF In-Reply-To: <1478866241.77.0.0742898329944.issue28665@psf.upfronthosting.co.za> Message-ID: <1478939673.09.0.286690972608.issue28665@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- Removed message: http://bugs.python.org/msg280641 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 03:34:42 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Nov 2016 08:34:42 +0000 Subject: [issue28665] Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF In-Reply-To: <1478866241.77.0.0742898329944.issue28665@psf.upfronthosting.co.za> Message-ID: <1478939682.69.0.484635069037.issue28665@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think the speed benefit for the last two patches is likely too modest to care about. The main reason I did the work was because you suggested it and because it seemed like a reasonable idea (the patched code looks nice, it does only work that is necessary, and it is more consistent with the other opcodes). Let me know if you want to go forward with it or leave it in the current state (the current juxtaposition of PyCell_GET with PyCell_Set looks a little weird but it does get the job done). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 03:56:04 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Nov 2016 08:56:04 +0000 Subject: [issue28665] Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF In-Reply-To: <1478866241.77.0.0742898329944.issue28665@psf.upfronthosting.co.za> Message-ID: <1478940964.2.0.145891217714.issue28665@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The argument about "harmonizing" doesn't look strong to me. Opcodes for locals use the SETLOCAL() macro which decrefs old value, while opcodes for nonlocals with your patches use the PyCell_SET() macro which doesn't. But performance arguments look more weighty. I made benchmarks. fastcell.diff speeds up STORE_FAST by 40%, delete_deref.diff speeds up DELETE_DEREF by 50%. and concat_deref.diff speeds up string concatenating up to 15%. All these operations are rare in comparison with operations with locals or LOAD_DEREF, but the cognitive cost of the optimization is pretty low. All patches LGTM. I only have doubts that such changes could be pushed in 3.6 at this stage. This is not bug fix and isn't tweaking new 3.6 feature. ---------- assignee: serhiy.storchaka -> rhettinger stage: patch review -> commit review versions: -Python 3.6 Added file: http://bugs.python.org/file45457/issue28665.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 04:00:11 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Nov 2016 09:00:11 +0000 Subject: [issue24379] Add operator.subscript as a convenience for creating slices In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1478941211.55.0.178188246218.issue24379@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 04:00:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Nov 2016 09:00:52 +0000 Subject: [issue26929] android: test_strptime fails In-Reply-To: <1462284711.76.0.324696843297.issue26929@psf.upfronthosting.co.za> Message-ID: <1478941252.64.0.89331795907.issue26929@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: exclude_ymd_3.patch LGTM. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 04:10:43 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Nov 2016 09:10:43 +0000 Subject: [issue28665] Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF In-Reply-To: <1478866241.77.0.0742898329944.issue28665@psf.upfronthosting.co.za> Message-ID: <20161112091040.59751.68972.37254DC4@psf.io> Roundup Robot added the comment: New changeset 5f3b7ceb394c by Raymond Hettinger in branch 'default': Issue #28665: Use macro form of PyCell_GET/SET https://hg.python.org/cpython/rev/5f3b7ceb394c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 04:12:16 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 12 Nov 2016 09:12:16 +0000 Subject: [issue28665] Harmonize STORE_DEREF with STORE_FAST and LOAD_DEREF In-Reply-To: <1478866241.77.0.0742898329944.issue28665@psf.upfronthosting.co.za> Message-ID: <1478941936.11.0.491327896243.issue28665@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I think small changes are fine while there is still another beta ahead but would rather just push it to 3.7 than spend more time talking about it. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 04:16:50 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 12 Nov 2016 09:16:50 +0000 Subject: [issue26929] android: test_strptime fails In-Reply-To: <1462284711.76.0.324696843297.issue26929@psf.upfronthosting.co.za> Message-ID: <1478942210.17.0.292710539075.issue26929@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Thanks Serhiy for your help with this issue. I will push this patch with the other Android patches after 3.6 is released. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 04:46:43 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sat, 12 Nov 2016 09:46:43 +0000 Subject: [issue24379] Add operator.subscript as a convenience for creating slices In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1478944003.04.0.185809171148.issue24379@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: I think it would be more useful for multidimensional slicing: >>> subscript[::-1, ..., ::-1] (slice(None, None, -1), Ellipsis, slice(None, None, -1)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 05:46:29 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 12 Nov 2016 10:46:29 +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: <1478947589.19.0.769072267244.issue28668@psf.upfronthosting.co.za> Xavier de Gaye added the comment: When the test is to be skipped: * The decorator in the previous patch (a decorator with arguments that takes no argument) returns a decorator which is unittest.skip (to be applied to the test method). * On the other side, the skip_unless_symlink decorator pattern (no argument) applies the unittest.skip decorator to the test method and returns the decorated test method. This new patch uses the second method suggested by Serhiy. ---------- Added file: http://bugs.python.org/file45458/test_multiprocessing_queue_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 06:13:39 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 12 Nov 2016 11:13:39 +0000 Subject: [issue26934] android: test_faulthandler fails In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za> Message-ID: <1478949219.18.0.228805291906.issue26934@psf.upfronthosting.co.za> Xavier de Gaye added the comment: New patch using a plain 'requires_raise' decorator without argument. ---------- Added file: http://bugs.python.org/file45459/buggy_raise_5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 06:18:30 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Nov 2016 11:18:30 +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: <1478949510.53.0.89719006526.issue28668@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: requires_multiprocessing_queue is used only in test_logging. Is it worth to add it in test.support? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 06:23:53 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Nov 2016 11:23:53 +0000 Subject: [issue26934] android: test_faulthandler fails In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za> Message-ID: <1478949833.27.0.821724515455.issue26934@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 06:38:54 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 12 Nov 2016 11:38:54 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1478950734.9.0.358237872277.issue26865@psf.upfronthosting.co.za> Xavier de Gaye added the comment: issue #28662: catch also PermissionError in tests when spawning a non existent program issue #28664: test_bz2 fails with BrokenPipeError when bunzip2 is missing issue #28668: instanciation of multiprocessing.Queue raises ImportError in test_logging ---------- dependencies: +catch also PermissionError in tests when spawning a non existent program, instanciation of multiprocessing.Queue raises ImportError in test_logging, test_bz2 fails with BrokenPipeError when bunzip2 is missing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 07:05:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Nov 2016 12:05:19 +0000 Subject: [issue28648] False assert in _Py_DecodeUTF8_surrogateescape In-Reply-To: <1478706126.26.0.281529783684.issue28648@psf.upfronthosting.co.za> Message-ID: <1478952319.49.0.597162108621.issue28648@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 07:12:28 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 12 Nov 2016 12:12:28 +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: <1478952748.19.0.490182088826.issue28668@psf.upfronthosting.co.za> Xavier de Gaye added the comment: IMHO other tests in the future may instantiate multiprocessing.Queue() and come up with another new decorator when the test fails on the (yet to come) Android buildbot, ignoring that one already exists if we move the decorator to the test_logging module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 07:15:34 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 12 Nov 2016 12:15:34 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1478952934.0.0.294738982834.issue21145@psf.upfronthosting.co.za> Nick Coghlan added the comment: I realised that PEP 487's __set_name__ can be used to detect the `__slots__` conflict at class definition time rather than on first lookup: def __set_name__(self, owner, name): try: slots = owner.__slots__ except AttributeError: return if "__dict__" not in slots: msg = f"'__dict__' attribute required on {owner.__name__!r} instances to cache {name!r} property." raise TypeError(msg) It also occurred to me that at the expense of one level of indirection in the runtime lookup, PEP 487's __set_name__ hook and a specified naming convention already permits a basic, albeit inefficient, "cached_slot" implementation: class cached_slot: def __init__(self, func): self.func = func self.cache_slot = func.__name__ + "_cache" self.__doc__ = func.__doc__ self._lock = RLock() def __set_name__(self, owner, name): try: slots = owner.__slots__ except AttributeError: msg = f"cached_slot requires '__slots__' on {owner!r}" raise TypeError(msg) from None if self.cache_slot not in slots: msg = f"cached_slot requires {self.cache_slot!r} slot on {owner!r}" raise TypeError(msg) from None def __get__(self, instance, cls=None): if instance is None: return self try: return getattr(instance, self.cache_slot) except AttributeError: # Cache not initialised yet, so proceed to double-checked locking pass with self.lock: # check if another thread filled cache while we awaited lock try: return getattr(instance, self.cache_slot) except AttributeError: # Cache still not initialised yet, so initialise it setattr(instance, self.cache_slot, self.func(instance)) return getattr(instance, self.cache_slot) def __set__(self, instance, value): setattr(instance, self.cache_slot, value) def __delete__(self, instance): delattr(instance, self.cache_slot) It can't be done as a data descriptor though (and can't be done efficiently in pure Python), so I don't think it makes sense to try to make cached_property itself work implicitly with both normal attributes and slot entries - instead, cached_property can handle the common case as simply and efficiently as possible, and the cached_slot case can be either handled separately or else not at all. The "don't offer cached_slot at all" argument would be that, given slots are used for memory-efficiency when handling large numbers of objects and lazy initialization is used to avoid unnecessary computations, a "lazily initialised slot" can be viewed as "64 bits of frequently wasted space", and hence we can expect demand for the feature to be incredibly low (and the community experience to date bears out that expectation). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 07:23:57 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Nov 2016 12:23:57 +0000 Subject: [issue28648] False assert in _Py_DecodeUTF8_surrogateescape In-Reply-To: <1478706126.26.0.281529783684.issue28648@psf.upfronthosting.co.za> Message-ID: <1478953437.98.0.106461273037.issue28648@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. Thank you for your patch Xiang. ---------- components: +Interpreter Core versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 07:35:08 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 12 Nov 2016 12:35:08 +0000 Subject: [issue21145] Add the @cached_property decorator In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za> Message-ID: <1478954108.34.0.087513143068.issue21145@psf.upfronthosting.co.za> Nick Coghlan added the comment: Having just said that I don't see much use for lazily initialized slots, it does occur to me that __weakref__ is essentially such a slot, and __dict__ itself could usefully be such a slot for types where instances mostly have a fixed set of attributes, but still allow for arbitrary additional attributes at runtime. However, I do think any such proposal should be considered as its own issue, rather than being treated as part of this one - the assumed absence of the instance dict creates too many differences in the design trade-offs involved and the potential use cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 07:37:38 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Nov 2016 12:37:38 +0000 Subject: [issue28648] False assert in _Py_DecodeUTF8_surrogateescape In-Reply-To: <1478706126.26.0.281529783684.issue28648@psf.upfronthosting.co.za> Message-ID: <20161112123735.5669.96765.BBD0E546@psf.io> Roundup Robot added the comment: New changeset 9bf1ca6ce1fe by Serhiy Storchaka in branch '3.3': Issue #28648: Fixed crash in Py_DecodeLocale() in debug build on Mac OS X https://hg.python.org/cpython/rev/9bf1ca6ce1fe New changeset bfd0da08438f by Serhiy Storchaka in branch '3.4': Issue #28648: Fixed crash in Py_DecodeLocale() in debug build on Mac OS X https://hg.python.org/cpython/rev/bfd0da08438f New changeset 65b5518da6e2 by Serhiy Storchaka in branch '3.5': Issue #28648: Fixed crash in Py_DecodeLocale() in debug build on Mac OS X https://hg.python.org/cpython/rev/65b5518da6e2 New changeset 2cbd2ec6307d by Serhiy Storchaka in branch '3.6': Issue #28648: Fixed crash in Py_DecodeLocale() in debug build on Mac OS X https://hg.python.org/cpython/rev/2cbd2ec6307d New changeset 0b576ab589c5 by Serhiy Storchaka in branch 'default': Issue #28648: Fixed crash in Py_DecodeLocale() in debug build on Mac OS X https://hg.python.org/cpython/rev/0b576ab589c5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 07:40:21 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Nov 2016 12:40:21 +0000 Subject: [issue28648] False assert in _Py_DecodeUTF8_surrogateescape In-Reply-To: <1478706126.26.0.281529783684.issue28648@psf.upfronthosting.co.za> Message-ID: <1478954421.41.0.111716097242.issue28648@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Since the crash can be caused by environment I consider it as a security issue (bot not critical) and applied the patch to 3.3 and 3.4. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 07:41:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Nov 2016 12:41:54 +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: <1478954514.19.0.366017238035.issue28668@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Okay. test_multiprocessing_queue_2.patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 08:48:13 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 12 Nov 2016 13:48:13 +0000 Subject: [issue24379] Add operator.subscript as a convenience for creating slices In-Reply-To: <1478939025.58.0.313690477504.issue24379@psf.upfronthosting.co.za> Message-ID: <20161112134807.GO3365@ando.pearwood.info> Steven D'Aprano added the comment: On Sat, Nov 12, 2016 at 08:23:45AM +0000, Raymond Hettinger wrote: > I can't even dream up any scenarios where > ``operator.subscript[3:7:2]`` would be better than > ``slice(3, 7, 2)``. For that specific example, I completely agree. But I think that in general ``slice[::-1]`` is better than either the current alternative ``slice(None, None, -1)`` or the proposed ``operator.subscript[::-1]``. And there's no comparison once you get to multi-dimensional slices: s = slice[::-1, 1:, 1::2] spam[s] + eggs[s] versus: s = slice(slice(None, None, -1), slice(1, None), slice(1, None, 2)) spam[s] + eggs[s] Even simple examples look nice in slice syntax: slice[3:7:2] I had completely forgotten about this feature request, but coincidentally re-suggested it on the Python-Ideas mailing list earlier today: https://mail.python.org/pipermail/python-ideas/2016-November/043630.html The downside is that beginners who are still learning Python's syntax may try writing: slice(::-1) by mistake. Nevertheless, it seems to me that the advantage to more experienced developers to be able to read and write slice objects using slice format outweighs the temporary confusion to beginners. (I would expect that outside of the Numpy community, few beginners use the slice() object directly, so this would not often affect them.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 10:57:04 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Sat, 12 Nov 2016 15:57:04 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <1478966224.03.0.15974786453.issue28587@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks for the feedback, Raymond :) I rephrased the docs like the following, what do you think? Return zero-based index in the list of the first item whose value is *x*. It is an error if there is no such item. Optional arguments ``start`` and ``end`` are interpreted as in slice notation. ---------- Added file: http://bugs.python.org/file45460/issue28587v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 11:29:26 2016 From: report at bugs.python.org (Damian Kotlar) Date: Sat, 12 Nov 2016 16:29:26 +0000 Subject: [issue28674] fosa.zd.djkps@gmail.com Message-ID: <1478968165.19.0.779355016378.issue28674@psf.upfronthosting.co.za> Changes by Damian Kotlar : ---------- assignee: docs at python components: 2to3 (2.x to 3.x conversion tool), Cross-Build, Demos and Tools, Documentation, Extension Modules, Installation, Interpreter Core, Library (Lib), SSL, Tests, XML, email files: samsungapps.html nosy: Alex.Willmer, barry, docs at python, fosa.zd.djkps at gmail.com, r.david.murray priority: normal severity: normal status: open title: fosa.zd.djkps at gmail.com versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45461/samsungapps.html _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 11:55:11 2016 From: report at bugs.python.org (Zachary Ware) Date: Sat, 12 Nov 2016 16:55:11 +0000 Subject: [issue28674] Spam Message-ID: <1478969711.81.0.84259952295.issue28674@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- assignee: docs at python -> components: -2to3 (2.x to 3.x conversion tool), Cross-Build, Demos and Tools, Documentation, Extension Modules, Installation, Interpreter Core, Library (Lib), SSL, Tests, XML, email nosy: -Alex.Willmer, barry, docs at python, fosa.zd.djkps at gmail.com, r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed title: fosa.zd.djkps at gmail.com -> Spam versions: -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 Sat Nov 12 11:55:28 2016 From: report at bugs.python.org (Zachary Ware) Date: Sat, 12 Nov 2016 16:55:28 +0000 Subject: [issue28674] Spam Message-ID: <1478969728.26.0.246367582106.issue28674@psf.upfronthosting.co.za> Changes by Zachary Ware : Removed file: http://bugs.python.org/file45461/samsungapps.html _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 12:28:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Nov 2016 17:28:37 +0000 Subject: [issue25996] Add support of file descriptor in os.scandir() In-Reply-To: <1451758238.49.0.729670752807.issue25996@psf.upfronthosting.co.za> Message-ID: <1478971716.99.0.197349071167.issue25996@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for the review Josh. Updated patch addresses your comments and adds yet few microoptimizations. ---------- Added file: http://bugs.python.org/file45462/os-scandir-fd-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 12:30:22 2016 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 12 Nov 2016 17:30:22 +0000 Subject: [issue28673] When using pyro4 with more than 15 threads, python 2.7.12 cores frequently In-Reply-To: <1478939498.33.0.0967391900201.issue28673@psf.upfronthosting.co.za> Message-ID: <1478971822.52.0.161114001632.issue28673@psf.upfronthosting.co.za> Eric V. Smith added the comment: Can you provide a short sample that causes this error? Without a way to reproduce it, there's not a lot we can do. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 13:21:35 2016 From: report at bugs.python.org (Gareth Rees) Date: Sat, 12 Nov 2016 18:21:35 +0000 Subject: [issue28647] python --help: -u is misdocumented as binary mode In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za> Message-ID: <1478974895.69.0.740188029464.issue28647@psf.upfronthosting.co.za> Gareth Rees added the comment: The output of "python3.5 --help" says: -u : unbuffered binary stdout and stderr, stdin always buffered; also PYTHONUNBUFFERED=x see man page for details on internal buffering relating to '-u' If you look at the man page as instructed then you'll see a clearer explanation: -u Force the binary I/O layers of stdout and stderr to be unbuffered. stdin is always buffered. The text I/O layer will still be line-buffered. For example, if you try this: python3.5 -uc 'import sys,time;w=sys.stdout.buffer.write;w(b"a");time.sleep(1);w(b"b");' then you'll see that the binary output is indeed unbuffered as documented. The output of --help is trying to abbreviate this explanation, but I think it's abbreviated too much. The explanation from the man page seems clear to me, and is only a little longer, so I suggest changing the --help output to match the man page. ---------- nosy: +Gareth.Rees _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 13:36:51 2016 From: report at bugs.python.org (Gareth Rees) Date: Sat, 12 Nov 2016 18:36:51 +0000 Subject: [issue28647] python --help: -u is misdocumented as binary mode In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za> Message-ID: <1478975811.82.0.535205552316.issue28647@psf.upfronthosting.co.za> Gareth Rees added the comment: Here's a patch that copies the text for the -u option from the man page to the --help output. ---------- keywords: +patch Added file: http://bugs.python.org/file45463/issue28647.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 14:05:03 2016 From: report at bugs.python.org (Big Stone) Date: Sat, 12 Nov 2016 19:05:03 +0000 Subject: [issue28675] about PEP 528 / PEP 529 Message-ID: <1478977503.51.0.187349952636.issue28675@psf.upfronthosting.co.za> New submission from Big Stone: Hi, if possible a few words of explanation to implement it may be helpfull, as I don't see the difference yet, in the typical case where it was not good before: https://cloud.githubusercontent.com/assets/4312421/20240181/5bf917fe-a912-11e6-95e8-e65fcb9a8845.PNG (more an after PEP sales service request than a bug, I presume) ---------- components: Windows messages: 280667 nosy: Big Stone, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: about PEP 528 / PEP 529 versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 14:08:08 2016 From: report at bugs.python.org (Big Stone) Date: Sat, 12 Nov 2016 19:08:08 +0000 Subject: [issue28675] about PEP 528 / PEP 529 In-Reply-To: <1478977503.51.0.187349952636.issue28675@psf.upfronthosting.co.za> Message-ID: <1478977688.1.0.349312892761.issue28675@psf.upfronthosting.co.za> Big Stone added the comment: same un-effect in Qtconsole, I'm disappointed. Maybe I mis-understood what these PEP would bring ? ---------- Added file: http://bugs.python.org/file45464/pep_528-529_where_are_you_you.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 14:30:20 2016 From: report at bugs.python.org (Gareth Rees) Date: Sat, 12 Nov 2016 19:30:20 +0000 Subject: [issue28676] On macOS Sierra, warning: implicit declaration of function 'getentropy' Message-ID: <1478979020.94.0.0997412321445.issue28676@psf.upfronthosting.co.za> New submission from Gareth Rees: On macOS Sierra (OSX 10.12.1): $ ./configure --with-pydebug && make [... lots of output omitted ...] 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 -I. -I./Include -DPy_BUILD_CORE -o Python/random.o Python/random.c Python/random.c:97:19: warning: implicit declaration of function 'getentropy' is invalid in C99 [-Wimplicit-function-declaration] res = getentropy(buffer, len); ^ 1 warning generated. This is because OSX 10.12.1 has getentropy() but does not have getrandom(). You can see this in pyconfig.h: /* Define to 1 if you have the `getentropy' function. */ #define HAVE_GETENTROPY 1 /* Define to 1 if the getrandom() function is available */ /* #undef HAVE_GETRANDOM */ and this means that in Python/random.c the header is not included: # ifdef HAVE_GETRANDOM # include # elif defined(HAVE_GETRANDOM_SYSCALL) # include # endif It's necessary include if either HAVE_GETRANDOM or HAVE_GETENTROPY is defined. ---------- components: Build, macOS files: getentropy.patch keywords: patch messages: 280669 nosy: Gareth.Rees, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: On macOS Sierra, warning: implicit declaration of function 'getentropy' type: compile error versions: Python 3.7 Added file: http://bugs.python.org/file45465/getentropy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 15:14:21 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Nov 2016 20:14:21 +0000 Subject: [issue5830] heapq item comparison problematic with sched's events In-Reply-To: <1240580106.04.0.721938894312.issue5830@psf.upfronthosting.co.za> Message-ID: <1478981661.12.0.318172436813.issue5830@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 16:32:17 2016 From: report at bugs.python.org (Viorel Tabara) Date: Sat, 12 Nov 2016 21:32:17 +0000 Subject: [issue28677] difficult to parse sentence structure in "When an instance attribute is referenced that isn't a data attribute" Message-ID: <1478986337.93.0.398450030776.issue28677@psf.upfronthosting.co.za> New submission from Viorel Tabara: Method objects are explained at: https://docs.python.org/3/tutorial/classes.html#method-objects I'd like to suggest a change from: When an instance attribute is referenced that isn?t a data attribute, its class is searched. to something along this line: When an instance attribute --- that isn?t a data attribute --- is referenced, the instance parent class will be searched. ---------- assignee: docs at python components: Documentation messages: 280671 nosy: docs at python, viorel priority: normal severity: normal status: open title: difficult to parse sentence structure in "When an instance attribute is referenced that isn't a data attribute" type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 16:40:41 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Nov 2016 21:40:41 +0000 Subject: [issue28676] On macOS Sierra, warning: implicit declaration of function 'getentropy' In-Reply-To: <1478979020.94.0.0997412321445.issue28676@psf.upfronthosting.co.za> Message-ID: <20161112214037.7054.63981.351FBBA8@psf.io> Roundup Robot added the comment: New changeset 828251c2bccf by Ned Deily in branch '2.7': Issue #28676: Prevent missing 'getentropy' declaration warning on macOS. https://hg.python.org/cpython/rev/828251c2bccf New changeset 0efd48d4c47c by Ned Deily in branch '3.5': Issue #28676: Prevent missing 'getentropy' declaration warning on macOS. https://hg.python.org/cpython/rev/0efd48d4c47c New changeset e2faa8a22b69 by Ned Deily in branch '3.6': Issue #28676: merge from 3.5 https://hg.python.org/cpython/rev/e2faa8a22b69 New changeset b31a7efd8b31 by Ned Deily in branch 'default': Issue #28676: merge from 3.6 https://hg.python.org/cpython/rev/b31a7efd8b31 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 16:43:17 2016 From: report at bugs.python.org (Lewis McCarthy) Date: Sat, 12 Nov 2016 21:43:17 +0000 Subject: [issue28678] tarfile extract docs inconsistent naming of parameter numeric_owner or numeric_only Message-ID: <1478986997.97.0.266901565228.issue28678@psf.upfronthosting.co.za> New submission from Lewis McCarthy: https://docs.python.org/3/library/tarfile.html#tarfile-objects Most of the documentation for the extract and extractall methods refers to a parameter named numeric_owner. However, the notes on what changed in v3.5 refer instead to numeric_only. One of these names is incorrect and should be changed to match the other. Same issue in the 3.6 and 3.7 docs. https://docs.python.org/3.6/library/tarfile.html#tarfile-objects https://docs.python.org/3.7/library/tarfile.html#tarfile-objects ---------- assignee: docs at python components: Documentation messages: 280673 nosy: docs at python, pseudonym priority: normal severity: normal status: open title: tarfile extract docs inconsistent naming of parameter numeric_owner or numeric_only type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 16:43:39 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 12 Nov 2016 21:43:39 +0000 Subject: [issue28676] On macOS Sierra, warning: implicit declaration of function 'getentropy' In-Reply-To: <1478979020.94.0.0997412321445.issue28676@psf.upfronthosting.co.za> Message-ID: <1478987019.86.0.39014670916.issue28676@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the patch, Gareth! Pushed for release in 2.7.13, 3.5.3, 3.6.0b4, and 3.7.0. ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 17:25:21 2016 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 12 Nov 2016 22:25:21 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1478989521.1.0.692668606981.issue28618@psf.upfronthosting.co.za> Yury Selivanov added the comment: Can we commit this to 3.6 too? ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 17:47:31 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Nov 2016 22:47:31 +0000 Subject: [issue28678] tarfile extract docs inconsistent naming of parameter numeric_owner or numeric_only In-Reply-To: <1478986997.97.0.266901565228.issue28678@psf.upfronthosting.co.za> Message-ID: <1478990851.97.0.778450812567.issue28678@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +easy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 17:49:14 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 12 Nov 2016 22:49:14 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1478990954.04.0.468121289834.issue28635@psf.upfronthosting.co.za> Ned Deily added the comment: There are now a few markup errors that the Docs buildbots are catching. See, for example: http://buildbot.python.org/all/builders/Docs%203.x/builds/2849 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 17:52:48 2016 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 12 Nov 2016 22:52:48 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478990954.04.0.468121289834.issue28635@psf.upfronthosting.co.za> Message-ID: Yury Selivanov added the comment: I'll go through whatsnew on Monday, fixing errors etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 17:53:06 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Nov 2016 22:53:06 +0000 Subject: [issue14061] Misc fixes and cleanups in archiving code in shutil and test_shutil In-Reply-To: <1329705067.15.0.02936958618.issue14061@psf.upfronthosting.co.za> Message-ID: <1478991186.56.0.0780305777088.issue14061@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file45466/shutil_make_archive_misc_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 18:38:14 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 12 Nov 2016 23:38:14 +0000 Subject: [issue26934] android: test_faulthandler fails In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za> Message-ID: <1478993894.84.0.75885771746.issue26934@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, you didn't push your patch yet? Go ahead. buggy_raise_5.patch LGTM and is better than perfect :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 18:40:38 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 12 Nov 2016 23:40:38 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1478994038.04.0.621146663629.issue28618@psf.upfronthosting.co.za> STINNER Victor added the comment: > Can we commit this to 3.6 too? I worked on patches to try to optimize json_loads and regex_effbot as well, but it's still unclear to me how the hot attribute works, and I'm not 100% sure that using the attribut explicitly does not introduce a performance regession. So I prefer to experiment such change in default right now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 20:26:54 2016 From: report at bugs.python.org (Kubilay Kocak) Date: Sun, 13 Nov 2016 01:26:54 +0000 Subject: [issue23284] Improve termcap detection in setup.py In-Reply-To: <1421794283.67.0.365311015753.issue23284@psf.upfronthosting.co.za> Message-ID: <1479000414.3.0.500494076899.issue23284@psf.upfronthosting.co.za> Changes by Kubilay Kocak : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 20:43:47 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 13 Nov 2016 01:43:47 +0000 Subject: [issue28675] about PEP 528 / PEP 529 In-Reply-To: <1478977503.51.0.187349952636.issue28675@psf.upfronthosting.co.za> Message-ID: <1479001427.26.0.418682598813.issue28675@psf.upfronthosting.co.za> Steve Dower added the comment: Those are redirecting stdin and stdout from the real console to their own handlers, so they are responsible for setting the encoding. Both of those examples are able to fix the encoding issues whenever they like - assuming their GUI toolkits can handle it. The change for 3.6 only affected the standard Windows console. Other consoles can specify a different encoding independently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 21:32:16 2016 From: report at bugs.python.org (Yudai Fujiwara) Date: Sun, 13 Nov 2016 02:32:16 +0000 Subject: [issue28679] CGIHTTPServer displays raw python code when the url contains '/' after '?' Message-ID: <1479004336.61.0.664243507807.issue28679@psf.upfronthosting.co.za> Changes by Yudai Fujiwara : ---------- components: Library (Lib) nosy: Yudai Fujiwara priority: normal severity: normal status: open title: CGIHTTPServer displays raw python code when the url contains '/' after '?' type: security versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 21:33:12 2016 From: report at bugs.python.org (Yudai Fujiwara) Date: Sun, 13 Nov 2016 02:33:12 +0000 Subject: [issue28679] CGIHTTPServer displays raw python code when the url contains '/' after '?' Message-ID: <1479004392.72.0.0518318514233.issue28679@psf.upfronthosting.co.za> New submission from Yudai Fujiwara: I made a simple CGI server and prepared index.py on the root directory. When I access to '/index.py?value=data', it displays 'value = data', which is working correctly. However, when I access to '/index.py?/' or something like this, it displays its raw python code. It seems that this bug occurs when I access to a url that contains '/' after '?' ---------- Added file: http://bugs.python.org/file45467/index.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 21:39:12 2016 From: report at bugs.python.org (Timothy Widrick) Date: Sun, 13 Nov 2016 02:39:12 +0000 Subject: [issue28680] bdist_wininst generated 64-bit executable looks for 3.5-32 Message-ID: <1479004752.08.0.80929351166.issue28680@psf.upfronthosting.co.za> New submission from Timothy Widrick: Short version: wininst-14.0-amd64.exe has "-32" in it. It shouldn't, should it? Longer version: Running "python setup.py bdist_wininst" gives me a file named like: project-version.win-amd64-py3.5.exe When I run that, I get: Python version 3.5-32 required, which was not found in the registry. My "fix" was to edit the wininst-14.0-amd64.exe and replace the "-32" with 3 null bytes. ---------- components: Distutils messages: 280682 nosy: Timothy Widrick, dstufft, eric.araujo priority: normal severity: normal status: open title: bdist_wininst generated 64-bit executable looks for 3.5-32 type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 22:36:36 2016 From: report at bugs.python.org (Xue Fuqiao) Date: Sun, 13 Nov 2016 03:36:36 +0000 Subject: [issue28681] About function renaming in the tutorial Message-ID: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za> New submission from Xue Fuqiao: In https://hg.python.org/cpython/file/6fbb7c9d77c6/Doc/tutorial/controlflow.rst#l295 : A function definition introduces the function name in the current symbol table. The value of the function name has a type that is recognized by the interpreter as a user-defined function. This value can be assigned to another name which can then also be used as a function. This serves as a general renaming mechanism Maybe "aliasing" is a better term than "renaming" here, since the original function name can still be used after the "renaming". ---------- assignee: docs at python components: Documentation files: renaming.patch keywords: patch messages: 280683 nosy: docs at python, xfq priority: normal severity: normal status: open title: About function renaming in the tutorial type: enhancement versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45468/renaming.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 23:08:18 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 13 Nov 2016 04:08:18 +0000 Subject: [issue25662] _tkinter.TclError: bad event type or keysym "Alt" In-Reply-To: <1447891406.93.0.234833254631.issue25662@psf.upfronthosting.co.za> Message-ID: <1479010098.8.0.495641565482.issue25662@psf.upfronthosting.co.za> Terry J. Reedy added the comment: A crash is when Python stops without a traceback, even when run with somewhere for a traceback to go. However, I regard it as a bug for IDLE to stop because of a problem in a user.cfg file. I am not re-opening because this appears to be a duplicate of #11437, which had the same error message with 'up' instead of 'Alt'. ---------- nosy: +terry.reedy resolution: fixed -> duplicate stage: -> resolved superseder: -> IDLE crash on startup with typo in config-keys.cfg type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 23:10:14 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 13 Nov 2016 04:10:14 +0000 Subject: [issue11437] IDLE crash on startup with typo in config-keys.cfg In-Reply-To: <1299543243.52.0.970222997696.issue11437@psf.upfronthosting.co.za> Message-ID: <1479010214.87.0.218684028848.issue11437@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I closed #25662 in favor of this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 12 23:29:15 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 13 Nov 2016 04:29:15 +0000 Subject: [issue28681] About function renaming in the tutorial In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za> Message-ID: <1479011355.61.0.852403972426.issue28681@psf.upfronthosting.co.za> Raymond Hettinger added the comment: +1 "Aliasing" is more accurate. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 00:52:37 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 13 Nov 2016 05:52:37 +0000 Subject: [issue28681] About function renaming in the tutorial In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za> Message-ID: <1479016357.21.0.47973002009.issue28681@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I disagree that "aliasing" is more accurate. We have a perfectly good name for symbols in Python: "name". A value (and that includes functions) can have multiple names. It seems to me that if we're to start distinguishing between names and aliases, then aliases have to be different from names. And the way I understand "alias" is that it is another symbol for a variable, not another symbol for the same value. We wouldn't say that x = 1 y = x makes y an alias for x. y just happens to be a second name for the same value that x currently has. There's no guarantee that they will stay the same. Substitute a function object for the int 1, and you have the situation being discussed in the tutorial. I would expect that aliases should not be effected by rebinding: x = 1 y = alias(x) # if such a thing existed x = 2 assert y == 2 Obviously there's nothing in Python like that! This doesn't match Python's name binding model at all. I think that talking about a "general aliasing" mechanism is exactly wrong. I think that the tutorial should emphasis the reality that functions are just ordinary values, like ints and floats and dicts and lists, and not try to indicate that there is something special or different about names bound to functions: def f(): ... g = f is no different from the x = y example earlier. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 01:01:02 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 13 Nov 2016 06:01:02 +0000 Subject: [issue28681] About function renaming in the tutorial In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za> Message-ID: <1479016862.39.0.608372846409.issue28681@psf.upfronthosting.co.za> Raymond Hettinger added the comment: To me, this is renaming: def f(x): pass f.__name__ = g And this is aliasing: g = f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 04:04:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Nov 2016 09:04:52 +0000 Subject: [issue27998] Bytes paths now are supported in os.scandir() on Windows In-Reply-To: <1473236470.81.0.837469962495.issue27998@psf.upfronthosting.co.za> Message-ID: <1479027892.18.0.0468867307659.issue27998@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch documents bytes paths support on Windows. ---------- keywords: +patch nosy: +Elvis.Pranskevichus, yselivanov stage: needs patch -> patch review Added file: http://bugs.python.org/file45469/doc-scandir-bytes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 04:24:10 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Nov 2016 09:24:10 +0000 Subject: [issue28682] Bytes support in os.fwalk() Message-ID: <1479029050.5.0.426622691368.issue28682@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: os.walk() supports string and bytes paths, but os.fwalk() always supported only string paths. Proposed patch adds support of bytes paths in os.fwalk(). ---------- components: Library (Lib) files: fwalk-bytes.patch keywords: patch messages: 280690 nosy: larry, loewis, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Bytes support in os.fwalk() type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45470/fwalk-bytes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 05:31:21 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 13 Nov 2016 10:31:21 +0000 Subject: [issue28681] About function renaming in the tutorial In-Reply-To: <1479016862.39.0.608372846409.issue28681@psf.upfronthosting.co.za> Message-ID: <20161113103114.GQ3365@ando.pearwood.info> Steven D'Aprano added the comment: > And this is aliasing: > g = f Is it only aliasing if you know that f is a function? I don't mean that as a rhetorical question -- I'm asking if we're comfortable with the idea of saying that g is an alias when f is (say) a float. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 06:07:34 2016 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 13 Nov 2016 11:07:34 +0000 Subject: [issue11437] IDLE crash on startup with typo in config-keys.cfg In-Reply-To: <1299543243.52.0.970222997696.issue11437@psf.upfronthosting.co.za> Message-ID: <1479035254.79.0.252051699498.issue11437@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 06:23:24 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sun, 13 Nov 2016 11:23:24 +0000 Subject: [issue24379] Add operator.subscript as a convenience for creating slices In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1479036204.98.0.945791281061.issue24379@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Here is a new patch that does not cause refleaks, I just replaced empty __slots__ with a __setattr__: it looks like __slots__ are not needed here to save memory (there is only a singleton instance), they were used just to create an immutable object. ---------- Added file: http://bugs.python.org/file45471/operator_subscript_norefleak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 06:33:54 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sun, 13 Nov 2016 11:33:54 +0000 Subject: [issue28651] Make objects with empty __slots__ GC types In-Reply-To: <1478716305.57.0.745057898966.issue28651@psf.upfronthosting.co.za> Message-ID: <1479036834.88.0.426048338596.issue28651@psf.upfronthosting.co.za> Changes by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 06:59:11 2016 From: report at bugs.python.org (Petr) Date: Sun, 13 Nov 2016 11:59:11 +0000 Subject: [issue28632] configparser does not close files in read In-Reply-To: <1478537342.33.0.595722710962.issue28632@psf.upfronthosting.co.za> Message-ID: <1479038351.2.0.375274788103.issue28632@psf.upfronthosting.co.za> Petr added the comment: Thanks for your comments, I am myself quite puzzled how is it possible that the file is not closed after having been read. I suspect this to be an OS problem, therefore I am closing the bug for now. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 07:01:12 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 13 Nov 2016 12:01:12 +0000 Subject: [issue28679] CGIHTTPServer displays raw python code when the url contains '/' after '?' In-Reply-To: <1479004392.72.0.0518318514233.issue28679@psf.upfronthosting.co.za> Message-ID: <1479038472.18.0.997727881408.issue28679@psf.upfronthosting.co.za> Xiang Zhang added the comment: Sorry Yudai, I cannot reproduce this. Both '/index.py?value=data' and '/index.py?/' outputs 'value = None' with your index.py. ---------- nosy: +martin.panter, xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 07:26:19 2016 From: report at bugs.python.org (Yudai Fujiwara) Date: Sun, 13 Nov 2016 12:26:19 +0000 Subject: [issue28679] CGIHTTPServer displays raw python code when the url contains '/' after '?' In-Reply-To: <1479004392.72.0.0518318514233.issue28679@psf.upfronthosting.co.za> Message-ID: <1479039979.05.0.21334661311.issue28679@psf.upfronthosting.co.za> Yudai Fujiwara added the comment: Thanks for your reply. I uploaded server.py. I'm using python 2.7.5 to run server.py on CentOS 7. Both server.py and index.py are located in /var/www/html. $ ls -lh -rwxr-xr-x. 1 root root 189 11? 13 11:21 index.py -rw-r--r--. 1 root root 239 11? 13 21:04 server.py This is the response from the server when it works correctly: $ ncat 192.168.3.5 8000 GET /index.py?value=data HTTP/1.1 HTTP/1.0 200 Script output follows Server: SimpleHTTP/0.6 Python/2.7.5 Date: Sun, 13 Nov 2016 12:18:49 GMT Content-type: text/html

value = data

And this is the response when the bug occurs: $ ncat 192.168.3.5 GET /index.py?/ HTTP/1.1 HTTP/1.0 200 OK Server: SimpleHTTP/0.6 Python/2.7.5 Date: Sun, 13 Nov 2016 12:06:42 GMT Content-type: text/plain Content-Length: 189 Last-Modified: Sun, 13 Nov 2016 02:21:11 GMT #!/usr/bin/env python # coding: utf-8 import cgi form = cgi.FieldStorage() print("Content-type: text/html") print("") print("

value = {0}

".format( form.getvalue('value', 'None') ) The server.py is running on the terminal and it seems to be working perfectly: $ python server.py 192.168.3.5 - - [13/Nov/2016 21:18:49] "GET /index.py?value=data HTTP/1.1" 200 - 192.168.3.5 - - [13/Nov/2016 21:20:42] "GET /index.py?/ HTTP/1.1" 200 - Maybe the configuration in server.py is wrong? ---------- Added file: http://bugs.python.org/file45472/server.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 08:15:11 2016 From: report at bugs.python.org (SilentGhost) Date: Sun, 13 Nov 2016 13:15:11 +0000 Subject: [issue28632] configparser does not close files in read In-Reply-To: <1478537342.33.0.595722710962.issue28632@psf.upfronthosting.co.za> Message-ID: <1479042911.41.0.522606843879.issue28632@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 08:17:16 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 13 Nov 2016 13:17:16 +0000 Subject: [issue28679] CGIHTTPServer displays raw python code when the url contains '/' after '?' In-Reply-To: <1479004392.72.0.0518318514233.issue28679@psf.upfronthosting.co.za> Message-ID: <1479043036.51.0.0255978075306.issue28679@psf.upfronthosting.co.za> Xiang Zhang added the comment: I think this is a bug in 2.7.5 and has already been fixed. I'd suggest you get a more recent version of 2.7. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 09:10:50 2016 From: report at bugs.python.org (Yudai Fujiwara) Date: Sun, 13 Nov 2016 14:10:50 +0000 Subject: [issue28679] CGIHTTPServer displays raw python code when the url contains '/' after '?' In-Reply-To: <1479004392.72.0.0518318514233.issue28679@psf.upfronthosting.co.za> Message-ID: <1479046250.85.0.219853789108.issue28679@psf.upfronthosting.co.za> Yudai Fujiwara added the comment: I've just installed 2.7.11 and the bug seems to be fixed. Thank you for your accurate solution! Closed. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 09:12:57 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 13 Nov 2016 14:12:57 +0000 Subject: [issue28679] CGIHTTPServer displays raw python code when the url contains '/' after '?' In-Reply-To: <1479004392.72.0.0518318514233.issue28679@psf.upfronthosting.co.za> Message-ID: <1479046377.68.0.257536394153.issue28679@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 10:30:16 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sun, 13 Nov 2016 15:30:16 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1479051016.21.0.970050123584.issue28635@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Thank you Yury and Elvis for working on this! I have few more suggestions for What's New: * collections.abc.Reversible (http://bugs.python.org/issue25987). * various ABCs in collections.abc now have means for explicit "anti-registration" by setting a corresponding attribute to None (http://bugs.python.org/issue25958, https://docs.python.org/3.6/reference/datamodel.html#special-method-names). * implementation improvements (such as caching of generic types) in typing module give up to 30x seep-up and reduce memory footprint. * typing.py now supports generic type aliases (https://github.com/python/typing/pull/195 and https://github.com/python/typing/pull/308, see mypy docs for usage examples). * typing.py supports PEP 526 syntax for typed NamedTuple (https://github.com/python/typing/pull/282). (I see that there are already several items about typing, so please feel free to keep only the most important changes.) ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 10:53:54 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 13 Nov 2016 15:53:54 +0000 Subject: [issue24379] Add operator.subscript as a convenience for creating slices In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1479052434.52.0.478221858027.issue24379@psf.upfronthosting.co.za> Guido van Rossum added the comment: So we now have the refleak fixed. Can we apply the patch? Or is it too late for 3.6? ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 10:59:09 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sun, 13 Nov 2016 15:59:09 +0000 Subject: [issue24379] Add operator.subscript as a convenience for creating slices In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1479052749.18.0.154627048582.issue24379@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: The patch is small and it was initially applied before 3.6b1, I think we should ask Ned (added to nosy) if this is OK to apply the fixed version? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 11:21:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Nov 2016 16:21:13 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479054073.91.0.614064396979.issue21449@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This issue is not just about readability or performance. It is about correctness, since none of callers check for failure of _PyUnicode_CompareWithId. I just came to the same problem from other side (replacing PyUnicode_CompareWithASCII with PyUnicode_EqualToASCII or _PyUnicode_CompareWithId). Josh's idea in general LGTM, but there are few details: 1. None of callers check for failure of new functions as well. In boolean context the failure is interpreted as true. What is even worse, an exception is set, and this can cause a crash in debug build. If we don't want to rewrite all the uses of _PyUnicode_CompareWithId by adding the code for checking return value for error, we should make new function never failing. _PyUnicode_CompareWithId can fail if the first argument is not valid string or if there is no memory for allocating a Unicode object for identifier. I think it is better to return false value in these circumstances. If the first argument is not string, it isn't equal to an identifier. If it is an invalid string, it can't be equal too. If there is no memory for allocating a Unicode object for identifier, we should fallback to comparing the raw content (like in PyUnicode_CompareWithASCII). 2. It may be worth to replace _PyUnicode_FromId with the macro: #define _PyUnicode_FROM_ID(id) ((id)->object ? (id)->object : _PyUnicode_FromId(id)) Or rename _PyUnicode_FromId to _PyUnicode_FromIdInternal and _PyUnicode_FROM_ID to _PyUnicode_FromId? This would save us from rewriting a lot of code that uses _PyUnicode_FromId. 3. The name _PyUnicode_CompareWithIdEqual looks too long to me. What about _PyUnicode_EqualToId? 4. Pointers could be checked for equality before checking PyUnicode_CHECK_INTERNED(left). The former check is much cheaper than the latter. ---------- components: +Interpreter Core, Unicode nosy: +ezio.melotti, serhiy.storchaka type: -> behavior versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 11:43:01 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 13 Nov 2016 16:43:01 +0000 Subject: [issue28677] difficult to parse sentence structure in "When an instance attribute is referenced that isn't a data attribute" In-Reply-To: <1478986337.93.0.398450030776.issue28677@psf.upfronthosting.co.za> Message-ID: <1479055381.6.0.996322835514.issue28677@psf.upfronthosting.co.za> R. David Murray added the comment: "instance parent class" is not terminology used in our docs as far as I remember. "instance's class" would be more in line with the other docs. That would solve the pronoun reference problem more succinctly, I think. How about this version, which also improves the awkward phrasing, but without using em-dashes: "When a non-data attribute of an instance is referenced, the instance's class is searched." ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 12:02:58 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sun, 13 Nov 2016 17:02:58 +0000 Subject: [issue24379] Add operator.subscript as a convenience for creating slices In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1479056578.07.0.428341946408.issue24379@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Serhiy, thank you for review! Here is a corrected patch. ---------- Added file: http://bugs.python.org/file45473/operator_subscript_norefleak_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 12:21:19 2016 From: report at bugs.python.org (Elvis Pranskevichus) Date: Sun, 13 Nov 2016 17:21:19 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1479057679.26.0.692155287071.issue28635@psf.upfronthosting.co.za> Elvis Pranskevichus added the comment: Patch with updates attached. Thanks for the feedback guys! ---------- Added file: http://bugs.python.org/file45474/0001-Issue-28635-what-s-new-in-3.6-add-a-few-more-notes-o.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 12:24:11 2016 From: report at bugs.python.org (R. David Murray) Date: Sun, 13 Nov 2016 17:24:11 +0000 Subject: [issue28681] About function renaming in the tutorial In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za> Message-ID: <1479057851.66.0.0126534633545.issue28681@psf.upfronthosting.co.za> R. David Murray added the comment: I would rewrite that paragraph as follows: A function definition associates the function name with the function object in the current symbol table. The interpreter recognizes the object pointed to by that name as a user-defined function. Other names can also point to that same function object and can then also be used as a function. You will note that I've dropped the mention of renaming entirely, since the function does know it's __name__, and introducing that topic at this point in the tutorial would be confusing and unnecessary. (NB: one could also say "referenced" and "reference" rather than "pointed to" and "point to"; I'm not sure which is more in line with the rest of the tutorial). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 12:25:06 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Nov 2016 17:25:06 +0000 Subject: [issue24379] Add operator.subscript as a convenience for creating slices In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1479057906.12.0.0594531809321.issue24379@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: operator_subscript_norefleak_v2.patch LGTM. Waiting for Ned's decision about 3.6. ---------- assignee: -> ned.deily priority: normal -> release blocker stage: patch review -> commit review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 13:40:28 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 13 Nov 2016 18:40:28 +0000 Subject: [issue24379] Add operator.subscript as a convenience for creating slices In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1479062428.17.0.148143612817.issue24379@psf.upfronthosting.co.za> Ned Deily added the comment: I don't think this is appropriate for 3.6 now. We're a little more than 4 weeks from the final release - way past the feature code cut-off - and, from the comments here, there is no longer a total consensus that this feature should go back in at all after being pulled and largely forgotten about for a year. ---------- assignee: ned.deily -> priority: release blocker -> normal versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 14:14:21 2016 From: report at bugs.python.org (Viorel Tabara) Date: Sun, 13 Nov 2016 19:14:21 +0000 Subject: [issue28677] difficult to parse sentence structure in "When an instance attribute is referenced that isn't a data attribute" In-Reply-To: <1478986337.93.0.398450030776.issue28677@psf.upfronthosting.co.za> Message-ID: <1479064461.55.0.577384074812.issue28677@psf.upfronthosting.co.za> Viorel Tabara added the comment: David, that sounds clear enough to me, thanks. However, English isn't my first language so I can't comment on the grammatical subtleties. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 14:32:04 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 13 Nov 2016 19:32:04 +0000 Subject: [issue28683] bind() on a unix socket raises PermissionError on Android for a non-root user Message-ID: <1479065524.08.0.12999801833.issue28683@psf.upfronthosting.co.za> New submission from Xavier de Gaye: Tests in test_socket and test_asyncore fail on Android when bind() on a unix socket raises PermissionError for a non-root user. This occurs also in test_asyncio and this is logged in a separate issue as asyncio has its own project. Patch attached. ---------- assignee: xdegaye components: Tests files: bind_unix_socket.patch keywords: patch messages: 280709 nosy: xdegaye priority: normal severity: normal stage: patch review status: open title: bind() on a unix socket raises PermissionError on Android for a non-root user type: behavior versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45475/bind_unix_socket.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 15:14:38 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 Nov 2016 20:14:38 +0000 Subject: [issue26934] android: test_faulthandler fails In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za> Message-ID: <20161113201435.12099.66215.E9A7ADE8@psf.io> Roundup Robot added the comment: New changeset 66aac9676a28 by Xavier de Gaye in branch 'default': Issue #26934: Fix test_faulthandler on Android where raise() exits with 0, https://hg.python.org/cpython/rev/66aac9676a28 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 15:17:52 2016 From: report at bugs.python.org (Julien) Date: Sun, 13 Nov 2016 20:17:52 +0000 Subject: [issue10444] A mechanism is needed to override waiting for Python threads to finish In-Reply-To: <1290002661.34.0.535369286873.issue10444@psf.upfronthosting.co.za> Message-ID: <1479068272.81.0.819653227047.issue10444@psf.upfronthosting.co.za> Julien added the comment: `daemon` flag cannot be changed after thread is started, the documentation is right and the code of the daemon setter is actually: if self._started.is_set(): raise RuntimeError("cannot set daemon status of active thread") But still it looks like a code review problem: all your daemonic threads should be created as daemonic. Breaking the `daemon` semantics looks like a bug magnet: any future uses of non-daemonic threads (by an "experienced" developer of your team, specifically needing a non-daemon thread for a specific task) will behave as a deamon thread and the specific task may not be correctly executed (like, logging an exception?). ---------- nosy: +sizeof _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 15:18:34 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 13 Nov 2016 20:18:34 +0000 Subject: [issue26934] android: test_faulthandler fails In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za> Message-ID: <1479068314.0.0.495296034978.issue26934@psf.upfronthosting.co.za> Xavier de Gaye added the comment: New changeset f37ac1a003f3 in branch 3.6. New changeset 892f13827219 in branch default. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 15:19:56 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 13 Nov 2016 20:19:56 +0000 Subject: [issue26934] android: test_faulthandler fails In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za> Message-ID: <1479068396.89.0.121204339225.issue26934@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 15:31:31 2016 From: report at bugs.python.org (SilentGhost) Date: Sun, 13 Nov 2016 20:31:31 +0000 Subject: [issue26934] android: test_faulthandler fails In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za> Message-ID: <1479069091.7.0.353081316125.issue26934@psf.upfronthosting.co.za> SilentGhost added the comment: Buildbots fail since _ANDROID_API_LEVEL could end up being None ---------- nosy: +SilentGhost status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 15:39:34 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 13 Nov 2016 20:39:34 +0000 Subject: [issue28684] [asyncio] bind() on a unix socket raises PermissionError on Android for a non-root user Message-ID: <1479069574.19.0.731580166174.issue28684@psf.upfronthosting.co.za> New submission from Xavier de Gaye: Tests in test_asyncio fail on Android when bind() on a unix socket raises PermissionError for a non-root user. See the attached test_asyncio.log. See also issue 28683 and its patch(es). ---------- components: Tests, asyncio files: test_asyncio.log messages: 280714 nosy: giampaolo.rodola, gvanrossum, haypo, xdegaye, yselivanov priority: normal severity: normal stage: needs patch status: open title: [asyncio] bind() on a unix socket raises PermissionError on Android for a non-root user type: behavior versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45476/test_asyncio.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 15:57:32 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 Nov 2016 20:57:32 +0000 Subject: [issue26934] android: test_faulthandler fails In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za> Message-ID: <20161113205729.61259.7299.E36A58BC@psf.io> Roundup Robot added the comment: New changeset 2639afcedaad by Xavier de Gaye in branch '3.6': Issue #26934: Handle _ANDROID_API_LEVEL is None on Windows https://hg.python.org/cpython/rev/2639afcedaad New changeset 4012e28539c4 by Xavier de Gaye in branch 'default': Issue #26934: Merge 3.6 https://hg.python.org/cpython/rev/4012e28539c4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 15:58:18 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sun, 13 Nov 2016 20:58:18 +0000 Subject: [issue24379] Add operator.subscript as a convenience for creating slices In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1479070698.88.0.686929460524.issue24379@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Maybe then it makes sense to apply this to 3.7? It looks like most people are in favour of this (also on python-ideas), only Raymond is not sure/mildly against. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 16:09:46 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 13 Nov 2016 21:09:46 +0000 Subject: [issue28646] Using a read-only buffer. In-Reply-To: <1478664292.05.0.145705220958.issue28646@psf.upfronthosting.co.za> Message-ID: <1479071386.63.0.687061135652.issue28646@psf.upfronthosting.co.za> Martin Panter added the comment: Issue 11427 has some discussion about this. It seems one concern was to make it hard to modify the buffer of a bytes object (which is supposed to be immutable). But I agree there should be an easy way to access read-only buffers in ctypes. Perhaps that could be by relaxing from_buffer(), or perhaps by some safer or more explicit API. See also Issue 11429, complaining about scattered support of writable buffers elsewhere, and using bytes objects with an offset. ---------- nosy: +martin.panter versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 16:19:40 2016 From: report at bugs.python.org (Elliot Gorokhovsky) Date: Sun, 13 Nov 2016 21:19:40 +0000 Subject: [issue28685] Optimizing list.sort() by performing safety checks in advance Message-ID: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za> New submission from Elliot Gorokhovsky: When python compares two objects, there are many safety checks that have to be performed before the actual comparison can take place. These include checking the types of the two objects, as well as checking various type-specific properties, like character width for strings or the number of machine-words that represent a long. Obviously, the vast majority of the work done during a list.sort() is spent in comparisons, so even small optimizations can be important. What I noticed is that since we have n objects, but we're doing O(nlogn) comparisons, it pays off to do all the safety checks in a single pass and then select an optimized comparison function that leverages the information gained to avoid as many sort-time checks as possible. I made the following assumptions: 1. In practice, lists to be sorted are almost always type-homogeneous. 2. Most lists to be sorted consist of homogeneous elements of the following types: a. Latin strings (i.e. strings whose characters are one machine-word wide) b. Longs that fit in a single machine-word c. Floats d. Tuples of the above 3. The above assumptions also hold for lists constructed by taking a list of tuples to be sorted and extracting the first elements. 4. The vast majority of tuple comparisons never get past the first element (i.e. the first elements of tuples are rarely equal). My patch adds the following routine to list.sort(): 1. Go through the list and see which of the assumptions, if any, hold (except (4), which can't be checked in advance). 2. Replace PyObject_RichCompareBool() with an optimized compare function that is able to ignore some safety checks by applying the assumption we've already verified to be true. There are then two questions: when none of the assumptions hold, how expensive is (1)? And when we do get a "hit", how much time do we save by applying (2)? Those questions, of course, can only be answered by benchmarks. So here they are, computed on an isolated CPU core, on two python interpreters, both compiled with ./configure --with-optimizations: # This is a runnable script. Just build the reference interpreter in python-ref and the patched interpreter in python-dev. # Pathological cases (where we pay for (1) but don't get any savings from (2)): what kind of losses do we suffer? # How expensive is (1) for empty lists? python-dev/python -m perf timeit -s "l=[]" "sorted(l)" --rigorous python-ref/python -m perf timeit -s "l=[]" "sorted(l)" --rigorous # Median +- std dev: 212 ns +- 9 ns # Median +- std dev: 216 ns +- 10 ns # (difference is within std dev) # How expensive is (1) for singleton lists? python-dev/python -m perf timeit -s "l=[None]" "sorted(l)" --rigorous python-ref/python -m perf timeit -s "l=[None]" "sorted(l)" --rigorous # Median +- std dev: 235 ns +- 16 ns # Median +- std dev: 238 ns +- 15 ns # (difference is within std dev) # How expensive is (1) for non-type-homogeneous lists? # (we use small lists because as n gets large, the fraction time spent in (1) gets smaller) python-dev/python -m perf timeit -s "import random; l=[random.uniform(-1,1) for _ in range(0,10)]+[1]" "sorted(l)" --rigorous python-ref/python -m perf timeit -s "import random; l=[random.uniform(-1,1) for _ in range(0,10)]+[1]" "sorted(l)" --rigorous # Median +- std dev: 784 ns +- 35 ns # Median +- std dev: 707 ns +- 51 ns # 10% slower. While this is unfortunate, this case almost never occurs in practice, and the losses are certainly offset by the gains we'll see below. # Also, note that for large lists, the difference would be *much* smaller, since the time spent in (1) gets smaller like 1/log(n). # So basically, we only pay a penalty for non-type-homogeneous small lists. # OK, now for the cases that actually occur in practice: # What kind of gains do we get for floats? python-dev/python -m perf timeit -s "import random; l=[random.uniform(-1,1) for _ in range(0,100)]" "sorted(l)" --rigorous python-ref/python -m perf timeit -s "import random; l=[random.uniform(-1,1) for _ in range(0,100)]" "sorted(l)" --rigorous # Median +- std dev: 3.63 us +- 0.20 us # Median +- std dev: 8.81 us +- 0.37 us # Wow! 59% faster! And if we used a large list, we would've gotten even better numbers. # What kind of gains do we get for latin strings? python-dev/python -m perf timeit -s "import random; l=[str(random.uniform(-1,1)) for _ in range(0,100)]" "sorted(l)" --rigorous python-ref/python -m perf timeit -s "import random; l=[str(random.uniform(-1,1)) for _ in range(0,100)]" "sorted(l)" --rigorous # Median +- std dev: 9.51 us +- 0.28 us # Median +- std dev: 15.9 us +- 0.7 us # 40% faster! # What kind of gains do we get for non-latin strings (which I imagine aren't that common to sort in practice anyway) python-dev/python -m perf timeit -s "import random; l=[str(random.uniform(-1,1))+'\uffff' for _ in range(0,100)]" "sorted(l)" --rigorous python-ref/python -m perf timeit -s "import random; l=[str(random.uniform(-1,1))+'\uffff' for _ in range(0,100)]" "sorted(l)" --rigorous # Median +- std dev: 12.2 us +- 0.4 us # Median +- std dev: 14.2 us +- 0.6 us # 14%. Not as impressive, but again, this is a bit of a pathological case. # What kind of gains do we get for ints that fit in a machine word? (I'll keep them in (-2^15,2^15) to be safe) python-dev/python -m perf timeit -s "import random; l=[int(random.uniform(-1,1)*2**15) for _ in range(0,100)]" "sorted(l)" --rigorous python-ref/python -m perf timeit -s "import random; l=[int(random.uniform(-1,1)*2**15) for _ in range(0,100)]" "sorted(l)" --rigorous # Median +- std dev: 4.92 us +- 0.35 us # Median +- std dev: 9.59 us +- 0.75 us # 49% faster. Pretty cool stuff! # What kind of gains do we get for pathologically large ints? python-dev/python -m perf timeit -s "import random; l=[int(random.uniform(-1,1)*2**100) for _ in range(0,100)]" "sorted(l)" --rigorous python-ref/python -m perf timeit -s "import random; l=[int(random.uniform(-1,1)*2**100) for _ in range(0,100)]" "sorted(l)" --rigorous # Median +- std dev: 6.93 us +- 0.26 us # Median +- std dev: 8.93 us +- 0.23 us # 22% faster. The same comparison function is used as in the pathological string case, but the numbers are different because comparing strings # is more expensive than comparing ints, so we save less time from skipping the type checks. Regardless, 22% is still pretty cool. And I can't # imagine it's that common to sort huge ints anyway, unless you're doing some sort of math conjecture testing or something. # What kind of gains do we get for tuples whose first elements are floats? python-dev/python -m perf timeit -s "import random; l=[(random.uniform(-1,1), 'whatever') for _ in range(0,100)]" "sorted(l)" --rigorous python-ref/python -m perf timeit -s "import random; l=[(random.uniform(-1,1), 'whatever') for _ in range(0,100)]" "sorted(l)" --rigorous # Median +- std dev: 5.83 us +- 0.50 us # Median +- std dev: 21.5 us +- 0.5 us # WOW! 73% faster! # A note: I know of at least one application where this is relevant. The DEAP evolutionary algorithms library, which is very popular, has to sort # tuples of floats when it's selecting individuals for the next generation. It spends a non-trivial amount of time sorting those tuples of floats, # and this patch cuts that non-trivial time by 73%! Pretty cool! Now we can evolve more individuals more better! # What kind of gains do we get for tuples whose first elements are latin strings? python-dev/python -m perf timeit -s "import random; l=[(str(random.uniform(-1,1)), 42) for _ in range(0,100)]" "sorted(l)" --rigorous python-ref/python -m perf timeit -s "import random; l=[(str(random.uniform(-1,1)), 42) for _ in range(0,100)]" "sorted(l)" --rigorous # Median +- std dev: 14.9 us +- 0.8 us # Median +- std dev: 31.2 us +- 1.3 us # 52%. Not too shabby! # What kind of gains do we get for tuples of other stuff? # Obviously there are lots of combinations possible, I won't waste your time documenting all of them. # Suffice it to say that the gains for lists tuples of x is always greater than the gains for lists of x, since we bypass # two layers of safety checks: checks on the tuples, and then checks on the x. # What kind of gains do we for arbitrary lists of objects of the same type? # See the benchmarks for large ints and non-latin strings. It will be different for each object, since it depends on the ratio between # the cost of type-check and the cost of comparison. Regardless, it is always non-trivial, unless the cost of comparison is huge. # End of script # TL;DR: This patch makes common list.sort() cases 40-75% faster, and makes very uncommon pathological cases at worst 15% slower. It accomplishes this by performing the endless, but necessary, safety checks involved in comparison up front, and then using optimized compares that ignore the already-performed checks during the actual sort. ---------- components: Interpreter Core files: fastsort.patch keywords: patch messages: 280718 nosy: elliot.gorokhovsky priority: normal severity: normal status: open title: Optimizing list.sort() by performing safety checks in advance type: performance versions: Python 3.7 Added file: http://bugs.python.org/file45477/fastsort.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 17:05:39 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 13 Nov 2016 22:05:39 +0000 Subject: [issue28678] tarfile extract docs inconsistent naming of parameter numeric_owner or numeric_only In-Reply-To: <1478986997.97.0.266901565228.issue28678@psf.upfronthosting.co.za> Message-ID: <1479074739.53.0.182676067545.issue28678@psf.upfronthosting.co.za> Martin Panter added the comment: The offending commit is revision 6b70f16d585a. The true name is numeric_owner; numeric_only is wrong. The name also needs fixing in Doc/whatsnew/3.5.rst. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 17:11:01 2016 From: report at bugs.python.org (Julien) Date: Sun, 13 Nov 2016 22:11:01 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1479075061.19.0.714591067396.issue24339@psf.upfronthosting.co.za> Julien added the comment: Hi John, thanks for your contribution, Looks like your implementation is missing some codepoints, like "\t": >>> print("\t".encode(encoding='iso6937')) [...] UnicodeError: encoding with 'iso6937' codec failed (UnicodeError: Unacceptable utf-8 character) Probably due to the "range(0x20, "?, why `0x20`? You're having problems to decode multibytes sequences as you're not having the `else: ? result += chr(c[0])` in this case. So typically decoding `\xc2\x20` will raise a `KeyError` as `\x20` is _not_ in your decoding table. Also, please conform your contribution to the PEP8: you're missing spaces after comas and you're sometime indenting with 8 spaces instead of 4. I implemented a simple checker based on glibc localedata, it show clearly your decoding problems step by step, and should be easily extended to check for your encoding function too, see attachment. It uses the ISO6937 found typically in the locales debian package or in an 'apt-get sourcee glibc'. ---------- nosy: +sizeof Added file: http://bugs.python.org/file45478/check_iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 17:39:32 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 13 Nov 2016 22:39:32 +0000 Subject: [issue24379] Add operator.subscript as a convenience for creating slices In-Reply-To: <1479070698.88.0.686929460524.issue24379@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Actually I'm with Raymond -- I'm also not sure or mildly against (-0). Given how easy it is to do without and how cumbersome using the operator module is I don't see a great benefit. (IMO the operator module should be the measure of *last* resort -- it is not to become part of anybody's toolkit for common operators. But I seem to be a minority opinion here.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 18:04:31 2016 From: report at bugs.python.org (Elliot Gorokhovsky) Date: Sun, 13 Nov 2016 23:04:31 +0000 Subject: [issue28685] Optimizing list.sort() by performing safety checks in advance In-Reply-To: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za> Message-ID: <1479078271.15.0.780607396518.issue28685@psf.upfronthosting.co.za> Changes by Elliot Gorokhovsky : ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 18:53:23 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 Nov 2016 23:53:23 +0000 Subject: [issue28678] tarfile extract docs inconsistent naming of parameter numeric_owner or numeric_only In-Reply-To: <1478986997.97.0.266901565228.issue28678@psf.upfronthosting.co.za> Message-ID: <20161113235320.59692.24171.F7078C48@psf.io> Roundup Robot added the comment: New changeset 4aca14dbb66d by Martin Panter in branch '3.5': Issue #28678: Fix references to numeric_owner parameter https://hg.python.org/cpython/rev/4aca14dbb66d New changeset 5efa1a39ee59 by Martin Panter in branch '3.6': Issue #28678: Merge parameter name from 3.5 into 3.6 https://hg.python.org/cpython/rev/5efa1a39ee59 New changeset 817a003ecdc6 by Martin Panter in branch 'default': Issue #28678: Merge parameter name from 3.6 https://hg.python.org/cpython/rev/817a003ecdc6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 19:29:36 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 14 Nov 2016 00:29:36 +0000 Subject: [issue28678] tarfile extract docs inconsistent naming of parameter numeric_owner or numeric_only In-Reply-To: <1478986997.97.0.266901565228.issue28678@psf.upfronthosting.co.za> Message-ID: <1479083376.82.0.548688009803.issue28678@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks Lewis ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 19:58:46 2016 From: report at bugs.python.org (Joshua Jay Herman) Date: Mon, 14 Nov 2016 00:58:46 +0000 Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> Message-ID: <1479085126.62.0.897931113496.issue24459@psf.upfronthosting.co.za> Joshua Jay Herman added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 20:05:57 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 14 Nov 2016 01:05:57 +0000 Subject: [issue23839] Clear caches after every test In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za> Message-ID: <1479085557.28.0.240839702774.issue23839@psf.upfronthosting.co.za> Martin Panter added the comment: When I run the tests with -Werror (or any other -W option), I now get 2 tests altered the execution environment: test___all__ test_warnings ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 20:45:51 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 14 Nov 2016 01:45:51 +0000 Subject: [issue8840] truncate() semantics changed in 3.1.2 In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za> Message-ID: <1479087951.93.0.504746021883.issue8840@psf.upfronthosting.co.za> Martin Panter added the comment: In general I agree with the doc strings giving the main details, and leaving smaller details for the reference documentation. Maybe for concrete implementations like BytesIO, it is not worth saying the expanded contents are undefined. One other way to make them shorter is to drop ?as reported by tell()?. diff --git a/Lib/_pyio.py b/Lib/_pyio.py @@ -344,10 +344,12 @@ def truncate(self, pos=None): + """Resize stream to at most size bytes. Wouldn?t it be more correct to say ?at most ?pos? bytes?? You should avoid mentioning byte sizes for TextIOBase.truncate(); see Issue 25849. Also applies to the StringIO subclasses. + Position in the stream is left unchanged. Size defaults to I think it should be ?The position in the stream . . .?, to match the other full sentences in these paragraphs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 20:57:56 2016 From: report at bugs.python.org (Antony Lee) Date: Mon, 14 Nov 2016 01:57:56 +0000 Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> Message-ID: <1479088676.95.0.859783598665.issue24459@psf.upfronthosting.co.za> Changes by Antony Lee : ---------- nosy: -Antony.Lee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 21:12:46 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 14 Nov 2016 02:12:46 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1479089566.96.0.289306118191.issue24339@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 22:10:51 2016 From: report at bugs.python.org (Vinay Anantharaman) Date: Mon, 14 Nov 2016 03:10:51 +0000 Subject: [issue14119] Ability to adjust queue size in Executors In-Reply-To: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za> Message-ID: <1479093051.12.0.871208992557.issue14119@psf.upfronthosting.co.za> Vinay Anantharaman added the comment: I did a code reading myself and I noticed that task_done is not called as well. Is there a reason? ---------- nosy: +Vinay Anantharaman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 13 22:10:56 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 14 Nov 2016 03:10:56 +0000 Subject: [issue28629] Emit ResourceWarning when implicitly terminating a suspended frame? In-Reply-To: <1478487031.39.0.63356302946.issue28629@psf.upfronthosting.co.za> Message-ID: <1479093056.25.0.977008903733.issue28629@psf.upfronthosting.co.za> Martin Panter added the comment: This would be hard to get right, but maybe not impossible. If the frame is suspended, and will do special handling of GeneratorExit, a ResourceWarning would be nice in most cases. But if the frame will not catch any exception, there should be no ResourceWarning. I think this is the big difference between mygen() and Victor?s generator expression: gen = (2**i for i in itertools.count()) next(gen) # Generator suspended but won?t catch any exception del gen # Like deleting a plain iterator; no ResourceWarning expected One more complication: If the frame is suspended at something like ?yield from open(fname)?, it should trigger a ResourceWarning, because GeneratorExit would cause the file?s close() method to be called. But if ?yield from? is calling a simpler generator-iterator with nothing to clean up, it should not emit a ResourceWarning. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 00:13:35 2016 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 14 Nov 2016 05:13:35 +0000 Subject: [issue27050] Demote run() below the high level APIs in subprocess docs In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za> Message-ID: <1479100415.33.0.795007419691.issue27050@psf.upfronthosting.co.za> Nick Coghlan added the comment: The introduction of run() and its presentation as the preferred interface has effectively reversed much of the progress that had been made in actually making the subprocess module approachable for the simplest use cases like https://twitter.com/fuzzychef/status/798025538237382656 (i.e. the exact case that "subprocess.call()" handles) It does make sense to have run() as an intermediate tier of complexity between the base trio of call/check_call/check_output, and the full configurability of Popen, so it isn't the introduction of the API itself that's problematic, just the way we're currently presenting it. ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 00:20:38 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 14 Nov 2016 05:20:38 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479100838.27.0.360666017353.issue21449@psf.upfronthosting.co.za> Xiang Zhang added the comment: > The name _PyUnicode_CompareWithIdEqual looks too long to me. What about _PyUnicode_EqualToId? +1. I think this name is more clear. Serhiy's idea on the implementation sounds good. As for _PyUnicode_FROM_ID, I think it's better for another issue. ---------- nosy: +xiang.zhang Added file: http://bugs.python.org/file45479/_PyUnicode_EqualToId.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 00:39:13 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Nov 2016 05:39:13 +0000 Subject: [issue28016] test_fileio fails on AIX In-Reply-To: <1473323328.73.0.215988699422.issue28016@psf.upfronthosting.co.za> Message-ID: <20161114053910.12237.62387.26A0D254@psf.io> Roundup Robot added the comment: New changeset a2ba15f05ed1 by Martin Panter in branch '3.5': Issue #28016: Skip /dev/tty seekable() test on AIX https://hg.python.org/cpython/rev/a2ba15f05ed1 New changeset b1f99e09bd77 by Martin Panter in branch '2.7': Issue #28016: Skip /dev/tty seekable() test on AIX https://hg.python.org/cpython/rev/b1f99e09bd77 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 00:39:13 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Nov 2016 05:39:13 +0000 Subject: [issue28000] Build fails on AIX with _LINUX_SOURCE_COMPAT flag In-Reply-To: <1473261703.53.0.692891859324.issue28000@psf.upfronthosting.co.za> Message-ID: <20161114053910.12237.17479.45148BF4@psf.io> Roundup Robot added the comment: New changeset 7598e65a924e by Martin Panter in branch '3.5': Issue #28000: Fix gethostbyname_r() usage on AIX with _LINUX_SOURCE_COMPAT https://hg.python.org/cpython/rev/7598e65a924e New changeset 77cb8fa47138 by Martin Panter in branch '2.7': Issue #28000: Fix gethostbyname_r() usage on AIX with _LINUX_SOURCE_COMPAT https://hg.python.org/cpython/rev/77cb8fa47138 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 00:47:55 2016 From: report at bugs.python.org (Thomas Kluyver) Date: Mon, 14 Nov 2016 05:47:55 +0000 Subject: [issue27050] Demote run() below the high level APIs in subprocess docs In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za> Message-ID: <1479102475.03.0.625184367612.issue27050@psf.upfronthosting.co.za> Thomas Kluyver added the comment: I still feel that having one function with various options is easier to explain than three separate functions with awkward names and limited use cases (e.g. no capturing output without checking the exit code). The tweeter you replied to said he didn't like subprocess.call(). If you really think the trio is a better starting point, though, you're the one with the power to change the docs ;-) There's more awkwardness in the subprocess API; I suspect that what that tweeter wants is something built around an event loop - like Node - so you can handle output incrementally using events. That's not something that we can easily fix in subprocess, because we don't have a default event loop to attach subprocesses to. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 01:01:06 2016 From: report at bugs.python.org (Evan) Date: Mon, 14 Nov 2016 06:01:06 +0000 Subject: [issue28595] shlex.shlex should not augment wordchars In-Reply-To: <1478166136.94.0.995190174918.issue28595@psf.upfronthosting.co.za> Message-ID: <1479103266.32.0.688909766789.issue28595@psf.upfronthosting.co.za> Evan added the comment: I have some additional concerns with the changes introduced in http://bugs.python.org/issue1521950: 1. The fact that posix defaults to False in shlex.shlex (but not in shlex.split) is a huge beginner trap. If users are expecting to use this for "compatibility with the parsing performed by common Unix shells like bash, dash, and sh", they must also remember to set posix=True. The documentation for punctuation_chars makes no mention of this. The examples use non-POSIX mode parsing rules. 2. Even with posix=True, there is no mechanism to escape characters that are special inside double quotes, like $. This is a separate unaddressed incompatibility. For 1, this could be fixed by making posix default to True if punctuation_chars is specified. Longer term, perhaps the default could be changed to True in all cases. I'm not sure what to do about 2. (Please let me know if I should split these out into separate issues.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 01:53:23 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 14 Nov 2016 06:53:23 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479106403.2.0.607355292983.issue21449@psf.upfronthosting.co.za> Changes by Xiang Zhang : Added file: http://bugs.python.org/file45480/_PyUnicode_EqualToId_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 02:12:22 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 14 Nov 2016 07:12:22 +0000 Subject: [issue28000] Build fails on AIX with _LINUX_SOURCE_COMPAT flag In-Reply-To: <1473261703.53.0.692891859324.issue28000@psf.upfronthosting.co.za> Message-ID: <1479107542.41.0.78771132386.issue28000@psf.upfronthosting.co.za> Martin Panter added the comment: I committed your patches for 3.5+ and 2.7. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 02:12:27 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 14 Nov 2016 07:12:27 +0000 Subject: [issue28016] test_fileio fails on AIX In-Reply-To: <1473323328.73.0.215988699422.issue28016@psf.upfronthosting.co.za> Message-ID: <1479107547.81.0.22813171248.issue28016@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 2.7, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 02:15:53 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Nov 2016 07:15:53 +0000 Subject: [issue28629] Emit ResourceWarning when implicitly terminating a suspended frame? In-Reply-To: <1479093056.25.0.977008903733.issue28629@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > del gen # Like deleting a plain iterator; no ResourceWarning expected Hum, wait, I'm not sure that I got the whole point of this issue. If the generator uses "with obj:", "del gen" will not call obj.__exit__(). Do you consider that "del gen" is better to clear obj than not known when gen and obj are destroyed? Is there a solution to call obj.__exit__()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 02:38:50 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 14 Nov 2016 07:38:50 +0000 Subject: [issue28629] Emit ResourceWarning when implicitly terminating a suspended frame? In-Reply-To: <1478487031.39.0.63356302946.issue28629@psf.upfronthosting.co.za> Message-ID: <1479109130.03.0.503959236573.issue28629@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps I shouldn?t have mentioned ?del gen?. That was meant to represent the garbage collector running and calling gen.__del__() or equivalent. Basically what I was trying to say is I think there will be two classes of generators: 1. Simple generators just implementing the plain iterator protocol, where there is nothing to clean up. In these cases a ResourceWarning is unwanted. Example: generator expressions. 2. Complex generators that have special cleanup code. Ideally the user should either exhaust the generator or call its close() method, and a ResourceWarning would be useful if neither of these happen. Example: Nick?s mygen(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 02:40:21 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 14 Nov 2016 07:40:21 +0000 Subject: [issue26934] android: test_faulthandler fails In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za> Message-ID: <1479109221.83.0.684432698257.issue26934@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 02:59:46 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 14 Nov 2016 07:59:46 +0000 Subject: [issue28629] Emit ResourceWarning when implicitly terminating a suspended frame? In-Reply-To: <1478487031.39.0.63356302946.issue28629@psf.upfronthosting.co.za> Message-ID: <1479110386.86.0.796859494427.issue28629@psf.upfronthosting.co.za> Martin Panter added the comment: BTW my understanding is that currently, if the garbage collector deletes a generator, it effectively calls its close() method. When close() is called, it throws GeneratorExit into the suspended generator. This is meant to cause all the ?with? and ?try? statements to clean up. So, yes, explicitly calling close() should immediately release the resources, call obj.__exit__(), etc. The idea of the ResourceWarning is to tell the programmer they forgot to call close(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 03:04:12 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 14 Nov 2016 08:04:12 +0000 Subject: [issue28023] python-gdb.py must be updated for the new Python 3.6 compact dict In-Reply-To: <1473351940.28.0.277088210884.issue28023@psf.upfronthosting.co.za> Message-ID: <1479110652.85.0.0209941394085.issue28023@psf.upfronthosting.co.za> INADA Naoki added the comment: @haypo, would you review this patch? ---------- versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 03:07:24 2016 From: report at bugs.python.org (wdhwg001) Date: Mon, 14 Nov 2016 08:07:24 +0000 Subject: [issue28686] py.exe ignored PATH when using python3 shebang Message-ID: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za> New submission from wdhwg001: https://github.com/pypa/virtualenv/issues/979 TL;DR py.exe does not search PATH when using `#! /usr/bin/env python3`. And the right steps I think should be: 1. Search ./ 2. Search PATH 3. Fallback to system installed Python 3 But currently py.exe seems only do Step 3 once the shebang has substring of `python3`. ---------- components: Windows messages: 280740 nosy: paul.moore, steve.dower, tim.golden, wdhwg001, zach.ware priority: normal severity: normal status: open title: py.exe ignored PATH when using python3 shebang type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 03:53:33 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 14 Nov 2016 08:53:33 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1479113613.56.0.546881386797.issue24339@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Another comment about coding style: please use \uXXXX hex code representations for the decoding map. The stdlib source code is normally kept ASCII compatible and, for codecs, the Unicode code point numbers make it easier to check the mappings for correctness. Thanks. PS: You will also have to sign a contributor agreement: https://www.python.org/psf/contrib/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 04:20:05 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Nov 2016 09:20:05 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479115205.48.0.62449993936.issue21449@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There are yet few subtle details. 1. _PyUnicode_FromId() uses UTF-8 for decoding from C string, but PyUnicode_CompareWithASCIIString() uses Latin1. Two ways of comparison can return different results. Currently all identifiers are ASCII, thus perhaps we can ignore this issue for a time. Perhaps the simplest solution is to make PyUnicode_FromId() using ASCII or Latin1. 2. PyUnicode_READY() can fail either because Unicode object is misformed or due to MemoryError. The former case is unavoidable error and returning false is good. But the latter can be temporary error and we should add a fallback, compare wchar_t * representation of non-ready Unicode object with char * representation of identifier. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 04:31:20 2016 From: report at bugs.python.org (Paul Moore) Date: Mon, 14 Nov 2016 09:31:20 +0000 Subject: [issue28686] py.exe ignored PATH when using python3 shebang In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za> Message-ID: <1479115880.59.0.532184399763.issue28686@psf.upfronthosting.co.za> Paul Moore added the comment: 1. I don't think searching . should be included - on Unix /usr/bin/env searches PATH, and I believe we should do the same here. 2. The PATH search does happen (from my reading of the code) but it looks for a "python3" command, which isn't available. Again this is the same behaviour as Unix, and so defensible, but given that Windows doesn't provide the versioned executables, it's less useful there. The biggest problem is that with "#!/usr/bin/env python3" the user clearly expects Python 3, and without versioned executables, we can't guarantee that on Windows for a PATH search. Whether not supporting this usage is worse than supporting it without a guarantee that you'll get Python 3, I'm not sure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 04:58:29 2016 From: report at bugs.python.org (wdhwg001) Date: Mon, 14 Nov 2016 09:58:29 +0000 Subject: [issue28686] py.exe ignored PATH when using python3 shebang In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za> Message-ID: <1479117509.97.0.860412172622.issue28686@psf.upfronthosting.co.za> wdhwg001 added the comment: But actually after I created a `python3.bat` into venv/Scripts, the shebang `#! /usr/bin/env python3` still does not take the `python3.bat`. Then I created a hardlink from `python.exe` to `python3.exe`, the shebang still does not work. I didn't check the code of py.exe, but it just behave like it may not search the PATH of current session correctly. More details were updated on github: https://github.com/pypa/virtualenv/issues/979 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 05:10:24 2016 From: report at bugs.python.org (wdhwg001) Date: Mon, 14 Nov 2016 10:10:24 +0000 Subject: [issue28686] py.exe ignored PATH when using python3 shebang In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za> Message-ID: <1479118224.92.0.440914412412.issue28686@psf.upfronthosting.co.za> wdhwg001 added the comment: And during the entire testing procedure, `C:\Users\wdhwg001\study\venv\Scripts` was manually added to user `PATH` and system `PATH`, but `py.exe` cannot find the hardlinked `python3.exe` in there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 05:38:20 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 14 Nov 2016 10:38:20 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479119900.28.0.177501219244.issue21449@psf.upfronthosting.co.za> Xiang Zhang added the comment: _PyUnicode_FromId could fail due to memoryerror or bad encoded data. They should be treated differently like PyUnicode_READY. Could we treat it like PyDict_GetItem? If memoryerror happens it's highly possible other parts will fail too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 05:38:47 2016 From: report at bugs.python.org (Igor Skochinsky) Date: Mon, 14 Nov 2016 10:38:47 +0000 Subject: [issue28687] Python 2.7.12 windows x64 installer fails after previous bad uninstall Message-ID: <1479119927.24.0.974377093409.issue28687@psf.upfronthosting.co.za> New submission from Igor Skochinsky: It's somewhat my fault but I think it's not such an uncommon scenario. I had installed 2.7.10 x64 some time ago into C:\Python27_64 but then had to delete it to save space. Rather foolishly instead of using the uninstaller, I just trashed the directory and now I have a problem: neither the Control Panel uninstall item, nor the fresh 2.7.12 installer work. The latter fails when it tries to use the nonexisting Python to remove pip: -------------------------------- MSI (s) (04:B0) [11:00:09:881]: Product: Python 2.7.10 (64-bit) -- Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: RemovePip, location: C:\Python27_64\python.exe, command: -B -m ensurepip._uninstall -------------------------------- In the UI just the first message is shown, without the failed commandline, so it's not at all clear what went wrong. I think at the very least the user should be informed about the failed command so they can clean up the old installer's remains, or maybe the installation should be allowed to proceed anyway, replacing the bad paths in the registry. In the end, I had to use "Msizap TWA {E2B51919-207A-43EB-AE78-733F9C6797C3}" after which I could install 2.7.12 into a separate directory ---------- components: Installation messages: 280747 nosy: Igor.Skochinsky priority: normal severity: normal status: open title: Python 2.7.12 windows x64 installer fails after previous bad uninstall type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 05:41:11 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 14 Nov 2016 10:41:11 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1479120071.75.0.584727415183.issue28618@psf.upfronthosting.co.za> INADA Naoki added the comment: How about marking lookdict_unicode and lookdict_unicode_nodummy as hot? ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 05:53:18 2016 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 14 Nov 2016 10:53:18 +0000 Subject: [issue27050] Demote run() below the high level APIs in subprocess docs In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za> Message-ID: <1479120798.62.0.265494154834.issue27050@psf.upfronthosting.co.za> Nick Coghlan added the comment: Indeed, further discussion showed that what they were after was something more along the lines of sarge.Capture: http://sarge.readthedocs.io/en/latest/overview.html#main-features That is, the ability to start the subprocess running in the background, and access the output line-by-line, but with the precise mechanics of how that works being a hidden implementation detail (just as concurrent.futures hides the details of the inter-process communication for function calls). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 06:04:36 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 14 Nov 2016 11:04:36 +0000 Subject: [issue28673] When using pyro4 with more than 15 threads, python 2.7.12 cores frequently In-Reply-To: <1478939498.33.0.0967391900201.issue28673@psf.upfronthosting.co.za> Message-ID: <1479121476.42.0.583431896069.issue28673@psf.upfronthosting.co.za> INADA Naoki added the comment: Traceback tells: #22 0x00000000005a52db in PyInterpreterState_Clear (interp=0x95ac80) at ../Python/pystate.c:111 Py_CLEAR(interp->sysdict); While cleaning up interp->sysdict... #19 0x00000000004d86c6 in tb_dealloc.46270 (tb=0x7f0aa1278f38) at ../Python/traceback.c:28 #20 0x00000000004d87e1 in tb_dealloc.46270 (tb=0x7f0aa1278ea8) at ../Python/traceback.c:27 Removing some traceback from sysdict. Maybe, sys.exc_traceback. #17 0x00000000004c56e7 in subtype_dealloc.25650 ( self=, acquire=, _Condition__waiters=[], release=) at remote 0x7f0a9e9241d0>) at remote 0x7f0a9e924190>, objectsById={'root': , _operations={'cookie_9de0e8d93ed84452a1ce8cc92268979e': , _lock=<_RLock(_Verbose__verbose=False, _RLock__owner=None, _RLock__block=, _RLock__count=0) at remote 0x7f0a9e936190>, _started_at=, cookie='cookie_9de0e8d93ed84452a1ce8cc92268979e', _complete=<_Condition(_Condition__lock=...(truncated)) at ../Objects/typeobject.c:1035 #18 0x0000000000534b93 in frame_dealloc.14921 (f=Frame 0x7f0a9f6d49d8, for file /etc/remoting/remoting_agent.zip/Pyro4/socketserver/threadpool.py, line 39, in run ()) at ../Objects/frameobject.c:458 Removing frame object owned by the traceback. ... #7 PyEval_EvalFrameEx (f=f at entry=Frame 0x7f0a40000b50, for file /etc/remoting/remoting_agent.zip/Pyro4/socketutil.py, line 453, in __del__ (self=), throwflag=throwflag at entry=0) at ../Python/ceval.c:2987 #4 PyEval_EvalFrameEx (f=f at entry=Frame 0x7f0a9e929b60, for file /etc/remoting/remoting_agent.zip/Pyro4/socketutil.py, line 463, in close (self=), throwflag=throwflag at entry=0) at ../Python/ceval.c:3251 Calling SocketConnection.__del__. It calls SocketConnection.close. #3 0x000000000055acc0 in set_exc_info (tb=, value=exceptions.AttributeError("'NoneType' object has no attribute 'SHUT_RDWR'",), type=, tstate=0x95ad10) at ../Python/ceval.c:3736 SocketConnection.close raise AttributeError. #2 PySys_SetObject (name=name at entry=0x61d02a "exc_type", v=v at entry=) at ../Python/sysmodule.c:83 Trying to register the exception to sys. #0 PyDict_SetItem (op=op at entry=0x0, key=key at entry='exc_type', value=value at entry=) at ../Objects/dictobject.c:832 But interp->sysdict is NULL already. ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 06:28:39 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 14 Nov 2016 11:28:39 +0000 Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> Message-ID: <1479122919.52.0.769662122436.issue24459@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the updated patch, Joshua. I will review and commit it this week. ---------- versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 06:37:44 2016 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 14 Nov 2016 11:37:44 +0000 Subject: [issue28629] Emit ResourceWarning when implicitly terminating a suspended frame? In-Reply-To: <1478487031.39.0.63356302946.issue28629@psf.upfronthosting.co.za> Message-ID: <1479123464.82.0.469895350315.issue28629@psf.upfronthosting.co.za> Nick Coghlan added the comment: Martin raises an interesting point - the cases where ResourceWarning is likely to be appropriate are going to be those where the frame has been suspended inside a with statement or a try/finally statement. However, we don't currently track those at runtime or at compile time in any way - they're implicit in the state of the frame stack. That doesn't mean we *couldn't* track them though, and I think co_lnotab provides a hint as to how we could do it with minimal runtime overhead: add a new co_cleanup data table to code objects that provides efficiently packed storage for a sequence of "setup/cleanup" bytecode offset 2-tuples. All code objects would gain an additional pointer, and those that used with and try/finally would get fractionally larger than that, but frame objects would remain the same size they are today. Glossing over the complexities of large bytecode offsets (ala co_lnotab), consider: >>> def g_with(): ... with ...: ... pass ... >>> dis.dis(g_with) 2 0 LOAD_CONST 1 (Ellipsis) 3 SETUP_WITH 5 (to 11) 6 POP_TOP 3 7 POP_BLOCK 8 LOAD_CONST 0 (None) >> 11 WITH_CLEANUP_START 12 WITH_CLEANUP_FINISH 13 END_FINALLY 14 LOAD_CONST 0 (None) 17 RETURN_VALUE Here, co_cleanup would include a single 2-tuple with '0x03' as an absolute offset (for the setup) and '0x08' as a relative offset (for the cleanup). If '(f_lasti - 0x03) < 0x08' then __del__ on a generator-iterator or coroutine would raise ResourceWarning. >>> def g_finally(): ... try: ... pass ... finally: ... pass ... >>> dis.dis(g_finally) 2 0 SETUP_FINALLY 4 (to 7) 3 3 POP_BLOCK 4 LOAD_CONST 0 (None) 5 >> 7 END_FINALLY 8 LOAD_CONST 0 (None) 11 RETURN_VALUE Here, co_cleanup would include a single 2-tuple with '0x00' as an absolute offset (for the setup) and '0x07' as a relative offset (for the cleanup). If '(f_lasti - 0x00) < 0x07' then __del__ on a generator-iterator or coroutine would raise ResourceWarning. The key is that *only* __del__ would get slower (not explicit close() calls), and it would only get slower in cases where the frame was still suspended *and* co_cleanup was populated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 06:40:55 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Nov 2016 11:40:55 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <20161114114052.7925.43299.BEE99AA1@psf.io> Roundup Robot added the comment: New changeset 5fd69d4a93e0 by Victor Stinner in branch '3.6': Issue #28637: Reapply changeset 223731925d06 https://hg.python.org/cpython/rev/5fd69d4a93e0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 06:40:55 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Nov 2016 11:40:55 +0000 Subject: [issue28082] re: convert re flags to (much friendlier) IntFlag constants In-Reply-To: <1473625770.04.0.107359046953.issue28082@psf.upfronthosting.co.za> Message-ID: <20161114114052.7925.98159.F8B7B6CC@psf.io> Roundup Robot added the comment: New changeset 5fd69d4a93e0 by Victor Stinner in branch '3.6': Issue #28637: Reapply changeset 223731925d06 https://hg.python.org/cpython/rev/5fd69d4a93e0 New changeset be66786e95de by Victor Stinner in branch '3.6': Issue #28082: Add basic unit tests on re enums https://hg.python.org/cpython/rev/be66786e95de ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 06:42:31 2016 From: report at bugs.python.org (Michael Foord) Date: Mon, 14 Nov 2016 11:42:31 +0000 Subject: [issue28569] mock.attach_mock should work with any return value of patch() In-Reply-To: <1477935134.31.0.733482108189.issue28569@psf.upfronthosting.co.za> Message-ID: <1479123751.36.0.528401916919.issue28569@psf.upfronthosting.co.za> Michael Foord added the comment: It should be perfectly valid to use attach_mock with an attribute that doesn't already exist. Part of it's purpose is to create new attributes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 06:45:00 2016 From: report at bugs.python.org (Syed Suhail Ahmed) Date: Mon, 14 Nov 2016 11:45:00 +0000 Subject: [issue28569] mock.attach_mock should work with any return value of patch() In-Reply-To: <1479123751.36.0.528401916919.issue28569@psf.upfronthosting.co.za> Message-ID: Syed Suhail Ahmed added the comment: But since autospec is set as True, then shouldnt attach_mock throw an exception when called with an attribute that doesn't exist? On Mon, Nov 14, 2016 at 5:12 PM, Michael Foord wrote: > > Michael Foord added the comment: > > It should be perfectly valid to use attach_mock with an attribute that > doesn't already exist. Part of it's purpose is to create new attributes. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 06:47:19 2016 From: report at bugs.python.org (Michael Foord) Date: Mon, 14 Nov 2016 11:47:19 +0000 Subject: [issue28569] mock.attach_mock should work with any return value of patch() In-Reply-To: <1477935134.31.0.733482108189.issue28569@psf.upfronthosting.co.za> Message-ID: <1479124039.53.0.164992754295.issue28569@psf.upfronthosting.co.za> Michael Foord added the comment: Oh, I see what you mean - an attribute that doesn't exist on the original. With autospec that should throw an exception (AttributeError) I think, yes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 06:54:15 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Nov 2016 11:54:15 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1479124454.99.0.396951323574.issue28637@psf.upfronthosting.co.za> STINNER Victor added the comment: Ethan Furman: "Does this mean we can put enum back in re?" I checked manually: adding "import enum" to Lib/re.py has no more impact on "python_startup" benchmark. Guido van Rossum: "Honestly now the basic startup time is under control I am fine with restoring the re enum. We can optimize that later." I concur with Guido, so I reapplied Ethan's changeset. Enjoy readable str() on re flags ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 06:54:54 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 14 Nov 2016 11:54:54 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1479124494.19.0.37046512454.issue24339@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Just as reference, here's the wikipedia page for the encoding: https://en.wikipedia.org/wiki/ISO/IEC_6937 and this is the ISO document (as preview): http://webstore.iec.ch/preview/info_isoiec6937%7Bed3.0%7Den.pdf (from the German wikipedia page). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 06:55:02 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Nov 2016 11:55:02 +0000 Subject: [issue28637] Python startup performance regression In-Reply-To: <1478560101.77.0.456510195055.issue28637@psf.upfronthosting.co.za> Message-ID: <1479124502.69.0.0372774211585.issue28637@psf.upfronthosting.co.za> STINNER Victor added the comment: The initial bug (performance regression in python_startup) is fixed. Thanks everyone for the nice discussion. I close the issue. Please open new issues if you want to continue efforts on making CPython faster ;-) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 07:03:26 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Nov 2016 12:03:26 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1479125006.56.0.170693383599.issue24339@psf.upfronthosting.co.za> STINNER Victor added the comment: iso6937.py: > # from utf-8 to iso6937 > def iso6937_encode(input,errors,encoding_map): Wait, is this code for Python 3? Decode from UTF-8 and encode to ISO-6937 in the same function seems strange to me. I expected that the codec only implements two functions: encode text (unicode) to ISO-6937 (bytes), decode bytes from ISO-6937 to text. Since the encoding is non trivial (multibyte), if we decide to add it, I suggest to require unit tests. I would like to see unit tests on multibyte strings, to check how the error handler is handled. -- In general, I would prefer to not embed too many codecs in Python, it has a little cost to maintain these codecs. My rule is more to only added encodings used (in practice) as locale encodings. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 07:16:23 2016 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 14 Nov 2016 12:16:23 +0000 Subject: [issue28629] Emit ResourceWarning when implicitly terminating a suspended frame? In-Reply-To: <1478487031.39.0.63356302946.issue28629@psf.upfronthosting.co.za> Message-ID: <1479125783.11.0.560804320887.issue28629@psf.upfronthosting.co.za> Nick Coghlan added the comment: Oops, I forgot to mention one other potential cost-minimisation strategy for a `co_cleanuptab` field: only populate it with setup/cleanup opcode pairs that include a yield, yield from, or await operation between them. The potential benefit I can see to *not* doing that is that if the information is always available (even on synchronous frames), then greenlet based frameworks like gevent may be able to make use of it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 07:18:19 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Nov 2016 12:18:19 +0000 Subject: [issue22495] merge large parts of test_binop.py and test_fractions.py In-Reply-To: <1411648064.39.0.863179207441.issue22495@psf.upfronthosting.co.za> Message-ID: <1479125899.46.0.23801030706.issue22495@psf.upfronthosting.co.za> STINNER Victor added the comment: > This requires quite a bit of work though for a relatively minor improvement so do you think it's worth the effort ? If you factorize code of unit tests, I expect better tests and more tests, so yes, it's valuable. But since this issue is old (no activity last 2 years), I close the issue. Please come back with a reviewable patch (reopen the issue, or open a new one, it's up to you), so it will be easier to discuss. The patch doesn't have to be complete, you can start by factorizing a single function just to discuss the principle and then complete the patch. Note: I added our fractions experts to the issue while closing it :-) ---------- nosy: +haypo, mark.dickinson, rhettinger resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 07:23:38 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Nov 2016 12:23:38 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1479120071.75.0.584727415183.issue28618@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: INADA Naoki added the comment: > How about marking lookdict_unicode and lookdict_unicode_nodummy as hot? I don't understand well the effect of the hot attribute, so I suggest to run benchmarks and check that it has a non negligible effect on benchmarks ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 07:27:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Nov 2016 12:27:32 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1479126452.11.0.746545181109.issue24339@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think the encoder can just use codecs.charmap_encode(). The decoder seems could be simpler too. Would be nice to generate the ISO 6937 encoding file from external data (e.g. from glibc localedata) like they are generated for other encodings. Take Tools/unicode/ files as a pattern. Tests are required. A number of lists of encodings should be updated: Doc/library/codecs.rst, Lib/encodings/aliases.py, Lib/locale.py, Lib/test/test_unicode.py, Lib/test/test_codecs.py, Lib/test/test_xml_etree.py. ---------- stage: -> needs patch versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 07:53:53 2016 From: report at bugs.python.org (Eryk Sun) Date: Mon, 14 Nov 2016 12:53:53 +0000 Subject: [issue28686] py.exe ignored PATH when using python3 shebang In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za> Message-ID: <1479128033.54.0.772413731744.issue28686@psf.upfronthosting.co.za> Eryk Sun added the comment: Virtual commands that are parsed to start with "python" are restricted to the list of installed versions of Python -- unless the virtual command allows searching and the Python command has no version specification (e.g.`#! /usr/bin/env python`). "python3" is versioned, so the launcher will not search for it using the default SearchPath path. For reference, see maybe_handle_shebang() [1], lines 1265-69: command += 6; /* skip past "python" */ if (search && ((*command == L'\0') || isspace(*command))) { /* Command is eligible for path search, and there * is no version specification. */ The default SearchPath path includes the py.exe application directory, the process working directory, system directories, and the %Path% directories. This default search path can be made 'safe' via SetSearchPathMode or a registry setting, but doing so just swaps the order to search system directories before the working directory. It doesn't remove the working directory, unlike the safe search used by CreateProcess when %NoDefaultCurrentDirectoryInExePath% is defined. I think the implementation of find_on_path() could be improved. It should always try appending .EXE, .COM, .BAT, and .CMD if the bare command isn't found, not just if the command doesn't contain a ".". It's not unheard of to have a name with mulitple dots in it, e.g. "spam4.2.exe". Also, looping over all of the extensions listed in %PathExt% is of doubtful value. We don't call ShellExecuteEx to execute arbitrary file types, such as .VBS, .VBE, .JS, .JSE, .WSF, .WSH, and .MSC. [1]: https://hg.python.org/cpython/file/v3.6.0b3/PC/launcher.c#l1112 ---------- nosy: +eryksun versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 07:56:46 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Nov 2016 12:56:46 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings Message-ID: <1479128206.47.0.155651436814.issue28688@psf.upfronthosting.co.za> New submission from STINNER Victor: The issue #23839 modified the test runner to always clear caches before running tests. As a side effect, test_warnings started to complain with: Warning -- warnings.filters was modified by test_warnings The issue comes from the following function of test_warnings/__init__.py: def setUpModule(): py_warnings.onceregistry.clear() c_warnings.onceregistry.clear() I suggest to rewrite this function as a setUp/tearDown method in BaseTest and *restores* the old value of these dictionaries. I guess that the bug affects all Python versions, even if only Python 3.7 logs a warning. ---------- components: Tests messages: 280767 nosy: haypo, martin.panter, serhiy.storchaka priority: normal severity: normal status: open title: Warning -- warnings.filters was modified by test_warnings versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 07:57:50 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Nov 2016 12:57:50 +0000 Subject: [issue23839] Clear caches after every test In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za> Message-ID: <1479128270.51.0.179053301868.issue23839@psf.upfronthosting.co.za> STINNER Victor added the comment: Martin Panter: """ When I run the tests with -Werror (or any other -W option), I now get 2 tests altered the execution environment: test___all__ test_warnings """ I confirm: I opened issue #28688 to track this issue (this issue is now closed). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 08:03:52 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Nov 2016 13:03:52 +0000 Subject: [issue28684] [asyncio] bind() on a unix socket raises PermissionError on Android for a non-root user In-Reply-To: <1479069574.19.0.731580166174.issue28684@psf.upfronthosting.co.za> Message-ID: <1479128632.16.0.326929629756.issue28684@psf.upfronthosting.co.za> STINNER Victor added the comment: I suggest to write a decorator in Lib/asyncio/test_utils.py to skip AF_UNIX tests on Android if os.getuid() != 0. Another approach is to catch the PermissionError and re-raises an unittest.SkipTest. Begin by modifying unix_socket_path() context manager in Lib/asyncio/test_utils.py. I prefer the approach catching PermissionError: it allows to run unit tests on a flavor of Android which doesn't raise PermissionError, and it handles PermissionError on other platforms. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 08:05:58 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Nov 2016 13:05:58 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1479126452.11.0.746545181109.issue24339@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: @Serhiy: Do you think that the encoding is popular enough to pay the price of its maintainance? It's already possible to register manually a new encoding in an application. It was even already possible in Python 2.7 (and older). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 08:08:07 2016 From: report at bugs.python.org (Julien Palard) Date: Mon, 14 Nov 2016 13:08:07 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1479128887.48.0.761297904258.issue24339@psf.upfronthosting.co.za> Julien Palard added the comment: @Serhiy @haypo: Popular enough or not, it may start as a lib on pypi, we'll see its usage from here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 08:09:50 2016 From: report at bugs.python.org (Julien Palard) Date: Mon, 14 Nov 2016 13:09:50 +0000 Subject: [issue28685] Optimizing list.sort() by performing safety checks in advance In-Reply-To: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za> Message-ID: <1479128990.79.0.773886734459.issue28685@psf.upfronthosting.co.za> Julien Palard added the comment: Hi Elliot, nice spot! Why are you redefining Py_ABS, which looks already defined in `pymacro.h` included itself by `Python.h`? I'm not fan of undefining it later, it may surprise someone later expecting it to be there. I tried to compile without your definition of Py_ABS, just in case I missed something in the includes, and it works. ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 08:11:10 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 14 Nov 2016 13:11:10 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1479125006.56.0.170693383599.issue24339@psf.upfronthosting.co.za> Message-ID: <5829B7E9.4090704@egenix.com> Marc-Andre Lemburg added the comment: On 14.11.2016 13:03, STINNER Victor wrote: > > STINNER Victor added the comment: > > iso6937.py: > >> # from utf-8 to iso6937 >> def iso6937_encode(input,errors,encoding_map): > > Wait, is this code for Python 3? Decode from UTF-8 and encode to ISO-6937 in the same function seems strange to me. The patch shows the file as UTF-8. In reality, it is decoding from Unicode strings. > I expected that the codec only implements two functions: encode text (unicode) to ISO-6937 (bytes), decode bytes from ISO-6937 to text. > > Since the encoding is non trivial (multibyte), if we decide to add it, I suggest to require unit tests. I would like to see unit tests on multibyte strings, to check how the error handler is handled. +1 > In general, I would prefer to not embed too many codecs in Python, it has a little cost to maintain these codecs. > > My rule is more to only added encodings used (in practice) as locale encodings. This encoding is used in EPG data of various DVB television formats. As such it is in active use (even though it is very old). I think "active use" is a better approach to restricting ourselves to only locale encodings, since the latter are slowly converging towards UTF-8 :-) BTW: Once a charmap style codec is written, there is little change, so the maintenance is minimal. Codecs which include more active logic such as this one are different, of course, and therefore may potentially add more maintenance burden. ---------- _______________________________________ Python tracker _______________________________________ From mal at egenix.com Mon Nov 14 08:11:05 2016 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 14 Nov 2016 14:11:05 +0100 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1479125006.56.0.170693383599.issue24339@psf.upfronthosting.co.za> References: <1479125006.56.0.170693383599.issue24339@psf.upfronthosting.co.za> Message-ID: <5829B7E9.4090704@egenix.com> On 14.11.2016 13:03, STINNER Victor wrote: > > STINNER Victor added the comment: > > iso6937.py: > >> # from utf-8 to iso6937 >> def iso6937_encode(input,errors,encoding_map): > > Wait, is this code for Python 3? Decode from UTF-8 and encode to ISO-6937 in the same function seems strange to me. The patch shows the file as UTF-8. In reality, it is decoding from Unicode strings. > I expected that the codec only implements two functions: encode text (unicode) to ISO-6937 (bytes), decode bytes from ISO-6937 to text. > > Since the encoding is non trivial (multibyte), if we decide to add it, I suggest to require unit tests. I would like to see unit tests on multibyte strings, to check how the error handler is handled. +1 > In general, I would prefer to not embed too many codecs in Python, it has a little cost to maintain these codecs. > > My rule is more to only added encodings used (in practice) as locale encodings. This encoding is used in EPG data of various DVB television formats. As such it is in active use (even though it is very old). I think "active use" is a better approach to restricting ourselves to only locale encodings, since the latter are slowly converging towards UTF-8 :-) BTW: Once a charmap style codec is written, there is little change, so the maintenance is minimal. Codecs which include more active logic such as this one are different, of course, and therefore may potentially add more maintenance burden. -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Mon Nov 14 08:28:48 2016 From: report at bugs.python.org (Stuart Prescott) Date: Mon, 14 Nov 2016 13:28:48 +0000 Subject: [issue28631] [2.7/3.5/3.6 Regression] crash using ctypes In-Reply-To: <1478531194.3.0.136911442919.issue28631@psf.upfronthosting.co.za> Message-ID: <1479130128.58.0.431836713902.issue28631@psf.upfronthosting.co.za> Stuart Prescott added the comment: Having added the suggested restype (plus a lot of others and also quite a few extra argtypes), we now have code that works across a few different versions of Python once again. Thanks for the hint, eryksun and also thanks to doko for proxying the report and narrowing down the version range in the first place. ---------- nosy: +themill _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 08:33:18 2016 From: report at bugs.python.org (Matthias Klose) Date: Mon, 14 Nov 2016 13:33:18 +0000 Subject: [issue28631] [2.7/3.5/3.6 Regression] crash using ctypes In-Reply-To: <1478531194.3.0.136911442919.issue28631@psf.upfronthosting.co.za> Message-ID: <1479130398.8.0.99901528597.issue28631@psf.upfronthosting.co.za> Matthias Klose added the comment: closing ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 09:10:47 2016 From: report at bugs.python.org (Christian Heimes) Date: Mon, 14 Nov 2016 14:10:47 +0000 Subject: [issue28689] OpenSSL 1.1.0c test failures Message-ID: <1479132647.76.0.450425015981.issue28689@psf.upfronthosting.co.za> New submission from Christian Heimes: OpenSSL 1.1.0c broke a bunch of tests. The same tests are passing fine with OpenSSL 1.1.0 to 1.1.0b. It looks like a problem with EOF / connection close error. I'm seeing similar problems in MIT KRB5's OpenSSL plugin, too. ====================================================================== ERROR: test_ciphers (test.test_ssl.SimpleBackgroundTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 1658, in test_ciphers s.connect(self.server_addr) File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1093, in connect self._real_connect(addr, False) File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1084, in _real_connect self.do_handshake() File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1061, in do_handshake self._sslobj.do_handshake() File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 683, in do_handshake self._sslobj.do_handshake() ConnectionResetError: [Errno 104] Connection reset by peer ====================================================================== ERROR: test_connect (test.test_ssl.SimpleBackgroundTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 1483, in test_connect s.connect(self.server_addr) File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1093, in connect self._real_connect(addr, False) File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1084, in _real_connect self.do_handshake() File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1061, in do_handshake self._sslobj.do_handshake() File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 683, in do_handshake self._sslobj.do_handshake() ConnectionResetError: [Errno 104] Connection reset by peer ====================================================================== ERROR: test_connect_cadata (test.test_ssl.SimpleBackgroundTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 1600, in test_connect_cadata s.connect(self.server_addr) File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1093, in connect self._real_connect(addr, False) File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1084, in _real_connect self.do_handshake() File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1061, in do_handshake self._sslobj.do_handshake() File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 683, in do_handshake self._sslobj.do_handshake() ConnectionResetError: [Errno 104] Connection reset by peer ====================================================================== ERROR: test_connect_capath (test.test_ssl.SimpleBackgroundTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 1579, in test_connect_capath s.connect(self.server_addr) File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1093, in connect self._real_connect(addr, False) File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1080, in _real_connect socket.connect(self, addr) ConnectionRefusedError: [Errno 111] Connection refused ====================================================================== ERROR: test_connect_with_context (test.test_ssl.SimpleBackgroundTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 1541, in test_connect_with_context s.connect(self.server_addr) File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1093, in connect self._real_connect(addr, False) File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1084, in _real_connect self.do_handshake() File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1061, in do_handshake self._sslobj.do_handshake() File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 683, in do_handshake self._sslobj.do_handshake() ConnectionResetError: [Errno 104] Connection reset by peer ====================================================================== ERROR: test_get_server_certificate (test.test_ssl.SimpleBackgroundTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 1645, in test_get_server_certificate _test_get_server_certificate(self, *self.server_addr, cert=SIGNING_CA) File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 1830, in _test_get_server_certificate pem = ssl.get_server_certificate((host, port), ca_certs=cert) File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1215, in get_server_certificate with create_connection(addr) as sock: File "/home/heimes/dev/python/cpython/Lib/socket.py", line 722, in create_connection raise err File "/home/heimes/dev/python/cpython/Lib/socket.py", line 713, in create_connection sock.connect(sa) ConnectionRefusedError: [Errno 111] Connection refused ====================================================================== ERROR: test_session_handling (test.test_ssl.ThreadedTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 3552, in test_session_handling s.connect((HOST, server.port)) File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1093, in connect self._real_connect(addr, False) File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1080, in _real_connect socket.connect(self, addr) ConnectionRefusedError: [Errno 111] Connection refused ====================================================================== ERROR: test_tls_unique_channel_binding (test.test_ssl.ThreadedTests) Test tls-unique channel binding. ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 3167, in test_tls_unique_channel_binding s.connect((HOST, server.port)) File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1093, in connect self._real_connect(addr, False) File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1080, in _real_connect socket.connect(self, addr) ConnectionRefusedError: [Errno 111] Connection refused ---------- assignee: christian.heimes components: SSL, Tests messages: 280776 nosy: christian.heimes priority: high severity: normal status: open title: OpenSSL 1.1.0c test failures type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 09:12:25 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Nov 2016 14:12:25 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings In-Reply-To: <1479128206.47.0.155651436814.issue28688@psf.upfronthosting.co.za> Message-ID: <1479132745.6.0.575744883782.issue28688@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: How you got this warning? I can't reproduce. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 09:19:18 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Mon, 14 Nov 2016 14:19:18 +0000 Subject: [issue28689] OpenSSL 1.1.0c test failures In-Reply-To: <1479132647.76.0.450425015981.issue28689@psf.upfronthosting.co.za> Message-ID: <1479133158.56.0.340519757629.issue28689@psf.upfronthosting.co.za> Changes by Chi Hsuan Yen : ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 09:19:35 2016 From: report at bugs.python.org (Christian Heimes) Date: Mon, 14 Nov 2016 14:19:35 +0000 Subject: [issue28689] OpenSSL 1.1.0c test failures In-Reply-To: <1479132647.76.0.450425015981.issue28689@psf.upfronthosting.co.za> Message-ID: <1479133175.98.0.525830412325.issue28689@psf.upfronthosting.co.za> Christian Heimes added the comment: test_server_accept (test.test_ssl.ThreadedTests) ... Exception in thread Thread-348: Traceback (most recent call last): File "/home/heimes/dev/python/cpython/Lib/threading.py", line 916, in _bootstrap_inner self.run() File "/home/heimes/dev/python/cpython/Lib/threading.py", line 864, in run self._target(*self._args, **self._kwargs) File "/home/heimes/dev/python/cpython/Lib/test/test_ssl.py", line 3044, in serve remote.recv(1) File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 987, in recv return self.read(buflen) File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 865, in read return self._sslobj.read(len, buffer) File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 627, in read v = self._sslobj.read(len) OSError: [Errno 0] Error ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 10:02:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Nov 2016 15:02:54 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1479135774.3.0.953185518142.issue24339@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > My rule is more to only added encodings used (in practice) as locale encodings. Just for reference: issue19459, issue21081, issue22679, issue20087. > @Serhiy: Do you think that the encoding is popular enough to pay the price of its maintainance? Yes, it seems to me that the encoding still in use. I found questions about decoding from ISO 6937 and implementations for different programming languages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 10:03:39 2016 From: report at bugs.python.org (Tim Graham) Date: Mon, 14 Nov 2016 15:03:39 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1479135819.38.0.632535497954.issue28563@psf.upfronthosting.co.za> Tim Graham added the comment: Hi, this broke a couple tests with Django because it's passing number as a float rather than an integer. For example: ====================================================================== ERROR: test_localized_formats (template_tests.filter_tests.test_filesizeformat.FunctionTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/tim/code/django/tests/template_tests/filter_tests/test_filesizeformat.py", line 28, in test_localized_formats self.assertEqual(filesizeformat(1023), '1023\xa0Bytes') File "/home/tim/code/django/django/template/defaultfilters.py", line 895, in filesizeformat value = ungettext("%(size)d byte", "%(size)d bytes", bytes_) % {'size': bytes_} File "/home/tim/code/django/django/utils/translation/__init__.py", line 91, in ungettext return _trans.ungettext(singular, plural, number) File "/home/tim/code/django/django/utils/translation/trans_real.py", line 385, in ngettext return do_ntranslate(singular, plural, number, 'ngettext') File "/home/tim/code/django/django/utils/translation/trans_real.py", line 372, in do_ntranslate return getattr(t, translation_function)(singular, plural, number) File "/home/tim/code/cpython/Lib/gettext.py", line 441, in ngettext tmsg = self._catalog[(msgid1, self.plural(n))] File "", line 4, in func ValueError: Plural value must be an integer, got 1023.0. Can you advise if this patch could be adapted or if Django should adapt? By the way, I used this patch to get a more useful error message: diff --git a/Lib/gettext.py b/Lib/gettext.py index 7032efa..2076a3f 100644 --- a/Lib/gettext.py +++ b/Lib/gettext.py @@ -185,7 +185,7 @@ def c2py(plural): exec('''if True: def func(n): if not isinstance(n, int): - raise ValueError('Plural value must be an integer.') + raise ValueError('Plural value must be an integer, got %%s. return int(%s) ''' % result, ns) return ns['func'] ---------- nosy: +Tim.Graham _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 10:29:07 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 14 Nov 2016 15:29:07 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1479137347.78.0.166379294018.issue28563@psf.upfronthosting.co.za> Xiang Zhang added the comment: GNU gettext only allows the plural value(n) to be an integer(unsigned long int). Django deliberately converts the value to long in filesizeformat. Any reason not to use int? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 10:36:32 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Nov 2016 15:36:32 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings In-Reply-To: <1479128206.47.0.155651436814.issue28688@psf.upfronthosting.co.za> Message-ID: <1479137792.62.0.415226807048.issue28688@psf.upfronthosting.co.za> STINNER Victor added the comment: > How you got this warning? I can't reproduce. Sorry, I forgot to mention that the warning only occurs if you run Python with -Werror: @selma$ ./python -Werror -m test test_warnings Run tests sequentially 0:00:00 [1/1] test_warnings Warning -- warnings.filters was modified by test_warnings test_warnings failed (env changed) 1 test altered the execution environment: test_warnings Total duration: 2 sec Tests result: SUCCESS Moreover, the warning goes away if you don't run tests in verbose mode!? haypo at selma$ ./python -Werror -m test -v test_warnings ... 1 test OK. Total duration: 2 sec Tests result: SUCCESS ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 10:39:07 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Nov 2016 15:39:07 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1479135774.3.0.953185518142.issue24339@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Ok. I'm not waiting for a simpler patch reusing existing charmap functions to see the complexity of the codec ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 10:53:29 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Nov 2016 15:53:29 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1479138809.24.0.602949506222.issue28563@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch makes gettext accepting non-integer numbers. But DeprecationWarning is emitted if this number have fractional part (because in this case the result of current code can be different from the result of old code). I think Django tests should be passed without errors and warnings. In future versions (probably in 3.7) this warning will be replaced with TypeError or ValueError, and new warning will be added for all non-integer numbers. ---------- stage: resolved -> patch review status: closed -> open Added file: http://bugs.python.org/file45481/gettext-non-integer-plural.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 11:02:45 2016 From: report at bugs.python.org (Christian Heimes) Date: Mon, 14 Nov 2016 16:02:45 +0000 Subject: [issue28689] OpenSSL 1.1.0c test failures In-Reply-To: <1479132647.76.0.450425015981.issue28689@psf.upfronthosting.co.za> Message-ID: <1479139365.98.0.842495449936.issue28689@psf.upfronthosting.co.za> Christian Heimes added the comment: A git bisect between OpenSSL_1_1_0b (good) and OpenSSL_1_1_0c (bad) revealed the breaking commit: $ git bisect good 122580ef71e4e5f355a1a104c9bfb36feee43759 is the first bad commit commit 122580ef71e4e5f355a1a104c9bfb36feee43759 Author: Matt Caswell Date: Fri Oct 21 13:25:19 2016 +0100 A zero return from BIO_read()/BIO_write() could be retryable A zero return from BIO_read()/BIO_write() could mean that an IO operation is retryable. A zero return from SSL_read()/SSL_write() means that the connection has been closed down (either cleanly or not). Therefore we should not propagate a zero return value from BIO_read()/BIO_write() back up the stack to SSL_read()/SSL_write(). This could result in a retryable failure being treated as fatal. Reviewed-by: Richard Levitte (cherry picked from commit 4880672a9b41a09a0984b55e219f02a2de7ab75e) :040000 040000 8097bc37a0a2a3c1e6a8879ad49ee773001d8d52 8083927cb2eb28a71baa8b90b07b0962016d74b3 M ssl ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 11:04:28 2016 From: report at bugs.python.org (Christian Heimes) Date: Mon, 14 Nov 2016 16:04:28 +0000 Subject: [issue28689] OpenSSL 1.1.0c test failures In-Reply-To: <1479132647.76.0.450425015981.issue28689@psf.upfronthosting.co.za> Message-ID: <1479139468.62.0.453467873732.issue28689@psf.upfronthosting.co.za> Christian Heimes added the comment: https://github.com/openssl/openssl/commit/122580ef71e4e5f355a1a104c9bfb36feee43759 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 11:13:18 2016 From: report at bugs.python.org (Christian Heimes) Date: Mon, 14 Nov 2016 16:13:18 +0000 Subject: [issue28689] OpenSSL 1.1.0c test failures In-Reply-To: <1479132647.76.0.450425015981.issue28689@psf.upfronthosting.co.za> Message-ID: <1479139998.9.0.449811223488.issue28689@psf.upfronthosting.co.za> Christian Heimes added the comment: OpenSSL upstream bug: https://github.com/openssl/openssl/issues/1919 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 11:16:17 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Nov 2016 16:16:17 +0000 Subject: [issue28662] catch also PermissionError in tests when spawning a non existent program In-Reply-To: <1478819871.94.0.069145146671.issue28662@psf.upfronthosting.co.za> Message-ID: <20161114161614.4958.91752.61A56878@psf.io> Roundup Robot added the comment: New changeset 1b2b2cb8f962 by Xavier de Gaye in branch '3.6': Issue #28662: Catch PermissionError in tests when spawning a non existent program https://hg.python.org/cpython/rev/1b2b2cb8f962 New changeset c3f7d81d9050 by Xavier de Gaye in branch 'default': Issue #28662: Merge 3.6 https://hg.python.org/cpython/rev/c3f7d81d9050 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 11:17:38 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 14 Nov 2016 16:17:38 +0000 Subject: [issue28662] catch also PermissionError in tests when spawning a non existent program In-Reply-To: <1478819871.94.0.069145146671.issue28662@psf.upfronthosting.co.za> Message-ID: <1479140258.62.0.79646480546.issue28662@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 11:23:08 2016 From: report at bugs.python.org (Tim Graham) Date: Mon, 14 Nov 2016 16:23:08 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1479140588.18.0.730604068015.issue28563@psf.upfronthosting.co.za> Tim Graham added the comment: Thanks, that does fix that first test. There is one more that still fails: $ python -Wall tests/runtests.py humanize_tests.tests.HumanizeTests.test_i18n_intword Testing against Django installed in '/home/tim/code/django/django' with up to 3 processes Creating test database for alias 'default'... Creating test database for alias 'other'... /home/tim/code/cpython/Lib/gettext.py:454: DeprecationWarning: Plural value must be an integer, got 1.2 tmsg = self._catalog[(msgid1, self.plural(n))] /home/tim/code/cpython/Lib/gettext.py:454: DeprecationWarning: Plural value must be an integer, got 1.2 tmsg = self._catalog[(msgid1, self.plural(n))] F ====================================================================== FAIL: test_i18n_intword (humanize_tests.tests.HumanizeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/tim/code/django/tests/humanize_tests/tests.py", line 133, in test_i18n_intword self.humanize_tester(test_list, result_list, 'intword') File "/home/tim/code/django/tests/humanize_tests/tests.py", line 39, in humanize_tester msg="%s test failed, produced '%s', should've produced '%s'" % (method, rendered, result)) AssertionError: '1,2 Million' != '1,2 Millionen' : intword test failed, produced '1,2 Million', should've produced '1,2 Millionen' I think the relevant code is https://github.com/django/django/blob/cbae4d31847d75d889815bfe7c04af035f45e28d/django/contrib/humanize/templatetags/humanize.py#L60-L63. I'm not too familiar with this code, but I'll try to get a better explanation if it's not clear to you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 11:24:47 2016 From: report at bugs.python.org (Walter Farrell) Date: Mon, 14 Nov 2016 16:24:47 +0000 Subject: [issue28690] Loop in re (regular expression) processing Message-ID: <1479140687.65.0.411208896351.issue28690@psf.upfronthosting.co.za> New submission from Walter Farrell: Given: pattern = r"(^|[^\\])<(pm [^ ]+( +|'[^']*'|\"[^\"]*\"|[^>]+)+)>" s = "Bain, F. W. " added to the end of s, it returns quickly with a match. Without the ">" it should fail, but instead seems to loop. (If I use the regex module instead of re, it fails properly and quickly.) Python 3.5.1, Windows 10: Python 3.5.1 (v3.5.1:37a07cee5969, Dec 6 2015, 01:54:25) [MSC v.1900 64 bit (AMD64)] on win32 ---------- components: Library (Lib), Regular Expressions messages: 280790 nosy: Walter Farrell, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: Loop in re (regular expression) processing type: resource usage versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 11:32:05 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Nov 2016 16:32:05 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1479141125.38.0.452346635393.issue28563@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What about following patch? ---------- Added file: http://bugs.python.org/file45482/gettext-non-integer-plural-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 11:49:45 2016 From: report at bugs.python.org (Tim Graham) Date: Mon, 14 Nov 2016 16:49:45 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1479142185.09.0.284005233013.issue28563@psf.upfronthosting.co.za> Tim Graham added the comment: Yes, that fixes the second test. Current warning (with stacklevel=3): /home/tim/code/cpython/Lib/gettext.py:454: DeprecationWarning: Plural value must be an integer, got 1.29 tmsg = self._catalog[(msgid1, self.plural(n))] Possibly the stacklevel should instead be 4: /home/tim/code/django/django/utils/translation/trans_real.py:373: DeprecationWarning: Plural value must be an integer, got 1.29 return getattr(t, translation_function)(singular, plural, number) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 11:53:06 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Nov 2016 16:53:06 +0000 Subject: [issue28691] python3.6 -Werror -c '"\c"' fails with an assertion error Message-ID: <1479142386.33.0.817704504707.issue28691@psf.upfronthosting.co.za> New submission from STINNER Victor: The issue #28128 (changeset 259745f9a1e4) introduced a DeprecationWarning on invalid Unicode sequence like "\c". When Python is run with -Werror, Python crashs with an assertion error: $ ./python -Werror -c '"\c"' python: Objects/abstract.c:2232: PyObject_Call: Assertion `!PyErr_Occurred()' failed. Aborted (core dumped) Gdb traceback: (gdb) where #0 0x00007ffff711f6f5 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #1 0x00007ffff71212fa in __GI_abort () at abort.c:89 #2 0x00007ffff7117f97 in __assert_fail_base (fmt=, assertion=assertion at entry=0x69b577 "!PyErr_Occurred()", file=file at entry=0x69a922 "Objects/abstract.c", line=line at entry=2232, function=function at entry=0x69b9c8 <__PRETTY_FUNCTION__.11084> "PyObject_Call") at assert.c:92 #3 0x00007ffff7118042 in __GI___assert_fail (assertion=0x69b577 "!PyErr_Occurred()", file=0x69a922 "Objects/abstract.c", line=2232, function=0x69b9c8 <__PRETTY_FUNCTION__.11084> "PyObject_Call") at assert.c:101 #4 0x000000000045afe8 in PyObject_Call (func=, args=(2, 'No such file or directory', ''), kwargs=0x0) at Objects/abstract.c:2232 #5 0x00000000005e77de in PyErr_SetFromErrnoWithFilenameObjects (exc=, filenameObject='', filenameObject2=0x0) at Python/errors.c:559 #6 0x00000000005e7631 in PyErr_SetFromErrnoWithFilenameObject (exc=, filenameObject='') at Python/errors.c:471 #7 0x000000000043e839 in _Py_fopen_obj (path='', mode=0x6c86e7 "rb") at Python/fileutils.c:1138 #8 0x00000000005e8e54 in PyErr_ProgramTextObject (filename='', lineno=1) at Python/errors.c:1179 #9 0x0000000000598e90 in ast_error (c=0x7fffffffd8b0, n=0x7ffff02d31f0, errmsg=0x7ffff02c1a80 "invalid escape sequence \\c") at Python/ast.c:673 #10 0x00000000005a3ae8 in warn_invalid_escape_sequence (c=0x7fffffffd8b0, n=0x7ffff02d31f0, first_invalid_escape_char=99 'c') at Python/ast.c:4134 #11 0x00000000005a4123 in decode_unicode_with_escapes (c=0x7fffffffd8b0, n=0x7ffff02d31f0, s=0x7ffff03157f0 "\\c\313\313\313\313\313\313\313\313\313", , len=2) at Python/ast.c:4202 #12 0x00000000005a63b8 in parsestr (c=0x7fffffffd8b0, n=0x7ffff02d31f0, bytesmode=0x7fffffffd29c, rawmode=0x7fffffffd298, result=0x7fffffffd290, fstr=0x7fffffffd288, fstrlen=0x7fffffffd280) at Python/ast.c:5114 #13 0x00000000005a64cb in parsestrplus (c=0x7fffffffd8b0, n=0x7ffff02d31a8) at Python/ast.c:5145 #14 0x000000000059d17b in ast_for_atom (c=0x7fffffffd8b0, n=0x7ffff02d31a8) at Python/ast.c:2112 #15 0x000000000059e4d9 in ast_for_atom_expr (c=0x7fffffffd8b0, n=0x7ffff02d3160) at Python/ast.c:2467 #16 0x000000000059e649 in ast_for_power (c=0x7fffffffd8b0, n=0x7ffff02d3118) at Python/ast.c:2504 #17 0x000000000059ef95 in ast_for_expr (c=0x7fffffffd8b0, n=0x7ffff02d3118) at Python/ast.c:2692 #18 0x000000000059f8d2 in ast_for_testlist (c=0x7fffffffd8b0, n=0x7ffff0351d30) at Python/ast.c:2883 #19 0x000000000059f992 in ast_for_expr_stmt (c=0x7fffffffd8b0, n=0x7ffff0351ce8) at Python/ast.c:2906 #20 0x00000000005a3475 in ast_for_stmt (c=0x7fffffffd8b0, n=0x7ffff0351ce8) at Python/ast.c:3983 #21 0x00000000005997e8 in PyAST_FromNodeObject (n=0x7ffff0351c10, flags=0x7fffffffdcf0, filename='', arena=0x7ffff02ec040) at Python/ast.c:839 #22 0x000000000042a146 in PyParser_ASTFromFileObject (fp=0x7ffff74a78c0 <_IO_2_1_stdin_>, filename='', enc=0x7ffff7e574f8 "UTF-8", start=256, ps1=0x7ffff02cdd18 ">>> ", ps2=0x7ffff02cdde8 "... ", flags=0x7fffffffdcf0, errcode=0x7fffffffda4c, arena=0x7ffff02ec040) at Python/pythonrun.c:1169 #23 0x0000000000426b00 in PyRun_InteractiveOneObject (fp=0x7ffff74a78c0 <_IO_2_1_stdin_>, filename='', flags=0x7fffffffdcf0) at Python/pythonrun.c:212 #24 0x0000000000426698 in PyRun_InteractiveLoopFlags (fp=0x7ffff74a78c0 <_IO_2_1_stdin_>, filename_str=0x697276 "", flags=0x7fffffffdcf0) at Python/pythonrun.c:112 #25 0x0000000000426491 in PyRun_AnyFileExFlags (fp=0x7ffff74a78c0 <_IO_2_1_stdin_>, filename=0x697276 "", closeit=0, flags=0x7fffffffdcf0) at Python/pythonrun.c:74 #26 0x00000000004421cd in run_file (fp=0x7ffff74a78c0 <_IO_2_1_stdin_>, filename=0x0, p_cf=0x7fffffffdcf0) at Modules/main.c:319 #27 0x0000000000443086 in Py_Main (argc=2, argv=0x9d2010) at Modules/main.c:779 #28 0x000000000041d2c9 in main (argc=2, argv=0x7fffffffdf28) at ./Programs/python.c:69 ---------- messages: 280793 nosy: ebarry, eric.smith, haypo, ned.deily priority: release blocker severity: normal status: open title: python3.6 -Werror -c '"\c"' fails with an assertion error versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 11:55:40 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Nov 2016 16:55:40 +0000 Subject: [issue28691] python3.6 -Werror -c '"\c"' fails with an assertion error In-Reply-To: <1479142386.33.0.817704504707.issue28691@psf.upfronthosting.co.za> Message-ID: <1479142540.3.0.97157095755.issue28691@psf.upfronthosting.co.za> STINNER Victor added the comment: By the way, an unit test is missing since the bug was not catched by the test suite! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 12:04:07 2016 From: report at bugs.python.org (Andrey Fedorov) Date: Mon, 14 Nov 2016 17:04:07 +0000 Subject: [issue28569] mock.attach_mock should work with any return value of patch() In-Reply-To: <1479124039.53.0.164992754295.issue28569@psf.upfronthosting.co.za> Message-ID: Andrey Fedorov added the comment: Here's the full extension of the example from documentation that doesn't seem to handle classes and functions consistently: import mock patches = { 'requests_get': 'requests.get', 'mymodule_Class1': 'mymodule.Class1' } root_mock = mock.Mock() for name, path in patches.items(): m = mock.patch(path, autospec=True) root_mock.attach_mock(m.start(), name) import requests import mymodule mymodule.Class1('foo') requests.get('bar') print root_mock.mock_calls # [call.mymodule_Class1('foo')] Does this working as expected make sense, or is there some reason this is an undesirable API to behave consistently regardless of what's being patched? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 12:04:53 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Nov 2016 17:04:53 +0000 Subject: [issue28691] python3.6 -Werror -c '"\c"' fails with an assertion error In-Reply-To: <1479142386.33.0.817704504707.issue28691@psf.upfronthosting.co.za> Message-ID: <1479143093.97.0.510920538199.issue28691@psf.upfronthosting.co.za> STINNER Victor added the comment: Attached ast.patch fixes the issue: replace the DeprecationWarning with a SyntaxError. Is it the expected behaviour? Is it worth it to chain the two exceptions? ---------- keywords: +patch Added file: http://bugs.python.org/file45483/ast.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 12:05:57 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Nov 2016 17:05:57 +0000 Subject: [issue28691] python3.6 -Werror -c '"\c"' fails with an assertion error In-Reply-To: <1479142386.33.0.817704504707.issue28691@psf.upfronthosting.co.za> Message-ID: <1479143157.83.0.364442080574.issue28691@psf.upfronthosting.co.za> STINNER Victor added the comment: > By the way, an unit test is missing since the bug was not catched by the test suite! Lib/test/test_string_literals.py contains an unit test but it changes the warnings filter, so -Werror option is ignored. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 12:19:18 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 14 Nov 2016 17:19:18 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings In-Reply-To: <1479128206.47.0.155651436814.issue28688@psf.upfronthosting.co.za> Message-ID: <1479143958.39.0.917324515892.issue28688@psf.upfronthosting.co.za> Xiang Zhang added the comment: test___all__ gets the same behaviour. ./python -Werror -m test test___all__ Run tests sequentially 0:00:00 [1/1] test___all__ Warning -- warnings.filters was modified by test___all__ test___all__ failed (env changed) 1 test altered the execution environment: test___all__ Total duration: 1 sec Tests result: SUCCESS And on my PC in company I sometimes get the behaviour for test_distutils. I originally thought this is not a problem. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 12:25:39 2016 From: report at bugs.python.org (Elliot Gorokhovsky) Date: Mon, 14 Nov 2016 17:25:39 +0000 Subject: [issue28685] Optimizing list.sort() by performing safety checks in advance In-Reply-To: <1479128990.79.0.773886734459.issue28685@psf.upfronthosting.co.za> Message-ID: Elliot Gorokhovsky added the comment: Sure, if it compiles without that def, I'll remove it from the patch. I added it because I did all the development in an extension module, which also included Python.h, but for some reason it gave me a "function implicitly defined" error for using Py_ABS. Even though I had included Python.h. Weird, right? So I assumed I had to leave it in the patch as well. Thanks for pointing this out! On Mon, Nov 14, 2016 at 6:09 AM Julien Palard wrote: > > Julien Palard added the comment: > > Hi Elliot, nice spot! > > Why are you redefining Py_ABS, which looks already defined in `pymacro.h` > included itself by `Python.h`? I'm not fan of undefining it later, it may > surprise someone later expecting it to be there. > > I tried to compile without your definition of Py_ABS, just in case I > missed something in the includes, and it works. > > ---------- > nosy: +mdk > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 12:31:44 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Nov 2016 17:31:44 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <20161114173141.25197.39333.ECB1305B@psf.io> Roundup Robot added the comment: New changeset 5b6cde995b3a by Serhiy Storchaka in branch '3.3': Issue #28563: Make plural form selection more lenient and accepting https://hg.python.org/cpython/rev/5b6cde995b3a New changeset 6ca91a14a555 by Serhiy Storchaka in branch '2.7': Issue #28563: Make plural form selection more lenient and accepting https://hg.python.org/cpython/rev/6ca91a14a555 New changeset f78a05cda5aa by Serhiy Storchaka in branch '3.4': Issue #28563: Make plural form selection more lenient and accepting https://hg.python.org/cpython/rev/f78a05cda5aa New changeset 6a2754055ff8 by Serhiy Storchaka in branch '3.5': Issue #28563: Make plural form selection more lenient and accepting https://hg.python.org/cpython/rev/6a2754055ff8 New changeset 4c201c65ce5d by Serhiy Storchaka in branch '3.6': Issue #28563: Make plural form selection more lenient and accepting https://hg.python.org/cpython/rev/4c201c65ce5d New changeset d0efb8532589 by Serhiy Storchaka in branch 'default': Issue #28563: Make plural form selection more lenient and accepting https://hg.python.org/cpython/rev/d0efb8532589 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 12:32:50 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Nov 2016 17:32:50 +0000 Subject: [issue28685] Optimizing list.sort() by performing safety checks in advance In-Reply-To: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za> Message-ID: <1479144770.68.0.416919580207.issue28685@psf.upfronthosting.co.za> STINNER Victor added the comment: Maybe we should investigate more optimizations on specialized lists. PyPy uses a more compact structure for lists of integers for example. Something like compact strings, PEP 393, of Python 3.3, but for lists. http://doc.pypy.org/en/latest/interpreter-optimizations.html#list-optimizations But we are limited by the C API, so we cannot change deeply the C structure without breaking backward compatibility. > # (difference is within std dev) You can use perf timeit --compare-to to check if the result is significant or not, and it displays you the "N.NNx faster" or "N.NNx slower" if it's significant. About benchmarks, I also would like to see a benchmark on the bad case, when specialization is not used. And not only on an empty list :-) For example, sort 1000 objects which implement compare operators and/or a sort function. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 12:39:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Nov 2016 17:39:32 +0000 Subject: [issue28563] Arbitrary code execution in gettext.c2py In-Reply-To: <1477846721.72.0.339090840874.issue28563@psf.upfronthosting.co.za> Message-ID: <1479145172.17.0.331056845214.issue28563@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, you are right, the stacklevel should be 4. Thank you for your report and testing Tim. Committed the patch without any deprecation. Will add a deprecation in separate issue. ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 13:05:42 2016 From: report at bugs.python.org (wdhwg001) Date: Mon, 14 Nov 2016 18:05:42 +0000 Subject: [issue28686] py.exe ignored PATH when using python3 shebang In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za> Message-ID: <1479146742.27.0.739078491281.issue28686@psf.upfronthosting.co.za> wdhwg001 added the comment: Okay. But somehow I still think the current way of handling shebang is confusing. That makes a python3-only script unable to find a way to use both versioned shebang and virtualenv. Maybe it could be changed to `Command is eligible for path search, or there is no version specification`. Then if shebang is versioned, py.exe should try to search `PATH` for a versioned executable file(though it might not exist), and fallback to the installed list. This could be less confusing I think. And more importantly, virtualenv cannot and shouldn't create registry keys or even hijack py.exe to fix this issue. This change provides a better way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 13:37:59 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Nov 2016 18:37:59 +0000 Subject: [issue28692] gettext: deprecate selecting plural form by fractional numbers Message-ID: <1479148679.54.0.229445108959.issue28692@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: GNU gettext library accepts only integer value for selecting plural form. Python gettext accepts arbitrary numbers. But gettext formulas are not purposed to support non-integer values and can return incorrect result. For example (in Ukrainian): "1 ?????", but "1.5 ?????", not "1.5 ????". "2 ???????", but "2.75 ???????", not "2.75 ????????". "5 ????", but "5.7 ?????", not "5.7 ????". Separate plural form should be used for fractional numbers. Even if fractional part happens to be zero, it is acceptable (e.g. "Time elapsed: 1.000 seconds" in English). Proposed patch deprecates fractional numbers for selecting plural form in gettext. ---------- components: Library (Lib) messages: 280804 nosy: Tim.Graham, loewis, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: gettext: deprecate selecting plural form by fractional numbers type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 13:53:27 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Nov 2016 18:53:27 +0000 Subject: [issue28691] python3.6 -Werror -c '"\c"' fails with an assertion error In-Reply-To: <1479142386.33.0.817704504707.issue28691@psf.upfronthosting.co.za> Message-ID: <1479149607.87.0.28397802993.issue28691@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is my fault. Proposed patch adds tests for the "error" action. ---------- components: +Interpreter Core nosy: +serhiy.storchaka stage: -> patch review type: -> crash Added file: http://bugs.python.org/file45484/test_eval_str_invalid_escape_error.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 14:45:02 2016 From: report at bugs.python.org (Julien Palard) Date: Mon, 14 Nov 2016 19:45:02 +0000 Subject: [issue28692] gettext: deprecate selecting plural form by fractional numbers In-Reply-To: <1479148679.54.0.229445108959.issue28692@psf.upfronthosting.co.za> Message-ID: <1479152702.4.0.415426372853.issue28692@psf.upfronthosting.co.za> Julien Palard added the comment: Hi, did you forget to attach the patch? ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 14:49:44 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 14 Nov 2016 19:49:44 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <20161114194941.4911.2357.D21927E4@psf.io> Roundup Robot added the comment: New changeset 993215342a95 by Yury Selivanov in branch '3.6': Issue #28635: what's new in 3.6: add a few more notes on typing https://hg.python.org/cpython/rev/993215342a95 New changeset c3b4eea73615 by Yury Selivanov in branch 'default': Merge 3.6 (issue #28635) https://hg.python.org/cpython/rev/c3b4eea73615 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 14:55:24 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Nov 2016 19:55:24 +0000 Subject: [issue27854] Installed 2.7: IDLE Help disabled because help.html is missing In-Reply-To: <1472078066.3.0.116550230826.issue27854@psf.upfronthosting.co.za> Message-ID: <1479153324.79.0.00955622602967.issue27854@psf.upfronthosting.co.za> Steve Dower added the comment: I ran a build and the file is included now. I didn't test an install or the functionality from IDLE, so make sure you cover that with the RC (and since there won't be an RC with a release blocker open, I'll resolve this and we can reactivate if there are new issues). ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 14:58:52 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Nov 2016 19:58:52 +0000 Subject: [issue19717] resolve() fails when the path doesn't exist In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za> Message-ID: <1479153532.55.0.530607165343.issue19717@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 14:59:00 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Nov 2016 19:59:00 +0000 Subject: [issue19717] resolve() fails when the path doesn't exist In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za> Message-ID: <1479153540.47.0.738245725559.issue19717@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 14:59:50 2016 From: report at bugs.python.org (Paul Moore) Date: Mon, 14 Nov 2016 19:59:50 +0000 Subject: [issue28686] py.exe ignored PATH when using python3 shebang In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za> Message-ID: <1479153590.79.0.141797971812.issue28686@psf.upfronthosting.co.za> Paul Moore added the comment: I agree that the docs are a little confusing on this. Having said that, though, I'm not entirely sure the behaviour needs fixing. The scenario where there's a problem is: 1. User has written a script that needs Python 3 and won't run with Python 2. 2. User does not want to force a specific interpreter, or use the system Python. 3. User wants to use virtualenvs (or otherwise manipulate PATH to switch Python versions) and will sometimes have Python 2 and sometimes Python 3 active. 4. User expects to be able to run the script with Python 2 active and in that case use the system Python 3. That's a pretty rare situation, IMO. Add to that the fact that it's really hard to detect when the python on PATH is Python 2 (you basically need to run python -V). The discussion seems to be veering a little too much towards "do what I mean" to me, and I'd prefer we keep the behaviour simple. I'm happy with the idea that "/usr/bin/env python3" should search, and then fall back to the system defined Python 3. The question is what should we search *for*. There seem to me to be only 2 options: 1. python - but this could select a Python 2 interpreter, so that seems wrong. 2. python3 - that's logical but has a number of quirks 2a. There isn't a python3 executable supplied as standard, so this behaviour is useless without user customisation. 2b. Do we want to force searching for additional extensions like .bat? What about .ps1 for Powershell users? What do we do for the GUI version? Overall, I think option 2 has too many grey areas to be really acceptable, and I'm inclined to say YAGNI, and we simply leave "/usr/bin/env python3" undefined. For the OP's use case, I'm not clear precisely why "/usr/bin/env python" wouldn't be a sufficiently good approach. If there's a specific scenario in his setup that means we really do *have* to have "/usr/bin/env python3" I'd be grateful if he could clarify. Or to put it another way, is this issue simply "I was surprised it didn't work as I expected" or is it "I cannot do what I want because this doesn't work"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 15:04:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Nov 2016 20:04:24 +0000 Subject: [issue28692] gettext: deprecate selecting plural form by fractional numbers In-Reply-To: <1479148679.54.0.229445108959.issue28692@psf.upfronthosting.co.za> Message-ID: <1479153864.44.0.393772093737.issue28692@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry. Here is a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file45485/gettext-non-int-plural-deprecate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 15:09:08 2016 From: report at bugs.python.org (Mingye Wang) Date: Mon, 14 Nov 2016 20:09:08 +0000 Subject: [issue28693] No HKSCS support in Windows cp950 Message-ID: <1479154148.6.0.43343383532.issue28693@psf.upfronthosting.co.za> New submission from Mingye Wang: Python's cp950 implementation lacks support for HKSCS ('big5hkscs'). This support, which maps HKSCS Big5-EUDC code points to Unicode PUA code points algorithmically, is found in Windows Vista+ as well as an update for XP. An experiment session is shown below. I will use '2>>>' to denote a Win32 build of Python 2.7.10 running under a console window set to cp950 (via chcp), and '3>>>' to denote a Python 3.4.3 build running under Cygwin's UTF-8 mintty. HKSCS-2008's table is used http://www.ogcio.gov.hk/en/business/tech_promotion/ccli/terms/doc/hkscs-2008-big5-iso.txt for a list of HKSCS characters; note though, its non-PUA mappings are not found in Windows. Let's start with the first character in that list. 3>>> u'\u43F0' '?' 3>>> print(u'\uF266') # provisional PUA ? 3>>> u'\u43F0'.encode('cp950') # FAIL 3>>> u'\uF266'.encode('cp950') # FAIL 3>>> u'\u43F0'.encode('hkscs') b'\x87@' 3>>> u'\uF266'.encode('hkscs') # FAIL` These experiments above show how Python 3 handles HKSCS characters, and how U+43F0 should normally be encoded. Now let's switch to Windows console, which would be using Windows' decode-to-Unicode routine for cp950. 2>>> print b'\x87@' ? Let's try to identify this character: 3>>> u'?' '\uf266' So indeed there is some sort of HKSCS going on. But note what Windows has is really not any kind of new HKSCS: > Big5 ucs93 ucs00 ucs03 + 1-6 > 876B 9734 9734 9734 > 876C F292 F292 27BEF > 876D 5BDB 5BDB 5BDB 2>>> print b'\x87\x6b,\x87\x6c,\x87\x6d' ?,?,? 3>>> u'?,?,?' '\uf291,\uf292,\uf293' Just as for all other code pages, you can always find Microsoft's mapping at ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit950.txt. If you are uncomfortable with adding a whole new table and wasting space (this is done for hkscs btw), use the algorithmic mapping at https://en.wikipedia.org/wiki/Code_page_950. ---------- components: Unicode messages: 280811 nosy: Artoria2e5, ezio.melotti, haypo priority: normal severity: normal status: open title: No HKSCS support in Windows cp950 type: behavior versions: 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 Mon Nov 14 15:25:37 2016 From: report at bugs.python.org (Mingye Wang) Date: Mon, 14 Nov 2016 20:25:37 +0000 Subject: [issue24117] Wrong range checking in GB18030 decoder. In-Reply-To: <1430641019.11.0.12743813091.issue24117@psf.upfronthosting.co.za> Message-ID: <1479155137.06.0.447167579199.issue24117@psf.upfronthosting.co.za> Mingye Wang added the comment: Just FYI, cp950 0xC6A1 (\uf6b1) is found in current WindowsBestFit: ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit950.txt ---------- nosy: +Artoria2e5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 15:55:25 2016 From: report at bugs.python.org (Gareth Rees) Date: Mon, 14 Nov 2016 20:55:25 +0000 Subject: [issue28690] Loop in re (regular expression) processing In-Reply-To: <1479140687.65.0.411208896351.issue28690@psf.upfronthosting.co.za> Message-ID: <1479156925.14.0.601715521823.issue28690@psf.upfronthosting.co.za> Gareth Rees added the comment: This is a well-known gotcha with backtracking regexp implementations. The problem is that in the alternation "( +|'[^']*'|\"[^\"]*\"|[^>]+)" there are some characters (space, apostrophe, double quotes) that match multiple alternatives (for example a space matches both " +" and "[^>]+"). This causes the regexp engine to have to backtrack for each ambiguous character to try out the other alternatives, leading to runtime that's exponential in the number of ambiguous characters. Linear behaviour can be restored if you make the alternation unambiguous, like this: ( +|'[^']*'|\"[^\"]*\"|[^>'\"]+) ---------- nosy: +Gareth.Rees _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 16:09:42 2016 From: report at bugs.python.org (Walter Farrell) Date: Mon, 14 Nov 2016 21:09:42 +0000 Subject: [issue28690] Loop in re (regular expression) processing In-Reply-To: <1479156925.14.0.601715521823.issue28690@psf.upfronthosting.co.za> Message-ID: Walter Farrell added the comment: Thanks, Gareth. That does work. Interesting that regex does still seem to work linearly with the original version, but your version seems cleaner. On Mon, Nov 14, 2016 at 3:55 PM, Gareth Rees wrote: > > Gareth Rees added the comment: > > This is a well-known gotcha with backtracking regexp implementations. The > problem is that in the alternation "( +|'[^']*'|\"[^\"]*\"|[^>]+)" there > are some characters (space, apostrophe, double quotes) that match multiple > alternatives (for example a space matches both " +" and "[^>]+"). This > causes the regexp engine to have to backtrack for each ambiguous character > to try out the other alternatives, leading to runtime that's exponential in > the number of ambiguous characters. > > Linear behaviour can be restored if you make the alternation unambiguous, > like this: ( +|'[^']*'|\"[^\"]*\"|[^>'\"]+) > > ---------- > nosy: +Gareth.Rees > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 17:01:10 2016 From: report at bugs.python.org (Elliot Gorokhovsky) Date: Mon, 14 Nov 2016 22:01:10 +0000 Subject: [issue28685] Optimizing list.sort() by performing safety checks in advance In-Reply-To: <1479144770.68.0.416919580207.issue28685@psf.upfronthosting.co.za> Message-ID: Elliot Gorokhovsky added the comment: On Mon, Nov 14, 2016 at 10:32 AM STINNER Victor wrote: > You can use perf timeit --compare-to to check if the result is significant > or not, and it displays you the "N.NNx faster" or "N.NNx slower" if it's > significant. > Will do -- I'm writing this up as a paper since this is my science fair project, so I'll redo the measurements that way and upload a pdf here. > About benchmarks, I also would like to see a benchmark on the bad case, > when specialization is not used. And not only on an empty list :-) For > example, sort 1000 objects which implement compare operators and/or a sort > function. > The worst case is the third benchmark from the top -- a list of floats with a single, sad, solitary long at the end. That disables optimization because keys_are_all_same_type gets set to 0 when assign_compare_function finds the long (since key_type == &PyFloat_Type). That benchmark is the *absolute* worst case for two reasons: 1. Float compares are really cheap, so the ratio doesn't get messed up by the common term "time spent actually comparing floats" (since the total time is "time spent on overhead + time spend actually comparing floats"). 2. The list is of size 10. I guess I could've used size 3 or 4, but it shouldn't be too far off... smaller lists give worse ratios because the overhead is O(n) while sorting is O(nlogn). So, again, the absolute worst possible case is the third benchmark, which suffers a 10% slowdown. Certainly a reasonable price to pay considering how rare that case is in practice, and considering the 40-75% gains we get on the common cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 17:35:16 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 14 Nov 2016 22:35:16 +0000 Subject: [issue28670] PEP 235: Implement on every POSIX system, and clean up the C code for `import' In-Reply-To: <1478899111.69.0.0154952768919.issue28670@psf.upfronthosting.co.za> Message-ID: <1479162916.56.0.0213216863977.issue28670@psf.upfronthosting.co.za> Brett Cannon added the comment: Because this would be a feature change in Python 2.7 it can't go in there. This could potentially go into 3.7 if it's deemed useful. As for why the code review tool isn't picking up your uploads, it's because we work in patch files and not patch sets. See https://docs.python.org/devguide/patch.html on how to create a patch file that can be reviewed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 17:35:43 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 14 Nov 2016 22:35:43 +0000 Subject: [issue28670] PEP 235: Implement on every POSIX system, and clean up the C code for `import' In-Reply-To: <1478899111.69.0.0154952768919.issue28670@psf.upfronthosting.co.za> Message-ID: <1479162943.85.0.189825047298.issue28670@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 19:17:12 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Nov 2016 00:17:12 +0000 Subject: [issue28573] Python 3.6.0b3 64-bit has no sys._mercurial info In-Reply-To: <1477975263.28.0.609263953959.issue28573@psf.upfronthosting.co.za> Message-ID: <20161115001708.11937.6341.C6BC4DB4@psf.io> Roundup Robot added the comment: New changeset 25cb7df5b19d by Steve Dower in branch '3.6': Issue #28573: Avoid setting up env too many times during build https://hg.python.org/cpython/rev/25cb7df5b19d New changeset ae8f525cef2a by Steve Dower in branch 'default': Issue #28573: Avoid setting up env too many times during build https://hg.python.org/cpython/rev/ae8f525cef2a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 19:20:38 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 15 Nov 2016 00:20:38 +0000 Subject: [issue28573] Python 3.6.0b3 64-bit has no sys._mercurial info In-Reply-To: <1477975263.28.0.609263953959.issue28573@psf.upfronthosting.co.za> Message-ID: <1479169238.85.0.348398361404.issue28573@psf.upfronthosting.co.za> Steve Dower added the comment: I suspect this is because my PATH was getting too long within my build script because of setting up the VS build environment too many times (if PATH gets too long then new processes may ignore or truncate it). The commit should cut this down to the point where we don't lose Mercurial off of PATH, but I'm running validation builds to be sure. As this only applies to the Windows builds and we haven't seen it against 3.5 yet, I'm dropping that from the versions list. ---------- stage: test needed -> commit review versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 20:52:04 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Nov 2016 01:52:04 +0000 Subject: [issue28573] Python 3.6.0b3 64-bit has no sys._mercurial info In-Reply-To: <1477975263.28.0.609263953959.issue28573@psf.upfronthosting.co.za> Message-ID: <20161115015200.13690.54616.79E29D1F@psf.io> Roundup Robot added the comment: New changeset d997e64130bd by Steve Dower in branch '3.6': Issue #28573: Fixes issue with nested if blocks https://hg.python.org/cpython/rev/d997e64130bd New changeset 35f510158490 by Steve Dower in branch 'default': Issue #28573: Fixes issue with nested if blocks https://hg.python.org/cpython/rev/35f510158490 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 20:52:40 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 15 Nov 2016 01:52:40 +0000 Subject: [issue28573] Python 3.6.0b3 64-bit has no sys._mercurial info In-Reply-To: <1477975263.28.0.609263953959.issue28573@psf.upfronthosting.co.za> Message-ID: <1479174760.99.0.652435431028.issue28573@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 20:53:20 2016 From: report at bugs.python.org (Lance Ware) Date: Tue, 15 Nov 2016 01:53:20 +0000 Subject: [issue28694] tkinter interface to fontchooser Message-ID: <1479174800.7.0.200377827869.issue28694@psf.upfronthosting.co.za> New submission from Lance Ware: Tcl/Tk 8.6 now has a fontchooser command. I have developed a tkinter interface to it, similar to colorchooser/askcolor. How does one go about contributing this or proposing for future enhancement to the tkinter module suite? ---------- components: Tkinter messages: 280820 nosy: Lance Ware priority: normal severity: normal status: open title: tkinter interface to fontchooser type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 21:48:18 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 15 Nov 2016 02:48:18 +0000 Subject: [issue28692] gettext: deprecate selecting plural form by fractional numbers In-Reply-To: <1479148679.54.0.229445108959.issue28692@psf.upfronthosting.co.za> Message-ID: <1479178098.97.0.97227569743.issue28692@psf.upfronthosting.co.za> Xiang Zhang added the comment: Maybe you have forgotten to remove the debug print in the patch? ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 22:34:50 2016 From: report at bugs.python.org (Kushal Das) Date: Tue, 15 Nov 2016 03:34:50 +0000 Subject: [issue28666] Make test.support.rmtree() able to remove non-writable directories In-Reply-To: <1478866355.91.0.707083472132.issue28666@psf.upfronthosting.co.za> Message-ID: <1479180890.16.0.845959384004.issue28666@psf.upfronthosting.co.za> Kushal Das added the comment: The patch looks good to me. This can be applied, and tests are running fine with the patch. https://ci.centos.org/job/cPython-build-patch/25/console ---------- nosy: +kushal.das _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 22:41:11 2016 From: report at bugs.python.org (Zachary Ware) Date: Tue, 15 Nov 2016 03:41:11 +0000 Subject: [issue28694] tkinter interface to fontchooser In-Reply-To: <1479174800.7.0.200377827869.issue28694@psf.upfronthosting.co.za> Message-ID: <1479181271.57.0.688906627402.issue28694@psf.upfronthosting.co.za> Zachary Ware added the comment: You've already done the proposing part by opening this issue ;). To contribute you work, attach it here as a patch to the tkinter sources found in Lib/tkinter/ of a cpython source checkout. You'll need to sign a contributor agreement before we can look at or accept it, the tracker should prompt you to do so when you attach your patch. The devguide is also a great resource for questions you may have while preparing your patch. Thanks for your interest in contributing! ---------- nosy: +serhiy.storchaka, terry.reedy, zach.ware stage: -> needs patch versions: +Python 3.7 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 14 23:15:52 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 15 Nov 2016 04:15:52 +0000 Subject: [issue28694] tkinter interface to fontchooser In-Reply-To: <1479174800.7.0.200377827869.issue28694@psf.upfronthosting.co.za> Message-ID: <1479183352.0.0.293169593109.issue28694@psf.upfronthosting.co.za> Terry J. Reedy added the comment: https://www.tcl.tk/man/tcl/TkCmd/fontchooser.htm I agree that this should be wrapped, as is colorchooser. There are a few details that may need to be thrashed out. It is a nuisance that the native font dialog is modal on Windows and not on Mac (and ??? on *nix?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 00:49:15 2016 From: report at bugs.python.org (Michael Witten) Date: Tue, 15 Nov 2016 05:49:15 +0000 Subject: [issue28670] PEP 235: Implement on every POSIX system, and clean up the C code for `import' In-Reply-To: <1478899111.69.0.0154952768919.issue28670@psf.upfronthosting.co.za> Message-ID: <1479188955.95.0.359252113134.issue28670@psf.upfronthosting.co.za> Michael Witten added the comment: Thank you for the reply. * As already stated, I believe that Python 3 is not affected by this problem; certainly, version 3.5.2 does not seem to be affected, as per my ad hoc testing. * Very many programs are targeted to Python 2.7, and probably will be for quite some time. Without my patch, `python' (2.7) itself breaks them as described; yet, with my patch, these programs will just work (without intervention). It seems to me that this patch isn't a change in a feature, but is rather the overdue implementation of promised behavior; the file system is what matters, not the host operating system, which has hitherto been conflated with the file system. That is, this patch is a bug fix. * I'm not sure how a test could be written to handle this situation. I suppose that by default, such a test could be skipped with a warning; a user could be required to set up a relevant mount point, and then to signal the testing infrastructure to use it. --------------- * With regard to the form of the patches, my intention is that they be introduced into the history severally, with the commit messages and other metadata as specified. It would probably make most sense for these commits to be the ancestors of a merge commit that provides the sole reference to this tracker issue. For instance, the most correct and useful application of the patch series is given by the following: $ hg pull --branch 2.7 # This must pull in something new for the rest to work. $ tip=$(hg log --limit 1 --template '{node}' -r tip) $ hg update -c -r 59260b38f7cd4a2ae66928de5227798524006e64 $ hg import /path/to/pep-235-on-posix.patch $ hg merge -r "$tip" $ hg commit --message "Issue #28670: Implement PEP 235 on every POSIX system, and clean up the C code for \`import'" That produces a single commit whose message supplies the usual dearth of information, but whose ancestral history captures the rich details. It should be noted that `hg bundle' and `hg unbundle' could be used to import more directly the proper pre-merge history, albeit at the expense of the human-readability of the "patch" file. That is to say, I'm underwhelmed by the way you guys are managing this project's history. Despite all of its faults, Mercurial is still being underutilized. * I could split the original patch file into 3 separate patch files, but what should I do with the metadata? If each separate patch were to contain its own metadata, would the code review tool still choke? I suspect it would. What's the point? The original file itself is perfectly readable, and you can simply review the diffs after applying them within your repo, anyway. Ironically, the very point of having multiple changesets is to make digesting the changes as easy as possible---not only now, but far into the future, when you're simply looking at the graph of the history! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 03:13:07 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Nov 2016 08:13:07 +0000 Subject: [issue28691] python3.6 -Werror -c '"\c"' fails with an assertion error In-Reply-To: <1479142386.33.0.817704504707.issue28691@psf.upfronthosting.co.za> Message-ID: <20161115081259.13588.91327.C16F55CD@psf.io> Roundup Robot added the comment: New changeset aa52ea2a7731 by Victor Stinner in branch '3.6': Fix warn_invalid_escape_sequence() https://hg.python.org/cpython/rev/aa52ea2a7731 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 03:14:16 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Nov 2016 08:14:16 +0000 Subject: [issue28691] python3.6 -Werror -c '"\c"' fails with an assertion error In-Reply-To: <1479142386.33.0.817704504707.issue28691@psf.upfronthosting.co.za> Message-ID: <1479197656.7.0.267436663045.issue28691@psf.upfronthosting.co.za> STINNER Victor added the comment: Thanks Serhiy for your unit tests! I pushed with patch with your tests. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 03:29:18 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Nov 2016 08:29:18 +0000 Subject: [issue28693] No HKSCS support in Windows cp950 In-Reply-To: <1479154148.6.0.43343383532.issue28693@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Python supports native Windows code pages using codecs.code_page_encode() and codecs.code_page_decode() methods. See for example Lib/encodings/cp65001.py : this codec is not implemented in Python, but is a wrapper to native Windows functions (MultiByteToWideChar and WideCharToMultiByte). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 05:03:49 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Nov 2016 10:03:49 +0000 Subject: [issue28690] Loop in re (regular expression) processing In-Reply-To: <1479140687.65.0.411208896351.issue28690@psf.upfronthosting.co.za> Message-ID: <1479204229.42.0.0983612924254.issue28690@psf.upfronthosting.co.za> STINNER Victor added the comment: It's not really a bug, but more a trap of regular expressions. It seems like you fixed your issue, so I close it. ---------- nosy: +haypo resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 06:01:28 2016 From: report at bugs.python.org (Christian Heimes) Date: Tue, 15 Nov 2016 11:01:28 +0000 Subject: [issue28695] Add SSL_CTX_set_client_cert_engine Message-ID: <1479207688.81.0.066994858547.issue28695@psf.upfronthosting.co.za> New submission from Christian Heimes: Python's ssl module does not support smartcard authentication of clients. In order to use an external engine like OpenSC's engine_pkcs11, SSLContext must be configured to use a loaded engine for client cert auth. It's really simple. Pseudo code without error reporting, engine_id is a char*: ENGINE *e = ENGINE_by_id(engine_id); SSL_CTX_set_client_cert_engine(ctx, e); ---------- assignee: christian.heimes components: SSL messages: 280830 nosy: christian.heimes priority: normal severity: normal stage: needs patch status: open title: Add SSL_CTX_set_client_cert_engine type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 06:01:35 2016 From: report at bugs.python.org (Christian Heimes) Date: Tue, 15 Nov 2016 11:01:35 +0000 Subject: [issue28695] Add SSL_CTX_set_client_cert_engine In-Reply-To: <1479207688.81.0.066994858547.issue28695@psf.upfronthosting.co.za> Message-ID: <1479207695.51.0.759057189779.issue28695@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 06:56:36 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 15 Nov 2016 11:56:36 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1479210996.84.0.948834895663.issue28618@psf.upfronthosting.co.za> INADA Naoki added the comment: > I don't understand well the effect of the hot attribute I compared lookdict_unicode_nodummy assembly by `objdump -d dictobject.o`. It looks completely same. So I think only difference is placement. hot functions are in .text.hot section and linker groups hot functions. This reduces cache hazard possibility. When compiling Python with PGO, we can see what function is hot by objdump. ``` ~/work/cpython/Objects$ objdump -tj .text.hot dictobject.o dictobject.o: file format elf64-x86-64 SYMBOL TABLE: 0000000000000000 l d .text.hot 0000000000000000 .text.hot 00000000000007a0 l F .text.hot 0000000000000574 lookdict_unicode_nodummy 00000000000046d0 l F .text.hot 00000000000000e8 free_keys_object 00000000000001c0 l F .text.hot 0000000000000161 new_keys_object 00000000000003b0 l F .text.hot 00000000000003e8 insertdict 0000000000001180 l F .text.hot 000000000000081f dictresize 00000000000019a0 l F .text.hot 0000000000000165 find_empty_slot.isra.0 0000000000002180 l F .text.hot 00000000000005f1 lookdict 0000000000001b10 l F .text.hot 00000000000000c2 unicode_eq 0000000000002780 l F .text.hot 0000000000000184 dict_traverse 0000000000004c20 l F .text.hot 00000000000005f7 lookdict_unicode 0000000000006b20 l F .text.hot 0000000000000330 lookdict_split ... ``` cold section of hot function is placed in .text.unlikely section. ``` $ objdump -t dictobject.o | grep lookdict 00000000000007a0 l F .text.hot 0000000000000574 lookdict_unicode_nodummy 0000000000002180 l F .text.hot 00000000000005f1 lookdict 000000000000013e l .text.unlikely 0000000000000000 lookdict_unicode_nodummy.cold.6 0000000000000a38 l .text.unlikely 0000000000000000 lookdict.cold.15 0000000000004c20 l F .text.hot 00000000000005f7 lookdict_unicode 0000000000006b20 l F .text.hot 0000000000000330 lookdict_split 0000000000001339 l .text.unlikely 0000000000000000 lookdict_unicode.cold.28 0000000000001d01 l .text.unlikely 0000000000000000 lookdict_split.cold.42 ``` All lookdict* function are put in hot section, and all of cold part is 0 byte. It seems PGO put all lookdict* functions in hot section. compiler info: ``` $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ``` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 07:04:06 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 15 Nov 2016 12:04:06 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1479211446.64.0.271351136682.issue28618@psf.upfronthosting.co.za> INADA Naoki added the comment: > so I suggest to run benchmarks and check that it has a non negligible effect on benchmarks ;-) When added _Py_HOT_FUNCTION to lookdict_unicode, lookdict_unicode_nodummy and lookdict_split (I can't measure L1 miss via `perf stat -d` because I use EC2 for benchmark): $ ~/local/python-master/bin/python3 -m perf compare_to -G all-master.json all-patched.json Slower (28): - pybench.CompareFloats: 106 ns +- 1 ns -> 112 ns +- 1 ns: 1.07x slower - pybench.BuiltinFunctionCalls: 1.62 us +- 0.00 us -> 1.68 us +- 0.03 us: 1.04x slower - pybench.CompareFloatsIntegers: 180 ns +- 3 ns -> 185 ns +- 3 ns: 1.03x slower - sympy_sum: 163 ms +- 7 ms -> 167 ms +- 7 ms: 1.03x slower - deltablue: 13.7 ms +- 0.4 ms -> 14.1 ms +- 0.5 ms: 1.02x slower - pickle_list: 5.77 us +- 0.09 us -> 5.90 us +- 0.07 us: 1.02x slower - pybench.PythonFunctionCalls: 1.20 us +- 0.02 us -> 1.22 us +- 0.02 us: 1.02x slower - pybench.SpecialClassAttribute: 1.46 us +- 0.02 us -> 1.49 us +- 0.03 us: 1.02x slower - pybench.TryRaiseExcept: 207 ns +- 4 ns -> 210 ns +- 0 ns: 1.02x slower - pickle_pure_python: 868 us +- 18 us -> 882 us +- 16 us: 1.02x slower - genshi_text: 56.0 ms +- 0.7 ms -> 56.8 ms +- 0.6 ms: 1.01x slower - json_dumps: 19.5 ms +- 0.3 ms -> 19.8 ms +- 0.2 ms: 1.01x slower - richards: 137 ms +- 3 ms -> 139 ms +- 2 ms: 1.01x slower - sqlalchemy_declarative: 272 ms +- 4 ms -> 276 ms +- 3 ms: 1.01x slower - pickle_dict: 43.5 us +- 0.4 us -> 44.1 us +- 0.2 us: 1.01x slower - go: 436 ms +- 4 ms -> 441 ms +- 4 ms: 1.01x slower - pybench.SecondImport: 2.52 us +- 0.04 us -> 2.55 us +- 0.07 us: 1.01x slower - pybench.NormalClassAttribute: 1.46 us +- 0.02 us -> 1.47 us +- 0.02 us: 1.01x slower - genshi_xml: 118 ms +- 2 ms -> 118 ms +- 3 ms: 1.01x slower - pybench.UnicodePredicates: 75.8 ns +- 0.6 ns -> 76.2 ns +- 0.9 ns: 1.01x slower - pybench.ListSlicing: 415 us +- 4 us -> 417 us +- 4 us: 1.01x slower - scimark_fft: 494 ms +- 2 ms -> 496 ms +- 12 ms: 1.01x slower - logging_format: 23.7 us +- 0.3 us -> 23.9 us +- 0.4 us: 1.00x slower - chaos: 200 ms +- 1 ms -> 201 ms +- 1 ms: 1.00x slower - pybench.StringPredicates: 509 ns +- 3 ns -> 511 ns +- 4 ns: 1.00x slower - call_method: 13.6 ms +- 0.1 ms -> 13.7 ms +- 0.2 ms: 1.00x slower - pybench.StringSlicing: 530 ns +- 3 ns -> 532 ns +- 8 ns: 1.00x slower - pybench.SimpleLongArithmetic: 535 ns +- 2 ns -> 536 ns +- 4 ns: 1.00x slower Faster (47): - html5lib: 169 ms +- 7 ms -> 158 ms +- 6 ms: 1.07x faster - pybench.ConcatUnicode: 57.3 ns +- 3.0 ns -> 55.8 ns +- 1.3 ns: 1.03x faster - pybench.IfThenElse: 60.5 ns +- 1.0 ns -> 59.0 ns +- 0.7 ns: 1.02x faster - logging_silent: 606 ns +- 14 ns -> 593 ns +- 13 ns: 1.02x faster - scimark_lu: 411 ms +- 5 ms -> 404 ms +- 4 ms: 1.02x faster - pathlib: 29.1 ms +- 0.3 ms -> 28.7 ms +- 0.5 ms: 1.02x faster - pybench.CreateStringsWithConcat: 2.87 us +- 0.01 us -> 2.82 us +- 0.00 us: 1.02x faster - pybench.DictCreation: 621 ns +- 10 ns -> 612 ns +- 8 ns: 1.01x faster - meteor_contest: 167 ms +- 5 ms -> 164 ms +- 5 ms: 1.01x faster - unpickle_pure_python: 656 us +- 19 us -> 647 us +- 9 us: 1.01x faster - pybench.NestedForLoops: 20.2 ns +- 0.1 ns -> 20.0 ns +- 0.1 ns: 1.01x faster - regex_effbot: 4.01 ms +- 0.07 ms -> 3.95 ms +- 0.06 ms: 1.01x faster - pybench.CreateUnicodeWithConcat: 57.1 ns +- 0.2 ns -> 56.4 ns +- 0.2 ns: 1.01x faster - chameleon: 18.3 ms +- 0.2 ms -> 18.0 ms +- 0.3 ms: 1.01x faster - python_startup: 13.7 ms +- 0.1 ms -> 13.5 ms +- 0.1 ms: 1.01x faster - pybench.SmallTuples: 967 ns +- 6 ns -> 955 ns +- 8 ns: 1.01x faster - pybench.TryFinally: 200 ns +- 3 ns -> 198 ns +- 2 ns: 1.01x faster - pybench.SimpleIntegerArithmetic: 425 ns +- 3 ns -> 420 ns +- 4 ns: 1.01x faster - pybench.Recursion: 1.34 us +- 0.02 us -> 1.33 us +- 0.03 us: 1.01x faster - pybench.SimpleIntFloatArithmetic: 424 ns +- 1 ns -> 420 ns +- 1 ns: 1.01x faster - float: 222 ms +- 2 ms -> 220 ms +- 3 ms: 1.01x faster - 2to3: 531 ms +- 4 ms -> 527 ms +- 5 ms: 1.01x faster - python_startup_no_site: 8.30 ms +- 0.04 ms -> 8.23 ms +- 0.05 ms: 1.01x faster - xml_etree_parse: 196 ms +- 5 ms -> 194 ms +- 2 ms: 1.01x faster - pybench.ComplexPythonFunctionCalls: 794 ns +- 7 ns -> 788 ns +- 7 ns: 1.01x faster - logging_simple: 20.4 us +- 0.2 us -> 20.3 us +- 0.4 us: 1.01x faster - fannkuch: 795 ms +- 9 ms -> 790 ms +- 3 ms: 1.01x faster - hexiom: 18.7 ms +- 0.1 ms -> 18.6 ms +- 0.1 ms: 1.01x faster - regex_compile: 322 ms +- 9 ms -> 320 ms +- 8 ms: 1.01x faster - mako: 36.0 ms +- 0.1 ms -> 35.8 ms +- 0.2 ms: 1.01x faster - pybench.UnicodeProperties: 91.7 ns +- 0.9 ns -> 91.1 ns +- 0.8 ns: 1.01x faster - pybench.SimpleComplexArithmetic: 577 ns +- 8 ns -> 573 ns +- 3 ns: 1.01x faster - xml_etree_process: 147 ms +- 2 ms -> 146 ms +- 2 ms: 1.01x faster - pybench.CompareUnicode: 22.4 ns +- 0.1 ns -> 22.2 ns +- 0.1 ns: 1.01x faster - crypto_pyaes: 175 ms +- 1 ms -> 174 ms +- 1 ms: 1.01x faster - unpickle_list: 5.43 us +- 0.04 us -> 5.41 us +- 0.02 us: 1.01x faster - pybench.WithFinally: 257 ns +- 4 ns -> 256 ns +- 2 ns: 1.01x faster - xml_etree_generate: 183 ms +- 2 ms -> 182 ms +- 2 ms: 1.00x faster - pybench.WithRaiseExcept: 475 ns +- 4 ns -> 472 ns +- 6 ns: 1.00x faster - pybench.SecondPackageImport: 2.85 us +- 0.08 us -> 2.84 us +- 0.09 us: 1.00x faster - pybench.SimpleListManipulation: 444 ns +- 1 ns -> 442 ns +- 2 ns: 1.00x faster - spectral_norm: 208 ms +- 2 ms -> 208 ms +- 1 ms: 1.00x faster - pybench.ForLoops: 8.95 ns +- 0.19 ns -> 8.94 ns +- 0.01 ns: 1.00x faster - scimark_sor: 371 ms +- 3 ms -> 371 ms +- 2 ms: 1.00x faster - scimark_sparse_mat_mult: 5.61 ms +- 0.06 ms -> 5.61 ms +- 0.36 ms: 1.00x faster - pybench.UnicodeMappings: 40.7 us +- 0.1 us -> 40.7 us +- 0.0 us: 1.00x faster - pybench.CompareStrings: 22.2 ns +- 0.0 ns -> 22.2 ns +- 0.0 ns: 1.00x faster Benchmark hidden because not significant (47): call_method_slots, call_method_unknown, call_simple, django_template, dulwich_log, json_loads, nbody, nqueens, pickle, pidigits, pybench.BuiltinMethodLookup, pybench.CompareIntegers, pybench. CompareInternedStrings, pybench.CompareLongs, pybench.ConcatStrings, pybench.CreateInstances, pybench.CreateNewInstances, pybench.DictWithFloatKeys, pybench.DictWithIntegerKeys, pybench.DictWithStringKeys, pybench.NestedListComprehensions , pybench.NormalInstanceAttribute, pybench.PythonMethodCalls, pybench.SecondSubmoduleImport, pybench.SimpleDictManipulation, pybench.SimpleFloatArithmetic, pybench.SimpleListComprehensions, pybench.SmallLists, pybench.SpecialInstanceAttri bute, pybench.StringMappings, pybench.TryExcept, pybench.TupleSlicing, pybench.UnicodeSlicing, raytrace, regex_dna, regex_v8, scimark_monte_carlo, sqlalchemy_imperative, sqlite_synth, sympy_expand, sympy_integrate, sympy_str, telco, torna do_http, unpack_sequence, unpickle, xml_etree_iterparse ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 07:52:50 2016 From: report at bugs.python.org (Lev Veshnyakov) Date: Tue, 15 Nov 2016 12:52:50 +0000 Subject: [issue28696] imap from ThreadPool hangs by an exception in a generator function Message-ID: <1479214370.8.0.751710549169.issue28696@psf.upfronthosting.co.za> New submission from Lev Veshnyakov: It's only in imap, in map it's ok. The following code explains the issue: from multiprocessing.pool import ThreadPool pool = ThreadPool(10) def gen(): yield 1 + '1' # here is an error try: next((pool.imap(str, gen()))) except: # Will be catched using pool.map normally, but using pool.imap will be not. # Instead it hangs. This is the same for ThreadPool and Pool. print('this will not be printed because thread is hanging') ---------- components: Library (Lib) files: test.py messages: 280833 nosy: lev-veshnyakov priority: normal severity: normal status: open title: imap from ThreadPool hangs by an exception in a generator function type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file45486/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 07:56:59 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Nov 2016 12:56:59 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479214619.85.0.264707507434.issue21449@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: _PyUnicode_FromId would not fail due to bad encoded data if use the Latin1 encoding. Seems encoded data always is ASCII. We could use PyErr_WriteUnraisable() for output a warning if it is not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 08:00:28 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Nov 2016 13:00:28 +0000 Subject: [issue28692] gettext: deprecate selecting plural form by fractional numbers In-Reply-To: <1479148679.54.0.229445108959.issue28692@psf.upfronthosting.co.za> Message-ID: <1479214828.83.0.254011117895.issue28692@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, of cause. Thank your for noticing this. ---------- Added file: http://bugs.python.org/file45487/gettext-non-int-plural-deprecate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 08:02:12 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 15 Nov 2016 13:02:12 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479214932.84.0.135347677999.issue21449@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 08:34:09 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Nov 2016 13:34:09 +0000 Subject: [issue28082] re: convert re flags to (much friendlier) IntFlag constants In-Reply-To: <1473625770.04.0.107359046953.issue28082@psf.upfronthosting.co.za> Message-ID: <1479216849.25.0.577059879382.issue28082@psf.upfronthosting.co.za> STINNER Victor added the comment: The change 5fd69d4a93e0 (use IntFlag for re constants) made the "regex_compile" benchmark slower: Median +- std dev: [71c1970f27b6] 388 ms +- 3 ms -> [3cf248d10bed] 470 ms +- 4 ms: 1.21x slower ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 08:44:53 2016 From: report at bugs.python.org (Kubilay Kocak) Date: Tue, 15 Nov 2016 13:44:53 +0000 Subject: [issue27838] test_os.test_chown() failure on koobs-freebsd-{current, 9} In-Reply-To: <1471959658.26.0.0626423066304.issue27838@psf.upfronthosting.co.za> Message-ID: <1479217493.06.0.560876773722.issue27838@psf.upfronthosting.co.za> Kubilay Kocak added the comment: @Serhiy I have noticed that the failure is reproducible in the buildbot workers only when startup (of buildbot) is invoked via sudo, and not when started on first-boot (rc runs as root). In both situations, twistd then drops privs to --uid=buildbot --gid=buildbot). However, I *cannot* reproduce the failure (python -m test.regrtest test_os) on a clean checkout and build of 3.x either under a normal user, *or* under sudo. I think we need some instrumentation added to test to see whats happening. We can add that instrumentation and also test your patch committed to a private hg branch using the 'custom' builder. I can also provide SSH access to the buildbot hosts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 08:52:18 2016 From: report at bugs.python.org (Davin Potts) Date: Tue, 15 Nov 2016 13:52:18 +0000 Subject: [issue28696] imap from ThreadPool hangs by an exception in a generator function In-Reply-To: <1479214370.8.0.751710549169.issue28696@psf.upfronthosting.co.za> Message-ID: <1479217938.65.0.0448446740962.issue28696@psf.upfronthosting.co.za> Davin Potts added the comment: Using the supplied example, I was unable to reproduce what you described using either 3.5 or 3.6-beta on OS X 10.11. What platform are you using? (Perhaps it is platform specific.) ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 08:53:31 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 15 Nov 2016 13:53:31 +0000 Subject: [issue28692] gettext: deprecate selecting plural form by fractional numbers In-Reply-To: <1479148679.54.0.229445108959.issue28692@psf.upfronthosting.co.za> Message-ID: <1479218011.2.0.134172752777.issue28692@psf.upfronthosting.co.za> Xiang Zhang added the comment: I think the stacklevel should be 3. stacklevel = 3: ./python -Walways /tmp/a.py /tmp/a.py:2: DeprecationWarning: Plural value must be an integer, got float c2py('n!=1')(1.1) stacklevel = 4: ./python -Walways /tmp/a.py sys:1: DeprecationWarning: Plural value must be an integer, got float ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 08:55:37 2016 From: report at bugs.python.org (Lev Veshnyakov) Date: Tue, 15 Nov 2016 13:55:37 +0000 Subject: [issue28696] imap from ThreadPool hangs by an exception in a generator function In-Reply-To: <1479214370.8.0.751710549169.issue28696@psf.upfronthosting.co.za> Message-ID: <1479218137.57.0.210075907021.issue28696@psf.upfronthosting.co.za> Lev Veshnyakov added the comment: Ubuntu 14.04 LTS, 3.13.0-83-generic, x86_64 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 09:00:45 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 15 Nov 2016 14:00:45 +0000 Subject: [issue28692] gettext: deprecate selecting plural form by fractional numbers In-Reply-To: <1479148679.54.0.229445108959.issue28692@psf.upfronthosting.co.za> Message-ID: <1479218445.79.0.124027987049.issue28692@psf.upfronthosting.co.za> Xiang Zhang added the comment: Ohh, sorry. It should be 4 and I make a mistake. Sorry for the noise. Patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 09:04:29 2016 From: report at bugs.python.org (Lev Veshnyakov) Date: Tue, 15 Nov 2016 14:04:29 +0000 Subject: [issue28696] imap from ThreadPool hangs by an exception in a generator function In-Reply-To: <1479214370.8.0.751710549169.issue28696@psf.upfronthosting.co.za> Message-ID: <1479218669.54.0.105302590271.issue28696@psf.upfronthosting.co.za> Lev Veshnyakov added the comment: So, I've checked twice, it's presented by me on python 3.4.3, and not by 3.5.2. So I will go deaper ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 09:08:08 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Nov 2016 14:08:08 +0000 Subject: [issue24329] __qualname__ and __slots__ In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za> Message-ID: <1479218888.54.0.577203834723.issue24329@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 09:09:08 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Nov 2016 14:09:08 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479218948.15.0.539316021911.issue21449@psf.upfronthosting.co.za> STINNER Victor added the comment: Please don't modify _PyUnicode_FromId(), I prefer to keep it as it is, decode from UTF-8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 09:15:28 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Nov 2016 14:15:28 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <20161115141524.12047.78492.E3ADDF61@psf.io> Roundup Robot added the comment: New changeset cfc956f13ce2 by Victor Stinner in branch 'default': Issue #28618: Mark dict lookup functions as hot https://hg.python.org/cpython/rev/cfc956f13ce2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 09:18:35 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Nov 2016 14:18:35 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1479219515.58.0.919148562259.issue28618@psf.upfronthosting.co.za> STINNER Victor added the comment: > How about marking lookdict_unicode and lookdict_unicode_nodummy as hot? Ok, your benchmark results doens't look bad, so I marked the following functions as hot: - lookdict - lookdict_unicode - lookdict_unicode_nodummy - lookdict_split It's common to see these functions in the top 3 of "perf report". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 09:21:57 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Nov 2016 14:21:57 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1479219717.6.0.12321709438.issue28618@psf.upfronthosting.co.za> STINNER Victor added the comment: hot3.patch: Mark additional functions as hot * PyNumber_AsSsize_t() * _PyUnicode_FromUCS1() * json: scanstring_unicode() * siphash24() * sre_ucs1_match, sre_ucs2_match, sre_ucs4_match I'm not sure about this patch. It's hard to get reliable benchmark results on microbenchmarks :-/ It's hard to understand if a speedup comes from the hot attribute, or if the compiler decided itself to change the code placement. Without the hot attribute, the code placement seems random. ---------- Added file: http://bugs.python.org/file45488/hot3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 09:25:36 2016 From: report at bugs.python.org (Mingye Wang) Date: Tue, 15 Nov 2016 14:25:36 +0000 Subject: [issue28343] Bad encoding alias cp936 -> gbk: euro sign In-Reply-To: <1475464291.36.0.0934021228231.issue28343@psf.upfronthosting.co.za> Message-ID: <1479219936.55.0.0110524078288.issue28343@psf.upfronthosting.co.za> Mingye Wang added the comment: Also, go to ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit936.txt for MS reference. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 09:26:27 2016 From: report at bugs.python.org (Martijn Pieters) Date: Tue, 15 Nov 2016 14:26:27 +0000 Subject: [issue1633941] for line in sys.stdin: doesn't notice EOF the first time Message-ID: <1479219987.92.0.199011791216.issue1633941@psf.upfronthosting.co.za> Martijn Pieters added the comment: This bug affects all use of `file.__iter__` and interrupts (EINTR), not just sys.stdin. You can reproduce the issue by reading from a (slow) pipe in a terminal window and resizing that window, for example; the interrupt is not handled and a future call ends up raising `IOError: [Errno 0] Error`, a rather confusing message. The Mercurial community is switching away from using direct iteration over this bug; Jun's excellent analysis is included and enlightening: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-November/090522.html The fix is to use interrupted = ferror(f->f_fp) && errno == EINTR; // .. if (interrupted) { clearerr(f->f_fp); if (PyErr_CheckSignals()) { Py_DECREF(v); return NULL; } } and check for interrupted == 0 in the chunksize == 0 case after Py_UniversalNewlineFread calls, as file_read does, for example, but which readahead doesn't (where the only public user of readahead is file_iternext). ---------- nosy: +mjpieters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 09:28:34 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Nov 2016 14:28:34 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1479219717.6.0.12321709438.issue28618@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I wrote hot3.patch when trying to make the following benchmarks more reliable: - logging_silent: rev 8ebaa546a033 is 20% slower than the average en 2016 - json_loads: rev 0bd618fe0639 is 30% slower and rev 8ebaa546a033 is 15% slower than the average on 2016 - regex_effbot: rev 573bc1f9900e (nov 7) takes 6.0 ms, rev cf7711887b4a (nov 7) takes 5.2 ms, rev 8ebaa546a033 (nov 10) takes 6.1 ms, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 09:32:26 2016 From: report at bugs.python.org (Martijn Pieters) Date: Tue, 15 Nov 2016 14:32:26 +0000 Subject: [issue21090] File read silently stops after EIO I/O error In-Reply-To: <1396045786.33.0.781369785301.issue21090@psf.upfronthosting.co.za> Message-ID: <1479220346.37.0.368974929583.issue21090@psf.upfronthosting.co.za> Martijn Pieters added the comment: The Python 2.7 issue (using fread without checking for interrupts) looks like a duplicate of http://bugs.python.org/issue1633941 ---------- nosy: +mjpieters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 09:35:14 2016 From: report at bugs.python.org (Martijn Pieters) Date: Tue, 15 Nov 2016 14:35:14 +0000 Subject: [issue1633941] for line in sys.stdin: doesn't notice EOF the first time Message-ID: <1479220514.31.0.0797497610434.issue1633941@psf.upfronthosting.co.za> Martijn Pieters added the comment: It looks like readahead was missed when http://bugs.python.org/issue12268 was fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 09:36:08 2016 From: report at bugs.python.org (Martijn Pieters) Date: Tue, 15 Nov 2016 14:36:08 +0000 Subject: [issue12268] file readline, readlines & readall methods can lose data on EINTR In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za> Message-ID: <1479220568.06.0.978502019155.issue12268@psf.upfronthosting.co.za> Martijn Pieters added the comment: Follow-up bug, readahead was missed: http://bugs.python.org/issue1633941 ---------- nosy: +mjpieters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 09:40:01 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Nov 2016 14:40:01 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1479220801.94.0.407693816098.issue28618@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > * json: scanstring_unicode() This doesn't look wise. This is specific to single extension module and perhaps to single particular benchmark. Most Python code don't use json at all. What is the top of "perf report"? How this list intersects with the list of functions in .text.hot section of PGO build? Make several PGO builds (perhaps on different computers). Is .text.hot section stable? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 09:45:45 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Nov 2016 14:45:45 +0000 Subject: [issue1633941] for line in sys.stdin: doesn't notice EOF the first time Message-ID: <1479221145.88.0.169086532086.issue1633941@psf.upfronthosting.co.za> STINNER Victor added the comment: Martijn Pieters: Sadly, Python 2 I/O are full of bugs in corner cases :-/ First of all, in most cases, Python 2 uses the libc for I/O, but the libc has known bugs including segfaults: https://haypo-notes.readthedocs.io/python.html#bugs-in-the-c-stdio-used-by-the-python-i-o Python 3 is better to handle EINTR. EINTR should now be "fully supported" in Python 3.5 thanks for the PEP 475. I mean in the Python core, I don't expect that any third party implement the PEP 475. Hopefully, most third party module don't implement syscall wrappers themself, but reuse Python which handles EINTR for them. To come back to Python 2: yeah, we still have to fix issues to make the code more robust in corner cases, and enhance error reporting. It seems like fread() errors are not checked correctly in some places. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 09:47:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Nov 2016 14:47:35 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479221255.56.0.622488403343.issue21449@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Please don't modify _PyUnicode_FromId(), I prefer to keep it as it is, decode from UTF-8. Then we should add handling of three special cases: PyUnicode_READY() fails, _PyUnicode_FromId() fails and both fail due to memory error. This means that should be implemented character-by-character encoding of UCS1, UCS2, UCS4 or wchar_t (with possible surrogate pairs) to UTF-8 and comparing with UTF-8 encoded data. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 09:53:02 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Nov 2016 14:53:02 +0000 Subject: [issue1633941] for line in sys.stdin: doesn't notice EOF the first time Message-ID: <1479221582.7.0.181004298398.issue1633941@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't see any simple solution to get a 100% reliable I/O stack on Python 2. Python 3.5 contains a pure Python implementation of the io module: _pyio.FileIO uses os.read() and os.write(). In Python 3.4 and older, the _pyio still used io.FileIO (implemented in C). But try to recall Python 3.0 which had *very* bad I/O performance because its io module was fully implemented in pure Python! The uvloop project proved that Python can be very efficient for (network) I/O using code written with Cython. But I also know that Mercurial cares of PyPy which is not really Cython-friendly. Even if fread() bugs are fixed in Python 2.7.x+1, you will still hit bugs on Python 2.7.x and older. Maybe it can be a strong motivation to pursue your Python 3 efforts :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 10:04:28 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Nov 2016 15:04:28 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479222268.87.0.291274878163.issue21449@psf.upfronthosting.co.za> STINNER Victor added the comment: > This issue is not just about readability or performance. It is about correctness, since none of callers check for failure of _PyUnicode_CompareWithId. Callers should be fixed to handle errors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 10:31:35 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 15 Nov 2016 15:31:35 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479223895.57.0.0560916419181.issue21449@psf.upfronthosting.co.za> Xiang Zhang added the comment: Since currently _PyUnicode_CompareWithId is used to compare a unicode with ascii identifiers for all cases, how about introduce a more specific function like _PyUnicode_EqualToASCIIId for this case? We can preserve _PyUnicode_CompareWithId for more general purpose usage. It's much easier to write a error free _PyUnicode_EqualToASCIIId. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 10:42:10 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Nov 2016 15:42:10 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1479224530.7.0.248948181189.issue28618@psf.upfronthosting.co.za> STINNER Victor added the comment: > New changeset cfc956f13ce2 by Victor Stinner in branch 'default': > Issue #28618: Mark dict lookup functions as hot > https://hg.python.org/cpython/rev/cfc956f13ce2 Here are benchmark results on the speed-python server: haypo at speed-python$ PYTHONPATH=~/perf python -m perf compare_to 2016-11-15_09-12-default-ac93d188ebd6.json 2016-11-15_15-13-default-cfc956f13ce2.json -G --min-speed=1 Slower (6): - json_loads: 62.8 us +- 1.1 us -> 65.8 us +- 2.6 us: 1.05x slower - nbody: 243 ms +- 2 ms -> 253 ms +- 6 ms: 1.04x slower - mako: 42.7 ms +- 0.2 ms -> 43.5 ms +- 0.3 ms: 1.02x slower - chameleon: 29.2 ms +- 0.3 ms -> 29.7 ms +- 0.2 ms: 1.02x slower - spectral_norm: 261 ms +- 2 ms -> 266 ms +- 3 ms: 1.02x slower - pickle: 26.6 us +- 0.4 us -> 27.0 us +- 0.4 us: 1.01x slower Faster (26): - xml_etree_generate: 290 ms +- 4 ms -> 275 ms +- 3 ms: 1.06x faster - float: 306 ms +- 5 ms -> 292 ms +- 7 ms: 1.05x faster - logging_simple: 37.7 us +- 0.4 us -> 36.1 us +- 0.4 us: 1.04x faster - hexiom: 25.6 ms +- 0.1 ms -> 24.5 ms +- 0.1 ms: 1.04x faster - regex_effbot: 6.11 ms +- 0.31 ms -> 5.88 ms +- 0.43 ms: 1.04x faster - sympy_expand: 1.19 sec +- 0.02 sec -> 1.15 sec +- 0.01 sec: 1.04x faster - telco: 21.5 ms +- 0.4 ms -> 20.8 ms +- 0.4 ms: 1.03x faster - raytrace: 1.41 sec +- 0.02 sec -> 1.37 sec +- 0.02 sec: 1.03x faster - scimark_sor: 512 ms +- 11 ms -> 500 ms +- 12 ms: 1.03x faster - logging_format: 44.6 us +- 0.5 us -> 43.6 us +- 0.7 us: 1.02x faster - sympy_str: 532 ms +- 4 ms -> 520 ms +- 4 ms: 1.02x faster - fannkuch: 1.11 sec +- 0.01 sec -> 1.08 sec +- 0.02 sec: 1.02x faster - django_template: 475 ms +- 5 ms -> 467 ms +- 6 ms: 1.02x faster - chaos: 308 ms +- 2 ms -> 303 ms +- 3 ms: 1.02x faster - xml_etree_process: 244 ms +- 4 ms -> 240 ms +- 4 ms: 1.02x faster - xml_etree_iterparse: 225 ms +- 5 ms -> 221 ms +- 4 ms: 1.02x faster - pathlib: 51.1 ms +- 0.5 ms -> 50.3 ms +- 0.5 ms: 1.02x faster - sqlite_synth: 10.5 us +- 0.2 us -> 10.3 us +- 0.2 us: 1.01x faster - dulwich_log: 186 ms +- 1 ms -> 184 ms +- 1 ms: 1.01x faster - sqlalchemy_imperative: 72.5 ms +- 1.6 ms -> 71.5 ms +- 1.6 ms: 1.01x faster - deltablue: 18.5 ms +- 0.3 ms -> 18.3 ms +- 0.2 ms: 1.01x faster - tornado_http: 438 ms +- 5 ms -> 433 ms +- 5 ms: 1.01x faster - json_dumps: 30.4 ms +- 0.4 ms -> 30.1 ms +- 0.4 ms: 1.01x faster - genshi_xml: 212 ms +- 3 ms -> 210 ms +- 3 ms: 1.01x faster - scimark_monte_carlo: 273 ms +- 5 ms -> 271 ms +- 5 ms: 1.01x faster - call_simple: 13.3 ms +- 0.3 ms -> 13.2 ms +- 0.4 ms: 1.01x faster Benchmark hidden because not significant (32): 2to3, call_method, call_method_slots, call_method_unknown, crypto_pyaes, genshi_text, go, html5lib, logging_silent, meteor_contest, nqueens, pickle_dict, pickle_list, pickle_pure_python, pidigits, python_startup, python_startup_no_site, regex_compile, regex_dna, regex_v8, richards, scimark_fft, scimark_lu, scimark_sparse_mat_mult, sqlalchemy_declarative, sympy_integrate, sympy_sum, unpack_sequence, unpickle, unpickle_list, unpickle_pure_python, xml_etree_parse ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 10:50:33 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Nov 2016 15:50:33 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1479225033.82.0.822226817156.issue28618@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy Storchaka: >> * json: scanstring_unicode() > > This doesn't look wise. This is specific to single extension module and perhaps to single particular benchmark. Most Python code don't use json at all. Well, I tried different things to make these benchmarks more stable. I didn't say that we should merge hot3.patch as it is :-) It's just an attempt. > What is the top of "perf report"? For json_loads, it's: 14.99% _json.cpython-37m-x86_64-linux-gnu.so scanstring_unicode 8.34% python _PyUnicode_FromUCS1 8.32% _json.cpython-37m-x86_64-linux-gnu.so scan_once_unicode 8.01% python lookdict_unicode_nodummy 6.72% python siphash24 4.45% python PyDict_SetItem 4.26% python _PyObject_Malloc 3.38% python _PyEval_EvalFrameDefault 3.16% python _Py_HashBytes 2.72% python PyUnicode_New 2.36% python PyLong_FromString 2.25% python _PyObject_Free 2.02% libc-2.19.so __memcpy_sse2_unaligned 1.61% python PyDict_GetItem 1.40% python dictresize 1.24% python unicode_hash 1.11% libc-2.19.so _int_malloc 1.07% python unicode_dealloc 1.00% python free_keys_object Result produced with: $ perf record ./python ~/performance/performance/benchmarks/bm_json_loads.py --worker -v -l 128 -w0 -n 100 $ perf report > How this list intersects with the list of functions in .text.hot section of PGO build? I checked which functions are considered as "hot" by a PGO build: I found more than 2,000 functions... I'm not interested to tag so many functions with _Py_HOT_FUNCTIONS. I would prefer to only tag something like the top 10 or top 25 functions. I don't know the recommandations to tag functions as hot. I guess that what matters is the total size of hot functions. Should I be smaller than the L2 cache? Smaller than the L3 cache? I'm talking about instructions, but data share also these caches... > Make several PGO builds (perhaps on different computers). Is .text.hot section stable? In my experience PGO builds don't provide stable performances, but I was never able to write an article on that because of so many bugs :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 11:03:31 2016 From: report at bugs.python.org (Ulrich Petri) Date: Tue, 15 Nov 2016 16:03:31 +0000 Subject: [issue28697] asyncio.Lock, Condition, Semaphore docs don't mention `async with` syntax Message-ID: <1479225811.34.0.0222578393475.issue28697@psf.upfronthosting.co.za> New submission from Ulrich Petri: The docs for asyncio's Lock, Condition and Semaphore should use the new clean `async with lock:` syntax instead of the older (and IMO rather ugly) `with (yield from lock):` version. ---------- assignee: docs at python components: Documentation, asyncio messages: 280861 nosy: docs at python, gvanrossum, ulope, yselivanov priority: normal severity: normal status: open title: asyncio.Lock, Condition, Semaphore docs don't mention `async with` syntax versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 11:06:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Nov 2016 16:06:56 +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: <20161115160652.60595.95243.F60EBBA1@psf.io> Roundup Robot added the comment: New changeset a377e6987821 by Xavier de Gaye in branch '3.5': Issue 28668: Skip tests where instanciation of multiprocessing.Queue https://hg.python.org/cpython/rev/a377e6987821 New changeset e5404ba1b19e by Xavier de Gaye in branch '3.6': Issue 28668: Merge 3.5 https://hg.python.org/cpython/rev/e5404ba1b19e New changeset 1f0b0ecf7dc1 by Xavier de Gaye in branch 'default': Issue 28668: Merge 3.6 https://hg.python.org/cpython/rev/1f0b0ecf7dc1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 11:08:16 2016 From: report at bugs.python.org (Lev Veshnyakov) Date: Tue, 15 Nov 2016 16:08:16 +0000 Subject: [issue28696] imap from ThreadPool hangs by an exception in a generator function In-Reply-To: <1479214370.8.0.751710549169.issue28696@psf.upfronthosting.co.za> Message-ID: <1479226096.5.0.137998447231.issue28696@psf.upfronthosting.co.za> Lev Veshnyakov added the comment: I've reproduced it on 2 different machines: - on a MacBook in Docker (debian:jessie, python 3.4.2) - on another desktop (Ubuntu 14.04.1, 3.16.0-77-generic, x86_64, python 3.4.3) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 11:26:48 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Nov 2016 16:26:48 +0000 Subject: [issue26929] android: test_strptime fails In-Reply-To: <1462284711.76.0.324696843297.issue26929@psf.upfronthosting.co.za> Message-ID: <20161115162646.61850.3970.75DE85BE@psf.io> Roundup Robot added the comment: New changeset 3c6e5f83d235 by Xavier de Gaye in branch '3.6': Issue #26929: Skip some test_strptime tests failing on Android that https://hg.python.org/cpython/rev/3c6e5f83d235 New changeset 91e0cf7f8e30 by Xavier de Gaye in branch 'default': Issue #26929: Merge 3.6 https://hg.python.org/cpython/rev/91e0cf7f8e30 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 11:32:00 2016 From: report at bugs.python.org (Jun Wu) Date: Tue, 15 Nov 2016 16:32:00 +0000 Subject: [issue1633941] for line in sys.stdin: doesn't notice EOF the first time Message-ID: <1479227520.06.0.0527564888381.issue1633941@psf.upfronthosting.co.za> Jun Wu added the comment: haypo: The file.__iter__ EINTR issue may be better discussed as a separate bug report. It's not related to stdin or EOF or Windows. Since we have some EINTR fixes for Python 2.7.4, I think it's reasonable to fix the remaining EINTR issues for 2.7.13+. If I have read fileobject.c correctly, readahead() is the only remaining place having the EINTR issue. If you agree that we should fix readahead(), I can prepare the patch. ---------- nosy: +quark _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 11:32:51 2016 From: report at bugs.python.org (Lev Veshnyakov) Date: Tue, 15 Nov 2016 16:32:51 +0000 Subject: [issue28696] imap from ThreadPool hangs by an exception in a generator function In-Reply-To: <1479214370.8.0.751710549169.issue28696@psf.upfronthosting.co.za> Message-ID: <1479227571.84.0.620532176484.issue28696@psf.upfronthosting.co.za> Lev Veshnyakov added the comment: It's hanging in a while loop in _handle_workers, /usr/lib/python3.4/multiprocessingpool.py:365. I can't figure out what is the reason. @staticmethod def _handle_workers(pool): thread = threading.current_thread() # Keep maintaining workers until the cache gets drained, unless the pool # is terminated. while thread._state == RUN or (pool._cache and thread._state != TERMINATE): pool._maintain_pool() time.sleep(0.1) # send sentinel to stop workers pool._taskqueue.put(None) util.debug('worker handler exiting') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 11:37:48 2016 From: report at bugs.python.org (Davin Potts) Date: Tue, 15 Nov 2016 16:37:48 +0000 Subject: [issue28696] imap from ThreadPool hangs by an exception in a generator function In-Reply-To: <1479214370.8.0.751710549169.issue28696@psf.upfronthosting.co.za> Message-ID: <1479227868.07.0.297248989357.issue28696@psf.upfronthosting.co.za> Davin Potts added the comment: If it only occurs in 3.4.x, is moving to 3.5 an option for you? ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 12:19:39 2016 From: report at bugs.python.org (Lev Veshnyakov) Date: Tue, 15 Nov 2016 17:19:39 +0000 Subject: [issue28696] imap from ThreadPool hangs by an exception in a generator function In-Reply-To: <1479214370.8.0.751710549169.issue28696@psf.upfronthosting.co.za> Message-ID: <1479230379.71.0.624965816972.issue28696@psf.upfronthosting.co.za> Lev Veshnyakov added the comment: Yes, I'm free to move to 3.5, now I'm seeing isn't there any problems in 3.5 according to this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 12:23:56 2016 From: report at bugs.python.org (Alex Wang) Date: Tue, 15 Nov 2016 17:23:56 +0000 Subject: [issue28698] Python 3.x ctypes c_wchar_p return is different from official documentation example Message-ID: <1479230636.43.0.863548306007.issue28698@psf.upfronthosting.co.za> New submission from Alex Wang: - Python Version Python 3.5.2 - Issue I found that the c_wchar_p and c_char_p return results behaves different from what it is based on ctypes doc. From the ctypes doc of Python 3.5: >>> c_wchar_p("Hello, World") c_wchar_p('Hello, World') It return the ctypes string. But my results of execute the same cmd in Python3.5 console: >>> from ctypes import * >>> c_wchar_p("Hello, World") c_wchar_p(1374004842736) >>> c_wchar_p("Hello, World") c_wchar_p(1374004841680) >>> c_wchar_p("Hello, World") c_wchar_p(1374004842736) So seems like the orignial string part replaced by memory address. Digged in more, and found out if it is Python 2.x, then the return shows the string like the Python 3.5 ctypes doc shows. But in Python 3.x, it always return these numbers. Checked on multiple PCs, all seen the same thing. And understood the part that, we can use .value to return the original string. Same thing observed on create_string_buffer() and create_unicode_buffer(). Meanwhile, for other data types like c_int(), c_bool, c_void_p etc., not see this. - Question Can anyone provide a explaination about this behavior of ctypes? And is there any way to fix the Python3.x return resuls as the same as what is doc wrote? (It seems that when it behave like this, I had issue with passing Python string to C function, when I interact with a C DLL.) - Repro This can be reproduce in python.org/shell easily. Thanks a lot in advance~ ---------- components: ctypes messages: 280869 nosy: Alex Wang priority: normal severity: normal status: open title: Python 3.x ctypes c_wchar_p return is different from official documentation example type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 12:49:39 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Nov 2016 17:49:39 +0000 Subject: [issue28556] typing.py upgrades In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za> Message-ID: <20161115174936.5669.6349.130D01D8@psf.io> Roundup Robot added the comment: New changeset da2ac103d326 by Guido van Rossum in branch '3.5': Issue #28556: Allow keyword syntax for NamedTuple (Ivan Levkivskyi) (upstream #321) https://hg.python.org/cpython/rev/da2ac103d326 New changeset 38ec88a4e282 by Guido van Rossum in branch '3.6': Issue #28556: Allow keyword syntax for NamedTuple (Ivan Levkivskyi) (upstream #321) (3.5->3.6) https://hg.python.org/cpython/rev/38ec88a4e282 New changeset a3de2d0f49ea by Guido van Rossum in branch 'default': Issue #28556: Allow keyword syntax for NamedTuple (Ivan Levkivskyi) (upstream #321) (3.6->3.7) https://hg.python.org/cpython/rev/a3de2d0f49ea ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 13:08:30 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Nov 2016 18:08:30 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479233310.35.0.0996663305472.issue21449@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Callers should be fixed to handle errors. This would make the code of callers more complex for small benefit. And perhaps we will add more callers (if replace PyUnicode_CompareWithASCII with new function). > Since currently _PyUnicode_CompareWithId is used to compare a unicode with ascii identifiers for all cases, how about introduce a more specific function like _PyUnicode_EqualToASCIIId for this case? Great idea Xiang! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 13:22:19 2016 From: report at bugs.python.org (Lev Veshnyakov) Date: Tue, 15 Nov 2016 18:22:19 +0000 Subject: [issue28699] Imap from ThreadPool behaves unexpectedly Message-ID: <1479234139.82.0.483433491582.issue28699@psf.upfronthosting.co.za> New submission from Lev Veshnyakov: Consider the following code: from multiprocessing.pool import ThreadPool pool = ThreadPool(10) def gen(): yield 1 + '1' # here is an error print(list(pool.imap(str, gen()))) # prints [] print(list(pool.map(str, gen()))) # raises TypeError The difference is, that the line with imap prints an empty list, while the line with map raises an exception, as expected. Change the above snippet of code, adding additional yield statement: from multiprocessing.pool import ThreadPool pool = ThreadPool(10) def gen(): yield 1 yield 1 + '1' # here is an error print(list(pool.imap(str, gen()))) # raises TypeError print(list(pool.map(str, gen()))) # also would raise TypeError So now both map and imap will raise the exception, as expected. Therefore I suppose the behavior of imap showed in the first case is wrong. ---------- components: Library (Lib) messages: 280872 nosy: lev-veshnyakov priority: normal severity: normal status: open title: Imap from ThreadPool behaves unexpectedly type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 13:26:06 2016 From: report at bugs.python.org (Mathieu Sornay) Date: Tue, 15 Nov 2016 18:26:06 +0000 Subject: [issue27585] asyncio.Lock deadlock after cancellation In-Reply-To: <1469120801.4.0.62510822161.issue27585@psf.upfronthosting.co.za> Message-ID: <1479234366.28.0.416265310372.issue27585@psf.upfronthosting.co.za> Mathieu Sornay added the comment: I might have found another pathological case not fixed by https://github.com/python/asyncio/pull/393 Tested in 3.6.0b3 The deadlock.py file prints : DEADLOCK HERE _locked: False _waiters: deque([]) ---------- nosy: +msornay versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file45489/deadlock.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 13:29:44 2016 From: report at bugs.python.org (Lev Veshnyakov) Date: Tue, 15 Nov 2016 18:29:44 +0000 Subject: [issue28699] Imap from ThreadPool behaves unexpectedly In-Reply-To: <1479234139.82.0.483433491582.issue28699@psf.upfronthosting.co.za> Message-ID: <1479234584.05.0.648131938969.issue28699@psf.upfronthosting.co.za> Changes by Lev Veshnyakov : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 13:51:55 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 15 Nov 2016 18:51:55 +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: <1479235915.87.0.349044682797.issue28668@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 13:52:41 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 15 Nov 2016 18:52:41 +0000 Subject: [issue26929] android: test_strptime fails In-Reply-To: <1462284711.76.0.324696843297.issue26929@psf.upfronthosting.co.za> Message-ID: <1479235960.99.0.723804688362.issue26929@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 13:53:08 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 15 Nov 2016 18:53:08 +0000 Subject: [issue27585] asyncio.Lock deadlock after cancellation In-Reply-To: <1479234366.28.0.416265310372.issue27585@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Looks like create_waiter() entered the with-statement but didn't leave it properly due to the cancellation, right? @1st1 any idea? async with bug or asyncio bug? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 13:53:12 2016 From: report at bugs.python.org (Eryk Sun) Date: Tue, 15 Nov 2016 18:53:12 +0000 Subject: [issue28698] Python 3.x ctypes c_wchar_p return is different from official documentation example In-Reply-To: <1479230636.43.0.863548306007.issue28698@psf.upfronthosting.co.za> Message-ID: <1479235992.16.0.561556781345.issue28698@psf.upfronthosting.co.za> Eryk Sun added the comment: The repr can't automatically dereference the string at the address because it may be an invalid pointer. ctypes was developed on Windows, for which, in Python 2, it (ab)uses the obsolete IsBadStringPtr[A|W] function [1]. This function should never be used in a multithreaded process. On POSIX systems, the repr of c_char_p was special-cased to avoid dereferencing the pointer, but c_wchar_p was overlooked, and you can still easily crash Python 2 like this: Python 2.7.12 (default, Jul 1 2016, 15:12:24) [GCC 5.4.0 20160609] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> ctypes.c_wchar_p(1) Segmentation fault (core dumped A while back the bogus use of WinAPI IsBadStringPtr was removed from the Python 3 branch, but apparently the docs weren't updated to reflect this change. I'm changing this to a documentation issue. [1]: https://msdn.microsoft.com/en-us/library/aa366714 ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, eryksun versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 13:57:57 2016 From: report at bugs.python.org (Eryk Sun) Date: Tue, 15 Nov 2016 18:57:57 +0000 Subject: [issue28698] Python 3.x ctypes c_wchar_p return is different from official documentation example In-Reply-To: <1479230636.43.0.863548306007.issue28698@psf.upfronthosting.co.za> Message-ID: <1479236277.15.0.616661653669.issue28698@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- keywords: +easy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 14:24:19 2016 From: report at bugs.python.org (Alex Wang) Date: Tue, 15 Nov 2016 19:24:19 +0000 Subject: [issue28698] Python 3.x ctypes c_wchar_p return is different from official documentation example In-Reply-To: <1479236277.21.0.0574855895966.issue28698@psf.upfronthosting.co.za> Message-ID: Alex Wang added the comment: Hi Eryk, Thanks a lot for quick reply~ This is about the bug I filed: http://bugs.python.org/issue28698# I may still need your help to have a look the original case when I caught this issue: ?I am writing some test automation which call C DLL from Python, the C function is something like: MEASURE_API int InitTester(char *ipAddress) ?So I need to pass an IP address string (for example, 192.168.100.100) from Python in ctypes to this function. For non-const char in C, I used c_ipAddress = create_string_buffer(b'192.168.100.100') lib.InitTester(c_ipAddress) ?But error code returned indicate that the parameter passing is incorrect, then I traced back and found then reported the c_char_p/c_wchar_p issue.? Also tried ?c_ipAddress = create_unicode_buffer('192.168.100.100') c_ipAddress = c_char_p(b'192.168.100.100') c_ipAddress = c_wchar_p('192.168.100.100')? ?But none of them working... I had called other function to this C DLL passing c_int(). c_bool(), c_void_p() and etc. they are all working as expected, only string related have this issue. Therefore, any idea how write the correct assignment and pass it to ?C DLL for this case in Python 3.5? Any hint would be great helpful. Thank you in advance~ BR, Alex On Tue, Nov 15, 2016 at 10:57 AM, Eryk Sun wrote: > > Changes by Eryk Sun : > > > ---------- > keywords: +easy > stage: -> needs patch > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 14:27:18 2016 From: report at bugs.python.org (Greg Ward) Date: Tue, 15 Nov 2016 19:27:18 +0000 Subject: [issue28700] test_dbm failure: KeyError: b'0' (regression in 3.6) Message-ID: <1479238038.8.0.290390662143.issue28700@psf.upfronthosting.co.za> New submission from Greg Ward: test_dbm.py fails reliably for me in 3.6, but in 3.5 it passes ~80% of the time. The failure in both cases is KeyError: b'0', which has come up previously in http://bugs.python.org/issue20094 and http://bugs.python.org/issue14120. But since we've switched from 20% failure rate to 100% failure rate, I figured something must have changed. I used "hg bisect" to track it down to a recent commit: changeset: 103360:0bd618fe0639 user: Victor Stinner date: Wed Sep 07 17:40:12 2016 -0700 summary: Implement compact dict Here is how it fails: $ ./python -m test -v test_dbm == CPython 3.6.0a4+ (default:0bd618fe0639, Nov 15 2016, 14:07:07) [GCC 5.4.0 20160609] == Linux-4.4.0-47-generic-x86_64-with-debian-stretch-sid little-endian == hash algorithm: siphash24 64bit == /home/data/src/cpython/3.6/build/test_python_10093 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) Run tests sequentially 0:00:00 [1/1] test_dbm test_keys (test.test_dbm.WhichDBTestCase) ... ok test_whichdb (test.test_dbm.WhichDBTestCase) ... ok test_whichdb_ndbm (test.test_dbm.WhichDBTestCase) ... BDB0004 fop_read_meta: @test_10093_tmp_ndbm.db: unexpected file type or format ok test_anydbm_access (test.test_dbm.TestCase-dbm.ndbm) ... ok test_anydbm_creation (test.test_dbm.TestCase-dbm.ndbm) ... ERROR BDB3028 @test_10093_tmp.db: unable to flush: No such file or directory test_anydbm_creation_n_file_exists_with_invalid_contents (test.test_dbm.TestCase-dbm.ndbm) ... ok test_anydbm_keys (test.test_dbm.TestCase-dbm.ndbm) ... ok test_anydbm_modification (test.test_dbm.TestCase-dbm.ndbm) ... ERROR BDB3028 @test_10093_tmp.db: unable to flush: No such file or directory test_anydbm_not_existing (test.test_dbm.TestCase-dbm.ndbm) ... ok test_anydbm_read (test.test_dbm.TestCase-dbm.ndbm) ... ERROR test_error (test.test_dbm.TestCase-dbm.ndbm) ... ok test_anydbm_access (test.test_dbm.TestCase-dbm.dumb) ... ok test_anydbm_creation (test.test_dbm.TestCase-dbm.dumb) ... ok test_anydbm_creation_n_file_exists_with_invalid_contents (test.test_dbm.TestCase-dbm.dumb) ... ok test_anydbm_keys (test.test_dbm.TestCase-dbm.dumb) ... ok test_anydbm_modification (test.test_dbm.TestCase-dbm.dumb) ... ok test_anydbm_not_existing (test.test_dbm.TestCase-dbm.dumb) ... ok test_anydbm_read (test.test_dbm.TestCase-dbm.dumb) ... ok test_error (test.test_dbm.TestCase-dbm.dumb) ... ok ====================================================================== ERROR: test_anydbm_creation (test.test_dbm.TestCase-dbm.ndbm) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/data/src/cpython/3.6/Lib/test/test_dbm.py", line 73, in test_anydbm_creation self.read_helper(f) File "/home/data/src/cpython/3.6/Lib/test/test_dbm.py", line 114, in read_helper self.assertEqual(self._dict[key], f[key.encode("ascii")]) KeyError: b'0' ====================================================================== ERROR: test_anydbm_modification (test.test_dbm.TestCase-dbm.ndbm) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/data/src/cpython/3.6/Lib/test/test_dbm.py", line 88, in test_anydbm_modification self.read_helper(f) File "/home/data/src/cpython/3.6/Lib/test/test_dbm.py", line 114, in read_helper self.assertEqual(self._dict[key], f[key.encode("ascii")]) KeyError: b'0' ====================================================================== ERROR: test_anydbm_read (test.test_dbm.TestCase-dbm.ndbm) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/data/src/cpython/3.6/Lib/test/test_dbm.py", line 94, in test_anydbm_read self.read_helper(f) File "/home/data/src/cpython/3.6/Lib/test/test_dbm.py", line 114, in read_helper self.assertEqual(self._dict[key], f[key.encode("ascii")]) KeyError: b'0' ---------------------------------------------------------------------- Ran 19 tests in 0.052s FAILED (errors=3) test test_dbm failed test_dbm failed 1 test failed: test_dbm Total duration: 77 ms Tests result: FAILURE ---------- components: Tests messages: 280877 nosy: gward priority: normal severity: normal status: open title: test_dbm failure: KeyError: b'0' (regression in 3.6) type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 14:40:47 2016 From: report at bugs.python.org (Eryk Sun) Date: Tue, 15 Nov 2016 19:40:47 +0000 Subject: [issue28698] Python 3.x ctypes c_wchar_p return is different from official documentation example In-Reply-To: <1479230636.43.0.863548306007.issue28698@psf.upfronthosting.co.za> Message-ID: <1479238847.72.0.604964927179.issue28698@psf.upfronthosting.co.za> Eryk Sun added the comment: The issue tracker isn't a forum to answer general programming questions. Please ask this on python-list, and I'll try to help you there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 14:42:14 2016 From: report at bugs.python.org (Greg Ward) Date: Tue, 15 Nov 2016 19:42:14 +0000 Subject: [issue28700] test_dbm failure: KeyError: b'0' (regression in 3.6) In-Reply-To: <1479238038.8.0.290390662143.issue28700@psf.upfronthosting.co.za> Message-ID: <1479238934.9.0.768634892453.issue28700@psf.upfronthosting.co.za> Greg Ward added the comment: Forgot to mention: I'm running: No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.1 LTS Release: 16.04 Codename: xenial with $ dpkg-query -W | grep dbm libgdbm3:amd64 1.8.3-13.1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 14:44:43 2016 From: report at bugs.python.org (Greg Ward) Date: Tue, 15 Nov 2016 19:44:43 +0000 Subject: [issue28700] test_dbm failure: KeyError: b'0' (regression in 3.6) In-Reply-To: <1479238038.8.0.290390662143.issue28700@psf.upfronthosting.co.za> Message-ID: <1479239083.03.0.0339336476424.issue28700@psf.upfronthosting.co.za> Greg Ward added the comment: As suggested in http://bugs.python.org/issue14120, I installed libgdbm-dev, re-configured, and re-compiled. That fixes the problem. IMHO that's not good enough: if we're missing a dependency, then either configuring or building should fail. It's nice that the test failure is now rock-solid reliable rather than intermittent, but it's still a test failure due to missing dependency. Yuck. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 14:45:12 2016 From: report at bugs.python.org (Greg Ward) Date: Tue, 15 Nov 2016 19:45:12 +0000 Subject: [issue28700] test_dbm failure: KeyError: b'0' (intermittent in 3.5, reliable in 3.6) In-Reply-To: <1479238038.8.0.290390662143.issue28700@psf.upfronthosting.co.za> Message-ID: <1479239112.4.0.409215844104.issue28700@psf.upfronthosting.co.za> Changes by Greg Ward : ---------- title: test_dbm failure: KeyError: b'0' (regression in 3.6) -> test_dbm failure: KeyError: b'0' (intermittent in 3.5, reliable in 3.6) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 14:47:20 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 15 Nov 2016 19:47:20 +0000 Subject: [issue28670] PEP 235: Implement on every POSIX system, and clean up the C code for `import' In-Reply-To: <1478899111.69.0.0154952768919.issue28670@psf.upfronthosting.co.za> Message-ID: <1479239240.64.0.903037321965.issue28670@psf.upfronthosting.co.za> Brett Cannon added the comment: So there's no "promised behavior" that's missing in Python 2.7. If you read PEP 235 it's very clear what platforms it was meant for: cygwin, macOS, and Windows. There's no promise of supporting PYTHONCASEOK for POSIX in general so it isn't as if the PEP is not fully implemented. And even if it was promised, this is a potential breaking change as the semantics of Python 2.7 would shift in a rather key way on certain platforms based on the external factor of PYTHONCASEOK simply being set which someone may have carelessly done. In other words while you view this as a fix for breakage on a platform, I view it as adding support for a certain platform configuration on POSIX which is a new feature. Since you said this doesn't affect Python 3, I'm closing this as rejected. I appreciate the attempt at a patch, but this is considered a new feature for Python 2.7 which is not open to new features. In case you choose to submit other patches in the future I'll address your other comments you left about how to test and our development workflow. To test this what you would basically need to do is detect when the test suite was run on a platform that was case-preserving but case-insensitive and then on such a platform make sure imports worked as expected with and without PYTHONCASEOK set (see the tests that already do this on macOS and Windows). As for your patchset, I understand your intention, but Python's workflow simply doesn't work the way you want it to. The commit messages that go into version control are set by core developers on purpose to make sure they are formatted as expected and contain the appropriate information. For instance, while your commit messages are very detailed, we tend to askew long commit messages and go for succinct messages that explain the "why" something was done (a paragraph of explanation is itself rare). Your commit messages were also not formatted correctly, e.g. we always list the relevant issue that motivated a change first like "Issue #28670: ...". And lastly, we want commits to represent a single unit of semantic change when possible, so if your work made sense to break up into multiple patches then we would need to open multiple issues for each semantic change to be discussed in isolation and on their own merits. It also makes tracking what semantic changes broke something easier when running a bisection on commits to find the change that broke something (and thus easier to also back out instead of searching for every related commit because it spanned more than one). ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 14:50:06 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Nov 2016 19:50:06 +0000 Subject: [issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString Message-ID: <1479239405.55.0.31899621759.issue28701@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch replaces calls of public function PyUnicode_CompareWithASCIIString() with new private function _PyUnicode_EqualToASCIIString(). The problem with PyUnicode_CompareWithASCIIString() is that it returns -1 for the result "less than" and error, but the error case is never checked. The patch is purposed for following purposes: 1. Readability. ``_PyUnicode_EqualToASCIIString(...)`` looks more readable than ``PyUnicode_CompareWithASCIIString(...) == 0`` or ``!PyUnicode_CompareWithASCIIString(...)``, especially in large expression. I always have to make an effort to understand correctly the meaning of the latter expression. 2. Efficiency. If the strings are not equal, _PyUnicode_EqualToASCIIString() can quickly return false, but PyUnicode_CompareWithASCIIString() needs to check whether what string is larger. 3. Correctness. Since no caller checks the error of PyUnicode_CompareWithASCIIString(), it is incorrectly interpreted as "less then". Exception set by PyUnicode_CompareWithASCIIString() can be leaked in following code causing mystical error or crash in debug build. There are too many callers to add error checking for them all. These would be non-trivial error-prone changes that add new lines of the code, new variables and new returns or gotos. On other hand replacing PyUnicode_CompareWithASCIIString() with _PyUnicode_EqualToASCIIString() is done by simple script. _PyUnicode_EqualToASCIIString() returns true value (1) if strings are equal, false value (0) if they are different, and doesn't raise exceptions. Unlike to PyUnicode_CompareWithASCIIString() it works only with ASCII characters and returns false if any string contains non-ASCII characters. The patch also documents the return value of PyUnicode_CompareWithASCIIString() in case of error. See issue21449 for similar issue with _PyUnicode_CompareWithId(). ---------- components: Interpreter Core, Unicode files: _PyUnicode_EqualToASCIIString.patch keywords: patch messages: 280882 nosy: ezio.melotti, haypo, josh.r, serhiy.storchaka, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45490/_PyUnicode_EqualToASCIIString.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 14:51:39 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Nov 2016 19:51:39 +0000 Subject: [issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString In-Reply-To: <1479239405.55.0.31899621759.issue28701@psf.upfronthosting.co.za> Message-ID: <1479239499.5.0.757122071444.issue28701@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file45491/PyUnicode_CompareWithASCIIString.cocci _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 14:53:32 2016 From: report at bugs.python.org (Eryk Sun) Date: Tue, 15 Nov 2016 19:53:32 +0000 Subject: [issue28698] Python 3.x ctypes c_wchar_p return is different from official documentation example In-Reply-To: <1479230636.43.0.863548306007.issue28698@psf.upfronthosting.co.za> Message-ID: <1479239612.17.0.34469328896.issue28698@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- Removed message: http://bugs.python.org/msg280878 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 14:53:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Nov 2016 19:53:34 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479239614.71.0.589671334644.issue21449@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: _PyUnicode_EqualToASCIIString() added in issue28701 would help in the patch for this issue. ---------- dependencies: +Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 15:04:43 2016 From: report at bugs.python.org (Greg Ward) Date: Tue, 15 Nov 2016 20:04:43 +0000 Subject: [issue28702] Confusing error message when None used in expressions, eg. "'NoneType' object has no attribute 'foo'" Message-ID: <1479240283.12.0.750407106609.issue28702@psf.upfronthosting.co.za> New submission from Greg Ward: Python's error message when you let None accidentally sneak into an expression where it doesn't belong could be better. The canonical example is attribute lookup: >>> a = None >>> a.foo Traceback (most recent call last): File "", line 1, in AttributeError: 'NoneType' object has no attribute 'foo' This assumes that the programmer knows there is only one object of type NoneType, and it is None. That's a lot to assume of a beginner, whether they are coming from another programming language ("null has a type? that's crazy talk!") or are completely new to programming ("null? none? nil? wat...??"). There are plenty of other places this use of NoneType in error messages comes up: >>> a + 1 Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for +: 'NoneType' and 'int' >>> 1 + a Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for +: 'int' and 'NoneType' >>> len(a) Traceback (most recent call last): File "", line 1, in TypeError: object of type 'NoneType' has no len() >>> a < 1 Traceback (most recent call last): File "", line 1, in TypeError: '<' not supported between instances of 'NoneType' and 'int' I think we can do better than this. For example, here is an proposed improvement to user experience for getting and setting attributes on None: >>> a.foo Traceback (most recent call last): File "", line 1, in AttributeError: attempt to access attribute 'foo' of None, but None has no attributes >>> a.foo = 42 Traceback (most recent call last): File "", line 1, in AttributeError: attempt to set attribute 'foo' on None, but None is read-only Let the bikeshedding commence. I have a working patch, but need to write tests. Will upload it here when that is done. ---------- assignee: gward components: Interpreter Core messages: 280884 nosy: gward priority: normal severity: normal status: open title: Confusing error message when None used in expressions, eg. "'NoneType' object has no attribute 'foo'" type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 15:05:22 2016 From: report at bugs.python.org (Greg Ward) Date: Tue, 15 Nov 2016 20:05:22 +0000 Subject: [issue28702] Confusing error message when None used in expressions, eg. "'NoneType' object has no attribute 'foo'" In-Reply-To: <1479240283.12.0.750407106609.issue28702@psf.upfronthosting.co.za> Message-ID: <1479240322.04.0.54936191278.issue28702@psf.upfronthosting.co.za> Greg Ward added the comment: Based on a brief conversation with Brett Cannon at PyCon Canada the other day. Thanks for the idea, Brett! ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 15:18:49 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 15 Nov 2016 20:18:49 +0000 Subject: [issue28703] Fix asyncio.iscoroutinefunction to handle Mock objects Message-ID: <1479241129.21.0.885185313052.issue28703@psf.upfronthosting.co.za> New submission from Yury Selivanov: Proxy for https://github.com/python/asyncio/pull/459 ---------- assignee: yselivanov components: asyncio messages: 280886 nosy: gvanrossum, yselivanov priority: normal severity: normal stage: resolved status: open title: Fix asyncio.iscoroutinefunction to handle Mock objects type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 15:18:54 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 15 Nov 2016 20:18:54 +0000 Subject: [issue28703] Fix asyncio.iscoroutinefunction to handle Mock objects In-Reply-To: <1479241129.21.0.885185313052.issue28703@psf.upfronthosting.co.za> Message-ID: <1479241134.7.0.109991096832.issue28703@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 15:21:42 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Nov 2016 20:21:42 +0000 Subject: [issue28703] Fix asyncio.iscoroutinefunction to handle Mock objects In-Reply-To: <1479241129.21.0.885185313052.issue28703@psf.upfronthosting.co.za> Message-ID: <20161115202139.59839.32562.B376A130@psf.io> Roundup Robot added the comment: New changeset 179e556a50ce by Yury Selivanov in branch '3.5': Issue #28703: Fix asyncio.iscoroutinefunction to handle Mock objects. https://hg.python.org/cpython/rev/179e556a50ce New changeset 4d78290b1d8e by Yury Selivanov in branch '3.6': Merge 3.5 (issue #28703) https://hg.python.org/cpython/rev/4d78290b1d8e New changeset 298c53e2461f by Yury Selivanov in branch 'default': Merge 3.6 (issue #28703) https://hg.python.org/cpython/rev/298c53e2461f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 15:24:42 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 15 Nov 2016 20:24:42 +0000 Subject: [issue28700] test_dbm failure: KeyError: b'0' (intermittent in 3.5, reliable in 3.6) In-Reply-To: <1479238038.8.0.290390662143.issue28700@psf.upfronthosting.co.za> Message-ID: <1479241482.84.0.264108382858.issue28700@psf.upfronthosting.co.za> Martin Panter added the comment: Is the problem something like a missing C function prototype? Maybe you see compiler warnings, but the compiler and linker carry on with the wrong prototype. If you build with ?make -s?, warnings might be easier to see. If my guess is right, this would be similar to Issue 27659, where a module half builds with warnings about a missing crypt() function prototype, although it later fails when linking. Maybe more configure or setup.py checks? (I?m not a fan of configure, but it often seems the easiest short-term solution.) ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 15:25:21 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 15 Nov 2016 20:25:21 +0000 Subject: [issue28704] Fix create_unix_server to support Path-like objects (PEP 519) Message-ID: <1479241521.58.0.821851179075.issue28704@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- assignee: yselivanov components: asyncio nosy: gvanrossum, yselivanov priority: normal severity: normal stage: resolved status: open title: Fix create_unix_server to support Path-like objects (PEP 519) type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 15:25:32 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 15 Nov 2016 20:25:32 +0000 Subject: [issue28704] Fix create_unix_server to support Path-like objects (PEP 519) Message-ID: <1479241532.61.0.176787784157.issue28704@psf.upfronthosting.co.za> New submission from Yury Selivanov: Proxy for https://github.com/python/asyncio/pull/462 ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 15:27:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Nov 2016 20:27:56 +0000 Subject: [issue28704] Fix create_unix_server to support Path-like objects (PEP 519) In-Reply-To: <1479241532.61.0.176787784157.issue28704@psf.upfronthosting.co.za> Message-ID: <20161115202753.59751.1271.B758E2A0@psf.io> Roundup Robot added the comment: New changeset f8207c98eb5e by Yury Selivanov in branch '3.5': Issue #28704: Fix create_unix_server to support Path-like objects https://hg.python.org/cpython/rev/f8207c98eb5e New changeset 0d663f758adb by Yury Selivanov in branch '3.6': Merge 3.5 (issue #28704) https://hg.python.org/cpython/rev/0d663f758adb New changeset c7d2ec49a80b by Yury Selivanov in branch 'default': Merge 3.6 (issue #28704) https://hg.python.org/cpython/rev/c7d2ec49a80b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 15:40:24 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 15 Nov 2016 20:40:24 +0000 Subject: [issue28705] Clean up design FAQ question about compiling to C Message-ID: <1479242424.69.0.486701583989.issue28705@psf.upfronthosting.co.za> New submission from Brett Cannon: E.g. drop reference to Pyrex and Weave (especially since the latter has a stale link to https://scipy.github.io/devdocs/tutorial/weave.html and is Python 2.7-only and not recommended for new code). ---------- assignee: brett.cannon components: Documentation messages: 280891 nosy: brett.cannon priority: normal severity: normal status: open title: Clean up design FAQ question about compiling to C _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 15:43:19 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Nov 2016 20:43:19 +0000 Subject: [issue28702] Confusing error message when None used in expressions, eg. "'NoneType' object has no attribute 'foo'" In-Reply-To: <1479240283.12.0.750407106609.issue28702@psf.upfronthosting.co.za> Message-ID: <1479242599.55.0.879056619014.issue28702@psf.upfronthosting.co.za> R. David Murray added the comment: That presumably means adding special None support to all the places None can appear in a message, where now the code treats None like it does every other object. I'm not sure the added complexity is worth it, especially since NoneType would still creep in anywhere we'd forgotten to "fix". I'm not voting -1, but I'm dubious. Maybe we should just make NoneType's name be 'None' :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 15:58:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Nov 2016 20:58:52 +0000 Subject: [issue28702] Confusing error message when None used in expressions, eg. "'NoneType' object has no attribute 'foo'" In-Reply-To: <1479240283.12.0.750407106609.issue28702@psf.upfronthosting.co.za> Message-ID: <1479243532.77.0.390990562418.issue28702@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Approximate counts. C code: ob_type->tp_name 161 Py_TYPE(...)->tp_name 285 Python code: __class__.__name__ 224 __class__.__qualname__ 23 type(...).__name__ 112 type(...).__qualname__ 5 Is it worth changing about 800 places in CPython code? Not counting third-party code. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 16:08:30 2016 From: report at bugs.python.org (=?utf-8?b?SmnFmcOtIEhvZm1hbg==?=) Date: Tue, 15 Nov 2016 21:08:30 +0000 Subject: [issue28706] msvc9compiler does not find a vcvarsall.bat of Visual C++ for Python 9.0 Message-ID: <1479244110.83.0.177633464347.issue28706@psf.upfronthosting.co.za> New submission from Ji?? Hofman: When running "c:\Program Files\Python27\Scripts\pip2.7.exe" install wx following error occurs: Complete output from command "c:\program files\python27\python.exe" -u -c "import setuptools, tokenize;__file__='c:\\users\\jiri\\appdata\\local\\temp\\pip-build-lqokio\\wx\\setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record c:\users\jiri\appdata\local\temp\pip-51m45m-record\install-record.txt --single-version-externally-managed --compile: running install running build WARNING: Building this way assumes that all generated files have been generated already. If that is not the case then use build.py directly to generate the source and perform the build stage. You can use --skip-build with the bdist_* or install commands to avoid this message and the wxWidgets and Phoenix build steps in the future. "c:\program files\python27\python.exe" -u build.py build Will build using: "c:\program files\python27\python.exe" 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:24:40) [MSC v.1500 64 bit (AMD64)] Python's architecture is 64bit cfg.VERSION: 3.0.3 Running command: build Running command: build_wx Command '"c:\program files\python27\python.exe" -c "import distutils.msvc9compiler as msvc; mc = msvc.MSVCCompiler(); mc.initialize(); print(mc.cc)"' failed with exit code 1. Traceback (most recent call last): File "", line 1, in File "c:\program files\python27\lib\distutils\msvc9compiler.py", line 385, in initialize vc_env = query_vcvarsall(VERSION, plat_spec) File "c:\program files\python27\lib\distutils\msvc9compiler.py", line 273, in query_vcvarsall raise DistutilsPlatformError("Unable to find vcvarsall.bat") distutils.errors.DistutilsPlatformError: Unable to find vcvarsall.bat Finished command: build_wx (0.138s) Finished command: build (0.139s) Command '"c:\program files\python27\python.exe" -u build.py build' failed with exit code 1. I found out that the problem is in msvc9compiler. The dir where vcvarsall.bat is installed is not found. It is installed (by default) in C:\Users\Jiri\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0 Needed registry keys do not exist after installation of the Visual C++ for Python 9.0. My OS is Windows 10 Home (64bit). ---------- components: Distutils messages: 280894 nosy: dstufft, eric.araujo, jyrkih priority: normal severity: normal status: open title: msvc9compiler does not find a vcvarsall.bat of Visual C++ for Python 9.0 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 16:58:58 2016 From: report at bugs.python.org (Michael Witten) Date: Tue, 15 Nov 2016 21:58:58 +0000 Subject: [issue28670] PEP 235: Implement on every POSIX system, and clean up the C code for `import' In-Reply-To: <1478899111.69.0.0154952768919.issue28670@psf.upfronthosting.co.za> Message-ID: <1479247138.69.0.446683007488.issue28670@psf.upfronthosting.co.za> Michael Witten added the comment: Guess what? Linux can access HFS+ and NTFS volumes. Firstly, how does that fit into your ideas for testing? It doesn't; however, you'll note that my own brief analysis did attempt to wrestle with this nuance. Secondly, it was (and is) clearly asinine to conflate an operating system with a particular file system; PEP 235 betrays the naive ways of ancient thinkers---the spirit of the text of PEP 235 has never been completely implemented, and the result of this naivete is a broken userspace *today*. Here are the cases for my patch: * Non-POSIX platforms: Nothing changes. * POSIX platforms: * PYTHONCASEOK set: Nothing changes. * PYTHONCASEOK not set: Almost nothing changes. ----------------------- Accessing an insane file system now works just like on a Non-POSIX platform. In most cases, this won't change anything; yet, rare cases will *now* Just Work, rather than crapping out with some inscrutable error. Where is your qualm? As for the organization of patches, what I have presented (and especially what I describe for a merge commit) not only meets your stated goals, but *exceeds* them in every way. Nevertheless, I would be willing to dumb down my submission if it meant getting this bug fixed. ---------- It's rude to close abruptly an issue without even the implicit consent of your collocutor, especially when the reasoning for such an action is, once again, based explicitly on a startling degree of willful ignorance and maybe even technical incompetence. ---------- resolution: rejected -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 17:07:44 2016 From: report at bugs.python.org (Michael Hu) Date: Tue, 15 Nov 2016 22:07:44 +0000 Subject: [issue28673] When using pyro4 with more than 15 threads, python 2.7.12 cores frequently In-Reply-To: <1478939498.33.0.0967391900201.issue28673@psf.upfronthosting.co.za> Message-ID: <1479247664.24.0.0591020224814.issue28673@psf.upfronthosting.co.za> Michael Hu added the comment: Core is uploaded for python 2.7.10 to assist debugging. ---------- Added file: http://bugs.python.org/file45492/core_python2.7.10.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 17:11:00 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Nov 2016 22:11:00 +0000 Subject: [issue28673] When using pyro4 with more than 15 threads, python 2.7.12 cores frequently In-Reply-To: <1478939498.33.0.0967391900201.issue28673@psf.upfronthosting.co.za> Message-ID: <1479247860.39.0.607542119544.issue28673@psf.upfronthosting.co.za> STINNER Victor added the comment: Try to get the Python traceback of thread on the crash: try the faulthandler module. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 17:31:49 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 15 Nov 2016 22:31:49 +0000 Subject: [issue28707] add 'directory' option to the http.server module Message-ID: <1479249109.08.0.530385659795.issue28707@psf.upfronthosting.co.za> New submission from St?phane Wirtel: When we execute the http.server module, the tool will use the current directory (os.getcwd()) but sometimes we would like to specify a directory on the command line. With the next patch, I try to fix this missing feature ;-) Just with python -m http.server -d /tmp by default the system will use the current directory. if necessary, I will show an error if the directory does not exist. ---------- files: chdir-httpserver.diff keywords: patch messages: 280898 nosy: matrixise priority: normal severity: normal status: open title: add 'directory' option to the http.server module versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45493/chdir-httpserver.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 17:32:06 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 15 Nov 2016 22:32:06 +0000 Subject: [issue28707] add 'directory' option to the http.server module In-Reply-To: <1479249109.08.0.530385659795.issue28707@psf.upfronthosting.co.za> Message-ID: <1479249126.77.0.087148393247.issue28707@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 17:34:15 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Nov 2016 22:34:15 +0000 Subject: [issue28707] add 'directory' option to the http.server module In-Reply-To: <1479249109.08.0.530385659795.issue28707@psf.upfronthosting.co.za> Message-ID: <1479249255.14.0.332839060154.issue28707@psf.upfronthosting.co.za> STINNER Victor added the comment: The new feature should be documented in Doc/library/http.server.rst, and maybe also Doc/whatsnew/3.7.rst. Is it possible to write an unit test? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 17:52:38 2016 From: report at bugs.python.org (David Hirschfeld) Date: Tue, 15 Nov 2016 22:52:38 +0000 Subject: [issue28708] Low FD_SETSIZE limit on Windows Message-ID: <1479250358.07.0.768722440644.issue28708@psf.upfronthosting.co.za> New submission from David Hirschfeld: Back in 1999 the compile-time constant FD_SETSIZE was raised from (the default on Windows) 64 to 512 open sockets to support *serious async servers* http://bugs.python.org/issue210843 https://github.com/python/cpython/blame/master/Modules/selectmodule.c#L29-L36 The world has moved on and serious async servers require far more than 512 sockets available. This is one of the key reasons why tornado explicitly states: > Tornado will also run on Windows, although this configuration is not officially supported and is recommended only for development use. Yes, using select on Windows is the wrong thing to do, but it's far preferable to be able to use a library which makes use of select, putting up with the poor performance than it is to be told to use linux which often isn't an option. Since there's no alternative other than recompiling Python it would be good if this constant could be increased to a more useful (these days) value of say 16384. As a data point ZMQ have recently increased the value of this constant to 16k themselves https://github.com/zeromq/libzmq/pull/2035 ---------- messages: 280900 nosy: David Hirschfeld priority: normal severity: normal status: open title: Low FD_SETSIZE limit on Windows type: resource usage versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 17:55:41 2016 From: report at bugs.python.org (Zachary Ware) Date: Tue, 15 Nov 2016 22:55:41 +0000 Subject: [issue28708] Low FD_SETSIZE limit on Windows In-Reply-To: <1479250358.07.0.768722440644.issue28708@psf.upfronthosting.co.za> Message-ID: <1479250541.27.0.142052351618.issue28708@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- components: +Build, Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 17:57:12 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Nov 2016 22:57:12 +0000 Subject: [issue28708] Low FD_SETSIZE limit on Windows In-Reply-To: <1479250358.07.0.768722440644.issue28708@psf.upfronthosting.co.za> Message-ID: <1479250632.72.0.78719333022.issue28708@psf.upfronthosting.co.za> STINNER Victor added the comment: To implement an efficient event loop, IOCP is the way to do: the asyncio module supports it using ProactorEventLoop. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 18:42:24 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 15 Nov 2016 23:42:24 +0000 Subject: [issue28708] Low FD_SETSIZE limit on Windows In-Reply-To: <1479250358.07.0.768722440644.issue28708@psf.upfronthosting.co.za> Message-ID: <1479253344.8.0.622636321975.issue28708@psf.upfronthosting.co.za> Steve Dower added the comment: It looks like Modules/selectmodule.c already has the handling for when this gets large (and we really want to stop allocating the static array on the stack), which is a plus, but I'd want to see the performance cost to small selects if suddenly we're allocating 100s of KB on the heap rather than small and cheap stack allocations. For the amount of work going on here for each select() call, Victor is right - you're going to get severely diminishing returns as this increases in size. However, I see no reason why this couldn't be totally dynamic, at least on Windows. Redefining that value just changes a static array definition, but the array size never gets passed in to the OS AFAICT, so there's no reason we couldn't stack allocate for small select()s and heap allocate for big select()s. That's considerably more work than anyone had in mind, I'd wager. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 18:46:12 2016 From: report at bugs.python.org (Julien Palard) Date: Tue, 15 Nov 2016 23:46:12 +0000 Subject: [issue28707] add 'directory' option to the http.server module In-Reply-To: <1479249109.08.0.530385659795.issue28707@psf.upfronthosting.co.za> Message-ID: <1479253572.34.0.244175615501.issue28707@psf.upfronthosting.co.za> Julien Palard added the comment: Hi St?phane, Your patch is simple and elegant, but I'm asking myself a question about the idea to pass a class instead of an instance to the TCPServer ctor (I know that's not your choice). If we were able to pass an instance of SimpleHTTPRequestHandler instead of its class, we'd be able to give the `directory` to the handler during the `main()`, instead of using with `chdir` and `getcwd` to pass the information in a kind of hidden/side channel. I think that relying on `chdir` and `getcwd` to pass a parameter is not the most pretty or most testable way to do so. Also, having an `os.getcwd()` hardcoded in `SimpleHTTPRequestHandler` does not looks right (again, not your fault, it was here before?) typically for testability, but also when used in a concurrent environment, when cwd may be changed by other "coroutines". I tried to provide a patch fixing all those condiderations, here it is. still, I can't write a patch as KISS as yours, so I'm probably in the wrong way, at least I tried. ---------- nosy: +mdk Added file: http://bugs.python.org/file45494/28707.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 19:00:14 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 16 Nov 2016 00:00:14 +0000 Subject: [issue28709] PyStructSequence_NewType is broken Message-ID: <1479254414.47.0.784230878249.issue28709@psf.upfronthosting.co.za> New submission from Josh Rosenberg: I could be missing something, but it looks like PyStructSequence_NewType is guaranteed broken. Specifically, it allocates the memory with PyType_GenericAlloc (use PyType_Type as the base), and PyType declares itself to have garbage collected instances, so the memory is allocated with _PyObject_GC_Malloc and added to GC tracking just before PyType_GenericAlloc returns. Problem is, PyStructSequence_Init2 copies from a template struct which sets Py_TPFLAGS_DEFAULT. So even though the new struct sequence is GC allocated and managed, it doesn't set Py_TPFLAGS_HEAPTYPE, which means when GC tries to traverse it, type's type_traverse errors out with: Fatal Python error: type_traverse() called for non-heap type 'NameOfStructSequence' It's possible I'm missing something here, so I've attached simple test code for others to confirm (it omits most error checking for simplicity/readability). Just compile the extension module, then run (with the module in the working directory): python -c "import testnewtype; Foo = testnewtype.makeseq('Foo', ['x', 'y'])" There is a commented out line in the test code that explicitly sets the HEAPTYPE flag after type construction (no idea if that's supposed to be supported), and uncommenting it seems to fix the crash (though again, if retroactively flagging as HEAPTYPE is unsupported, something else may break here). I can't find any actual use of PyStructSequence_NewType in the CPython code base, which probably explains why this hasn't been seen; odds are, most extensions using struct sequences are using Init, not NewType, and I only ran into this because I was experimenting with a struct sequence based replacement for collections.namedtuple (to end the start up time objections to using namedtuple in the built-in modules, e.g. #28638). ---------- components: Interpreter Core files: testnewtype.c messages: 280904 nosy: josh.r priority: normal severity: normal status: open title: PyStructSequence_NewType is broken versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45495/testnewtype.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 19:00:25 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 16 Nov 2016 00:00:25 +0000 Subject: [issue28709] PyStructSequence_NewType is broken In-Reply-To: <1479254414.47.0.784230878249.issue28709@psf.upfronthosting.co.za> Message-ID: <1479254425.41.0.310763345431.issue28709@psf.upfronthosting.co.za> Changes by Josh Rosenberg : Added file: http://bugs.python.org/file45496/setup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 19:01:23 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 16 Nov 2016 00:01:23 +0000 Subject: [issue28709] PyStructSequence_NewType is broken; makes GC type without setting Py_TPFLAGS_HEAPTYPE In-Reply-To: <1479254414.47.0.784230878249.issue28709@psf.upfronthosting.co.za> Message-ID: <1479254483.28.0.615751150424.issue28709@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- title: PyStructSequence_NewType is broken -> PyStructSequence_NewType is broken; makes GC type without setting Py_TPFLAGS_HEAPTYPE _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 19:14:07 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 16 Nov 2016 00:14:07 +0000 Subject: [issue28709] PyStructSequence_NewType is broken; makes GC type without setting Py_TPFLAGS_HEAPTYPE In-Reply-To: <1479254414.47.0.784230878249.issue28709@psf.upfronthosting.co.za> Message-ID: <1479255247.66.0.561361194061.issue28709@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Note: Uncommenting the line that forces Py_TPFLAGS_HEAPTYPE isn't enough, since it looks like the PyHeapTypeObject fields aren't initialized properly, causing seg faults if you access, for example, __name__/__qualname__ (or print the type's repr, which implicitly accesses same): python -c "import testnewtype; Foo = testnewtype.makeseq('Foo', ['x', 'y']); print(Foo.__name__)" The type behaves properly otherwise (you can make instances, access values on them), but crashing on repr is probably poor form. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 19:32:40 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Nov 2016 00:32:40 +0000 Subject: [issue28707] add 'directory' option to the http.server module In-Reply-To: <1479253572.34.0.244175615501.issue28707@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Julien Palard added the comment: > If we were able to pass an instance of SimpleHTTPRequestHandler instead of its class, we'd be able to give the `directory` to the handler during the `main()`, instead of using with `chdir` and `getcwd` to pass the information in a kind of hidden/side channel. You may be able to use functools.partial() to pass an additional parameter to the request handler constructor. We use something like that in asyncio for protocols. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 19:59:42 2016 From: report at bugs.python.org (Patrick Lehmann) Date: Wed, 16 Nov 2016 00:59:42 +0000 Subject: [issue28710] Sphinx incompatible markup in configparser.ConfigParser. Message-ID: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za> New submission from Patrick Lehmann: Why does e.g. configparser.ConfigParser contain doc strings with Sphinx incompatible markup? The markup starts with back-tick, but ends with a single quote. Example: https://github.com/python/cpython/blob/master/Lib/configparser.py?ts=2#L26 Sphinx writes these messages: D:\git\PoC\py\lib\ExtendedConfigParser\__init__.py:docstring of lib.ExtendedConfigParser.ExtendedConfigParser.read_file:3: WARNING: Inline interpreted text or phrase reference start-str ing without end-string. Note: ExtendedConfigParser is class derived from configparser.ConfigParser. Inherited methods get documented too. ------------------------ Btw. I have some improvements for this class, how can I contribute them? Who is the maintainer for this class? Please contact me: Patrick.Lehmann at tu-dresden.de The improved version is available at GitHub: https://github.com/Paebbels/ExtendedConfigParser?ts=2 ---------- assignee: docs at python components: Documentation messages: 280907 nosy: Patrick Lehmann, docs at python priority: normal severity: normal status: open title: Sphinx incompatible markup in configparser.ConfigParser. versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 21:07:58 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 16 Nov 2016 02:07:58 +0000 Subject: [issue28709] PyStructSequence_NewType is broken; makes GC type without setting Py_TPFLAGS_HEAPTYPE In-Reply-To: <1479254414.47.0.784230878249.issue28709@psf.upfronthosting.co.za> Message-ID: <1479262078.78.0.696001774496.issue28709@psf.upfronthosting.co.za> Josh Rosenberg added the comment: On further checking, looks like there is a lot of work that should be done to initialize heap types (see PyType_FromSpecWithBases) that PyStructSequeuence_Init2 doesn't do (because it thinks it's working on a static type). I think the solution here is decouple PyStructSequeuence_NewType from PyStructSequeuence_Init2 (or to minimize code duplication, make both of them call a third internal function that accepts additional flags, e.g. to make the type a HEAPTYPE, BASETYPE, or both, and performs the additional work required for those flags if given); Init2 clearly expects a static type, and definitionally, NewType is producing a heap/dynamic type. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 21:31:06 2016 From: report at bugs.python.org (Michael Hu) Date: Wed, 16 Nov 2016 02:31:06 +0000 Subject: [issue28673] When using pyro4 with more than 15 threads, python 2.7.12 cores frequently In-Reply-To: <1478939498.33.0.0967391900201.issue28673@psf.upfronthosting.co.za> Message-ID: <1479263466.29.0.66835741972.issue28673@psf.upfronthosting.co.za> Michael Hu added the comment: (gdb) py-bt #4 Frame 0x7f0ab7a2db60, for file /etc/remoting/remoting_agent.zip/Pyro4/socketutil.py, line 463, in close (self=) self.sock.shutdown(socket.SHUT_RDWR) #7 Frame 0x7f0ab0001760, for file /etc/remoting/remoting_agent.zip/Pyro4/socketutil.py, line 453, in __del__ (self=) self.close() (gdb) py-list 458 def recv(self, size): 459 return receiveData(self.sock, size) 460 461 def close(self): 462 try: >463 self.sock.shutdown(socket.SHUT_RDWR) 464 except (OSError, socket.error): 465 pass 466 try: 467 self.sock.close() 468 except AttributeError: (gdb) f 7 #7 PyEval_EvalFrameEx ( f=f at entry=Frame 0x7f0ab0001760, for file /etc/remoting/remoting_agent.zip/Pyro4/socketutil.py, line 453, in __del__ (self=), throwflag=throwflag at entry=0) at ../Python/ceval.c:2681 2681 in ../Python/ceval.c (gdb) py-list 448 def __init__(self, sock, objectId=None): 449 self.sock = sock 450 self.objectId = objectId 451 452 def __del__(self): >453 self.close() 454 455 def send(self, data): 456 sendData(self.sock, data) 457 458 def recv(self, size): (gdb) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 23:11:36 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 16 Nov 2016 04:11:36 +0000 Subject: [issue28709] PyStructSequence_NewType is broken; makes GC type without setting Py_TPFLAGS_HEAPTYPE In-Reply-To: <1479254414.47.0.784230878249.issue28709@psf.upfronthosting.co.za> Message-ID: <1479269496.15.0.723278479951.issue28709@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 23:25:25 2016 From: report at bugs.python.org (Bryan) Date: Wed, 16 Nov 2016 04:25:25 +0000 Subject: [issue28711] IDLE doesn't open Message-ID: <1479270325.09.0.272646595028.issue28711@psf.upfronthosting.co.za> New submission from Bryan: Hello there I am using python 2.7 on windows 10 because my college class requires it, I am having issues when trying to open the IDLE. When i click on it the blue ring loads and then noting happens. I started to have to issue when i was changing the key settings so i can right- click or at least trying to figure out how to do it. If anyone can help it will greatly appreciated. ---------- messages: 280910 nosy: bg90299 priority: normal severity: normal status: open title: IDLE doesn't open type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 15 23:51:16 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 16 Nov 2016 04:51:16 +0000 Subject: [issue28673] When using pyro4 with more than 15 threads, python 2.7.12 cores frequently In-Reply-To: <1478939498.33.0.0967391900201.issue28673@psf.upfronthosting.co.za> Message-ID: <1479271876.11.0.431242028224.issue28673@psf.upfronthosting.co.za> INADA Naoki added the comment: Can you check backtrace of main thread? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 00:12:46 2016 From: report at bugs.python.org (Chun-Yu Tseng) Date: Wed, 16 Nov 2016 05:12:46 +0000 Subject: [issue26072] pdb fails to access variables closed over In-Reply-To: <1452402984.12.0.000738362264887.issue26072@psf.upfronthosting.co.za> Message-ID: <1479273166.5.0.542991792524.issue26072@psf.upfronthosting.co.za> Chun-Yu Tseng added the comment: Call for review again. Maybe xdegaye would like to take a look? I found this related issue: #21161 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 00:23:36 2016 From: report at bugs.python.org (Antony Lee) Date: Wed, 16 Nov 2016 05:23:36 +0000 Subject: [issue26072] pdb fails to access variables closed over In-Reply-To: <1452402984.12.0.000738362264887.issue26072@psf.upfronthosting.co.za> Message-ID: <1479273816.11.0.536443281173.issue26072@psf.upfronthosting.co.za> Changes by Antony Lee : ---------- nosy: -Antony.Lee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 00:29:56 2016 From: report at bugs.python.org (Elias Zamaria) Date: Wed, 16 Nov 2016 05:29:56 +0000 Subject: [issue28625] multiprocessing.Pool.imap swallows exceptions thrown by generators In-Reply-To: <1478449003.58.0.0873174644967.issue28625@psf.upfronthosting.co.za> Message-ID: <1479274196.35.0.459360426722.issue28625@psf.upfronthosting.co.za> Elias Zamaria added the comment: I tried my code in Python 3.6.0b3 and got the same result. ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 00:40:28 2016 From: report at bugs.python.org (Mingye Wang) Date: Wed, 16 Nov 2016 05:40:28 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages Message-ID: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> New submission from Mingye Wang: Mappings for 0x81 and 0x8D in multiple Windows code pages diverge from what Windows does. Attached is a script that tests for this behavior. (These two bytes are not necessary the only problems, but for sure they are the most widespread and famous ones. Again, refer to Unicode best fit for something that works.) This problem is seen in Python 2.7.10 on Windows 10b14959, but apparently it is known since long ago[1]. Python 3.4.3 on Cygwin also fails ``b'\x81\x8d'.encode('cp1252')``. [1]: https://ftfy.readthedocs.io/en/latest/#module-ftfy.bad_codecs.sloppy ---------- components: Unicode files: pycp.py messages: 280914 nosy: Artoria2e5, ezio.melotti, haypo priority: normal severity: normal status: open title: Non-Windows mappings for a couple of Windows code pages type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45497/pycp.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 00:40:54 2016 From: report at bugs.python.org (Mingye Wang) Date: Wed, 16 Nov 2016 05:40:54 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479274854.49.0.907918778076.issue28712@psf.upfronthosting.co.za> Changes by Mingye Wang : Added file: http://bugs.python.org/file45498/windows10_14959.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 00:44:36 2016 From: report at bugs.python.org (Mingye Wang) Date: Wed, 16 Nov 2016 05:44:36 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479275076.84.0.0662452360592.issue28712@psf.upfronthosting.co.za> Mingye Wang added the comment: > Python 3.4.3 on Cygwin also fails ``b'\x81\x8d'.encode('cp1252')``. ... but since Cygwin packagers did not enable Win32 APIs for their build, I cannot test the script directly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 01:07:02 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 16 Nov 2016 06:07:02 +0000 Subject: [issue28707] add 'directory' option to the http.server module In-Reply-To: <1479249109.08.0.530385659795.issue28707@psf.upfronthosting.co.za> Message-ID: <1479276422.12.0.792599821098.issue28707@psf.upfronthosting.co.za> Xiang Zhang added the comment: +1 for this idea. I use this command everyday in work and every time must cd to the directory is an annoyance. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 01:35:11 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Nov 2016 06:35:11 +0000 Subject: [issue26920] android: test_sys fails In-Reply-To: <1462267582.58.0.744255750518.issue26920@psf.upfronthosting.co.za> Message-ID: <20161116063508.107129.32211.00922E80@psf.io> Roundup Robot added the comment: New changeset 73bd6bbbb5e2 by Xavier de Gaye in branch '3.6': Issue #26920: Fix not getting the locale's charset upon initializing the interpreter, https://hg.python.org/cpython/rev/73bd6bbbb5e2 New changeset f358d849c14e by Xavier de Gaye in branch 'default': Issue #26920: Merge 3.6 https://hg.python.org/cpython/rev/f358d849c14e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 01:51:00 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 06:51:00 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479279060.55.0.308284663288.issue28712@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It seems to me there is something wrong with your test. For example decoding b'\x81\x8d' from CP1251 (as well from any other codepage!) gives you u'\x81\x8d', but codes 0x81 and 0x8D are assigned to different characters: '?' (U+0402) and '?' (U+040C). 0x81 0x0403 #CYRILLIC CAPITAL LETTER GJE 0x8D 0x040C #CYRILLIC CAPITAL LETTER KJE [1] https://en.wikipedia.org/wiki/Windows-1251 [2] http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1251.TXT [3] http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1251.txt ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 01:51:56 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 16 Nov 2016 06:51:56 +0000 Subject: [issue26926] test_io large file test failure on 32 bits Android platforms In-Reply-To: <1462283737.14.0.888848894928.issue26926@psf.upfronthosting.co.za> Message-ID: <1479279116.52.0.23465474623.issue26926@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 01:52:40 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 06:52:40 +0000 Subject: [issue28625] multiprocessing.Pool.imap swallows exceptions thrown by generators In-Reply-To: <1478449003.58.0.0873174644967.issue28625@psf.upfronthosting.co.za> Message-ID: <1479279160.4.0.296979490656.issue28625@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 01:53:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 06:53:07 +0000 Subject: [issue28709] PyStructSequence_NewType is broken; makes GC type without setting Py_TPFLAGS_HEAPTYPE In-Reply-To: <1479254414.47.0.784230878249.issue28709@psf.upfronthosting.co.za> Message-ID: <1479279187.25.0.013437967064.issue28709@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 01:53:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 06:53:54 +0000 Subject: [issue28710] Sphinx incompatible markup in configparser.ConfigParser. In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za> Message-ID: <1479279234.89.0.726698804785.issue28710@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +easy stage: -> needs patch versions: +Python 2.7, Python 3.6, Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 01:54:53 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 06:54:53 +0000 Subject: [issue28711] IDLE doesn't open In-Reply-To: <1479270325.09.0.272646595028.issue28711@psf.upfronthosting.co.za> Message-ID: <1479279293.69.0.808690994815.issue28711@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> terry.reedy components: +IDLE nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 02:05:10 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 16 Nov 2016 07:05:10 +0000 Subject: [issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString In-Reply-To: <1479239405.55.0.31899621759.issue28701@psf.upfronthosting.co.za> Message-ID: <1479279910.06.0.68048017754.issue28701@psf.upfronthosting.co.za> Xiang Zhang added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 02:07:09 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Nov 2016 07:07:09 +0000 Subject: [issue26935] android: test_os fails In-Reply-To: <1462287800.22.0.0769666286965.issue26935@psf.upfronthosting.co.za> Message-ID: <20161116070706.25019.86359.106BD897@psf.io> Roundup Robot added the comment: New changeset 80e4cb5888f3 by Xavier de Gaye in branch '3.6': Issue #26935: Fix broken Android dup2() in test_os https://hg.python.org/cpython/rev/80e4cb5888f3 New changeset da59b7084dbe by Xavier de Gaye in branch 'default': Issue #26935: Merge 3.6 https://hg.python.org/cpython/rev/da59b7084dbe ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 02:13:30 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Nov 2016 07:13:30 +0000 Subject: [issue28673] When using pyro4 with more than 15 threads, python 2.7.12 cores frequently In-Reply-To: <1479263466.29.0.66835741972.issue28673@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Ok but can you also try faulthandler to see all frames of all threads? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 02:15:23 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Nov 2016 07:15:23 +0000 Subject: [issue28673] When using pyro4 with more than 15 threads, python 2.7.12 cores frequently In-Reply-To: Message-ID: STINNER Victor added the comment: By the way, you can try your application on Python 3.6 using PYTHONMALLOC=debug env var. Or retry your application on Python 2.7 recompiled using ./configure --with-pydebug. I would like to know if Python sees a buffer overflow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 02:16:21 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Nov 2016 07:16:21 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1479239614.71.0.589671334644.issue21449@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: _PyUnicode_CompareWithId is a private function. We can remove it if it has issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 02:19:52 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 16 Nov 2016 07:19:52 +0000 Subject: [issue26920] android: test_sys fails In-Reply-To: <1462267582.58.0.744255750518.issue26920@psf.upfronthosting.co.za> Message-ID: <1479280792.53.0.983778860709.issue26920@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 02:24:43 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 16 Nov 2016 07:24:43 +0000 Subject: [issue26931] android: test_distutils fails In-Reply-To: <1462285501.44.0.0195995288955.issue26931@psf.upfronthosting.co.za> Message-ID: <1479281083.85.0.292198163399.issue26931@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- assignee: -> xdegaye stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 02:37:17 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 16 Nov 2016 07:37:17 +0000 Subject: [issue26935] android: test_os fails In-Reply-To: <1462287800.22.0.0769666286965.issue26935@psf.upfronthosting.co.za> Message-ID: <1479281837.62.0.655101505614.issue26935@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- dependencies: -android: add platform.android_ver() resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 02:37:22 2016 From: report at bugs.python.org (Daisuke Miyakawa) Date: Wed, 16 Nov 2016 07:37:22 +0000 Subject: [issue28713] Recent tutorial for recent Python3 still uses IOError. Message-ID: <1479281842.16.0.362729785805.issue28713@psf.upfronthosting.co.za> New submission from Daisuke Miyakawa: https://docs.python.org/3.5/tutorial/errors.html for arg in sys.argv[1:]: try: f = open(arg, 'r') except IOError: print('cannot open', arg) else: print(arg, 'has', len(f.readlines()), 'lines') f.close() Although IOError is still available as an alias to OSError, it should not be used in the tutorial, I believe. ---------- assignee: docs at python components: Documentation messages: 280924 nosy: dmiyakawa, docs at python priority: normal severity: normal status: open title: Recent tutorial for recent Python3 still uses IOError. versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 02:43:24 2016 From: report at bugs.python.org (Daisuke Miyakawa) Date: Wed, 16 Nov 2016 07:43:24 +0000 Subject: [issue28713] Recent tutorial for recent Python3 still uses IOError. In-Reply-To: <1479281842.16.0.362729785805.issue28713@psf.upfronthosting.co.za> Message-ID: <1479282204.71.0.108847244259.issue28713@psf.upfronthosting.co.za> Changes by Daisuke Miyakawa : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 02:56:23 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 16 Nov 2016 07:56:23 +0000 Subject: [issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString In-Reply-To: <1479239405.55.0.31899621759.issue28701@psf.upfronthosting.co.za> Message-ID: <1479282983.7.0.894552911678.issue28701@psf.upfronthosting.co.za> INADA Naoki added the comment: Patch LGTM. But I don't know it's OK to commit it on 2.7, 3.5 and 3.6. ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 03:20:20 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Nov 2016 08:20:20 +0000 Subject: [issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString In-Reply-To: <1479239405.55.0.31899621759.issue28701@psf.upfronthosting.co.za> Message-ID: <20161116082016.7819.5744.DBA95EFA@psf.io> Roundup Robot added the comment: New changeset 386c682dcd75 by Serhiy Storchaka in branch '3.5': Issue #28701: Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString. https://hg.python.org/cpython/rev/386c682dcd75 New changeset 72d07d13869a by Serhiy Storchaka in branch '3.6': Issue #28701: Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString. https://hg.python.org/cpython/rev/72d07d13869a New changeset 6f0f77333da5 by Serhiy Storchaka in branch 'default': Issue #28701: Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString. https://hg.python.org/cpython/rev/6f0f77333da5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 03:20:27 2016 From: report at bugs.python.org (Matthieu S) Date: Wed, 16 Nov 2016 08:20:27 +0000 Subject: [issue28000] Build fails on AIX with _LINUX_SOURCE_COMPAT flag In-Reply-To: <1473261703.53.0.692891859324.issue28000@psf.upfronthosting.co.za> Message-ID: <1479284427.14.0.942745672786.issue28000@psf.upfronthosting.co.za> Matthieu S added the comment: Thanks ! ---------- resolution: fixed -> status: closed -> open versions: -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 03:21:15 2016 From: report at bugs.python.org (Matthieu S) Date: Wed, 16 Nov 2016 08:21:15 +0000 Subject: [issue28000] Build fails on AIX with _LINUX_SOURCE_COMPAT flag In-Reply-To: <1473261703.53.0.692891859324.issue28000@psf.upfronthosting.co.za> Message-ID: <1479284475.57.0.327450238306.issue28000@psf.upfronthosting.co.za> Changes by Matthieu S : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 03:22:36 2016 From: report at bugs.python.org (Matthieu S) Date: Wed, 16 Nov 2016 08:22:36 +0000 Subject: [issue28000] Build fails on AIX with _LINUX_SOURCE_COMPAT flag In-Reply-To: <1473261703.53.0.692891859324.issue28000@psf.upfronthosting.co.za> Message-ID: <1479284556.2.0.742996989822.issue28000@psf.upfronthosting.co.za> Changes by Matthieu S : ---------- versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 03:25:43 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 08:25:43 +0000 Subject: [issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString In-Reply-To: <1479239405.55.0.31899621759.issue28701@psf.upfronthosting.co.za> Message-ID: <1479284743.2.0.232027978198.issue28701@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Xiang and Inada for your reviews. The patch fixes a bug: error is not checked after PyUnicode_CompareWithASCIIString(). The patch is not applicable to 2.7 since PyUnicode_CompareWithASCIIString() is Python 3 only. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 04:20:59 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 16 Nov 2016 09:20:59 +0000 Subject: [issue28711] IDLE doesn't open In-Reply-To: <1479270325.09.0.272646595028.issue28711@psf.upfronthosting.co.za> Message-ID: <1479288059.19.0.0213954615325.issue28711@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Run IDLE from Command Prompt with 'python -m idlelib.idle' (or 'py -2 -m idlelib.idle') and you should see an error message. Post it here. What do you mean by 'change the key settings'? What, specifically, did you do? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 04:32:30 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 16 Nov 2016 09:32:30 +0000 Subject: [issue26072] pdb fails to access variables closed over In-Reply-To: <1452402984.12.0.000738362264887.issue26072@psf.upfronthosting.co.za> Message-ID: <1479288750.15.0.988022710592.issue26072@psf.upfronthosting.co.za> Xavier de Gaye added the comment: It seems that the last patch in issue 21161 fixes all the problems described here, msg 149096 explains why. Can you confirm that this is a duplicate of issue 21161. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 05:13:31 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 16 Nov 2016 10:13:31 +0000 Subject: [issue27945] Various segfaults with dict In-Reply-To: <1472852008.61.0.354257945943.issue27945@psf.upfronthosting.co.za> Message-ID: <1479291211.23.0.122619553601.issue27945@psf.upfronthosting.co.za> INADA Naoki added the comment: 0001-Issue-27945-fix-PyDict_MergeFromSeq2-use-after-free.patch: LGTM. I've checked it can be applied to 2.7 and 3.5 branch and passes `make quicktest`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 05:27:31 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 16 Nov 2016 10:27:31 +0000 Subject: [issue27945] Various segfaults with dict In-Reply-To: <1472852008.61.0.354257945943.issue27945@psf.upfronthosting.co.za> Message-ID: <1479292051.54.0.385791864968.issue27945@psf.upfronthosting.co.za> INADA Naoki added the comment: 0001-Issue-27945-fix-dictitems_contains-use-after-free.patch LGTM. This patch can be applied to 2.7 and 3.5, without conflict against previous patch. It passes `make quicktest`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 05:53:37 2016 From: report at bugs.python.org (Chun-Yu Tseng) Date: Wed, 16 Nov 2016 10:53:37 +0000 Subject: [issue26072] pdb fails to access variables closed over In-Reply-To: <1452402984.12.0.000738362264887.issue26072@psf.upfronthosting.co.za> Message-ID: <1479293617.41.0.21525039006.issue26072@psf.upfronthosting.co.za> Chun-Yu Tseng added the comment: The last patch in #21161 fixes some problems but also brings up critical issues: (Pdb) list . 1 y = 2 2 3 def f(): 4 y = 9 5 z = 10 6 -> import pdb; pdb.set_trace(); 7 f() [EOF] (Pdb) globals()['y'] 9 (Pdb) global y; print(y) 9 (Pdb) globals()['z'] 10 I think that we should not copy local variables to globals() while doing execution. It will always bring out the wrong result of `globals()`. So, the patch I proposed here is focused on "Showing Friendly Error Message" to let the users be less confused. # The patch works when a user tries to bound a free variable to a list comprehension. It will show the proper error message, too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 05:55:07 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Nov 2016 10:55:07 +0000 Subject: [issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString In-Reply-To: <1479239405.55.0.31899621759.issue28701@psf.upfronthosting.co.za> Message-ID: <1479293707.42.0.0404583074373.issue28701@psf.upfronthosting.co.za> STINNER Victor added the comment: (I reopen the issue to ask my question :-)) +/* Test whether a unicode is equal to ASCII string. Return 1 if true, + 0 otherwise. Return 0 if any argument contains non-ASCII characters. + Any error occurs inside will be cleared before return. */ Can you please also document the behaviour if you pass two non-ASCII strings which are equal? I understand that it returns also 0, right? Maybe the API should be more strict and require right to be ASCII: "right string must be encoded to ASCII". I expect an assertion error or a fatal error if right is non-ASCII when Python is compiled in debug mode. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 06:26:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 11:26:13 +0000 Subject: [issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString In-Reply-To: <1479239405.55.0.31899621759.issue28701@psf.upfronthosting.co.za> Message-ID: <1479295573.28.0.930781722978.issue28701@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Can you please also document the behaviour if you pass two non-ASCII strings which are equal? What mean "equal"? The left argument is a Unicode string, but the right argument is a byte string. For comparing them we should decode right argument or encode left argument. The result depends on using encoding. _PyUnicode_EqualToASCIIString() uses ASCII (as shown from its name). Non-ASCII strings can't be equal. This is documented. If the documentation is not clear, could you provide better wording? > Maybe the API should be more strict and require right to be ASCII: "right string must be encoded to ASCII". I expect an assertion error or a fatal error if right is non-ASCII when Python is compiled in debug mode. I hesitated about adding an assertion error or a fatal error in a bug fix. But this can be added in develop version. I don't know what is better -- return 0 in all builds or return 0 in release build and crash in debug build? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 06:28:04 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 16 Nov 2016 11:28:04 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479295684.92.0.12779164585.issue21449@psf.upfronthosting.co.za> Xiang Zhang added the comment: > _PyUnicode_CompareWithId is a private function. We can remove it if it has issues. It doesn't. But once there is _PyUnicode_EqualToASCIIId, it's can be rarely used. The new patch implements a version of _PyUnicode_EqualToASCIIId. ---------- Added file: http://bugs.python.org/file45499/_PyUnicode_EqualToASCIIId.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 06:46:18 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 16 Nov 2016 11:46:18 +0000 Subject: [issue27945] Various segfaults with dict In-Reply-To: <1472852008.61.0.354257945943.issue27945@psf.upfronthosting.co.za> Message-ID: <1479296778.18.0.0058281550948.issue27945@psf.upfronthosting.co.za> INADA Naoki added the comment: 0001-Issue-27945-fix-dictiter_iternextitem-use-after-free.patch LGTM and OK too. But 0001-Issue-27945-Fixed-segfaults-in-dict.fromkeys-when-it.patch cause conflict. I want to commit first three patches. For another reviewer, here is the patch merging three patches. Please review it. ---------- Added file: http://bugs.python.org/file45500/27945-dict-segv-py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 07:08:55 2016 From: report at bugs.python.org (Mathieu Sornay) Date: Wed, 16 Nov 2016 12:08:55 +0000 Subject: [issue27585] asyncio.Lock deadlock after cancellation In-Reply-To: <1469120801.4.0.62510822161.issue27585@psf.upfronthosting.co.za> Message-ID: <1479298135.11.0.617098948539.issue27585@psf.upfronthosting.co.za> Mathieu Sornay added the comment: Fix attempt : https://github.com/python/asyncio/pull/467 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 07:32:21 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 16 Nov 2016 12:32:21 +0000 Subject: [issue28595] shlex.shlex should not augment wordchars In-Reply-To: <1478166136.94.0.995190174918.issue28595@psf.upfronthosting.co.za> Message-ID: <1479299541.37.0.0147101082716.issue28595@psf.upfronthosting.co.za> R. David Murray added the comment: Per our conversation on IRC: since this is not a regression, it is unlikely to be addressed at this stage of the 3.6 release cycle. I'm adding the release manager as nosy just in case, but I don't expect him to want this to be addressed now. IMO if the behavior does not match "the posix shell", then it is a bug, and can be fixed in 3.6.1. (I'd prefer not to wait longer than that, though). So proposing a patch with tests and doc changes would be beneficial. As for the flag defaults, that's a backward compatibility issue. I don't like the idea of changing the default based on the value of another flag, but it could be discussed. The 'longer term' would be a several release deprecation cycle...I think that has been discussed previously but I can't find the discussion in a quick search. The documentation, however, could be improved. Please open a separate issue for the doc change request at least. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 07:46:29 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 12:46:29 +0000 Subject: [issue27945] Various segfaults with dict In-Reply-To: <1472852008.61.0.354257945943.issue27945@psf.upfronthosting.co.za> Message-ID: <1479300389.96.0.885357831814.issue27945@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I worry about performance. Additional increment/decrement of reference counter can add significant overhead in critical places of Python interpreter. Before committing any patches we should measure the performance lost. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 07:52:24 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 16 Nov 2016 12:52:24 +0000 Subject: [issue28670] PEP 235: Implement on every POSIX system, and clean up the C code for `import' In-Reply-To: <1478899111.69.0.0154952768919.issue28670@psf.upfronthosting.co.za> Message-ID: <1479300744.83.0.173123244241.issue28670@psf.upfronthosting.co.za> Nick Coghlan added the comment: Michael, please do not reopen feature requests that have been declared out of scope for maintenance releases. Python 2.7 DOES NOT support filesystem semantics that differ from the "default" semantics for the host operating system. Even Python 3 requires that the filesystems attached be at least somewhat consistent (e.g. using a common filesystem encoding) if you want to use the default Python-level APIs. If you wish to pursue this topic further, please take it to the issue tracker for your preferred Linux distribution and convince *them* that this is an operating system level bug in their system Python installation. If multiple Linux distributions agree that this is a bug that should be fixed rather than a new feature, and are willing to carry a patch to address it, then that will add weight to your argument that the change should be applied in an upstream maintenance release. In the meantime, folks that really want the behaviour you propose may upgrade to Python 3, or potentially explore the importlib2 backport of the Python 3 import system to the Python 2 series. ---------- resolution: -> rejected stage: test needed -> resolved status: open -> closed type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 07:59:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 12:59:24 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479301164.8.0.486595249858.issue21449@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. Except that _PyUnicode_EqualToASCIIString() could be used for simplicity. > _PyUnicode_CompareWithId is a private function. We can remove it if it has issues. I would left it in maintained releases and removed it in 3.7 (or 3.6?). ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 08:20:00 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 16 Nov 2016 13:20:00 +0000 Subject: [issue27945] Various segfaults with dict In-Reply-To: <1472852008.61.0.354257945943.issue27945@psf.upfronthosting.co.za> Message-ID: <1479302400.16.0.475601991438.issue27945@psf.upfronthosting.co.za> INADA Naoki added the comment: OK, I'll run benchmark in this week. But three patches seems don't affects to performance critical APIs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 08:36:40 2016 From: report at bugs.python.org (Mingye Wang) Date: Wed, 16 Nov 2016 13:36:40 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479303400.37.0.967012685372.issue28712@psf.upfronthosting.co.za> Mingye Wang added the comment: Ugh... This is weird. Attached is a correct version use Python 3.6's 'code page' methods. I have modified the script a little to make sure it runs on Py3. ---------- Added file: http://bugs.python.org/file45501/win10_14959_py36.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 08:37:23 2016 From: report at bugs.python.org (Mingye Wang) Date: Wed, 16 Nov 2016 13:37:23 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479303443.63.0.508809164411.issue28712@psf.upfronthosting.co.za> Changes by Mingye Wang : Added file: http://bugs.python.org/file45502/pycp.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 08:37:31 2016 From: report at bugs.python.org (Mingye Wang) Date: Wed, 16 Nov 2016 13:37:31 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479303451.45.0.756163077708.issue28712@psf.upfronthosting.co.za> Changes by Mingye Wang : Removed file: http://bugs.python.org/file45497/pycp.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 08:39:37 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Nov 2016 13:39:37 +0000 Subject: [issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString In-Reply-To: <1479295573.28.0.930781722978.issue28701@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I suggest "return 0 in release build and crash in debug build". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 08:41:49 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Nov 2016 13:41:49 +0000 Subject: [issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString In-Reply-To: <1479239405.55.0.31899621759.issue28701@psf.upfronthosting.co.za> Message-ID: <20161116134145.89163.50310.A7287D7E@psf.io> Roundup Robot added the comment: New changeset faf04a995031 by Serhiy Storchaka in branch '3.5': Issue #28701: Replace _PyUnicode_CompareWithId with _PyUnicode_EqualToASCIIId. https://hg.python.org/cpython/rev/faf04a995031 New changeset ff3dacc98b3a by Serhiy Storchaka in branch '3.6': Issue #28701: Replace _PyUnicode_CompareWithId with _PyUnicode_EqualToASCIIId. https://hg.python.org/cpython/rev/ff3dacc98b3a New changeset 765013f71bc4 by Serhiy Storchaka in branch 'default': Issue #28701: Replace _PyUnicode_CompareWithId with _PyUnicode_EqualToASCIIId. https://hg.python.org/cpython/rev/765013f71bc4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 08:43:10 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 13:43:10 +0000 Subject: [issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString In-Reply-To: <1479239405.55.0.31899621759.issue28701@psf.upfronthosting.co.za> Message-ID: <1479303790.46.0.516760951255.issue28701@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The correct issue for above commits is issue21449. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 08:43:38 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 13:43:38 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479303818.26.0.937440243798.issue21449@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: New changeset faf04a995031 by Serhiy Storchaka in branch '3.5': Issue #28701: Replace _PyUnicode_CompareWithId with _PyUnicode_EqualToASCIIId. https://hg.python.org/cpython/rev/faf04a995031 New changeset ff3dacc98b3a by Serhiy Storchaka in branch '3.6': Issue #28701: Replace _PyUnicode_CompareWithId with _PyUnicode_EqualToASCIIId. https://hg.python.org/cpython/rev/ff3dacc98b3a New changeset 765013f71bc4 by Serhiy Storchaka in branch 'default': Issue #28701: Replace _PyUnicode_CompareWithId with _PyUnicode_EqualToASCIIId. https://hg.python.org/cpython/rev/765013f71bc4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 08:44:51 2016 From: report at bugs.python.org (Tristan Fisher) Date: Wed, 16 Nov 2016 13:44:51 +0000 Subject: [issue2504] Add gettext.pgettext() and variants support In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za> Message-ID: <1479303891.84.0.786806303902.issue2504@psf.upfronthosting.co.za> Changes by Tristan Fisher : ---------- nosy: +Tristan.Fisher _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 08:53:22 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 13:53:22 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479304402.68.0.299485250204.issue28712@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is the output of new script? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 08:57:13 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Nov 2016 13:57:13 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <20161116135710.25000.56075.2B2D4068@psf.io> Roundup Robot added the comment: New changeset b995a6950139 by Serhiy Storchaka in branch '3.6': Issue #21449: Removed private function _PyUnicode_CompareWithId. https://hg.python.org/cpython/rev/b995a6950139 New changeset 9b053d3c74dc by Serhiy Storchaka in branch 'default': Issue #21449: Removed private function _PyUnicode_CompareWithId. https://hg.python.org/cpython/rev/9b053d3c74dc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 08:59:39 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 13:59:39 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479304779.13.0.570279385946.issue21449@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Josh and Xiang for your contribution. ---------- dependencies: -Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 08:59:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 13:59:58 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479304798.84.0.0905546945101.issue21449@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 09:04:40 2016 From: report at bugs.python.org (Michael Witten) Date: Wed, 16 Nov 2016 14:04:40 +0000 Subject: [issue28670] PEP 235: Implement on every POSIX system, and clean up the C code for `import' In-Reply-To: <1478899111.69.0.0154952768919.issue28670@psf.upfronthosting.co.za> Message-ID: <1479305080.49.0.717402902503.issue28670@psf.upfronthosting.co.za> Michael Witten added the comment: * This is not a feature request; this is a bug fix for errant behavior. However, in the interest of civility, I have not re-opened this issue. * > Python 2.7 DOES NOT support filesystem semantics that differ > from the "default" semantics for the host operating system. That statement makes no sense; the decisions being made here are based on nonsense. * > folks that really want the behaviour you propose may upgrade to Python 3 Ah. I'm getting the distinct impression that this is a political matter, rather than a technical matter. No wonder the responses have been incomprehensible. Here's an idea that echos your own: If you wish to pursue this outcome further, please take it to the issue tracker for your preferred Linux distribution and convince *them* that all the software they provide should be ported to Python 3. If multiple Linux distributions agree that it is no longer valuable to support Python 2, then that will add weight to your argument that there is little reason to fix its bugs, and that Python 3 is actually useful. ---------- type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 09:13:31 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Nov 2016 14:13:31 +0000 Subject: [issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString In-Reply-To: <1479239405.55.0.31899621759.issue28701@psf.upfronthosting.co.za> Message-ID: <20161116141328.106564.48578.1E88F1C8@psf.io> Roundup Robot added the comment: New changeset b607f835f170 by Serhiy Storchaka in branch '3.5': Fixed an off-by-one error in _PyUnicode_EqualToASCIIString (issue #28701). https://hg.python.org/cpython/rev/b607f835f170 New changeset 1369e51182b7 by Serhiy Storchaka in branch '3.6': Fixed an off-by-one error in _PyUnicode_EqualToASCIIString (issue #28701). https://hg.python.org/cpython/rev/1369e51182b7 New changeset ba14f8b61bd8 by Serhiy Storchaka in branch 'default': Fixed an off-by-one error in _PyUnicode_EqualToASCIIString (issue #28701). https://hg.python.org/cpython/rev/ba14f8b61bd8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 09:31:21 2016 From: report at bugs.python.org (Mingye Wang) Date: Wed, 16 Nov 2016 14:31:21 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479306681.62.0.27276318825.issue28712@psf.upfronthosting.co.za> Mingye Wang added the comment: The output is already attached as win10_14959_py36.txt. PS: after playing with ctypes, I got a version of pycp that works with Py < 3.3 too (attached with comment). ---------- Added file: http://bugs.python.org/file45503/pycp_ctypes.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 09:31:34 2016 From: report at bugs.python.org (Mingye Wang) Date: Wed, 16 Nov 2016 14:31:34 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479306694.3.0.807588199605.issue28712@psf.upfronthosting.co.za> Changes by Mingye Wang : Removed file: http://bugs.python.org/file45502/pycp.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 09:48:38 2016 From: report at bugs.python.org (Davin Potts) Date: Wed, 16 Nov 2016 14:48:38 +0000 Subject: [issue28625] multiprocessing.Pool.imap swallows exceptions thrown by generators In-Reply-To: <1478449003.58.0.0873174644967.issue28625@psf.upfronthosting.co.za> Message-ID: <1479307718.26.0.413020071231.issue28625@psf.upfronthosting.co.za> Davin Potts added the comment: In issue28699, an important clue has been identified (a variation on the generator triggers a different, inconsistent behavior). I will merge this issue into that one to keep us all on the same page. ---------- superseder: -> Imap from ThreadPool behaves unexpectedly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 09:54:30 2016 From: report at bugs.python.org (Davin Potts) Date: Wed, 16 Nov 2016 14:54:30 +0000 Subject: [issue28699] Imap from ThreadPool behaves unexpectedly In-Reply-To: <1479234139.82.0.483433491582.issue28699@psf.upfronthosting.co.za> Message-ID: <1479308070.78.0.651580630815.issue28699@psf.upfronthosting.co.za> Davin Potts added the comment: To tie in the example given by @elias in issue28625, this inconsistency in behavior is not limited to ThreadPool -- it appears with a process Pool as well: from multiprocessing import Pool def double(x): return 2 * x def get_numbers(): raise Exception("oops") yield 1 yield 2 >>> list(Pool(processes=2).imap(double, get_numbers())) # returns list [] >>> list(Pool(processes=2).map(double, get_numbers())) Traceback (most recent call last): ... Exception: oops def get_numbers_differently(): yield 1 raise Exception("oops") yield 2 >>> list(Pool(processes=2).imap(double, get_numbers_differently())) # now we see exception Traceback (most recent call last): ... Exception: oops ---------- assignee: -> davin nosy: +elias stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 09:56:11 2016 From: report at bugs.python.org (Davin Potts) Date: Wed, 16 Nov 2016 14:56:11 +0000 Subject: [issue28699] Imap from ThreadPool behaves unexpectedly In-Reply-To: <1479234139.82.0.483433491582.issue28699@psf.upfronthosting.co.za> Message-ID: <1479308171.81.0.421689661222.issue28699@psf.upfronthosting.co.za> Davin Potts added the comment: This inconsistent behavior in imap on both Pool and ThreadPool is not what I would expect. ---------- versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 10:00:35 2016 From: report at bugs.python.org (George Fischhof) Date: Wed, 16 Nov 2016 15:00:35 +0000 Subject: [issue28714] Addition to Documentation of configparser.ConfigParser.write() documentaion Message-ID: <1479308435.4.0.112292626323.issue28714@psf.upfronthosting.co.za> New submission from George Fischhof: Hi There, I used configparser.ConfigParser.write() to update a config file. And I found that my config wa duplicated. The file was opened with mode 'r+' I figured out that write (I mean the write method of configparser) writes at actual file position. I issued a file.seek(0) command before write and the result was good. So I think documentaion should advice to user to reopen the file with mode 'w' or to issue a file.seek(0) command before using the ConfigParser.write() I used the following python version on windows: Python 3.5.1 (v3.5.1:37a07cee5969, Dec 6 2015, 01:38:48) [MSC v.1900 32 bit (Intel)] on win32 affected documentation: https://docs.python.org/3.5/library/configparser.html#configparser.ConfigParser.write Best Regards, George Fischhof ---------- assignee: docs at python components: Documentation messages: 280960 nosy: docs at python, georgefischhof priority: normal severity: normal status: open title: Addition to Documentation of configparser.ConfigParser.write() documentaion versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 10:01:52 2016 From: report at bugs.python.org (Davin Potts) Date: Wed, 16 Nov 2016 15:01:52 +0000 Subject: [issue28696] imap from ThreadPool hangs by an exception in a generator function In-Reply-To: <1479214370.8.0.751710549169.issue28696@psf.upfronthosting.co.za> Message-ID: <1479308512.32.0.262121547921.issue28696@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- superseder: -> Imap from ThreadPool behaves unexpectedly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 10:02:21 2016 From: report at bugs.python.org (George Fischhof) Date: Wed, 16 Nov 2016 15:02:21 +0000 Subject: [issue28714] Addition to Documentation of configparser.ConfigParser.write() In-Reply-To: <1479308435.4.0.112292626323.issue28714@psf.upfronthosting.co.za> Message-ID: <1479308541.04.0.777638901847.issue28714@psf.upfronthosting.co.za> Changes by George Fischhof : ---------- title: Addition to Documentation of configparser.ConfigParser.write() documentaion -> Addition to Documentation of configparser.ConfigParser.write() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 10:14:42 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 16 Nov 2016 15:14:42 +0000 Subject: [issue28670] PEP 235: Implement on every POSIX system, and clean up the C code for `import' In-Reply-To: <1478899111.69.0.0154952768919.issue28670@psf.upfronthosting.co.za> Message-ID: <1479309282.87.0.368658420269.issue28670@psf.upfronthosting.co.za> Nick Coghlan added the comment: We work closely with Linux distribution providers, and a number of us work *for* commercial Linux distributors (most notably Red Hat and Canonical). Linux distributions have already agreed that Python 2.7 is in maintenance mode, and already influence the process of backporting any Python 3 changes that they consider sufficiently valuable to their users. (For example, Red Hat has backported the SSL/TLS improvements to the system Python in RHEL 7 and to the Python 2.7 Software Collection after OpenStack developers at Rackspace convinced myself and others that the old behaviours were genuinely problematic) Thus, is you want to convince us that this is a bug that actually needs fixing rather than a new feature request, you need to come up with a convincing explanation for why no Linux distribution (whether community run or commercial) has seen fit to report it as a bug at any point in the past 15 years. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 10:22:23 2016 From: report at bugs.python.org (Kushal Das) Date: Wed, 16 Nov 2016 15:22:23 +0000 Subject: [issue28713] Recent tutorial for recent Python3 still uses IOError. In-Reply-To: <1479281842.16.0.362729785805.issue28713@psf.upfronthosting.co.za> Message-ID: <1479309743.19.0.00288711575138.issue28713@psf.upfronthosting.co.za> Kushal Das added the comment: This following one line change should fix this one. ---------- keywords: +patch nosy: +kushal.das Added file: http://bugs.python.org/file45504/issue28713.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 10:49:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Nov 2016 15:49:33 +0000 Subject: [issue28713] Recent tutorial for recent Python3 still uses IOError. In-Reply-To: <1479281842.16.0.362729785805.issue28713@psf.upfronthosting.co.za> Message-ID: <20161116154930.89451.65871.1D3EB9AD@psf.io> Roundup Robot added the comment: New changeset 3375c111d1ff by Kushal Das in branch '3.6': Closes #28713 uses OSError in the tutorial https://hg.python.org/cpython/rev/3375c111d1ff New changeset 15e5e476e4a1 by Kushal Das in branch 'default': Closes #28713 uses OSError in the tutorial https://hg.python.org/cpython/rev/15e5e476e4a1 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 11:10:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 16:10:17 +0000 Subject: [issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString In-Reply-To: <1479239405.55.0.31899621759.issue28701@psf.upfronthosting.co.za> Message-ID: <1479312617.59.0.110862623107.issue28701@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Following patch adds checks in debug mode that the right argument of _PyUnicode_EqualToASCIIString and _PyUnicode_EqualToASCIIId is ASCII-only string. ---------- Added file: http://bugs.python.org/file45505/_PyUnicode_EqualToASCII-runtime-check.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 11:11:14 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 16:11:14 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479312674.63.0.922187689117.issue28712@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 11:48:11 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 16 Nov 2016 16:48:11 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479314891.26.0.0235108698194.issue28712@psf.upfronthosting.co.za> Steve Dower added the comment: So is this a bug in the hardcoded encoding tables in Python? I briefly considered making them all use the OS functions, but then they'll be inconsistent with other platforms (where the tables should work fine). Do you have a proposed fix? That will help illustrate where the problem is. ---------- versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 11:54:33 2016 From: report at bugs.python.org (Michael Witten) Date: Wed, 16 Nov 2016 16:54:33 +0000 Subject: [issue28670] PEP 235: Implement on every POSIX system, and clean up the C code for `import' In-Reply-To: <1478899111.69.0.0154952768919.issue28670@psf.upfronthosting.co.za> Message-ID: <1479315273.86.0.337601572883.issue28670@psf.upfronthosting.co.za> Michael Witten added the comment: * Bugs, by their very nature, are often obscure; some of the worst in history have lain dormant, unseen, for years or perhaps even decades. Unsurprisingly, then, this bug is also a corner case that would be unknowingly triggered in practice only rarely; consequently, it is unsurprising that it has not been reported previously, despite the fact that the mistake is OBVIOUS in a retrospective (and literal!) reading of PEP 235, which is clearly naive in its view of the world of computing systems. * Furthermore, in any computing system that is sufficiently complex, there is usually a workaround for any particular bug, which thus diminishes the impetus to report the problem at all; this just compounds the obscurity of the bug. * The more obscure a bug, the less compelling the ratio of the reward to the solution effort, particularly when the objections are mired not in technical analysis, but rather in an incomplete understanding of the report, as well as perhaps some kind of political puffery. So, why bother even beginning a discussion of the issue? Indeed, this correspondence has proven to me (once again, unfortunately) that it's usually an utter waste of resources to attempt to solve problems purely for the benefit of others. Let the confused gnash their teeth, and let the clever hack their own way out of trouble. As long as my personal itch has been scratched in some way, that's good enough. * How is it that you did not perceive the irrelevance of [at least the rest of] your reply? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 11:55:20 2016 From: report at bugs.python.org (Mingye Wang) Date: Wed, 16 Nov 2016 16:55:20 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479315320.24.0.615289835742.issue28712@psf.upfronthosting.co.za> Mingye Wang added the comment: Yes, it's a table issue. My suggested fix is to replace them all with WindowsBestFit tables, where MS currently redirects https://msdn.microsoft.com/en-us/globalization/mt767590 visitors to. These old "WINDOWS" tables appear abandoned since long ago. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 12:00:36 2016 From: report at bugs.python.org (Mingye Wang) Date: Wed, 16 Nov 2016 17:00:36 +0000 Subject: [issue28343] Bad encoding alias cp936 -> gbk: euro sign In-Reply-To: <1475464291.36.0.0934021228231.issue28343@psf.upfronthosting.co.za> Message-ID: <1479315636.26.0.055713408433.issue28343@psf.upfronthosting.co.za> Changes by Mingye Wang : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 12:01:35 2016 From: report at bugs.python.org (Mingye Wang) Date: Wed, 16 Nov 2016 17:01:35 +0000 Subject: [issue28343] Bad encoding alias cp936 -> gbk: euro sign In-Reply-To: <1475464291.36.0.0934021228231.issue28343@psf.upfronthosting.co.za> Message-ID: <1479315695.0.0.0984316630996.issue28343@psf.upfronthosting.co.za> Mingye Wang added the comment: Update: the test script at issue28712 can be modified to show this issue too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 12:01:38 2016 From: report at bugs.python.org (Mingye Wang) Date: Wed, 16 Nov 2016 17:01:38 +0000 Subject: [issue28693] No HKSCS support in Windows cp950 In-Reply-To: <1479154148.6.0.43343383532.issue28693@psf.upfronthosting.co.za> Message-ID: <1479315698.59.0.041026120723.issue28693@psf.upfronthosting.co.za> Mingye Wang added the comment: Update: the test script at issue28712 can be modified to show this issue too. ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 12:03:32 2016 From: report at bugs.python.org (Mingye Wang) Date: Wed, 16 Nov 2016 17:03:32 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479315812.59.0.766740023821.issue28712@psf.upfronthosting.co.za> Mingye Wang added the comment: ... On the other hand, I am happy to use these Win32 functions if they are faster, but still the table should be made correct in the first place. (See also issue28343 (936) and issue28693 (950) for problems with DBCS Chinese code pages.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 12:40:03 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 16 Nov 2016 17:40:03 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479318003.38.0.614910010982.issue28712@psf.upfronthosting.co.za> Steve Dower added the comment: No idea which is faster, but the tables have better compatibility. However, I'm not sure that changing the tables in already released versions is a great idea, since it could "corrupt" programs without warning. Adding the release managers to weigh in - my gut feel is that targeted table fixes plus validation tests are okay for 3.6 if we hurry, but are probably not suitable for 2.7 or 3.5. ---------- nosy: +benjamin.peterson, larry, ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 12:46:27 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 17:46:27 +0000 Subject: [issue28715] Check result of PyUnicode_AsUTF8 Message-ID: <1479318387.76.0.271221021143.issue28715@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The function PyUnicode_AsUTF8() can fail, but not all callers check for error. Proposed patch adds missed checks. In some places the code is rewritten to not use PyUnicode_AsUTF8() at all. ---------- components: Extension Modules, Interpreter Core files: check-PyUnicode_AsUTF8.patch keywords: patch messages: 280972 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Check result of PyUnicode_AsUTF8 type: crash versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45506/check-PyUnicode_AsUTF8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 12:48:12 2016 From: report at bugs.python.org (Ned Deily) Date: Wed, 16 Nov 2016 17:48:12 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479318492.24.0.213393886674.issue28712@psf.upfronthosting.co.za> Ned Deily added the comment: I'm not qualified to offer a technical opinion on Windows matters like this so, for 3.6, I leave it to your discretion, Steve. If you do decide to push this change, please do so before 3.6.0b4 on Monday. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 12:53:56 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 17:53:56 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479318836.19.0.0192950143105.issue28712@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Codecs are strict by default in Python. Call MultiByteToWideChar() with the MB_ERR_INVALID_CHARS flag as Python does. You also could use _codecs.code_page_decode(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 12:56:03 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Nov 2016 17:56:03 +0000 Subject: [issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString In-Reply-To: <1479312617.59.0.110862623107.issue28701@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: _PyUnicode_EqualToASCII-runtime-check.diff LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 13:03:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Nov 2016 18:03:24 +0000 Subject: [issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString In-Reply-To: <1479239405.55.0.31899621759.issue28701@psf.upfronthosting.co.za> Message-ID: <20161116180321.89163.77603.29B82DF7@psf.io> Roundup Robot added the comment: New changeset 6dd22ed7140e by Serhiy Storchaka in branch '3.6': Issue #28701: _PyUnicode_EqualToASCIIId and _PyUnicode_EqualToASCIIString now https://hg.python.org/cpython/rev/6dd22ed7140e New changeset 44874b20e612 by Serhiy Storchaka in branch 'default': Issue #28701: _PyUnicode_EqualToASCIIId and _PyUnicode_EqualToASCIIString now https://hg.python.org/cpython/rev/44874b20e612 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 13:04:01 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 18:04:01 +0000 Subject: [issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString In-Reply-To: <1479239405.55.0.31899621759.issue28701@psf.upfronthosting.co.za> Message-ID: <1479319441.31.0.0673243255704.issue28701@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 13:06:28 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Wed, 16 Nov 2016 18:06:28 +0000 Subject: [issue28716] Fractions instantiation revisited Message-ID: <1479319587.68.0.845103759053.issue28716@psf.upfronthosting.co.za> New submission from Wolfgang Maier: I've spent a bit of time lately trying to optimize the instantiation of Fractions. This is related to Issue22464, but instead of focusing on constructing Fractions from ints, my attempts revolve around improving instantiation from strings, floats and decimals. I'm attaching a patch with all my changes for discussion, but here's an overview of what's in it: CHANGES TO INSTANTIATION FROM STRINGS: - isinstance checking for str is performed before the more expensive check for numbers.Rational (which has to go through abc) - instantiation from strings doesn't use a regex pattern anymore for parsing; this is faster in many cases (and never slower) than the current version - while reimplementing string parsing I added PEP 515 support (this is the only behavior change in the patch) combined this gives me the following performance changes for instantiation of Fractions from different arguments (profiled with 1,000,000 random inputs each): 'x/y'-type of strings: ---------------------- ncalls tottime percall cumtime percall filename:lineno(function) old: 1000000 12.162 0.000 27.778 0.000 fractions.py:84(__new__) new: 1000000 9.619 0.000 12.428 0.000 frc.py:68(__new__) scientific notation (e.g., '1.234E-7'): --------------------------------------- ncalls tottime percall cumtime percall filename:lineno(function) old: 1000000 18.209 0.000 37.341 0.000 fractions.py:84(__new__) new: 1000000 15.509 0.000 21.252 0.000 frc.py:68(__new__) integer strings (e.g. '123456'): -------------------------------- ncalls tottime percall cumtime percall filename:lineno(function) old: 1000000 11.272 0.000 26.201 0.000 fractions.py:84(__new__) new: 1000000 9.347 0.000 12.425 0.000 frc.py:68(__new__) from other Fractions (to test effect on instantiation of numbers.Rational): ncalls tottime percall cumtime percall filename:lineno(function) old: 1000000 4.708 0.000 10.093 0.000 fractions.py:84(__new__) new: 1000000 4.835 0.000 10.572 0.000 frc.py:68(__new__) from int subclass (as another numbers.Rational): ncalls tottime percall cumtime percall filename:lineno(function) old: 1000000 3.446 0.000 8.044 0.000 fractions.py:84(__new__) new: 1000000 3.795 0.000 8.836 0.000 frc.py:68(__new__) SUMMARY of this part ==================== + very significant speedup for instatiation from strings of different forms with (near) negligible effects on instantiation from numbers.Rational. + correct parsing of PEP 515-like number strings - possibly slower error bubbling with invalid input (untested) CHANGES TO INSTANTIATION FROM FLOAT AND DECIMAL: - no explicit check for float and decimal in standard constructor; instead, simply try to call as_integer_ratio as last resort (even after checking for numbers.Rational) - speed up alternate from_float and from_decimal constructor class methods by rearranging type checks and making use of _normalize flag - import decimal only on demand (when using from_decimal) Resulting performance changes: standard constructor with float: -------------------------------- ncalls tottime percall cumtime percall filename:lineno(function) old: 1000000 4.362 0.000 12.452 0.000 fractions.py:84(__new__) new: 1000000 6.693 0.000 16.020 0.000 frc.py:68(__new__) from_float: ----------- ncalls tottime percall cumtime percall filename:lineno(function) old: 1000000 3.146 0.000 17.769 0.000 fractions.py:193(from_float) new: 1000000 2.544 0.000 7.591 0.000 frc.py:205(from_float) standard constructor with decimal: -------------------------------- ncalls tottime percall cumtime percall filename:lineno(function) old: 1000000 4.672 0.000 20.795 0.000 fractions.py:84(__new__) new: 1000000 7.097 0.000 24.526 0.000 frc.py:68(__new__) from_decimal: ------------- ncalls tottime percall cumtime percall filename:lineno(function) old: 1000000 5.054 0.000 34.473 0.000 fractions.py:207(from_decimal) new: 1000000 2.942 0.000 16.013 0.000 frc.py:220(from_decimal) SUMMARY of this part: - standard constructor becomes a bit slower for floats and Decimals specialized class methods become a lot faster (for Decimal the benchmarks are based on _pydecimal - with the C implementation the percent differences would be even larger) - eliminates decimal from regularly imported modules - allows Fraction instantiation from duck-typing classes that provide as_integer_ratio I hope at least some of this is interesting. ---------- components: Library (Lib) files: fractions.patch keywords: patch messages: 280977 nosy: wolma priority: normal severity: normal status: open title: Fractions instantiation revisited type: behavior versions: Python 3.7 Added file: http://bugs.python.org/file45507/fractions.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 13:10:17 2016 From: report at bugs.python.org (Elliot Gorokhovsky) Date: Wed, 16 Nov 2016 18:10:17 +0000 Subject: [issue28685] Optimizing list.sort() by performing safety checks in advance In-Reply-To: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za> Message-ID: <1479319817.13.0.19715726113.issue28685@psf.upfronthosting.co.za> Elliot Gorokhovsky added the comment: So thanks for pointing out that perf has a --compare_to option: it turns out I had calculated the times wrong! Specifically, I had used (ref-dev)/ref while I should have used ref/dev which is what perf --compare_to uses. Anyway, the actual times are even more incredible than I could have imagined! First, here's my benchmark script: #!/bin/bash rm ref.json dev.json 2> /dev/null python-dev/python -m perf timeit -s "$1" "sorted(l)" --rigorous -o dev.json > /dev/null python-ref/python -m perf timeit -s "$1" "sorted(l)" --rigorous -o ref.json > /dev/null python-ref/python -m perf compare_to ref.json dev.json And here are the results: ./bench.sh "import random; l=[random.uniform(-1,1) for _ in range(0,100)]" Median +- std dev: [ref] 8.34 us +- 0.18 us -> [dev] 3.33 us +- 0.13 us: 2.50x faster So it's 150% faster! (i.e. 150% + 100% = 250%). 150% faster sorting for floats!!! If we make them tuples, it's even more incredible: Median +- std dev: [ref] 20.9 us +- 1.0 us -> [dev] 4.99 us +- 0.27 us: 4.19x faster 319% faster!!! And earlier, I had thought 75% was impressive... I mean, 319%!!! And again, this is an application that is directly useful: DEAP spends a great deal of time sorting tuples of floats, this will make their EAs run a lot faster. "import random; l=[str(random.uniform(-1,1)) for _ in range(0,100)]" Median +- std dev: [ref] 15.7 us +- 0.9 us -> [dev] 9.24 us +- 0.52 us: 1.70x faster "import random; l=[int(random.uniform(-1,1)*2**15) for _ in range(0,100)]" Median +- std dev: [ref] 8.59 us +- 0.19 us -> [dev] 4.35 us +- 0.13 us: 1.98x faster ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 13:12:38 2016 From: report at bugs.python.org (Elliot Gorokhovsky) Date: Wed, 16 Nov 2016 18:12:38 +0000 Subject: [issue28685] Optimizing list.sort() by performing safety checks in advance In-Reply-To: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za> Message-ID: <1479319958.32.0.636926777238.issue28685@psf.upfronthosting.co.za> Changes by Elliot Gorokhovsky : Added file: http://bugs.python.org/file45508/fastsort.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 13:14:50 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 16 Nov 2016 18:14:50 +0000 Subject: [issue28670] PEP 235: Implement on every POSIX system, and clean up the C code for `import' In-Reply-To: <1478899111.69.0.0154952768919.issue28670@psf.upfronthosting.co.za> Message-ID: <1479320090.17.0.109066527227.issue28670@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 13:15:47 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 18:15:47 +0000 Subject: [issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_EqualToASCIIId In-Reply-To: <1399412124.32.0.206189886441.issue21449@psf.upfronthosting.co.za> Message-ID: <1479320147.1.0.701155542445.issue21449@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- title: Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual -> Replace _PyUnicode_CompareWithId with _PyUnicode_EqualToASCIIId _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 13:50:17 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 16 Nov 2016 18:50:17 +0000 Subject: [issue28716] Fractions instantiation revisited In-Reply-To: <1479319587.68.0.845103759053.issue28716@psf.upfronthosting.co.za> Message-ID: <1479322217.88.0.969196817851.issue28716@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 14:18:00 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 16 Nov 2016 19:18:00 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479323880.69.0.361652571743.issue28712@psf.upfronthosting.co.za> Eryk Sun added the comment: Serhiy, single-byte codepages map every byte value, even if it's just to a Unicode C1 control code [1]. For example: import ctypes kernel32 = ctypes.WinDLL('kernel32', use_last_error=True) MB_ERR_INVALID_CHARS = 0x00000008 def mbtwc_errcheck(result, func, args): if not result and args[-1]: raise ctypes.WinError(ctypes.get_last_error()) return args kernel32.MultiByteToWideChar.errcheck = mbtwc_errcheck def decode(codepage, data, strict=True): flags = MB_ERR_INVALID_CHARS if strict else 0 n = kernel32.MultiByteToWideChar(codepage, flags, data, len(data), None, 0) buf = (ctypes.c_wchar * n)() kernel32.MultiByteToWideChar(codepage, flags, data, len(data), buf, n) return buf.value codepages = [437, 874] + list(range(1250, 1259)) for cp in codepages: print('cp%d:' % cp, ascii(decode(cp, b'\x81\x8d'))) Output: cp437: '\xfc\xec' cp874: '\x81\x8d' cp1250: '\x81\u0164' cp1251: '\u0403\u040c' cp1252: '\x81\x8d' cp1253: '\x81\x8d' cp1254: '\x81\x8d' cp1255: '\x81\x8d' cp1256: '\u067e\u0686' cp1257: '\x81\xa8' cp1258: '\x81\x8d' [1]: https://en.wikipedia.org/wiki/C0_and_C1_control_codes ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 14:37:39 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 19:37:39 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479325059.13.0.757625139667.issue28712@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Eryk. Could you please run following script and attach the output? import codecs codepages = [424, 856, 857, 864, 869, 874, 932, 949, 950, 1250, 1251, 1252, 1253, 1254, 1255, 1257, 1258] for cp in codepages: table = [] for i in range(256): try: c = codecs.code_page_decode(cp, bytes([i]), None, True) except Exception: c = None table.append(c) print(cp, ascii(table)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 14:55:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 19:55:54 +0000 Subject: [issue28716] Fractions instantiation revisited In-Reply-To: <1479319587.68.0.845103759053.issue28716@psf.upfronthosting.co.za> Message-ID: <1479326154.39.0.890293098372.issue28716@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Profiling give you only approximate results. In normal execution the effect of your changes can be opposite. Could you please provide benchmarks without using profiling? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 14:57:55 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 19:57:55 +0000 Subject: [issue28715] Check result of PyUnicode_AsUTF8 In-Reply-To: <1479318387.76.0.271221021143.issue28715@psf.upfronthosting.co.za> Message-ID: <1479326275.23.0.0606277796015.issue28715@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: _PyUnicode_AsString is just an outdated alias to PyUnicode_AsUTF8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 15:02:04 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 16 Nov 2016 20:02:04 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479326524.58.0.0684900587304.issue28712@psf.upfronthosting.co.za> Eryk Sun added the comment: How about just the ASCII repr of the 256 decoded characters in CSV? I don't think the list of 2-tuple results is useful. For these single-byte codepages it's always 1 byte consumed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 15:10:59 2016 From: report at bugs.python.org (William McIlhagga) Date: Wed, 16 Nov 2016 20:10:59 +0000 Subject: [issue28717] rounding error in % operator Message-ID: <1479327059.34.0.959568530383.issue28717@psf.upfronthosting.co.za> New submission from William McIlhagga: '%.1f' % 0.25 yields the string '0.2' '%.1f' % 0.75 yields the string '0.8' This is wrong. ---------- messages: 280984 nosy: William McIlhagga priority: normal severity: normal status: open title: rounding error in % operator type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 15:12:07 2016 From: report at bugs.python.org (Jim Nasby) Date: Wed, 16 Nov 2016 20:12:07 +0000 Subject: [issue28718] '*' matches entire path in fnmatch.translate Message-ID: <1479327127.15.0.931047394142.issue28718@psf.upfronthosting.co.za> New submission from Jim Nasby: A '*' in fnmatch.translate is converted into '.*', which will greedily match directory separators. This doesn't match shell behavior, which is that * will only match file names: decibel at decina:[14:07]~$ls ~/tmp/*/1|head ls: /Users/decibel/tmp/*/1: No such file or directory decibel at decina:[14:07]~$ls ~/tmp/d*/base/1|head 112 >From a posix standpoint, this would easily be fixed by using '[^/]*' instead of '.*'. I'm not sure how to make this work cross-platform though. It's worth noting that some programs (rsync, git) support **, which would correctly translate to '.*'. ---------- components: Library (Lib) messages: 280985 nosy: Jim Nasby priority: normal severity: normal status: open title: '*' matches entire path in fnmatch.translate _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 15:19:04 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 20:19:04 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479327544.23.0.582667518828.issue28712@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This would be helpful too if every byte is decoded to exactly 1 character. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 15:29:23 2016 From: report at bugs.python.org (Elliot Gorokhovsky) Date: Wed, 16 Nov 2016 20:29:23 +0000 Subject: [issue28685] Optimizing list.sort() by performing safety checks in advance In-Reply-To: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za> Message-ID: <1479328163.25.0.831004644083.issue28685@psf.upfronthosting.co.za> Elliot Gorokhovsky added the comment: Oh wait... uh... never mind... we want "faster" to refer to total time taken, so 1-def/ref is indeed the correct formula. I just got confused because perf outputs ref/dev, but that doesn't make sense for percents. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 15:37:32 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 16 Nov 2016 20:37:32 +0000 Subject: [issue26072] pdb fails to access variables closed over In-Reply-To: <1452402984.12.0.000738362264887.issue26072@psf.upfronthosting.co.za> Message-ID: <1479328652.27.0.905848453309.issue26072@psf.upfronthosting.co.za> Xavier de Gaye added the comment: This patch fixes the problems raised in this issue and allows accessing the globals at the Pdb prompt with the globals() dictionary: (Pdb) list 1 y = 2 2 3 def f(): 4 y = 9 5 z = 10 6 -> import pdb; pdb.set_trace(); 7 f() [EOF] (Pdb) globals()['y'] 2 ---------- Added file: http://bugs.python.org/file45509/free_variables.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 15:38:18 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 16 Nov 2016 20:38:18 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479328698.45.0.0276153057539.issue28712@psf.upfronthosting.co.za> Eryk Sun added the comment: I don't think the 2nd tuple element is useful when decoding a single byte. It either works or it doesn't, such as failing for non-ASCII bytes with multibyte codepages such as 932 and 950. I'm attaching the output from the following, which you should be able to open in a spreadsheet: import codecs codepages = [424, 856, 857, 864, 869, 874, 932, 949, 950, 1250, 1251, 1252, 1253, 1254, 1255, 1257, 1258] for cp in codepages: table = [] for i in range(256): try: c = codecs.code_page_decode(cp, bytes([i]), None, True) c = ascii(c[0]) except Exception: c = None table.append(c) print(cp, *table, sep=',') ---------- Added file: http://bugs.python.org/file45510/codepage_table.csv _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 15:52:11 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 16 Nov 2016 20:52:11 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479329531.04.0.659652347026.issue28712@psf.upfronthosting.co.za> Changes by Eryk Sun : Removed file: http://bugs.python.org/file45510/codepage_table.csv _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 16:06:46 2016 From: report at bugs.python.org (Eryk Sun) Date: Wed, 16 Nov 2016 21:06:46 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479330406.25.0.815809568963.issue28712@psf.upfronthosting.co.za> Eryk Sun added the comment: I rewrote it using the csv module since I can't remember the escaping rules. ---------- Added file: http://bugs.python.org/file45511/codepage_table.csv _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 16:12:20 2016 From: report at bugs.python.org (Michael Felt) Date: Wed, 16 Nov 2016 21:12:20 +0000 Subject: [issue18235] _sysconfigdata.py wrong on AIX installations In-Reply-To: <1371429201.94.0.372851990361.issue18235@psf.upfronthosting.co.za> Message-ID: <1479330740.37.0.49393175078.issue18235@psf.upfronthosting.co.za> Michael Felt added the comment: As this is the issue still open with regard to issues with ld_so_aix... The current release Python3-3.5.2 does not include ld_so_aix in the "make install DESTDIR=xxx output ("make install" also neglects to install ld_so_aix) Installation Summary -------------------- Name Level Part Event Result ------------------------------------------------------------------------------- aixtools.python3.rte 3.5.2.0 USR APPLY SUCCESS root at x064:[/data/prj/python3/python3-3.5.2]find /opt -name ld_so_aix root at x064:[/data/prj/python3/python3-3.5.2]grep ld_so_aix /opt/lib/py*/_sys*.py 'BLDSHARED': '/opt/lib/python3.5/config/ld_so_aix xlc_r ' 'LDCXXSHARED': '/opt/lib/python3.5/config/ld_so_aix xlc_r ' 'LDSHARED': '/opt/lib/python3.5/config/ld_so_aix xlc_r ' So, the last two variables are correct - BLDSHARED is not correct in _sysconfigdata.py because the file does not exist during the build process. However, the build succeeds, so apparently this value for BLDSHARED is not used during the build. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 16:16:06 2016 From: report at bugs.python.org (Bert JW Regeer) Date: Wed, 16 Nov 2016 21:16:06 +0000 Subject: [issue28719] zipfile increase in size Message-ID: <1479330966.86.0.764348227568.issue28719@psf.upfronthosting.co.za> New submission from Bert JW Regeer: I am the current maintainer of WebOb, and noticed that on Python 3.6 and 3.7 I noticed that a test started failing. Granted, the test is checking the size of the file created and it is not the brightest idea in a test, but it's been stable since Python 2.5... https://travis-ci.org/Pylons/webob/jobs/176505096#L224 shows the failure. _________________________ test_response_file_body_tell _________________________ def test_response_file_body_tell(): import zipfile from webob.response import ResponseBodyFile rbo = ResponseBodyFile(Response()) assert rbo.tell() == 0 writer = zipfile.ZipFile(rbo, 'w') writer.writestr('zinfo_or_arcname', b'foo') writer.close() > assert rbo.tell() == 133 E assert 145 == 133 E + where 145 = >>() E + where >> = >.tell tests/test_response.py:608: AssertionError I am not sure that this is necessarily a bug, but it would be good to know why files are no longer generated the same way. ---------- messages: 280992 nosy: X-Istence priority: normal severity: normal status: open title: zipfile increase in size type: resource usage versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 16:30:06 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 16 Nov 2016 21:30:06 +0000 Subject: [issue28720] Add collections.abc.AsyncGenerator Message-ID: <1479331805.85.0.746323979181.issue28720@psf.upfronthosting.co.za> New submission from Yury Selivanov: This patch adds collections.abc.AsyncGenerator (closely modelled after collections.abc.Generator). Ned, is it OK if this goes into 3.6? This is something I completely forgot to do as part of PEP 525. This ABC is needed for asynchronous generators compiled with Cython and async-generator-like objects/wrappers. I'll update the PEP if we can push this to 3.6. ---------- assignee: yselivanov components: Library (Lib) files: agen_abc.patch keywords: patch messages: 280993 nosy: gvanrossum, ned.deily, yselivanov priority: release blocker severity: normal stage: patch review status: open title: Add collections.abc.AsyncGenerator type: enhancement versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45512/agen_abc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 16:31:51 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 16 Nov 2016 21:31:51 +0000 Subject: [issue28720] Add collections.abc.AsyncGenerator In-Reply-To: <1479331805.85.0.746323979181.issue28720@psf.upfronthosting.co.za> Message-ID: <1479331911.52.0.267797069544.issue28720@psf.upfronthosting.co.za> Changes by Yury Selivanov : Removed file: http://bugs.python.org/file45512/agen_abc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 16:32:02 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 16 Nov 2016 21:32:02 +0000 Subject: [issue28720] Add collections.abc.AsyncGenerator In-Reply-To: <1479331805.85.0.746323979181.issue28720@psf.upfronthosting.co.za> Message-ID: <1479331922.0.0.0730047626808.issue28720@psf.upfronthosting.co.za> Changes by Yury Selivanov : Added file: http://bugs.python.org/file45513/agen_abc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 16:37:10 2016 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 16 Nov 2016 21:37:10 +0000 Subject: [issue28717] rounding error in % operator In-Reply-To: <1479327059.34.0.959568530383.issue28717@psf.upfronthosting.co.za> Message-ID: <1479332230.73.0.669477266522.issue28717@psf.upfronthosting.co.za> Mark Dickinson added the comment: You don't say why you think this behaviour is wrong, or what you'd expect to see instead. Nevertheless, this behaviour is by design: the code `'%.1f' % x` rounds `x` to the nearest one-digit-after-the-point decimal number, and returns a string representation of that number. In the case `x=0.25`, there is no single nearest number: `0.2` and `0.3` are equally close to `0.25`, so a choice between the two has to be made. In keeping with many other languages, Python chooses the value with even last digit. (The original behaviour is inherited from the typical behaviour of the standard library strtod or dtoa functions in C.) ---------- nosy: +mark.dickinson resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 16:43:11 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Wed, 16 Nov 2016 21:43:11 +0000 Subject: [issue28716] Fractions instantiation revisited In-Reply-To: <1479319587.68.0.845103759053.issue28716@psf.upfronthosting.co.za> Message-ID: <1479332591.35.0.365524453279.issue28716@psf.upfronthosting.co.za> Wolfgang Maier added the comment: sure, I just happened to have the profiling available since I used it to optimize things. Here's similar microbenchmarks using perf: STRINGS ======= $ python -m perf timeit -s "from fractions import Fraction" "Fraction('1.23456e-7')" ..................... Median +- std dev: 17.0 us +- 0.3 us $ python -m perf timeit -s "from frc import Fraction" "Fraction('1.23456e-7')" ..................... Median +- std dev: 8.95 us +- 0.16 us $ python -m perf timeit -s "from fractions import Fraction" "Fraction('234/567')" ..................... Median +- std dev: 12.6 us +- 0.1 us $ python -m perf timeit -s "from frc import Fraction" "Fraction('234/567')" ..................... Median +- std dev: 5.45 us +- 0.16 us $ python -m perf timeit -s "from fractions import Fraction" "Fraction('123456')" ..................... Median +- std dev: 12.4 us +- 0.6 us $ python -m perf timeit -s "from frc import Fraction" "Fraction('123456')" ..................... Median +- std dev: 5.77 us +- 0.12 us $ python -m perf timeit -s "from fractions import Fraction; f=Fraction(3/4)" "Fraction(f)" ..................... Median +- std dev: 4.36 us +- 0.06 us $ python -m perf timeit -s "from frc import Fraction; f=Fraction(3/4)" "Fraction(f)" ..................... Median +- std dev: 4.59 us +- 0.07 us $ python -m perf timeit -s "from fractions import Fraction" -s "class myInt(int): pass" -s "i=myInt(123456)" "Fraction(i)" ..................... Median +- std dev: 4.04 us +- 0.07 us $ python -m perf timeit -s "from frc import Fraction" -s "class myInt(int): pass" -s "i=myInt(123456)" "Fraction(i)" ..................... Median +- std dev: 4.27 us +- 0.06 us FLOATS ====== $ python -m perf timeit -s "from fractions import Fraction" "Fraction(1.23456e-7)" ..................... Median +- std dev: 6.30 us +- 0.28 us $ python -m perf timeit -s "from frc import Fraction" "Fraction(1.23456e-7)" ..................... Median +- std dev: 8.64 us +- 0.13 us $ python -m perf timeit -s "from fractions import Fraction" "Fraction.from_float(1.23456e-7)" ..................... Median +- std dev: 8.68 us +- 0.14 us $ python -m perf timeit -s "from frc import Fraction" "Fraction.from_float(1.23456e-7)" ..................... Median +- std dev: 3.37 us +- 0.17 us DECIMALS (using C implementation this time) =========================================== $ python -m perf timeit -s "from fractions import Fraction; from decimal import Decimal; d=Decimal('123456')" "Fraction(d)"..................... Median +- std dev: 6.95 us +- 0.21 us $ python -m perf timeit -s "from frc import Fraction; from decimal import Decimal; d=Decimal('123456')" "Fraction(d)" ..................... Median +- std dev: 8.43 us +- 0.17 us $ python -m perf timeit -s "from fractions import Fraction; from decimal import Decimal; d=Decimal('123456')" "Fraction.from_decimal(d)" ..................... Median +- std dev: 11.6 us +- 0.2 us $ python -m perf timeit -s "from frc import Fraction; from decimal import Decimal; d=Decimal('123456')" "Fraction.from_decimal(d)" ..................... Median +- std dev: 4.14 us +- 0.28 us ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 16:53:01 2016 From: report at bugs.python.org (William McIlhagga) Date: Wed, 16 Nov 2016 21:53:01 +0000 Subject: [issue28717] rounding error in % operator In-Reply-To: <1479332230.73.0.669477266522.issue28717@psf.upfronthosting.co.za> Message-ID: William McIlhagga added the comment: OK, not wrong, just unexpected. Is this behaviour documented? Or are you just expected to know what C does? On 16 November 2016 at 21:37, Mark Dickinson wrote: > > Mark Dickinson added the comment: > > You don't say why you think this behaviour is wrong, or what you'd expect > to see instead. > > Nevertheless, this behaviour is by design: the code `'%.1f' % x` rounds > `x` to the nearest one-digit-after-the-point decimal number, and returns a > string representation of that number. In the case `x=0.25`, there is no > single nearest number: `0.2` and `0.3` are equally close to `0.25`, so a > choice between the two has to be made. In keeping with many other > languages, Python chooses the value with even last digit. (The original > behaviour is inherited from the typical behaviour of the standard library > strtod or dtoa functions in C.) > > ---------- > nosy: +mark.dickinson > resolution: -> not a bug > stage: -> resolved > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ > -- Dr. William McIlhagga Bradford School of Optometry & Vision Science, Bradford University Great Horton Road Bradford BD7 1DP UK Room G23, Richmond tel. (44) (1274) 235957 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 17:03:05 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 16 Nov 2016 22:03:05 +0000 Subject: [issue28716] Fractions instantiation revisited In-Reply-To: <1479319587.68.0.845103759053.issue28716@psf.upfronthosting.co.za> Message-ID: <1479333785.33.0.263328832488.issue28716@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Might it make sense to make instantiation from numbers.Rational duck typing based as well? Just try to get the numerator and denominator attributes, on AttributeError, skip it and move on. Unless there is some concern that a non-Rational type might have both attributes and not intend them to mean it's a Rational? ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 17:06:04 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 16 Nov 2016 22:06:04 +0000 Subject: [issue28716] Fractions instantiation revisited In-Reply-To: <1479319587.68.0.845103759053.issue28716@psf.upfronthosting.co.za> Message-ID: <1479333964.01.0.846526815219.issue28716@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Similarly, type checking for int might be replaced with calling operator.index on the input and handling the TypeError; that way, anything that has declared itself logically int-like is handled without explicit type checking at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 17:20:31 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Wed, 16 Nov 2016 22:20:31 +0000 Subject: [issue28716] Fractions instantiation revisited In-Reply-To: <1479319587.68.0.845103759053.issue28716@psf.upfronthosting.co.za> Message-ID: <1479334831.31.0.809354324034.issue28716@psf.upfronthosting.co.za> Wolfgang Maier added the comment: No, I don't think the numeric tower ABC should be replaced by duck-typing. One of the very reasons the fractions module exists is that it showcases how to use the numeric tower. If you want a class to be picked up as a Rational it should be registered as such. Pretty much the same goes for integer-like things. The direct type check for ints only exists to speed up the most obvious case, but anything integer-like should be registered as a numbers.Integral and it will just work with fractions. Beautiful stuff! This is not the case for as_integer_ratio because that method is not defined in the numeric tower and this is why I think duck-typing could be of interest here (I'm not sure though whether its worth the somewhat decreased performance). My reasoning is that the standard constructor is anyway slower for floats and ints than the specialized classmethods for the two so people who really care about speed here (probably not too many) can just use the classmethods. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 17:23:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 22:23:20 +0000 Subject: [issue28719] zipfile increase in size In-Reply-To: <1479330966.86.0.764348227568.issue28719@psf.upfronthosting.co.za> Message-ID: <1479335000.34.0.412306605966.issue28719@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you get a dump of rbo data? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 17:30:25 2016 From: report at bugs.python.org (Bert JW Regeer) Date: Wed, 16 Nov 2016 22:30:25 +0000 Subject: [issue28719] zipfile increase in size In-Reply-To: <1479330966.86.0.764348227568.issue28719@psf.upfronthosting.co.za> Message-ID: <1479335425.68.0.526282254835.issue28719@psf.upfronthosting.co.za> Bert JW Regeer added the comment: It's literally the string written: writer.writestr('zinfo_or_arcname', b'foo') rbo in this case is a simple file like object. I can get dumps from Python 3.5 and Python 3.6 if necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 17:30:32 2016 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 16 Nov 2016 22:30:32 +0000 Subject: [issue28717] rounding error in % operator In-Reply-To: <1479327059.34.0.959568530383.issue28717@psf.upfronthosting.co.za> Message-ID: <1479335432.41.0.585172763819.issue28717@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Is this behaviour documented? Or are you just expected to know what C does? Indeed, it's not as well documented as it should be. I think that's partly for historical reasons: before Python 2.7, Python's % formatting more-or-less delegated directly to the underlying C sprintf library function, and so just inherited whatever the behaviour of that function happened to be on the target operating system. Because the C standard doesn't make guarantees about the behaviour of %f for ties, Python wasn't in a position to do so either. But that excuse doesn't work any more with Python 2.7 and Python 3.x, where on most (but still not all) platforms, we're consistently rounding results using the usual round-ties-to-even rounding mode. There's a currently open issue (#17259) to improve the documentation here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 17:31:52 2016 From: report at bugs.python.org (Ned Deily) Date: Wed, 16 Nov 2016 22:31:52 +0000 Subject: [issue28720] Add collections.abc.AsyncGenerator In-Reply-To: <1479331805.85.0.746323979181.issue28720@psf.upfronthosting.co.za> Message-ID: <1479335512.72.0.671090988991.issue28720@psf.upfronthosting.co.za> Ned Deily added the comment: OK for 3.6.0b4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 17:45:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Nov 2016 22:45:17 +0000 Subject: [issue28719] zipfile increase in size In-Reply-To: <1479330966.86.0.764348227568.issue28719@psf.upfronthosting.co.za> Message-ID: <1479336317.58.0.416811966655.issue28719@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Please make a dump. It should include not just literally the string written, but headers and other special fields. I tried with rbo = io.BytesIO(), and get rbo.tell() == 133. Should be a difference between io.BytesIO and ResponseBodyFile. Maybe ResponseBodyFile is not seekable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 17:50:03 2016 From: report at bugs.python.org (Patrick Lehmann) Date: Wed, 16 Nov 2016 22:50:03 +0000 Subject: [issue28710] Sphinx incompatible markup in configparser.ConfigParser. In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za> Message-ID: <1479336603.01.0.694269379468.issue28710@psf.upfronthosting.co.za> Patrick Lehmann added the comment: How can I supply a fix? I have a branch with lots of fixes. https://github.com/Paebbels/cpython/tree/paebbels/issue-28710?ts=2 Why don't you accept pull requests via GitHub? Kind regards Patrick ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 17:58:14 2016 From: report at bugs.python.org (Bert JW Regeer) Date: Wed, 16 Nov 2016 22:58:14 +0000 Subject: [issue28719] zipfile increase in size In-Reply-To: <1479330966.86.0.764348227568.issue28719@psf.upfronthosting.co.za> Message-ID: <1479337094.15.0.576282169879.issue28719@psf.upfronthosting.co.za> Bert JW Regeer added the comment: Here's a dump from Python 3.6: b'PK\x03\x04\x14\x00\x08\x00\x00\x00\xc0~pI\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00\x00zinfo_or_arcnamefoo!es\x8c\x03\x00\x00\x00\x03\x00\x00\x00PK\x01\x02\x14\x03\x14\x00\x08\x00\x00\x00\xc0~pI!es\x8c\x03\x00\x00\x00\x03\x00\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x80\x01\x00\x00\x00\x00zinfo_or_arcnamePK\x05\x06\x00\x00\x00\x00\x01\x00\x01\x00>\x00\x00\x00=\x00\x00\x00\x00\x00' You are correct that ResponseBodyFile does not have a seek() method and is not seekable. Adding seek() to ResponseBodyFile might be a little more complicated... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 18:00:50 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 16 Nov 2016 23:00:50 +0000 Subject: [issue28710] Sphinx incompatible markup in configparser.ConfigParser. In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za> Message-ID: <1479337250.97.0.953010738142.issue28710@psf.upfronthosting.co.za> R. David Murray added the comment: We will accept github pull requests in the future (the transition is underway). For now, you can create a diff file (using hg diff by preference, but git diff will work) and uploaded it to the issue. For this issue, please only upload the docstring changes. For other enhancement suggestions, open separate issues. (This would be true even if we were accepting pull requests). The existing docstring markup is probably a remnant of the days when the documentation was written in LaTeX. Lukasz Langa is the current maintainer of this module. ---------- nosy: +lukasz.langa, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 18:12:03 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 16 Nov 2016 23:12:03 +0000 Subject: [issue28721] Fix asynchronous generators athrow() and aclose() to handle StopAsyncIteration Message-ID: <1479337923.66.0.886081078513.issue28721@psf.upfronthosting.co.za> New submission from Yury Selivanov: 1. aclose() should not propagate StopAsyncIteration: async def agen(): try: yield except: pass gen = agen() await agen.asend(None) await agen.aclose() # <- this shouldn't raise StopAsyncIteration 2. athrow() should propagate StopAsyncIteration when the exception was swallowed by the generator and it returned: async def agen(): try: yield except: pass gen = agen() await agen.asend(None) await agen.athrow(ValueError) # <- this should raise StopAsyncIteration ---------- assignee: yselivanov components: Interpreter Core files: agen.patch keywords: patch messages: 281008 nosy: ned.deily, yselivanov priority: release blocker severity: normal stage: commit review status: open title: Fix asynchronous generators athrow() and aclose() to handle StopAsyncIteration type: behavior versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45514/agen.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 18:16:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Nov 2016 23:16:56 +0000 Subject: [issue28721] Fix asynchronous generators athrow() and aclose() to handle StopAsyncIteration In-Reply-To: <1479337923.66.0.886081078513.issue28721@psf.upfronthosting.co.za> Message-ID: <20161116231647.11902.41962.B1CE8BAF@psf.io> Roundup Robot added the comment: New changeset 0f12a1d3a737 by Yury Selivanov in branch '3.6': Issue #28721: Fix asynchronous generators aclose() and athrow() https://hg.python.org/cpython/rev/0f12a1d3a737 New changeset 22cd78026ad1 by Yury Selivanov in branch 'default': Merge 3.6 (issue #28721) https://hg.python.org/cpython/rev/22cd78026ad1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 18:23:34 2016 From: report at bugs.python.org (Patrick Lehmann) Date: Wed, 16 Nov 2016 23:23:34 +0000 Subject: [issue28710] Sphinx incompatible markup in configparser.ConfigParser. In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za> Message-ID: <1479338614.44.0.635081562082.issue28710@psf.upfronthosting.co.za> Patrick Lehmann added the comment: Here is the patch file created with: PS> git diff > docstring_markup.patch This patchfile effects all files with this markup in the CPython repository. Kind regards Patrick ---------- keywords: +patch Added file: http://bugs.python.org/file45515/docstring_markup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 18:23:39 2016 From: report at bugs.python.org (William McIlhagga) Date: Wed, 16 Nov 2016 23:23:39 +0000 Subject: [issue28717] rounding error in % operator In-Reply-To: <1479335432.41.0.585172763819.issue28717@psf.upfronthosting.co.za> Message-ID: William McIlhagga added the comment: Thanks, maybe I should get off my ass and contribute to the documentation then ... On 16 November 2016 at 22:30, Mark Dickinson wrote: > > Mark Dickinson added the comment: > > > Is this behaviour documented? Or are you just expected to know what C > does? > > Indeed, it's not as well documented as it should be. I think that's partly > for historical reasons: before Python 2.7, Python's % formatting > more-or-less delegated directly to the underlying C sprintf library > function, and so just inherited whatever the behaviour of that function > happened to be on the target operating system. Because the C standard > doesn't make guarantees about the behaviour of %f for ties, Python wasn't > in a position to do so either. > > But that excuse doesn't work any more with Python 2.7 and Python 3.x, > where on most (but still not all) platforms, we're consistently rounding > results using the usual round-ties-to-even rounding mode. > > There's a currently open issue (#17259) to improve the documentation here. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > -- Dr. William McIlhagga Bradford School of Optometry & Vision Science, Bradford University Great Horton Road Bradford BD7 1DP UK Room G23, Richmond tel. (44) (1274) 235957 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 18:25:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Nov 2016 23:25:56 +0000 Subject: [issue28720] Add collections.abc.AsyncGenerator In-Reply-To: <1479331805.85.0.746323979181.issue28720@psf.upfronthosting.co.za> Message-ID: <20161116232553.93220.56133.F1BC7F53@psf.io> Roundup Robot added the comment: New changeset ae1dba7e7d04 by Yury Selivanov in branch '3.6': Issue #28720: Add collections.abc.AsyncGenerator. https://hg.python.org/cpython/rev/ae1dba7e7d04 New changeset fb9c8fdef3ec by Yury Selivanov in branch 'default': Merge 3.6 (issue #28720) https://hg.python.org/cpython/rev/fb9c8fdef3ec ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 18:26:07 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 16 Nov 2016 23:26:07 +0000 Subject: [issue28720] Add collections.abc.AsyncGenerator In-Reply-To: <1479331805.85.0.746323979181.issue28720@psf.upfronthosting.co.za> Message-ID: <1479338767.67.0.0125951212873.issue28720@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 18:26:32 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 16 Nov 2016 23:26:32 +0000 Subject: [issue28720] Add collections.abc.AsyncGenerator In-Reply-To: <1479331805.85.0.746323979181.issue28720@psf.upfronthosting.co.za> Message-ID: <1479338792.03.0.0456031633561.issue28720@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks Ned. I went ahead and committed the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 18:26:54 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 16 Nov 2016 23:26:54 +0000 Subject: [issue28721] Fix asynchronous generators athrow() and aclose() to handle StopAsyncIteration In-Reply-To: <1479337923.66.0.886081078513.issue28721@psf.upfronthosting.co.za> Message-ID: <1479338814.89.0.108799654088.issue28721@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 19:18:07 2016 From: report at bugs.python.org (Mingye Wang) Date: Thu, 17 Nov 2016 00:18:07 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479341886.99.0.999203666007.issue28712@psf.upfronthosting.co.za> Mingye Wang added the comment: > Codecs are strict by default in Python. Call MultiByteToWideChar() with the MB_ERR_INVALID_CHARS flag as Python does. Great catch. Without MB_ERR_INVALID_CHARS or WC_NO_BEST_FIT_CHARS Windows would perform the "best fit" behavior described in the BestFit files, which is not marked explicitly (they didn't add '<< Best Fit Mapping' like in the readme) in these files and requires checking for existence of reverse mapping[1]. When MB_ERR_INVALID_CHARS is set, Windows would perform a strict check. [2]: http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/readme.txt By the way, will there be a 'mbcsbestfitreplace' error handler on Windows to invoke "best fit" behavior? It might be useful for interoperating with common Windows programs and users. (Implementation for other platforms can be constructed from WindowsBestFit charts, but it might be too large relative to its usefulness.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 20:19:41 2016 From: report at bugs.python.org (Rajiv Bakulesh Shah) Date: Thu, 17 Nov 2016 01:19:41 +0000 Subject: [issue28722] doctest example exit status Message-ID: <1479345580.78.0.277825169146.issue28722@psf.upfronthosting.co.za> New submission from Rajiv Bakulesh Shah: It might be nice if the doctest example set the appropriate exit status. Apologies if this is beyond the scope of the example, but I thought it might be good practice. Here is the file: https://github.com/python/cpython/blob/master/Doc/library/doctest.rst Here is the example as written: if __name__ == "__main__": import doctest doctest.testmod() Here is my proposal: if __name__ == '__main__': import doctest import sys results = doctest.testmod() sys.exit(bool(results.failed)) I'm happy to fork the repo and submit a PR, if that makes things easier. I'm not familiar with the protocol here. Thanks for the great work! ---------- assignee: docs at python components: Documentation messages: 281015 nosy: Brainix, docs at python priority: normal severity: normal status: open title: doctest example exit status versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 20:50:55 2016 From: report at bugs.python.org (Chun-Yu Tseng) Date: Thu, 17 Nov 2016 01:50:55 +0000 Subject: [issue26072] pdb fails to access variables closed over In-Reply-To: <1452402984.12.0.000738362264887.issue26072@psf.upfronthosting.co.za> Message-ID: <1479347455.13.0.570600968687.issue26072@psf.upfronthosting.co.za> Chun-Yu Tseng added the comment: Your solution is quite neat. But it still misses use cases of the `global` statement: 1 y = 2 2 3 def f(): 4 y = 9 5 -> import pdb; pdb.set_trace(); 6 7 f() (Pdb) global y; y 9 (Pdb) global y; y += 1; y 10 (Pdb) globals()['y'] 2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 21:00:14 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 17 Nov 2016 02:00:14 +0000 Subject: [issue28718] '*' matches entire path in fnmatch.translate In-Reply-To: <1479327127.15.0.931047394142.issue28718@psf.upfronthosting.co.za> Message-ID: <1479348014.96.0.0081044967134.issue28718@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Presumably something like: r'(?:' + r'|'.join({re.escape(os.path.sep), re.escape(os.path.altsep)}) + r')' would cover it completely. I switched to using non-capturing groups over a character class both to deal with the fact that escaping doesn't work the same way for character classes and to cover the possibility (no idea here) that some terrible OS might have a multicharacter path separator. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 21:01:17 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 17 Nov 2016 02:01:17 +0000 Subject: [issue28718] '*' matches entire path in fnmatch.translate In-Reply-To: <1479327127.15.0.931047394142.issue28718@psf.upfronthosting.co.za> Message-ID: <1479348077.72.0.593341477217.issue28718@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Oops, altsep is None, not the empty string when there is only one separator. And I didn't handle inverting the match. Sigh. You get the idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 21:25:03 2016 From: report at bugs.python.org (Eryk Sun) Date: Thu, 17 Nov 2016 02:25:03 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479349503.02.0.826181136142.issue28712@psf.upfronthosting.co.za> Eryk Sun added the comment: The ANSI and OEM codepages are conveniently supported on a Windows system as the encodings 'mbcs' and 'oem' (new in 3.6). The best-fit mapping is used by the 'replace' error handler (see the encode_code_page_flags function in Objects/unicodeobject.c). For other Windows codepages, while it's not as convenient, you can use codecs.code_page_encode. For example: >>> codecs.code_page_encode(1252, '?', 'replace') (b'a', 1) For decoding, MB_ERR_INVALID_CHARS has no effect on decoding single-byte codepages because they map every byte. It only affects decoding byte sequences that are invalid in multibyte codepages such as 932 and 65001. Without this flag, invalid sequences are silently decoded as the codepage's Unicode default character. This is usually "?", but for 932 it's Katakana middle dot (U+30FB), and for UTF-8 it's U+FFFD. codecs.code_page_decode uses MB_ERR_INVALID_CHARS almost always, except not for UTF-7 (see the decode_code_page_flags function). So its 'replace' error handling is completely Python's own implementation. For example: MultiByteToWideChar without MB_ERR_INVALID_CHARS: >>> decode(932, b'\xe05', strict=False) '\u30fb' versus code_page_decode: >>> codecs.code_page_decode(932, b'\xe05', 'replace', True) ('\ufffd5', 2) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 21:53:28 2016 From: report at bugs.python.org (Davin Potts) Date: Thu, 17 Nov 2016 02:53:28 +0000 Subject: [issue28699] Imap from ThreadPool behaves unexpectedly In-Reply-To: <1479234139.82.0.483433491582.issue28699@psf.upfronthosting.co.za> Message-ID: <1479351208.94.0.646004122414.issue28699@psf.upfronthosting.co.za> Davin Potts added the comment: Though it still lacks a proper test, I'm attaching a preliminary patch to address the problematic behavior in 3.5/3.6/default in the hopes that others might help test it. ---------- keywords: +patch Added file: http://bugs.python.org/file45516/issue_28699_lacks_test_but_check_unsorted_py3x.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 22:31:32 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 17 Nov 2016 03:31:32 +0000 Subject: [issue28670] PEP 235: Implement on every POSIX system, and clean up the C code for `import' In-Reply-To: <1478899111.69.0.0154952768919.issue28670@psf.upfronthosting.co.za> Message-ID: <1479353492.81.0.0744675098808.issue28670@psf.upfronthosting.co.za> Nick Coghlan added the comment: Michael, you seem to be operating under the assumption that the fact that the CPython VM assumes by default that Linux systems use consistent filesystem semantics is an accidental oversight. It's not - it's a pervasive simplifying assumption that runs throughout various parts of the interpreter design, mainly in the form of scoping various settings to "the machine" based on the detected operating system that are in reality specific to a particular filesystem within the machine. That's the reason what you propose is a feature request for Python 2.7 rather than a bug fix - you've picked one particular instance of that general assumption and proposed not making it anymore. However, you've also indicated that Python 3 (and hence presumably the `importlib2` backport of the Python 3 import system to Python 2) have already removed that assumption in this particular case. Hence my suggestion to discuss your concerns with Linux distribution providers - if something has changed in the past few years to make them more concerned about it, and they aren't satisfied with resolving it through their current Python 3 migration efforts [1,2], the use of `importlib2`, or the use of other filesystem interface bindings (such as PyFilesystem, GObject introspection, or Qt), then that would make a difference in the disposition of the issue report. [1] https://wiki.ubuntu.com/Python [2] http://fedora.portingdb.xyz/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 16 23:14:18 2016 From: report at bugs.python.org (Simon Holland) Date: Thu, 17 Nov 2016 04:14:18 +0000 Subject: [issue28723] tkinter, radiobutton, indicatoron=0 has no effect. Message-ID: <1479356058.22.0.131810563362.issue28723@psf.upfronthosting.co.za> New submission from Simon Holland: tkinters radiobutton's have an option 'indicatoron=0' which should display Radio Buttons as actual labelled buttons. button = tk.Radiobutton(self, text=option, variable = var, value = answer, indicatoron=0) Screenshots of expected and actual results ... http://imgur.com/a/2fI02 taken from ... http://stackoverflow.com/questions/34459221/tkinter-radiobutton-indicatoron-value-doesnt-effect-anything Kkinter 8.5 descrbes the functionality as so : Normally a checkbutton displays as its indicator a box that shows whether the checkbutton is set or not. You can get this behavior by setting indic- atoron=1. However, if you set indicatoron=0, the indicator disappears, and the entire widget becomes a push-push button that looks raised when it is cleared and sunken when it is set. You may want to increase the bor- derwidth value to make it easier to see the state of such a control. ---------- components: Tkinter files: u1mdKuC.png messages: 281022 nosy: Inyoka priority: normal severity: normal status: open title: tkinter, radiobutton, indicatoron=0 has no effect. type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file45517/u1mdKuC.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 01:58:23 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 17 Nov 2016 06:58:23 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479349503.02.0.826181136142.issue28712@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Windows API doc is not easy to understand. I wrote this doc when I fixed code pages in Python 3: http://unicodebook.readthedocs.io/operating_systems.html#windows ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 02:14:41 2016 From: report at bugs.python.org (Michael Felt) Date: Thu, 17 Nov 2016 07:14:41 +0000 Subject: [issue18235] _sysconfigdata.py wrong on AIX installations In-Reply-To: <1371429201.94.0.372851990361.issue18235@psf.upfronthosting.co.za> Message-ID: <1479366881.51.0.323189926937.issue18235@psf.upfronthosting.co.za> Michael Felt added the comment: FYI: after manually creating the .../libpython3.5/config directory and copying three files (see below) I was able to "pip3 install cython" as test. At the packing area: michael at x071:[/data/prj/python3/python3-3.5.2]ls Xany/opt/lib/python3.5/config ld_so_aix makexp_aix python.exp in the package: michael at x071:[/data/prj/python3/python3-3.5.2]restore -Tqf installp/ppc/*.I | grep lib/python3.5/config New volume on installp/ppc/aixtools.python3.3.5.2.0.I: Cluster size is 51200 bytes (100 blocks). The volume number is 1. The backup date is: Wed Nov 16 21:48:37 UTC 2016 Files are backed up by name. The user is root. ./opt/lib/python3.5/config ./opt/lib/python3.5/config/ld_so_aix ./opt/lib/python3.5/config/python.exp ./opt/lib/python3.5/config/makexp_aix ./opt/lib/python3.5/configparser.py ./opt/lib/python3.5/config-3.5m ./opt/lib/python3.5/config-3.5m/libpython3.5m.a ./opt/lib/python3.5/config-3.5m/Setup ./opt/lib/python3.5/config-3.5m/python-config.py ./opt/lib/python3.5/config-3.5m/config.c ./opt/lib/python3.5/config-3.5m/Setup.local ./opt/lib/python3.5/config-3.5m/config.c.in ./opt/lib/python3.5/config-3.5m/makesetup ./opt/lib/python3.5/config-3.5m/Setup.config ./opt/lib/python3.5/config-3.5m/install-sh ./opt/lib/python3.5/config-3.5m/Makefile ./opt/lib/python3.5/config-3.5m/python.o The number of archived files is 7390. Results: +-----------------------------------------------------------------------------+ Installing Software... +-----------------------------------------------------------------------------+ installp: APPLYING software for: aixtools.python3.rte 3.5.2.0 Restoring files, please wait. 4250 files restored. Finished processing all filesets. (Total time: 1 mins 1 secs). +-----------------------------------------------------------------------------+ Summaries: +-----------------------------------------------------------------------------+ Installation Summary -------------------- Name Level Part Event Result ------------------------------------------------------------------------------- aixtools.python3.rte 3.5.2.0 USR APPLY SUCCESS root at x064:[/data/prj/python3/python3-3.5.2]export OBJECT_MODE=64 root at x064:[/data/prj/python3/python3-3.5.2]pip3 install cython Collecting cython Using cached Cython-0.25.1.tar.gz Installing collected packages: cython Running setup.py install for cython ... done Successfully installed cython-0.25.1 You are using pip version 8.1.1, however version 9.0.1 is available. You should consider upgrading via the 'pip install --upgrade pip' command. Question: if there is a patch since 3.5.2 was released - how do I pick this up in order to test (and maybe patch)? I am a bit lost in the hg/git discussion about where to go to get current status. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 02:41:40 2016 From: report at bugs.python.org (Simon Holland) Date: Thu, 17 Nov 2016 07:41:40 +0000 Subject: [issue28723] tkinter, radiobutton, indicatoron=0 has no effect. In-Reply-To: <1479356058.22.0.131810563362.issue28723@psf.upfronthosting.co.za> Message-ID: <1479368500.01.0.0145384773666.issue28723@psf.upfronthosting.co.za> Changes by Simon Holland : ---------- nosy: +gpolo, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 03:02:57 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 17 Nov 2016 08:02:57 +0000 Subject: [issue26931] android: test_distutils fails In-Reply-To: <1462285501.44.0.0195995288955.issue26931@psf.upfronthosting.co.za> Message-ID: <20161117080253.11981.66288.5C0772ED@psf.io> Roundup Robot added the comment: New changeset cea3b621973f by Xavier de Gaye in branch '3.6': Issue 26931: Skip the test_distutils tests using a compiler executable https://hg.python.org/cpython/rev/cea3b621973f New changeset 99d69fd1b24e by Xavier de Gaye in branch 'default': Issue 26931: Merge 3.6 https://hg.python.org/cpython/rev/99d69fd1b24e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 03:07:06 2016 From: report at bugs.python.org (Ivan Pozdeev) Date: Thu, 17 Nov 2016 08:07:06 +0000 Subject: [issue26786] bdist_msi duplicates directories with names in ALL CAPS to a bogus location In-Reply-To: <1460844390.43.0.520967711704.issue26786@psf.upfronthosting.co.za> Message-ID: <1479370026.04.0.469859472492.issue26786@psf.upfronthosting.co.za> Changes by Ivan Pozdeev : ---------- versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 03:07:49 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 17 Nov 2016 08:07:49 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479370069.34.0.795859720719.issue28712@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Eryk. That is what I want. I just missed that code_page_decode() returns a tuple. Seems Windows maps undefined codes to Unicode characters if they are in the range 0x80-0x9f and makes an error if they are outside of this range. But if the code starts multibyte sequence, the single byte is an error even if it is in the range 0x80-0x9f (codepages 932, 949, 950). This could be emulated by either decoding with errors='surrogateescape' and postprocessing the result (replace '\udc80'-'\udc9f' with '\x80'-'\x9f' and handle '\udca0'-'\udcff' as error) or writing custom error handler that does the job (but perhaps needed several error handlers corresponding 'strict', 'replace', 'ignore', etc). Adding a new codec of cause is an option too. There are few other minor differences between Python and Windows: cp864: On Windows 0x25 is mapped to '%' (U+0025) instead of '?' (U+066A). cp932: 0xA0, 0xFD, 0xFE, 0xFF are errors instead of mapping to U+F8F0-U+F8F3. cp1255: 0xCA is mapped to U+05BA instead of be undefined. The first two differences can be handled by postprocessing, the latter needs changing the codec. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 03:23:18 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 17 Nov 2016 08:23:18 +0000 Subject: [issue26926] test_io large file test failure on 32 bits Android platforms In-Reply-To: <1462283737.14.0.888848894928.issue26926@psf.upfronthosting.co.za> Message-ID: <20161117082315.106564.8430.BC14F54A@psf.io> Roundup Robot added the comment: New changeset d616304b82aa by Xavier de Gaye in branch '3.6': Issue #26926: Skip some test_io tests on platforms without large file support https://hg.python.org/cpython/rev/d616304b82aa New changeset 878f91b4ad19 by Xavier de Gaye in branch 'default': Issue #26926: Merge 3.6 https://hg.python.org/cpython/rev/878f91b4ad19 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 03:29:40 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 17 Nov 2016 08:29:40 +0000 Subject: [issue28723] tkinter, radiobutton, indicatoron=0 has no effect. In-Reply-To: <1479356058.22.0.131810563362.issue28723@psf.upfronthosting.co.za> Message-ID: <1479371380.79.0.364484910015.issue28723@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Works to me on Linux (identical results with Tkinter and Tk). In any case if there is some bug on your platform, this is not Tkinter bug, but Tk bug. Tkinter doesn't handle this option specially, it just pass it to Tk. File a bug on Tk bugtracker: http://core.tcl.tk/tk/ticket . ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 03:51:09 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 17 Nov 2016 08:51:09 +0000 Subject: [issue28699] Imap from ThreadPool behaves unexpectedly In-Reply-To: <1479234139.82.0.483433491582.issue28699@psf.upfronthosting.co.za> Message-ID: <1479372669.8.0.227918498467.issue28699@psf.upfronthosting.co.za> Xiang Zhang added the comment: Hi Davin, could it be fixed like this? diff -r 05a728e1da15 Lib/multiprocessing/pool.py --- a/Lib/multiprocessing/pool.py Wed Nov 16 16:35:53 2016 -0800 +++ b/Lib/multiprocessing/pool.py Thu Nov 17 16:35:38 2016 +0800 @@ -398,7 +398,7 @@ except Exception as ex: job, ind = task[:2] if task else (0, 0) if job in cache: - cache[job]._set(ind + 1, (False, ex)) + cache[job]._set(ind + 1 if task else 0, (False, ex)) if set_length: util.debug('doing set_length()') set_length(i+1) It seems to me the bug is _handle_tasks doesn't treat the exception correctly if it's on the very first. Every time it _set(ind + 1) since if there is any exception the task is the previous task and + 1 is needed. But if the exception occurs at the very first, task is None and the + 1 is not needed. I am not very sure but the reported cases work correctly now: list(Pool(processes=2).imap(double, get_numbers())) # raises error now list(pool.imap(str, gen())) # raises error now ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 05:13:06 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 17 Nov 2016 10:13:06 +0000 Subject: [issue7659] Attribute assignment on object() instances raises wrong exception In-Reply-To: <1262968332.68.0.476240777656.issue7659@psf.upfronthosting.co.za> Message-ID: <1479377586.08.0.390281817266.issue7659@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could this issue be closed now? ---------- nosy: +serhiy.storchaka status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 05:20:45 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 17 Nov 2016 10:20:45 +0000 Subject: [issue26931] android: test_distutils fails In-Reply-To: <1462285501.44.0.0195995288955.issue26931@psf.upfronthosting.co.za> Message-ID: <1479378045.42.0.436896192761.issue26931@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 05:21:14 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 17 Nov 2016 10:21:14 +0000 Subject: [issue26926] test_io large file test failure on 32 bits Android platforms In-Reply-To: <1462283737.14.0.888848894928.issue26926@psf.upfronthosting.co.za> Message-ID: <1479378074.03.0.1662321382.issue26926@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 05:26:43 2016 From: report at bugs.python.org (Pascal Chambon) Date: Thu, 17 Nov 2016 10:26:43 +0000 Subject: [issue7659] Attribute assignment on object() instances raises wrong exception In-Reply-To: <1262968332.68.0.476240777656.issue7659@psf.upfronthosting.co.za> Message-ID: <1479378403.3.0.52423310069.issue7659@psf.upfronthosting.co.za> Pascal Chambon added the comment: I guess it can, since retrocompatibility prevents some normalization here. Or is it worth updating the doc about "AttributeError", misleading regarding the type of exception expected in this case ? ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 05:46:36 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 17 Nov 2016 10:46:36 +0000 Subject: [issue28696] imap from ThreadPool hangs by an exception in a generator function In-Reply-To: <1479214370.8.0.751710549169.issue28696@psf.upfronthosting.co.za> Message-ID: <1479379596.96.0.0566294009273.issue28696@psf.upfronthosting.co.za> Xiang Zhang added the comment: In Py3.6, it raises error: >>> next((pool.imap(str, gen()))) Traceback (most recent call last): File "/opt/lib/python3.7/multiprocessing/pool.py", line 684, in next item = self._items.popleft() IndexError: pop from an empty deque During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/opt/lib/python3.7/multiprocessing/pool.py", line 690, in next item = self._items.popleft() IndexError: pop from an empty deque During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "/opt/lib/python3.7/multiprocessing/pool.py", line 693, in next raise StopIteration StopIteration But this doesn't looks good. I think it should raise TypeError. It can be fixed in #28699. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 06:21:17 2016 From: report at bugs.python.org (Simon Holland) Date: Thu, 17 Nov 2016 11:21:17 +0000 Subject: [issue28723] tkinter, radiobutton, indicatoron=0 has no effect. In-Reply-To: <1479371380.79.0.364484910015.issue28723@psf.upfronthosting.co.za> Message-ID: Simon Holland added the comment: Thank you On 17 November 2016 at 15:29, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > Works to me on Linux (identical results with Tkinter and Tk). In any case > if there is some bug on your platform, this is not Tkinter bug, but Tk bug. > Tkinter doesn't handle this option specially, it just pass it to Tk. File a > bug on Tk bugtracker: http://core.tcl.tk/tk/ticket . > > ---------- > resolution: -> third party > stage: -> resolved > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ > -- Simon Holland BA Hons Medan, Indonesia -------------------- Mobile : +62 81 26055297 Fax : +62 81 6613280 [image: Twitter] [image: LinkedIn] [image: YouTube] [image: Google Talk] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 07:17:54 2016 From: report at bugs.python.org (INADA Naoki) Date: Thu, 17 Nov 2016 12:17:54 +0000 Subject: [issue27945] Various segfaults with dict In-Reply-To: <1472852008.61.0.354257945943.issue27945@psf.upfronthosting.co.za> Message-ID: <1479385074.46.0.501522758256.issue27945@psf.upfronthosting.co.za> INADA Naoki added the comment: I run performance 0.5.0 on Python 3.5. Since it took long time even without -b all option, I haven't run it for Python 2.7 yet. On Python 3.5: $ ./venv/cpython3.5-846d5b1f0b61/bin/python -m perf compare_to py35-master.json py35-patched.json -G Slower (14): - logging_silent: 2.92 us +- 0.15 us -> 3.05 us +- 0.18 us: 1.04x slower - pickle: 93.2 us +- 4.7 us -> 95.8 us +- 5.0 us: 1.03x slower - python_startup: 72.6 ms +- 4.7 ms -> 74.6 ms +- 4.8 ms: 1.03x slower - meteor_contest: 766 ms +- 13 ms -> 779 ms +- 15 ms: 1.02x slower - scimark_sor: 2.00 sec +- 0.04 sec -> 2.04 sec +- 0.03 sec: 1.02x slower - fannkuch: 3.86 sec +- 0.05 sec -> 3.91 sec +- 0.04 sec: 1.01x slower - python_startup_no_site: 37.4 ms +- 2.4 ms -> 38.0 ms +- 2.6 ms: 1.01x slower - regex_dna: 958 ms +- 13 ms -> 973 ms +- 16 ms: 1.01x slower - regex_compile: 1.41 sec +- 0.02 sec -> 1.43 sec +- 0.02 sec: 1.01x slower - raytrace: 5.46 sec +- 0.06 sec -> 5.52 sec +- 0.07 sec: 1.01x slower - scimark_lu: 1.88 sec +- 0.09 sec -> 1.90 sec +- 0.12 sec: 1.01x slower - nbody: 887 ms +- 19 ms -> 895 ms +- 21 ms: 1.01x slower - 2to3: 3.01 sec +- 0.03 sec -> 3.03 sec +- 0.04 sec: 1.01x slower - scimark_fft: 2.52 sec +- 0.05 sec -> 2.54 sec +- 0.04 sec: 1.01x slower Faster (16): - scimark_sparse_mat_mult: 35.0 ms +- 1.8 ms -> 32.7 ms +- 2.0 ms: 1.07x faster - xml_etree_process: 1.13 sec +- 0.03 sec -> 1.07 sec +- 0.03 sec: 1.06x faster - xml_etree_generate: 1.35 sec +- 0.03 sec -> 1.29 sec +- 0.03 sec: 1.05x faster - mako: 154 ms +- 8 ms -> 149 ms +- 7 ms: 1.04x faster - telco: 87.4 ms +- 3.7 ms -> 84.2 ms +- 4.1 ms: 1.04x faster - tornado_http: 1.75 sec +- 0.03 sec -> 1.70 sec +- 0.03 sec: 1.03x faster - call_simple: 45.5 ms +- 2.1 ms -> 44.3 ms +- 1.4 ms: 1.03x faster - sympy_integrate: 202 ms +- 9 ms -> 198 ms +- 7 ms: 1.02x faster - sympy_str: 2.08 sec +- 0.06 sec -> 2.04 sec +- 0.06 sec: 1.02x faster - django_template: 1.65 sec +- 0.03 sec -> 1.61 sec +- 0.03 sec: 1.02x faster - call_method_unknown: 65.1 ms +- 0.9 ms -> 64.3 ms +- 0.9 ms: 1.01x faster - xml_etree_parse: 1.34 sec +- 0.04 sec -> 1.32 sec +- 0.04 sec: 1.01x faster - sympy_sum: 1.01 sec +- 0.03 sec -> 998 ms +- 35 ms: 1.01x faster - call_method_slots: 59.3 ms +- 0.8 ms -> 58.6 ms +- 1.0 ms: 1.01x faster - float: 1.24 sec +- 0.03 sec -> 1.23 sec +- 0.02 sec: 1.01x faster - chaos: 1.20 sec +- 0.02 sec -> 1.19 sec +- 0.02 sec: 1.01x faster Benchmark hidden because not significant (31): call_method, chameleon, crypto_pyaes, deltablue, dulwich_log, genshi_text, genshi_xml, go, hexiom, html5lib, json_dumps, json_loads, logging_format, logging_simple, nqueens, pathlib, pickle_dict, pickle_list, pickle_pure_python, pidigits, regex_effbot, regex_v8, richards, scimark_monte_carlo, spectral_norm, sympy_expand, unpack_sequence, unpickle, unpickle_list, unpickle_pure_python, xml_etree_iterparse ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 07:25:47 2016 From: report at bugs.python.org (INADA Naoki) Date: Thu, 17 Nov 2016 12:25:47 +0000 Subject: [issue27945] Various segfaults with dict In-Reply-To: <1472852008.61.0.354257945943.issue27945@psf.upfronthosting.co.za> Message-ID: <1479385547.85.0.728203175467.issue27945@psf.upfronthosting.co.za> INADA Naoki added the comment: Only patch which affects to hot loop is: --- a/Objects/dictobject.c Tue Nov 15 21:21:35 2016 -0500 +++ b/Objects/dictobject.c Wed Nov 16 11:40:51 2016 +0000 @@ -1550,11 +1550,18 @@ PyDict_MergeFromSeq2(PyObject *d, PyObje /* Update/merge with this (key, value) pair. */ key = PySequence_Fast_GET_ITEM(fast, 0); value = PySequence_Fast_GET_ITEM(fast, 1); + Py_INCREF(key); + Py_INCREF(value); if (override || PyDict_GetItem(d, key) == NULL) { int status = PyDict_SetItem(d, key, value); - if (status < 0) + if (status < 0) { + Py_DECREF(key); + Py_DECREF(value); goto Fail; + } } + Py_DECREF(key); + Py_DECREF(value); Py_DECREF(fast); Py_DECREF(item); } Microbenchmark for it: $ ~/local/py35/bin/master -m perf timeit --rigorous -t --python ~/local/py35/bin/patched --compare-to ~/local/py35/bin/master -s 'L = [(i,i) for i in range(10000)]' -- 'dict.fromkeys(L)' Benchmark master ================ .........................................Total duration: 21.2 sec Start date: 2016-11-17 12:21:39 End date: 2016-11-17 12:22:13 Raw sample minimum: 109 ms Raw sample maximum: 144 ms Number of runs: 41 Total number of samples: 120 Number of samples per run: 3 Number of warmups per run: 1 Loop iterations per sample: 32 Minimum: 3.41 ms (-13%) Median +- std dev: 3.92 ms +- 0.19 ms Mean +- std dev: 3.92 ms +- 0.19 ms Maximum: 4.50 ms (+15%) Median +- std dev: 3.92 ms +- 0.19 ms Benchmark patched ================= .........................................Total duration: 21.3 sec Start date: 2016-11-17 12:22:13 End date: 2016-11-17 12:22:47 Raw sample minimum: 108 ms Raw sample maximum: 152 ms Number of runs: 41 Total number of samples: 120 Number of samples per run: 3 Number of warmups per run: 1 Loop iterations per sample: 32 Minimum: 3.39 ms (-14%) Median +- std dev: 3.92 ms +- 0.23 ms Mean +- std dev: 3.95 ms +- 0.23 ms Maximum: 4.74 ms (+21%) Median +- std dev: 3.92 ms +- 0.23 ms Compare ======= Median +- std dev: [master] 3.92 ms +- 0.19 ms -> [patched] 3.92 ms +- 0.23 ms: 1.00x slower Not significant! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 07:27:39 2016 From: report at bugs.python.org (A. Jesse Jiryu Davis) Date: Thu, 17 Nov 2016 12:27:39 +0000 Subject: [issue25924] investigate if getaddrinfo(3) on OSX is thread-safe In-Reply-To: <1450789030.99.0.515103781608.issue25924@psf.upfronthosting.co.za> Message-ID: <1479385659.28.0.314023687336.issue25924@psf.upfronthosting.co.za> A. Jesse Jiryu Davis added the comment: Here's a retelling of this bug report as a silly fantasy saga: https://engineering.mongodb.com/post/the-saga-of-concurrent-dns-in-python-and-the-defeat-of-the-wicked-mutex-troll/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 07:34:56 2016 From: report at bugs.python.org (INADA Naoki) Date: Thu, 17 Nov 2016 12:34:56 +0000 Subject: [issue27945] Various segfaults with dict In-Reply-To: <1472852008.61.0.354257945943.issue27945@psf.upfronthosting.co.za> Message-ID: <1479386096.46.0.442865444957.issue27945@psf.upfronthosting.co.za> INADA Naoki added the comment: I'm sorry, dict.fromkeys() didn't use PyDict_MergeFromSeq2(). This may be microbench for worst case: $ ~/local/py35/bin/master -m perf timeit --rigorous --python ~/local/py35/bin/patched --compare-to ~/local/py35/bin/master -s 'L = [(i,i) for i in range(10000)]' -- 'dict(L)' master: ......................................... 2.06 ms +- 0.11 ms patched: ......................................... 2.16 ms +- 0.09 ms Median +- std dev: [master] 2.06 ms +- 0.11 ms -> [patched] 2.16 ms +- 0.09 ms: 1.05x slower $ ~/local/py27/bin/master -m perf timeit --rigorous --python ~/local/py27/bin/patched --compare-to ~/local/py27/bin/master -s 'L = [(i,i) for i in range(10000)]' -- 'dict(L)' master: ......................................... 1.48 ms +- 0.06 ms patched: ......................................... 1.57 ms +- 0.09 ms Median +- std dev: [master] 1.48 ms +- 0.06 ms -> [patched] 1.57 ms +- 0.09 ms: 1.06x slower ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 07:45:48 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 17 Nov 2016 12:45:48 +0000 Subject: [issue28684] [asyncio] bind() on a unix socket raises PermissionError on Android for a non-root user In-Reply-To: <1479069574.19.0.731580166174.issue28684@psf.upfronthosting.co.za> Message-ID: <1479386748.38.0.84300859759.issue28684@psf.upfronthosting.co.za> Xavier de Gaye added the comment: With this patch, test_asyncio runs successfully with no ResourceWarning when run on the android-24 emulator. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file45518/test_asyncio_bind.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 08:13:33 2016 From: report at bugs.python.org (INADA Naoki) Date: Thu, 17 Nov 2016 13:13:33 +0000 Subject: [issue27945] Various segfaults with dict In-Reply-To: <1472852008.61.0.354257945943.issue27945@psf.upfronthosting.co.za> Message-ID: <1479388413.79.0.163077284107.issue27945@psf.upfronthosting.co.za> INADA Naoki added the comment: I modified the patch to avoid incref&decref when pair is not list, because tuple is common for such case. But I can't get back original performance. (python 2.7 is modified version of patch) inada-n at test1:~/work/bench$ ~/local/py27/bin/master -m perf timeit --rigorous --python ~/local/py27/bin/python2.7 --compare-to ~/local/py27/bin/master -s 'L = [(i,i) for i in range(10000)]' -- 'dict(L)' master: ......................................... 1.47 ms +- 0.06 ms python2.7: ......................................... 1.55 ms +- 0.06 ms Median +- std dev: [master] 1.47 ms +- 0.06 ms -> [python2.7] 1.55 ms +- 0.06 ms: 1.05x slower inada-n at test1:~/work/bench$ ~/local/py27/bin/master -m perf timeit --rigorous --python ~/local/py27/bin/python2.7 --compare-to ~/local/py27/bin/patched -s 'L = [(i,i) for i in range(10000)]' -- 'dict(L)' patched: ......................................... 1.56 ms +- 0.08 ms python2.7: ......................................... 1.55 ms +- 0.09 ms Median +- std dev: [patched] 1.56 ms +- 0.08 ms -> [python2.7] 1.55 ms +- 0.09 ms: 1.01x faster Not significant! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 08:43:29 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 17 Nov 2016 13:43:29 +0000 Subject: [issue28699] Imap from ThreadPool behaves unexpectedly In-Reply-To: <1479234139.82.0.483433491582.issue28699@psf.upfronthosting.co.za> Message-ID: <1479390209.88.0.279658006145.issue28699@psf.upfronthosting.co.za> Xiang Zhang added the comment: What's more, this case seems non-reentrant. Since there is no task in this case, the job id is always 0 which is not true. This means after the first time, we can not set even the exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 10:05:33 2016 From: report at bugs.python.org (Shinya Okano) Date: Thu, 17 Nov 2016 15:05:33 +0000 Subject: [issue28724] Add method send_io, recv_io to the socket module. Message-ID: <1479395133.65.0.0720889900419.issue28724@psf.upfronthosting.co.za> New submission from Shinya Okano: This patch makes it easy to pass file descriptor in using AF_UNIX. Ruby language libraries have such methods. see slso: - https://docs.ruby-lang.org/en/2.3.0/UNIXSocket.html#method-i-send_io ---------- components: Library (Lib) files: socket_send_io_recv_io.patch keywords: patch messages: 281041 nosy: tokibito priority: normal severity: normal status: open title: Add method send_io, recv_io to the socket module. type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45519/socket_send_io_recv_io.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 10:30:53 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 17 Nov 2016 15:30:53 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings In-Reply-To: <1479128206.47.0.155651436814.issue28688@psf.upfronthosting.co.za> Message-ID: <1479396653.23.0.155218106914.issue28688@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, this issue is a regression caused by the issue #23839. The environment warning was already fixed by the issue #18383 (duplicate: issue #26742): New changeset f57f4e33ba5e by Martin Panter in branch '3.5': Issue #18383: Avoid adding duplicate filters when warnings is reloaded https://hg.python.org/cpython/rev/f57f4e33ba5e The problem is that _sre.SRE_Pattern doesn't import rich compare: so two patterns are only equal if it's exactly the same object... which is likely when re caches the compiled expression... But the Python test runner now starts by clearing the re cache! I see different options: * Find something else to not re-initialize warning filters, "_processoptions(sys.warnoptions)" in warnings.py. * Fix warnings._add_filter() to implement a custom comparator operator for regular expression objects: compare pattern and flags * Implement comparision in _sre.SRE_Pattern ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 10:43:29 2016 From: report at bugs.python.org (Gavin Panella) Date: Thu, 17 Nov 2016 15:43:29 +0000 Subject: [issue28725] Awaiting an awaitable returned from an async function does nothing Message-ID: <1479397409.08.0.1550595702.issue28725@psf.upfronthosting.co.za> New submission from Gavin Panella: The following will sleep: async def one(): await asyncio.sleep(10) async def two(): await one() loop.run_until_complete(two()) but the following will not: async def one(): return asyncio.sleep(10) async def two(): await one() loop.run_until_complete(two()) I would expect run_until_complete to keep bouncing awaitable results back into the event-loop until a non-awaitable is returned. In my code I work around this with: result = loop.run_until_complete(...) while inspect.isawaitable(result): result = loop.run_until_complete(result) I would also expect that the await in `two` would have DTRT with the returned generator/coroutine. ---------- components: asyncio messages: 281043 nosy: allenap, gvanrossum, yselivanov priority: normal severity: normal status: open title: Awaiting an awaitable returned from an async function does nothing type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 10:54:34 2016 From: report at bugs.python.org (Eryk Sun) Date: Thu, 17 Nov 2016 15:54:34 +0000 Subject: [issue28712] Non-Windows mappings for a couple of Windows code pages In-Reply-To: <1479274828.26.0.726447169651.issue28712@psf.upfronthosting.co.za> Message-ID: <1479398074.31.0.0391134593896.issue28712@psf.upfronthosting.co.za> Eryk Sun added the comment: Thanks, Serihy. When I looked at this previously, I mistakenly assumed that any undefined codes would be decoded using the codepage's default Unicode character. But for single-byte codepages in the range above 0x9F, Windows instead maps undefined codes to the Private Use Area (PUA). For example, using decode() from above: ERROR_NO_UNICODE_TRANSLATION = 0x0459 codepages = 857, 864, 874, 1253, 1255, 1257 for cp in codepages: undefined = [] for i in range(256): b = bytes([i]) try: decode(cp, b) except OSError as e: if e.winerror == ERROR_NO_UNICODE_TRANSLATION: c = decode(cp, b, False) undefined.append('{:02x}=>{:04x}'.format(ord(b), ord(c))) print(cp, *undefined, sep=', ') output: 857, d5=>f8bb, e7=>f8bc, f2=>f8bd 864, a6=>f8be, a7=>f8bf, ff=>f8c0 874, db=>f8c1, dc=>f8c2, dd=>f8c3, de=>f8c4, fc=>f8c5, fd=>f8c6, fe=>f8c7, ff=>f8c8 1253, aa=>f8f9, d2=>f8fa, ff=>f8fb 1255, d9=>f88d, da=>f88e, db=>f88f, dc=>f890, dd=>f891, de=>f892, df=>f893, fb=>f894, fc=>f895, ff=>f896 1257, a1=>f8fc, a5=>f8fd Do you think Python's 'replace' handler should prevent adding the MB_ERR_INVALID_CHARS flag for PyUnicode_DecodeCodePageStateful? One benefit is that the PUA code can be encoded back to the original byte value: >>> codecs.code_page_encode(1257, '\uf8fd') (b'\xa5', 1) > cp932: 0xA0, 0xFD, 0xFE, 0xFF are errors instead of mapping to U+F8F0-U+F8F3. Windows maps these byte values to PUA codes if the MB_ERR_INVALID_CHARS flag isn't used: >>> decode(932, b'\xa0\xfd\xfe\xff', False) '\uf8f0\uf8f1\uf8f2\uf8f3' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 10:56:15 2016 From: report at bugs.python.org (Pravic Ehysta) Date: Thu, 17 Nov 2016 15:56:15 +0000 Subject: [issue28726] py.exe launches wrong version Message-ID: <1479398175.28.0.0714056726862.issue28726@psf.upfronthosting.co.za> New submission from Pravic Ehysta: d:\>py -3.5 Requested Python version (3.5) not installed d:\>py -3.3 Requested Python version (3.3) not installed d:\>py -3.4 Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> ^Z ---------- components: Windows messages: 281045 nosy: Pravic Ehysta, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: py.exe launches wrong version type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 11:02:48 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 17 Nov 2016 16:02:48 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern Message-ID: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch implements rich comparison for _sre.SRE_Pattern objects created by re.compile(). Comparison between patterns is used in the warnings module to not add duplicated filters, see issue #18383: New changeset f57f4e33ba5e by Martin Panter in branch '3.5': Issue #18383: Avoid adding duplicate filters when warnings is reloaded https://hg.python.org/cpython/rev/f57f4e33ba5e For the warnings module, it became a problem in test_warnings since the Python test runner started to clear all caches. When re.purge() is called, re.compile() creates a new object, whereas with the cache it returns the same object and so the two patterns are equal since it's the same object. => see issue #28688 ---------- files: pattern_compare.patch keywords: patch messages: 281046 nosy: haypo priority: normal severity: normal status: open title: Implement comparison (x==y and x!=y) for _sre.SRE_Pattern type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45520/pattern_compare.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 11:03:29 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 17 Nov 2016 16:03:29 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings In-Reply-To: <1479128206.47.0.155651436814.issue28688@psf.upfronthosting.co.za> Message-ID: <1479398609.48.0.0463910262529.issue28688@psf.upfronthosting.co.za> STINNER Victor added the comment: > * Implement comparision in _sre.SRE_Pattern I wrote a patch and opened the issue #28727: "Implement comparison (x==y and x!=y) for _sre.SRE_Pattern". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 11:19:57 2016 From: report at bugs.python.org (Steve Dower) Date: Thu, 17 Nov 2016 16:19:57 +0000 Subject: [issue28726] py.exe launches wrong version In-Reply-To: <1479398175.28.0.0714056726862.issue28726@psf.upfronthosting.co.za> Message-ID: <1479399597.63.0.699580467804.issue28726@psf.upfronthosting.co.za> Steve Dower added the comment: Can you do "set PYLAUNCH_DEBUG=1" and then run "py -3.4" again and paste the full output? Also, is there anything unusual about how you installed Python? Did you customize any settings? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 11:26:03 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 17 Nov 2016 16:26:03 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings In-Reply-To: <1479128206.47.0.155651436814.issue28688@psf.upfronthosting.co.za> Message-ID: <1479399963.29.0.427503350325.issue28688@psf.upfronthosting.co.za> STINNER Victor added the comment: > * Fix warnings._add_filter() to implement a custom comparator operator for regular expression objects: compare pattern and flags Attached patch warnings_key.patch implements this. I really dislike the patch :-( ---------- keywords: +patch Added file: http://bugs.python.org/file45521/warnings_key.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 11:27:15 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 17 Nov 2016 16:27:15 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings In-Reply-To: <1479128206.47.0.155651436814.issue28688@psf.upfronthosting.co.za> Message-ID: <1479400035.48.0.223091613245.issue28688@psf.upfronthosting.co.za> STINNER Victor added the comment: FYI Python 2.7 is not impacted by this bug because it seems like reimporting warnings.py twice gets a new fresh list from _warnings.filters. I don't undertand how/why. ---------- versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 11:28:25 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 17 Nov 2016 16:28:25 +0000 Subject: [issue26939] android: test_functools hangs on armv7 In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za> Message-ID: <1479400105.55.0.484602883966.issue26939@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 11:29:26 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 17 Nov 2016 16:29:26 +0000 Subject: [issue26940] android: test_importlib hangs on armv7 In-Reply-To: <1462290134.16.0.615698223309.issue26940@psf.upfronthosting.co.za> Message-ID: <1479400166.86.0.252896318499.issue26940@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 11:30:01 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 17 Nov 2016 16:30:01 +0000 Subject: [issue26941] android: test_threading hangs on armv7 In-Reply-To: <1462290426.09.0.613967464154.issue26941@psf.upfronthosting.co.za> Message-ID: <1479400201.16.0.342151124449.issue26941@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 11:34:39 2016 From: report at bugs.python.org (Pravic Ehysta) Date: Thu, 17 Nov 2016 16:34:39 +0000 Subject: [issue28726] py.exe launches wrong version In-Reply-To: <1479398175.28.0.0714056726862.issue28726@psf.upfronthosting.co.za> Message-ID: <1479400479.45.0.621497427865.issue28726@psf.upfronthosting.co.za> Pravic Ehysta added the comment: d:\>py -3.5 launcher build: 32bit launcher executable: Console File 'C:\Users\owle\AppData\Local\py.ini' non-existent File 'C:\Windows\py.ini' non-existent Called with command line: -3.5 locating Pythons in 64bit registry locate_pythons_for_key: D:\perl\python\278\python.exe is a 32bit executable locate_pythons_for_key: D:\perl\python\278\PCBuild\win32\python.exe: ??????? ?? ??????? ????? ????????? ????. locate_pythons_for_key: D:\perl\python\278\PCBuild\amd64\python.exe: ??????? ?? ??????? ????? ????????? ????. locate_pythons_for_key: D:\perl\python\278\PCBuild\python.exe: ??????? ?? ??????? ????? ????????? ????. HKCU\SOFTWARE\Python\PythonCore\3.4\InstallPath: ?? ??????? ????? ????????? ????. HKLM\SOFTWARE\Python\PythonCore\2.7\InstallPath: ?? ??????? ????? ????????? ????. locate_pythons_for_key: D:\perl\python\3\python.exe is a 64bit executable locate_pythons_for_key: D:\perl\python\3\PCBuild\win32\python.exe: ??????? ?? ??????? ????? ????????? ????. locate_pythons_for_key: D:\perl\python\3\PCBuild\amd64\python.exe: ??????? ?? ??????? ????? ????????? ????. locate_pythons_for_key: D:\perl\python\3\PCBuild\python.exe: ??????? ?? ??????? ????? ????????? ????. locate_pythons_for_key: D:\Perl\python\3\python.exe: already found locate_pythons_for_key: D:\Perl\python\3\PCBuild\win32\python.exe: ??????? ?? ??????? ????? ????????? ????. locate_pythons_for_key: D:\Perl\python\3\PCBuild\amd64\python.exe: ??????? ?? ??????? ????? ????????? ????. locate_pythons_for_key: D:\Perl\python\3\PCBuild\python.exe: ??????? ?? ??????? ????? ????????? ????. locating Pythons in native registry locate_pythons_for_key: D:\perl\python\278\python.exe: already found locate_pythons_for_key: D:\perl\python\278\PCBuild\win32\python.exe: ??????? ?? ??????? ????? ????????? ????. locate_pythons_for_key: D:\perl\python\278\PCBuild\amd64\python.exe: ??????? ?? ??????? ????? ????????? ????. locate_pythons_for_key: D:\perl\python\278\PCBuild\python.exe: ??????? ?? ??????? ????? ????????? ????. HKCU\SOFTWARE\Python\PythonCore\3.4\InstallPath: ?? ??????? ????? ????????? ????. locate_pythons_for_key: D:\perl\python\2\python.exe is a 32bit executable locate_pythons_for_key: D:\perl\python\2\PCBuild\win32\python.exe: ??????? ?? ??????? ????? ????????? ????. locate_pythons_for_key: D:\perl\python\2\PCBuild\amd64\python.exe: ??????? ?? ??????? ????? ????????? ????. locate_pythons_for_key: D:\perl\python\2\PCBuild\python.exe: ??????? ?? ??????? ????? ????????? ????. HKLM\SOFTWARE\Python\PythonCore\3.4\InstallPath: ?? ??????? ????? ????????? ????. search for Python version '3.5' found no interpreter Requested Python version (3.5) not installed It seems, there are old registry keys which were not deleted by installer. HKEY_CURRENT_USER\Software\Python\PythonCore - contains 2.7 and invalid 3.4 (with "modules" subkey only) HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore - contains 2.7 (modules only), 3.4 and 3.5. HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore - contains 2.7 and 3.4 (modules only). Quiet messy. How can I clean my registry without reinstalling site packages? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 11:37:22 2016 From: report at bugs.python.org (SilentGhost) Date: Thu, 17 Nov 2016 16:37:22 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479400642.89.0.931137283798.issue28727@psf.upfronthosting.co.za> SilentGhost added the comment: Ten subtest in test_re fail with TypeError: unhashable type: '_sre.SRE_Pattern' ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 11:47:03 2016 From: report at bugs.python.org (Steve Dower) Date: Thu, 17 Nov 2016 16:47:03 +0000 Subject: [issue28726] py.exe launches wrong version In-Reply-To: <1479398175.28.0.0714056726862.issue28726@psf.upfronthosting.co.za> Message-ID: <1479401223.52.0.23449989037.issue28726@psf.upfronthosting.co.za> Steve Dower added the comment: Were Python 3.5 and 3.4 installed into the same location? That would explain some of the problems. It looks like it's finding it from the 3.4 key and then skipping the 3.5 key because the path is the same - hence "py -3.5" doesn't find it. Also, we apparently are lacking some Unicode support in the launcher :) If you delete all of the PythonCore keys and run repair installs for the versions of Python you want, that will restore the ones you need. Our installer deliberately does not remove anything in site-packages (except for pip, and only if it were installed by our installer). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 11:51:09 2016 From: report at bugs.python.org (Pravic Ehysta) Date: Thu, 17 Nov 2016 16:51:09 +0000 Subject: [issue28726] py.exe launches wrong version In-Reply-To: <1479398175.28.0.0714056726862.issue28726@psf.upfronthosting.co.za> Message-ID: <1479401469.53.0.801613449156.issue28726@psf.upfronthosting.co.za> Pravic Ehysta added the comment: Well, I deleted outdated registry keys, now it works fine. Thanks for helping and I am going to close this issue since it isn't a bug. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 12:02:49 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 17 Nov 2016 17:02:49 +0000 Subject: [issue28725] Awaiting an awaitable returned from an async function does nothing In-Reply-To: <1479397409.08.0.1550595702.issue28725@psf.upfronthosting.co.za> Message-ID: <1479402169.33.0.390501045221.issue28725@psf.upfronthosting.co.za> Yury Selivanov added the comment: This isn't a bug. Python doesn't magically unwind awaitables, you have to do that yourself: async def two(): await (await one()) Broadly speaking, returning awaitables from coroutines is an anti-pattern. Closing this one. Feel free to re-open or ask questions :) ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 12:14:41 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 17 Nov 2016 17:14:41 +0000 Subject: [issue28699] Imap from ThreadPool behaves unexpectedly In-Reply-To: <1479234139.82.0.483433491582.issue28699@psf.upfronthosting.co.za> Message-ID: <1479402881.16.0.781083314837.issue28699@psf.upfronthosting.co.za> Xiang Zhang added the comment: Here is a patch which is just a try. I don't quite like the implementation but I can not figure out a better solution. The examples in this one and #28696 seems to work and no test fails currently. ---------- Added file: http://bugs.python.org/file45522/issue28699_try.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 12:20:44 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 17 Nov 2016 17:20:44 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479403244.78.0.468014783078.issue28727@psf.upfronthosting.co.za> STINNER Victor added the comment: > Ten subtest in test_re fail with: TypeError: unhashable type: '_sre.SRE_Pattern' Oops, right. Updated patch implements also hash() on patterns. ---------- Added file: http://bugs.python.org/file45523/pattern_compare-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 12:25:07 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Nov 2016 17:25:07 +0000 Subject: [issue28708] Low FD_SETSIZE limit on Windows In-Reply-To: <1479250358.07.0.768722440644.issue28708@psf.upfronthosting.co.za> Message-ID: <1479403507.19.0.916707050465.issue28708@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > To implement an efficient event loop, IOCP is the way to do: the asyncio module supports it using ProactorEventLoop. Not everyone uses asyncio, though, so it would still be nice to see the select() limit raised anyway. Implementing your own event loop using IOCP is a hard exercise, much harder than getting something to work with select(). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 12:41:33 2016 From: report at bugs.python.org (Davin Potts) Date: Thu, 17 Nov 2016 17:41:33 +0000 Subject: [issue28699] Imap from ThreadPool behaves unexpectedly In-Reply-To: <1479234139.82.0.483433491582.issue28699@psf.upfronthosting.co.za> Message-ID: <1479404493.34.0.00628981733926.issue28699@psf.upfronthosting.co.za> Davin Potts added the comment: @xiang.zhang: Your patch looks to be introducing a number of changes to the structure of the data being passed around between threads and even monitored/indirectly shared across processes. It's looking increasingly high risk to me. We already have logic for handling exceptions arising during jobs but the one situation overlooked in this logic is if the exception occurs "quickly in an unfortunate order", meaning the exception is encountered and reported before any of the other individual tasks can complete and respond with a result. This oversight of logic can be addressed a couple of ways: 1. Add a flag to our IMapIterator to indicate when any exception is encountered. 2. Modify the tuples / data structures being maintained across IMapIterator's _cache, _items, _unsorted, _index, and _length. 3. Under relevant conditions, check both _items and _unsorted (not only _items) before declaring that we truly have all results in. I regard option 1 as being potentially a bit fragile and option 2 as introducing non-trivial complexity and risk. With option 3, there's effectively no risk and no measurable cost getting to the truth of what has actually happened. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 13:01:51 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 17 Nov 2016 18:01:51 +0000 Subject: [issue28699] Imap from ThreadPool behaves unexpectedly In-Reply-To: <1479234139.82.0.483433491582.issue28699@psf.upfronthosting.co.za> Message-ID: <1479405711.02.0.158531437687.issue28699@psf.upfronthosting.co.za> Xiang Zhang added the comment: > Your patch looks to be introducing a number of changes to the structure of the data being passed around between threads and even monitored/indirectly shared across processes. That's why I say even myself don't like it. To solve an edge case some long introduced codes have to been changed. Sigh. > Under relevant conditions, check both _items and _unsorted (not only _items) before declaring that we truly have all results in. I think you mean your patch. But how does it solve the reentrant problem? Yeah, actually it's not reentrant. If the problematic job is not the first job with id 0, then the exception won't be set. With your patch, repeatedly execute print(list(pool.imap(str, gen()))). Only the first time there is an exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 13:35:43 2016 From: report at bugs.python.org (SilentGhost) Date: Thu, 17 Nov 2016 18:35:43 +0000 Subject: [issue28728] test_host_resolution in test_socket fails on duplicate assert Message-ID: <1479407743.41.0.909577209709.issue28728@psf.upfronthosting.co.za> New submission from SilentGhost: Commit 540a9c69c2ea introduced double assertRaises which now is failing on ubuntu 16.10 If it is necessary, then it's not obvious why and there is no comment, but here is the one-line patch that removes the duplicated line and makes the test pass for me. ---------- components: Tests files: test_socket.diff keywords: patch messages: 281061 nosy: SilentGhost, neologix priority: normal severity: normal stage: patch review status: open title: test_host_resolution in test_socket fails on duplicate assert type: behavior versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45524/test_socket.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 14:00:02 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 17 Nov 2016 19:00:02 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479409202.51.0.46884782139.issue28727@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added comments on Rietveld. ---------- nosy: +serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 14:00:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 17 Nov 2016 19:00:19 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479409219.88.0.367045395873.issue28727@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 14:48:31 2016 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 17 Nov 2016 19:48:31 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> Message-ID: <1479412111.96.0.502881423022.issue25002@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 14:48:42 2016 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 17 Nov 2016 19:48:42 +0000 Subject: [issue25008] Deprecate smtpd (based on deprecated asyncore/asynchat): write a new smtp server with asyncio In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za> Message-ID: <1479412122.04.0.896790844651.issue25008@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 15:37:57 2016 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 17 Nov 2016 20:37:57 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479415077.34.0.357627415669.issue28727@psf.upfronthosting.co.za> Matthew Barnett added the comment: I hope you make it clear what you mean by 'equal', i.e. that it's comparing the pattern and the flags (AFAICT), so re.compile('(?x)a') != re.compile('(?x) a '). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 16:24:27 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 17 Nov 2016 21:24:27 +0000 Subject: [issue28684] [asyncio] bind() on a unix socket raises PermissionError on Android for a non-root user In-Reply-To: <1479069574.19.0.731580166174.issue28684@psf.upfronthosting.co.za> Message-ID: <1479417867.67.0.105318917137.issue28684@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 16:25:12 2016 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 17 Nov 2016 21:25:12 +0000 Subject: [issue28684] [asyncio] bind() on a unix socket raises PermissionError on Android for a non-root user In-Reply-To: <1479069574.19.0.731580166174.issue28684@psf.upfronthosting.co.za> Message-ID: <1479417912.59.0.0122526527235.issue28684@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: -giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 16:28:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 17 Nov 2016 21:28:19 +0000 Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection faulty In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za> Message-ID: <1479418099.43.0.995020268538.issue5322@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here are updated patches with tests for 3.x and 2.7. ---------- components: +Interpreter Core nosy: +serhiy.storchaka stage: -> patch review versions: +Python 2.7, Python 3.5, Python 3.6, Python 3.7 -Python 2.6 Added file: http://bugs.python.org/file45525/update_one_slot2-3.x.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 16:28:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 17 Nov 2016 21:28:37 +0000 Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection faulty In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za> Message-ID: <1479418117.47.0.744047488012.issue5322@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file45526/update_one_slot2-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 18:02:20 2016 From: report at bugs.python.org (Julien Palard) Date: Thu, 17 Nov 2016 23:02:20 +0000 Subject: [issue28724] Add method send_io, recv_io to the socket module. In-Reply-To: <1479395133.65.0.0720889900419.issue28724@psf.upfronthosting.co.za> Message-ID: <1479423740.92.0.896470735443.issue28724@psf.upfronthosting.co.za> Julien Palard added the comment: Hi, thanks for your contribution! Documentation give examples implementation of your methods: - https://docs.python.org/3/library/socket.html#socket.socket.sendmsg - https://docs.python.org/3/library/socket.html#socket.socket.recvmsg and from here, some remarks: - Why allowing people to mix fds and file objects? I'm not a fan of this: I prefer the clarity of allowing only file descriptors. Have you seen such methods (allowing both fd and file obj) in the stdlib? - The documented implementation for recv_io checks for integer truncation, there may be a good reason, should'n you do the same? - The documented implementation allows to pass a message, shouldn't you at least allow for an optional message to be passed? Adding those methods may make sense if people are copying send_fds/recv_fds in their code, but I found only two copy/paste in github, so I think the best is to put your code as a module on pypi and see, from here, if it gets popular? You should also write a few tests, and comply to the PEP8 (your two methods should probably be separated by a newline). Bests ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 18:25:40 2016 From: report at bugs.python.org (Peter Inglesby) Date: Thu, 17 Nov 2016 23:25:40 +0000 Subject: [issue28729] Exception from sqlite3 adapter masked by sqlite3.InterfaceError Message-ID: <1479425140.19.0.0824888445668.issue28729@psf.upfronthosting.co.za> New submission from Peter Inglesby: The following code raises `sqlite3.InterfaceError: Error binding parameter 0 - probably unsupported type.` when I would expect it to raise `AssertionError: Problem in adapter`. import sqlite3 class Point: def __init__(self, x, y): self.x, self.y = x, y def adapt_point(point): assert False, 'Problem in adapter' sqlite3.register_adapter(Point, adapt_point) con = sqlite3.connect(":memory:") cur = con.cursor() p = Point(4.0, -3.2) cur.execute("select ?", (p,)) ---------- messages: 281066 nosy: inglesp priority: normal severity: normal status: open title: Exception from sqlite3 adapter masked by sqlite3.InterfaceError type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 18:39:05 2016 From: report at bugs.python.org (Michael Hu) Date: Thu, 17 Nov 2016 23:39:05 +0000 Subject: [issue28673] When using pyro4 with more than 15 threads, python 2.7.12 cores frequently In-Reply-To: <1478939498.33.0.0967391900201.issue28673@psf.upfronthosting.co.za> Message-ID: <1479425945.35.0.794687927882.issue28673@psf.upfronthosting.co.za> Michael Hu added the comment: Could you please look into the core (attached into this bug) to figure out? This issue does not happen always. We are tight on resource to reproduce this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 19:02:49 2016 From: report at bugs.python.org (Julien Palard) Date: Fri, 18 Nov 2016 00:02:49 +0000 Subject: [issue28729] Exception from sqlite3 adapter masked by sqlite3.InterfaceError In-Reply-To: <1479425140.19.0.0824888445668.issue28729@psf.upfronthosting.co.za> Message-ID: <1479427369.87.0.527575508688.issue28729@psf.upfronthosting.co.za> Julien Palard added the comment: Problems looks from `Modules/_sqlite/statement.c`: ``` if (!_need_adapt(current_param)) { adapted = current_param; } else { adapted = pysqlite_microprotocols_adapt(current_param, (PyObject*)&pysqlite_PrepareProtocolType, NULL); if (adapted) { Py_DECREF(current_param); } else { PyErr_Clear(); adapted = current_param; } } ``` It has not changed since 2006, since e200ab5b3e (backport from pysqlite2 SVN repository). I read it as "If an parameter needs an adapter, and the adapter fails, that's OK, continue with the original (unadapted) parameter.", which looks wrong to me, but I may miss something obvious? I tried to set an error instead of restoring the `current_param` and the 261 tests went well, but I'm not yet aware of the coverage of adapters in tests. ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 19:10:56 2016 From: report at bugs.python.org (Julien Palard) Date: Fri, 18 Nov 2016 00:10:56 +0000 Subject: [issue28729] Exception from sqlite3 adapter masked by sqlite3.InterfaceError In-Reply-To: <1479425140.19.0.0824888445668.issue28729@psf.upfronthosting.co.za> Message-ID: <1479427856.01.0.648059258678.issue28729@psf.upfronthosting.co.za> Julien Palard added the comment: I missed an occurrence of this "if/else" block, and by changing it, a lot of tests are failing, typically: ```====================================================================== ERROR: CheckBlob (sqlite3.test.types.SqliteTypeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/mdk/cpython/Lib/sqlite3/test/types.py", line 72, in CheckBlob self.cur.execute("insert into test(b) values (?)", (val,)) sqlite3.InterfaceError: Problem in adapter ``` So this "if/else" giving back the unadapted parameter even when need_adapt is true is necessary, we'll have to understand why and how we can properly detect an adapter failure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 20:31:03 2016 From: report at bugs.python.org (Jeff Reback) Date: Fri, 18 Nov 2016 01:31:03 +0000 Subject: [issue28730] __reduce__ not being called in dervied extension class from datetime.datetime Message-ID: <1479432663.49.0.198725524634.issue28730@psf.upfronthosting.co.za> New submission from Jeff Reback: xref to https://github.com/pandas-dev/pandas/issues/14679. pandas has had a cython extension class to datetime.datetime for quite some time. A simple __reduce__ is defined. def __reduce__(self): object_state = self.value, self.freq, self.tzinfo print(object_state) return (Timestamp, object_state) In 3.5.2: Python 3.5.2 |Continuum Analytics, Inc.| (default, Jul 2 2016, 17:52:12) [GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import pandas as pd >>> import pickle >>> pickle.dumps(pd.Timestamp('20130101')) (1356998400000000000, None, None) b'\x80\x03cpandas.tslib\nTimestamp\nq\x00\x8a\x08\x00\x00\xc6\xe8\xda\x06\xd5\x12NN\x87q\x01Rq\x02.' But in 3.6.03b Python 3.6.0b3 | packaged by conda-forge | (default, Nov 2 2016, 03:28:12) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.54)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import pandas as pd >>> import pickle >>> pickle.dumps(pd.Timestamp('20130101')) b'\x80\x03cpandas.tslib\nTimestamp\nq\x00C\n\x07\xdd\x01\x01\x00\x00\x00\x00\x00\x00q\x01\x85q\x02Rq\x03.' So it appears __reduce__ is no longer called at all (I tried defining __getstate__, __getnewargs__ as well, but to no avail). Instead it looks like datetime.datetime.__reduce__ (well a c function is actually called). Link to the codebase. https://github.com/pandas-dev/pandas/blob/master/pandas/tslib.pyx#L490 ---------- components: IO messages: 281070 nosy: Jeff Reback priority: normal severity: normal status: open title: __reduce__ not being called in dervied extension class from datetime.datetime type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 20:36:16 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 18 Nov 2016 01:36:16 +0000 Subject: [issue28728] test_host_resolution in test_socket fails on duplicate assert In-Reply-To: <1479407743.41.0.909577209709.issue28728@psf.upfronthosting.co.za> Message-ID: <1479432976.23.0.506892438029.issue28728@psf.upfronthosting.co.za> Martin Panter added the comment: That?s not exactly a duplicate; one is host-by-NAME, the other host-by-ADDR ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 20:53:10 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 18 Nov 2016 01:53:10 +0000 Subject: [issue28728] test_host_resolution in test_socket fails on duplicate assert In-Reply-To: <1479407743.41.0.909577209709.issue28728@psf.upfronthosting.co.za> Message-ID: <1479433990.98.0.255588251903.issue28728@psf.upfronthosting.co.za> R. David Murray added the comment: It might be interesting to stick a 'with subtest' in there and see which address is failing to raise. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 21:32:45 2016 From: report at bugs.python.org (Simon Holland) Date: Fri, 18 Nov 2016 02:32:45 +0000 Subject: [issue28723] tkinter, radiobutton, indicatoron=0 has no effect. In-Reply-To: Message-ID: Simon Holland added the comment: FYI, it seems that the Tk team are unable to use cocoa for this functionality so indicatoron has not worked on OSX for Radiobuttons or Checkbuttons for over 4 years. On 17 November 2016 at 18:21, Simon Holland wrote: > > Simon Holland added the comment: > > Thank you > > On 17 November 2016 at 15:29, Serhiy Storchaka > wrote: > > > > > Serhiy Storchaka added the comment: > > > > Works to me on Linux (identical results with Tkinter and Tk). In any case > > if there is some bug on your platform, this is not Tkinter bug, but Tk > bug. > > Tkinter doesn't handle this option specially, it just pass it to Tk. > File a > > bug on Tk bugtracker: http://core.tcl.tk/tk/ticket . > > > > ---------- > > resolution: -> third party > > stage: -> resolved > > status: open -> closed > > > > _______________________________________ > > Python tracker > > > > _______________________________________ > > > > -- > > Simon Holland BA Hons > Medan, Indonesia > -------------------- > Mobile : +62 81 26055297 > Fax : +62 81 6613280 > > [image: Twitter] [image: LinkedIn] > [image: YouTube] > [image: Google Talk] > > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > -- Simon Holland BA Hons Medan, Indonesia -------------------- Mobile : +62 81 26055297 Fax : +62 81 6613280 [image: Twitter] [image: LinkedIn] [image: YouTube] [image: Google Talk] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 17 22:36:24 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Fri, 18 Nov 2016 03:36:24 +0000 Subject: [issue20572] subprocess.Popen.wait() undocumented "endtime" parameter In-Reply-To: <1391941400.18.0.703922206544.issue20572@psf.upfronthosting.co.za> Message-ID: <1479440184.05.0.661489377213.issue20572@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: 1. So, is it ok to remove the endtime parameter now? 2. Can the attached downloadfile.htm be removed? It's a spam. Thanks :) ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 00:19:52 2016 From: report at bugs.python.org (Bert JW Regeer) Date: Fri, 18 Nov 2016 05:19:52 +0000 Subject: [issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition In-Reply-To: <1471355745.98.0.805545529346.issue27777@psf.upfronthosting.co.za> Message-ID: <1479446392.94.0.656670666768.issue27777@psf.upfronthosting.co.za> Bert JW Regeer added the comment: @berker.peksag: Attached is a patch with a test case that exercises this issue. Code path is that read_single() checks if the length is greater than 0, and then it reads binary, otherwise it reads it as a single line. This fixes make_file so that if self.length is greater than or equal to 0, it opens the file in binary mode, this matches the checks that write stuff as binary. This also undoes the change that was made in https://bugs.python.org/issue24764. Fixing this issue fixed that one as well, and arguably throwing data away doesn't seem like a good idea. ---------- keywords: +patch Added file: http://bugs.python.org/file45527/bug27777.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 00:21:51 2016 From: report at bugs.python.org (Bert JW Regeer) Date: Fri, 18 Nov 2016 05:21:51 +0000 Subject: [issue24764] cgi.FieldStorage can't parse multipart part headers with Content-Length and no filename in Content-Disposition In-Reply-To: <1438358841.56.0.603079767616.issue24764@psf.upfronthosting.co.za> Message-ID: <1479446511.53.0.643583731386.issue24764@psf.upfronthosting.co.za> Bert JW Regeer added the comment: I've uploaded a patchset to bug #27777 that fixes this issue by fixing make_file, and doesn't cause Python to throw out the content-length information. It also fixes FieldStorage for when you provide it a non-multipart form submission and there is no list in FS. Please see http://bugs.python.org/issue27777 ---------- nosy: +X-Istence _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 01:20:05 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Nov 2016 06:20:05 +0000 Subject: [issue28730] __reduce__ not being called in dervied extension class from datetime.datetime In-Reply-To: <1479432663.49.0.198725524634.issue28730@psf.upfronthosting.co.za> Message-ID: <1479450005.75.0.532858273917.issue28730@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: That is because some datetime classes now define __reduce_ex__ instead of __reduce__ (see issue24773). It has higher priority. ---------- nosy: +belopolsky, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 01:20:59 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Fri, 18 Nov 2016 06:20:59 +0000 Subject: [issue28159] Deprecate isdst argument in email.utils.localtime In-Reply-To: <1473890113.79.0.964863330823.issue28159@psf.upfronthosting.co.za> Message-ID: <1479450059.01.0.356989173604.issue28159@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Hi Alexander, Is the idea here to raise deprecation warning starting in 3.6 and remove it by 3.8? Thanks :) ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 02:19:29 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 18 Nov 2016 07:19:29 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings In-Reply-To: <1479128206.47.0.155651436814.issue28688@psf.upfronthosting.co.za> Message-ID: <1479453569.21.0.0695799825104.issue28688@psf.upfronthosting.co.za> Martin Panter added the comment: I didn?t really like adding the _add_filter() special handling in the first place, but I went ahead because I couldn?t think of a better way to avoid the problem with reloading the warnings modules. So unless anyone can suggest anything better, I am okay with your patch (even if you dislike it :). + return (item[0], _pattern_key(item[1]), item[2], _pattern_key(item[3])) The key is based on (action, message, category, module). I think you should add item[4] (lineno). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 02:39:27 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 07:39:27 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings In-Reply-To: <1479453569.21.0.0695799825104.issue28688@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > The key is based on (action, message, category, module). I think you should add item[4] (lineno). Oops, right! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 02:44:08 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 07:44:08 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings In-Reply-To: <1479128206.47.0.155651436814.issue28688@psf.upfronthosting.co.za> Message-ID: <1479455048.88.0.840811561798.issue28688@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, let me propose a plan for 3.5, 3.6 and 3.7: * Remove warnings.filters test on Python 3.5 from regrtest * Implement comparison for SRE_Pattern in Python 3.6 and 3.7: issue #28727 I consider that the issue #28727 is a minor enhancement and so is still good for Python 3.6. So we avoid the ugly *warnings_key.patch*. Reminder: this issue only occurs in the Python test suite which explicitly reloads modules. It should not occur in the wild. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 02:46:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Nov 2016 07:46:24 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings In-Reply-To: <1479128206.47.0.155651436814.issue28688@psf.upfronthosting.co.za> Message-ID: <1479455184.44.0.544143528205.issue28688@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Your plan LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 02:57:02 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 07:57:02 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479455822.97.0.295965709537.issue28727@psf.upfronthosting.co.za> STINNER Victor added the comment: Patch version 3: * pattern_hash() includes isbytes, I also shifted flags by 1 bit to not erase the isbytes bit (FYI maximum value of flags is 256) * pattern_richcompare() avoids calling PyObject_RichCompareBool() if flags or isbytes is different * unit test ensures that no BytesWarning warning is raised * checks hash() in unit tests * fix also the unit test with a different flag (use the same pattern) * document also in the unit test that the comparison is case sensitive ---------- Added file: http://bugs.python.org/file45528/pattern_compare-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 03:47:28 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 08:47:28 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479458848.18.0.289647358163.issue28727@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I hope that it's the last attempt: patch 5 * Remove hash(b) != hash(a): only keep tests on hash(b)==hash(a) when b==a * Replace re.ASCII flag with no flag to test two patterns with different flags ---------- Added file: http://bugs.python.org/file45529/pattern_compare-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 04:04:52 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 18 Nov 2016 09:04:52 +0000 Subject: [issue20572] subprocess.Popen.wait() undocumented "endtime" parameter In-Reply-To: <1391941400.18.0.703922206544.issue20572@psf.upfronthosting.co.za> Message-ID: <1479459892.53.0.101561845034.issue20572@psf.upfronthosting.co.za> Changes by Martin Panter : Removed file: http://bugs.python.org/file42579/downloadfile.htm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 04:06:10 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 18 Nov 2016 09:06:10 +0000 Subject: [issue20572] subprocess.Popen.wait() undocumented "endtime" parameter In-Reply-To: <1391941400.18.0.703922206544.issue20572@psf.upfronthosting.co.za> Message-ID: <1479459970.79.0.988131274801.issue20572@psf.upfronthosting.co.za> Martin Panter added the comment: I think other people wanted to add an automated deprecation warning in the code first, before removing it. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 04:07:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Nov 2016 09:07:54 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479460074.22.0.0729182192522.issue28727@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is a problem with locale-depending flags. The same pattern may be compiled with the LOCALE flag to different pattern objects in different locales. Perhaps we should compare the compiled code instead of pattern strings. Or both. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 04:15:16 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 09:15:16 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479460516.78.0.897563730332.issue28727@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy: "There is a problem with locale-depending flags. The same pattern may be compiled with the LOCALE flag to different pattern objects in different locales." Oh, I didn't know and you are right. "Perhaps we should compare the compiled code instead of pattern strings. Or both." PatternObject contains many fields. I used the following two fields which come from re.compile(): * pattern * flags I considered that they were enough because pattern_repr() only displays these ones. Other fields: * groups * groupindex * indexgroup * weakreflist * isbytes * codesize, code weakreflist can be skipped, isbytes is already tested in my patch. Would it be possible to only compare code instead of pattern? What are groups, groupindex and indexgroup: should we also compare them? Maybe I can start from pattern_compare-4.patch and only add a test comparing code? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 04:35:26 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Nov 2016 09:35:26 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479461726.82.0.899215201384.issue28727@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: '[abc]' and '[cba]' are compiled to the same code. Do we want to handle them as equal? This is implementation defined. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 05:08:08 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 18 Nov 2016 10:08:08 +0000 Subject: [issue28724] Add method send_io, recv_io to the socket module. In-Reply-To: <1479395133.65.0.0720889900419.issue28724@psf.upfronthosting.co.za> Message-ID: <1479463688.02.0.460562428336.issue28724@psf.upfronthosting.co.za> INADA Naoki added the comment: FYI, multiprocessing.reduction module has send_fds and recv_fds. ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 05:31:45 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 18 Nov 2016 10:31:45 +0000 Subject: [issue26928] _bootlocale imports locale at startup on Android, causing test_site to fail In-Reply-To: <1462284365.5.0.819379627022.issue26928@psf.upfronthosting.co.za> Message-ID: <1479465105.46.0.710809254248.issue26928@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Patch that follows closely the conditionals in the __bootlocale module. ---------- stage: patch review -> commit review Added file: http://bugs.python.org/file45530/skip_test_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 05:55:49 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 10:55:49 +0000 Subject: [issue26928] _bootlocale imports locale at startup on Android, causing test_site to fail In-Reply-To: <1462284365.5.0.819379627022.issue26928@psf.upfronthosting.co.za> Message-ID: <1479466549.94.0.639185818834.issue26928@psf.upfronthosting.co.za> STINNER Victor added the comment: > The problem is caused by the fact that android does not have HAVE_LANGINFO_H and CODESET set Hum, is it possible to get the locale encoding by another way? If not, what is the locale encoding? Does Android provide mbstowcs() and wcstombs() functions? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 06:03:05 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 18 Nov 2016 11:03:05 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict Message-ID: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za> New submission from INADA Naoki: _PyDict_NewPresized(6) creates dict which keysize is 8. But it's capacity is 5 (8 * 2 // 3 = 5). This internal API is used by BUILD_MAP and BUILD_CONST_KEYMAP. ---------- assignee: inada.naoki files: PyDict_NewPresized-too-small.patch keywords: patch messages: 281092 nosy: haypo, inada.naoki priority: high severity: normal stage: patch review status: open title: _PyDict_NewPresized() creates too small dict type: performance versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45531/PyDict_NewPresized-too-small.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 06:08:28 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 18 Nov 2016 11:08:28 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za> Message-ID: <1479467308.33.0.107267316387.issue28731@psf.upfronthosting.co.za> INADA Naoki added the comment: This patch includes fix for ESTIMATE_SIZE macro. (see below) Same fix is included in patch for issue28147. >>> def estimate_size(n): ... return n * 3 // 2 # Current ESTIMATE_SIZE ... >>> def usable(n): ... return n * 2 // 3 ... >>> def keysize(minsize): ... size = 8 ... while size < minsize: # Current implementation uses <= ... size *= 2 ... return size ... >>> def check(): ... for i in range(1000): ... estimate = estimate_size(i) ... size = keysize(estimate) ... cap = usable(size) ... if cap < i: ... print(i, estimate, size, cap) ... >>> check() 11 16 16 10 43 64 64 42 171 256 256 170 683 1024 1024 682 >>> # >>> estimate_size = lambda n: (n * 3 +1) // 2 # Fixed version >>> check() >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 06:13:45 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 11:13:45 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479461726.82.0.899215201384.issue28727@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > '[abc]' and '[cba]' are compiled to the same code. Do we want to handle them as equal? Comparison must be fast. If the comparison is just memcmp(code1, code2, codesize), it's ok. I agree that we must put a similar somewhere to say that some parts are implementation details. Maybe split the test in two parts, and mark the second part with @cpython_only. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 06:22:35 2016 From: report at bugs.python.org (srinivasaraoMaddukuri) Date: Fri, 18 Nov 2016 11:22:35 +0000 Subject: [issue28732] spawnl crash on windows7 Message-ID: <1479468155.36.0.0223780421373.issue28732@psf.upfronthosting.co.za> New submission from srinivasaraoMaddukuri: in window7 (using python 3.4.3,3.5.2) following script crashes import os os.spawnl( os.P_NOWAIT, 'C:/Tcl/bin/tclsh.exe' )" Note: similar issue is already exist https://bugs.python.org/issue8036 ---------- components: Interpreter Core messages: 281095 nosy: srinim priority: normal severity: normal status: open title: spawnl crash on windows7 type: crash versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 06:24:04 2016 From: report at bugs.python.org (srinivasaraoMaddukuri) Date: Fri, 18 Nov 2016 11:24:04 +0000 Subject: [issue28732] spawnl crash on windows7 In-Reply-To: <1479468155.36.0.0223780421373.issue28732@psf.upfronthosting.co.za> Message-ID: <1479468244.41.0.821575052371.issue28732@psf.upfronthosting.co.za> srinivasaraoMaddukuri added the comment: small correction (removed " ) import os os.spawnl( os.P_NOWAIT, 'C:/Tcl/bin/tclsh.exe' ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 06:25:08 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 11:25:08 +0000 Subject: [issue28732] spawnl crash on windows7 In-Reply-To: <1479468155.36.0.0223780421373.issue28732@psf.upfronthosting.co.za> Message-ID: <1479468308.55.0.978560645056.issue28732@psf.upfronthosting.co.za> STINNER Victor added the comment: Just to make sure: a crash means that the Python process is killed and you get a popup or something like that? Can you please try to run the script on Python 3.6 using: python.exe -X faulthandler script.py It should display the Windows error code at least. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 06:26:54 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 18 Nov 2016 11:26:54 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za> Message-ID: <1479468414.48.0.350108179051.issue28731@psf.upfronthosting.co.za> INADA Naoki added the comment: current: $ ~/work/python36/bin/python3 -m perf timeit -- 'd = {"a":1, "b":2, "c":3, "d":4, "e":5, "f":6}' ..................... Median +- std dev: 925 ns +- 49 ns patched: $ ~/work/python36/bin/python3 -m perf timeit -- 'd = {"a":1, "b":2, "c":3, "d":4, "e":5, "f":6}' ..................... Median +- std dev: 726 ns +- 30 ns ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 06:26:55 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 11:26:55 +0000 Subject: [issue28732] spawnl crash on windows7 In-Reply-To: <1479468155.36.0.0223780421373.issue28732@psf.upfronthosting.co.za> Message-ID: <1479468415.51.0.239892697918.issue28732@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 06:31:12 2016 From: report at bugs.python.org (Jeff Reback) Date: Fri, 18 Nov 2016 11:31:12 +0000 Subject: [issue28730] __reduce__ not being called in dervied extension class from datetime.datetime In-Reply-To: <1479432663.49.0.198725524634.issue28730@psf.upfronthosting.co.za> Message-ID: <1479468672.78.0.795995185106.issue28730@psf.upfronthosting.co.za> Jeff Reback added the comment: ok thanks for the info. fixed in pandas here: https://github.com/pandas-dev/pandas/pull/14689 is this documented in the whatsnew? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 06:38:18 2016 From: report at bugs.python.org (Jelte Fennema) Date: Fri, 18 Nov 2016 11:38:18 +0000 Subject: [issue26273] Expose TCP_CONGESTION and TCP_USER_TIMEOUT to the socket module In-Reply-To: <1454489684.49.0.598051421532.issue26273@psf.upfronthosting.co.za> Message-ID: <1479469098.69.0.551011731457.issue26273@psf.upfronthosting.co.za> Jelte Fennema added the comment: Is there any issue in merging this? TCP_USER_TIMEOUT is quite useful, for automatic failover of connections that suddenly died. ---------- nosy: +JelteF _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 06:45:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Nov 2016 11:45:19 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479469519.28.0.373929240811.issue28727@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I see two options: * Compare flags, isbytes and code. This makes some different patterns be compiled to equal objects. For example spaces in verbose mode are ignored. But this don't make equal all equivalent patterns. '[aA]' would be equal to '(?:a|A)' but still would be not equal to '(i?a)' with current implementation. * Compare flags, isbytes, code and pattern. This makes literally different patterns be compiled to not equal objects even if the difference is not significant. '[abc]' would be different from '[cba]' despites the fact that matching both always returns the same result. Since this issue becomes a little ambiguous, I would target the patch to 3.7 only. Maybe we will find other subtle details or will decide to change the meaning of equality of pattern objects before releasing 3.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 06:57:03 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Fri, 18 Nov 2016 11:57:03 +0000 Subject: [issue20572] subprocess.Popen.wait() undocumented "endtime" parameter In-Reply-To: <1391941400.18.0.703922206544.issue20572@psf.upfronthosting.co.za> Message-ID: <1479470223.68.0.645041461767.issue20572@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks, Martin :) Attached is the patch where deprecation warning is emitted if endtime argument is passed. Let me know if this works. Thanks :) ---------- keywords: +patch Added file: http://bugs.python.org/file45532/issue20572.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 07:04:02 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Fri, 18 Nov 2016 12:04:02 +0000 Subject: [issue26928] _bootlocale imports locale at startup on Android, causing test_site to fail In-Reply-To: <1462284365.5.0.819379627022.issue26928@psf.upfronthosting.co.za> Message-ID: <1479470642.81.0.390008878208.issue26928@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Seems Android/BioniC always uses UTF-8: https://android.googlesource.com/platform/bionic/+/master/libc/bionic/mbrtoc32.cpp#83 ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 07:04:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Nov 2016 12:04:13 +0000 Subject: [issue28730] __reduce__ not being called in dervied extension class from datetime.datetime In-Reply-To: <1479432663.49.0.198725524634.issue28730@psf.upfronthosting.co.za> Message-ID: <1479470653.35.0.392676170557.issue28730@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It seems to me that this is not documented. I'm even not sure that this change is compatible. Additional bit is saved only with protocol 4. The default protocol is 3, thus your should explicitly specify it. But protocol 4 is supported since 3.4. It seems to me that if you pickle the datetime object with the fold bit set with protocol 4, you could get invalid result when unpickle it in 3.4 and 3.5. Yet one doubtful detail is that the fold bit is added to the hour bit in datetime.time, but to the month field in datetime.datetime. In any case __reduce_ex__ has the highest priority. After implementing it your can be sure that it would be used. ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 07:18:49 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 12:18:49 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479468414.48.0.350108179051.issue28731@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: FYI if you rename Python binaries, you can use: ./python-patched perf timeit --compare-to=./python-orig ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 07:18:50 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 12:18:50 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479468414.48.0.350108179051.issue28731@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Median +- std dev: 925 ns +- 49 ns > Median +- std dev: 726 ns +- 30 ns Nice speedup. Can you please compare Python 3.5? Better if you compile it yourself with the same options. I'm curious if 925 ns is slower than py3.5 or if 726 ns is faster than py3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 07:22:30 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 12:22:30 +0000 Subject: [issue26928] _bootlocale imports locale at startup on Android, causing test_site to fail In-Reply-To: <1479470642.81.0.390008878208.issue26928@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: If it is not possible to change the locale, it makes sense to hardcode utf8. Note: to avoid mojibake, it's better if sys.getfilesystemencoding() and locale.getpreferredencoding(False) are equal. I understand that both must be utf8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 07:31:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Nov 2016 12:31:58 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za> Message-ID: <1479472318.01.0.342885521632.issue28731@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The condition in the loop in _PyDict_NewPresized() contains the test newsize > 0. This is a check for integer overflow. But it doesn't make much sense. First, the overflow is undefined behavior, and it is too late to detect it when it already is happen. Second, after detecting the negative value just is passed to new_keys_object() which either is crashed in debug build or makes other integer overflow and creates invalid object. I would add a runtime check that minused is less than PY_SSIZE_MAX/3 (or more strong PY_SSIZE_MAX/3*2/sizeof(Pobject *)). This would guarantee that integer overflow is not possible. The test "newsize > 0" could be removed. There is similar code in dictresize(). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 07:49:04 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 18 Nov 2016 12:49:04 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za> Message-ID: <1479473344.32.0.0305884112253.issue28731@psf.upfronthosting.co.za> INADA Naoki added the comment: inada-n at test1:~/work/py36$ ~/local/py36/bin/patched -m perf timeit --compare-to ~/local/py36/bin/master -- 'd = {"a":1, "b":2, "c":3, "d":4, "e":5, "f":6}' master: ..................... 910 ns +- 49 ns patched: ..................... 713 ns +- 26 ns Median +- std dev: [master] 910 ns +- 49 ns -> [patched] 713 ns +- 26 ns: 1.28x faster inada-n at test1:~/work/py36$ ~/local/py36/bin/patched -m perf timeit --compare-to ~/local/py35/bin/python3.5 -- 'd = {"a":1, "b":2, "c":3, "d":4, "e":5, "f":6}' python3.5: ..................... 1.17 us +- 0.06 us patched: ..................... 720 ns +- 24 ns Median +- std dev: [python3.5] 1.17 us +- 0.06 us -> [patched] 720 ns +- 24 ns: 1.62x faster ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 07:52:19 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Fri, 18 Nov 2016 12:52:19 +0000 Subject: [issue26928] _bootlocale imports locale at startup on Android, causing test_site to fail In-Reply-To: <1462284365.5.0.819379627022.issue26928@psf.upfronthosting.co.za> Message-ID: <1479473539.59.0.449329504571.issue26928@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: There are some locale strings supported in setlocale(): https://android.googlesource.com/platform/bionic/+/master/libc/bionic/locale.cpp#104. However, seems mbstowcs just ignores such a setting on Android. Here's an example: #include #include #include #include #define BUFFER_SIZE 10 void test_mbstowcs() { wchar_t dest[BUFFER_SIZE]; memset(dest, 0, sizeof(dest)); printf("mbstowcs: %ld\n", mbstowcs(dest, "??", BUFFER_SIZE)); printf("dest: %x %x\n", dest[0], dest[1]); } int main() { printf("setlocale: %d\n", setlocale(LC_ALL, "en_US.UTF-8") != NULL); test_mbstowcs(); printf("setlocale: %d\n", setlocale(LC_ALL, "C") != NULL); test_mbstowcs(); return 0; } On Linux (glibc 2.24) the result is: $ ./a.out setlocale: 1 mbstowcs: 2 dest: 4e2d 6587 setlocale: 1 mbstowcs: -1 dest: 0 0 On Android (6.0 Marshmallow) the result is: shell at ASUS_Z00E_2:/ $ /data/local/tmp/a.out setlocale: 1 mbstowcs: 2 dest: 4e2d 6587 setlocale: 1 mbstowcs: 2 dest: 4e2d 6587 A quick search indicates setlocale() affects *scanf functions only, so I guess it's safe to force UTF-8 in CPython. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 07:55:29 2016 From: report at bugs.python.org (Eryk Sun) Date: Fri, 18 Nov 2016 12:55:29 +0000 Subject: [issue28732] spawnl crash on windows7 In-Reply-To: <1479468155.36.0.0223780421373.issue28732@psf.upfronthosting.co.za> Message-ID: <1479473729.88.0.565382911198.issue28732@psf.upfronthosting.co.za> Eryk Sun added the comment: spawnl is implemented by calling _spawnv [1], which is documented to invoke the invalid parameter handler if argv points to a NULL pointer. It wants the program name, or whatever, as long as argv[0] isn't NULL or an empty string, e.g. `os.spawnl(os.P_NOWAIT, 'C:/Tcl/bin/tclsh.exe', 'tclsh')`. The invalid parameter handler should be disabled (_Py_BEGIN_SUPPRESS_IPH) when calling _spawnv[e], which in this case would lead to an EINVAL OSError instead of crashing the process. For example: import os, sys from ctypes import * ucrt = CDLL('ucrtbase') @CFUNCTYPE(None, c_wchar_p, c_wchar_p, c_wchar_p, c_int, c_void_p) def iph(*args): pass ucrt._set_thread_local_invalid_parameter_handler(iph) >>> os.spawnl(os.P_NOWAIT, sys.executable) Traceback (most recent call last): File "", line 1, in File "C:\Program Files\Python35\lib\os.py", line 977, in spawnl return spawnv(mode, file, args) OSError: [Errno 22] Invalid argument Also, in this case a descriptive ValueError would be friendlier, given an empty argv or argv[0] that's an empty string -- at least on Windows. [1]: https://msdn.microsoft.com/en-us/library/7zt1y878.aspx ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 07:56:13 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 18 Nov 2016 12:56:13 +0000 Subject: [issue28730] __reduce__ not being called in dervied extension class from datetime.datetime In-Reply-To: <1479470653.35.0.392676170557.issue28730@psf.upfronthosting.co.za> Message-ID: Alexander Belopolsky added the comment: > On Nov 18, 2016, at 7:04 AM, Serhiy Storchaka wrote: > > Yet one doubtful detail is that the fold bit is added to the hour bit in datetime.time, but to the month field in datetime.datetime. The reason behind this choice is documented in PEP 495: "We picked these bytes because they are the only bytes that are checked by the current unpickle code. Thus loading post-PEP fold=1 pickles in a pre-PEP Python will result in an exception rather than an instance with out of range components." https://www.python.org/dev/peps/pep-0495/#pickles ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 07:57:45 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 18 Nov 2016 12:57:45 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za> Message-ID: <1479473865.06.0.999811305772.issue28731@psf.upfronthosting.co.za> INADA Naoki added the comment: Python 3.5 has similar issue: $ ~/local/py35/bin/patched -m perf timeit --compare-to ~/local/py35/bin/master -- 'd = {"a":1, "b":2, "c":3, "d":4, "e":5, "f":6}' master: ..................... 1.15 us +- 0.09 us patched: ..................... 885 ns +- 37 ns Median +- std dev: [master] 1.15 us +- 0.09 us -> [patched] 885 ns +- 37 ns: 1.30x faster patch: diff -r 20f62e4a9c2f Objects/dictobject.c --- a/Objects/dictobject.c Wed Nov 16 16:32:22 2016 -0800 +++ b/Objects/dictobject.c Fri Nov 18 12:56:38 2016 +0000 @@ -1015,8 +1015,9 @@ PyObject * { Py_ssize_t newsize; PyDictKeysObject *new_keys; + minused = (minused * 3 + 1) / 2; for (newsize = PyDict_MINSIZE_COMBINED; - newsize <= minused && newsize > 0; + newsize < minused && newsize > 0; newsize <<= 1) ; new_keys = new_keys_object(newsize); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 08:17:52 2016 From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Bultrowicz?=) Date: Fri, 18 Nov 2016 13:17:52 +0000 Subject: [issue28733] Show how to use mock_open in modules other that __main__ Message-ID: <1479475072.8.0.338397997846.issue28733@psf.upfronthosting.co.za> New submission from Micha? Bultrowicz: Documentation of mock_open doesn't say how to use it in real-life test situations (when you're probably not mocking in __main__). I've spent some time scratching my head and googling for the way to mock-out the "open" function, want to spare other people the hassle. The thing is that "open" needs to be mocked out from the magical "builtins" module, and not from the place of usage (like when mocking everything that's not built-in). So it's not obvious how to do that, especially that the example with __main__ makes it look like the normal mocking approach should work. I still don't fully understand why mocking "__main__.open" can work from interpreter, but that's a different thing... ---------- assignee: docs at python components: Documentation files: mock_open_doc.patch keywords: patch messages: 281114 nosy: butla, docs at python priority: normal severity: normal status: open title: Show how to use mock_open in modules other that __main__ type: enhancement versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45533/mock_open_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 08:28:31 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 13:28:31 +0000 Subject: [issue26928] _bootlocale imports locale at startup on Android, causing test_site to fail In-Reply-To: <1479473539.59.0.449329504571.issue26928@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: In Python, the most important functions are Py_DecodeLocale() and Py_EncodeLocale() which use mbstowcs() and wvstombs(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 08:31:05 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 13:31:05 +0000 Subject: [issue28732] spawnl crash on windows7 In-Reply-To: <1479473729.88.0.565382911198.issue28732@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I like the idea of using _Py_BEGIN_SUPPRESS_IPH, but also the idea of implementing most obvious checks on arguments. Sadly, I don't have access to Windows yet to write such patch. Eryk, if you write such patch, I would be happy to review it ;-) Especially if it includes unit tests :-D ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 08:33:15 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 13:33:15 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za> Message-ID: <1479475995.08.0.938241188856.issue28731@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, it's an optimization, not a performance regression of Python 3.6. In this case, I suggest to first push the change to Python 3.7, and after 3.6.0 release, backport to 3.6 (if you want to), and maybe even 3.5 if it makes sense (and if you want). I didn't review the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 08:49:04 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 18 Nov 2016 13:49:04 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479472318.01.0.342885521632.issue28731@psf.upfronthosting.co.za> Message-ID: INADA Naoki added the comment: On Fri, Nov 18, 2016 at 9:31 PM, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > The condition in the loop in _PyDict_NewPresized() contains the test newsize > 0. This is a check for integer overflow. But it doesn't make much sense. First, the overflow is undefined behavior, and it is too late to detect it when it already is happen. Second, after detecting the negative value just is passed to new_keys_object() which either is crashed in debug build or makes other integer overflow and creates invalid object. > > I would add a runtime check that minused is less than PY_SSIZE_MAX/3 (or more strong PY_SSIZE_MAX/3*2/sizeof(Pobject *)). This would guarantee that integer overflow is not possible. The test "newsize > 0" could be removed. > > There is similar code in dictresize(). > Nice idea. I'll update patch in issue28147. In case of _PyDict_NewPresized(minused), it would be called from 3rd party libraries, and there are no strong guarantee about PyDict_SetItem() won't resize until minused items. So how about more small, maximum presize? #define MAX_INITSIZE (128 * 1024) if (minused > USABLE_FRACTION(MAX_INITSIZE)) { newsize = MAX_INITSIZE; } else { newsize = PyDict_MINSIZE; whilie (newsize < minused) newsize <<= 1; // Can't we assume *= 2 is optimized? }; ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 08:49:43 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Nov 2016 13:49:43 +0000 Subject: [issue28730] __reduce__ not being called in dervied extension class from datetime.datetime In-Reply-To: <1479432663.49.0.198725524634.issue28730@psf.upfronthosting.co.za> Message-ID: <1479476983.13.0.79655864051.issue28730@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your explanation Alexander. It looks reasonable. But there are two drawbacks. 1. By default the fold bit is ignored. That means that you lost it when use multiprocessing or other library that uses default pickle protocol. 2. It is not easy to make a workaround for pickles with fold=1 in pre-PEP Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 08:52:22 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 13:52:22 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za> Message-ID: <1479477142.28.0.139206474622.issue28731@psf.upfronthosting.co.za> STINNER Victor added the comment: Even if the use case is limited (creation of small dictionaries), it's a nice enhancement, good job Naoki! It's nice to see someone looking at this very important Python type! 1.28x faster or 1.62x faster is significant for a micro-optimization! (My personal threshold is at least 10% faster for a micro-optimization.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 08:58:43 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Nov 2016 13:58:43 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za> Message-ID: <1479477523.88.0.883613380351.issue28731@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > So how about more small, maximum presize? I don't know what is the benefit of this, but this change looks correct. The benefit of preresizing is vanishingly small for very large dicts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 09:09:11 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Nov 2016 14:09:11 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za> Message-ID: <1479478151.35.0.613830788507.issue28731@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This optimization affects only 6-element (and perhaps to less extend 11-element) dicts. But in any case this is good enhancement. Naoki, could you please make microbenchmarks for 5- and 7-element dicts with your next patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 09:14:29 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 18 Nov 2016 14:14:29 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: Message-ID: INADA Naoki added the comment: Can I assume PY_SSIZE_T_MAX is 2**n-1? If so, I can define like: #define PyDict_MAXSIZE (PY_SSIZE_T/8+1) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 09:19:11 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 14:19:11 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: Message-ID: STINNER Victor added the comment: > Can I assume PY_SSIZE_T_MAX is 2**n-1? I think so. Add an assertion just to be sure :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 09:31:23 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 18 Nov 2016 14:31:23 +0000 Subject: [issue28159] Deprecate isdst argument in email.utils.localtime In-Reply-To: <1473890113.79.0.964863330823.issue28159@psf.upfronthosting.co.za> Message-ID: <1479479483.71.0.220049498818.issue28159@psf.upfronthosting.co.za> R. David Murray added the comment: At this point I think the deprecation warning will go into 3.7, but we should be able to remove it in 3.8. I think I'll probably keep the 'localtime' method and have it delegate it to astimezone, because frankly I would never be able to remember that that was the datetime method I needed to get localtime. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 09:57:16 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 18 Nov 2016 14:57:16 +0000 Subject: [issue28730] __reduce__ not being called in dervied extension class from datetime.datetime In-Reply-To: <1479476983.13.0.79655864051.issue28730@psf.upfronthosting.co.za> Message-ID: <2C4E6248-114D-445F-BB6D-9C7791AAADA3@gmail.com> Alexander Belopolsky added the comment: > On Nov 18, 2016, at 8:49 AM, Serhiy Storchaka wrote: > > But there are two drawbacks. It is not too late to make improvements. If you have specific proposals - please bring them up on the mailing list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 10:18:29 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Fri, 18 Nov 2016 15:18:29 +0000 Subject: [issue28159] Deprecate isdst argument in email.utils.localtime In-Reply-To: <1473890113.79.0.964863330823.issue28159@psf.upfronthosting.co.za> Message-ID: <1479482309.08.0.395989205719.issue28159@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks David :) So, I found that isdst was never added as method signature in the docs, but it is mentioned in the paragraph. https://docs.python.org/3.7/library/email.util.html?#email.utils.localtime The intention is still just to deprecate isdst argument, right? not the localtime(). I can add a sentence in the docs indicating that we favor datetime.astimezone() instead of email.utils.localtime(), if that works for you. What do you think about this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 10:41:15 2016 From: report at bugs.python.org (Adam Stewart) Date: Fri, 18 Nov 2016 15:41:15 +0000 Subject: [issue28734] argparse: successive parsing wipes out nargs=? values Message-ID: <1479483675.86.0.774570236197.issue28734@psf.upfronthosting.co.za> New submission from Adam Stewart: I'm writing a wrapper that optionally accepts a file and reads more options from that file. The wrapper then needs to pass all of these options and the file to another program (qsub). Here is a minimal example to reproduce the behavior I'm seeing: >>> import argparse >>> parser = argparse.ArgumentParser() >>> parser.add_argument('-a') >>> parser.add_argument('file', nargs='?') >>> args = parser.parse_args(['-a', '3', 'myFile']) >>> print(args) Namespace(file='myFile', a='3') >>> parser.parse_args(['-a', '4'], namespace=args) >>> print(args) Namespace(file=None, a='4') The behavior I expect is that the file should remain as 'myFile', but it is being wiped out. Is there any way to prevent this, or is this actually a bug? I can recreate this problem in Python 2.7 and 3.5. ---------- components: Library (Lib) messages: 281128 nosy: ajstewart priority: normal severity: normal status: open title: argparse: successive parsing wipes out nargs=? values type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 10:43:21 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 15:43:21 +0000 Subject: [issue28398] Return singleton empty string in _PyUnicode_FromASCII In-Reply-To: <1476028146.3.0.529072270103.issue28398@psf.upfronthosting.co.za> Message-ID: <1479483801.48.0.659970023373.issue28398@psf.upfronthosting.co.za> STINNER Victor added the comment: To reduce the memory footprint, it's important that we reuse internal Unicode singletons. For the empty string singleton, you have two choices: * if length is equal to zero, return the singleton * create a string and then call unicode_result() unicode_result() should be used when the output length is not easy to compute or when the code is complex. Here is the code is very simple and the output length is obvious. Serhiy: "In what circumstances _PyUnicode_FromASCII is called with size=0?" I checked the current code: I'm unable to see any function which can call _PyUnicode_FromASCII() with size=0. Xiang: "IMHO, _PyUnicode_FromASCII is a private API and could be used in other places in future. We should not rely on the caller to check and return the singleton empty string." I agree. Xiang's patch is short and makes sense, so I vote +1 on it. I let Serhiy decides if the patch should be merged or not. If we decide to reject the patch, I suggest to add the following code at the beginning of _PyUnicode_FromASCII: /* Detect missed optimization */ assert(size != 0); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 10:48:44 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 18 Nov 2016 15:48:44 +0000 Subject: [issue26936] android: test_socket fails In-Reply-To: <1462288246.37.0.495121419926.issue26936@psf.upfronthosting.co.za> Message-ID: <1479484124.16.0.374153487615.issue26936@psf.upfronthosting.co.za> Xavier de Gaye added the comment: New patch using support.less_than_android_api(level). ---------- stage: patch review -> commit review Added file: http://bugs.python.org/file45534/test_socket_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 10:51:44 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Fri, 18 Nov 2016 15:51:44 +0000 Subject: [issue28596] on Android _bootlocale on startup relies on too many library modules In-Reply-To: <1478166520.26.0.975749703987.issue28596@psf.upfronthosting.co.za> Message-ID: <1479484304.33.0.226526164683.issue28596@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Here's my try: force UTF-8 on Android as explained in msg281110. sys.getfilesystemencoding() is already UTF-8 since issue22747. Testing: 1. Starting up time 0.18~0.19s => 0.11~0.12s, on Android 6.0, ASUS ZE500KL (Qualcomm MSM8916 QuadCore 1.2GHz) 2. test_site passes ---------- keywords: +patch nosy: +Chi Hsuan Yen Added file: http://bugs.python.org/file45535/android-locale-utf8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 10:52:32 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Fri, 18 Nov 2016 15:52:32 +0000 Subject: [issue26928] _bootlocale imports locale at startup on Android, causing test_site to fail In-Reply-To: <1462284365.5.0.819379627022.issue26928@psf.upfronthosting.co.za> Message-ID: <1479484352.0.0.212583166776.issue26928@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Submitted a patch to issue28596 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 10:54:26 2016 From: report at bugs.python.org (Lance Ware) Date: Fri, 18 Nov 2016 15:54:26 +0000 Subject: [issue28694] tkinter interface to fontchooser In-Reply-To: <1479174800.7.0.200377827869.issue28694@psf.upfronthosting.co.za> Message-ID: <1479484466.75.0.904169099879.issue28694@psf.upfronthosting.co.za> Lance Ware added the comment: Not having any luck creating a patch. I have retrieved source, built python, put my fontchooser.py file (attached) in cpython\Lib\tkinter, done hg add and hg commit, but when I try to do hg diff it gives me nothing. ---------- Added file: http://bugs.python.org/file45536/fontchooser.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 10:56:24 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 15:56:24 +0000 Subject: [issue28531] Improve utf7 encoder memory usage In-Reply-To: <1477412206.88.0.583380682603.issue28531@psf.upfronthosting.co.za> Message-ID: <1479484584.63.0.41418328566.issue28531@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy Storchaka: "The performance of the UTF-7 codec is not important." Right. "Actually I'm going to propose replacing it with Python implementation." Oh. Sadly, PyUnicode_DecodeUTF7() is part of the stable ABI. Do you want to call the Python codec from the C function for backward compatibility? I dislike UTF-7 because it's complex, but it's not as optimized as the UTF-8 codec, so the code remains not too big and so not too expensive to matain. "This encoder was omitted form _PyBytesWriter-using optimizations for purpose." Ah? I don't recall that. When I wrote _PyBytesWriter, I skipped UTF-7 because I don't know well this codec and I preferred to keep the code unchanged to avoid bugs :-) "The patch complicates the implementation." Hum, I have to disagree. For me, the patched new is no more complex than the current code. The main change is that it adds code checking the kind to better estimate the output length. It's not hard to understand the link between the Unicode kind of the max_char_size. I vote +1 on this patch because I consider that it makes the code simpler, not because it makes the codec faster (I don't really care of UTF-7 codec performance). But again (as in issue #28398), it's up to you Serhiy: I'm also ok to leave the code unchanged if you are against the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 11:07:14 2016 From: report at bugs.python.org (Rafael Jacinto Caricio da Fonseca) Date: Fri, 18 Nov 2016 16:07:14 +0000 Subject: [issue28735] Mock is equal to ANY but MagicMock is not Message-ID: <1479485234.58.0.222215885157.issue28735@psf.upfronthosting.co.za> New submission from Rafael Jacinto Caricio da Fonseca: On Python 3.5.2 mock.Mock() is equal to mock.ANY, but mock.MagicMock() is not. Minimal example: In Python 3.5.2: >>> from unittest import mock >>> mock.Mock() == mock.ANY True >>> mock.ANY == mock.Mock() True >>> mock.MagicMock() == mock.ANY False >>> mock.ANY == mock.MagicMock() True ---------- components: Library (Lib) messages: 281135 nosy: rafael.fonseca priority: normal severity: normal status: open title: Mock is equal to ANY but MagicMock is not type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 11:10:45 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 18 Nov 2016 16:10:45 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za> Message-ID: <1479485445.87.0.996831882097.issue28731@psf.upfronthosting.co.za> INADA Naoki added the comment: > This optimization affects only 6-element (and perhaps to less extend 11-element) dicts. But in any case this is good enhancement. This affects when minused = (n*2/3)+1 .. n-1 (n=8, 16, ...) n=8: 6, 7 n=16: 11, 12, ..15 > Naoki, could you please make microbenchmarks for 5- and 7-element dicts with your next patch? + /home/inada-n/local/py36/bin/patched -m perf timeit --compare-to /home/inada-n/local/py36/bin/master -- 'd = {"a":1, "b":2, "c":3, "d":4, "e":5}' master: ..................... 568 ns +- 18 ns patched: ..................... 567 ns +- 23 ns Median +- std dev: [master] 568 ns +- 18 ns -> [patched] 567 ns +- 23 ns: 1.00x faster Not significant! + /home/inada-n/local/py36/bin/patched -m perf timeit --compare-to /home/inada-n/local/py36/bin/master -- 'd = {"a":1, "b":2, "c":3, "d":4, "e":5, "f":6}' master: ..................... 1.01 us +- 0.04 us patched: ..................... 756 ns +- 20 ns Median +- std dev: [master] 1.01 us +- 0.04 us -> [patched] 756 ns +- 20 ns: 1.33x faster + /home/inada-n/local/py36/bin/patched -m perf timeit --compare-to /home/inada-n/local/py36/bin/master -- 'd = {"a":1, "b":2, "c":3, "d":4, "e":5, "f":6, "g":7}' master: ..................... 1.12 us +- 0.03 us patched: ..................... 867 ns +- 31 ns Median +- std dev: [master] 1.12 us +- 0.03 us -> [patched] 867 ns +- 31 ns: 1.29x faster + /home/inada-n/local/py36/bin/patched -m perf timeit --compare-to /home/inada-n/local/py36/bin/master -- 'd = {"a":1, "b":2, "c":3, "d":4, "e":5, "f":6, "g":7, "h":8}' master: ..................... 1.04 us +- 0.03 us patched: ..................... 1.03 us +- 0.04 us Median +- std dev: [master] 1.04 us +- 0.03 us -> [patched] 1.03 us +- 0.04 us: 1.00x faster Not significant! + /home/inada-n/local/py36/bin/patched -m perf timeit --compare-to /home/inada-n/local/py36/bin/master -- 'd = {"a":1, "b":2, "c":3, "d":4, "e":5, "f":6, "g":7, "h":8, "i":9, "j":10}' master: ..................... 1.16 us +- 0.04 us patched: ..................... 1.16 us +- 0.04 us Median +- std dev: [master] 1.16 us +- 0.04 us -> [patched] 1.16 us +- 0.04 us: 1.00x faster Not significant! + /home/inada-n/local/py36/bin/patched -m perf timeit --compare-to /home/inada-n/local/py36/bin/master -- 'd = {"a":1, "b":2, "c":3, "d":4, "e":5, "f":6, "g":7, "h":8, "i":9, "j":10, "k":11}' master: ..................... 1.67 us +- 0.06 us patched: ..................... 1.39 us +- 0.04 us Median +- std dev: [master] 1.67 us +- 0.06 us -> [patched] 1.39 us +- 0.04 us: 1.20x faster ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 11:16:36 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Fri, 18 Nov 2016 16:16:36 +0000 Subject: [issue28734] argparse: successive parsing wipes out nargs=? values In-Reply-To: <1479483675.86.0.774570236197.issue28734@psf.upfronthosting.co.za> Message-ID: <1479485796.85.0.226261206118.issue28734@psf.upfronthosting.co.za> Wolfgang Maier added the comment: try this: parser.add_argument('file', nargs='?', default = argparse.SUPPRESS) I don't think this is a bug. The default for the default parameter is None so the behavior is consistent with the documentation. ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 11:16:55 2016 From: report at bugs.python.org (Carl Dunham) Date: Fri, 18 Nov 2016 16:16:55 +0000 Subject: [issue25731] Assigning and deleting __new__ attr on the class does not allow to create instances of this class In-Reply-To: <1448454590.41.0.350843358205.issue25731@psf.upfronthosting.co.za> Message-ID: <1479485815.78.0.185439493153.issue25731@psf.upfronthosting.co.za> Changes by Carl Dunham : ---------- nosy: +Carl Dunham _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 11:19:02 2016 From: report at bugs.python.org (Adam Stewart) Date: Fri, 18 Nov 2016 16:19:02 +0000 Subject: [issue28734] argparse: successive parsing wipes out nargs=? values In-Reply-To: <1479483675.86.0.774570236197.issue28734@psf.upfronthosting.co.za> Message-ID: <1479485942.63.0.220924090238.issue28734@psf.upfronthosting.co.za> Adam Stewart added the comment: Works for me, thanks Wolfgang! ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 11:23:27 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 18 Nov 2016 16:23:27 +0000 Subject: [issue28159] Deprecate isdst argument in email.utils.localtime In-Reply-To: <1473890113.79.0.964863330823.issue28159@psf.upfronthosting.co.za> Message-ID: <1479486207.83.0.705292943831.issue28159@psf.upfronthosting.co.za> R. David Murray added the comment: No, localtime does something subtly different, in that it will accept a naive datetime add the local timezone to it. Calling localtime() is also more convenient/readable than calling datetime.now().astimezone(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 11:29:02 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Nov 2016 16:29:02 +0000 Subject: [issue28398] Return singleton empty string in _PyUnicode_FromASCII In-Reply-To: <1476028146.3.0.529072270103.issue28398@psf.upfronthosting.co.za> Message-ID: <1479486542.46.0.255920606924.issue28398@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I know that _PyUnicode_FromASCII() is called with size=0. But most callers call it only with size!=0. I didn't investigate further. We should know what is the benefit of the patch before committing it. Just "for consistency" is a weak argument itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 11:32:34 2016 From: report at bugs.python.org (Eric Leadbetter) Date: Fri, 18 Nov 2016 16:32:34 +0000 Subject: [issue28736] multiprocessing.Lock() no longer has .acquire() Message-ID: <1479486754.06.0.767072130944.issue28736@psf.upfronthosting.co.za> New submission from Eric Leadbetter: The documentation on the multiprocessing library in Python 3 uses Lock.acquire()/Lock.release() in the example for primitive synchronization (https://docs.python.org/3/library/multiprocessing.html#synchronization-between-processes). Lock() has been changed in Python 3 to use coroutines and so the documentation should replace the call to Lock.acquire() with an appropriate yield statement. ---------- assignee: docs at python components: Documentation messages: 281141 nosy: Eric Leadbetter, docs at python priority: normal severity: normal status: open title: multiprocessing.Lock() no longer has .acquire() versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 11:33:48 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 16:33:48 +0000 Subject: [issue28398] Return singleton empty string in _PyUnicode_FromASCII In-Reply-To: <1476028146.3.0.529072270103.issue28398@psf.upfronthosting.co.za> Message-ID: <1479486828.67.0.0744294693395.issue28398@psf.upfronthosting.co.za> STINNER Victor added the comment: > We should know what is the benefit of the patch before committing it. The purpose of the patch is to use the empty string singleton to reduce the memory footprint, instead of creating multiple empty (Unicode) string objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 11:40:36 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Nov 2016 16:40:36 +0000 Subject: [issue28531] Improve utf7 encoder memory usage In-Reply-To: <1477412206.88.0.583380682603.issue28531@psf.upfronthosting.co.za> Message-ID: <1479487236.7.0.441111317558.issue28531@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I fixed many long living bugs in the UTF-7 codec in the past, and I remember that we fixed bugs introduced by using _PyUnicodeWriter or _PyBytesWriter many months after changing the code. Since the UTF-7 codec is rarely used, there is a risk of introducing new long living bug. You should peruse not just the code near the changed lines, but all the codec. I'm not strongly against this patch, if you Victor takes the responsibility for it, I left it on you. ---------- assignee: -> haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 11:44:27 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 16:44:27 +0000 Subject: [issue28531] Improve utf7 encoder memory usage In-Reply-To: <1477412206.88.0.583380682603.issue28531@psf.upfronthosting.co.za> Message-ID: <1479487467.95.0.13557181938.issue28531@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh no, now I'm afraid of breaking something :-D I don't trust anymore our test suite for the UTF-7 codec, so I close the issue :-) Sorry Xiang, but as we said, this rarely used codec is not important enough to require optimization. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 11:45:40 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 16:45:40 +0000 Subject: [issue28531] Improve utf7 encoder memory usage In-Reply-To: <1477412206.88.0.583380682603.issue28531@psf.upfronthosting.co.za> Message-ID: <1479487540.48.0.315307172681.issue28531@psf.upfronthosting.co.za> STINNER Victor added the comment: > I remember that we fixed bugs introduced by using _PyUnicodeWriter or _PyBytesWriter many months after changing the code. Yeah, now I recall it (vaguely), that's why I closed the bug :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 11:47:36 2016 From: report at bugs.python.org (Sam Gross) Date: Fri, 18 Nov 2016 16:47:36 +0000 Subject: [issue28737] Document that tp_dealloc handler must call PyObject_GC_UnTrack if Py_TPFLAGS_HAVE_GC is set Message-ID: <1479487656.43.0.616591816842.issue28737@psf.upfronthosting.co.za> New submission from Sam Gross: In general, an a PyTypeObject that has Py_TPFLAGS_HAVE_GC set must call PyObject_GC_UnTrack() before it frees any PyObject* references it owns. The only reference to this requirement I found is in https://docs.python.org/3/c-api/gcsupport.html#c._PyObject_GC_TRACK. This requirement should be documented in: 1. https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_dealloc 2. https://docs.python.org/3/extending/newtypes.html A call to PyObject_GC_UnTrack() should also be added to he official "noddy4" example. Currently, the example is incorrect and can crash if a referred-to object triggers a GC from it's destructor. See the following example which segfaults: https://github.com/colesbury/noddy It may be worthwhile to have _Py_Dealloc call PyObject_GC_UnTrack() if the PyTypeObject has Py_TPFLAGS_HAVE_GC set. Considering that the official Python extension example is missing the call, it seems likely that extension writers often forget to include it. ---------- assignee: docs at python components: Documentation, Extension Modules messages: 281146 nosy: colesbury, docs at python priority: normal severity: normal status: open title: Document that tp_dealloc handler must call PyObject_GC_UnTrack if Py_TPFLAGS_HAVE_GC is set versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 11:52:31 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Nov 2016 16:52:31 +0000 Subject: [issue28398] Return singleton empty string in _PyUnicode_FromASCII In-Reply-To: <1476028146.3.0.529072270103.issue28398@psf.upfronthosting.co.za> Message-ID: <1479487951.64.0.514141995895.issue28398@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: My question is simple: in what circumstances the patch has an effect? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 12:12:44 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 18 Nov 2016 17:12:44 +0000 Subject: [issue28398] Return singleton empty string in _PyUnicode_FromASCII In-Reply-To: <1476028146.3.0.529072270103.issue28398@psf.upfronthosting.co.za> Message-ID: <1479489164.92.0.79354114623.issue28398@psf.upfronthosting.co.za> Xiang Zhang added the comment: > My question is simple: in what circumstances the patch has an effect? My original intention is that there is no need for the caller to check for the empty string. Even there is no use case now, it could be in future. But Serhiy, I am actually very glad to get a determined result, even it's rejected. If the issue is still open, I would think you are still open to discussion. Such a trivial patch isn't worth it. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 12:15:59 2016 From: report at bugs.python.org (SilentGhost) Date: Fri, 18 Nov 2016 17:15:59 +0000 Subject: [issue28728] test_host_resolution in test_socket fails on duplicate assert In-Reply-To: <1479407743.41.0.909577209709.issue28728@psf.upfronthosting.co.za> Message-ID: <1479489359.39.0.60817623687.issue28728@psf.upfronthosting.co.za> Changes by SilentGhost : Removed file: http://bugs.python.org/file45524/test_socket.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 12:17:24 2016 From: report at bugs.python.org (SilentGhost) Date: Fri, 18 Nov 2016 17:17:24 +0000 Subject: [issue28728] test_host_resolution in test_socket fails In-Reply-To: <1479407743.41.0.909577209709.issue28728@psf.upfronthosting.co.za> Message-ID: <1479489444.49.0.0564446166283.issue28728@psf.upfronthosting.co.za> SilentGhost added the comment: Of course, you're right, that was my mistake. The last three addresses fail to raise, namely: '::1q', '::1::2' and '1:1:1:1:1:1:1:1:1'. ---------- stage: patch review -> title: test_host_resolution in test_socket fails on duplicate assert -> test_host_resolution in test_socket fails _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 12:34:17 2016 From: report at bugs.python.org (Zachary Ware) Date: Fri, 18 Nov 2016 17:34:17 +0000 Subject: [issue28694] tkinter interface to fontchooser In-Reply-To: <1479174800.7.0.200377827869.issue28694@psf.upfronthosting.co.za> Message-ID: <1479490457.18.0.0240309198803.issue28694@psf.upfronthosting.co.za> Zachary Ware added the comment: I would recommend backing out your commit (hg rollback if you haven't pulled or otherwise changed your checkout since you made your commit), and just do 'hg diff' at the point where you would commit. In this particular case, if there are no changes other than the added file it doesn't really matter much that it's not in patch form. It would be nice to have some unit tests. It may not be possible to test anything but your _str_to_font and _font_to_str functions, though. I notice that your Fontchooser class doesn't inherit from commondialog.Dialog like colorchooser.Chooser does; is commondialog.Dialog usable for this? Or are there improvements that can be made to commondialog.Dialog to make it suitable for Fontchooser and also improve colorchooser.Chooser? Can this reuse anything from Lib/tkinter/font.py or perhaps be merged into that file to keep all the font stuff together? After we have some of those details ironed out, this is going to make a nice addition to tkinter! ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 12:35:55 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Nov 2016 17:35:55 +0000 Subject: [issue28673] pyro4 with more than 15 threads often crashes 2.7.12 In-Reply-To: <1478939498.33.0.0967391900201.issue28673@psf.upfronthosting.co.za> Message-ID: <1479490555.2.0.59263862472.issue28673@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> test needed title: When using pyro4 with more than 15 threads, python 2.7.12 cores frequently -> pyro4 with more than 15 threads often crashes 2.7.12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 12:38:57 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Nov 2016 17:38:57 +0000 Subject: [issue28677] difficult to parse sentence structure in "When an instance attribute is referenced that isn't a data attribute" In-Reply-To: <1478986337.93.0.398450030776.issue28677@psf.upfronthosting.co.za> Message-ID: <1479490737.94.0.446625434602.issue28677@psf.upfronthosting.co.za> Terry J. Reedy added the comment: David's wording looks good. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 12:45:26 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 18 Nov 2016 17:45:26 +0000 Subject: [issue28736] multiprocessing.Lock() no longer has .acquire() In-Reply-To: <1479486754.06.0.767072130944.issue28736@psf.upfronthosting.co.za> Message-ID: <1479491126.57.0.792219790815.issue28736@psf.upfronthosting.co.za> R. David Murray added the comment: What gives you the idea that the multiprocessing Lock implementation has been changed? Are you confusing the asyncio Lock with the threading Lock? Is there a documentation crosslink somewhere that is going to the wrong place? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 12:47:32 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Fri, 18 Nov 2016 17:47:32 +0000 Subject: [issue28596] on Android _bootlocale on startup relies on too many library modules In-Reply-To: <1478166520.26.0.975749703987.issue28596@psf.upfronthosting.co.za> Message-ID: <1479491252.61.0.501596463508.issue28596@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Version 2 - use sys.implementation._multiarch to determine whether it's Android or not ---------- Added file: http://bugs.python.org/file45537/android-locale-utf8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 12:59:49 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Nov 2016 17:59:49 +0000 Subject: [issue28596] on Android _bootlocale on startup relies on too many library modules In-Reply-To: <1478166520.26.0.975749703987.issue28596@psf.upfronthosting.co.za> Message-ID: <1479491989.67.0.945368908121.issue28596@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 13:25:26 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Nov 2016 18:25:26 +0000 Subject: [issue28681] About function renaming in the tutorial In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za> Message-ID: <1479493526.39.0.448501167892.issue28681@psf.upfronthosting.co.za> Terry J. Reedy added the comment: It took me a moment to realize that 'value of the function name' meant 'the function object associated with the name'. I think David's rewrite is a substantial improvement. I would just change the end 'can be used as a function' to 'can be used to access the function.' 'Renaming' is wrong to me because it implies invalidation of the previous name. 'Alternate name' is more accurate. I agree that 'alias' is better, but also that it is a bit problematical*. 'Alias' is distinct from 'legal name'. The closest analogy to 'legal name' is 'definition name' (.__name__ attribute). But definition names are distinct from bound names, only some objects have definition names, and when they do, they can be renamed if and only if the object is coded in Python. I don't understand the relevance of the middle sentence "The interpreter recognizes the object pointed to by that name as a user-defined function." All objects can be given multiple names. In this context, the difference between C and Python coded names is whether the .__name__ attribute can be rebound, and that attribute is not part of the discussion here. The paragraph introduces this code example, which has nothing to do with .__name__. >>> fib >>> f = fib >>> f(100) 0 1 1 2 3 5 8 13 21 34 55 89 (* Steven, I would say that both 'x' and 'y' in your example are aliases for the int 1. But I understand the other viewpoint.) ---------- nosy: +terry.reedy stage: -> needs patch versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 13:28:18 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Nov 2016 18:28:18 +0000 Subject: [issue24452] Make webbrowser support Chrome on Mac OS X In-Reply-To: <1434317605.99.0.218705045555.issue24452@psf.upfronthosting.co.za> Message-ID: <20161118182815.33512.48675.02F3B367@psf.io> Roundup Robot added the comment: New changeset 0c8270cbdc62 by Brett Cannon in branch 'default': Issue #24452: add attribution https://hg.python.org/cpython/rev/0c8270cbdc62 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 13:42:18 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Nov 2016 18:42:18 +0000 Subject: [issue28705] Clean up design FAQ question about compiling to C In-Reply-To: <1479242424.69.0.486701583989.issue28705@psf.upfronthosting.co.za> Message-ID: <20161118184215.32822.21745.D45C5934@psf.io> Roundup Robot added the comment: New changeset a0a3dab4ed66 by Brett Cannon in branch '3.6': Issue #28705: greatly simplify the FAQ entry on transpiling. https://hg.python.org/cpython/rev/a0a3dab4ed66 New changeset 89e2201142f9 by Brett Cannon in branch 'default': Merge for issue #28705 https://hg.python.org/cpython/rev/89e2201142f9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 13:42:27 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 18 Nov 2016 18:42:27 +0000 Subject: [issue28705] Clean up design FAQ question about compiling to C In-Reply-To: <1479242424.69.0.486701583989.issue28705@psf.upfronthosting.co.za> Message-ID: <1479494547.73.0.95979209943.issue28705@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 13:45:18 2016 From: report at bugs.python.org (Eric Leadbetter) Date: Fri, 18 Nov 2016 18:45:18 +0000 Subject: [issue28736] multiprocessing.Lock() no longer has .acquire() In-Reply-To: <1479486754.06.0.767072130944.issue28736@psf.upfronthosting.co.za> Message-ID: <1479494718.17.0.12950271555.issue28736@psf.upfronthosting.co.za> Eric Leadbetter added the comment: It was a typographical error on my part. My mistake. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 13:53:53 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Nov 2016 18:53:53 +0000 Subject: [issue28687] Python 2.7.12 windows x64 installer fails after previous bad uninstall In-Reply-To: <1479119927.24.0.974377093409.issue28687@psf.upfronthosting.co.za> Message-ID: <1479495233.99.0.0187943327985.issue28687@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I had something like this happen with early 3.y.z. I believe I re-downloaded and re-installed the old version before either uninstalling or upgrading. I now keep the installer for x.y.z around until it is deleted or replaced. (I don't now if this is still needed for the 3.5+ non-msi installers.) I don't know how easy it would be to make a change as the author/maintainer of the msi installers is not currently active. ---------- nosy: +loewis, steve.dower, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 13:58:28 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Nov 2016 18:58:28 +0000 Subject: [issue28693] No HKSCS support in Windows cp950 In-Reply-To: <1479154148.6.0.43343383532.issue28693@psf.upfronthosting.co.za> Message-ID: <1479495508.56.0.350876131927.issue28693@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 14:03:43 2016 From: report at bugs.python.org (Zachary Ware) Date: Fri, 18 Nov 2016 19:03:43 +0000 Subject: [issue28736] multiprocessing.Lock() no longer has .acquire() In-Reply-To: <1479486754.06.0.767072130944.issue28736@psf.upfronthosting.co.za> Message-ID: <1479495823.0.0.0471988535087.issue28736@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- resolution: -> not a bug stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 14:38:36 2016 From: report at bugs.python.org (Wojtek Ruszczewski) Date: Fri, 18 Nov 2016 19:38:36 +0000 Subject: [issue28738] Document SIGBREAK as argument for signal() under Windows. Message-ID: <1479497916.69.0.534558560438.issue28738@psf.upfronthosting.co.za> New submission from Wojtek Ruszczewski: SIGBREAK should be listed as acceptable for signal.signal() under Windows. Some context. Registering a handler for SIGBREAK may be useful as this is the signal that generating CTRL_BREAK_EVENT results in (and the latter combined with the CREATE_NEW_PROCESS_GROUP flag might be the closest that one can get to terminating a process group). Some pointers: * The changed documentation fragment: https://docs.python.org/3/library/signal.html#signal.signal. * MSDN doesn't say so much about SIGBREAK: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682541(v=vs.85).aspx. * SIGBREAK was added to the signal module with #466877. * The signal number check looks as follows: https://github.com/python/cpython/blob/3.6/Modules/signalmodule.c#L402. ---------- assignee: docs at python components: Documentation, Windows files: sigbreak.patch keywords: patch messages: 281159 nosy: docs at python, paul.moore, steve.dower, tim.golden, wrwrwr, zach.ware priority: normal severity: normal status: open title: Document SIGBREAK as argument for signal() under Windows. type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45538/sigbreak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 14:42:22 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Nov 2016 19:42:22 +0000 Subject: [issue28702] Confusing error message when None used in expressions, eg. "'NoneType' object has no attribute 'foo'" In-Reply-To: <1479240283.12.0.750407106609.issue28702@psf.upfronthosting.co.za> Message-ID: <1479498142.78.0.410778139165.issue28702@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I have doubts also. The issue is the same for NotImplemented, though the occurrence is much rarer, and similar for Ellipsis. >>> NotImplemented.foo Traceback (most recent call last): File "", line 1, in NotImplemented.foo AttributeError: 'NotImplementedType' object has no attribute 'foo' >>> Ellipsis.foo Traceback (most recent call last): File "", line 1, in Ellipsis.foo AttributeError: 'ellipsis' object has no attribute 'foo' Replacing the type name with the object name works for this message, but not for the type errors. TypeError: unsupported operand type(s) for +: 'None' and 'int' is wrong. Replacing 'NoneType' with 'None' in error messages will break code that does something like "if 'NoneType' in err.args[0]" in an exception message. The same replacement would have to be make in user code. Fortunately, it would continue to work with older versions. ---------- nosy: +terry.reedy stage: -> test needed versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 14:46:51 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 18 Nov 2016 19:46:51 +0000 Subject: [issue28159] Deprecate isdst argument in email.utils.localtime In-Reply-To: <1473890113.79.0.964863330823.issue28159@psf.upfronthosting.co.za> Message-ID: <1479498411.86.0.41385380174.issue28159@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Keeping localtime as a convenience function in email.util is fine, but isdst argument should be eliminated at some point. There is a fundamental problem with disambiguating fold times with isdst: some folds do not involve the change in dst or happen in the regions that do not have a dst regime at all. PEP 495 covers this in all the gory details. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 15:16:48 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Nov 2016 20:16:48 +0000 Subject: [issue28710] Sphinx incompatible markup in configparser.ConfigParser. In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za> Message-ID: <1479500208.09.0.538853289622.issue28710@psf.upfronthosting.co.za> Terry J. Reedy added the comment: As far as I looked, the patch changes `xyz' in docstrings and quotes to ``xyz``. A rst expert should verify that this is correct. In printed strings, `zyz' is changed to 'xyz', which I consider to be correct. Before applying this, I would want to review in Rietveld, with side by side diff and changes color marked. However, Rietveld does not like the patch and there is no 'review' button. I thought it might be the git format, but I found another git patch that did have a review button. When I downloaded and tried to apply (to default), hg says that there is no diff. I don't see the problem, but we cannot currently use a patch that does not apply in hg. Patrick, in order to use patches, we require Contributor Agreements. https://www.python.org/psf/contrib/ There is an electronic form that makes submission easy. https://www.python.org/psf/contrib/contrib-form/ ---------- nosy: +terry.reedy stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 15:22:29 2016 From: report at bugs.python.org (Steve Dower) Date: Fri, 18 Nov 2016 20:22:29 +0000 Subject: [issue28687] Python 2.7.12 windows x64 installer fails after previous bad uninstall In-Reply-To: <1479119927.24.0.974377093409.issue28687@psf.upfronthosting.co.za> Message-ID: <1479500549.79.0.286431829365.issue28687@psf.upfronthosting.co.za> Steve Dower added the comment: So the fix for pre-2.7.13 here is to Repair first and then reinstall. But we've actually fixed this for 2.7.13 by making the pip uninstall step non-vital (the work was sponsored by Microsoft because it affects the Visual Studio installer). See issue27888 for the change. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Hide pip install/uninstall windows in setup _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 15:23:02 2016 From: report at bugs.python.org (Steve Dower) Date: Fri, 18 Nov 2016 20:23:02 +0000 Subject: [issue28687] Python 2.7.12 windows x64 installer fails after previous bad uninstall In-Reply-To: <1479119927.24.0.974377093409.issue28687@psf.upfronthosting.co.za> Message-ID: <1479500581.99.0.0859281078706.issue28687@psf.upfronthosting.co.za> Steve Dower added the comment: > ...is to Repair first and then reinstall Repair and then *un*install (obviously). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 15:36:58 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 18 Nov 2016 20:36:58 +0000 Subject: [issue28710] Sphinx incompatible markup in configparser.ConfigParser. In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za> Message-ID: <1479501418.04.0.972905405025.issue28710@psf.upfronthosting.co.za> R. David Murray added the comment: I think that we do not generally use ReST markup in our docstrings. So replacing `x' with 'x' would be more correct, I think. In many cases the quotes could just be omitted entirely. The patch command says: patch unexpectedly ends in middle of line patch: **** Only garbage was found in the patch input. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 15:43:51 2016 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 18 Nov 2016 20:43:51 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings Message-ID: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za> New submission from Yury Selivanov: Can f-strings be used as docstrings? Right now: class Foo: f'spam' Foo.__doc__ is None I couldn't find that f-strings cannot be used as docstrings in neither PEP 498 not in the 3.6 documentation, so I suppose this is a bug. ---------- components: Interpreter Core messages: 281166 nosy: eric.smith, gvanrossum, martin.panter, yselivanov priority: normal severity: normal status: open title: PEP 498: docstrings as f-strings versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 15:58:25 2016 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 18 Nov 2016 20:58:25 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za> Message-ID: <1479502705.86.0.602268373846.issue28739@psf.upfronthosting.co.za> Eric V. Smith added the comment: As you've seen, the answer is "no"! We'd need to add logic to evaluate them at function definition time. That would be a slight noticeable change, if the expressions had side effects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 16:02:43 2016 From: report at bugs.python.org (SilentGhost) Date: Fri, 18 Nov 2016 21:02:43 +0000 Subject: [issue28735] Mock is equal to ANY but MagicMock is not In-Reply-To: <1479485234.58.0.222215885157.issue28735@psf.upfronthosting.co.za> Message-ID: <1479502963.29.0.0362565857588.issue28735@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +michael.foord versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 16:23:44 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 18 Nov 2016 21:23:44 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za> Message-ID: <1479504224.12.0.862745727102.issue28739@psf.upfronthosting.co.za> Martin Panter added the comment: There was a bit of discussion at the top of . IMO it would be simpler do disallow all f-strings as docstrings. Otherwise, what would the result of this be: name = "module level" class C: name = "class level" def m(self, name="default param"): f"{name}" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 16:26:35 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 21:26:35 +0000 Subject: [issue28740] Add sys.getandroidapilevel() Message-ID: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za> New submission from STINNER Victor: Android slowly becomes a first-citizen class platform in CPython thanks to Xavier de Gaye and other motivated developers, thanks to all of them :-) To fix the issue #28596, we need a function to check if we are running Android. Chi Hsuan Yen proposed to use sysconfig to get the new ANDROID_API_LEVEL configuration option: + if sysconfig.get_config_var('ANDROID_API_LEVEL'): But I asked to avoid sysconfig to reduce imports at Python startup (especially when the site module is not loaded). I proposed to add a new function to the sys module: sys.getandroidapilevel(). sys.getandroidapilevel() would only be available on Android, as sys.getwindowsversion() is only available on Windows, and would return ANDROID_API_LEVEL as an integer. I'm not sure about the type: should we use a string? A tuple of integers like sys.version_info? sys.getwindowsversion() returns a named tuple: https://docs.python.org/dev/library/sys.html#sys.getwindowsversion I'm sorry, I don't have access to an Android development platform, so I let someone else implement it :-) ---------- messages: 281169 nosy: Chi Hsuan Yen, haypo, xdegaye priority: normal severity: normal status: open title: Add sys.getandroidapilevel() type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 16:27:03 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 21:27:03 +0000 Subject: [issue28596] on Android _bootlocale on startup relies on too many library modules In-Reply-To: <1478166520.26.0.975749703987.issue28596@psf.upfronthosting.co.za> Message-ID: <1479504423.64.0.6062253796.issue28596@psf.upfronthosting.co.za> STINNER Victor added the comment: I created the issue #28740: Add sys.getandroidapilevel(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 16:39:30 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 21:39:30 +0000 Subject: [issue28740] Add sys.getandroidapilevel() In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za> Message-ID: <1479505170.3.0.500967314432.issue28740@psf.upfronthosting.co.za> STINNER Victor added the comment: Ah, I wrote a patch to implement the function. I used ANDROID_API_LEVEL from pyconfig.h. I chose to simply return an integer. I don't know if it's the most future-proof API :-) ---------- keywords: +patch Added file: http://bugs.python.org/file45539/getandroidapilevel.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 16:41:08 2016 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 18 Nov 2016 21:41:08 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za> Message-ID: <1479505268.01.0.0141047570329.issue28739@psf.upfronthosting.co.za> Yury Selivanov added the comment: > IMO it would be simpler do disallow all f-strings as docstrings. How exactly you want to disallow them? Raise SyntaxError? If you don't raise anything, then the behaviour is just confusing -- the interpreter parses them, but __doc__ is None. I think this needs to be fixed. Eric, can we still fix this in 3.6? If not, then we need to update the PEP and the docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 16:51:56 2016 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 18 Nov 2016 21:51:56 +0000 Subject: [issue28741] PEP 498: single '}' is not allowed Message-ID: <1479505916.83.0.442816788413.issue28741@psf.upfronthosting.co.za> New submission from Yury Selivanov: The PEP should document the "single '}' is not allowed" error. ---------- assignee: docs at python components: Documentation messages: 281173 nosy: docs at python, eric.smith, yselivanov priority: normal severity: normal status: open title: PEP 498: single '}' is not allowed versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 17:14:12 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 18 Nov 2016 22:14:12 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za> Message-ID: <1479507252.76.0.29976484383.issue28739@psf.upfronthosting.co.za> Martin Panter added the comment: Actually, testing your code fragment, it seems you do get a doc string when the f-string has no substitutions in curly brackets, otherwise you don?t get any doc string. Maybe this is due to how different forms of string are compiled. >>> class Foo: ... f'spam' # Compiled as plain 'spam' ... >>> Foo.__doc__ 'spam' >>> class Foo: ... 'spam' f'{"MMM"}' # Compiled as f'spam{"MMM"}' ... >>> Foo.__doc__ is None True ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 17:19:45 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 18 Nov 2016 22:19:45 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za> Message-ID: <1479507585.57.0.528230698249.issue28739@psf.upfronthosting.co.za> Martin Panter added the comment: Having an unassigned f-string as the first statement is still valid syntax, so could at most be a warning, not a SyntaxError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 17:40:09 2016 From: report at bugs.python.org (Julien Palard) Date: Fri, 18 Nov 2016 22:40:09 +0000 Subject: [issue28729] Exception from sqlite3 adapter masked by sqlite3.InterfaceError In-Reply-To: <1479425140.19.0.0824888445668.issue28729@psf.upfronthosting.co.za> Message-ID: <1479508809.88.0.848909305689.issue28729@psf.upfronthosting.co.za> Julien Palard added the comment: By moving: ``` /* else set the right exception and return NULL */ PyErr_SetString(pysqlite_ProgrammingError, "can't adapt"); ``` from `pysqlite_microprotocols_adapt` to `pysqlite_adapt` (to avoid changing the semantics from the outside) make the `pysqlite_microprotocols_adapt`protocol clearer: - if it went well return something - If it went well but had nothing to do: return NULL - If it broke, set an exception and return NULL It does not break any test. Then in `Modules/_sqlite/statement.c`, we can stop blindly muting exceptions with the `PyErr_Clear`s, replacing them with ``if (PyErr_Occurred()) return;``. Again it does not break any test. I added a test to check that if an adapter raises an exception it bubbles outside the execute method, and it passes. Sample code given by the issue now gives:: $ ./python issue28729.py Traceback (most recent call last): File "issue28729.py", line 18, in cur.execute("select ?", (p,)) File "issue28729.py", line 10, in adapt_point assert False, 'Problem in adapter' AssertionError: Problem in adapter I did not found precise documentation about pysqlite_microprotocols_adapt or pysqlite_adapt, so my changes may break a "well known protocol", but it looks safe as I do not change the _sqlite protocol as far as I can tell, (only when the exception comes directly from the adaptor, obviously), and there were no other uses of pysqlite_microprotocols_adapt, which is not exposed in the module. ---------- keywords: +patch Added file: http://bugs.python.org/file45540/issue28729.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 17:59:00 2016 From: report at bugs.python.org (Martin Blais) Date: Fri, 18 Nov 2016 22:59:00 +0000 Subject: [issue10049] Add a "no-op" (null) context manager to contextlib In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za> Message-ID: <1479509940.36.0.119618555788.issue10049@psf.upfronthosting.co.za> Martin Blais added the comment: I've been looking for this today; I would have used it. Instead of an obvious (and explicit) null context manager, I had to read through this entire thread to eventually find out that I can use something called ExitStack(), which is designed for another use case. When many users have to replicate the same boilerplate code time and time again, it's not cruft, it's just something that ought to be part of the stdlib. There are a number of such cases in the stdlib. I think nullcontext should be part of the included batteries Python aims to provide. ---------- nosy: +Martin Blais _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 18:04:15 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Nov 2016 23:04:15 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479510255.24.0.324371039205.issue28727@psf.upfronthosting.co.za> STINNER Victor added the comment: New approach: patch 5 now compares indexgroup, groupindex and code instead of comparing pattern, to handle correctly two equal pattern strings compiled with the re.LOCALE flag and two different locales. The patch also converts indexgroup list to a tuple to be able to hash it. (It also prevents modification, but this is just a side effect, and groupindex remains a mutable dictionary.) _sre.compile() checks types which helps to identify a bug in unit tests. ---------- Added file: http://bugs.python.org/file45541/pattern_compare-5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 18:22:13 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 18 Nov 2016 23:22:13 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings In-Reply-To: <1479128206.47.0.155651436814.issue28688@psf.upfronthosting.co.za> Message-ID: <1479511333.85.0.408909250571.issue28688@psf.upfronthosting.co.za> Martin Panter added the comment: Here is another way to remember that the filter list has already been initialized. I made a new immortal _warnings.filters_initialized flag at the C level. It is actually a list so that it can be mutated and remembered across module reloads, but it is either empty (evaluates as false), or a single element: [True]. Also, Python 2 does get duplicated filters, but I guess there is not test that exposes it. $ python2 -Wall . . . >>> import warnings >>> len(warnings.filters) 5 >>> reload(warnings) >>> len(warnings.filters) 6 I agree there is no need to change Python 2 at this stage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 18:22:35 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 18 Nov 2016 23:22:35 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings In-Reply-To: <1479128206.47.0.155651436814.issue28688@psf.upfronthosting.co.za> Message-ID: <1479511355.79.0.0194172501727.issue28688@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file45542/immortal-filters.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 18:30:19 2016 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 18 Nov 2016 23:30:19 +0000 Subject: [issue10049] Add a "no-op" (null) context manager to contextlib In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za> Message-ID: <1479511819.3.0.40199801098.issue10049@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: ExitStack() already covers the "null ctx mgr" use case described in the first message. Original example: with transaction or contextlib.null(): ... By using ExitStack: with transaction or ExitStack(): ... You can push this further and do this, which is even more flexible: with ExitStack() as stack: if condition: stack.enter_context(transaction) ... So ExitStack really is better than the original proposal which could have made sense 6 years ago but not anymore. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 18:50:48 2016 From: report at bugs.python.org (Steve Dower) Date: Fri, 18 Nov 2016 23:50:48 +0000 Subject: [issue28732] spawnl crash on windows7 In-Reply-To: <1479468155.36.0.0223780421373.issue28732@psf.upfronthosting.co.za> Message-ID: <1479513048.55.0.859947750493.issue28732@psf.upfronthosting.co.za> Steve Dower added the comment: Looks like a few functions in os module need this. os_execve_impl also doesn't release the GIL at any point, but I don't see why it shouldn't. I'll try and get to this over the weekend if nobody else comes up with a patch first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 19:16:11 2016 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 19 Nov 2016 00:16:11 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za> Message-ID: <1479514571.65.0.290447152683.issue28739@psf.upfronthosting.co.za> Eric V. Smith added the comment: It's Ned's call, but I wouldn't recommend changing this in 3.6, at least not 3.6.0. As Martin points out, the reason f'foo' is a "normal" string has to do with how strings and f-strings are assembled and concatenated. Similarly: 'foo' f'bar' 'baz' is a normal string, 'foobarbaz'. I can't think of another place that requires a "normal" string, but if they exist, they'd be affected by this, too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 19:17:09 2016 From: report at bugs.python.org (Peter Eckersley) Date: Sat, 19 Nov 2016 00:17:09 +0000 Subject: [issue28742] argparse.ArgumentDefaultsHelpFormatter sometimes provides inaccurate documentation of defaults, so they should be overrideable Message-ID: <1479514629.23.0.218870455687.issue28742@psf.upfronthosting.co.za> New submission from Peter Eckersley: When argparse lists the default values for cli flags and arguments, it shows argparse's view of the internal Pythonic default, not the default behaviour of the program as a whole. This can be wrong in many cases, as documented at https://bugs.python.org/issue27153 and https://github.com/certbot/certbot/issues/3734. To mitigate this, we should allow the caller to set arbitrary strings that argparse will display to the user as the "default" in the CLI help. I wrote a first patch to do this via a new "help_default" argument that can be added to argparse actions: https://gist.github.com/pde/daec08cadc21bca0d62852020887ee13 The patch was written against argparse.py from Python2.7, but seems to apply and run okay against the Python 3.x version. ---------- messages: 281183 nosy: pde priority: normal severity: normal status: open title: argparse.ArgumentDefaultsHelpFormatter sometimes provides inaccurate documentation of defaults, so they should be overrideable versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 19:23:22 2016 From: report at bugs.python.org (Peter Eckersley) Date: Sat, 19 Nov 2016 00:23:22 +0000 Subject: [issue28742] argparse.ArgumentDefaultsHelpFormatter sometimes provides inaccurate documentation of defaults, so they should be overrideable In-Reply-To: <1479514629.23.0.218870455687.issue28742@psf.upfronthosting.co.za> Message-ID: <1479515002.77.0.106617247567.issue28742@psf.upfronthosting.co.za> Peter Eckersley added the comment: One thing I noticed when testing my patch by vendorizing it into the Certbot tree was that if a developer had somehow inherited from a version of argparse.Action that *doesn't* have this patch applied to it, and then passes in instances of those inheriting classes to the new patched version, things will break (because the argparse engine now assumes every action has a help_default attribute, rather than checking for it). That's an unlikely situation but might arise if a developer had managed to use the standard library version of argparse in some places, and the pypi packaged version in other places. It might be possible, but uglier, to write this patch more defensively so that that wouldn't happen; I would appreciate some feedback on whether people think that's necessary or a good idea. ---------- components: +Library (Lib) type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 19:47:44 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Nov 2016 00:47:44 +0000 Subject: [issue28743] test_choices_algorithms() in test_random uses lots of memory Message-ID: <1479516464.04.0.874513077096.issue28743@psf.upfronthosting.co.za> New submission from Martin Panter: Revision 32bfc81111b6 added test.test_random.MersenneTwister_TestBasicOps.test_choices_algorithms(), which runs the following code: n = 13132817 # 13 million self.gen.choices(range(n), [1]*n, k=10000) When I build Python with the ?--with-pydebug? configure option on x86-64 Linux, this call uses over 1.2 GB of memory. My computer only has 2 GiB, so it tends to slow down the whole operating system and/or trigger Linux?s out-of-memory killler. Especially if other tests are run concurrently. Is it practical to reduce the magnitude of the test parameters, or optimize the implementation to use less memory? If not, perhaps we could hook into the mechanism that other tests use when the allocate large blocks of memory, to cause them to be skipped in low-memory situations. ---------- components: Tests messages: 281185 nosy: martin.panter, rhettinger priority: normal severity: normal status: open title: test_choices_algorithms() in test_random uses lots of memory type: resource usage versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 19:57:10 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 19 Nov 2016 00:57:10 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1479514571.65.0.290447152683.issue28739@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Might I point out the precedent of b-strings? Those also don't contribute to __doc__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 20:01:33 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Nov 2016 01:01:33 +0000 Subject: [issue25659] ctypes.Array.from_buffer segmentation fault when trying to create from array.array In-Reply-To: <1447869436.37.0.609997226839.issue25659@psf.upfronthosting.co.za> Message-ID: <1479517293.59.0.763727294047.issue25659@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch implementing Eryk?s suggestion, for both from_buffer() and from_buffer_copy() methods. This is exactly how it is already handled for Array.from_address(). The two buffer methods were added more recently than from_address(). ---------- keywords: +patch nosy: +martin.panter stage: -> patch review versions: +Python 3.7 -Python 3.4 Added file: http://bugs.python.org/file45543/from_buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 20:11:30 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 19 Nov 2016 01:11:30 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za> Message-ID: <1479517890.15.0.522912055425.issue28739@psf.upfronthosting.co.za> Ned Deily added the comment: Since this was previously discussed and rejected (in Issue25179), I don't think we should revisit this now for 3.6, other than potentially a documentation tweak. ---------- nosy: +ned.deily versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 20:18:15 2016 From: report at bugs.python.org (Peter Eckersley) Date: Sat, 19 Nov 2016 01:18:15 +0000 Subject: [issue28742] argparse.ArgumentDefaultsHelpFormatter sometimes provides inaccurate documentation of defaults, so they should be overrideable In-Reply-To: <1479514629.23.0.218870455687.issue28742@psf.upfronthosting.co.za> Message-ID: <1479518295.37.0.868475408397.issue28742@psf.upfronthosting.co.za> Peter Eckersley added the comment: Patch is now against the latest Python development tree, and includes test cases: https://gist.github.com/pde/daec08cadc21bca0d62852020887ee13 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 20:19:30 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 19 Nov 2016 01:19:30 +0000 Subject: [issue28548] http.server parse_request() bug and error reporting In-Reply-To: <1477670229.81.0.419990644201.issue28548@psf.upfronthosting.co.za> Message-ID: <20161119011926.14116.19836.E75E72B0@psf.io> Roundup Robot added the comment: New changeset 7c98768368cb by Martin Panter in branch 'default': Issue #28548: Parse HTTP request version even if too many words received https://hg.python.org/cpython/rev/7c98768368cb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 20:52:48 2016 From: report at bugs.python.org (Renner) Date: Sat, 19 Nov 2016 01:52:48 +0000 Subject: [issue28744] Basic precision calc error Message-ID: <1479520368.98.0.185264707762.issue28744@psf.upfronthosting.co.za> New submission from Renner: Simple code: print('%.55f' %(1.1 + 2.2 - 3.3)) print('%.55f' %(1.1 + 2.2)) is supposed to produce 0.0000000000000000000000000000000000000000000000000000000 3.3000000000000000000000000000000000000000000000000000000 But when I run it, Actually it produces 0.0000000000000004440892098500626161694526672363281250000 3.3000000000000002664535259100375697016716003417968750000 Found by chance... python 3.5.2 sysname:'Darwin' release:'15.6.0 version:'Darwin Kernel Version 15.6.0: Thu Jun 23 18:25:34 PDT 2016; root:xnu-3248.60.10~1/RELEASE_X86_64') ---------- components: Interpreter Core messages: 281191 nosy: Renner priority: normal severity: normal status: open title: Basic precision calc error type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 21:13:35 2016 From: report at bugs.python.org (Zachary Ware) Date: Sat, 19 Nov 2016 02:13:35 +0000 Subject: [issue28744] Basic precision calc error In-Reply-To: <1479520368.98.0.185264707762.issue28744@psf.upfronthosting.co.za> Message-ID: <1479521615.1.0.307274371773.issue28744@psf.upfronthosting.co.za> Zachary Ware added the comment: https://docs.python.org/3/tutorial/floatingpoint.html ---------- nosy: +zach.ware resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 22:04:18 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Nov 2016 03:04:18 +0000 Subject: [issue20572] subprocess.Popen.wait() undocumented "endtime" parameter In-Reply-To: <1391941400.18.0.703922206544.issue20572@psf.upfronthosting.co.za> Message-ID: <1479524658.63.0.158321613876.issue20572@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks Mariatta. Some people like to use the warn(stacklevel=2) parameter, then the warning message is potentially more useful. Also, I think it would be good to write a brief test case for the warning. There are probably lots of examples in the test suite, e.g. search for DeprecationWarning in revision 0dd263949e41. Have you checked if there is existing code using the endtime=... parameter? It you run the test suite with -Werror enabled, that would be a good indicator. Maybe it is okay to remove the parameter completely in 3.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 22:04:31 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Nov 2016 03:04:31 +0000 Subject: [issue20572] subprocess.Popen.wait() undocumented "endtime" parameter In-Reply-To: <1391941400.18.0.703922206544.issue20572@psf.upfronthosting.co.za> Message-ID: <1479524671.46.0.204237441652.issue20572@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: -> patch review versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 22:06:33 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Nov 2016 03:06:33 +0000 Subject: [issue28548] http.server parse_request() bug and error reporting In-Reply-To: <1477670229.81.0.419990644201.issue28548@psf.upfronthosting.co.za> Message-ID: <1479524793.92.0.457440237099.issue28548@psf.upfronthosting.co.za> Martin Panter added the comment: Okay committed to 3.7 for the moment. I think that is all we can reasonably do unless we drop the pseudo-HTTP-0.9 support. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 22:17:48 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 19 Nov 2016 03:17:48 +0000 Subject: [issue10049] Add a "no-op" (null) context manager to contextlib (Rejected: use contextlib.ExitStack()) In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za> Message-ID: <1479525468.9.0.883287276078.issue10049@psf.upfronthosting.co.za> Nick Coghlan added the comment: The problem Martin is referring to is the SEO one, which is that the top link when searching for either "null context manager python" or "no-op context manager python" is this thread, rather than the "Use ExitStack for that" recipe in the docs: https://docs.python.org/3/library/contextlib.html#simplifying-support-for-single-optional-context-managers We unfortunately have exactly zero SEO experts working on the CPython documentation, so even when we provide specific recipes in the docs for solving particular problems, they aren't always easy for people to find. I've at least added the "use contextlib.ExitStack()" note to the issue title here, so folks can find that without having to read through the whole comment thread. ---------- title: Add a "no-op" (null) context manager to contextlib -> Add a "no-op" (null) context manager to contextlib (Rejected: use contextlib.ExitStack()) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 22:18:58 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Nov 2016 03:18:58 +0000 Subject: [issue10656] "Out of tree" build fails on AIX In-Reply-To: <1291865704.62.0.494509897126.issue10656@psf.upfronthosting.co.za> Message-ID: <1479525538.39.0.161034651879.issue10656@psf.upfronthosting.co.za> Martin Panter added the comment: Okay I will assume that $(srcdir) reference was just due to a mistake or bad cargo-culting then. Will commit this soon unless anyone has a good idea to avoid embedding @abs_srcdir at . ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 22:30:48 2016 From: report at bugs.python.org (Patrick Lehmann) Date: Sat, 19 Nov 2016 03:30:48 +0000 Subject: [issue28710] Sphinx incompatible markup in configparser.ConfigParser. In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za> Message-ID: <1479526248.71.0.640863880709.issue28710@psf.upfronthosting.co.za> Patrick Lehmann added the comment: Hello, I used this regexp on all files: -------------------------------------- match pattern: `([A-Za-z0-9_]+)' replace pattern ``\1`` -------------------------------------- I assumed that only identifiers where quoted in such way. I think my editor found around 139 matches in the whole CPython repository. I found some of these markup in non docstring strings, which I reverted as far as I found them by manually reviewing all changed files. For a colored diff, see my Git branch: https://github.com/Paebbels/cpython/commit/6d3f348f71b5b0ae9fbfcb8fdbba72dc5fac428a?ts=2 There is also a PR-, commit-, and line-based comment feature box GitHub. How you solve it is up to you, but I would like to get rid of hundreds of warnings in my Sphinx runs, when modules are inherting code (and docstrings) from Python. Kind regards Patrick ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 18 22:39:44 2016 From: report at bugs.python.org (Patrick Lehmann) Date: Sat, 19 Nov 2016 03:39:44 +0000 Subject: [issue28710] Sphinx incompatible markup in configparser.ConfigParser. In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za> Message-ID: <1479526784.67.0.633927937364.issue28710@psf.upfronthosting.co.za> Patrick Lehmann added the comment: .... I signed the CLA. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 00:19:37 2016 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Sat, 19 Nov 2016 05:19:37 +0000 Subject: [issue28681] About function renaming in the tutorial In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za> Message-ID: <1479532777.19.0.779270636267.issue28681@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: Obligatory link: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ :-P Yes, Python objects are simpler than people, but still not completely trivial. The core issue is "who does the calling". Even one's native language might subtly (in Orwell sense) alter what they mean the name is. English question "What is your name?" is usually translated into Croatian (and some other Slavic languages) as "Kako se zove??", literally "how do you call yourself". In some other languages, it's "how should I call you". I think you agree those are three different concepts. And I think most disagreements between people in these discussions stem from those cultural differences. (Even people who consider English their native language might still have cultural differences, since English is spoken so widely.) In Python, the most important distinction is "name as own identity"(1) vs "name as handle for calling"(2). Of course, we all know that each of these concepts have disadvantages, and as such, cannot serve completely. name(1) is not something all objects have (but e.g. functions and classes do), while name(2) is external to the object - each of existing namespaces might or might not have a way (or three, or infinitely many) to refer to it. And all those ways are not considered to be known to the object itself. Since this concrete example speaks about names of functions defined with a def statement, those concepts coincide, and that's why some people have thought it speaks about name(1) and some others have thought it speaks about name(2). If we want to be completely honest, we should clarify that "name" is used in two ways, and that later text speaks only about name(2). But it might be too much for beginners. In that case, we should probably avoid mention name(1) sense until much later, and speak only of names as "name(2)". ---------- nosy: +veky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 00:51:44 2016 From: report at bugs.python.org (Martin Blais) Date: Sat, 19 Nov 2016 05:51:44 +0000 Subject: [issue10049] Add a "no-op" (null) context manager to contextlib (Rejected: use contextlib.ExitStack()) In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za> Message-ID: <1479534704.72.0.482659738297.issue10049@psf.upfronthosting.co.za> Martin Blais added the comment: Adding nullcontext = ExitStack in the source file would solve this problem in a single line of code. ---------- nosy: +blais _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 00:54:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Nov 2016 05:54:20 +0000 Subject: [issue28743] test_choices_algorithms() in test_random uses lots of memory In-Reply-To: <1479516464.04.0.874513077096.issue28743@psf.upfronthosting.co.za> Message-ID: <1479534860.81.0.915747491688.issue28743@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is a problem to me too. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 00:56:25 2016 From: report at bugs.python.org (woo yoo) Date: Sat, 19 Nov 2016 05:56:25 +0000 Subject: [issue28745] Python 3.5.2 "from ... import" statement is different from official documentation Message-ID: <1479534985.73.0.593618849184.issue28745@psf.upfronthosting.co.za> New submission from woo yoo: I've experiment with the statement,however the result did not match the official description. I created a namespace package named l007, within which submodule named l009 was placed.I typed "from l007 import l009" in the interpreter, the execution was ok, while in which case a ImportError should have been raised. Is my understanding wrong? ---------- assignee: docs at python components: Documentation files: ??.PNG messages: 281202 nosy: docs at python, woo yoo priority: normal severity: normal status: open title: Python 3.5.2 "from ... import" statement is different from official documentation type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file45544/??.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 01:05:32 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 19 Nov 2016 06:05:32 +0000 Subject: [issue28745] Python 3.5.2 "from ... import" statement is different from official documentation In-Reply-To: <1479534985.73.0.593618849184.issue28745@psf.upfronthosting.co.za> Message-ID: <1479535532.59.0.285206052715.issue28745@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Please don't post screen shots of text. Copy and paste the text into the bug report. Some people (those who are blind, visually impaired or using a screen-reader for some other reason) cannot see the screen shot, and even those who can prefer to deal with text that can be copied and pasted, not pixels. Please show (in text, not a picture) the layout and contents of your package, the exact Python code you used, the result you expected, and the result you actually got. If an import succeeded that you expected to fail, please print module.__file__ to ensure that you have imported the module you expected to import. Ideally anyone (fully sighted or not) should be able to copy and paste your code into the Python interpreter and determine whether or not they get the same results as you. Thank you. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 01:07:48 2016 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 19 Nov 2016 06:07:48 +0000 Subject: [issue28745] Python 3.5.2 "from ... import" statement is different from official documentation In-Reply-To: <1479534985.73.0.593618849184.issue28745@psf.upfronthosting.co.za> Message-ID: <1479535668.28.0.0520769336143.issue28745@psf.upfronthosting.co.za> Steven D'Aprano added the comment: If you're quoting from the docs, its a good idea to give the URL to *which* documentation you are reading, not just a copy of the text. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 01:25:13 2016 From: report at bugs.python.org (woo yoo) Date: Sat, 19 Nov 2016 06:25:13 +0000 Subject: [issue28745] Python 3.5.2 "from ... import" statement is different from official documentation In-Reply-To: <1479534985.73.0.593618849184.issue28745@psf.upfronthosting.co.za> Message-ID: <1479536713.46.0.89905180411.issue28745@psf.upfronthosting.co.za> woo yoo added the comment: The link associated with the documentation is https://docs.python.org/3/reference/simple_stmts.html#import. My package layout is : --l007 --l009.py My code is : >from l007 import l009 The excution was ok, which was not the case i had expected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 01:52:26 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 19 Nov 2016 06:52:26 +0000 Subject: [issue28745] Python 3.5.2 "from ... import" statement is different from official documentation In-Reply-To: <1479534985.73.0.593618849184.issue28745@psf.upfronthosting.co.za> Message-ID: <1479538346.0.0.663519626274.issue28745@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Why is this unexpected? Per the docs, the process is: find the module specified in the from clause, loading and initializing it if necessary; for each of the identifiers specified in the import clauses: check if the imported module has an attribute by that name *** if not, attempt to import a submodule with that name and then check the imported module again for that attribute if the attribute is not found, ImportError is raised. otherwise, a reference to that value is stored in the local namespace, using the name in the as clause if it is present, otherwise using the attribute name The *** is next to where it ends up in the tree; it found the l007 package, determined it had no attribute named l009, determined it did have a module of that name, and imported it. What were you expecting? For the record, it would be nice if you'd used a name that didn't begin with a lowercase L; it makes it look like the module is named entirely with digits (which would be illegal). ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 02:23:51 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 19 Nov 2016 07:23:51 +0000 Subject: [issue28740] Add sys.getandroidapilevel() In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za> Message-ID: <1479540231.4.0.759937484745.issue28740@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > I proposed to add a new function to the sys module: sys.getandroidapilevel() This would also help fixing the long standing issue 16255, and possibly also issue 16353. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 02:27:09 2016 From: report at bugs.python.org (woo yoo) Date: Sat, 19 Nov 2016 07:27:09 +0000 Subject: [issue28745] Python 3.5.2 "from ... import" statement is different from official documentation In-Reply-To: <1479534985.73.0.593618849184.issue28745@psf.upfronthosting.co.za> Message-ID: <1479540429.74.0.439558944046.issue28745@psf.upfronthosting.co.za> woo yoo added the comment: Thanks for your advice. ---------- nosy: -docs at python, steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 02:53:55 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 19 Nov 2016 07:53:55 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1479542035.88.0.159654815673.issue26865@psf.upfronthosting.co.za> Xavier de Gaye added the comment: issue #28740: Add sys.getandroidapilevel() ---------- dependencies: +Add sys.getandroidapilevel() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 02:56:36 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 19 Nov 2016 07:56:36 +0000 Subject: [issue28740] Add sys.getandroidapilevel() In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za> Message-ID: <1479542196.39.0.662214736297.issue28740@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Patch tested with success on the android-24 emulator. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 03:04:42 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 19 Nov 2016 08:04:42 +0000 Subject: [issue28740] Add sys.getandroidapilevel() In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za> Message-ID: <1479542682.86.0.810418346883.issue28740@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Maybe time to re-implement android_ver() in issue26855 in C. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 04:14:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Nov 2016 09:14:23 +0000 Subject: [issue28719] zipfile increase in size In-Reply-To: <1479330966.86.0.764348227568.issue28719@psf.upfronthosting.co.za> Message-ID: <1479546863.16.0.815796771323.issue28719@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If the output file is not seekable, zipfile sets bit 3 in file header flags and writes 12 or 20 (if ZIP64 extension is used) additional bytes after the compressed data. These bytes contain the CRC, compressed and uncompressed sizes. Corresponding fields in local file header are set to zero. In case of writestr() this can be considered as a regression, since the CRC and sizes can be calculated before writing compressed data and saved in local file header. But it would be not easy to fix this. ---------- assignee: -> serhiy.storchaka components: +Library (Lib) stage: -> needs patch type: resource usage -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 05:41:14 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 19 Nov 2016 10:41:14 +0000 Subject: [issue28740] Add sys.getandroidapilevel() In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za> Message-ID: <1479552074.26.0.629622399597.issue28740@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: I translate the Python version at issue26855 to C. Quite new to the C API, hope I'm doing it right :) Codes only. Docs and tests later sys.getwindowsversion() uses named tuples. Is there a similar need for Android or just plain tuples are fine? ---------- Added file: http://bugs.python.org/file45545/sys_getandroidversion.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 06:16:31 2016 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 19 Nov 2016 11:16:31 +0000 Subject: [issue28745] Python 3.5.2 "from ... import" statement is different from official documentation In-Reply-To: <1479534985.73.0.593618849184.issue28745@psf.upfronthosting.co.za> Message-ID: <1479554191.0.0.863430118725.issue28745@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 06:23:30 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 19 Nov 2016 11:23:30 +0000 Subject: [issue28740] Add sys.getandroidapilevel() In-Reply-To: <1479552074.26.0.629622399597.issue28740@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I didn't know that there are build and runtime versions. If the runtime version is available, it should be preferred. Hum, maybe its better to expose the __system_property_get() function in the os module, something similar to os.confstr()? https://docs.python.org/dev/library/os.html#os.confstr If the OS returns a string, I suggest to return a string in Python too. The caller would be responsible to convert it to integer. What do you think of that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 07:23:07 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 19 Nov 2016 12:23:07 +0000 Subject: [issue10049] Add a "no-op" (null) context manager to contextlib (Rejected: use contextlib.ExitStack()) In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za> Message-ID: <1479558186.99.0.210816652081.issue10049@psf.upfronthosting.co.za> Nick Coghlan added the comment: No, it wouldn't, as ExitStack() does far more than merely implement a null context. It would be like adding "nulliterable = ()" as a builtin, rather than just telling people "If you need a null iterable, use an empty tuple". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 08:13:36 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 19 Nov 2016 13:13:36 +0000 Subject: [issue28740] Add sys.getandroidapilevel() In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za> Message-ID: <1479561216.82.0.948647083948.issue28740@psf.upfronthosting.co.za> Xavier de Gaye added the comment: __system_property_get() is not a public API, see Android bug report [1]. In this stackoverflow question, an Android developer confirms this point and suggests to use the file /system/build.prop instead, noting however that "build.prop isn't guaranteed to be stable (or even present)". This interesting document [3] describes the Android properties management design. I think we must use the reliable build time Android API level and implement sys.getandroidapilevel() (Victor patch) for knowing, in the standard library, whether we are running on an Android platform, and provide a best effort platform.android_ver() for the Android run time version. Things are changing very fast with the Android project and the OEM may add their own changes too. [1] https://code.google.com/p/android/issues/detail?id=143627 [2] http://stackoverflow.com/questions/28413530/api-to-get-android-system-properties-is-removed-in-arm64-platforms [3] http://rxwen.blogspot.fr/2010/01/android-property-system.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 08:26:21 2016 From: report at bugs.python.org (Gareth Rees) Date: Sat, 19 Nov 2016 13:26:21 +0000 Subject: [issue28743] test_choices_algorithms() in test_random uses lots of memory In-Reply-To: <1479516464.04.0.874513077096.issue28743@psf.upfronthosting.co.za> Message-ID: <1479561981.42.0.407460730435.issue28743@psf.upfronthosting.co.za> Gareth Rees added the comment: Couldn't the test case use something like this to avoid allocating so much memory? from collections.abc import Sequence class RepeatedSequence(Sequence): """Immutable sequence of n repeats of elem.""" def __init__(self, elem, n): self.elem = elem self.n = n def __getitem__(self, key): return self.elem def __len__(self): return self.n and then: self.gen.choices(range(n), RepeatedSequence(1, n), k=10000) ---------- nosy: +Gareth.Rees _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 08:29:57 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 19 Nov 2016 13:29:57 +0000 Subject: [issue28740] Add sys.getandroidapilevel() In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za> Message-ID: <1479562197.19.0.259325444554.issue28740@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The build time Android API level is also a valuable information to Python users (application developers), it may be used at installation time or to detect a version mismatch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 08:47:39 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Nov 2016 13:47:39 +0000 Subject: [issue28743] test_choices_algorithms() in test_random uses lots of memory In-Reply-To: <1479516464.04.0.874513077096.issue28743@psf.upfronthosting.co.za> Message-ID: <1479563259.12.0.83590083061.issue28743@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The main memory consumer is a list of cumulated weights created inside choices(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 08:49:12 2016 From: report at bugs.python.org (Gareth Rees) Date: Sat, 19 Nov 2016 13:49:12 +0000 Subject: [issue28743] test_choices_algorithms() in test_random uses lots of memory In-Reply-To: <1479516464.04.0.874513077096.issue28743@psf.upfronthosting.co.za> Message-ID: <1479563352.44.0.117879496001.issue28743@psf.upfronthosting.co.za> Gareth Rees added the comment: In order for this to work, the __getitem__ method needs to be: def __getitem__(self, key): if 0 <= key < self.n: return self.elem else: raise IndexError(key) But unfortunately this is very bad for the performance of the test. The original code, with [1]*n: Ran 1 test in 5.256s With RepeatedSequence(1, n): Ran 1 test in 33.620s So that's no good. However, I notice that although the documentation of choices specifies that weights is a sequence, in fact it seems only to require an iterable: cum_weights = list(_itertools.accumulate(weights)) so itertools.repeat works, and is faster than the original code: Ran 1 test in 4.991s Patch attached, in case it's acceptable to pass an iterable here. ---------- keywords: +patch Added file: http://bugs.python.org/file45546/issue28743.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 09:19:33 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 19 Nov 2016 14:19:33 +0000 Subject: [issue28746] cannot set_inheritable() for a file descriptor on Android Message-ID: <1479565173.32.0.268004385274.issue28746@psf.upfronthosting.co.za> New submission from Xavier de Gaye: test_socket on Android fails with: FAIL: test_set_inheritable (test.test_socket.InheritanceTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sdcard/org.bitbucket.pyona/lib/python3.7/test/test_socket.py", line 4936, in test_set_inheritable self.assertEqual(sock.get_inheritable(), True) AssertionError: False != True ====================================================================== FAIL: test_set_inheritable_cloexec (test.test_socket.InheritanceTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sdcard/org.bitbucket.pyona/lib/python3.7/test/test_socket.py", line 4965, in test_set_inheritable_cloexec 0) AssertionError: 1 != 0 Setting a file descriptor with os.set_inheritable() also fails. Setting directly the file descriptor with fcntl.fcntl() succeeds. ---------- assignee: xdegaye components: Interpreter Core messages: 281221 nosy: xdegaye priority: normal severity: normal stage: needs patch status: open title: cannot set_inheritable() for a file descriptor on Android type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 09:26:07 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 19 Nov 2016 14:26:07 +0000 Subject: [issue28746] cannot set_inheritable() for a file descriptor on Android In-Reply-To: <1479565173.32.0.268004385274.issue28746@psf.upfronthosting.co.za> Message-ID: <1479565567.69.0.00314124999327.issue28746@psf.upfronthosting.co.za> Xavier de Gaye added the comment: It seems the code path run by Android is not tested by any of the buildbots. Patch attached. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file45547/set_inheritable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 09:53:04 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 19 Nov 2016 14:53:04 +0000 Subject: [issue28740] Add sys.getandroidapilevel() In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za> Message-ID: <1479567184.43.0.600305951592.issue28740@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: Both sys.androidapilevel() and platform.android_ver() return information about Android's API level. I guess that would be confusing so I hope to get them unified. Techinically it won't be a problem as Chromium is still using it (in a even dirty way) and the plan to remove it is stalled. [1] [1] https://bugs.chromium.org/p/chromium/issues/detail?id=392191 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 10:15:37 2016 From: report at bugs.python.org (Aviv Palivoda) Date: Sat, 19 Nov 2016 15:15:37 +0000 Subject: [issue28729] Exception from sqlite3 adapter masked by sqlite3.InterfaceError In-Reply-To: <1479425140.19.0.0824888445668.issue28729@psf.upfronthosting.co.za> Message-ID: <1479568537.44.0.625785481601.issue28729@psf.upfronthosting.co.za> Changes by Aviv Palivoda : ---------- nosy: +palaviv _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 10:21:29 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 19 Nov 2016 15:21:29 +0000 Subject: [issue28746] cannot set_inheritable() for a file descriptor on Android In-Reply-To: <1479565173.32.0.268004385274.issue28746@psf.upfronthosting.co.za> Message-ID: <20161119152116.10449.60078.3BA1140C@psf.io> Roundup Robot added the comment: New changeset 2fb2e3dc450e by Xavier de Gaye in branch '3.6': Issue #28746: Fix the set_inheritable() file descriptor method on platforms https://hg.python.org/cpython/rev/2fb2e3dc450e New changeset 3248782c3176 by Xavier de Gaye in branch 'default': Issue #28746: Merge 3.6 https://hg.python.org/cpython/rev/3248782c3176 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 11:35:49 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 19 Nov 2016 16:35:49 +0000 Subject: [issue28746] cannot set_inheritable() for a file descriptor on Android In-Reply-To: <1479565173.32.0.268004385274.issue28746@psf.upfronthosting.co.za> Message-ID: <1479573349.49.0.131714871821.issue28746@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 12:12:07 2016 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 19 Nov 2016 17:12:07 +0000 Subject: [issue28741] PEP 498: single '}' is not allowed In-Reply-To: <1479505916.83.0.442816788413.issue28741@psf.upfronthosting.co.za> Message-ID: <1479575527.84.0.758911306109.issue28741@psf.upfronthosting.co.za> Eric V. Smith added the comment: Thanks. Fixed in the pep repo in 4e86033. ---------- assignee: docs at python -> eric.smith resolution: -> fixed status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 13:33:31 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 19 Nov 2016 18:33:31 +0000 Subject: [issue28556] typing.py upgrades In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za> Message-ID: <20161119183328.46084.53263.6A1D3EFF@psf.io> Roundup Robot added the comment: New changeset 1e49abb03e0f by Guido van Rossum in branch '3.5': Issue #28556: two more small upstream changes by Ivan Levkivskyi (#329, #330) https://hg.python.org/cpython/rev/1e49abb03e0f New changeset cdddf4ee0e00 by Guido van Rossum in branch '3.6': Issue #28556: two more small upstream changes by Ivan Levkivskyi (#329, #330) (3.5->3.6) https://hg.python.org/cpython/rev/cdddf4ee0e00 New changeset 1465baaccd84 by Guido van Rossum in branch 'default': Issue #28556: two more small upstream changes by Ivan Levkivskyi (#329, #330) (3.6->3.7) https://hg.python.org/cpython/rev/1465baaccd84 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 14:28:50 2016 From: report at bugs.python.org (Masayuki Yamamoto) Date: Sat, 19 Nov 2016 19:28:50 +0000 Subject: [issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX In-Reply-To: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za> Message-ID: <1479583730.84.0.404415930447.issue25658@psf.upfronthosting.co.za> Masayuki Yamamoto added the comment: I wrote a patch to avoid compile error for platforms that pthread_key_t is not integer. This patch changes to turn off Py_HAVE_NATIVE_TLS if pthread_key_t is not integer. Hence the platforms use TLS functions implemented by CPython self. And, I would propose new thread local storage API based on C11 thread and current TLS functions move to deprecated. C11 tss_t doesn't require defined as integer [1]. Therefore I think new API should use tss_t, not hide into integer. [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf (page 394) I'm thinking of new interfaces. For example, declaration in Include/pythread.h /* Specialise to each platforms using #if directive */ typedef /* TLS key types or C11 tss_t */ Py_tss_t; /* Based on C11 threads.h, but destructor doesn't support. the delete value function is maintained for the implementation by CPython self. */ PyAPI_FUNC(int) PyThread_tss_create(Py_tss_t *); PyAPI_FUNC(void) PyThread_tss_delete(Py_tss_t); PyAPI_FUNC(void *) PyThread_tss_get(Py_tss_t); PyAPI_FUNC(int) PyThread_tss_set(Py_tss_t, void *); PyAPI_FUNC(void) PyThread_tss_delete_value(Py_tss_t); ---------- Added file: http://bugs.python.org/file45548/configure-pthread_key_t.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 14:33:10 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Nov 2016 19:33:10 +0000 Subject: [issue27945] Various segfaults with dict In-Reply-To: <1472852008.61.0.354257945943.issue27945@psf.upfronthosting.co.za> Message-ID: <1479583990.63.0.358707415313.issue27945@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a consolidated patch for review. ---------- Added file: http://bugs.python.org/file45549/27945-dict-segv-py36.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 16:33:29 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Nov 2016 21:33:29 +0000 Subject: [issue27945] Various segfaults with dict In-Reply-To: <1472852008.61.0.354257945943.issue27945@psf.upfronthosting.co.za> Message-ID: <1479591209.35.0.475177651427.issue27945@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The change to dict_equal() LGTM. It doesn't add an overhead. For dictiter_iternextitem() I propose other change. It doesn't add an overhead. There are bugs in the patch for _PyDict_FromKeys(). The change to dictitems_contains() adds an overhead, but it is small and seems unavoidable. I wondering whether it is worth to use PySequence_Tuple() instead of PySequence_Fast() in PyDict_MergeFromSeq2(). This would add a cost of creating new tuple if items are not tuples, but save increfing/decrefing the key and the value in common case. I have doubts about insertdict(). Additional incref duplicates increfs in dict_merge(). Is it worth to move it outside of insertdict()? I have doubts about _PyDict_FromKeys(). It seems to me that it is safe to use _PyDict_Next() in a loop that mutates the dict (not checked _PySet_Next()). With guarded insertdict() additional check is not needed (and it doesn't help against clearing the dict inside insertdict()). In updated patch fixed some bugs and used different solution for dictiter_iternextitem(). ---------- Added file: http://bugs.python.org/file45550/27945-dict-segv-py37-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 16:36:12 2016 From: report at bugs.python.org (Steve Dower) Date: Sat, 19 Nov 2016 21:36:12 +0000 Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback Message-ID: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za> New submission from Steve Dower: As a prerequisite for fixing issues such as issue20916 (dynamic download/update of CAs and CRLs), we really need to be able to plug into the certificate verification function for OpenSSL. This patch adds SSLContext._set_cert_verify_callback, which will allow Python code to inject its own verification function. No other functionality is added, but I have proof-of-concept code that uses this patch to delegate all certificate handling to Windows and it works beautifully (better than I expected :) ). If possible, I'd like to get this into Python 3.6. I intend to turn that proof-of-concept into an actual released library and would like to be able to do it sooner rather than later. Targeting 3.6 is the main reason I named the function with an underscore, but I'd be happy to drop it. ---------- assignee: christian.heimes components: SSL messages: 281230 nosy: christian.heimes, ned.deily, steve.dower priority: normal severity: normal stage: patch review status: open title: Expose SSL_CTX_set_cert_verify_callback type: security versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 16:37:36 2016 From: report at bugs.python.org (Steve Dower) Date: Sat, 19 Nov 2016 21:37:36 +0000 Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za> Message-ID: <1479591456.66.0.194614243228.issue28747@psf.upfronthosting.co.za> Steve Dower added the comment: Patch attached with code changes and basic tests. Doc changes to follow. ---------- keywords: +patch Added file: http://bugs.python.org/file45551/28747_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 16:38:02 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Sat, 19 Nov 2016 21:38:02 +0000 Subject: [issue27583] configparser: modifying default_section at runtime In-Reply-To: <1469105653.63.0.572086425799.issue27583@psf.upfronthosting.co.za> Message-ID: <1479591482.28.0.413185704907.issue27583@psf.upfronthosting.co.za> Wolfgang Maier added the comment: Well, you *can* change the value at runtime as you are demonstrating in your script, but you are misunderstanding the effect this will have. It *won't* cause a reevaluation of an already parsed config file. Instead it will affect the writing of the parsed settings to a new config file. This is explained a bit further up in the documentation of the module: https://docs.python.org/3/library/configparser.html#customizing-parser-behaviour where it says: "Its current value can be retrieved using the parser_instance.default_section attribute and may be modified at runtime (i.e. to convert files from one format to another)." So maybe this hint could be repeated in the actual parameter description of https://docs.python.org/3/library/configparser.html#configparser-objects to avoid confusion, but I don't think there is a bug here. ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 16:39:22 2016 From: report at bugs.python.org (Steve Dower) Date: Sat, 19 Nov 2016 21:39:22 +0000 Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za> Message-ID: <1479591561.99.0.932387745184.issue28747@psf.upfronthosting.co.za> Steve Dower added the comment: Oh, I also made the SSL module chain exceptions properly. That's probably the biggest and scariest part of the change, but it can't have been overwriting exceptions before anyway (because it calls back into Python code to instantiate SSLError), so it's only going to chain in the new case of the callback function raising. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 17:30:05 2016 From: report at bugs.python.org (Martin Blais) Date: Sat, 19 Nov 2016 22:30:05 +0000 Subject: [issue10049] Add a "no-op" (null) context manager to contextlib (Rejected: use contextlib.ExitStack()) In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za> Message-ID: <1479594605.84.0.219415522902.issue10049@psf.upfronthosting.co.za> Martin Blais added the comment: Well that just echoes exactly what I originally thought, but somebody else said it was not needed because ExitStack already exists and could be used for that purpose. If this were at work and/or it were all just to me, I'd just implement a brand new nullcontext and move on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 18:08:47 2016 From: report at bugs.python.org (Christian Heimes) Date: Sat, 19 Nov 2016 23:08:47 +0000 Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za> Message-ID: <1479596927.37.0.101784699859.issue28747@psf.upfronthosting.co.za> Christian Heimes added the comment: Hi Steve, there is a better approach to fix issue20916. The verify callback is not the correct API, because it is called too late. We want to hook into the cert resolution mechanism of OpenSSL and get trust anchors and CRLs in before OpenSSL builds the verification chain. Instead of a verify cb we have to implement a X509_LOOKUP_METHOD with a get_by_subject(). The function looks up X509_LU_CRL or X509_LU_X509 by X509_NAME. The other lookups functions (fingerprint, issuer) aren't used to look up root CAs. Then use some CAPI function like CertFindCertificateInStore() with CERT_FIND_SUBJECT_NAME to look up the cert, convert it to OpenSSL X509 object, copy the additional trust flags from Windows' cert type to the X509_CERT_AUX member of OpenSSL's X509 type. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 18:33:08 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 19 Nov 2016 23:33:08 +0000 Subject: [issue27583] configparser: modifying default_section at runtime In-Reply-To: <1469105653.63.0.572086425799.issue27583@psf.upfronthosting.co.za> Message-ID: <1479598388.93.0.104618511633.issue27583@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 18:59:51 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 19 Nov 2016 23:59:51 +0000 Subject: [issue28740] Add sys.getandroidapilevel() In-Reply-To: Message-ID: STINNER Victor added the comment: > I think we must use the reliable build time Android API level and implement sys.getandroidapilevel() (Victor patch) for knowing, in the standard library, whether we are running on an Android platform, and provide a best effort platform.android_ver() for the Android run time version. Things are changing very fast with the Android project and the OEM may add their own changes too. Hum, IMO we should at least use a structure with names for the sys function to be able to return more information later. Maybe call the function sys.getandroidversion()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 19:44:42 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 20 Nov 2016 00:44:42 +0000 Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za> Message-ID: <1479602682.63.0.483594270933.issue28747@psf.upfronthosting.co.za> Steve Dower added the comment: When I was stepping through, this callback avoided all of those lookups, so I don't understand how it's being called too late? This approach basically takes the entire raw certificate and lets the OS do whatever it needs. OpenSSL doesn't ever have to crack it open at all (or at least when it does, it can assume the whole chain is trusted). What am I missing here? I've got no doubt I'm missing something, as OpenSSL is possibly the most complicated code I've ever seen :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 20:10:18 2016 From: report at bugs.python.org (Antony Lee) Date: Sun, 20 Nov 2016 01:10:18 +0000 Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> Message-ID: <1479604218.61.0.0146214470129.issue24459@psf.upfronthosting.co.za> Antony Lee added the comment: PYTHONUSERBASE is also missing. ---------- nosy: +Antony.Lee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 20:10:36 2016 From: report at bugs.python.org (Antony Lee) Date: Sun, 20 Nov 2016 01:10:36 +0000 Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> Message-ID: <1479604236.2.0.560868079631.issue24459@psf.upfronthosting.co.za> Changes by Antony Lee : ---------- nosy: -Antony.Lee _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 21:10:43 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 20 Nov 2016 02:10:43 +0000 Subject: [issue28732] spawnl crash on windows7 In-Reply-To: <1479468155.36.0.0223780421373.issue28732@psf.upfronthosting.co.za> Message-ID: <1479607843.8.0.816442513521.issue28732@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- assignee: -> steve.dower versions: +Python 3.6, Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 21:42:08 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Nov 2016 02:42:08 +0000 Subject: [issue28732] spawnl crash on windows7 In-Reply-To: <1479468155.36.0.0223780421373.issue28732@psf.upfronthosting.co.za> Message-ID: <20161120024205.46126.59176.F61A1FBB@psf.io> Roundup Robot added the comment: New changeset 02f416441def by Steve Dower in branch '3.5': Issue #28732: Fix crash in os.spawnv() with no elements in args https://hg.python.org/cpython/rev/02f416441def ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 21:51:44 2016 From: report at bugs.python.org (Eryk Sun) Date: Sun, 20 Nov 2016 02:51:44 +0000 Subject: [issue28732] spawnl crash on windows7 In-Reply-To: <1479468155.36.0.0223780421373.issue28732@psf.upfronthosting.co.za> Message-ID: <1479610304.01.0.102762498625.issue28732@psf.upfronthosting.co.za> Eryk Sun added the comment: A ValueError should also be raised when argv[0] is an empty string. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 21:53:47 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Nov 2016 02:53:47 +0000 Subject: [issue28732] spawnl crash on windows7 In-Reply-To: <1479468155.36.0.0223780421373.issue28732@psf.upfronthosting.co.za> Message-ID: <20161120025344.40975.41061.831F670F@psf.io> Roundup Robot added the comment: New changeset 1a9e4b465497 by Steve Dower in branch '3.6': Issue #28732: Raise ValueError when os.spawn*() is passed an empty tuple of arguments https://hg.python.org/cpython/rev/1a9e4b465497 New changeset 75824899f0dd by Steve Dower in branch 'default': Issue #28732: Raise ValueError when os.spawn*() is passed an empty tuple of arguments https://hg.python.org/cpython/rev/75824899f0dd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 22:18:00 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Nov 2016 03:18:00 +0000 Subject: [issue28732] spawnl crash on windows7 In-Reply-To: <1479468155.36.0.0223780421373.issue28732@psf.upfronthosting.co.za> Message-ID: <20161120031757.12405.37427.E814C8E6@psf.io> Roundup Robot added the comment: New changeset e076ace7b0ff by Steve Dower in branch '3.5': Issue #28732: Raise ValueError when argv[0] is empty. https://hg.python.org/cpython/rev/e076ace7b0ff New changeset af78b33704af by Steve Dower in branch '3.6': Issue #28732: Raise ValueError when argv[0] is empty https://hg.python.org/cpython/rev/af78b33704af New changeset fc6f757e53de by Steve Dower in branch 'default': Issue #28732: Raise ValueError when argv[0] is empty https://hg.python.org/cpython/rev/fc6f757e53de ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 22:19:41 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 20 Nov 2016 03:19:41 +0000 Subject: [issue28732] spawnl crash on windows7 In-Reply-To: <1479468155.36.0.0223780421373.issue28732@psf.upfronthosting.co.za> Message-ID: <1479611981.63.0.525173311678.issue28732@psf.upfronthosting.co.za> Steve Dower added the comment: > ValueError should also be raised when argv[0] is an empty string. Added that too. Python 3.5 is missing the tests for these functions completely, so I only added those to 3.6 and later. Also the original issue was already resolved in 3.6, but I tidied up a few other functions that were missing proper handling. ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 22:22:19 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 20 Nov 2016 03:22:19 +0000 Subject: [issue27998] Bytes paths now are supported in os.scandir() on Windows In-Reply-To: <1473236470.81.0.837469962495.issue27998@psf.upfronthosting.co.za> Message-ID: <1479612139.91.0.191514001721.issue27998@psf.upfronthosting.co.za> Steve Dower added the comment: Doc change looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 22:57:19 2016 From: report at bugs.python.org (Joshua Jay Herman) Date: Sun, 20 Nov 2016 03:57:19 +0000 Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> Message-ID: <1479614239.02.0.796215763291.issue24459@psf.upfronthosting.co.za> Joshua Jay Herman added the comment: Thanks for pointing out that wasn't in the latest patch this has been corrected. ---------- Added file: http://bugs.python.org/file45552/corrected.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 23:12:22 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Nov 2016 04:12:22 +0000 Subject: [issue28732] spawnl crash on windows7 In-Reply-To: <1479468155.36.0.0223780421373.issue28732@psf.upfronthosting.co.za> Message-ID: <20161120041219.45337.65277.4167D23C@psf.io> Roundup Robot added the comment: New changeset 2e1fb851dfb4 by Steve Dower in branch '3.6': Issue #28732: Adds new errors to spawnv emulation for platforms that only have fork and execv https://hg.python.org/cpython/rev/2e1fb851dfb4 New changeset ac6de11fbd50 by Steve Dower in branch 'default': Issue #28732: Adds new errors to spawnv emulation for platforms that only have fork and execv https://hg.python.org/cpython/rev/ac6de11fbd50 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 19 23:14:37 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 20 Nov 2016 04:14:37 +0000 Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za> Message-ID: <1479615277.32.0.820754211078.issue28747@psf.upfronthosting.co.za> Steve Dower added the comment: Few patch updates - better tests and some docs. ---------- Added file: http://bugs.python.org/file45553/28747_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 00:40:20 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 20 Nov 2016 05:40:20 +0000 Subject: [issue28732] spawnl crash on windows7 In-Reply-To: <1479468155.36.0.0223780421373.issue28732@psf.upfronthosting.co.za> Message-ID: <1479620420.21.0.0134327649596.issue28732@psf.upfronthosting.co.za> Steve Dower added the comment: Buildbots seem to be happy now so I'm closing the issue. Feel free to reopen if anyone spots anything in commit review. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 01:25:31 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Nov 2016 06:25:31 +0000 Subject: [issue27998] Bytes paths now are supported in os.scandir() on Windows In-Reply-To: <1473236470.81.0.837469962495.issue27998@psf.upfronthosting.co.za> Message-ID: <20161120062528.5752.48253.09FB70D4@psf.io> Roundup Robot added the comment: New changeset ac63c70635db by Serhiy Storchaka in branch '3.6': Issue #27998: Documented bytes paths support on Windows. https://hg.python.org/cpython/rev/ac63c70635db New changeset 26195e07fcc5 by Serhiy Storchaka in branch 'default': Issue #27998: Documented bytes paths support on Windows. https://hg.python.org/cpython/rev/26195e07fcc5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 01:26:46 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 06:26:46 +0000 Subject: [issue27998] Bytes paths now are supported in os.scandir() on Windows In-Reply-To: <1473236470.81.0.837469962495.issue27998@psf.upfronthosting.co.za> Message-ID: <1479623206.14.0.684915458605.issue27998@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Steve. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 01:35:46 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 06:35:46 +0000 Subject: [issue25996] Add support of file descriptor in os.scandir() In-Reply-To: <1451758238.49.0.729670752807.issue25996@psf.upfronthosting.co.za> Message-ID: <1479623746.96.0.369413639213.issue25996@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Resolved conflicts in the documentation. ---------- Added file: http://bugs.python.org/file45554/os-scandir-fd-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 01:47:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 06:47:32 +0000 Subject: [issue28715] Check result of PyUnicode_AsUTF8 In-Reply-To: <1479318387.76.0.271221021143.issue28715@psf.upfronthosting.co.za> Message-ID: <1479624452.09.0.313417017014.issue28715@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 01:48:49 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Nov 2016 06:48:49 +0000 Subject: [issue28715] Check result of PyUnicode_AsUTF8 In-Reply-To: <1479318387.76.0.271221021143.issue28715@psf.upfronthosting.co.za> Message-ID: <20161120064846.45102.73719.BE80E017@psf.io> Roundup Robot added the comment: New changeset 38f321a6be41 by Serhiy Storchaka in branch '3.5': Issue #28715: Added error checks for PyUnicode_AsUTF8(). https://hg.python.org/cpython/rev/38f321a6be41 New changeset 0bb8ab158042 by Serhiy Storchaka in branch '3.6': Issue #28715: Added error checks for PyUnicode_AsUTF8(). https://hg.python.org/cpython/rev/0bb8ab158042 New changeset 9cd42ed64bdb by Serhiy Storchaka in branch 'default': Issue #28715: Added error checks for PyUnicode_AsUTF8(). https://hg.python.org/cpython/rev/9cd42ed64bdb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 01:49:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 06:49:12 +0000 Subject: [issue28715] Check result of PyUnicode_AsUTF8 In-Reply-To: <1479318387.76.0.271221021143.issue28715@psf.upfronthosting.co.za> Message-ID: <1479624552.44.0.439844041794.issue28715@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 03:10:38 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 20 Nov 2016 08:10:38 +0000 Subject: [issue28740] Add sys.getandroidapilevel() In-Reply-To: Message-ID: <58315A7B.4010200@egenix.com> Marc-Andre Lemburg added the comment: On 20.11.2016 00:59, STINNER Victor wrote: > > STINNER Victor added the comment: > >> I think we must use the reliable build time Android API level and > implement sys.getandroidapilevel() (Victor patch) for knowing, in the > standard library, whether we are running on an Android platform, and > provide a best effort platform.android_ver() for the Android run time > version. Things are changing very fast with the Android project and the OEM > may add their own changes too. > > Hum, IMO we should at least use a structure with names for the sys function > to be able to return more information later. > > Maybe call the function sys.getandroidversion()? Since this is an OS level interface, it should either go into the os module or, if it doesn't rely on a C API, into the platform module (see e.g. the platform.win32_ver() and .mac_ver() APIs as example). I don't think the sys module is the right place to put the API, since it doesn't have anything to do with the Python system internals. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 03:14:23 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 20 Nov 2016 08:14:23 +0000 Subject: [issue20572] subprocess.Popen.wait() undocumented "endtime" parameter In-Reply-To: <1391941400.18.0.703922206544.issue20572@psf.upfronthosting.co.za> Message-ID: <1479629663.6.0.313016193555.issue20572@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks Martin :) Alright, in v2 patch, I added stacklevel=2 parameter and test case for it. Did not find any usage of the endtime parameter in cpython. I'm also thinking that it can be removed in 3.7, considering it's been documented as deprecated since 3.4. But maybe I'm not a good judge for this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 03:15:15 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 20 Nov 2016 08:15:15 +0000 Subject: [issue20572] subprocess.Popen.wait() undocumented "endtime" parameter In-Reply-To: <1391941400.18.0.703922206544.issue20572@psf.upfronthosting.co.za> Message-ID: <1479629715.15.0.153414158928.issue20572@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: lol forgot to upload the patch. Here it is :) ---------- Added file: http://bugs.python.org/file45555/issue20572v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 04:32:00 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 09:32:00 +0000 Subject: [issue28748] Make _Py_PackageContext of type "const char *" Message-ID: <1479634320.59.0.400146468836.issue28748@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Currently _Py_PackageContext has type "char *". But it is either NULL or a pointer to internal readonly UTF-8 representation of Unicode object. Adding the const qualifier makes it clear that the data is immutable. I don't think this change will break third-party code. ---------- components: Interpreter Core files: _Py_PackageContext-const.patch keywords: patch messages: 281256 nosy: brett.cannon, eric.snow, ncoghlan, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Make _Py_PackageContext of type "const char *" type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45556/_Py_PackageContext-const.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 04:34:03 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 09:34:03 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za> Message-ID: <1479634443.4.0.293037124472.issue19569@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 05:17:06 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Nov 2016 10:17:06 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za> Message-ID: <20161120101704.8083.54450.1B61A700@psf.io> Roundup Robot added the comment: New changeset 75fe67538905 by Serhiy Storchaka in branch '3.5': Issue #19569: Suggested more appropriate replacements for deprecated Unicode https://hg.python.org/cpython/rev/75fe67538905 New changeset f26d3f9a958a by Serhiy Storchaka in branch '3.6': Issue #19569: Suggested more appropriate replacements for deprecated Unicode https://hg.python.org/cpython/rev/f26d3f9a958a New changeset 2ae992bc2def by Serhiy Storchaka in branch 'default': Issue #19569: Suggested more appropriate replacements for deprecated Unicode https://hg.python.org/cpython/rev/2ae992bc2def New changeset f692dafe6797 by Serhiy Storchaka in branch 'default': Issue #19569: Compiler warnings are now emitted if use most of deprecated https://hg.python.org/cpython/rev/f692dafe6797 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 05:23:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 10:23:19 +0000 Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of deprecated functions and macros In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za> Message-ID: <1479637399.97.0.952159136989.issue19569@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Arfrever, could you please provide your proposition as a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 05:29:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 10:29:58 +0000 Subject: [issue28749] Fixed the documentation of the mapping codec APIs Message-ID: <1479637798.25.0.994184606714.issue28749@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch adds the documentation of PyUnicode_Translate() and fixes the documentation of other mapping codec APIs (it is incorrect in Python 3): PyUnicode_DecodeCharmap(), PyUnicode_AsCharmapString(), PyUnicode_EncodeCharmap(), and PyUnicode_TranslateCharmap(). ---------- assignee: docs at python components: Documentation, Unicode files: docs-PyUnicode_Translate.patch keywords: patch messages: 281259 nosy: docs at python, ezio.melotti, haypo, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Fixed the documentation of the mapping codec APIs type: behavior versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45557/docs-PyUnicode_Translate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 05:52:08 2016 From: report at bugs.python.org (Christian Heimes) Date: Sun, 20 Nov 2016 10:52:08 +0000 Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za> Message-ID: <1479639127.99.0.61288628058.issue28747@psf.upfronthosting.co.za> Christian Heimes added the comment: IMHO SSL CTX set cert verify callback() is the wrong approach. Your are completely bypassing cert validation checks of OpenSSL. The callback has to build the chain and perform all checks on its own. By all checks I literally mean *all*, https://wiki.openssl.org/index.php/Manual:SSL_CTX_set_cert_verify_callback(3)#WARNINGS Basically you want to replace OpenSSL's X509 verification with Windows' cert validation and just leave the handshake and encryption to OpenSSL? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 06:10:24 2016 From: report at bugs.python.org (Patrick Lehmann) Date: Sun, 20 Nov 2016 11:10:24 +0000 Subject: [issue28710] Sphinx incompatible markup in configparser.ConfigParser. In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za> Message-ID: <1479640224.11.0.804778128531.issue28710@psf.upfronthosting.co.za> Patrick Lehmann added the comment: I also found some docstrings using double back-tick plus double single quotes. For example: ``x.y = v'' in builtins.py in function setattr(...). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 07:24:18 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 12:24:18 +0000 Subject: [issue28710] Sphinx incompatible markup in configparser.ConfigParser. In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za> Message-ID: <1479644658.51.0.357008267593.issue28710@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 07:53:35 2016 From: report at bugs.python.org (Steve Dower) Date: Sun, 20 Nov 2016 12:53:35 +0000 Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za> Message-ID: <1479646415.92.0.639157575463.issue28747@psf.upfronthosting.co.za> Steve Dower added the comment: > Basically you want to replace OpenSSL's X509 verification with Windows' cert validation and just leave the handshake and encryption to OpenSSL? Yep. (See WinVerifyTrust for the Windows API I'm using.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 08:58:32 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 20 Nov 2016 13:58:32 +0000 Subject: [issue28750] Replace string with bytes in doc of unicode-escape an raw-unicode-escape Message-ID: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za> New submission from Xiang Zhang: The docs of the encoders of unicode-escape and raw-unicode-escape still tell the result of the encoding is Python string object. It should be Python bytes object. ---------- assignee: docs at python components: Documentation files: unicode-escape-doc.patch keywords: patch messages: 281263 nosy: docs at python, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Replace string with bytes in doc of unicode-escape an raw-unicode-escape versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45558/unicode-escape-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 09:03:20 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sun, 20 Nov 2016 14:03:20 +0000 Subject: [issue28750] Replace string with bytes in doc of unicode-escape an raw-unicode-escape In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za> Message-ID: <1479650600.41.0.933714846801.issue28750@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 09:16:55 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 20 Nov 2016 14:16:55 +0000 Subject: [issue10049] Add a "no-op" (null) context manager to contextlib (Rejected: use contextlib.ExitStack()) In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za> Message-ID: <1479651415.1.0.341710323461.issue10049@psf.upfronthosting.co.za> Nick Coghlan added the comment: Unfortunately, the redundancy doesn't buy enough to justify the permanent documentation and style guide cost of providing two ways to do exactly the same thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 09:20:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Nov 2016 14:20:56 +0000 Subject: [issue28666] Make test.support.rmtree() able to remove non-writable directories In-Reply-To: <1478866355.91.0.707083472132.issue28666@psf.upfronthosting.co.za> Message-ID: <20161120142053.7475.43824.3980DDE2@psf.io> Roundup Robot added the comment: New changeset 63820871014d by Serhiy Storchaka in branch '2.7': Issue #28666: Now test.support.rmtree is able to remove unwritable or https://hg.python.org/cpython/rev/63820871014d New changeset c92f9be77b9b by Serhiy Storchaka in branch '3.5': Issue #28666: Now test.support.rmtree is able to remove unwritable or https://hg.python.org/cpython/rev/c92f9be77b9b New changeset efe2993b20e2 by Serhiy Storchaka in branch '3.6': Issue #28666: Now test.support.rmtree is able to remove unwritable or https://hg.python.org/cpython/rev/efe2993b20e2 New changeset 3a1e75ecc17d by Serhiy Storchaka in branch 'default': Issue #28666: Now test.support.rmtree is able to remove unwritable or https://hg.python.org/cpython/rev/3a1e75ecc17d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 09:21:12 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 20 Nov 2016 14:21:12 +0000 Subject: [issue28748] Make _Py_PackageContext of type "const char *" In-Reply-To: <1479634320.59.0.400146468836.issue28748@psf.upfronthosting.co.za> Message-ID: <1479651672.66.0.22851171249.issue28748@psf.upfronthosting.co.za> Nick Coghlan added the comment: It technically could (if they're passing it to a function that takes a "char *"), but if they are and they can't change the affected function to take "const char *" instead, then that's an actual bug in the way they're using it. So +1 from me for explicitly declaring the immutability in 3.7+ - it will need a note in the What's New porting guide though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 09:21:35 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 20 Nov 2016 14:21:35 +0000 Subject: [issue28750] Replace string with bytes in doc of unicode-escape an raw-unicode-escape In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za> Message-ID: <1479651695.16.0.0550768958796.issue28750@psf.upfronthosting.co.za> Changes by Xiang Zhang : Added file: http://bugs.python.org/file45559/unicode-escape-doc_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 09:21:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 14:21:54 +0000 Subject: [issue28666] Make test.support.rmtree() able to remove non-writable directories In-Reply-To: <1478866355.91.0.707083472132.issue28666@psf.upfronthosting.co.za> Message-ID: <1479651714.55.0.744131226093.issue28666@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Kushal. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 09:23:13 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sun, 20 Nov 2016 14:23:13 +0000 Subject: [issue28750] Replace string with bytes in doc of unicode-escape an raw-unicode-escape In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za> Message-ID: <1479651793.52.0.697142662193.issue28750@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 09:29:55 2016 From: report at bugs.python.org (Ned Batchelder) Date: Sun, 20 Nov 2016 14:29:55 +0000 Subject: [issue28751] Fix comments in code.h Message-ID: <1479652195.59.0.115870067836.issue28751@psf.upfronthosting.co.za> New submission from Ned Batchelder: A field moved in PyCodeObject, but comments mentioning it were not updated. Also, there's a stray word? ---------- messages: 281268 nosy: brett.cannon, nedbat priority: normal severity: normal status: open title: Fix comments in code.h versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 09:30:54 2016 From: report at bugs.python.org (Ned Batchelder) Date: Sun, 20 Nov 2016 14:30:54 +0000 Subject: [issue28751] Fix comments in code.h In-Reply-To: <1479652195.59.0.115870067836.issue28751@psf.upfronthosting.co.za> Message-ID: <1479652254.65.0.703459808676.issue28751@psf.upfronthosting.co.za> Changes by Ned Batchelder : ---------- keywords: +patch Added file: http://bugs.python.org/file45560/28751.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 09:34:19 2016 From: report at bugs.python.org (Emanuel Barry) Date: Sun, 20 Nov 2016 14:34:19 +0000 Subject: [issue28751] Fix comments in code.h In-Reply-To: <1479652195.59.0.115870067836.issue28751@psf.upfronthosting.co.za> Message-ID: <1479652459.62.0.477140153776.issue28751@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 09:43:14 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 14:43:14 +0000 Subject: [issue28750] Replace string with bytes in doc of unicode-escape an raw-unicode-escape In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za> Message-ID: <1479652994.89.0.898474617487.issue28750@psf.upfronthosting.co.za> Julien Palard added the comment: The inconcistencies were introduced in hg changeset 41703:7993f23ad46c, git commit: commit 40ec96630b96f077c8b5746ab0ec038f95aede8b Author: Walter D?rwald Date: Sat May 12 11:08:06 2007 +0000 Change PyUnicode_EncodeUnicodeEscape() to return a bytes object. However PyUnicode_AsUnicodeEscapeString() (which is used by Objects/fileobject.c::file_repr()) still returns a str8 object. Give unicode_repr() it's own implementation which returns a str8 object (it was formerly just calling unicodeescape_string() which was used to implement PyUnicode_EncodeUnicodeEscape() too), because once repr() is required to return unicode objects it needs its own implementation anyway. (PyUnicode_EncodeUnicodeEscape was the old name for PyUnicode_AsUnicodeEscapeString (since 06ade3ac0d12beacd84382bd5fc8baf1c21c0e74).) I searched in the documentation for "python string" and it looks like PyUnicode_EncodeCharmap is documented to return a string, but it returns bytes (same issue), therefore, the same issue happen for PyUnicode_AsCharmapString which uses PyUnicode_EncodeCharmap. ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 09:45:25 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 14:45:25 +0000 Subject: [issue28750] Replace string with bytes in doc of unicode-escape an raw-unicode-escape In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za> Message-ID: <1479653125.74.0.507927936424.issue28750@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Good catch Xiang! But I think the word "Python" in "Python bytes object" is redundant. It was needed in "Python string object" to distinguish from "C string" and "Python Unicode object". ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 09:46:30 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 14:46:30 +0000 Subject: [issue28750] Replace string with bytes in doc of unicode-escape an raw-unicode-escape In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za> Message-ID: <1479653190.13.0.284460192557.issue28750@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For PyUnicode_AsCharmapString and PyUnicode_EncodeCharmap see issue28749. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 09:48:41 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 14:48:41 +0000 Subject: [issue28667] FD_SETSIZE is unsigned on FreeBSD In-Reply-To: <1478872990.6.0.256289601446.issue28667@psf.upfronthosting.co.za> Message-ID: <1479653321.87.0.220313819073.issue28667@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 10:03:24 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 20 Nov 2016 15:03:24 +0000 Subject: [issue28750] Replace string with bytes in doc of unicode-escape an raw-unicode-escape In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za> Message-ID: <1479654204.08.0.124981719177.issue28750@psf.upfronthosting.co.za> Xiang Zhang added the comment: > But I think the word "Python" in "Python bytes object" is redundant. It was needed in "Python string object" to distinguish from "C string" and "Python Unicode object". Make sense. This "Python" actually appears in many places in the docs. I only change the related parts of this issue. ---------- Added file: http://bugs.python.org/file45561/unicode-escape-doc_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 10:05:44 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 15:05:44 +0000 Subject: [issue28750] Replace string with bytes in doc of unicode-escape an raw-unicode-escape In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za> Message-ID: <1479654344.28.0.126339084929.issue28750@psf.upfronthosting.co.za> Julien Palard added the comment: So, lgtm. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 10:12:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 15:12:54 +0000 Subject: [issue28655] Tests altered the execution environment in isolated mode In-Reply-To: <1478767618.32.0.527967950395.issue28655@psf.upfronthosting.co.za> Message-ID: <1479654774.37.0.91353335155.issue28655@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Most warnings are fixed in issue19398. The only warnings are left in test_import and test_lib2to3. $ ./python -I -S -m test.regrtest -vv test_import test_lib2to3 >/dev/null Warning -- files was modified by test_import Before: [] After: ['@test_15631_tmp.pyc'] /home/serhiy/py/cpython3.6/Lib/lib2to3/tests/test_parser.py:393: UserWarning: ParseError on file /home/serhiy/py/cpython3.6/Lib/lib2to3/main.py (bad input: type=22, value='=', context=('', (130, 38))) warnings.warn('ParseError on file %s (%s)' % (filepath, err)) /home/serhiy/py/cpython3.6/Lib/lib2to3/tests/test_parser.py:393: UserWarning: ParseError on file /home/serhiy/py/cpython3.6/Lib/lib2to3/tests/pytree_idempotency.py (bad input: type=22, value='=', context=('', (49, 33))) warnings.warn('ParseError on file %s (%s)' % (filepath, err)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 10:14:26 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 15:14:26 +0000 Subject: [issue28750] Replace string with bytes in doc of unicode-escape an raw-unicode-escape In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za> Message-ID: <1479654866.71.0.315184840739.issue28750@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- assignee: docs at python -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 10:22:02 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Nov 2016 15:22:02 +0000 Subject: [issue28750] Replace string with bytes in doc of unicode-escape an raw-unicode-escape In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za> Message-ID: <20161120152153.10070.42716.EDCEC1AC@psf.io> Roundup Robot added the comment: New changeset 059b8e15b738 by Serhiy Storchaka in branch '3.5': Issue #28750: Fixed docs of of unicode-escape an raw-unicode-escape C API. https://hg.python.org/cpython/rev/059b8e15b738 New changeset 0c6fccf04a79 by Serhiy Storchaka in branch '3.6': Issue #28750: Fixed docs of of unicode-escape an raw-unicode-escape C API. https://hg.python.org/cpython/rev/0c6fccf04a79 New changeset deff7bf26d00 by Serhiy Storchaka in branch 'default': Issue #28750: Fixed docs of of unicode-escape an raw-unicode-escape C API. https://hg.python.org/cpython/rev/deff7bf26d00 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 10:22:29 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 15:22:29 +0000 Subject: [issue28750] Replace string with bytes in doc of unicode-escape an raw-unicode-escape In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za> Message-ID: <1479655349.41.0.848255427627.issue28750@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 10:43:26 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Nov 2016 15:43:26 +0000 Subject: [issue28666] Make test.support.rmtree() able to remove non-writable directories In-Reply-To: <1478866355.91.0.707083472132.issue28666@psf.upfronthosting.co.za> Message-ID: <20161120154323.7241.60498.711169EF@psf.io> Roundup Robot added the comment: New changeset b51607ea54c5 by Serhiy Storchaka in branch '2.7': Issue #28666: Now test.test_support.rmtree is able to remove unwritable or https://hg.python.org/cpython/rev/b51607ea54c5 New changeset 9e23b8996584 by Serhiy Storchaka in branch '3.5': Issue #28666: Now test.support.rmtree is able to remove unwritable or https://hg.python.org/cpython/rev/9e23b8996584 New changeset 82ca763882f5 by Serhiy Storchaka in branch '3.6': Issue #28666: Now test.support.rmtree is able to remove unwritable or https://hg.python.org/cpython/rev/82ca763882f5 New changeset 593ec9658f4b by Serhiy Storchaka in branch 'default': Issue #28666: Now test.support.rmtree is able to remove unwritable or https://hg.python.org/cpython/rev/593ec9658f4b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 10:55:23 2016 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 20 Nov 2016 15:55:23 +0000 Subject: [issue28752] datetime object fails to restore from reduction Message-ID: <1479657323.42.0.875075153657.issue28752@psf.upfronthosting.co.za> New submission from Jason R. Coombs: On Python 3.5, the datetime would reduce and restore cleanly. $ python3.5 -c "import datetime; func, params = datetime.datetime.now().__reduce__(); func(*params)" With Python 3.6.0b3, it now fails with a TypeError. $ python3.6 -c "import datetime; func, params = datetime.datetime.now().__reduce__(); func(*params)" Traceback (most recent call last): File "", line 1, in TypeError: an integer is required (got type bytes) ---------- messages: 281278 nosy: jason.coombs priority: normal severity: normal status: open title: datetime object fails to restore from reduction versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 10:57:38 2016 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 20 Nov 2016 15:57:38 +0000 Subject: [issue28752] datetime object fails to restore from reduction In-Reply-To: <1479657323.42.0.875075153657.issue28752@psf.upfronthosting.co.za> Message-ID: <1479657458.82.0.602591493222.issue28752@psf.upfronthosting.co.za> Jason R. Coombs added the comment: Pickle still works, so pickle must be relying on a different protocol for serialization. $ python Python 3.6.0b3 (v3.6.0b3:8345e066c0ed, Oct 31 2016, 18:05:23) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import pickle >>> import datetime >>> pickle.loads(pickle.dumps(datetime.datetime.now())) datetime.datetime(2016, 11, 20, 10, 56, 43, 264436) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 11:10:56 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 16:10:56 +0000 Subject: [issue28752] datetime object fails to restore from reduction In-Reply-To: <1479657323.42.0.875075153657.issue28752@psf.upfronthosting.co.za> Message-ID: <1479658256.59.0.821335963019.issue28752@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Now pickling of the datetime.datetime objects is implemented with __reduce_ex__. __reduce__ is not defined in datetime.datetime and is inherited from datetime.date. >>> datetime.datetime.__reduce_ex__ >>> datetime.datetime.__reduce__ __reduce_ex__ has higher priority and is called instead of __reduce__. It is weird that __reduce_ex__ and __reduce__ are not consistent. __reduce__ should be defined as def __reduce__(self): return self.__reduce_ex__(2) or just __reduce__ = object.__reduce__ Other way is to define __reduce_ex__ instead of __reduce__ in datetime.date. ---------- components: +Extension Modules nosy: +belopolsky, serhiy.storchaka type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 11:44:04 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 16:44:04 +0000 Subject: [issue28753] Clinic: Converting Your First Function is not up to date Message-ID: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za> New submission from Julien Palard: It looks like the "Converting Your First Function" has been written with clinic-generated C code interspersed with user C code. But it looks like nowadays a `clinic/{}.c.h` file is generated, so the "Converting Your First Function" should tell us to add the `#include "clinic/?`. Also, the documentation states: > If any of these items differ in any way, adjust your Argument > Clinic function specification and rerun Tools/clinic/clinic.py > until they are the same. But since `METH_FASTCALL` it may be wrong (Clinic generated `METH_FASTCALL` but it was `METH_VARARGS|METH_KEYWORDS`). ---------- messages: 281281 nosy: mdk priority: normal severity: normal status: open title: Clinic: Converting Your First Function is not up to date _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 11:44:38 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 16:44:38 +0000 Subject: [issue28753] Clinic: Converting Your First Function is not up to date In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za> Message-ID: <1479660278.14.0.566761972483.issue28753@psf.upfronthosting.co.za> Changes by Julien Palard : ---------- components: +Argument Clinic nosy: +larry versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 11:44:45 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 16:44:45 +0000 Subject: [issue28753] Clinic: Converting Your First Function is not up to date In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za> Message-ID: <1479660285.57.0.600177431964.issue28753@psf.upfronthosting.co.za> Changes by Julien Palard : ---------- versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 11:46:29 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 16:46:29 +0000 Subject: [issue28753] Clinic: Converting Your First Function is not up to date In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za> Message-ID: <1479660389.26.0.830824287058.issue28753@psf.upfronthosting.co.za> Changes by Julien Palard : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 11:51:59 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 16:51:59 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left Message-ID: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> New submission from Julien Palard: Today I read https://docs.python.org/3.6/howto/clinic.html so I tried one: bisect.bisect_left. I was unable to do `bisect_right`, as it's an "alias" for `bisect`, and there's a unit-test checking `self.assertEqual(self.module.bisect, self.module.bisect_right)`. Any hint welcome. ---------- components: Argument Clinic messages: 281282 nosy: larry, mdk priority: normal severity: normal status: open title: Argument Clinic for bisect.bisect_left _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 11:52:24 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 16:52:24 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1479660744.25.0.870475900263.issue28754@psf.upfronthosting.co.za> Changes by Julien Palard : ---------- keywords: +patch Added file: http://bugs.python.org/file45562/issue28754.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 11:56:01 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 16:56:01 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1479660961.03.0.537390796668.issue28754@psf.upfronthosting.co.za> Changes by Julien Palard : Added file: http://bugs.python.org/file45563/issue28754-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 12:08:08 2016 From: report at bugs.python.org (Larry Hastings) Date: Sun, 20 Nov 2016 17:08:08 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1479661688.31.0.162179880656.issue28754@psf.upfronthosting.co.za> Larry Hastings added the comment: There's special syntax to handle aliases. From comments in clinic.py: # alternatively: # modulename.fnname [as c_basename] = modulename.existing_fn_name # clones the parameters and return converter from that # function. you can't modify them. you must enter a # new docstring. Sorry the docs are out of date--patches welcome. And speaking of patches, thanks for the patch! I'll review it when you say it's ready. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 12:09:22 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 17:09:22 +0000 Subject: [issue28752] datetime object fails to restore from reduction In-Reply-To: <1479657323.42.0.875075153657.issue28752@psf.upfronthosting.co.za> Message-ID: <1479661762.29.0.297281014309.issue28752@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch restores the __reduce__() methods and makes Python and C implementations more consistent. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file45564/datetime-reduce.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 12:09:41 2016 From: report at bugs.python.org (Larry Hastings) Date: Sun, 20 Nov 2016 17:09:41 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1479661781.35.0.106820430738.issue28754@psf.upfronthosting.co.za> Larry Hastings added the comment: Oh, and, if the code literally asserts they're the same function, that's just a sanity check based on the implementation. You could preserve that if you care to, or you could just write a new function and remove the assertion. Do what you think is best, then post your patch to the tracker and we'll all argue about it forever, how's that sound? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 12:11:51 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 17:11:51 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1479661911.62.0.405329476381.issue28754@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +rhettinger versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 12:12:27 2016 From: report at bugs.python.org (Larry Hastings) Date: Sun, 20 Nov 2016 17:12:27 +0000 Subject: [issue28753] Clinic: Converting Your First Function is not up to date In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za> Message-ID: <1479661947.79.0.779177578346.issue28753@psf.upfronthosting.co.za> Larry Hastings added the comment: The bit about the "clinic/_" include is a good point. Care to write a doc patch? The bit about FASTCALL I don't know anything about because I haven't worked with FASTCALL. I've added Victor Stinner, the author of the FASTCALL patch, maybe he can address your concerns about FASTCALL. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 12:19:31 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 20 Nov 2016 17:19:31 +0000 Subject: [issue28752] datetime object fails to restore from reduction In-Reply-To: <1479658256.59.0.821335963019.issue28752@psf.upfronthosting.co.za> Message-ID: <067DA331-D26D-4C52-A6EE-6D69B5FE37E4@gmail.com> Alexander Belopolsky added the comment: > On Nov 20, 2016, at 11:10 AM, Serhiy Storchaka wrote: > > Other way is to define __reduce_ex__ instead of __reduce__ in datetime.date. I would prefer this solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 12:34:51 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 17:34:51 +0000 Subject: [issue28752] datetime object fails to restore from reduction In-Reply-To: <1479657323.42.0.875075153657.issue28752@psf.upfronthosting.co.za> Message-ID: <1479663291.26.0.164398662695.issue28752@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Other way is to define __reduce_ex__ instead of __reduce__ in datetime.date. Sorry, I was wrong. This would wouldn't work with C implementation. And explicitly setting __reduce__ = object.__reduce__ doesn't work. The only way is to define both __reduce_ex__ and __reduce__ for time and datewtime. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 13:05:21 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Nov 2016 18:05:21 +0000 Subject: [issue28666] Make test.support.rmtree() able to remove non-writable directories In-Reply-To: <1478866355.91.0.707083472132.issue28666@psf.upfronthosting.co.za> Message-ID: <20161120180518.45206.54443.20A3B07C@psf.io> Roundup Robot added the comment: New changeset da1880183693 by Serhiy Storchaka in branch 'default': Issue #28666: Try to fix removing readonly directories on Windows. https://hg.python.org/cpython/rev/da1880183693 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 13:14:48 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 18:14:48 +0000 Subject: [issue28753] Clinic: Converting Your First Function is not up to date In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za> Message-ID: <1479665688.52.0.367603784986.issue28753@psf.upfronthosting.co.za> Julien Palard added the comment: @Larry: As a french-speaking guy, I typically don't write non-internal doc in english, fearing it sound weird for natives. I prefer translating it back in french (I'm the current leader of https://github.com/afpy/python_doc_fr) Here, here is a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file45565/issue28753.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 13:38:06 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Nov 2016 18:38:06 +0000 Subject: [issue28666] Make test.support.rmtree() able to remove non-writable directories In-Reply-To: <1478866355.91.0.707083472132.issue28666@psf.upfronthosting.co.za> Message-ID: <20161120183803.45337.79421.60086D04@psf.io> Roundup Robot added the comment: New changeset 573fd9607c75 by Serhiy Storchaka in branch '3.5': Issue #28666: Fix removing readonly directories on Windows. https://hg.python.org/cpython/rev/573fd9607c75 New changeset 01f867e9cd34 by Serhiy Storchaka in branch '2.7': Issue #28666: Fix removing readonly directories on Windows. https://hg.python.org/cpython/rev/01f867e9cd34 New changeset b9e1a51a2d19 by Serhiy Storchaka in branch '3.6': Issue #28666: Fix removing readonly directories on Windows. https://hg.python.org/cpython/rev/b9e1a51a2d19 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 13:46:45 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 20 Nov 2016 18:46:45 +0000 Subject: [issue28752] datetime object fails to restore from reduction In-Reply-To: <1479663291.26.0.164398662695.issue28752@psf.upfronthosting.co.za> Message-ID: <2C9EC1D3-BAE9-47F2-8EA1-8D5462590706@gmail.com> Alexander Belopolsky added the comment: > On Nov 20, 2016, at 12:34 PM, Serhiy Storchaka wrote: > > The only way is to define both __reduce_ex__ and __reduce__ for time and datewtime. OK. I'll review your patch and get it committed shortly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 13:48:50 2016 From: report at bugs.python.org (Larry Hastings) Date: Sun, 20 Nov 2016 18:48:50 +0000 Subject: [issue28753] Clinic: Converting Your First Function is not up to date In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za> Message-ID: <1479667730.78.0.109852837718.issue28753@psf.upfronthosting.co.za> Larry Hastings added the comment: I understand your concern as a non-English speaker, but your patch was really pretty good. I did edit it a little; how's this? ---------- Added file: http://bugs.python.org/file45566/larry.issue28753.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 14:28:19 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 19:28:19 +0000 Subject: [issue28753] Clinic: Converting Your First Function is not up to date In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za> Message-ID: <1479670099.94.0.0205781031553.issue28753@psf.upfronthosting.co.za> Julien Palard added the comment: Thanks for proof-reading my english, your editions are really nice: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 14:33:32 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Nov 2016 19:33:32 +0000 Subject: [issue28753] Clinic: Converting Your First Function is not up to date In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za> Message-ID: <20161120193329.10307.7670.E28F97F3@psf.io> Roundup Robot added the comment: New changeset 0a18d2cfeb52 by Larry Hastings in branch 'default': Issue 28753: Argument Clinic howto docfix, courtesy Julien Palard. https://hg.python.org/cpython/rev/0a18d2cfeb52 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 14:33:49 2016 From: report at bugs.python.org (Larry Hastings) Date: Sun, 20 Nov 2016 19:33:49 +0000 Subject: [issue28753] Clinic: Converting Your First Function is not up to date In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za> Message-ID: <1479670429.09.0.820684664971.issue28753@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 14:35:11 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 19:35:11 +0000 Subject: [issue28753] Clinic: Converting Your First Function is not up to date In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za> Message-ID: <1479670511.95.0.309900024815.issue28753@psf.upfronthosting.co.za> Julien Palard added the comment: Should we keep this open for the FASTCALL bit? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 14:35:57 2016 From: report at bugs.python.org (Larry Hastings) Date: Sun, 20 Nov 2016 19:35:57 +0000 Subject: [issue28753] Clinic: Converting Your First Function is not up to date In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za> Message-ID: <1479670557.56.0.252599758816.issue28753@psf.upfronthosting.co.za> Larry Hastings added the comment: Let's see what Victor has to say. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 14:37:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 19:37:37 +0000 Subject: [issue28666] Make test.support.rmtree() able to remove non-writable directories In-Reply-To: <1478866355.91.0.707083472132.issue28666@psf.upfronthosting.co.za> Message-ID: <1479670657.52.0.771435256727.issue28666@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 14:54:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 19:54:37 +0000 Subject: [issue28748] Make _Py_PackageContext of type "const char *" In-Reply-To: <1479634320.59.0.400146468836.issue28748@psf.upfronthosting.co.za> Message-ID: <1479671677.97.0.830395193875.issue28748@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added a What's New note. On GitHub I found only three projects (besides clones of CPython sources) that use _Py_PackageContext. They are not affected by this change. ---------- Added file: http://bugs.python.org/file45567/_Py_PackageContext-const-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 15:12:56 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 20:12:56 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1479672776.7.0.136227196021.issue28754@psf.upfronthosting.co.za> Julien Palard added the comment: I searched an occurrence of what I'm describing which is already using clinic and there is, at least, one in Modules/binascii.c line 1090: TL;DR: The idea is to use the `modulename.fnname [as c_basename] = modulename.existing_fn_name` clinic syntax, drop a "This function is also available as ?" in the docstring, and check if they return the same thing in the tests. This way looks good to me, it uses the dedicated syntax which looks right, and I'll drop the `self.assertEqual(self.module.bisect, self.module.bisect_right)` which is an implementation detail, replacing it by tests checking that both have the same behavior. ``` /*[clinic input] binascii.b2a_hex data: Py_buffer / Hexadecimal representation of binary data. The return value is a bytes object. This function is also available as "hexlify()". [clinic start generated code]*/ static PyObject * binascii_b2a_hex_impl(PyObject *module, Py_buffer *data) /*[clinic end generated code: output=92fec1a95c9897a0 input=96423cfa299ff3b1]*/ { return _Py_strhex_bytes((const char *)data->buf, data->len); } /*[clinic input] binascii.hexlify = binascii.b2a_hex Hexadecimal representation of binary data. The return value is a bytes object. [clinic start generated code]*/ static PyObject * binascii_hexlify_impl(PyObject *module, Py_buffer *data) /*[clinic end generated code: output=749e95e53c14880c input=2e3afae7f083f061]*/ { return _Py_strhex_bytes((const char *)data->buf, data->len); } ``` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 16:23:51 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 20 Nov 2016 21:23:51 +0000 Subject: [issue28032] --with-lto builds segfault in many situations In-Reply-To: <1473370352.47.0.536997029042.issue28032@psf.upfronthosting.co.za> Message-ID: <1479677031.33.0.250764683473.issue28032@psf.upfronthosting.co.za> Gregory P. Smith added the comment: The configure flag has been renamed to --enable-optimizations in the following commits for 3,5, 3.6, default, & 2.7 branches (everywhere it exists): remote: notified python-checkins at python.org of incoming changeset c0ea81315fb6 remote: notified python-checkins at python.org of incoming changeset 58c1a49a10b4 remote: notified python-checkins at python.org of incoming changeset 11cacf9f9a33 remote: notified python-checkins at python.org of incoming changeset 0d2b42344ae5 remote: notified python-checkins at python.org of incoming changeset 2d1d70b53376 remote: notified python-checkins at python.org of incoming changeset d5ff5a2f33fd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 16:27:49 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 20 Nov 2016 21:27:49 +0000 Subject: [issue26359] CPython build options for out-of-the box performance In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za> Message-ID: <1479677269.24.0.23682516994.issue26359@psf.upfronthosting.co.za> Gregory P. Smith added the comment: per comments in issue28032 the new configure flag has been renamed from --with-optimizations to --enable-optimizations in all branches it was added to: remote: notified python-checkins at python.org of incoming changeset c0ea81315fb6 remote: notified python-checkins at python.org of incoming changeset 58c1a49a10b4 remote: notified python-checkins at python.org of incoming changeset 11cacf9f9a33 remote: notified python-checkins at python.org of incoming changeset 0d2b42344ae5 remote: notified python-checkins at python.org of incoming changeset 2d1d70b53376 remote: notified python-checkins at python.org of incoming changeset d5ff5a2f33fd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 16:30:08 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 21:30:08 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1479677408.66.0.77154770936.issue28754@psf.upfronthosting.co.za> Julien Palard added the comment: Here it is for the whole bisect module. I separated my work in commits, but I'm not sure how rietveld will eat that as they'll have unknown references, so I'll probably also upload a single patch with a known reference. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 16:30:19 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 21:30:19 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1479677419.1.0.212220422496.issue28754@psf.upfronthosting.co.za> Changes by Julien Palard : Added file: http://bugs.python.org/file45568/bisect_left.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 16:30:33 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 21:30:33 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1479677433.05.0.0546552316728.issue28754@psf.upfronthosting.co.za> Changes by Julien Palard : Added file: http://bugs.python.org/file45569/bisect.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 16:30:42 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 21:30:42 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1479677442.89.0.79403219703.issue28754@psf.upfronthosting.co.za> Changes by Julien Palard : Added file: http://bugs.python.org/file45570/insort.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 16:30:57 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 21:30:57 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1479677457.64.0.480499420421.issue28754@psf.upfronthosting.co.za> Changes by Julien Palard : Added file: http://bugs.python.org/file45571/insort-left.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 16:33:31 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 21:33:31 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1479677611.29.0.99768344645.issue28754@psf.upfronthosting.co.za> Changes by Julien Palard : Added file: http://bugs.python.org/file45572/issue28754-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 16:34:30 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 21:34:30 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1479677670.85.0.238689275485.issue28754@psf.upfronthosting.co.za> Julien Palard added the comment: The whole diff is reviewable in `issue28754-3.diff`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 17:01:57 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 22:01:57 +0000 Subject: [issue28755] Rework syntax highlighing in howto/clinic.rst Message-ID: <1479679317.44.0.842687607942.issue28755@psf.upfronthosting.co.za> New submission from Julien Palard: I was reading `howto/clinic.html` and though I'll fix syntax highlighting. ---------- assignee: docs at python components: Argument Clinic, Documentation messages: 281304 nosy: docs at python, larry, mdk priority: normal severity: normal status: open title: Rework syntax highlighing in howto/clinic.rst versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 17:02:16 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 22:02:16 +0000 Subject: [issue28755] Rework syntax highlighing in howto/clinic.rst In-Reply-To: <1479679317.44.0.842687607942.issue28755@psf.upfronthosting.co.za> Message-ID: <1479679336.89.0.43694089397.issue28755@psf.upfronthosting.co.za> Changes by Julien Palard : ---------- keywords: +patch Added file: http://bugs.python.org/file45573/issue28755.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 17:04:29 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 22:04:29 +0000 Subject: [issue28512] PyErr_SyntaxLocationEx() and PyErr_SyntaxLocationObject() always set the offset attribute to None In-Reply-To: <1477173007.35.0.842183977255.issue28512@psf.upfronthosting.co.za> Message-ID: <1479679469.22.0.556538592678.issue28512@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that makes PyErr_SyntaxLocationObject() setting correct offset. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file45574/PyErr_SyntaxLocationObject-offset.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 17:15:53 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Nov 2016 22:15:53 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479680153.15.0.760480043451.issue28727@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This looks too complicated. groups, indexgroup and groupindex are unambiguously derived from pattern string. If caching works different pattern strings are compiled to different pattern objects. Currently they are not equal, even if their codes are equal. And I don't see large need to consider them equal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 17:40:25 2016 From: report at bugs.python.org (Julien Palard) Date: Sun, 20 Nov 2016 22:40:25 +0000 Subject: [issue28755] Rework syntax highlighing in howto/clinic.rst In-Reply-To: <1479679317.44.0.842687607942.issue28755@psf.upfronthosting.co.za> Message-ID: <1479681625.68.0.35550408679.issue28755@psf.upfronthosting.co.za> Changes by Julien Palard : Added file: http://bugs.python.org/file45575/issue28755-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 18:24:12 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Nov 2016 23:24:12 +0000 Subject: [issue28666] Make test.support.rmtree() able to remove non-writable directories In-Reply-To: <1478866355.91.0.707083472132.issue28666@psf.upfronthosting.co.za> Message-ID: <20161120232409.14226.1692.A9E41B81@psf.io> Roundup Robot added the comment: New changeset dd378356c77c by Martin Panter in branch '2.7': Issue #28666: Fix stat import https://hg.python.org/cpython/rev/dd378356c77c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 18:24:12 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Nov 2016 23:24:12 +0000 Subject: [issue10656] "Out of tree" build fails on AIX In-Reply-To: <1291865704.62.0.494509897126.issue10656@psf.upfronthosting.co.za> Message-ID: <20161120232409.14226.25342.081683BC@psf.io> Roundup Robot added the comment: New changeset 48526666321a by Martin Panter in branch '3.5': Issue #10656: Fix out-of-tree building on AIX https://hg.python.org/cpython/rev/48526666321a New changeset 76d1f8001e27 by Martin Panter in branch '3.6': Issue #10656: Merge AIX build fix from 3.5 https://hg.python.org/cpython/rev/76d1f8001e27 New changeset 180f046b597e by Martin Panter in branch 'default': Issue #10656: Merge AIX build fix from 3.6 https://hg.python.org/cpython/rev/180f046b597e New changeset ca46883fc5cf by Martin Panter in branch '2.7': Issue #10656: Fix out-of-tree building on AIX https://hg.python.org/cpython/rev/ca46883fc5cf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 18:24:13 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Nov 2016 23:24:13 +0000 Subject: [issue25659] ctypes.Array.from_buffer segmentation fault when trying to create from array.array In-Reply-To: <1447869436.37.0.609997226839.issue25659@psf.upfronthosting.co.za> Message-ID: <20161120232409.14226.32250.48277410@psf.io> Roundup Robot added the comment: New changeset 5f061870d49c by Martin Panter in branch '3.5': Issue #25659: Change assert to TypeError in from_buffer/_copy() https://hg.python.org/cpython/rev/5f061870d49c New changeset 1253ef20c947 by Martin Panter in branch '3.6': Issue #25659: Merge ctypes fix from 3.5 https://hg.python.org/cpython/rev/1253ef20c947 New changeset 821da4891051 by Martin Panter in branch 'default': Issue #25659: Merge ctypes fix from 3.6 https://hg.python.org/cpython/rev/821da4891051 New changeset 4de956751cf1 by Martin Panter in branch '2.7': Issue #25659: Change assert to TypeError in from_buffer/_copy() https://hg.python.org/cpython/rev/4de956751cf1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 19:31:19 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 00:31:19 +0000 Subject: [issue20572] subprocess.Popen.wait() undocumented "endtime" parameter In-Reply-To: <1391941400.18.0.703922206544.issue20572@psf.upfronthosting.co.za> Message-ID: <20161121003116.41201.48064.E95E7DE3@psf.io> Roundup Robot added the comment: New changeset 0e8aa537c565 by Gregory P. Smith in branch '3.6': Issue #20572: The subprocess.Popen.wait method's undocumented endtime https://hg.python.org/cpython/rev/0e8aa537c565 New changeset f02422c6110a by Gregory P. Smith in branch 'default': Issue #20572: Remove the subprocess.Popen.wait endtime parameter. https://hg.python.org/cpython/rev/f02422c6110a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 19:32:44 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 21 Nov 2016 00:32:44 +0000 Subject: [issue20572] subprocess.Popen.wait() undocumented "endtime" parameter In-Reply-To: <1391941400.18.0.703922206544.issue20572@psf.upfronthosting.co.za> Message-ID: <1479688364.66.0.946621643322.issue20572@psf.upfronthosting.co.za> Gregory P. Smith added the comment: thanks for the patch. I reworked it slightly including the test. warning in 3.6, gone in 3.7. i still need to update the 3.7 docs to remove it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 19:35:37 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 00:35:37 +0000 Subject: [issue20572] subprocess.Popen.wait() undocumented "endtime" parameter In-Reply-To: <1391941400.18.0.703922206544.issue20572@psf.upfronthosting.co.za> Message-ID: <20161121003534.40895.8795.E16911F5@psf.io> Roundup Robot added the comment: New changeset 54b2f377653d by Gregory P. Smith in branch 'default': issue 20572: remove the deprecation notice for the deleted endtime parameter. https://hg.python.org/cpython/rev/54b2f377653d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 20:16:47 2016 From: report at bugs.python.org (Stephen J. Turnbull) Date: Mon, 21 Nov 2016 01:16:47 +0000 Subject: [issue28032] --with-lto builds segfault in many situations In-Reply-To: <1473370352.47.0.536997029042.issue28032@psf.upfronthosting.co.za> Message-ID: <1479691007.61.0.357519943183.issue28032@psf.upfronthosting.co.za> Stephen J. Turnbull added the comment: FWIW, XEmacs has used a bit of m4 magic to make --with-* and --enable-* equivalent for 15 years, and nobody has ever complained. The autotools convention is a distinction without a difference, and confuses users when a program feature depends on an external library (especially where there are alternative implementations). ---------- nosy: +sjt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 20:23:47 2016 From: report at bugs.python.org (John Nagle) Date: Mon, 21 Nov 2016 01:23:47 +0000 Subject: [issue28756] robotfileparser always uses default Python user-agent Message-ID: <1479691426.59.0.686880429063.issue28756@psf.upfronthosting.co.za> New submission from John Nagle: urllib.robotparser.RobotFileParser always uses the default Python user agent. This agent is now blacklisted by many sites, and it's not possible to read the robots.txt file at all. ---------- components: Library (Lib) messages: 281314 nosy: nagle priority: normal severity: normal status: open title: robotfileparser always uses default Python user-agent type: enhancement versions: 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 Sun Nov 20 20:26:36 2016 From: report at bugs.python.org (John Nagle) Date: Mon, 21 Nov 2016 01:26:36 +0000 Subject: [issue28756] robotfileparser always uses default Python user-agent In-Reply-To: <1479691426.59.0.686880429063.issue28756@psf.upfronthosting.co.za> Message-ID: <1479691596.58.0.0726918397452.issue28756@psf.upfronthosting.co.za> John Nagle added the comment: Suggest adding a user_agent optional parameter, as shown here: def __init__(self, url='', user_agent=None): urllib.robotparser.RobotFileParser.__init__(self, url) # init parent self.user_agent = user_agent # save user agent def read(self): """ Reads the robots.txt URL and feeds it to the parser. Overrides parent read function. """ try: req = urllib.request.Request( # request with user agent specified self.url, data=None) if self.user_agent is not None : # if overriding user agent req.add_header("User-Agent", self.user_agent) f = urllib.request.urlopen(req) # open connection except urllib.error.HTTPError as err: if err.code in (401, 403): self.disallow_all = True elif err.code >= 400 and err.code < 500: self.allow_all = True else: raw = f.read() self.parse(raw.decode("utf-8").splitlines()) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 20:29:40 2016 From: report at bugs.python.org (John Nagle) Date: Mon, 21 Nov 2016 01:29:40 +0000 Subject: [issue28756] robotfileparser always uses default Python user-agent In-Reply-To: <1479691426.59.0.686880429063.issue28756@psf.upfronthosting.co.za> Message-ID: <1479691780.71.0.91962445742.issue28756@psf.upfronthosting.co.za> John Nagle added the comment: (That's from a subclass I wrote. As a change to RobotFileParser, __init__ should start like this.) def __init__(self, url='', user_agent=None): self.user_agent = user_agent # save user agent ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 21:02:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 02:02:24 +0000 Subject: [issue28556] typing.py upgrades In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za> Message-ID: <20161121020220.12080.36470.96D3C4EB@psf.io> Roundup Robot added the comment: New changeset 75c7bc2c1ad8 by Guido van Rossum in branch '3.5': Issue #28556: upstream improvements to docstrings and error messages by Ivan Levkivskyi (#331) https://hg.python.org/cpython/rev/75c7bc2c1ad8 New changeset 294525aac5eb by Guido van Rossum in branch '3.6': Issue #28556: upstream improvements to docstrings and error messages by Ivan Levkivskyi (#331) (3.5->3.6) https://hg.python.org/cpython/rev/294525aac5eb New changeset 30f154d9abf0 by Guido van Rossum in branch 'default': Issue #28556: upstream improvements to docstrings and error messages by Ivan Levkivskyi (#331) (3.6->3.7) https://hg.python.org/cpython/rev/30f154d9abf0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 21:30:23 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 21 Nov 2016 02:30:23 +0000 Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za> Message-ID: <1479695423.04.0.730992337514.issue28747@psf.upfronthosting.co.za> Steve Dower added the comment: Should have assigned this to me, as I expect I'll be the one to apply it. Christian - I need to look to you for whether I've exposed the right function here and it's not adding security risk (obviously excluding a broken callback implementation). I *think* it's okay, but I trust your greater experience here. 3.6.0b4 is being tagged tomorrow and I think this is worth getting in - hence why I added Ned. There's no added functionality and no impact if the API isn't used. The latest patch removes the '_' prefix but happy to put it back and leave it as undocumented. If neither of you have any concerns, I'll check it in. As I mentioned, at some point early in Python 3.6's release I should have a library available that lets the OS do certificate validation, but it needs this callback exposed. ---------- assignee: christian.heimes -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 21:49:37 2016 From: report at bugs.python.org (Sophia I. Salinas) Date: Mon, 21 Nov 2016 02:49:37 +0000 Subject: [issue28757] Installation Failure Message-ID: <1479696577.66.0.987824550114.issue28757@psf.upfronthosting.co.za> New submission from Sophia I. Salinas: I downloaded Python 3.2 for Mac but when I tried to install it, I got an error that says: "The installation failed. The installer could not install the software because there was no software found to install." ---------- messages: 281319 nosy: sophiaisa priority: normal severity: normal status: open title: Installation Failure type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 22:31:23 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 21 Nov 2016 03:31:23 +0000 Subject: [issue10656] "Out of tree" build fails on AIX In-Reply-To: <1291865704.62.0.494509897126.issue10656@psf.upfronthosting.co.za> Message-ID: <1479699083.78.0.248073527672.issue10656@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 22:32:14 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 21 Nov 2016 03:32:14 +0000 Subject: [issue25659] ctypes.Array.from_buffer segmentation fault when trying to create from array.array In-Reply-To: <1447869436.37.0.609997226839.issue25659@psf.upfronthosting.co.za> Message-ID: <1479699134.63.0.887775483518.issue25659@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 22:47:13 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Mon, 21 Nov 2016 03:47:13 +0000 Subject: [issue20572] subprocess.Popen.wait() undocumented "endtime" parameter In-Reply-To: <1391941400.18.0.703922206544.issue20572@psf.upfronthosting.co.za> Message-ID: <1479700033.79.0.375914303723.issue20572@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Works for me. Thanks :) Maybe it's ok to close this ticket now? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 20 23:59:31 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 21 Nov 2016 04:59:31 +0000 Subject: [issue4347] Circular dependency causes SystemError when adding new syntax In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za> Message-ID: <1479704371.25.0.681425479149.issue4347@psf.upfronthosting.co.za> Martin Panter added the comment: Equivalent patch for 2.7 ---------- Added file: http://bugs.python.org/file45576/graminit-dep.py2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 00:17:28 2016 From: report at bugs.python.org (dontbugme) Date: Mon, 21 Nov 2016 05:17:28 +0000 Subject: [issue28758] UnicodeDecodeError: 'gbk' codec can't decode byte 0xab in position 74: illegal multibyte sequence Message-ID: <1479705448.56.0.0763380057233.issue28758@psf.upfronthosting.co.za> New submission from dontbugme: you can see https://github.com/mintty/mintty/issues/609 os.popen('chcp 65001 && ' + JAVA + ' -jar ' + CHECKSTYLE_JAR + ' -c ' + CHECKSTYLE_XML + ' "%s/%s"' % (COMMIT_TEMP_DIT, changed)).read() ---------- messages: 281322 nosy: dontbugme priority: normal severity: normal status: open title: UnicodeDecodeError: 'gbk' codec can't decode byte 0xab in position 74: illegal multibyte sequence versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 00:40:42 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 21 Nov 2016 05:40:42 +0000 Subject: [issue28756] robotfileparser always uses default Python user-agent In-Reply-To: <1479691426.59.0.686880429063.issue28756@psf.upfronthosting.co.za> Message-ID: <1479706842.5.0.327498732115.issue28756@psf.upfronthosting.co.za> Xiang Zhang added the comment: Hi, John. This issue of robotparser has been reported in #15851. I'll close this as duplicate and you can discuss in that thread. ---------- nosy: +xiang.zhang resolution: -> duplicate status: open -> closed superseder: -> Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default. versions: -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 00:42:23 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 21 Nov 2016 05:42:23 +0000 Subject: [issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default. In-Reply-To: <1346610964.7.0.836759738208.issue15851@psf.upfronthosting.co.za> Message-ID: <1479706943.85.0.21194678872.issue15851@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- versions: +Python 3.7 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 01:12:12 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 21 Nov 2016 06:12:12 +0000 Subject: [issue28756] robotfileparser always uses default Python user-agent In-Reply-To: <1479691426.59.0.686880429063.issue28756@psf.upfronthosting.co.za> Message-ID: <1479708732.56.0.194389655783.issue28756@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 01:34:10 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 21 Nov 2016 06:34:10 +0000 Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za> Message-ID: <1479710050.6.0.224675109723.issue28747@psf.upfronthosting.co.za> Ned Deily added the comment: With the patch (_2), clang (and gcc 4.2) on macOS warn: ./Modules/_ssl.c:3968:7: warning: assigning to 'unsigned char *' from 'char *' converts between pointers to integer types with different sign [-Wpointer-sign] p = PyBytes_AS_STRING(enc_cert); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 01:45:50 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 21 Nov 2016 06:45:50 +0000 Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za> Message-ID: <1479710750.78.0.751196628912.issue28747@psf.upfronthosting.co.za> Ned Deily added the comment: And, as it stands, the tests fail (at least on macOS): ====================================================================== ERROR: test_set_cert_verify_callback (test.test_ssl.SimpleBackgroundTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/dev/36/root/fwd_macports/Library/Frameworks/pytest_10.12.framework/Versions/3.6/lib/python3.6/test/test_ssl.py", line 1782, in test_set_cert_verify_callback ctx._set_cert_verify_callback(callback) AttributeError: 'SSLContext' object has no attribute '_set_cert_verify_callback' ====================================================================== ERROR: test_set_cert_verify_callback_error (test.test_ssl.SimpleBackgroundTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/dev/36/root/fwd_macports/Library/Frameworks/pytest_10.12.framework/Versions/3.6/lib/python3.6/test/test_ssl.py", line 1805, in test_set_cert_verify_callback_error ctx._set_cert_verify_callback(raise_error) AttributeError: 'SSLContext' object has no attribute '_set_cert_verify_callback' ====================================================================== ERROR: test_set_cert_verify_callback_suppress_error (test.test_ssl.SimpleBackgroundTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/dev/36/root/fwd_macports/Library/Frameworks/pytest_10.12.framework/Versions/3.6/lib/python3.6/test/test_ssl.py", line 1827, in test_set_cert_verify_callback_suppress_error ctx._set_cert_verify_callback(raise_error) AttributeError: 'SSLContext' object has no attribute '_set_cert_verify_callback' ---------------------------------------------------------------------- Ran 130 tests in 27.416s FAILED (errors=3, skipped=8) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 01:50:57 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 21 Nov 2016 06:50:57 +0000 Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za> Message-ID: <1479711057.44.0.783377272123.issue28747@psf.upfronthosting.co.za> Ned Deily added the comment: We are two weeks from producing the release candidate for 3.6.0. I don't think we should be rushing to add a new security-critical API which, IIUC, won't be used in the initial release anyway. Let's target it for 3.7 after proper review and then we can decide whether it makes sense to backport to a 3.6.x maint release if the security issues it may solve warrant it. ---------- versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 02:09:21 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 21 Nov 2016 07:09:21 +0000 Subject: [issue28032] --with-lto builds segfault in many situations In-Reply-To: <1473370352.47.0.536997029042.issue28032@psf.upfronthosting.co.za> Message-ID: <1479712161.33.0.0436791095392.issue28032@psf.upfronthosting.co.za> Ned Deily added the comment: For 3.6 at least, there are still mentions of --with-optimizations in Doc/whatsnew/3.6.rst and README. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 02:45:38 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 21 Nov 2016 07:45:38 +0000 Subject: [issue27945] Various segfaults with dict In-Reply-To: <1472852008.61.0.354257945943.issue27945@psf.upfronthosting.co.za> Message-ID: <1479714338.71.0.486791523707.issue27945@psf.upfronthosting.co.za> INADA Naoki added the comment: LGTM. Performance on Azure VM (AMD Opteron(tm) Processor 4171 HE): $ ~/local/py36/bin/patched -m perf compare_to master.json patched.json -G Slower (10): - spectral_norm: 915 ms +- 17 ms -> 967 ms +- 25 ms: 1.06x slower - nbody: 774 ms +- 28 ms -> 805 ms +- 22 ms: 1.04x slower - regex_dna: 965 ms +- 18 ms -> 993 ms +- 22 ms: 1.03x slower - go: 1.93 sec +- 0.05 sec -> 1.99 sec +- 0.06 sec: 1.03x slower - python_startup_no_site: 29.7 ms +- 2.0 ms -> 30.5 ms +- 2.0 ms: 1.03x slower - xml_etree_parse: 1.02 sec +- 0.03 sec -> 1.04 sec +- 0.04 sec: 1.02x slower - python_startup: 52.7 ms +- 3.6 ms -> 53.7 ms +- 3.6 ms: 1.02x slower - xml_etree_generate: 962 ms +- 24 ms -> 978 ms +- 25 ms: 1.02x slower - pickle_dict: 188 us +- 8 us -> 191 us +- 8 us: 1.02x slower - scimark_fft: 2.19 sec +- 0.04 sec -> 2.20 sec +- 0.05 sec: 1.00x slower Faster (26): - fannkuch: 3.76 sec +- 0.07 sec -> 3.55 sec +- 0.09 sec: 1.06x faster - call_method_slots: 59.4 ms +- 9.0 ms -> 56.6 ms +- 3.4 ms: 1.05x faster - sqlite_synth: 27.6 us +- 1.4 us -> 26.4 us +- 1.2 us: 1.05x faster - nqueens: 852 ms +- 19 ms -> 813 ms +- 20 ms: 1.05x faster - django_template: 1.35 sec +- 0.04 sec -> 1.29 sec +- 0.03 sec: 1.05x faster - unpack_sequence: 407 ns +- 16 ns -> 390 ns +- 16 ns: 1.04x faster - call_method: 60.6 ms +- 1.4 ms -> 58.1 ms +- 1.6 ms: 1.04x faster - xml_etree_iterparse: 918 ms +- 29 ms -> 881 ms +- 32 ms: 1.04x faster - unpickle_pure_python: 3.44 ms +- 0.14 ms -> 3.31 ms +- 0.19 ms: 1.04x faster - richards: 608 ms +- 20 ms -> 585 ms +- 15 ms: 1.04x faster - chaos: 921 ms +- 22 ms -> 891 ms +- 24 ms: 1.03x faster - mako: 189 ms +- 8 ms -> 183 ms +- 8 ms: 1.03x faster - meteor_contest: 699 ms +- 23 ms -> 677 ms +- 26 ms: 1.03x faster - regex_compile: 1.52 sec +- 0.03 sec -> 1.48 sec +- 0.04 sec: 1.03x faster - chameleon: 101 ms +- 5 ms -> 97.8 ms +- 4.0 ms: 1.03x faster - regex_v8: 153 ms +- 7 ms -> 149 ms +- 6 ms: 1.03x faster - 2to3: 2.59 sec +- 0.05 sec -> 2.52 sec +- 0.05 sec: 1.03x faster - crypto_pyaes: 797 ms +- 20 ms -> 776 ms +- 18 ms: 1.03x faster - genshi_xml: 653 ms +- 23 ms -> 637 ms +- 27 ms: 1.03x faster - pickle_pure_python: 4.54 ms +- 0.19 ms -> 4.42 ms +- 0.20 ms: 1.03x faster - regex_effbot: 18.4 ms +- 0.7 ms -> 18.1 ms +- 0.6 ms: 1.02x faster - unpickle: 107 us +- 4 us -> 105 us +- 5 us: 1.02x faster - deltablue: 61.2 ms +- 3.4 ms -> 60.0 ms +- 3.5 ms: 1.02x faster - raytrace: 4.34 sec +- 0.14 sec -> 4.26 sec +- 0.10 sec: 1.02x faster - telco: 63.9 ms +- 3.1 ms -> 62.9 ms +- 3.2 ms: 1.02x faster - pidigits: 965 ms +- 14 ms -> 955 ms +- 20 ms: 1.01x faster Benchmark hidden because not significant (28): call_method_unknown, call_simple, dulwich_log, float, genshi_text, hexiom, html5lib, json_dumps, json_loads, logging_format, logging_silent, logging_simple, pathlib, pickle, pickle_list, scimark_lu, scimark_monte_carlo, scimark_sor, scimark_sparse_mat_mult, sqlalchemy_declarative, sqlalchemy_imperative, sympy_expand, sympy_integrate, sympy_str, sympy_sum, tornado_http, unpickle_list, xml_etree_process ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 03:12:55 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 21 Nov 2016 08:12:55 +0000 Subject: [issue28759] access to mkfifo, mknod and hard links is controled by SELinux MAC on Android Message-ID: <1479715975.06.0.930254771903.issue28759@psf.upfronthosting.co.za> New submission from Xavier de Gaye: List of the tests that fail with PermissionError when run as a non-root user on an Android emulator (API 24) and fixed by this patch: test_posix test_shutil test_stat test_genericpath test_ntpath test_posixpath test_macpath test_eintr test_pathlib Android uses SELinux mandatory access control (MAC), see: https://source.android.com/security/selinux/ Android commit message that does not grant hard link capabilities by default: https://android.googlesource.com/platform/external/sepolicy/+/85ce2c7 ---------- assignee: xdegaye components: Tests files: android_not_root.patch keywords: patch messages: 281329 nosy: xdegaye priority: normal severity: normal stage: patch review status: open title: access to mkfifo, mknod and hard links is controled by SELinux MAC on Android type: behavior versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45577/android_not_root.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 03:15:08 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 21 Nov 2016 08:15:08 +0000 Subject: [issue28032] --with-lto builds segfault in many situations In-Reply-To: <1473370352.47.0.536997029042.issue28032@psf.upfronthosting.co.za> Message-ID: <1479716108.65.0.329878319084.issue28032@psf.upfronthosting.co.za> Gregory P. Smith added the comment: doc references fixed. thanks! remote: notified python-checkins at python.org of incoming changeset a5e2add2c37b remote: notified python-checkins at python.org of incoming changeset 6ae0e6d435de remote: notified python-checkins at python.org of incoming changeset ea9cc29a274b remote: notified python-checkins at python.org of incoming changeset 38e9761ccc13 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 03:18:13 2016 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 21 Nov 2016 08:18:13 +0000 Subject: [issue28748] Make _Py_PackageContext of type "const char *" In-Reply-To: <1479634320.59.0.400146468836.issue28748@psf.upfronthosting.co.za> Message-ID: <1479716293.54.0.675193004133.issue28748@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ah, my apologies - for some reason I completely failed to notice the leading underscore until I saw you refer to this as a private variable in the What's New note. That means the note only needs to go in the NEWS file for the benefit of maintainers, rather than in the public porting notes. Sorry for overcomplicating things :) Aside from my confusion about this actually being a private interface, the patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 03:19:52 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 21 Nov 2016 08:19:52 +0000 Subject: [issue28032] --with-lto builds segfault in many situations In-Reply-To: <1473370352.47.0.536997029042.issue28032@psf.upfronthosting.co.za> Message-ID: <1479716392.64.0.772049305738.issue28032@psf.upfronthosting.co.za> Gregory P. Smith added the comment: This is no longer a release blocker as --with-lto is not enabled by default by --enable-optimizations since my commits in September. Regarding --with-lto itself segfaulting... Fixing compiler+linker toolchains is beyond what CPython itself should do. But the reason the flag remains named "optimizations" is that it is fair for us to include --with-lto or other future build time optimization in known good configurations detected by the autoconf configure.ac in the future if desired. I do not think there is anything more for us to do here. We should explicitly _not_ try to add smarts to --with-lto itself as to whether we believe it will build a broken binary or not. ---------- priority: release blocker -> normal resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 03:26:12 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 08:26:12 +0000 Subject: [issue28748] Make _Py_PackageContext of type "const char *" In-Reply-To: <1479634320.59.0.400146468836.issue28748@psf.upfronthosting.co.za> Message-ID: <20161121082609.41115.74015.99EA1896@psf.io> Roundup Robot added the comment: New changeset d2dd6578aa16 by Serhiy Storchaka in branch 'default': Issue #28748: Private variable _Py_PackageContext is now of type "const char *" https://hg.python.org/cpython/rev/d2dd6578aa16 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 03:27:08 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Nov 2016 08:27:08 +0000 Subject: [issue28748] Make _Py_PackageContext of type "const char *" In-Reply-To: <1479634320.59.0.400146468836.issue28748@psf.upfronthosting.co.za> Message-ID: <1479716828.31.0.949180146516.issue28748@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Nick. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 03:48:53 2016 From: report at bugs.python.org (Antti Haapala) Date: Mon, 21 Nov 2016 08:48:53 +0000 Subject: [issue19948] POSIX semantics of PATH search in execvpe is not respected In-Reply-To: <1386687325.82.0.275504904763.issue19948@psf.upfronthosting.co.za> Message-ID: <1479718133.07.0.194042837682.issue19948@psf.upfronthosting.co.za> Antti Haapala added the comment: Someone on Stack Overflow just had a problem where their shell script would work in shell but get `OSError: [Errno 8] Exec format error` when calling it with `subprocess.call`. I'd say rather fix this (on POSIX platforms). Why does Python do path resolving on its own anyway? Shouldn't it delegate these all to appropriate execv* variants. ---------- nosy: +ztane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 04:10:59 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 21 Nov 2016 09:10:59 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1479719459.69.0.0643087564516.issue28638@psf.upfronthosting.co.za> INADA Naoki added the comment: > If someone comes forward with more fully formed idea for code generation or overall structural enchancement, that can be put in another tracker item. I noticed argument clinic supports Python [1]. So there is one way to code generation already. Attached patch uses Argument Clinic and Makefile to generate source. [1]: https://docs.python.org/3.5/howto/clinic.html#using-argument-clinic-in-python-files ---------- Added file: http://bugs.python.org/file45578/namedtuple-clinic.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 04:24:14 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 21 Nov 2016 09:24:14 +0000 Subject: [issue28760] Cleanup PyUnicode_AsUnicodeEscapeString Message-ID: <1479720254.49.0.534389822333.issue28760@psf.upfronthosting.co.za> New submission from Xiang Zhang: PyUnicode_AsUnicodeEscapeString now still has some old comments and codes about the original "quotes" parameter of unicodeescape_string. Current implementation could get rid of them. ---------- files: PyUnicode_AsUnicodeEscapeString.patch keywords: patch messages: 281337 nosy: xiang.zhang priority: normal severity: normal stage: patch review status: open title: Cleanup PyUnicode_AsUnicodeEscapeString type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45579/PyUnicode_AsUnicodeEscapeString.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 04:29:50 2016 From: report at bugs.python.org (Antti Haapala) Date: Mon, 21 Nov 2016 09:29:50 +0000 Subject: [issue19948] POSIX semantics of PATH search in execvpe is not respected In-Reply-To: <1386687325.82.0.275504904763.issue19948@psf.upfronthosting.co.za> Message-ID: <1479720590.31.0.082143403419.issue19948@psf.upfronthosting.co.za> Antti Haapala added the comment: While at it, another POSIX semantic that execvp doesn't support is the behaviour when `PATH` is not set, e.g. on Linux, the search path is set to '.', followed by confstr(_CS_PATH). It is debatable whether this is desired (having current directory first in search path doesn't exactly sound right, which is also acknowledged by Linux man pages: NOTES On some other systems, the default path (used when the environment does not contain the variable PATH) has the current working direc? tory listed after /bin and /usr/bin, as an anti-Trojan-horse mea? sure. Linux uses here the traditional "current directory first" default path. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 04:30:53 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 21 Nov 2016 09:30:53 +0000 Subject: [issue28760] Cleanup PyUnicode_AsUnicodeEscapeString In-Reply-To: <1479720254.49.0.534389822333.issue28760@psf.upfronthosting.co.za> Message-ID: <1479720653.1.0.662494042934.issue28760@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Interpreter Core, Unicode nosy: +ezio.melotti, haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 04:35:02 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 21 Nov 2016 09:35:02 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1479720902.51.0.0245174948659.issue28638@psf.upfronthosting.co.za> INADA Naoki added the comment: Updated patch: fixed small issue in argument clinic, and added comment why we use code generation. ---------- Added file: http://bugs.python.org/file45580/namedtuple-clinic2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 04:40:16 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Nov 2016 09:40:16 +0000 Subject: [issue28761] Add the const qualifier to fields name and doc of public structs Message-ID: <1479721215.94.0.926847146167.issue28761@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch makes the fields name and doc of structures PyMemberDef, PyGetSetDef, PyStructSequence_Field, PyStructSequence_Desc, and wrapperbase being of type "const char *" rather of "char *". These structures often are initialized as static variables and name and doc fields are initialized from literal strings. These fields are always refer to constant string literal, NULL, or readonly UTF8 representation of a Unicode object. They are never refer to mutable data. Changing the data referred by these pointers is an error. Adding the const qualifier makes clear that this is an immutable data. This change may need some changes in third-party code. But it needs to change only one line in CPython sources, and I believe that most third-party projects don't need any changes at all. ---------- components: Interpreter Core files: const-name-and-doc-fields.patch keywords: patch messages: 281340 nosy: ncoghlan, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Add the const qualifier to fields name and doc of public structs type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45581/const-name-and-doc-fields.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 04:42:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Nov 2016 09:42:32 +0000 Subject: [issue28760] Cleanup PyUnicode_AsUnicodeEscapeString In-Reply-To: <1479720254.49.0.534389822333.issue28760@psf.upfronthosting.co.za> Message-ID: <1479721352.21.0.0656389477914.issue28760@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 04:44:45 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Nov 2016 09:44:45 +0000 Subject: [issue28760] Cleanup PyUnicode_AsUnicodeEscapeString In-Reply-To: <1479720254.49.0.534389822333.issue28760@psf.upfronthosting.co.za> Message-ID: <1479721485.84.0.386593549311.issue28760@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. Thanks Xiang. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 04:47:32 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 09:47:32 +0000 Subject: [issue28760] Cleanup PyUnicode_AsUnicodeEscapeString In-Reply-To: <1479720254.49.0.534389822333.issue28760@psf.upfronthosting.co.za> Message-ID: <20161121094729.46126.71071.CC35E4A3@psf.io> Roundup Robot added the comment: New changeset 2d0ce3f4dfbd by Serhiy Storchaka in branch '3.6': Issue #28760: Clean up and fix comments in PyUnicode_AsUnicodeEscapeString(). https://hg.python.org/cpython/rev/2d0ce3f4dfbd New changeset d656b93c5603 by Serhiy Storchaka in branch 'default': Issue #28760: Clean up and fix comments in PyUnicode_AsUnicodeEscapeString(). https://hg.python.org/cpython/rev/d656b93c5603 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 04:47:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Nov 2016 09:47:54 +0000 Subject: [issue28760] Cleanup PyUnicode_AsUnicodeEscapeString In-Reply-To: <1479720254.49.0.534389822333.issue28760@psf.upfronthosting.co.za> Message-ID: <1479721674.31.0.204127761493.issue28760@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 04:49:52 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 21 Nov 2016 09:49:52 +0000 Subject: [issue28760] Cleanup PyUnicode_AsUnicodeEscapeString In-Reply-To: <1479720254.49.0.534389822333.issue28760@psf.upfronthosting.co.za> Message-ID: <1479721792.81.0.742316095904.issue28760@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks for your work, Serhiy. ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 05:19:49 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 21 Nov 2016 10:19:49 +0000 Subject: [issue28762] configure links with lockf and F_LOCK is not declared in Android API 24 Message-ID: <1479723589.5.0.525775136475.issue28762@psf.upfronthosting.co.za> New submission from Xavier de Gaye: The patch fixes the following error: ====================================================================== ERROR: test_lockf (test.test_posix.PosixTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "/sdcard/org.bitbucket.pyona/lib/python3.7/test/test_posix.py", line 195, in test_lockf posix.lockf(fd, posix.F_LOCK, 4) AttributeError: module 'posix' has no attribute 'F_LOCK' ---------- assignee: xdegaye components: Interpreter Core files: test_posix_flock.patch keywords: patch messages: 281344 nosy: xdegaye priority: normal severity: normal stage: patch review status: open title: configure links with lockf and F_LOCK is not declared in Android API 24 type: behavior versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45582/test_posix_flock.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 05:20:27 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 21 Nov 2016 10:20:27 +0000 Subject: [issue28532] Show sys.version when -V option is supplied twice. In-Reply-To: <1477417861.44.0.42778795289.issue28532@psf.upfronthosting.co.za> Message-ID: <1479723627.97.0.168265329402.issue28532@psf.upfronthosting.co.za> INADA Naoki added the comment: I noticed today is code freeze for final beta. Is this too late for 3.6.0? ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 05:22:06 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 21 Nov 2016 10:22:06 +0000 Subject: [issue28023] python-gdb.py must be updated for the new Python 3.6 compact dict In-Reply-To: <1473351940.28.0.277088210884.issue28023@psf.upfronthosting.co.za> Message-ID: <1479723726.43.0.00168456674394.issue28023@psf.upfronthosting.co.za> INADA Naoki added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 06:33:29 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 21 Nov 2016 11:33:29 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za> Message-ID: <1479728009.92.0.697829908423.issue28731@psf.upfronthosting.co.za> Changes by INADA Naoki : Added file: http://bugs.python.org/file45583/28731-PyDict_NewPresized-too-small-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 06:34:56 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Nov 2016 11:34:56 +0000 Subject: [issue28763] Use en-dashes for ranges in docs Message-ID: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: It is recommended to use an em-dash instead of a hyphen for numerical ranges. It looks better in the rendered document. Python documentation already use it, but not always. Proposed patch adds more en-dashes. ---------- assignee: docs at python components: Documentation files: docs-en-dash.patch keywords: patch messages: 281347 nosy: docs at python, martin.panter, serhiy.storchaka priority: normal severity: normal status: open title: Use en-dashes for ranges in docs type: enhancement Added file: http://bugs.python.org/file45584/docs-en-dash.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 06:39:21 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 21 Nov 2016 11:39:21 +0000 Subject: [issue28532] Show sys.version when -V option is supplied twice. In-Reply-To: <1477417861.44.0.42778795289.issue28532@psf.upfronthosting.co.za> Message-ID: <1479728361.32.0.944106094722.issue28532@psf.upfronthosting.co.za> Martin Panter added the comment: Ned indicated he was open to the idea: . Maybe just double check; there?s still a few hours left! I?m not sure, but maybe there should be ?.. versionchanged:: 3.6? in the RST documentation, and an entry in What?s New? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 06:42:26 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Nov 2016 11:42:26 +0000 Subject: [issue28532] Show sys.version when -V option is supplied twice. In-Reply-To: <1477417861.44.0.42778795289.issue28532@psf.upfronthosting.co.za> Message-ID: <1479728546.62.0.978978300357.issue28532@psf.upfronthosting.co.za> STINNER Victor added the comment: verbose-version3.patch LGTM and seems useful to me. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 06:48:12 2016 From: report at bugs.python.org (Charalampos Stratakis) Date: Mon, 21 Nov 2016 11:48:12 +0000 Subject: [issue21590] Systemtap and DTrace support In-Reply-To: <1401195995.8.0.935339035852.issue21590@psf.upfronthosting.co.za> Message-ID: <1479728892.62.0.911487753995.issue21590@psf.upfronthosting.co.za> Charalampos Stratakis added the comment: @?ukasz Would it be possible to review the patch? Or is it preferable to open a new issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 06:58:21 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 11:58:21 +0000 Subject: [issue28532] Show sys.version when -V option is supplied twice. In-Reply-To: <1477417861.44.0.42778795289.issue28532@psf.upfronthosting.co.za> Message-ID: <20161121115818.40774.21157.E64E2AF4@psf.io> Roundup Robot added the comment: New changeset fc6bb69cec05 by INADA Naoki in branch '3.6': Issue #28532: Show sys.version when -V option is supplied twice https://hg.python.org/cpython/rev/fc6bb69cec05 New changeset 02aa667bd02d by INADA Naoki in branch 'default': Issue #28532: Show sys.version when -V option is supplied twice https://hg.python.org/cpython/rev/02aa667bd02d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 07:18:41 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 21 Nov 2016 12:18:41 +0000 Subject: [issue28532] Show sys.version when -V option is supplied twice. In-Reply-To: <1477417861.44.0.42778795289.issue28532@psf.upfronthosting.co.za> Message-ID: <1479730721.46.0.287045084629.issue28532@psf.upfronthosting.co.za> INADA Naoki added the comment: Thanks for review. Since doc update is allowed after final beta, I committed verbose-version3.patch for now. Here is patch for doc. ---------- Added file: http://bugs.python.org/file45585/vervose-version-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 07:41:09 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Nov 2016 12:41:09 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za> Message-ID: <1479732069.49.0.300769990944.issue28731@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: A variant in msg281118 looks better to me than 28731-PyDict_NewPresized-too-small-2.patch. It doesn't look good to me that newsize is set to arbitrary small value if estimated size is larger than very large PyDict_MAXSIZE (this is 2**28 on 32-bit and 2**60 on 64-bit). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 07:56:04 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 21 Nov 2016 12:56:04 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za> Message-ID: <1479732964.21.0.359687537124.issue28731@psf.upfronthosting.co.za> Changes by INADA Naoki : Added file: http://bugs.python.org/file45586/28731-PyDict_NewPresized-too-small-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 08:00:14 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 21 Nov 2016 13:00:14 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za> Message-ID: <1479733214.54.0.107428914891.issue28731@psf.upfronthosting.co.za> INADA Naoki added the comment: OK. I've updated the patch. BTW, I used const Py_ssize_t for function local constant. Should I use file scope macro for such heuristic threshold, even it is used only one function? ---------- priority: high -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 08:47:14 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Nov 2016 13:47:14 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za> Message-ID: <1479736034.25.0.945008683075.issue28731@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think function scope constant is good. Similar code in dictresize() should have different bound. The patch LGTM. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 08:57:26 2016 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 21 Nov 2016 13:57:26 +0000 Subject: [issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools) In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za> Message-ID: <1479736646.76.0.961638129394.issue28638@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ah, I had forgotten that Larry had already included Python support in Argument Clinic. With the inline code auto-generated from the pure Python implementation, that addresses the main maintenance concerns I had. I did briefly wonder about the difficulties of bootstrapping Argument Clinic (since it uses functools), but that's already accounted for in the comment-based design of Argument Clinic itself (i.e. since the generated code is checked in, the previous iteration can be used to generate the updated one when the namedtuple template changes). Raymond, how does this variant look to you? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 09:04:34 2016 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 21 Nov 2016 14:04:34 +0000 Subject: [issue28761] Add the const qualifier to fields name and doc of public structs In-Reply-To: <1479721215.94.0.926847146167.issue28761@psf.upfronthosting.co.za> Message-ID: <1479737074.96.0.272087929858.issue28761@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 from me. The only thing I noticed in the patch was that the issue number needs filling in now that you've filed it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 09:06:42 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 21 Nov 2016 14:06:42 +0000 Subject: [issue28763] Use en-dashes for ranges in docs In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za> Message-ID: <1479737202.66.0.199467242702.issue28763@psf.upfronthosting.co.za> Ezio Melotti added the comment: While you are at it, have you checked how many en-dashes have been used instead of em-dashes? "--" is commonly used to indicate em-dashes (e.g. in emails), but in rst it renders to an en-dash. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 09:19:01 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Nov 2016 14:19:01 +0000 Subject: [issue28023] python-gdb.py must be updated for the new Python 3.6 compact dict In-Reply-To: <1473351940.28.0.277088210884.issue28023@psf.upfronthosting.co.za> Message-ID: <1479737941.13.0.497009355433.issue28023@psf.upfronthosting.co.za> STINNER Victor added the comment: I reviewed dict_gdb.patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 09:25:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Nov 2016 14:25:34 +0000 Subject: [issue28763] Use en-dashes for ranges in docs In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za> Message-ID: <1479738334.72.0.984540408295.issue28763@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 353 en-dashes with spaces. 479 em-dashes with spaces. 89 em-dashes without spaces. And some number of hyphens with spaces. It is hard to automatically distinguish them from minuses in code examples, but in issue18529 I provided large patches that converted all of them to dashes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 09:41:53 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Nov 2016 14:41:53 +0000 Subject: [issue28763] Use en-dashes for ranges in docs In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za> Message-ID: <1479739313.16.0.516172020173.issue28763@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Some of these double hyphens are in code examples. Thus the actual number of en-dashes that can be changed to em-dashes is smaller. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 09:43:15 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Nov 2016 14:43:15 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479739395.27.0.486939641145.issue28727@psf.upfronthosting.co.za> STINNER Victor added the comment: Back to basis, patch 6: * revert changes on indexgroup and groupindex types: I will fix this later, once this issue is fixed * pattern_richcompare() and pattern_hash() also uses pattern, but don't use groups, indexgroup nor groupindex anymore I removed the @cpython_only unit test and rewrote test_pattern_compare_bytes() to make it easier to follow. re.compile('abc', re.IGNORECASE) is different than re.compile('ABC', re.IGNORECASE), but it's a deliberate choice to not test it. I consider that the behaviour can change depending on the Python implementation and in a future version. ---------- Added file: http://bugs.python.org/file45587/pattern_compare-6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 09:59:11 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Nov 2016 14:59:11 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479740351.72.0.867919762432.issue28727@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: pattern_compare-6.patch LGTM. ---------- assignee: -> haypo stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 10:22:02 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 21 Nov 2016 15:22:02 +0000 Subject: [issue28764] test_mailbox fails when run as a non-root user on Android API 24 Message-ID: <1479741722.73.0.770267227494.issue28764@psf.upfronthosting.co.za> New submission from Xavier de Gaye: The patch fixes the problem that on Android API 24, a non-root user is not allowed to create the hard links used by the mailbox module. Related to issue 28759. ---------- assignee: xdegaye components: Library (Lib) files: test_mailbox_link.patch keywords: patch messages: 281364 nosy: xdegaye priority: normal severity: normal stage: patch review status: open title: test_mailbox fails when run as a non-root user on Android API 24 type: behavior versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45588/test_mailbox_link.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 10:39:26 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 15:39:26 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <20161121153906.9962.6726.93DFAC95@psf.io> Roundup Robot added the comment: New changeset 5e8ef1493843 by Victor Stinner in branch '3.6': Implement rich comparison for _sre.SRE_Pattern https://hg.python.org/cpython/rev/5e8ef1493843 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 10:39:26 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 15:39:26 +0000 Subject: [issue18383] test_warnings modifies warnings.filters when running with "-W default" In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za> Message-ID: <20161121153906.9962.57100.310938E1@psf.io> Roundup Robot added the comment: New changeset 5e8ef1493843 by Victor Stinner in branch '3.6': Implement rich comparison for _sre.SRE_Pattern https://hg.python.org/cpython/rev/5e8ef1493843 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 10:40:04 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 21 Nov 2016 15:40:04 +0000 Subject: [issue26865] Meta-issue: support of the android platform In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za> Message-ID: <1479742804.7.0.24753545567.issue26865@psf.upfronthosting.co.za> Xavier de Gaye added the comment: New issues raised upon testing on the Android API 24 emulator: issue #28683: bind() on a unix socket raises PermissionError on Android for a non-root user issue #28684: [asyncio] bind() on a unix socket raises PermissionError on Android for a non-root user issue #28746: cannot set_inheritable() for a file descriptor on Android issue #28759: access to mkfifo, mknod and hard links is controled by SELinux MAC on Android issue #28762: configure links with lockf and F_LOCK is not declared in Android API 24 issue #28764: test_mailbox fails when run as a non-root user on Android API 24 ---------- dependencies: +[asyncio] bind() on a unix socket raises PermissionError on Android for a non-root user, access to mkfifo, mknod and hard links is controled by SELinux MAC on Android, bind() on a unix socket raises PermissionError on Android for a non-root user, cannot set_inheritable() for a file descriptor on Android, configure links with lockf and F_LOCK is not declared in Android API 24, test_mailbox fails when run as a non-root user on Android API 24 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 10:45:38 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 21 Nov 2016 15:45:38 +0000 Subject: [issue28023] python-gdb.py must be updated for the new Python 3.6 compact dict In-Reply-To: <1473351940.28.0.277088210884.issue28023@psf.upfronthosting.co.za> Message-ID: <1479743138.45.0.537302814589.issue28023@psf.upfronthosting.co.za> Changes by INADA Naoki : Added file: http://bugs.python.org/file45589/dict_gdb2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 10:46:28 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 15:46:28 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings In-Reply-To: <1479128206.47.0.155651436814.issue28688@psf.upfronthosting.co.za> Message-ID: <20161121154623.45508.45195.D88B968A@psf.io> Roundup Robot added the comment: New changeset 75b1091594f8 by Victor Stinner in branch '3.5': Issue #28688: Remove warnings.filters check from regrtest https://hg.python.org/cpython/rev/75b1091594f8 New changeset a2616863de06 by Victor Stinner in branch '3.6': Issue #28688: Null merge 3.5 https://hg.python.org/cpython/rev/a2616863de06 New changeset da042eec6743 by Victor Stinner in branch 'default': Issue #28688: Null merge 3.6 https://hg.python.org/cpython/rev/da042eec6743 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 10:48:09 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Nov 2016 15:48:09 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479743289.75.0.0130703620788.issue28727@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy Storchaka: "pattern_compare-6.patch LGTM." Thank you very much for your very useful reviews! I pushed the change. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 10:50:42 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 21 Nov 2016 15:50:42 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za> Message-ID: <1479743442.53.0.714675071834.issue28731@psf.upfronthosting.co.za> INADA Naoki added the comment: Thanks. As @haypo suggests, I'll commit this to default branch first, and backport to 3.6 after 3.6.0 is released. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 10:52:21 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Nov 2016 15:52:21 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings In-Reply-To: <1479128206.47.0.155651436814.issue28688@psf.upfronthosting.co.za> Message-ID: <1479743541.08.0.374401583515.issue28688@psf.upfronthosting.co.za> STINNER Victor added the comment: I implemented x==y operator for _sre.SRE_Pattern in Python 3.6 and 3.7, it fixed this issue. For Python 3.5, I removed the warnings.filters test, as we discussed. @Martin Panter: immortal-filters.patch works because I'm not super excited by the change. Somehow, it looks like a hack... even if I don't see any better solution for Python 3.5. Since the bug only impacts Python test suite in the practical, is it really worth it to fix it in Python 3.5 which is almost in the "security fix only" stage? @Martin: It's up to you, I have no strong opinion on your patch. > I agree there is no need to change Python 2 at this stage. Ok. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 10:57:16 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 15:57:16 +0000 Subject: [issue28731] _PyDict_NewPresized() creates too small dict In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za> Message-ID: <20161121155709.5574.5719.85091DB0@psf.io> Roundup Robot added the comment: New changeset b708b3190ecb by INADA Naoki in branch 'default': Issue #28731: Optimize _PyDict_NewPresized() to create correct size dict https://hg.python.org/cpython/rev/b708b3190ecb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 10:57:38 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Nov 2016 15:57:38 +0000 Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup and groupindex Message-ID: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch makes _sre.compile() more strict on types: groupindex must be a dictionary and indexgroup must be a tuple. Currently, indexgroup is passed as a list. I chose to convert it to a tuple to use less memory and to prevent unwanted changes. For unwanted changed, I'm not sure because groupindex remains a mutable dictionary. Do you think that it's worth it to require a tuple? Another option is to accept a list but to convert it to a list, but this change is more specific to the current implementation. ---------- files: sre_types.patch keywords: patch messages: 281373 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: _sre.compile(): be more strict on types of indexgroup and groupindex type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45590/sre_types.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 10:58:18 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Nov 2016 15:58:18 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479743898.92.0.279063238966.issue28727@psf.upfronthosting.co.za> STINNER Victor added the comment: For stricter checks on _sre.compile() arguments, I created the issue #28765: "_sre.compile(): be more strict on types of indexgroup and groupindex". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 11:18:27 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 21 Nov 2016 16:18:27 +0000 Subject: [issue28740] Add sys.getandroidapilevel() In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za> Message-ID: <1479745107.43.0.608306752457.issue28740@psf.upfronthosting.co.za> Xavier de Gaye added the comment: I agree with Marc-Andre, Windows has sys.getwindowsversion() returning system information for the Windows version, and a platform.win32_ver() returning additional version information from the Registry obtained at run time. So it is consistent to add the sys.getandroidapilevel() function returning the version based on the ANDROID_API_LEVEL macro (a build, system level data, that specifies the libc version Python has been built against) and to add the platform.android_ver() version returning the device/emulator run time version obtained from the local properties system. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 11:31:14 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 16:31:14 +0000 Subject: [issue23591] enum: Add Flags and IntFlags In-Reply-To: <1425569483.33.0.144069723147.issue23591@psf.upfronthosting.co.za> Message-ID: <20161121163111.45947.80481.09A6AB26@psf.io> Roundup Robot added the comment: New changeset f404a59d834e by Ethan Furman in branch '3.6': closes issue23591: add NEWS entry https://hg.python.org/cpython/rev/f404a59d834e ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 11:31:14 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 16:31:14 +0000 Subject: [issue28082] re: convert re flags to (much friendlier) IntFlag constants In-Reply-To: <1473625770.04.0.107359046953.issue28082@psf.upfronthosting.co.za> Message-ID: <20161121163111.45947.72168.F7F4BD90@psf.io> Roundup Robot added the comment: New changeset 176fc21f8430 by Ethan Furman in branch '3.6': closes issue28082: doc update and NEWS entry https://hg.python.org/cpython/rev/176fc21f8430 ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 11:35:39 2016 From: report at bugs.python.org (Yuwei Ba) Date: Mon, 21 Nov 2016 16:35:39 +0000 Subject: [issue28766] Remove the semicolon in source code Message-ID: <1479746139.91.0.549636125293.issue28766@psf.upfronthosting.co.za> New submission from Yuwei Ba: As we do not often use semicolons in Python world. I hope this historical semi would be cleaned in a future release. Source: Lib/httplib.py:1117 ---------- components: Library (Lib) files: mywork.patch hgrepos: 361 keywords: patch messages: 281378 nosy: ibigbug priority: normal severity: normal status: open title: Remove the semicolon in source code type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file45591/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 11:35:56 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Nov 2016 16:35:56 +0000 Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup and groupindex In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za> Message-ID: <1479746156.55.0.606982130161.issue28765@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If make groupindex and indexgroup a dict and a tuple, we could use concrete dict and tuple API instead of generic mapping and sequence APIs. Note that groups, groupindex and indexgroup are not independent. Actually indexgroup is derived from groups and groupindex (in Python code), but groups and groupindex could be derived from indexgroup. groups could be derived from code. The interface of _sre.compile() can be simplified by passing only groupindex or indexgroup. Current interface is only for backward compatibility. I don't know whether this still is needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 11:40:28 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 16:40:28 +0000 Subject: [issue28082] re: convert re flags to (much friendlier) IntFlag constants In-Reply-To: <1473625770.04.0.107359046953.issue28082@psf.upfronthosting.co.za> Message-ID: <20161121164021.5574.33614.B53E85FA@psf.io> Roundup Robot added the comment: New changeset 493359386360 by Ethan Furman in branch '3.6': issue28082: actually include NEWS entry https://hg.python.org/cpython/rev/493359386360 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 11:43:41 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 21 Nov 2016 16:43:41 +0000 Subject: [issue28764] test_mailbox fails when run as a non-root user on Android API 24 In-Reply-To: <1479741722.73.0.770267227494.issue28764@psf.upfronthosting.co.za> Message-ID: <1479746621.52.0.902044911161.issue28764@psf.upfronthosting.co.za> R. David Murray added the comment: LGTM. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 11:48:23 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 21 Nov 2016 16:48:23 +0000 Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za> Message-ID: <1479746903.82.0.463836955466.issue28747@psf.upfronthosting.co.za> Steve Dower added the comment: Whoops, that's what I get for renaming something. Easily fixed, but I'm happy to aim for 3.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 12:24:14 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 17:24:14 +0000 Subject: [issue28172] Upper-case all example enum members In-Reply-To: <1473966107.03.0.300297915122.issue28172@psf.upfronthosting.co.za> Message-ID: <20161121172254.12325.25961.7ED826BE@psf.io> Roundup Robot added the comment: New changeset b9801dab214a by Ethan Furman in branch '3.6': close issue28172: Change all example enum member names to uppercase, per Guido; patch by Chris Angelico. https://hg.python.org/cpython/rev/b9801dab214a New changeset 5ec8d4c51363 by Ethan Furman in branch 'default': close issue28172: Change all example enum member names to uppercase, per Guido; patch by Chris Angelico. https://hg.python.org/cpython/rev/5ec8d4c51363 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 12:25:11 2016 From: report at bugs.python.org (Ethan Furman) Date: Mon, 21 Nov 2016 17:25:11 +0000 Subject: [issue28172] Upper-case all example enum members In-Reply-To: <1473966107.03.0.300297915122.issue28172@psf.upfronthosting.co.za> Message-ID: <1479749111.23.0.202827204795.issue28172@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 12:40:40 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Mon, 21 Nov 2016 17:40:40 +0000 Subject: [issue28767] Readd __index__ support on ipaddress objects Message-ID: <1479750040.58.0.0255514552996.issue28767@psf.upfronthosting.co.za> New submission from Josh Rosenberg: It looks like, due to #16722, in #15559, __index__ was removed from ipaddress objects. #16722 was fixed a few months later, but the comments asking for it to be readded were put on a closed issue, so no one noticed. Can __index__ support be readded now? Should be as simple as undoing https://hg.python.org/cpython/rev/5abea8a43f19 (probably manually, assuming the subsequent history would make a direct rollback nonfeasible). Nosying the folks involved in fixing the original bugs. ---------- messages: 281384 nosy: benjamin.peterson, josh.r, ncoghlan priority: normal severity: normal status: open title: Readd __index__ support on ipaddress objects versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 12:53:21 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Nov 2016 17:53:21 +0000 Subject: [issue28767] Readd __index__ support on ipaddress objects In-Reply-To: <1479750040.58.0.0255514552996.issue28767@psf.upfronthosting.co.za> Message-ID: <1479750801.65.0.186556753968.issue28767@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why __index__ support is needed? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 13:52:19 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 21 Nov 2016 18:52:19 +0000 Subject: [issue28751] Fix comments in code.h In-Reply-To: <1479652195.59.0.115870067836.issue28751@psf.upfronthosting.co.za> Message-ID: <1479754339.69.0.994996785793.issue28751@psf.upfronthosting.co.za> Brett Cannon added the comment: Patch LGTM. ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 13:57:50 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 21 Nov 2016 18:57:50 +0000 Subject: [issue4347] Circular dependency causes SystemError when adding new syntax In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za> Message-ID: <1479754670.65.0.448710736166.issue4347@psf.upfronthosting.co.za> Brett Cannon added the comment: So what does having the tokenizer not depend on pgen accomplish? Does it break a circular dependency where the tokenizer will get rebuilt with pgen before a full build starts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 14:12:28 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 21 Nov 2016 19:12:28 +0000 Subject: [issue28752] datetime object fails to restore from reduction In-Reply-To: <1479657323.42.0.875075153657.issue28752@psf.upfronthosting.co.za> Message-ID: <1479755548.06.0.460684108253.issue28752@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- assignee: -> belopolsky stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 14:18:15 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 21 Nov 2016 19:18:15 +0000 Subject: [issue28752] datetime object fails to restore from reduction In-Reply-To: <1479657323.42.0.875075153657.issue28752@psf.upfronthosting.co.za> Message-ID: <1479755895.91.0.256772430975.issue28752@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: The patch LGTM. I'll commit it tonight unless Serhiy beats me to it. ---------- nosy: +alexandre.vassalotti, haypo, tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 14:34:08 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Nov 2016 19:34:08 +0000 Subject: [issue28752] datetime object fails to restore from reduction In-Reply-To: <1479657323.42.0.875075153657.issue28752@psf.upfronthosting.co.za> Message-ID: <1479756848.75.0.963776503131.issue28752@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 15:00:30 2016 From: report at bugs.python.org (Masayuki Yamamoto) Date: Mon, 21 Nov 2016 20:00:30 +0000 Subject: [issue28768] Warning: implicit declaration of function '_setmode' Message-ID: <1479758430.88.0.97682867264.issue28768@psf.upfronthosting.co.za> New submission from Masayuki Yamamoto: Platform that appeared warning is Vista Cygwin x86. Interpreter execution doesn't crash because _setmode function is supplied from cygwin1.dll that always linked. Warning reason is header io.h [*] doesn't include to source file. Therefore I wrote two patches for 3.7 and 2.7. [*] https://msdn.microsoft.com/en-us/library/tw4k6df8.aspx (Cygwin also avaliable) build log on 3.7: gcc -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -I. -I./Include -DPy_BUILD_CORE -o Modules/main.o Modules/main.c Modules/main.c: In function 'Py_Main': Modules/main.c:599:5: warning: implicit declaration of function '_setmode' [-Wimplicit-function-declaration] _setmode(fileno(stdin), O_BINARY); ^ gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -I. -I./Include -DPy_BUILD_CORE -I./Modules/_io -c ./Modules/_io/fileio.c -o Modules/fileio.o ./Modules/_io/fileio.c: In function '_io_FileIO___init___impl': ./Modules/_io/fileio.c:478:5: warning: implicit declaration of function '_setmode' [-Wimplicit-function-declaration] _setmode(self->fd, O_BINARY); ^ ---------- components: Build files: include-io.h.patch keywords: patch messages: 281389 nosy: benjamin.peterson, masamoto, stutzbach priority: normal severity: normal status: open title: Warning: implicit declaration of function '_setmode' type: compile error versions: Python 2.7, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45592/include-io.h.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 15:00:58 2016 From: report at bugs.python.org (Masayuki Yamamoto) Date: Mon, 21 Nov 2016 20:00:58 +0000 Subject: [issue28768] Warning: implicit declaration of function '_setmode' In-Reply-To: <1479758430.88.0.97682867264.issue28768@psf.upfronthosting.co.za> Message-ID: <1479758458.02.0.80792187591.issue28768@psf.upfronthosting.co.za> Changes by Masayuki Yamamoto : Added file: http://bugs.python.org/file45593/2.7-include-io.h.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 15:22:43 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 21 Nov 2016 20:22:43 +0000 Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za> Message-ID: <1479759763.12.0.460216676263.issue28747@psf.upfronthosting.co.za> Steve Dower added the comment: For the sake of review, I fixed the patch and rebased it on default. ---------- Added file: http://bugs.python.org/file45594/28747_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 16:52:19 2016 From: report at bugs.python.org (Charalampos Stratakis) Date: Mon, 21 Nov 2016 21:52:19 +0000 Subject: [issue28689] OpenSSL 1.1.0c test failures In-Reply-To: <1479132647.76.0.450425015981.issue28689@psf.upfronthosting.co.za> Message-ID: <1479765139.81.0.506041042507.issue28689@psf.upfronthosting.co.za> Charalampos Stratakis added the comment: Fixed upstream: https://github.com/openssl/openssl/commit/beacb0f0c1ae7b0542fe053b95307f515b578eb7 ---------- nosy: +cstratak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 16:55:31 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 21 Nov 2016 21:55:31 +0000 Subject: [issue28532] Show sys.version when -V option is supplied twice. In-Reply-To: <1477417861.44.0.42778795289.issue28532@psf.upfronthosting.co.za> Message-ID: <1479765331.54.0.334299749282.issue28532@psf.upfronthosting.co.za> Martin Panter added the comment: The text looks okay. I?m not sure about putting it in the ?Porting to Python 3.6? section, but there doesn?t seem to be a more appropriate existing heading. Perhaps we need a new heading, say ?Other Improvement?, near ?Optimizations? and ?Build and C API Changes?. A previous What?s New had . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 17:11:28 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 21 Nov 2016 22:11:28 +0000 Subject: [issue28751] Fix comments in code.h In-Reply-To: <1479652195.59.0.115870067836.issue28751@psf.upfronthosting.co.za> Message-ID: <1479766288.69.0.696593440055.issue28751@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 17:23:46 2016 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 21 Nov 2016 22:23:46 +0000 Subject: [issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default. In-Reply-To: <1346610964.7.0.836759738208.issue15851@psf.upfronthosting.co.za> Message-ID: <1479767026.92.0.791111095679.issue15851@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 17:24:59 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 22:24:59 +0000 Subject: [issue28751] Fix comments in code.h In-Reply-To: <1479652195.59.0.115870067836.issue28751@psf.upfronthosting.co.za> Message-ID: <20161121222456.26332.58958.D41C63B0@psf.io> Roundup Robot added the comment: New changeset 88880a916174 by Raymond Hettinger in branch '3.6': Issue 28751: Fix comments in code.h. (Contributed by Ned Batchelder). https://hg.python.org/cpython/rev/88880a916174 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 17:25:36 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 21 Nov 2016 22:25:36 +0000 Subject: [issue28751] Fix comments in code.h In-Reply-To: <1479652195.59.0.115870067836.issue28751@psf.upfronthosting.co.za> Message-ID: <1479767136.4.0.217678978435.issue28751@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks Ned. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 17:25:50 2016 From: report at bugs.python.org (Ned Deily) Date: Mon, 21 Nov 2016 22:25:50 +0000 Subject: [issue28752] datetime object fails to restore from reduction In-Reply-To: <1479657323.42.0.875075153657.issue28752@psf.upfronthosting.co.za> Message-ID: <1479767150.79.0.606141336241.issue28752@psf.upfronthosting.co.za> Ned Deily added the comment: If you can push this in the next hour or two, it can still make b4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 17:28:02 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 21 Nov 2016 22:28:02 +0000 Subject: [issue28752] datetime object fails to restore from reduction In-Reply-To: <1479657323.42.0.875075153657.issue28752@psf.upfronthosting.co.za> Message-ID: <1479767282.97.0.587370519346.issue28752@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > If you can push this in the next hour or two ... I'll do it now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 17:30:46 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 22:30:46 +0000 Subject: [issue28752] datetime object fails to restore from reduction In-Reply-To: <1479657323.42.0.875075153657.issue28752@psf.upfronthosting.co.za> Message-ID: <20161121223043.33323.47338.8B0481E6@psf.io> Roundup Robot added the comment: New changeset 0a2a0061e425 by Serhiy Storchaka in branch '3.6': Issue #28752: Restored the __reduce__() methods of datetime objects. https://hg.python.org/cpython/rev/0a2a0061e425 New changeset 23140bd66d86 by Serhiy Storchaka in branch 'default': Issue #28752: Restored the __reduce__() methods of datetime objects. https://hg.python.org/cpython/rev/23140bd66d86 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 17:33:00 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Nov 2016 22:33:00 +0000 Subject: [issue27414] http.server.BaseHTTPRequestHandler inconsistence with Content-Length value In-Reply-To: <1467207276.94.0.887561217469.issue27414@psf.upfronthosting.co.za> Message-ID: <1479767580.71.0.481661725626.issue27414@psf.upfronthosting.co.za> STINNER Victor added the comment: issue27414.patch is not good: see my review. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 17:34:59 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 21 Nov 2016 22:34:59 +0000 Subject: [issue28752] datetime object fails to restore from reduction In-Reply-To: <1479657323.42.0.875075153657.issue28752@psf.upfronthosting.co.za> Message-ID: <1479767699.33.0.851367744023.issue28752@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: It looks like Serhiy has already committed it. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 17:35:00 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 22:35:00 +0000 Subject: [issue28475] Misleading error on random.sample when k < 0 In-Reply-To: <1476863008.28.0.194554202317.issue28475@psf.upfronthosting.co.za> Message-ID: <20161121223457.33611.76755.FF23C385@psf.io> Roundup Robot added the comment: New changeset 89f95c78e0ab by Raymond Hettinger in branch '3.6': Issue 28475: Improve error message for random.sample() with k < 0. (Contributed by Francisco Couzo). https://hg.python.org/cpython/rev/89f95c78e0ab ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 17:35:22 2016 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 21 Nov 2016 22:35:22 +0000 Subject: [issue28752] datetime object fails to restore from reduction In-Reply-To: <1479657323.42.0.875075153657.issue28752@psf.upfronthosting.co.za> Message-ID: <1479767722.51.0.482793234271.issue28752@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 17:37:21 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 21 Nov 2016 22:37:21 +0000 Subject: [issue28475] Misleading error on random.sample when k < 0 In-Reply-To: <1476863008.28.0.194554202317.issue28475@psf.upfronthosting.co.za> Message-ID: <1479767841.01.0.162045687705.issue28475@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks Franscisco. I ended-up not modifying the docs because I think it clutters that clarity with an irrelevant side issue. The more important part was to make sure the error message wasn't misleading and the test that edge case. I didn't backport to Python 2.7 because I don't think it meets the threshold of being interesting enough to warrant a backport to an old release. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 17:48:05 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 22:48:05 +0000 Subject: [issue28652] Make loop methods reject socket kinds they do not support. In-Reply-To: <1478724276.61.0.52953250975.issue28652@psf.upfronthosting.co.za> Message-ID: <20161121224801.33520.33368.517A5296@psf.io> Roundup Robot added the comment: New changeset 0ee76f3afd70 by Yury Selivanov in branch '3.5': Issue #28652: Partially rollback previous changes https://hg.python.org/cpython/rev/0ee76f3afd70 New changeset a40159071359 by Yury Selivanov in branch '3.6': Merge 3.5 (issue #28652) https://hg.python.org/cpython/rev/a40159071359 New changeset a759fcba1866 by Yury Selivanov in branch 'default': Merge 3.6 (issue #28652) https://hg.python.org/cpython/rev/a759fcba1866 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 18:13:47 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 23:13:47 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <20161121231344.33742.70973.D54D3A25@psf.io> Roundup Robot added the comment: New changeset 62c16fafa7d4 by Raymond Hettinger in branch '3.6': Issue 28587: list.index documentation missing start and stop arguments. (Contributed by Mariatta Wijaya.) https://hg.python.org/cpython/rev/62c16fafa7d4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 18:14:45 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 21 Nov 2016 23:14:45 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <1479770085.2.0.162481333555.issue28587@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Mariatta, thank you for the patch. And Chris, thanks for the observant bug report. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 18:21:46 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 21 Nov 2016 23:21:46 +0000 Subject: [issue28743] test_choices_algorithms() in test_random uses lots of memory In-Reply-To: <1479516464.04.0.874513077096.issue28743@psf.upfronthosting.co.za> Message-ID: <1479770506.78.0.583483386117.issue28743@psf.upfronthosting.co.za> Martin Panter added the comment: Gareth, are you sure that fixes the main memory problem? Did you see Serhiy?s cum_weights list? Looking at the code, a list of every number from one to 13 million will use more memory (to hold each unique integer) than the initial list of repeated ones. I think the problem may also be causing buildbot failures: Crash in test_random: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.x/builds/5373/steps/test/logs/stdio 0:19:42 [368/404] test_random crashed -- running: test_zipfile (48 sec), test_tools (139 sec) Traceback (most recent call last): [. . .] File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/runtest_mp.py", line 221, in run_tests_multiprocess raise Exception(msg) Exception: Child error on test_random: Exit code -9 Timeout in choices(): http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.x%20Shared%203.x/builds/5464/steps/test/logs/stdio 0:17:05 [215/404] test_random crashed Timeout (0:15:00)! Thread 0x0000000802006400 (most recent call first): File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_random.py", line 637 in test_choices_algorithms [. . .] Traceback (most recent call last): [. . .] File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest_mp.py", line 221, in run_tests_multiprocess raise Exception(msg) Exception: Child error on test_random: Exit code 1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 18:23:10 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 21 Nov 2016 23:23:10 +0000 Subject: [issue28743] test_choices_algorithms() in test_random uses lots of memory In-Reply-To: <1479516464.04.0.874513077096.issue28743@psf.upfronthosting.co.za> Message-ID: <1479770590.66.0.0750037220032.issue28743@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 18:32:35 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Nov 2016 23:32:35 +0000 Subject: [issue28743] test_choices_algorithms() in test_random uses lots of memory In-Reply-To: <1479516464.04.0.874513077096.issue28743@psf.upfronthosting.co.za> Message-ID: <20161121233231.33323.73614.F7565CAD@psf.io> Roundup Robot added the comment: New changeset 3551fca2c6ae by Raymond Hettinger in branch '3.6': Issue #28743: Reduce memory consumption for random module tests https://hg.python.org/cpython/rev/3551fca2c6ae ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 18:34:44 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 21 Nov 2016 23:34:44 +0000 Subject: [issue28743] test_choices_algorithms() in test_random uses lots of memory In-Reply-To: <1479516464.04.0.874513077096.issue28743@psf.upfronthosting.co.za> Message-ID: <1479771284.82.0.288360280639.issue28743@psf.upfronthosting.co.za> Raymond Hettinger added the comment: A smaller value suffices for this test. It was trying to make sure the underlying algorithms are as in-sync as possible without going to extremes. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 18:36:24 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 21 Nov 2016 23:36:24 +0000 Subject: [issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default. In-Reply-To: <1346610964.7.0.836759738208.issue15851@psf.upfronthosting.co.za> Message-ID: <1479771384.15.0.222693153059.issue15851@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 18:41:24 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 21 Nov 2016 23:41:24 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <1479771684.45.0.378504123862.issue28587@psf.upfronthosting.co.za> Martin Panter added the comment: The committed change looks wrong in the new example. I think Mariatta?s patch was right; it the index found is 3, not 2: >>> a [66.25, 333, -1, 333, 1, 1234.5, 333] >>> a.index(333) 1 >>> a.index(333, 2) # search for 333 starting at index 2 3 ---------- nosy: +martin.panter status: closed -> open versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 18:52:01 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Mon, 21 Nov 2016 23:52:01 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <1479772321.89.0.881601094544.issue28587@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks, Raymond and Martin :) Not sure what the procedure is for fixing this. Do I upload another patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 18:53:26 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 21 Nov 2016 23:53:26 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <1479772406.04.0.480427888399.issue28587@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks for noticing. I tested against the original list rather than the subsequently modified version. I'm starting to think that this whole example section is annoyingly hard to follow and uninformative. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 19:05:47 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Nov 2016 00:05:47 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <1479773147.86.0.865040902004.issue28587@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Attaching an improved list example: * Replaced abstract and hard to follow numerical example with fruits * Demonstrate the non-mutating methods first ---------- Added file: http://bugs.python.org/file45595/new_list_example.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 19:14:42 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 22 Nov 2016 00:14:42 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <1479773682.85.0.586200926692.issue28587@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks Raymond. The new set of examples is much better than the previous one. +1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 19:31:32 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Nov 2016 00:31:32 +0000 Subject: [issue28743] test_choices_algorithms() in test_random uses lots of memory In-Reply-To: <1479516464.04.0.874513077096.issue28743@psf.upfronthosting.co.za> Message-ID: <1479774692.53.0.571363041544.issue28743@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks Raymond, now the test is noticeably faster and fine with my memory situation :) ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 19:32:06 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Nov 2016 00:32:06 +0000 Subject: [issue27825] Make the documentation for statistics' data argument clearer. In-Reply-To: <1471813007.76.0.49945343113.issue27825@psf.upfronthosting.co.za> Message-ID: <20161122003202.130879.40570.6E7597AE@psf.io> Roundup Robot added the comment: New changeset 71dd21a3b9cc by Raymond Hettinger in branch '3.6': Issue #27825: Improve for statistics data arguments. (Contributed by Mariatta Wijaya.) https://hg.python.org/cpython/rev/71dd21a3b9cc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 19:32:06 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Nov 2016 00:32:06 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <20161122003203.130879.41333.C560A0AE@psf.io> Roundup Robot added the comment: New changeset efac7ac53933 by Raymond Hettinger in branch '3.6': Issue #28587: Improve list examples in the tutorial https://hg.python.org/cpython/rev/efac7ac53933 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 19:32:58 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Nov 2016 00:32:58 +0000 Subject: [issue27825] Make the documentation for statistics' data argument clearer. In-Reply-To: <1471813007.76.0.49945343113.issue27825@psf.upfronthosting.co.za> Message-ID: <1479774778.86.0.498788328155.issue27825@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks Mariatta. As discussed in chat, I dropped the extra fractions examples because they didn't seem to add value. ---------- nosy: +rhettinger resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 19:33:28 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Nov 2016 00:33:28 +0000 Subject: [issue28587] list.index documentation missing start and stop arguments In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za> Message-ID: <1479774808.06.0.679828714369.issue28587@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Okay, applied. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 19:33:51 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 22 Nov 2016 00:33:51 +0000 Subject: [issue27825] Make the documentation for statistics' data argument clearer. In-Reply-To: <1471813007.76.0.49945343113.issue27825@psf.upfronthosting.co.za> Message-ID: <1479774831.19.0.357809218644.issue27825@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Sounds good. Thanks, Raymond :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 19:48:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Nov 2016 00:48:33 +0000 Subject: [issue5830] heapq item comparison problematic with sched's events In-Reply-To: <1240580106.04.0.721938894312.issue5830@psf.upfronthosting.co.za> Message-ID: <20161122004830.33742.69948.46BC41D6@psf.io> Roundup Robot added the comment: New changeset ecc6f7940e02 by Raymond Hettinger in branch '3.6': Issue #5830: Add test for ee476248a74a. (Contributed by Serhiy Storchaka.) https://hg.python.org/cpython/rev/ecc6f7940e02 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 19:49:39 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Nov 2016 00:49:39 +0000 Subject: [issue5830] heapq item comparison problematic with sched's events In-Reply-To: <1240580106.04.0.721938894312.issue5830@psf.upfronthosting.co.za> Message-ID: <1479775779.19.0.356797206362.issue5830@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks Serhiy. FWIW, I changed the variable name from "l" to "seq" for readability. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 19:53:42 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Nov 2016 00:53:42 +0000 Subject: [issue28763] Use en-dashes for ranges in docs In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za> Message-ID: <1479776022.17.0.638545730369.issue28763@psf.upfronthosting.co.za> Martin Panter added the comment: Personally I prefer en dashes where practical, but I fear the change may conflict with other people?s styles and preferences. I quickly counted 22 single hyphens (obviously I missed a few that your patch caught) and also 22 existing en dashes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 19:54:51 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Nov 2016 00:54:51 +0000 Subject: [issue26163] FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet) In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za> Message-ID: <1479776091.7.0.941760050443.issue26163@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Rather than making futile further attempts to scramble the bits in the final hash to hide the effect of weak upstream hash inputs, I'm inclined to disable this particular test which was already a crazily harsh torture test. I suspect that even the tuple hash wouldn't survive variants of this test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 19:59:40 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Nov 2016 00:59:40 +0000 Subject: [issue26163] FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet) In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za> Message-ID: <20161122005935.33458.28092.2BD4901A@psf.io> Roundup Robot added the comment: New changeset e0f0211d314d by Raymond Hettinger in branch '3.6': Issue #26163: Disable periodically failing test which was overly demanding of the frozenset hash function effectiveness https://hg.python.org/cpython/rev/e0f0211d314d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 20:00:06 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Nov 2016 01:00:06 +0000 Subject: [issue26163] FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet) In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za> Message-ID: <1479776406.24.0.197363363166.issue26163@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 20:00:20 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Nov 2016 01:00:20 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings In-Reply-To: <1479128206.47.0.155651436814.issue28688@psf.upfronthosting.co.za> Message-ID: <1479776420.2.0.758218535429.issue28688@psf.upfronthosting.co.za> Martin Panter added the comment: As long as we are restricted by backwards compatibility, it will be hard to find a hack-free solution. The ideal solution IMO is to re-create _warnings.filters from scratch when _warnings is reloaded, but such a change would be safer only for 3.7. So I am happy to leave things as they are. At least until something upsets things again :) ---------- resolution: -> out of date stage: -> resolved status: open -> closed superseder: -> Warning -- warnings.filters was modified by test_warnings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 20:00:50 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Nov 2016 01:00:50 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings In-Reply-To: <1479128206.47.0.155651436814.issue28688@psf.upfronthosting.co.za> Message-ID: <1479776450.49.0.346966525572.issue28688@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- superseder: Warning -- warnings.filters was modified by test_warnings -> Implement comparison (x==y and x!=y) for _sre.SRE_Pattern _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 20:12:16 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Nov 2016 01:12:16 +0000 Subject: [issue28766] Remove the semicolon in source code In-Reply-To: <1479746139.91.0.549636125293.issue28766@psf.upfronthosting.co.za> Message-ID: <1479777136.46.0.777270430848.issue28766@psf.upfronthosting.co.za> Martin Panter added the comment: This was added to 2.7 in r68532 (Issue 4879), but the semicolon never made it to the Python 3 branch that I can see, so I don?t think there is anything to fix there. Your patch is against the 2.7 branch, which is only open for bug fixes now, and I don?t think this qualifies, sorry :) ---------- nosy: +martin.panter resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 20:25:17 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Nov 2016 01:25:17 +0000 Subject: [issue27100] Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za> Message-ID: <20161122012504.33236.24107.4BF1C6C6@psf.io> Roundup Robot added the comment: New changeset 3aafb232f2db by Raymond Hettinger in branch '3.6': Issue #27100: With statement reports missing __enter__ before __exit__. (Contributed by Jonathan Ellington.) https://hg.python.org/cpython/rev/3aafb232f2db ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 20:26:13 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Nov 2016 01:26:13 +0000 Subject: [issue27100] Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za> Message-ID: <1479777973.93.0.90112386952.issue27100@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks for the patch Jonathan. Nick, thanks for chiming in. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 20:30:01 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Nov 2016 01:30:01 +0000 Subject: [issue23106] Remove smalltable from set objects In-Reply-To: <1419378045.35.0.931278321867.issue23106@psf.upfronthosting.co.za> Message-ID: <1479778201.8.0.0397561490022.issue23106@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Based on the performance hit, I am retracting this. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 20:39:22 2016 From: report at bugs.python.org (Eryk Sun) Date: Tue, 22 Nov 2016 01:39:22 +0000 Subject: [issue28738] Document SIGBREAK as argument for signal() under Windows. In-Reply-To: <1479497916.69.0.534558560438.issue28738@psf.upfronthosting.co.za> Message-ID: <1479778762.43.0.401895508979.issue28738@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- keywords: +easy priority: normal -> low stage: -> patch review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 21:10:44 2016 From: report at bugs.python.org (Greg Ward) Date: Tue, 22 Nov 2016 02:10:44 +0000 Subject: [issue28702] Confusing error message when None used in expressions, eg. "'NoneType' object has no attribute 'foo'" In-Reply-To: <1479240283.12.0.750407106609.issue28702@psf.upfronthosting.co.za> Message-ID: <1479780644.53.0.524928539782.issue28702@psf.upfronthosting.co.za> Greg Ward added the comment: > Is it worth changing about 800 places in CPython code? Not counting third-party code. Definitely not. My aim is not to fix every possible reference to "instance of 'NoneType'", just the handful of cases that are most frequently encountered, especially if we think they are likely to be confusing to beginners. That's why I've only modified getting and setting attributes so far; I wanted to see what the cost/benefit is like. Renaming 'NoneType' to 'None' sounds like a much easier approach, if it works. But then saying "instance of" + tp_name comes out weird. "Instance of NoneType" is confusing if technically accurate; "instance of None" is both confusing and technically inaccurate. Hmmmm. Still mulling. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 21:15:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 02:15:07 +0000 Subject: [issue28763] Use en-dashes for ranges in docs In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za> Message-ID: <1479780907.09.0.831054566593.issue28763@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The rest single hyphens between digits are meaningful hypens in iso-8859-1, ISDNs, sample outputs, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 21:32:08 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Nov 2016 02:32:08 +0000 Subject: [issue28763] Use en-dashes for ranges in docs In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za> Message-ID: <1479781928.86.0.300867611395.issue28763@psf.upfronthosting.co.za> Martin Panter added the comment: Sure, I was just saying that for whatever reason, 50% of the documentation uses hyphens for number ranges, and 50% uses en dashes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 21 23:55:37 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 22 Nov 2016 04:55:37 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1479790537.79.0.0530221421763.issue28635@psf.upfronthosting.co.za> INADA Naoki added the comment: I added ``-VV`` option to python command (issue28532). Which section should I add the entry about it? ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 00:24:55 2016 From: report at bugs.python.org (Yuwei Ba) Date: Tue, 22 Nov 2016 05:24:55 +0000 Subject: [issue28766] Remove the semicolon in source code In-Reply-To: <1479746139.91.0.549636125293.issue28766@psf.upfronthosting.co.za> Message-ID: <1479792295.77.0.316946278776.issue28766@psf.upfronthosting.co.za> Yuwei Ba added the comment: I know this is not a functional 'fix', though it's the fact that there should not be a semicolon. It can make user confusing. There might be another user who found this semicolon and create an issue again since there are still lots of Python27 codes running on tons of machines. So if possible, I'll persist on this patch to be applied. Though it's not so urgent, it's a right thing. ;) ---------- resolution: rejected -> not a bug status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 00:58:45 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Nov 2016 05:58:45 +0000 Subject: [issue28761] Add the const qualifier to fields name and doc of public structs In-Reply-To: <1479721215.94.0.926847146167.issue28761@psf.upfronthosting.co.za> Message-ID: <20161122055842.33552.64399.DF3275ED@psf.io> Roundup Robot added the comment: New changeset 42b0ba372ec2 by Serhiy Storchaka in branch 'default': Issue #28761: The fields name and doc of structures PyMemberDef, PyGetSetDef, https://hg.python.org/cpython/rev/42b0ba372ec2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 01:02:40 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 06:02:40 +0000 Subject: [issue5830] heapq item comparison problematic with sched's events In-Reply-To: <1240580106.04.0.721938894312.issue5830@psf.upfronthosting.co.za> Message-ID: <1479794560.58.0.298500688016.issue5830@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Agreed, "seq" is better name. Thanks Raymond. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 01:02:53 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 06:02:53 +0000 Subject: [issue5830] heapq item comparison problematic with sched's events In-Reply-To: <1240580106.04.0.721938894312.issue5830@psf.upfronthosting.co.za> Message-ID: <1479794573.32.0.964716535306.issue5830@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 01:03:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 06:03:58 +0000 Subject: [issue28761] Add the const qualifier to fields name and doc of public structs In-Reply-To: <1479721215.94.0.926847146167.issue28761@psf.upfronthosting.co.za> Message-ID: <1479794638.92.0.272244070237.issue28761@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Nick. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 01:04:38 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 06:04:38 +0000 Subject: [issue28761] Add the const qualifier to fields name and doc of public structs In-Reply-To: <1479721215.94.0.926847146167.issue28761@psf.upfronthosting.co.za> Message-ID: <1479794678.28.0.191199072442.issue28761@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 01:07:42 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 22 Nov 2016 06:07:42 +0000 Subject: [issue28573] Python 3.6.0b4 64-bit has no sys._mercurial info In-Reply-To: <1477975263.28.0.609263953959.issue28573@psf.upfronthosting.co.za> Message-ID: <1479794862.47.0.447480313798.issue28573@psf.upfronthosting.co.za> Steve Dower added the comment: Wasn't fixed as well as I'd like, so I clearly need a better approach here. ---------- resolution: fixed -> stage: resolved -> status: closed -> open title: Python 3.6.0b3 64-bit has no sys._mercurial info -> Python 3.6.0b4 64-bit has no sys._mercurial info _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 02:01:18 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Nov 2016 07:01:18 +0000 Subject: [issue28766] Remove the semicolon in source code In-Reply-To: <1479746139.91.0.549636125293.issue28766@psf.upfronthosting.co.za> Message-ID: <1479798078.79.0.735894842883.issue28766@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry Yuwei, but this is irrelevant and not appropriate for a Python 2.7 backport at this time. ---------- nosy: +rhettinger status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 02:55:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 07:55:24 +0000 Subject: [issue28769] Make PyUnicode_AsUTF8 returning "const char *" rather of "char *" Message-ID: <1479801324.65.0.962202188144.issue28769@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: PyUnicode_AsUTF8AndSize() and PyUnicode_AsUTF8() return a reference to cached readonly UTF-8 representation of a string. Changing the content of the UTF-8 representation is an error. Proposed patch makes these functions returning "const char *" rather of "char *" to force this restriction. This is backward-incompatible change. Since PyUnicode_AsUTF8AndSize() and PyUnicode_AsUTF8() can return an error, it is more likely that the result is saved in a local variable rather than passing to other function. If the type of this variable is "char *" rather than "const char *", this would cause a compiler error. The fix is simple -- just add the const qualifier to the local variable declaration (more preferable) or cast the result of PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8() to "char *". Both functions are not in stable API. ---------- components: Interpreter Core files: PyUnicode_AsUTF8-const.patch keywords: patch messages: 281439 nosy: ncoghlan, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Make PyUnicode_AsUTF8 returning "const char *" rather of "char *" type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45596/PyUnicode_AsUTF8-const.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 03:00:05 2016 From: report at bugs.python.org (Yuwei Ba) Date: Tue, 22 Nov 2016 08:00:05 +0000 Subject: [issue28766] Remove the semicolon in source code In-Reply-To: <1479746139.91.0.549636125293.issue28766@psf.upfronthosting.co.za> Message-ID: <1479801605.44.0.21679549694.issue28766@psf.upfronthosting.co.za> Yuwei Ba added the comment: Okay. Thanks you two fellows! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 03:09:21 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 22 Nov 2016 08:09:21 +0000 Subject: [issue27414] http.server.BaseHTTPRequestHandler inconsistence with Content-Length value In-Reply-To: <1467207276.94.0.887561217469.issue27414@psf.upfronthosting.co.za> Message-ID: <1479802161.66.0.224380523811.issue27414@psf.upfronthosting.co.za> Xiang Zhang added the comment: v2 applies the suggestions. ---------- priority: low -> normal versions: +Python 3.7 Added file: http://bugs.python.org/file45597/issue27414_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 03:10:17 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 22 Nov 2016 08:10:17 +0000 Subject: [issue28766] Remove the semicolon in source code In-Reply-To: <1479746139.91.0.549636125293.issue28766@psf.upfronthosting.co.za> Message-ID: <1479802217.13.0.330449100825.issue28766@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 03:31:36 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 08:31:36 +0000 Subject: [issue27414] http.server.BaseHTTPRequestHandler inconsistence with Content-Length value In-Reply-To: <1467207276.94.0.887561217469.issue27414@psf.upfronthosting.co.za> Message-ID: <1479803496.88.0.411993606581.issue27414@psf.upfronthosting.co.za> STINNER Victor added the comment: Mathieu: "For consistency, all header values should be str." Xiang: issue27414_v2.patch: Doc/library/http.server.rst "*keyword* and *value* should both be :class:`str`." I'm sorry, but I don't understand the whole point of this issue. The current code works, I don't see any good reason to change it. The unit test is a little bit complex for a little tiny implementation detail. Usually, we try to avoid unit tests on implementation details in the Python test suite. It's perfectly fine to pass an integer to an HTTP value, it's just super convenient. I checked the HTTP client: the type of the 'argument' parameter of putheader() is not documented neither, so I think that it's just fine to leave the doc unchanged. I close now this issue NOTABUG. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 03:43:07 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 08:43:07 +0000 Subject: [issue27414] http.server.BaseHTTPRequestHandler inconsistence with Content-Length value In-Reply-To: <1479803496.88.0.411993606581.issue27414@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Ah, on IRC Xiang told me that send_header("Connection", 1) raises an error. Right, *this* specific case raises an error. But I don't think that it's worth to require text for HTTP header values. If you consider that it's a shame, Python should handle this corner case (sorry, what is use case for "Connection: 1" ? :-D), please open a new issue. If you consider that the doc the HTTP server must be more explicit on the accepted types, please mention that integers are accepted for values, not only text. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 03:47:16 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 08:47:16 +0000 Subject: [issue28688] Warning -- warnings.filters was modified by test_warnings In-Reply-To: <1479776450.52.0.0197677353587.issue28688@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I'm ok to close this bug :-) > As long as we are restricted by backwards compatibility, it will be hard to find a hack-free solution. The ideal solution IMO is to re-create _warnings.filters from scratch when _warnings is reloaded, but such a change would be safer only for 3.7. Currently it's not possible to "reload" the _warnings module since it doesn't use the "module state" API. I don't see how you want to trigger an action in the _warnings module itself when it is "reloaded". Filteres are used internally in the _warnings C module. Maybe we need to enhance the _warnings C module to use the "module state" API? (Is it the PEP 489?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 03:49:22 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Nov 2016 08:49:22 +0000 Subject: [issue28769] Make PyUnicode_AsUTF8 returning "const char *" rather of "char *" In-Reply-To: <1479801324.65.0.962202188144.issue28769@psf.upfronthosting.co.za> Message-ID: <1479804562.65.0.170413000876.issue28769@psf.upfronthosting.co.za> Martin Panter added the comment: No opinion if this is a good change to make, but I left some review suggestions ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 03:56:36 2016 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 22 Nov 2016 08:56:36 +0000 Subject: [issue28763] Use en-dashes for ranges in docs In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za> Message-ID: <1479804996.38.0.232723859286.issue28763@psf.upfronthosting.co.za> Mark Dickinson added the comment: > It is recommended to use an em-dash instead of a hyphen for numerical ranges. Who makes that recommendation? Did you mean en-dash rather than em-dash? ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 03:59:10 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 08:59:10 +0000 Subject: [issue28769] Make PyUnicode_AsUTF8 returning "const char *" rather of "char *" In-Reply-To: <1479801324.65.0.962202188144.issue28769@psf.upfronthosting.co.za> Message-ID: <1479805150.62.0.0784859626331.issue28769@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, I would like to discuss this topic on python-dev. Changing PyUnicode_AsUTF8() alone is fine, but the issue with changing return type is that the const has to be propagated to callers, and then to callers of callers, etc. For example, if your patch, you cast (const char*) to (char*) to call tp_getattr. The question is why tp_getattr doesn't use (const char*)? I would prefer to take an overall decision for the C API, to decide if it's ok to "propagate" const changes in various places of the C API. About the stable API: in fact, it's more a stable *ABI*: PEP 384, "Defining a Stable ABI". At the ABI level, there is no more "const". So it's perfectly fine to add or remove const, we already did that in the past. Obviously, such change should only be done in Python 3.7. For me, the main issue is for Python modules compiled with -Werror: if they upgrade to Python 3.7, the compilation will fail because they cast (const char*) to (char*) implicitly, which is a warning when using -Wall -Wextra, warning converted to a compilation error. That's why I suggest to have an overall discussion on const on python-dev ;-) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 04:04:14 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 09:04:14 +0000 Subject: [issue28769] Make PyUnicode_AsUTF8 returning "const char *" rather of "char *" In-Reply-To: <1479801324.65.0.962202188144.issue28769@psf.upfronthosting.co.za> Message-ID: <1479805454.14.0.346654880765.issue28769@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, sorry, my opinion on const is not obvious in my previous message: I like const :-) I want to use const everywhere! I still "believe" (I don't know if it's true or not) that const helps a lot compilers to optimize the code. I don't know if it helps for a single variable. Maybe it's more helpful on a whole structure and/or pointers to avoid complex heuristics on aliasing. My first attempt to design the _PyBytesWriter API was a big mistake: it was much slower: issue #17742. I understood that using a structure instead of multiple variables does stress the compiler who doesn't know if some optimizations are still save. In case of doubt, the compiler doesn't optimize to avoid generating invalid code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 04:06:19 2016 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 22 Nov 2016 09:06:19 +0000 Subject: [issue28763] Use en-dashes for ranges in docs In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za> Message-ID: <1479805579.52.0.626068298435.issue28763@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Did you mean en-dash rather than em-dash? Ah, judging by the title and the patch, you did. :-) Phew! Now I can delete the long post I had citing multiple sources for using en-dashes (not em-dashes) for numeric ranges... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 04:08:29 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Nov 2016 09:08:29 +0000 Subject: [issue28763] Use en-dashes for ranges in docs In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za> Message-ID: <1479805709.65.0.971360449545.issue28763@psf.upfronthosting.co.za> Martin Panter added the comment: My Australian Style Manual says to use en rules for spans of figures etc. Wikipedia mentions some other guides: ; apparently some prefer the hyphen. That is why I said it is a style issue, not a black and white thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 04:16:45 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 09:16:45 +0000 Subject: [issue28763] Use en-dashes for ranges in docs In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za> Message-ID: <1479806205.56.0.904527261657.issue28763@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, yes, I meant en-dashes of course. I read this recommendation in many books about TeX, and also in other typographic resources. In modern fonts a hyphen-minus (U+002D) is shorter than digits in modern fonts and is placed lower than the middle of digits. An en-dash (U+2013) has the same width as digits and is placed higher, at the middle of digit's height. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 04:26:08 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 09:26:08 +0000 Subject: [issue28004] Optimize bytes.join(sequence) In-Reply-To: <1473272106.7.0.875359968235.issue28004@psf.upfronthosting.co.za> Message-ID: <1479806768.59.0.971307466291.issue28004@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I agree that it's not worth it to optimize bytes.join(list of byte strings). Code is already fast enough. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 04:27:43 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 09:27:43 +0000 Subject: [issue28023] python-gdb.py must be updated for the new Python 3.6 compact dict In-Reply-To: <1473351940.28.0.277088210884.issue28023@psf.upfronthosting.co.za> Message-ID: <1479806863.04.0.940876502501.issue28023@psf.upfronthosting.co.za> STINNER Victor added the comment: dict_gdb2.patch LGTM. Can you please follow Ned's instructions to get this change merged into 3.6 final? python-gdb.py is an important tool and it's completly broken. The patch cannot make python-gdb.py worse :-D (More seriously, it fixes python-gdb.py.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 04:28:13 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Nov 2016 09:28:13 +0000 Subject: [issue27100] Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za> Message-ID: <1479806893.96.0.329141801257.issue27100@psf.upfronthosting.co.za> Martin Panter added the comment: https://mail.python.org/pipermail/python-checkins/2016-November/147171.html test_collections leaked [0, 0, 7] memory blocks, sum=7 test_contextlib leaked [38, 38, 38] references, sum=114 test_contextlib leaked [13, 12, 12] memory blocks, sum=37 test_descr leaked [164, 164, 164] references, sum=492 test_descr leaked [59, 59, 59] memory blocks, sum=177 test_functools leaked [0, 3, 1] memory blocks, sum=4 test_with leaked [37, 37, 37] references, sum=111 test_with leaked [13, 13, 13] memory blocks, sum=39 Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R', '3:3:/home/psf-users/antoine/refleaks/reflogWMjqsJ', '--timeout', '7200'] Looking at the code change, it looks like you aren?t releasing __enter__ if the __exit__ lookup fails. A separate question: why not swap the ?async with? __aenter__ and __aexit__ code at the same time? ---------- nosy: +martin.panter status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 04:31:42 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Nov 2016 09:31:42 +0000 Subject: [issue27100] Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za> Message-ID: <1479807102.95.0.845493468787.issue27100@psf.upfronthosting.co.za> Martin Panter added the comment: Hmm, it seems I already discovered this leak six months ago: https://bugs.python.org/review/27100 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 04:32:17 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 09:32:17 +0000 Subject: [issue26530] tracemalloc: add C API to manually track/untrack memory allocations In-Reply-To: <1457619430.68.0.0968942184372.issue26530@psf.upfronthosting.co.za> Message-ID: <1479807137.4.0.57631751637.issue26530@psf.upfronthosting.co.za> STINNER Victor added the comment: So, the API is implemented, but I leave it as private because nobody tried it whereas I was waiting for a feedback from numpy at least. If you want a public API in Python 3.7, please tell if the API fits your use case and if the implementation works. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 04:42:50 2016 From: report at bugs.python.org (Jan-Philip Gehrcke) Date: Tue, 22 Nov 2016 09:42:50 +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: <1479807769.98.0.998647222888.issue16487@psf.upfronthosting.co.za> Jan-Philip Gehrcke added the comment: Christian, Senthil, would appreciate if I got another round of feedback (in the review thread) :-) ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 05:16:14 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Nov 2016 10:16:14 +0000 Subject: [issue4347] Circular dependency causes SystemError when adding new syntax In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za> Message-ID: <1479809774.47.0.111084155415.issue4347@psf.upfronthosting.co.za> Martin Panter added the comment: I?m not sure I understand your questions Brett (Which tokenizer? What rebuilding?), but I will try to explain some relevant parts. My main goal is to add a makefile dependency of parsetok.o on $(GRAMMAR_H). In Python 3, that is easy, and (I realize now) my problem would be solved without changing any other file. However my changes in parsetok.c eliminate an unnecessary bootstrapping problem, so I still think they are worthwhile. For Python 3, the parsetok.c code gets compiled to parsetok_pgen.o, and after executing, also gets compiled to a separate parsetok.o file. Rebuilding the code is not a problem here. In Python 2, the same parsetok.o object is both part of the pgen program, and the eventual Python program. In order to add my desired makefile dependency, I have to duplicate parsetok.c compilation into two makefile rules (parsetok.o and parsetok_pgen.o). So you could say I am breaking a circle _by_ rebuilding the code. Dependencies between files with my patch applied: Parser/parsetok_pgen.o -> Parser/pgen -> Include/graminit.h -> Parser/parsetok.o -> python ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 05:30:20 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 10:30:20 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1479810620.01.0.176864829236.issue28618@psf.upfronthosting.co.za> STINNER Victor added the comment: FYI I wrote an article about this issue: https://haypo.github.io/analysis-python-performance-issue.html Sadly, it seems like I was just lucky when adding __attribute__((hot)) fixed the issue, because call_method is slow again! * acde821520fc (Nov 21): 16.3 ms * 2a14385710dc (Nov 22): 24.6 ms (+51%) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 05:33:02 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 22 Nov 2016 10:33:02 +0000 Subject: [issue28023] python-gdb.py must be updated for the new Python 3.6 compact dict In-Reply-To: <1473351940.28.0.277088210884.issue28023@psf.upfronthosting.co.za> Message-ID: <1479810782.81.0.952805095384.issue28023@psf.upfronthosting.co.za> INADA Naoki added the comment: https://mail.python.org/pipermail/python-committers/2016-November/004065.html > The 3.6 branch in the cpython repo is now available again but, as noted, *only* for reviewed release critical fixes appropriate for the 3.6.0 final and for final 3.6.0 doc updates! So now I think I can commit this for now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 05:42:55 2016 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 22 Nov 2016 10:42:55 +0000 Subject: [issue28763] Use en-dashes for ranges in docs In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za> Message-ID: <1479811375.63.0.389016133552.issue28763@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I read this recommendation in many books about TeX, and also in other typographic resources. Same here. I'd add Apple's Style Guide and the Chicago Manual of Style to that list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 05:44:01 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Nov 2016 10:44:01 +0000 Subject: [issue28023] python-gdb.py must be updated for the new Python 3.6 compact dict In-Reply-To: <1473351940.28.0.277088210884.issue28023@psf.upfronthosting.co.za> Message-ID: <20161122104357.113713.49638.5DE826A3@psf.io> Roundup Robot added the comment: New changeset 4f6fb9e47f6b by INADA Naoki in branch '3.6': Issue #28023: Fix python-gdb.py didn't support new dict implementation https://hg.python.org/cpython/rev/4f6fb9e47f6b New changeset c51045920410 by INADA Naoki in branch 'default': Issue #28023: Fix python-gdb.py didn't support new dict implementation https://hg.python.org/cpython/rev/c51045920410 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 05:44:24 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 22 Nov 2016 10:44:24 +0000 Subject: [issue28023] python-gdb.py must be updated for the new Python 3.6 compact dict In-Reply-To: <1473351940.28.0.277088210884.issue28023@psf.upfronthosting.co.za> Message-ID: <1479811464.88.0.043959588172.issue28023@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 06:07:14 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 22 Nov 2016 11:07:14 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1479812834.97.0.983006488772.issue28618@psf.upfronthosting.co.za> INADA Naoki added the comment: Wow. It's sad that tagged version is accidentally slow... I want to reproduce it and check `perf record -e L1-icache-load-misses`. But IaaS (EC2, GCE, Azure VM) doesn't support CPU performance counter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 06:38:09 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 11:38:09 +0000 Subject: [issue28023] python-gdb.py must be updated for the new Python 3.6 compact dict In-Reply-To: <1473351940.28.0.277088210884.issue28023@psf.upfronthosting.co.za> Message-ID: <1479814689.14.0.993448987796.issue28023@psf.upfronthosting.co.za> STINNER Victor added the comment: test_gdb failed on a lot of buildbots. Examples: * http://buildbot.python.org/all/builders/PPC64%20Fedora%203.x/builds/2089 * http://buildbot.python.org/all/builders/AMD64%20Debian%20PGO%203.6/builds/330 * http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%20with%20X%203.6/builds/287 Extract of the Gentoo non-debug: (...) GNU gdb (Gentoo 7.10.1 vanilla) 7.10.1 (...) ====================================================================== FAIL: test_NULL_ob_type (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with NULL ob_type is handled gracefully ---------------------------------------------------------------------- Traceback (most recent call last): File "/buildbot/buildarea/3.6.ware-gentoo-x86.nondebug/build/Lib/test/test_gdb.py", line 490, in test_NULL_ob_type 'set v->ob_type=0') File "/buildbot/buildarea/3.6.ware-gentoo-x86.nondebug/build/Lib/test/test_gdb.py", line 461, in assertSane cmds_after_breakpoint=cmds_after_breakpoint) File "/buildbot/buildarea/3.6.ware-gentoo-x86.nondebug/build/Lib/test/test_gdb.py", line 240, in get_gdb_repr import_site=import_site) File "/buildbot/buildarea/3.6.ware-gentoo-x86.nondebug/build/Lib/test/test_gdb.py", line 218, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ["Python Exception Can[663 chars].: "] != [] First list contains 10 additional elements. First extra element 0: "Python Exception Cannot convert value to int.: " Diff is 745 characters long. Set self.maxDiff to None to see it. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 06:42:55 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 11:42:55 +0000 Subject: [issue28770] Update python-gdb.py for fastcalls Message-ID: <1479814975.16.0.381517171433.issue28770@psf.upfronthosting.co.za> New submission from STINNER Victor: Python 3.6 has a new C calling convention: "fast calls". python-gdb.py was disabled when compact dict was merged, see issue #27350. Sadly, I missed that fast calls also broke python-gdb.py. Attached patch fixes python-gdb.py, but I failed to fix test_gdb.py. With fast calls and patched python-gdb.py, python-gdb.py is now able to detect the Python frame of the call to the builtin id() function. It's a new feature compared to Python 3.5, but test_gdb.py should be updated to handle that. I will try to fix that later, but in the meanwhile I was interrupted because the fix for compact dict in python-gdb.py failed on buildbots, see: http://bugs.python.org/issue28023#msg281464 ---------- files: gdb_fastcall.patch keywords: patch messages: 281465 nosy: haypo priority: normal severity: normal status: open title: Update python-gdb.py for fastcalls versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45598/gdb_fastcall.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 06:43:14 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 11:43:14 +0000 Subject: [issue28770] Update python-gdb.py for fastcalls In-Reply-To: <1479814975.16.0.381517171433.issue28770@psf.upfronthosting.co.za> Message-ID: <1479814994.69.0.180616957993.issue28770@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 06:44:51 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 11:44:51 +0000 Subject: [issue28770] Update python-gdb.py for fastcalls In-Reply-To: <1479814975.16.0.381517171433.issue28770@psf.upfronthosting.co.za> Message-ID: <1479815091.24.0.937131816587.issue28770@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file45599/gdb_fastcall-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 06:47:12 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 11:47:12 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1479812834.97.0.983006488772.issue28618@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: 2016-11-22 12:07 GMT+01:00 INADA Naoki : > I want to reproduce it and check `perf record -e L1-icache-load-misses`. > But IaaS (EC2, GCE, Azure VM) doesn't support CPU performance counter. You don't need to go that far to check performances: just run call_method and check timings. You need to compare on multiple revisions. speed.python.org Timeline helps to track performances, to have an idea of the "average performance" and detect spikes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 06:50:54 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 11:50:54 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: Message-ID: STINNER Victor added the comment: Naoki: "Wow. It's sad that tagged version is accidentally slow..." If you use PGO compilation, for example use "./configure --enable-optimizations" as suggested by configure if you don't enable the option, you don't get the issue. I hope that most Linux distribution use PGO compilation. I'm quite sure that it's the case for Ubuntu. I don't know for Fedora. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 06:53:08 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Nov 2016 11:53:08 +0000 Subject: [issue28771] Update documented signatures of tp_get/setattr Message-ID: <1479815588.93.0.810601241454.issue28771@psf.upfronthosting.co.za> New submission from Martin Panter: https://docs.python.org/3.7/c-api/typeobj.html#c.PyTypeObject.tp_getattr tp_getattr and tp_setattr take a non-const char pointer in their signatures, but the documentation points to PyObject_GetAttrString() etc which were changed to take const char pointers a long time ago: revision 2f19b981ac24. This patch fixes the documentation of those two methods for Python 3. There could be more fixes needed for Python 2. ---------- assignee: docs at python components: Documentation files: typeobj-sigs.patch keywords: patch messages: 281468 nosy: docs at python, martin.panter priority: normal severity: normal stage: patch review status: open title: Update documented signatures of tp_get/setattr versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45600/typeobj-sigs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 06:54:14 2016 From: report at bugs.python.org (Chun-Yu Tseng) Date: Tue, 22 Nov 2016 11:54:14 +0000 Subject: [issue26072] pdb fails to access variables closed over In-Reply-To: <1452402984.12.0.000738362264887.issue26072@psf.upfronthosting.co.za> Message-ID: <1479815653.99.0.0527866851838.issue26072@psf.upfronthosting.co.za> Chun-Yu Tseng added the comment: Hey xdegaye, have you confirmed it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 07:07:10 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Nov 2016 12:07:10 +0000 Subject: [issue28768] Warning: implicit declaration of function '_setmode' In-Reply-To: <1479758430.88.0.97682867264.issue28768@psf.upfronthosting.co.za> Message-ID: <1479816429.99.0.446598253248.issue28768@psf.upfronthosting.co.za> Martin Panter added the comment: The Modules/main.c change at least looks reasonable as a bug fix. In the long term, it would be nice to clean up some of the conditions for including . Currently it is unconditional via PC/pyconfig.h, configure.ac optionally enables HAVE_IO_H, and there are various other conditions in different files, like as QUICKWIN, PYCC_VACPP and MS_WINDOWS || __CYGWIN__. ---------- components: +Windows nosy: +martin.panter, paul.moore, steve.dower, tim.golden, zach.ware stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 07:11:40 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Nov 2016 12:11:40 +0000 Subject: [issue28023] python-gdb.py must be updated for the new Python 3.6 compact dict In-Reply-To: <1473351940.28.0.277088210884.issue28023@psf.upfronthosting.co.za> Message-ID: <20161122121137.113240.36614.17219052@psf.io> Roundup Robot added the comment: New changeset 9b974f988c95 by Victor Stinner in branch '3.6': Issue #28023: Fix python-gdb.py on old GDB versions https://hg.python.org/cpython/rev/9b974f988c95 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 07:13:10 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Nov 2016 12:13:10 +0000 Subject: [issue20572] subprocess.Popen.wait() undocumented "endtime" parameter In-Reply-To: <1391941400.18.0.703922206544.issue20572@psf.upfronthosting.co.za> Message-ID: <1479816790.68.0.415254161606.issue20572@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 07:13:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 12:13:52 +0000 Subject: [issue28771] Update documented signatures of tp_get/setattr In-Reply-To: <1479815588.93.0.810601241454.issue28771@psf.upfronthosting.co.za> Message-ID: <1479816832.42.0.680933796484.issue28771@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 07:14:52 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 12:14:52 +0000 Subject: [issue28768] Warning: implicit declaration of function '_setmode' In-Reply-To: <1479758430.88.0.97682867264.issue28768@psf.upfronthosting.co.za> Message-ID: <1479816892.48.0.907048531584.issue28768@psf.upfronthosting.co.za> STINNER Victor added the comment: include-io.h.patch LGTM. 2.7-include-io.h.patch: Cygwin is not currently officially supported in CPython. I suggest to focus efforts on supporting Cygwin in the default branch (future 3.7) only, as we are doing with Android. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 07:19:34 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 22 Nov 2016 12:19:34 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1478305744.67.0.856588872906.issue28618@psf.upfronthosting.co.za> Message-ID: <1479817174.71.0.234978777489.issue28618@psf.upfronthosting.co.za> INADA Naoki added the comment: I setup Ubuntu 14.04 on Azure, built python without neither PGO nor LTO. But I failed to reproduce it. @haypo, would you give me two binaries? $ ~/local/py-2a143/bin/python3 -c 'import sys; print(sys.version)' 3.7.0a0 (default:2a14385710dc, Nov 22 2016, 12:02:34) [GCC 4.8.4] $ ~/local/py-acde8/bin/python3 -c 'import sys; print(sys.version)' 3.7.0a0 (default:acde821520fc, Nov 22 2016, 11:31:16) [GCC 4.8.4] $ ~/local/py-2a143/bin/python3 bm_call_method.py ..................... call_method: Median +- std dev: 16.1 ms +- 0.6 ms $ ~/local/py-acde8/bin/python3 bm_call_method.py ..................... call_method: Median +- std dev: 16.1 ms +- 0.7 ms ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 07:30:26 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 22 Nov 2016 12:30:26 +0000 Subject: [issue28023] python-gdb.py must be updated for the new Python 3.6 compact dict In-Reply-To: <1473351940.28.0.277088210884.issue28023@psf.upfronthosting.co.za> Message-ID: <1479817826.54.0.963466280244.issue28023@psf.upfronthosting.co.za> INADA Naoki added the comment: Thanks a lot! I hope I can run test on multiple environment before merge, after we move to Github. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 07:35:42 2016 From: report at bugs.python.org (Stefan Scherfke) Date: Tue, 22 Nov 2016 12:35:42 +0000 Subject: [issue28772] Bus error in Python 3.6.0beta Message-ID: <1479818142.38.0.0931531711664.issue28772@psf.upfronthosting.co.za> New submission from Stefan Scherfke: Hi all, I am trying to build a custom Conda installer for Python 3.6.0b4. I could successfully build an run Python. However, when I run the generated Conda installer, it dies with a "Bus error". It happens when Conda's meta-installer script tries to replace the build-prefix (e.g., /home/stefan/conda/asdf) with the prefix of the actual installation (e.g., /tmp/py36). Therefore, it opens all files in binary mode, reads their contents, replaces stuff, and writes the new contents back to the original file. This works fine with text files but it dies when it hits the first binary file. Here is a minimal example that reproduces the error: $ /tmp/py36/bin/python Python 3.6.0b4 (default, Nov 22 2016, 10:32:29) [GCC 6.2.1 20160916 (Red Hat 6.2.1-2)] on linux >>> >>> path = '/tmp/py36/lib/libpython3.6m.so.1.0' >>> f = open(path, 'wb') BusError Can anyone reproduce this? Is this a compilation error or an issue with Python itself? It works without issues with Python 3.5. Cheers, Stefan PS: If need, I can upload the Conda installer somewhere. It's ~40MiB. ---------- messages: 281475 nosy: Stefan Scherfke priority: normal severity: normal status: open title: Bus error in Python 3.6.0beta type: crash versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 07:43:31 2016 From: report at bugs.python.org (Manuel Krebber) Date: Tue, 22 Nov 2016 12:43:31 +0000 Subject: [issue28773] typing.FrozenSet missing in documentation. Message-ID: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za> New submission from Manuel Krebber: The typing.FrozenSet is missing in the typing module documentation. I have attached a patch that adds it similar to the typing.Set which is already in the documentation. ---------- components: Library (Lib) files: frozenset-doc.patch keywords: patch messages: 281476 nosy: Wheerd priority: normal severity: normal status: open title: typing.FrozenSet missing in documentation. type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45601/frozenset-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 08:17:27 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 13:17:27 +0000 Subject: [issue28618] Decorate hot functions using __attribute__((hot)) to optimize Python In-Reply-To: <1479817174.71.0.234978777489.issue28618@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > But I failed to reproduce it. Hey, performance issues with code placement is a mysterious secret :-) Nobody understands it :-D The server runner the benchmark is a Intel Xeon CPU of 2011. It seems like code placement issues are more important on this CPU than my more recent laptop or desktop PC. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 08:18:02 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 13:18:02 +0000 Subject: [issue28023] python-gdb.py must be updated for the new Python 3.6 compact dict In-Reply-To: <1479817826.54.0.963466280244.issue28023@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Ah nice, it seems like test_gdb pass again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 09:20:59 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 14:20:59 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479824459.26.0.406116031114.issue28727@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: + && left->codesize && right->codesize); There is a typo. Should be: + && left->codesize == right->codesize); ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 09:24:33 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 14:24:33 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479824673.06.0.677623422043.issue28727@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: While we are here, it perhaps worth to add a fast path for self == other. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 09:28:16 2016 From: report at bugs.python.org (Elvis Pranskevichus) Date: Tue, 22 Nov 2016 14:28:16 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1479824896.31.0.674952652681.issue28635@psf.upfronthosting.co.za> Elvis Pranskevichus added the comment: https://docs.python.org/3.6/whatsnew/3.6.html#changes-in-python-command-behavior seems appropriate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 09:29:22 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 22 Nov 2016 14:29:22 +0000 Subject: [issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1 Message-ID: <1479824962.83.0.769019580096.issue28774@psf.upfronthosting.co.za> New submission from Xiang Zhang: unicode_encode_ucs1 now recognizes as many characters as it can one time instead of one character a time. But the unicodeerror positions still only count 1(the second time). A similar problem reported in #28561. ---------- components: Interpreter Core files: unicode_encode_ucs1_error_pos.patch keywords: patch messages: 281482 nosy: haypo, serhiy.storchaka, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Better start and end position for unicodeerror in unicode_encode_ucs1 type: enhancement versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45602/unicode_encode_ucs1_error_pos.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 09:31:49 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Nov 2016 14:31:49 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <20161122143146.26332.25607.72BA74C5@psf.io> Roundup Robot added the comment: New changeset 6b43d15fd2d7 by Victor Stinner in branch '3.6': Issue #28727: Fix typo in pattern_richcompare() https://hg.python.org/cpython/rev/6b43d15fd2d7 New changeset c2cb70c97163 by Victor Stinner in branch '3.6': Issue #28727: Optimize pattern_richcompare() for a==a https://hg.python.org/cpython/rev/c2cb70c97163 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 09:32:35 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 14:32:35 +0000 Subject: [issue28727] Implement comparison (x==y and x!=y) for _sre.SRE_Pattern In-Reply-To: <1479398568.09.0.867806263276.issue28727@psf.upfronthosting.co.za> Message-ID: <1479825155.28.0.301478059008.issue28727@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy Storchaka: "&& left->codesize && right->codesize)" Ooops! Fixed! "While we are here, it perhaps worth to add a fast path for self == other." Done. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 09:41:47 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 22 Nov 2016 14:41:47 +0000 Subject: [issue27030] Remove deprecated re features In-Reply-To: <1463337497.02.0.81864271809.issue27030@psf.upfronthosting.co.za> Message-ID: <1479825707.36.0.585757404633.issue27030@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: FWIW, this breaks Mailman 3.1 (and probably 2.1) ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 09:41:52 2016 From: report at bugs.python.org (Elvis Pranskevichus) Date: Tue, 22 Nov 2016 14:41:52 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1479825712.68.0.22530948424.issue28635@psf.upfronthosting.co.za> Elvis Pranskevichus added the comment: On second thought `-VV` isn't really a porting change, so probably a new section under "Build and C API Changes". Something like "Other Improvements". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 09:42:47 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 22 Nov 2016 14:42:47 +0000 Subject: [issue27030] Remove deprecated re features In-Reply-To: <1463337497.02.0.81864271809.issue27030@psf.upfronthosting.co.za> Message-ID: <1479825767.36.0.0892313749882.issue27030@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Specifically, point #2; undefined combinations of \ + ASCII becoming an error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 09:48:19 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Nov 2016 14:48:19 +0000 Subject: [issue27030] Remove deprecated re features In-Reply-To: <1463337497.02.0.81864271809.issue27030@psf.upfronthosting.co.za> Message-ID: <1479826099.98.0.935343475773.issue27030@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 09:53:16 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 14:53:16 +0000 Subject: [issue28023] python-gdb.py must be updated for the new Python 3.6 compact dict In-Reply-To: <1473351940.28.0.277088210884.issue28023@psf.upfronthosting.co.za> Message-ID: <1479826396.0.0.939606498374.issue28023@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 09:54:00 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 14:54:00 +0000 Subject: [issue28023] python-gdb.py must be updated for the new Python 3.6 compact dict In-Reply-To: <1473351940.28.0.277088210884.issue28023@psf.upfronthosting.co.za> Message-ID: <1479826440.35.0.457691081325.issue28023@psf.upfronthosting.co.za> STINNER Victor added the comment: Thanks Naoki for the fix ;-) gdb scripts are a little bit weird sometimes, and the API has subtle changes in each minor GDB release :-/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 09:54:16 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 14:54:16 +0000 Subject: [issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1 In-Reply-To: <1479824962.83.0.769019580096.issue28774@psf.upfronthosting.co.za> Message-ID: <1479826456.76.0.839241124711.issue28774@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 10:01:00 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 15:01:00 +0000 Subject: [issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1 In-Reply-To: <1479824962.83.0.769019580096.issue28774@psf.upfronthosting.co.za> Message-ID: <1479826860.31.0.705777620798.issue28774@psf.upfronthosting.co.za> STINNER Victor added the comment: If I understood correctly, the patch fix the ASCII encoder to handle correctly error handlers which return non-ASCII text replacement strings. Right? I am not aware of such error handler, so I guess that it's a more a theorical fix? I really hate the code (in each encoder) which handles non-ASCII replacement strings. The code in the charmap encoder is just a mess: it uses a reentrant call to the encoder... I never understood this crazy behaviour. I guess that nobody relies on the behaviour. I hesitate to simply raise an error instead of using different rules depending on the code. Ah yes, by the way, each codec behaves differently on non-ASCII replacement strings... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 10:01:34 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 15:01:34 +0000 Subject: [issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1 In-Reply-To: <1479824962.83.0.769019580096.issue28774@psf.upfronthosting.co.za> Message-ID: <1479826894.6.0.963674859174.issue28774@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 10:52:10 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 15:52:10 +0000 Subject: [issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1 In-Reply-To: <1479824962.83.0.769019580096.issue28774@psf.upfronthosting.co.za> Message-ID: <1479829930.47.0.849848846469.issue28774@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. But it is too late for beta 4. I'll commit the patch either after releasing 3.6.0 or in the 3.7 branch only. And while we are here I noticed that handling non-ASCII replacement string could be simpler. ---------- Added file: http://bugs.python.org/file45603/unicode_encode_ucs1_error_pos2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 11:13:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 16:13:07 +0000 Subject: [issue27030] Remove deprecated re features In-Reply-To: <1463337497.02.0.81864271809.issue27030@psf.upfronthosting.co.za> Message-ID: <1479831187.83.0.397367235616.issue27030@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could Mailman be fixed? Undefined combinations of \ + ASCII emitted warnings in 3.5. And now they emit warnings even just in string literals (issue27364). If Mailman use undefined escape combinations, it could suffer from issue27364 too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 11:38:45 2016 From: report at bugs.python.org (Chi Hsuan Yen) Date: Tue, 22 Nov 2016 16:38:45 +0000 Subject: [issue28772] Bus error in Python 3.6.0beta In-Reply-To: <1479818142.38.0.0931531711664.issue28772@psf.upfronthosting.co.za> Message-ID: <1479832725.96.0.637698507251.issue28772@psf.upfronthosting.co.za> Chi Hsuan Yen added the comment: A common cause of bus error is mis-aligned memory access. Which architecture are you on and how did you compile Python? (compiler flags, etc.) FWIW, configure python with --with-pydebug may bring you more debugging information ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 11:46:19 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Tue, 22 Nov 2016 16:46:19 +0000 Subject: [issue22298] Lib/warnings.py _show_warning does not protect against being called with a file like object which is closed In-Reply-To: <1409315343.62.0.0672695786427.issue22298@psf.upfronthosting.co.za> Message-ID: <1479833179.89.0.129093226018.issue22298@psf.upfronthosting.co.za> Changes by Wolfgang Maier : ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 11:56:24 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Tue, 22 Nov 2016 16:56:24 +0000 Subject: [issue18943] argparse: default args in mutually exclusive groups In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za> Message-ID: <1479833784.12.0.669811466212.issue18943@psf.upfronthosting.co.za> Changes by Wolfgang Maier : ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 12:32:11 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 22 Nov 2016 17:32:11 +0000 Subject: [issue4347] Circular dependency causes SystemError when adding new syntax In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za> Message-ID: <1479835931.73.0.247022154962.issue4347@psf.upfronthosting.co.za> Brett Cannon added the comment: Ah, the fact parsetok.c gets compiled twice into different object files is the detail I was overlooking. Thanks for the clarification. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 12:42:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 17:42:12 +0000 Subject: [issue27100] Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za> Message-ID: <1479836532.39.0.895165161242.issue27100@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 12:54:12 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Nov 2016 17:54:12 +0000 Subject: [issue28775] Option to set startup directory in IDLE Message-ID: <1479837252.01.0.0581172301847.issue28775@psf.upfronthosting.co.za> New submission from Raymond Hettinger: In my Python courses, Windows users frequently ask about how to set a startup directory so they can run from their Desktop or a custom directory. The usual answer is to create a short-cut and then alter the properties on that shortcut. However, other programs they are used to will allow the startup directory to be specified from within the program (in our case, the preferences menu). Also, we should change the default directory from C:\\Python27 which is almost never the right place. A documents directory would be more appropriate. ---------- assignee: terry.reedy components: IDLE messages: 281494 nosy: rhettinger, terry.reedy priority: normal severity: normal status: open title: Option to set startup directory in IDLE versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 12:56:25 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Nov 2016 17:56:25 +0000 Subject: [issue27100] Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za> Message-ID: <1479837385.89.0.0732175848217.issue27100@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Martin, do you want to make a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 13:19:24 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 22 Nov 2016 18:19:24 +0000 Subject: [issue27030] Remove deprecated re features In-Reply-To: <1479831187.83.0.397367235616.issue27030@psf.upfronthosting.co.za> Message-ID: <20161122131920.108af7a6@subdivisions.wooz.org> Barry A. Warsaw added the comment: On Nov 22, 2016, at 04:13 PM, Serhiy Storchaka wrote: >Could Mailman be fixed? Undefined combinations of \ + ASCII emitted warnings >in 3.5. And now they emit warnings even just in string literals >(issue27364). If Mailman use undefined escape combinations, it could suffer >from issue27364 too. No, I think this is a valid bug/regression. The Mailman code is basically trying to do this: p = re.compile('%\d*d') p.sub(r'\s*\d+\s*', some_string) And so we get the error: sre_constants.error: bad escape \s at position 0 But this directly contradicts the documentation for re.sub(): "... if it is a string, any backslash escapes in it are processed. That is, \n is converted to a single newline character, \r is converted to a carriage return, and so forth. Unknown escapes such as \& are left alone." Clearly \s is not being left alone, so this is a real regression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 13:20:00 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 22 Nov 2016 18:20:00 +0000 Subject: [issue27030] Remove deprecated re features In-Reply-To: <1463337497.02.0.81864271809.issue27030@psf.upfronthosting.co.za> Message-ID: <1479838800.0.0.630414385309.issue27030@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +ned.deily priority: normal -> release blocker status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 13:20:17 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Nov 2016 18:20:17 +0000 Subject: [issue27100] Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za> Message-ID: <1479838817.42.0.362456288914.issue27100@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file45604/fix_with_refleak.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 13:20:28 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Nov 2016 18:20:28 +0000 Subject: [issue27100] Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za> Message-ID: <1479838828.34.0.447621935226.issue27100@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- Removed message: http://bugs.python.org/msg281495 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 13:23:30 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Nov 2016 18:23:30 +0000 Subject: [issue27100] Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za> Message-ID: <1479839010.73.0.93285495066.issue27100@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Serhiy, do you care to double check this patch? Martin, I'll leave the async_with for Yuri to fix-up. I believe that is his code, so he should do the honors. ---------- assignee: rhettinger -> serhiy.storchaka nosy: +serhiy.storchaka, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 13:55:47 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 18:55:47 +0000 Subject: [issue27030] Remove deprecated re features In-Reply-To: <1463337497.02.0.81864271809.issue27030@psf.upfronthosting.co.za> Message-ID: <1479840947.65.0.447851150883.issue27030@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This part of the documentation was just overlooked. Issue28450 is opened for this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 14:08:06 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 19:08:06 +0000 Subject: [issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za> Message-ID: <1479841686.29.0.394877427048.issue28450@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Maybe just remove the phrase "Unknown escapes such as \& are left alone"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 14:10:59 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 22 Nov 2016 19:10:59 +0000 Subject: [issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za> Message-ID: <1479841859.21.0.28946334616.issue28450@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I disagree that the documentation is at fault. This is known to break existing code, e.g. http://bugs.python.org/msg281496 I think it's not correct to change the documentation but leave the error-raising behavior for 3.6 because the deprecation was never documented in 3.5 so this will look like a gratuitous regression. issue27030 for reference. I also question whether it makes sense for such escapes to be illegal in the repl argument of re.sub(). I could understand for this limitation in the pattern argument, but that's not what's causing the error. ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 14:16:45 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 19:16:45 +0000 Subject: [issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za> Message-ID: <1479842205.29.0.349772055682.issue28450@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The deprecation was documented in 3.5. https://docs.python.org/3.5/library/re.html#re.sub Deprecated since version 3.5, will be removed in version 3.6: Unknown escapes consist of '\' and ASCII letter now raise a deprecation warning and will be forbidden in Python 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 14:23:28 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 22 Nov 2016 19:23:28 +0000 Subject: [issue27030] Remove deprecated re features In-Reply-To: <1463337497.02.0.81864271809.issue27030@psf.upfronthosting.co.za> Message-ID: <1479842608.95.0.796188285078.issue27030@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- priority: release blocker -> normal status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 14:28:56 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 19:28:56 +0000 Subject: [issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za> Message-ID: <1479842936.68.0.667608567846.issue28450@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The reason for disallowing some undefined escapes is the same as in pattern strings: this would allow as to introduce new special escape sequences. For example: * \N{...} for named character escape. * Perl and extended PCRE use \L and \U for making lower and upper casing of the replacement. \U is already used for other purpose, but you have an idea. Of course the need in new special escape sequences in template string is much less then in pattern string. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 14:34:29 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 19:34:29 +0000 Subject: [issue27030] Remove deprecated re features In-Reply-To: <1463337497.02.0.81864271809.issue27030@psf.upfronthosting.co.za> Message-ID: <1479843269.85.0.701974912734.issue27030@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If you insist I could revert converting warnings to errors (only in replacement string or all?) in 3.6. But I think they should left errors in 3.7. The earlier we make undefined escapes the errors, the earlier we can define new special escape sequences without confusing users. It is bad if the escape sequence is valid in two Python versions but has different meaning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 14:42:41 2016 From: report at bugs.python.org (Matthew Barnett) Date: Tue, 22 Nov 2016 19:42:41 +0000 Subject: [issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za> Message-ID: <1479843761.03.0.11370280558.issue28450@psf.upfronthosting.co.za> Matthew Barnett added the comment: @Barry: repl already supports some escapes, e.g. \g for named groups, although not \xXX et al, so deprecating unknown escapes like in the pattern makes sense to me. BTW, the regex module already supports \xXX, \N{XXX}, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 14:43:30 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 19:43:30 +0000 Subject: [issue27100] Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za> Message-ID: <1479843810.15.0.0368408548107.issue27100@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch LGTM. ---------- assignee: serhiy.storchaka -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 14:46:50 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 22 Nov 2016 19:46:50 +0000 Subject: [issue28573] Python 3.6.0b4 64-bit has no sys._mercurial info In-Reply-To: <1477975263.28.0.609263953959.issue28573@psf.upfronthosting.co.za> Message-ID: <1479844010.67.0.113151844236.issue28573@psf.upfronthosting.co.za> Steve Dower added the comment: Attaching the patch here for visibility. In short, rather than relying on PATH to find hg.exe, we now precalculate it and pass it in to the build. This completely avoids the problem where modifying PATH multiple times for different builds was causing Mercurial to fall off. This patch also fixes two other issues with my build script - the PGOOPTS need to come before CERTOPTS, as they are parsed by different scripts, and the debug build command fell off somewhere which resulted in the debug builds not being rebuilt for 3.6.0b4 - they are still the 3.6.0b3 debug build. ---------- keywords: +patch Added file: http://bugs.python.org/file45605/28573_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 14:49:41 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Nov 2016 19:49:41 +0000 Subject: [issue28573] Python 3.6.0b4 64-bit has no sys._mercurial info In-Reply-To: <1477975263.28.0.609263953959.issue28573@psf.upfronthosting.co.za> Message-ID: <20161122194938.24451.57458.13169D20@psf.io> Roundup Robot added the comment: New changeset 089886be06df by Steve Dower in branch '3.6': Issue #28573: Missing sys._mercurial info and other build issues. https://hg.python.org/cpython/rev/089886be06df New changeset d0958078bcb6 by Steve Dower in branch 'default': Issue #28573: Missing sys._mercurial info and other build issues. https://hg.python.org/cpython/rev/d0958078bcb6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 14:50:01 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 22 Nov 2016 19:50:01 +0000 Subject: [issue28573] Python 3.6.0b4 64-bit has no sys._mercurial info In-Reply-To: <1477975263.28.0.609263953959.issue28573@psf.upfronthosting.co.za> Message-ID: <1479844201.77.0.43193957624.issue28573@psf.upfronthosting.co.za> Steve Dower added the comment: Ned approved this last night on IRC, so now it's in. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 14:51:07 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Nov 2016 19:51:07 +0000 Subject: [issue27100] Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za> Message-ID: <20161122195105.9004.29372.40EE9AE4@psf.io> Roundup Robot added the comment: New changeset 749c5d6c4ba5 by Raymond Hettinger in branch '3.6': Issue #27100: Fix ref leak https://hg.python.org/cpython/rev/749c5d6c4ba5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 14:53:22 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Nov 2016 19:53:22 +0000 Subject: [issue27100] Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za> Message-ID: <1479844402.83.0.364639477626.issue27100@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Yuri, do you want to do the same for async-with? ---------- assignee: rhettinger -> yselivanov priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 14:55:51 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 22 Nov 2016 19:55:51 +0000 Subject: [issue27030] Remove deprecated re features In-Reply-To: <1463337497.02.0.81864271809.issue27030@psf.upfronthosting.co.za> Message-ID: <1479844551.38.0.142143057651.issue27030@psf.upfronthosting.co.za> R. David Murray added the comment: There is still the argument that we shouldn't break 2.7 compatibility unnecessarily until 2.7 is out of maintenance. That is: warnings are good, removals are bad. (I haven't read through this issue, so I may be off base.) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 15:28:47 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 22 Nov 2016 20:28:47 +0000 Subject: [issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions In-Reply-To: <1479842936.68.0.667608567846.issue28450@psf.upfronthosting.co.za> Message-ID: <20161122152843.08aee523@subdivisions.wooz.org> Barry A. Warsaw added the comment: On Nov 22, 2016, at 07:28 PM, Serhiy Storchaka wrote: >The reason for disallowing some undefined escapes is the same as in pattern >strings: this would allow as to introduce new special escape sequences. I'll note that technically speaking, you can still introduce new escapes for repl without breaking the documented contract. All the docs say are that "unknown escapes such as \& are left alone", but that doesn't list what are unknown escapes. So if new escapes are added in Python 3.7, and they are transformed in repl, that would be allowed. I'll also note that not *all* unknown sequences are rejected now, only backslashes followed by an ASCII letter. So \& is still probably left alone, while \s is now rejected. That does add to the confusion, although the deprecation note in the re.sub() documentation does document the new behavior correctly. On Nov 22, 2016, at 07:55 PM, R. David Murray wrote: >There is still the argument that we shouldn't break 2.7 compatibility >unnecessarily until 2.7 is out of maintenance. That is: warnings are good, >removals are bad. (I haven't read through this issue, so I may be off base.) This is also a reasonable argument, but not one I've thought about since I'm using Python 2 only rarely these days. On Nov 22, 2016, at 07:34 PM, Serhiy Storchaka wrote: >If you insist I could revert converting warnings to errors (only in >replacement string or all?) in 3.6. pattern is a regular expression string so it already follows the syntax as described in $6.2.1 Regular Expression Syntax. But I think a reading of that section (and the "special sequences" bit that follows) could also argue that unknown escapes shouldn't throw an error. >But I think they should left errors in 3.7. The earlier we make undefined >escapes the errors, the earlier we can define new special escape sequences >without confusing users. It is bad if the escape sequence is valid in two >Python versions but has different meaning. Perhaps so, but I do think this is a tricky question from a compatibility point of view. One possible optional, although it's late in the cycle, would be to introduce a new flag so the user could tell re exactly what behavior they want. The default would have to be backward compatible (i.e. leave unknown sequences alone), but there could be say an re.STRICTESCAPES flag that would cause the error to be thrown. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 15:49:46 2016 From: report at bugs.python.org (Peter Inglesby) Date: Tue, 22 Nov 2016 20:49:46 +0000 Subject: [issue28776] Duplicate method names should be an error Message-ID: <1479847786.59.0.434760924279.issue28776@psf.upfronthosting.co.za> New submission from Peter Inglesby: It should be an error for a class to define a method twice. That is, Python should raise an exception when the following code is loaded: class C: def m(self): # do something def m(self): # do something I have just witnessed a beginner get very confused by this! (Apologies if this is a duplicate of an existing issue.) ---------- messages: 281513 nosy: inglesp priority: normal severity: normal status: open title: Duplicate method names should be an error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 15:50:57 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 22 Nov 2016 20:50:57 +0000 Subject: [issue28773] typing.FrozenSet missing in documentation. In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za> Message-ID: <1479847857.2.0.145292626133.issue28773@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Manuel. Looks like FrozenSet is in PEP 484 and has been added to typing.__all__ in https://github.com/python/typing/pull/261 (already synced with the stdlib version of typing module) The patch looks good to me. Adding Guido to nosy list for a commit review. ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +berker.peksag, docs at python, gvanrossum stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 15:51:45 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 20:51:45 +0000 Subject: [issue28776] Duplicate method names should be an error In-Reply-To: <1479847786.59.0.434760924279.issue28776@psf.upfronthosting.co.za> Message-ID: <1479847905.1.0.0528205302143.issue28776@psf.upfronthosting.co.za> STINNER Victor added the comment: Redefine a method is a common practice indirectly using decorators: @staticmethod def method(): pass is like: def method(): pass method = staticmethod(method) So you can clarify what do you mean by "redefining"? Some linters already can such common mistake (very common mistake in unit tests when using copy & paste). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 16:00:38 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 22 Nov 2016 21:00:38 +0000 Subject: [issue28776] Duplicate method names should be an error In-Reply-To: <1479847786.59.0.434760924279.issue28776@psf.upfronthosting.co.za> Message-ID: <1479848438.14.0.78353504763.issue28776@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, IMO this is something that needs to go into a linter, not Python itself. The dynamic nature of the class dictionary is too important to many programs to change it at this point. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 16:01:33 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 21:01:33 +0000 Subject: [issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1 In-Reply-To: <1479824962.83.0.769019580096.issue28774@psf.upfronthosting.co.za> Message-ID: <1479848493.5.0.967144687607.issue28774@psf.upfronthosting.co.za> STINNER Victor added the comment: > LGTM. But it is too late for beta 4. I'll commit the patch either after releasing 3.6.0 or in the 3.7 branch only. Right now, I suggest to only commit into 3.7. Such minor bug can wait for Python 3.6.1. > And while we are here I noticed that handling non-ASCII replacement string could be simpler I also suggest to first commit unicode_encode_ucs1_error_pos.patch and then commit the other part of unicode_encode_ucs1_error_pos2.patch in a separated commit. I will be easy to backport the fix to the 3.6 branch later. Serhiy: Xiang became a core developer, are you ok if he push himself unicode_encode_ucs1_error_pos.patch to default tomorrow, and later you rebase your patch on top of that? I'm not super confident because the fix doesn't come with an unit test, but it's ok if Serhiy reviewed it :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 16:01:50 2016 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 22 Nov 2016 21:01:50 +0000 Subject: [issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za> Message-ID: <1479848510.01.0.733233284311.issue28450@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 16:04:25 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 21:04:25 +0000 Subject: [issue28776] Duplicate method names should be an error In-Reply-To: <1479847786.59.0.434760924279.issue28776@psf.upfronthosting.co.za> Message-ID: <1479848665.61.0.864546498274.issue28776@psf.upfronthosting.co.za> STINNER Victor added the comment: Without modifying the language, I guess that it's already technically possible to implement that in Python 3 in an application. Using the __prepare__() method of a metaclass and a custom dict subclass, I think that you can build what you want. I mean that you would have to modify your classes to inherit from a base class (which uses the metaclass) and/or use the metaclass everywhere, to catch such bug... I'm not sure that it's worth it. You don't want to have to modify your code to catch a single class of kind. Linters exist to check the code without having to modify it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 16:12:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Nov 2016 21:12:32 +0000 Subject: [issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1 In-Reply-To: <1479824962.83.0.769019580096.issue28774@psf.upfronthosting.co.za> Message-ID: <1479849152.23.0.550359098799.issue28774@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is not a bug itself. It seems to me that at worst case the current code is less efficient with non-standard error handler than it can be. I would commit the path to the 3.6 branch before beta 4 as it is nice and simple additional to already added optimization. But it is too late now, at last beta. Xiang can commit his patch to 3.7. No need to backport it to 3.6 (if I didn't miss something). ---------- assignee: serhiy.storchaka -> xiang.zhang stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 16:16:05 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 21:16:05 +0000 Subject: [issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1 In-Reply-To: <1479824962.83.0.769019580096.issue28774@psf.upfronthosting.co.za> Message-ID: <1479849365.06.0.970538423815.issue28774@psf.upfronthosting.co.za> STINNER Victor added the comment: > No need to backport it to 3.6 (if I didn't miss something). Sorry, I misunderstood the issue. It's an enhancement, so for 3.7 only. Right, 3.6 is now almost frozen, only major bug fixes blocking the release are accepted now (in short). Regular bugfixes should wait for 3.6.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 16:53:21 2016 From: report at bugs.python.org (Jason R. Coombs) Date: Tue, 22 Nov 2016 21:53:21 +0000 Subject: [issue28752] datetime object fails to restore from reduction In-Reply-To: <1479657323.42.0.875075153657.issue28752@psf.upfronthosting.co.za> Message-ID: <1479851601.73.0.792039901435.issue28752@psf.upfronthosting.co.za> Jason R. Coombs added the comment: Thanks all! So pleased to see this fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 16:55:36 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Nov 2016 21:55:36 +0000 Subject: [issue28770] Update python-gdb.py for fastcalls In-Reply-To: <1479814975.16.0.381517171433.issue28770@psf.upfronthosting.co.za> Message-ID: <20161122215532.18939.44110.08D769F1@psf.io> Roundup Robot added the comment: New changeset 752863f96fb8 by Victor Stinner in branch 'default': Issue #28770: Update python-gdb.py for fastcalls https://hg.python.org/cpython/rev/752863f96fb8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 17:02:21 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 22:02:21 +0000 Subject: [issue28770] Update python-gdb.py for fastcalls In-Reply-To: <1479814975.16.0.381517171433.issue28770@psf.upfronthosting.co.za> Message-ID: <1479852141.84.0.932715136211.issue28770@psf.upfronthosting.co.za> STINNER Victor added the comment: I keep the issue open until the 3.6 branch is reopened for regular bug fixes, like this one. Then I will backport the fix to 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 17:20:35 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Nov 2016 22:20:35 +0000 Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup and groupindex In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za> Message-ID: <20161122222032.88703.93841.647E8B21@psf.io> Roundup Robot added the comment: New changeset 1addc5d2c246 by Victor Stinner in branch 'default': Issue #28765: _sre.compile() now checks the type of groupindex and indexgroup https://hg.python.org/cpython/rev/1addc5d2c246 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 17:21:36 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Nov 2016 22:21:36 +0000 Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup and groupindex In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za> Message-ID: <1479853296.86.0.503319290781.issue28765@psf.upfronthosting.co.za> STINNER Victor added the comment: sre_compile_remove_groups.patch removes the groups parameter from _sre.compile(). A first step to simplify the API. I prefer to keep most of the code in pure Python, to have code easier to maintain. So I prefer to not accept only groupindex. I prefer to build both (indexgroup, groupindex) in pure Python and pass them to the C code. I pushed my patch sre_types.patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 17:38:40 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Nov 2016 22:38:40 +0000 Subject: [issue28776] Duplicate method names should be an error In-Reply-To: <1479847786.59.0.434760924279.issue28776@psf.upfronthosting.co.za> Message-ID: <1479854320.12.0.601317043981.issue28776@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Yes, IMO this is something that needs to go into a linter, > not Python itself. I concur with David Murray. This would break too many classes and is at odds with the design of Python where code inside a class definition is executed in its own namespace where it has the same rights and privileges as code execed elsewhere. ---------- nosy: +rhettinger resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 17:41:57 2016 From: report at bugs.python.org (Peter Inglesby) Date: Tue, 22 Nov 2016 22:41:57 +0000 Subject: [issue28776] Duplicate method names should be an error In-Reply-To: <1479847786.59.0.434760924279.issue28776@psf.upfronthosting.co.za> Message-ID: <1479854517.07.0.123339755439.issue28776@psf.upfronthosting.co.za> Peter Inglesby added the comment: Victor, I'm not talking about redefining a method, and David, I don't think I'm talking about changing dynamic nature of the class dictionary. All I'm suggesting is that if some code contains a class whose body defines the same method twice, Python should treat it as an error. At the moment, as far as I can tell, the first method is ignored. Is there any situation where this behaviour is useful? Python already handles a somewhat similar situation by raising a SyntaxError when it encounters a function whose parameter list contains duplicates: >>> def f(a, a): ... pass ... File "", line 1 SyntaxError: duplicate argument 'a' in function definition ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 17:51:00 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Tue, 22 Nov 2016 22:51:00 +0000 Subject: [issue28773] typing.FrozenSet missing in documentation. In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za> Message-ID: <1479855060.83.0.132897668707.issue28773@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: The patch looks good, I left just one small comment in Rietveld. ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 17:51:25 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 22 Nov 2016 22:51:25 +0000 Subject: [issue28776] Duplicate method names should be an error In-Reply-To: <1479847786.59.0.434760924279.issue28776@psf.upfronthosting.co.za> Message-ID: <1479855085.89.0.912253629267.issue28776@psf.upfronthosting.co.za> R. David Murray added the comment: It isn't ignored. The first definition is entered into the class dictionary, then the second definition replaces it. That's why Victor talked about redefining a method, because that's what happens. You can't really disentangle the two cases except by source inspection (a linter). In the parameter list case, the parser has the information it needs to detect it in hand, and more importantly there is no meaning to "replacing" a parameter, so we can and do generate an error in that case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 17:57:46 2016 From: report at bugs.python.org (Peter Inglesby) Date: Tue, 22 Nov 2016 22:57:46 +0000 Subject: [issue28776] Duplicate method names should be an error In-Reply-To: <1479847786.59.0.434760924279.issue28776@psf.upfronthosting.co.za> Message-ID: <1479855466.34.0.422107659386.issue28776@psf.upfronthosting.co.za> Peter Inglesby added the comment: OK, I'll defer to your collective decades of experience and wisdom! Thanks for all you all do for Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 18:04:35 2016 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 22 Nov 2016 23:04:35 +0000 Subject: [issue28757] Installation Failure In-Reply-To: <1479696577.66.0.987824550114.issue28757@psf.upfronthosting.co.za> Message-ID: <1479855875.88.0.325999021648.issue28757@psf.upfronthosting.co.za> Eric V. Smith added the comment: Thanks for the bug report. However, 3.2 is no longer supported. If you can reproduce this with 3.5 or 3.6, then please list the exact steps, including: OS version where you got the file you downloaded what steps you took to install it I'm closing this, but feel free to re-open it if you can reproduce with a supported version of Python. ---------- nosy: +eric.smith resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 18:22:57 2016 From: report at bugs.python.org (Manuel Krebber) Date: Tue, 22 Nov 2016 23:22:57 +0000 Subject: [issue28773] typing.FrozenSet missing in documentation. In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za> Message-ID: <1479856977.75.0.2566207479.issue28773@psf.upfronthosting.co.za> Manuel Krebber added the comment: I updated the patch to add reflect the covariance. ---------- Added file: http://bugs.python.org/file45606/frozenset-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 18:34:27 2016 From: report at bugs.python.org (Julien Palard) Date: Tue, 22 Nov 2016 23:34:27 +0000 Subject: [issue28772] Bus error in Python 3.6.0beta In-Reply-To: <1479818142.38.0.0931531711664.issue28772@psf.upfronthosting.co.za> Message-ID: <1479857667.69.0.95044101502.issue28772@psf.upfronthosting.co.za> Julien Palard added the comment: I can't reproduce the issue: $ ./python Python 3.6.0b4+ (default, Nov 23 2016, 00:23:59) [GCC 5.4.1 20160904] on linux Type "help", "copyright", "credits" or "license" for more information. >>> open('./python', 'rb') <_io.BufferedReader name='./python'> >>> But you may try, as Chi Hsuan Yen, with --with-pydebug, also try with faulthandler, and we'll gladly read the output for something like: $ strace /tmp/py36/bin/python -c "open('/tmp/py36/lib/libpython3.6m.so.1.0', 'rb')" 2>&1 | tail -n 20 Also, running it in gdb may provide a nice stacktrace, if you have nothing interesting from strace and faulthandler. ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 19:11:51 2016 From: report at bugs.python.org (Ned Deily) Date: Wed, 23 Nov 2016 00:11:51 +0000 Subject: [issue28757] Installation Failure In-Reply-To: <1479696577.66.0.987824550114.issue28757@psf.upfronthosting.co.za> Message-ID: <1479859911.32.0.787856266618.issue28757@psf.upfronthosting.co.za> Ned Deily added the comment: Just FYI, older python.org installer downloads for macOS, such as those provided for Python 3.2.x, used a now-obsolete installation package format that is no longer supported by the macOS installer app. Those installer downloads have file names that end with .dmg. More recent installer downloads are files ending with .pkg and should work OK. As Eric notes 3.2 is very old by Python 3 standards and its use should avoided. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 21:40:04 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 23 Nov 2016 02:40:04 +0000 Subject: [issue10414] Python does not work on an IPv6 only host In-Reply-To: <1289709318.9.0.235139859689.issue10414@psf.upfronthosting.co.za> Message-ID: <1479868804.81.0.519108725559.issue10414@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Reopening to expand upon this issue which is still a large problem: If you run on an IPv6-only Linux host, the following standard library tests all fail: test_asynchat, test_asyncio, test_asyncore, test_docxmlrpc, test_epoll, test_httpservers, test_logging, test_multiprocessing_fork, test_multiprocessing_forkserver, test_os, test_poplib, test_pydoc, test_robotparser, test_ssl, test_support, test_telnetlib, test_urllib2_localnet, test_urllib_response, test_uuid, test_xmlrpc I won't attempt to paste all of the errors into here but the errors have a few themes, here's a couple examples: ERROR: test_arp_getnode (test.test_uuid.TestUUID) ---------------------------------------------------------------------- Traceback (most recent call last): File "lib/python3.4/test/test_uuid.py", line 324, in test_arp_getnode node = uuid._arp_getnode() File "lib/python3.4/uuid.py", line 364, in _arp_getnode ip_addr = socket.gethostbyname(socket.gethostname()) socket.gaierror: [Errno -2] Name or service not known ERROR: test_getwelcome (test.test_poplib.TestPOP3Class) ---------------------------------------------------------------------- Traceback (most recent call last): File "lib/python3.4/test/test_poplib.py", line 246, in setUp self.server = DummyPOP3Server((HOST, PORT)) File "lib/python3.4/test/test_poplib.py", line 199, in __init__ self.create_socket(af, socket.SOCK_STREAM) File "lib/python3.4/asyncore.py", line 289, in create_socket sock = socket.socket(family, type) File "lib/python3.4/socket.py", line 126, in __init__ _socket.socket.__init__(self, family, type, proto, fileno) OSError: [Errno 97] Address family not supported by protocol (yes I know those are from an old 3.4 test suite run but code inspection of 3.6 shows that the underlying issues appear to remain) Someone will need to setup an IPv6 only host in order to work on these and can generate the full modern list of errors. It appears we have things that explicitly use IPv4 specific socket flags when unwarranted or use old API calls that don't deal with IPv6 at all, and represent IP addresses as strings within most of our standard library rather than adopting our own high level ipaddress module for API compatibility reasons. (see https://bugs.python.org/issue20215 regarding TCPServer not supporting IPv6 at all) Taking this on will keep Python relevant for the future without forcing people to jump through hoops or abandon the stdlib and only use third party networking libraries. ---------- nosy: +gregory.p.smith resolution: wont fix -> status: closed -> open title: socket.gethostbyname doesn't return an ipv6 address -> Python does not work on an IPv6 only host type: -> behavior versions: +Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 22 23:58:52 2016 From: report at bugs.python.org (Georgy) Date: Wed, 23 Nov 2016 04:58:52 +0000 Subject: [issue28777] asinc iter queue Message-ID: <1479877132.48.0.693527153069.issue28777@psf.upfronthosting.co.za> New submission from Georgy: adding to asyncio.Queue class following methods: def __aiter__(self): return self async def __anext__(self): return await self.get() let use asyncio.Queue follow: queue = asyncio.Queue() ... async for item in queue: do_something_with(item) ---------- components: asyncio messages: 281536 nosy: RekGRpth, gvanrossum, yselivanov priority: normal severity: normal status: open title: asinc iter queue type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 01:32:22 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 23 Nov 2016 06:32:22 +0000 Subject: [issue17343] Add a version of str.split which returns an iterator In-Reply-To: <1362359066.58.0.311917237277.issue17343@psf.upfronthosting.co.za> Message-ID: <1479882742.89.0.761241662475.issue17343@psf.upfronthosting.co.za> Raymond Hettinger added the comment: No one has submitted a patch for this or has expressed an interest in a long time. Perhaps the use case is already served by re.finditer() Unassigning. Feel free to push this forward or to close due to lack on interest. ---------- assignee: rhettinger -> versions: +Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 01:43:14 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 23 Nov 2016 06:43:14 +0000 Subject: [issue17577] Add lookahead/peek wrapper to itertools In-Reply-To: <1364600274.74.0.549757857069.issue17577@psf.upfronthosting.co.za> Message-ID: <1479883394.8.0.331440431248.issue17577@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This doesn't seem to have gained any traction and I haven't interest in the subject for years. Marking this as closed. If the topic takes on a new life, this can be reopened and we can revisit the idea. I don't think it would be hard to patch itertools.tee() to support indexing modeled on the patch above, but it is unclear whether it would be useful in practice or whether it would just be an attractive nuisance. (Note, we added copy support to tee() based on similar requests however this feature turned out to be ignored in practice). ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 01:48:41 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Nov 2016 06:48:41 +0000 Subject: [issue17343] Add a version of str.split which returns an iterator In-Reply-To: <1362359066.58.0.311917237277.issue17343@psf.upfronthosting.co.za> Message-ID: <1479883721.01.0.961788321794.issue17343@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 01:57:38 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 23 Nov 2016 06:57:38 +0000 Subject: [issue5384] mmap and exception type In-Reply-To: <1235755397.37.0.107266248804.issue5384@psf.upfronthosting.co.za> Message-ID: <1479884258.4.0.648867803125.issue5384@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Though the changes look like they would nicely harmonize mmap with other modules, I'm going to decline this patch. No one else has stepped forward to offer agreement and it likely isn't worth the disruption that would come from breaking existing code. Unfortunately, the time the fix-up an API is when it is proposed rather than years after the ship has already sailed. Charles-Fran?ois, thank you for the patch. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 01:59:18 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 23 Nov 2016 06:59:18 +0000 Subject: [issue17528] Implement dumps/loads for lru_cache In-Reply-To: <1364036381.48.0.635559042513.issue17528@psf.upfronthosting.co.za> Message-ID: <1479884358.67.0.119310544019.issue17528@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Marking this as rejected for the reasons mentions by me and Antoine. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 02:06:37 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 23 Nov 2016 07:06:37 +0000 Subject: [issue17528] Implement dumps/loads for lru_cache In-Reply-To: <1364036381.48.0.635559042513.issue17528@psf.upfronthosting.co.za> Message-ID: <1479884797.61.0.0889833670461.issue17528@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, the idea did have some merit and I appreciate your submitting it. The issues are that the net gain likely isn't worth the API complication, that it opens a can worms (about manipulating the cache contents beyond load and store), and that it is at odds with the core notion of being transparent. FWIW, the C version of OrderedDict now makes it trivially easy to roll your own highly performant variants of the LRU cache. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 03:09:29 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Nov 2016 08:09:29 +0000 Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup and groupindex In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za> Message-ID: <1479888569.07.0.698365705404.issue28765@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Following patch replaces abstract types API with concrete types API and makes the memory consumption of the pattern object smaller if there are no named groups. $ ./python -m perf timeit -s "import re; m = re.match('(?Pfirst) (?Psecond)', 'first second')" -- "m.lastgroup" Unpatched: Median +- std dev: 89.8 ns +- 1.8 ns Patched: Median +- std dev: 80.5 ns +- 3.3 ns $ ./python -m perf timeit -s "import re; m = re.match('(?Pfirst) (?Psecond)', 'first second')" -- "m.groupdict()" Unpatched: Median +- std dev: 803 ns +- 16 ns Patched: Median +- std dev: 711 ns +- 16 ns $ ./python -m perf timeit -s "import re; m = re.match('(?Pfirst) (?Psecond)', 'first second')" -- "m['first']" Unpatched: Median +- std dev: 228 ns +- 14 ns Patched: Median +- std dev: 217 ns +- 11 ns ---------- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett stage: -> patch review Added file: http://bugs.python.org/file45607/sre-concrete.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 03:16:58 2016 From: report at bugs.python.org (Mohammad Maaz Khan) Date: Wed, 23 Nov 2016 08:16:58 +0000 Subject: [issue16026] csv.DictReader argument names documented incorrectly In-Reply-To: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za> Message-ID: <1479889018.35.0.579424489001.issue16026@psf.upfronthosting.co.za> Mohammad Maaz Khan added the comment: Hi ?ric, I think the documentation should be changed to match the arguments' names. ---------- nosy: +maaz92 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 03:29:47 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 23 Nov 2016 08:29:47 +0000 Subject: [issue28773] typing.FrozenSet missing in documentation. In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za> Message-ID: <1479889787.46.0.478461297166.issue28773@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Thank you Manuel! LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 03:44:48 2016 From: report at bugs.python.org (Mohammad Maaz Khan) Date: Wed, 23 Nov 2016 08:44:48 +0000 Subject: [issue3687] Popen() object stdout attribute reassignment behaviour In-Reply-To: <1219766265.83.0.904411616188.issue3687@psf.upfronthosting.co.za> Message-ID: <1479890688.55.0.218006108677.issue3687@psf.upfronthosting.co.za> Mohammad Maaz Khan added the comment: Hi, I want to update the doc for this. This will be my first attempt to update the documentation. ---------- nosy: +maaz92 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 03:51:14 2016 From: report at bugs.python.org (RAUSHAN RAJ) Date: Wed, 23 Nov 2016 08:51:14 +0000 Subject: [issue28778] wsgiref HTTP Response Header Injection: CRLF Injection Message-ID: <1479891074.56.0.718206462594.issue28778@psf.upfronthosting.co.za> Changes by RAUSHAN RAJ : ---------- components: Library (Lib) nosy: RAUSHAN RAJ priority: normal severity: normal status: open title: wsgiref HTTP Response Header Injection: CRLF Injection type: security versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 03:52:52 2016 From: report at bugs.python.org (RAUSHAN RAJ) Date: Wed, 23 Nov 2016 08:52:52 +0000 Subject: [issue28778] wsgiref HTTP Response Header Injection: CRLF Injection Message-ID: <1479891172.05.0.173710900147.issue28778@psf.upfronthosting.co.za> New submission from RAUSHAN RAJ: https://www.owasp.org/index.php/CRLF_Injection Issue is in wsgiref.headers ? WSGI response header tools This module provides a single class, Headers, for convenient manipulation of WSGI response headers using a mapping-like interface. class wsgiref.headers.Headers(headers) Example: import wsgiref.headers as hd h=hd.Headers([]) h.add_header(' Content-type'+chr(10)+'set-cook:5', 'text/plain') h Headers([(' Content-type\nset-cook:5', 'text/plain')]) str(h) ' Content-type\nset-cook:5: text/plain\r\n\r\n' Response in Browser looks like this: Inline image 1 An attacker could use this flaw to inject additional headers in a Python application that allowed user provided header names or values. Also, No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace have led to security vulnerabilities in request routing and response handling. A server MUST reject any received request message that contains whitespace between a header field-name and colon with a response code of 400 (Bad Request). A proxy MUST remove any such whitespace from a response message before forwarding the message downstream. But add_header function allow whitespaces also. Tested for python 2.7.9 and python 3.5.1 For reference , it is related to (In this case request header injection is possible) https://bugs.python.org/issue22928 http://bugs.python.org/issue17322 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 04:21:43 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Nov 2016 09:21:43 +0000 Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup and groupindex In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za> Message-ID: <1479892903.12.0.078578682957.issue28765@psf.upfronthosting.co.za> STINNER Victor added the comment: sre-concrete.patch is wrong: if groupindex is a subtype of dict, you should use PyObject_GetItem. I like the idea of using PyDict_GetItem, you should just implement stricter checks in _sre.compile(). Maybe using PyDict_CheckExact? Since it's a private module, we don't have to support all types. It's ok to implement further optimizations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 04:40:48 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Nov 2016 09:40:48 +0000 Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup and groupindex In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za> Message-ID: <1479894048.12.0.540743615033.issue28765@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 1addc5d2c246 broke support of non-dict mappings, this patch brakes support of dict subclasses with overridden __getitem__. I think we can ignore this as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 04:47:37 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Nov 2016 09:47:37 +0000 Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup and groupindex In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za> Message-ID: <1479894457.96.0.5990943873.issue28765@psf.upfronthosting.co.za> STINNER Victor added the comment: Sorry, my comment is unclear: I'm only asking your to add PyDict_CheckExact check in _sre.compile() for sre-concrete.patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 05:05:08 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Nov 2016 10:05:08 +0000 Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup and groupindex In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za> Message-ID: <1479895508.0.0.00885379908313.issue28765@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Should we check that code is exact list? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 05:23:19 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Nov 2016 10:23:19 +0000 Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup and groupindex In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za> Message-ID: <1479896599.13.0.332248434841.issue28765@psf.upfronthosting.co.za> STINNER Victor added the comment: > Should we check that code is exact list? Do you mean a tuple for indexgroup? Yeah, it also seems worth it. I just checked: --- class Tuple(tuple): def __getitem__(self, index): return 9 a = Tuple([1, 2, 3]) print(a[0]) --- Output: --- 9 --- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 05:33:51 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 23 Nov 2016 10:33:51 +0000 Subject: [issue16026] csv.DictReader argument names documented incorrectly In-Reply-To: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za> Message-ID: <1479897231.02.0.757864475636.issue16026@psf.upfronthosting.co.za> Berker Peksag added the comment: James Salt's patch looks good to me, but it doesn't apply cleanly anymore. For the record, PyPy uses the same parameter name as Lib/csv.py: https://bitbucket.org/pypy/pypy/src/55a9404c80d6557854cac092addd92a6e0b683cc/lib-python/2.7/csv.py?at=default&fileviewer=file-view-default#csv.py-74 ---------- keywords: +easy -needs review nosy: +berker.peksag priority: normal -> low versions: +Python 3.5, Python 3.6, Python 3.7 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 05:35:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Nov 2016 10:35:12 +0000 Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup and groupindex In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za> Message-ID: <1479897312.42.0.951895014511.issue28765@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It is too. But I meant the code parameter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 05:53:36 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Nov 2016 10:53:36 +0000 Subject: [issue28775] Option to set startup directory in IDLE In-Reply-To: <1479837252.01.0.0581172301847.issue28775@psf.upfronthosting.co.za> Message-ID: <1479898416.63.0.0640128443744.issue28775@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree. I have had in mind (but cannot find an issue) to change the default to a user's home directory, as the best general default. But even that is not really the proper place that many would want. I can adapt and reuse the code used to browse and validate custom help files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 06:24:05 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 23 Nov 2016 11:24:05 +0000 Subject: [issue28532] Show sys.version when -V option is supplied twice. In-Reply-To: <1477417861.44.0.42778795289.issue28532@psf.upfronthosting.co.za> Message-ID: <1479900245.77.0.680759680839.issue28532@psf.upfronthosting.co.za> INADA Naoki added the comment: Elvis agreed to add "Other Improvements" section. (http://bugs.python.org/issue28635#msg281486) Here is new patch. ---------- Added file: http://bugs.python.org/file45608/vervose-version-doc2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 07:17:44 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 23 Nov 2016 12:17:44 +0000 Subject: [issue10049] Add a "no-op" (null) context manager to contextlib (Rejected: use contextlib.ExitStack()) In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za> Message-ID: <1479903464.32.0.715086350161.issue10049@psf.upfronthosting.co.za> Nick Coghlan added the comment: It turns out that there's a variant on the "null context manager" idea that may *not* be redundant with ExitStack(), and hence could potentially counter the current rationale for not adding one. Specifically, it relates to context managers like click.progressbar() that are designed to be used with an "as" clause: with click.progressbar(iterable) as myiter: for item in myiter: ... At the moment, making that optional is a bit messy, since you need to do something like: with click.progressbar(iterable) as myiter: if not show_progress: myiter = iterable # Don't use the special iterator for item in myiter: ... or: with ExitStack() as stack: if show_progress: myiter = stack.enter_context(click.progressbar(iterable)) else: myiter = iter(iterable) for item in myiter: ... or: @contextmanager def maybe_show_progress(iterable, show_progress) if show_progress: with click.progressbar(iterable) as myiter: yield myiter else: yield iter(iterable) with maybe_show_progress(iterable, show_progress) as myiter: for item in myiter: ... The problem is that there's no easy way to say "return *this* value from __enter__, but otherwise don't do anything special". With a suitably defined NullContext, that last approach could instead look more like: if show_progress: ctx = click.progressbar(iterable) else: ctx = NullContext(iter(iterable)) with ctx as myiter: for item in myiter: ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 07:19:27 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Nov 2016 12:19:27 +0000 Subject: [issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1 In-Reply-To: <1479824962.83.0.769019580096.issue28774@psf.upfronthosting.co.za> Message-ID: <20161123121924.89488.92554.D85A5CB1@psf.io> Roundup Robot added the comment: New changeset 3d660ed2a60e by Xiang Zhang in branch 'default': Issue #28774: Fix start/end pos in unicode_encode_ucs1(). https://hg.python.org/cpython/rev/3d660ed2a60e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 07:22:11 2016 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 23 Nov 2016 12:22:11 +0000 Subject: [issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1 In-Reply-To: <1479824962.83.0.769019580096.issue28774@psf.upfronthosting.co.za> Message-ID: <1479903731.55.0.461618736129.issue28774@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks Serhiy and Victor. Finished my first commit. :-) Now assign back to Serhiy and pos2 LGTM. ---------- assignee: xiang.zhang -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 08:03:45 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Nov 2016 13:03:45 +0000 Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup and groupindex In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za> Message-ID: <1479906225.14.0.110474816089.issue28765@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch restricts _sre.compile() to accepting only exact collection types. I don't like this patch. ---------- Added file: http://bugs.python.org/file45609/sre-concrete-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 08:07:25 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Nov 2016 13:07:25 +0000 Subject: [issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1 In-Reply-To: <1479824962.83.0.769019580096.issue28774@psf.upfronthosting.co.za> Message-ID: <1479906445.0.0.106505092422.issue28774@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Congratulations, Xiang! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 08:15:46 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Nov 2016 13:15:46 +0000 Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup and groupindex In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za> Message-ID: <1479906946.36.0.759735787854.issue28765@psf.upfronthosting.co.za> STINNER Victor added the comment: > It is too. But I meant the code parameter. Oh ok. It seems like we use PyList_xxx() functions, so yeah, it seems safer (to respect the Python semantics) to only accept exactly the list type. > Updated patch restricts _sre.compile() to accepting only exact collection types. I don't like this patch. Why not? Do you prefer to accept subtypes? sre-concrete-2.patch LGTM, I just added a minor comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 08:17:32 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Nov 2016 13:17:32 +0000 Subject: [issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1 In-Reply-To: <1479824962.83.0.769019580096.issue28774@psf.upfronthosting.co.za> Message-ID: <20161123131728.89721.8941.A66A4697@psf.io> Roundup Robot added the comment: New changeset 3addf93f4111 by Serhiy Storchaka in branch 'default': Issue #28774: Simplified encoding a str result of an error handler in ASCII https://hg.python.org/cpython/rev/3addf93f4111 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 08:19:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Nov 2016 13:19:32 +0000 Subject: [issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1 In-Reply-To: <1479824962.83.0.769019580096.issue28774@psf.upfronthosting.co.za> Message-ID: <1479907172.17.0.0181761065974.issue28774@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 08:32:59 2016 From: report at bugs.python.org (Julien Palard) Date: Wed, 23 Nov 2016 13:32:59 +0000 Subject: [issue28753] Clinic: Converting Your First Function is not up to date In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za> Message-ID: <1479907979.32.0.873425620246.issue28753@psf.upfronthosting.co.za> Julien Palard added the comment: Reopening to remind @Victor we have a question about METH_FASTCALL. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 08:33:40 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Nov 2016 13:33:40 +0000 Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup and groupindex In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za> Message-ID: <1479908020.11.0.229317278615.issue28765@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't like it because it adds a cumbersome code for guarding against a case that doesn't happen in practice. This is just unpythonic. _sre.compile() is a private function and it is called only with exact types. Even if it would called with subtypes, most subtypes don't override __len__ and __getitem__. This restriction is too strong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 10:26:41 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Nov 2016 15:26:41 +0000 Subject: [issue28779] set_forkserver_preload() can crash the forkserver if preloaded module instantiate multiprocessing classes Message-ID: <1479914801.47.0.114591938702.issue28779@psf.upfronthosting.co.za> New submission from Antoine Pitrou: The following script: import multiprocessing import os def f(): pass multiprocessing.Lock() if __name__ == "__main__": ctx = multiprocessing.get_context('forkserver') # modname is the script's importable name (not "__main__") modname = os.path.basename(__file__).split(".")[0] ctx.set_forkserver_preload([modname]) proc = ctx.Process(target=f) proc.start() proc.join() Fails with the following error: Traceback (most recent call last): File "/home/antoine/miniconda3/envs/dask35/lib/python3.5/multiprocessing/forkserver.py", line 178, in main _serve_one(s, listener, alive_r, handler) File "/home/antoine/miniconda3/envs/dask35/lib/python3.5/multiprocessing/forkserver.py", line 212, in _serve_one code = spawn._main(child_r) File "/home/antoine/miniconda3/envs/dask35/lib/python3.5/multiprocessing/spawn.py", line 115, in _main prepare(preparation_data) File "/home/antoine/miniconda3/envs/dask35/lib/python3.5/multiprocessing/spawn.py", line 221, in prepare set_start_method(data['start_method']) File "/home/antoine/miniconda3/envs/dask35/lib/python3.5/multiprocessing/context.py", line 231, in set_start_method raise RuntimeError('context has already been set') RuntimeError: context has already been set This makes set_forkserver_preload() quite fragile if you preload any library that may create multiprocessing resources (such as locks) at the top level. ---------- components: Library (Lib) messages: 281565 nosy: davin, pitrou, sbt priority: normal severity: normal stage: needs patch status: open title: set_forkserver_preload() can crash the forkserver if preloaded module instantiate multiprocessing classes type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 10:27:46 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Nov 2016 15:27:46 +0000 Subject: [issue28779] set_forkserver_preload() can crash the forkserver if preloaded module instantiate multiprocessing classes In-Reply-To: <1479914801.47.0.114591938702.issue28779@psf.upfronthosting.co.za> Message-ID: <1479914866.61.0.441094271247.issue28779@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The example above works if you comment out either the "Lock()" line or the "set_forkserver_preload()" line. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 10:34:51 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Wed, 23 Nov 2016 15:34:51 +0000 Subject: [issue27761] Private _nth_root function loses accuracy In-Reply-To: <1471141583.56.0.32662922065.issue27761@psf.upfronthosting.co.za> Message-ID: <1479915291.68.0.989176937122.issue27761@psf.upfronthosting.co.za> Changes by Wolfgang Maier : ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 11:18:23 2016 From: report at bugs.python.org (Mark Wood) Date: Wed, 23 Nov 2016 16:18:23 +0000 Subject: [issue28780] netrc throws NetrcParseError for record without 'password' Message-ID: <1479917903.22.0.642970878487.issue28780@psf.upfronthosting.co.za> New submission from Mark Wood: netrc.netrc() throws a NetrcParseError if ~/.netrc contains an entry witout a 'password' field. Other users of .netrc do not do this. In my case, I have entries for sftp hosts which will use public-key authentication instead of a password. What I would suggest is that if any or all of 'login', 'account', and 'password' are omitted, simply accept that and store a 0-length string. Someone on StackOverflow says he has rewritten netrc to fix various problems but doesn't know how to contribute it. http://stackoverflow.com/questions/28754547/python-netrc-error-on-file-with-comment ---------- components: Library (Lib) messages: 281567 nosy: Mark Wood priority: normal severity: normal status: open title: netrc throws NetrcParseError for record without 'password' type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 11:18:59 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 23 Nov 2016 16:18:59 +0000 Subject: [issue28714] Addition to Documentation of configparser.ConfigParser.write() In-Reply-To: <1479308435.4.0.112292626323.issue28714@psf.upfronthosting.co.za> Message-ID: <1479917939.46.0.651580349303.issue28714@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report, George. Using 'r+' means that you don't have to reopen the same file if you want to both read and write to it but it's up to you to check where the cursor is before writing anything to it. Since the ConfigParser.write() method doesn't have any control over the file object (and this is not the only place that someone can pass a file object in the stdlib), I don't think we should make its documentation more complicated. I wouldn't strongly object adding a short sentence about the behavior of the + mode if someone wants to write a patch. Doc/tutorial/inputoutput.rst or Doc/library/functions.rst might be a good place to put that information. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 11:25:51 2016 From: report at bugs.python.org (Mark Harris) Date: Wed, 23 Nov 2016 16:25:51 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message Message-ID: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> New submission from Mark Harris: While I am installing python when it gets towards the end of the installation the message appears "The program can't start because python35.dll is missing from your computer. Try reinstalling the program to fix this problem". Apart from this message the installation finishes successfully. When I type python into the command prompt the message appears again. I've tried as suggested installing again, it was installing to my local file C:\Users\myusername\AppData\Local\Programs\Python\Python35-32 so I thought it might be something to do with the path not being setting up correctly and have tried several locations. The installer doesn't seem to be adding the PATH file on installation to the system as well. This all started because pip stopped working and I was trying to re-install to resolve the problem. Any suggestions on a fix? Thanks, Mark ---------- components: Installation messages: 281569 nosy: Marcopolo priority: normal severity: normal status: open title: On Installation of 3.5 Python get error message type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 11:33:41 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Nov 2016 16:33:41 +0000 Subject: [issue28779] set_forkserver_preload() can crash the forkserver if preloaded module instantiate multiprocessing classes In-Reply-To: <1479914801.47.0.114591938702.issue28779@psf.upfronthosting.co.za> Message-ID: <1479918821.74.0.0649644523133.issue28779@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file45610/forkserver_preload.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 11:34:27 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Nov 2016 16:34:27 +0000 Subject: [issue28779] set_forkserver_preload() can crash the forkserver if preloaded module instantiate multiprocessing classes In-Reply-To: <1479914801.47.0.114591938702.issue28779@psf.upfronthosting.co.za> Message-ID: <1479918867.42.0.398412117513.issue28779@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 11:35:01 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Nov 2016 16:35:01 +0000 Subject: [issue28779] set_forkserver_preload() can crash the forkserver if preloaded module instantiate multiprocessing classes In-Reply-To: <1479914801.47.0.114591938702.issue28779@psf.upfronthosting.co.za> Message-ID: <1479918901.21.0.0844271562191.issue28779@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file45610/forkserver_preload.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 11:35:08 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Nov 2016 16:35:08 +0000 Subject: [issue28779] set_forkserver_preload() can crash the forkserver if preloaded module instantiate multiprocessing classes In-Reply-To: <1479914801.47.0.114591938702.issue28779@psf.upfronthosting.co.za> Message-ID: <1479918908.11.0.253221009138.issue28779@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Added file: http://bugs.python.org/file45611/forkserver_preload.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 11:37:11 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 23 Nov 2016 16:37:11 +0000 Subject: [issue28722] doctest example exit status In-Reply-To: <1479345580.78.0.277825169146.issue28722@psf.upfronthosting.co.za> Message-ID: <1479919031.22.0.277734688829.issue28722@psf.upfronthosting.co.za> Berker Peksag added the comment: Hi Rajiv, thanks for the report, but this is already possible by default. I will use the factorial example from https://docs.python.org/3.5/library/doctest.html to demonstrate it: $ python -m doctest example.py $ echo $? 0 Now change the following line >>> [factorial(n) for n in range(6)] to >>> [factorial(n) for n in range(5)] and run the script again: $ python -m doctest example.py [...] ***Test Failed*** 1 failures. $ echo $? 1 ---------- nosy: +berker.peksag resolution: -> not a bug stage: -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 12:29:55 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Wed, 23 Nov 2016 17:29:55 +0000 Subject: [issue22298] Lib/warnings.py _show_warning does not protect against being called with a file like object which is closed In-Reply-To: <1409315343.62.0.0672695786427.issue22298@psf.upfronthosting.co.za> Message-ID: <1479922195.17.0.148510320601.issue22298@psf.upfronthosting.co.za> Wolfgang Maier added the comment: Issue23016 fixed the "AttributeError: 'NoneType' object has no attribute 'write'" problem when sys.stderr is None. With that it's now possible and good practice to set sys.stderr = None when closing it, just as Antoine suggested. Should this issue be closed then? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 12:47:18 2016 From: report at bugs.python.org (Doug Hellmann) Date: Wed, 23 Nov 2016 17:47:18 +0000 Subject: [issue9216] FIPS support for hashlib In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za> Message-ID: <1479923238.28.0.456110746664.issue9216@psf.upfronthosting.co.za> Changes by Doug Hellmann : ---------- nosy: +doughellmann _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 12:56:05 2016 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 23 Nov 2016 17:56:05 +0000 Subject: [issue9216] FIPS support for hashlib In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za> Message-ID: <1479923765.33.0.988921479287.issue9216@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: -gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 13:03:27 2016 From: report at bugs.python.org (Martin Richard) Date: Wed, 23 Nov 2016 18:03:27 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine Message-ID: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> New submission from Martin Richard: Hi, I stumbled upon a SEGFAULT while trying Python 3.6.0 on a project using asyncio. I can't really figure out what's happening, so I reduced the original code triggering the bug down to a reproducible case (which looks a bit clunky, sorry). The case has been tested on two Linux systems (Archlinux and Debian), and with several versions of Python. The bug appears between 3.6.0a4 (most recent version tested not affected) and 3.60b1 (so before the C asyncio module I believe), and is not fixed in the current repository tip (changeset: 105345:3addf93f4111). I also produced a traceback using gdb (see bellow). The segfault happens around the "await" in the body of Cursor._read_data(), interestingly, if I change anything in the body of the method, the SEGFAULT disappears and the code works as expected. Also, it seems that calling it from an other coroutine (main() in the example) is required to trigger the bug. Cheers, Martin Case (also attached as test.py) : import asyncio loop = asyncio.get_event_loop() class Connection: def read_until(self, *args, **kwargs): return self async def all(self): return b"\n" class Cursor: def __init__(self): self._connection = Connection() self._max_bytes = 100 self._data = bytearray() async def _read_data(self): # XXX segfault there, if I change anything in the code, it works... while True: data = await self._connection.read_until( b'\n', max_bytes=self._max_bytes).all() self._max_bytes -= len(data) if data == b'\n': break self._data.extend(data) async def main(): await Cursor()._read_data() loop.run_until_complete(main()) Traceback extract (with Python3.6.0b4, --with-pydebug on Linux): Program received signal SIGSEGV, Segmentation fault. 0x000000000046d177 in _PyGen_yf (gen=gen at entry=0x7ffff34bdaf8) at Objects/genobject.c:361 361 Py_INCREF(yf); (gdb) bt #0 0x000000000046d177 in _PyGen_yf (gen=gen at entry=0x7ffff34bdaf8) at Objects/genobject.c:361 #1 0x000000000052f49c in _PyEval_EvalFrameDefault (f=0x7ffff67067d8, throwflag=) at Python/ceval.c:1992 #2 0x000000000052a0fc in PyEval_EvalFrameEx (f=f at entry=0x7ffff67067d8, throwflag=throwflag at entry=0) at Python/ceval.c:718 #3 0x000000000046d393 in gen_send_ex (gen=gen at entry=0x7ffff34bdc08, arg=, exc=exc at entry=0, closing=closing at entry=0) at Objects/genobject.c:189 #4 0x000000000046de8d in _PyGen_Send (gen=gen at entry=0x7ffff34bdc08, arg=) at Objects/genobject.c:308 #5 0x00007ffff384ba2c in task_step_impl (task=task at entry=0x7ffff3263bd8, exc=exc at entry=0x0) at (...)/Python-3.6.0b4/Modules/_asynciomodule.c:1963 #6 0x00007ffff384c72e in task_step (task=0x7ffff3263bd8, exc=0x0) at (...)/Python-3.6.0b4/Modules/_asynciomodule.c:2247 #7 0x00007ffff384ca79 in task_call_step (arg=, task=) at (...)/Python-3.6.0b4/Modules/_asynciomodule.c:1848 #8 TaskSendMethWrapper_call (o=, args=, kwds=) at (...)/Python-3.6.0b4/Modules/_asynciomodule.c:1167 #9 0x0000000000446702 in PyObject_Call (func=0x7ffff37d7f60, args=0x7ffff7fb8058, kwargs=0x0) at Objects/abstract.c:2246 #10 0x00000000005295c8 in do_call_core (func=func at entry=0x7ffff37d7f60, callargs=callargs at entry=0x7ffff7fb8058, kwdict=kwdict at entry=0x0) at Python/ceval.c:5054 #11 0x0000000000534c64 in _PyEval_EvalFrameDefault (f=0xb4cb48, throwflag=) at Python/ceval.c:3354 #12 0x000000000052a0fc in PyEval_EvalFrameEx (f=f at entry=0xb4cb48, throwflag=throwflag at entry=0) at Python/ceval.c:718 #13 0x000000000052a1cc in _PyFunction_FastCall (co=, args=0xb4c5b0, nargs=nargs at entry=1, globals=) at Python/ceval.c:4867 (...) ---------- components: Interpreter Core files: test.py messages: 281573 nosy: martius, yselivanov priority: normal severity: normal status: open title: SEGFAULT when running a given coroutine type: crash versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45612/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 13:06:02 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Nov 2016 18:06:02 +0000 Subject: [issue28722] doctest example exit status In-Reply-To: <1479345580.78.0.277825169146.issue28722@psf.upfronthosting.co.za> Message-ID: <1479924362.56.0.863509247374.issue28722@psf.upfronthosting.co.za> R. David Murray added the comment: Rajiv is suggesting an improvement to the documentation. I think it is a reasonable thought, but probably not a good idea on closer examination. The example introduces the basic doctest concepts, and goes on to say that this is not the mostly likely way to make use of doctest (and indeed it is not common). So complicating the example and the explanation would be counterproductive to the intent of the text, in my opinion. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 13:10:14 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Nov 2016 18:10:14 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> Message-ID: <1479924614.58.0.139197215012.issue28782@psf.upfronthosting.co.za> R. David Murray added the comment: I'm marking this as a release blocker since it is a (new) segfault. ---------- nosy: +ned.deily, r.david.murray priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 13:29:44 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Nov 2016 18:29:44 +0000 Subject: [issue28783] Embedded/nuget packages incorrectly reference bdist_wininst Message-ID: <1479925784.02.0.834073933599.issue28783@psf.upfronthosting.co.za> New submission from Steve Dower: For the embedded zip and nuget releases, I've omitted bdist_wininst. However, I forgot to remove the reference to it from distutils.command.__init__.__all__, and so setuptools will occasionally crash trying to import it. This patch updates Tools/msi/make_zip.py to exclude the default distutils.command.__init__ and substitute a copy that does not have the added reference in it. Doing something "smarter" in the actual Lib/distutils/command/__init__.py isn't really an option. The only reliable option is to import the module eagerly, which I don't want to do. Including bdist_wininst in these packages is also a bad option (I considered completely removing distutils from them, but it has *some* uses - can't say the same for bdist_wininst though). Ned - I'd like to apply this change to 3.6. The patch is against 3.5, and there may be some subtle differences when I merge it forward (not every change to make_zip.py has been backported), but the intent is well captured here. If this is not applied to 3.6, then the packages will not be reliably usable with pip/setuptools, which is one of the intended uses (particularly for the nuget package). ---------- assignee: steve.dower components: Windows files: no_bdist_wininst.patch keywords: patch messages: 281576 nosy: ned.deily, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: patch review status: open title: Embedded/nuget packages incorrectly reference bdist_wininst type: behavior versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45613/no_bdist_wininst.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 13:34:34 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Nov 2016 18:34:34 +0000 Subject: [issue28783] Embedded/nuget packages incorrectly reference bdist_wininst In-Reply-To: <1479925784.02.0.834073933599.issue28783@psf.upfronthosting.co.za> Message-ID: <1479926074.54.0.455564339159.issue28783@psf.upfronthosting.co.za> Steve Dower added the comment: The full fix may also require updating setuptools, which I'm pursuing, but we also should stop referring to a module that isn't there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 13:51:54 2016 From: report at bugs.python.org (Ned Deily) Date: Wed, 23 Nov 2016 18:51:54 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1479927114.66.0.0366331345289.issue28781@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 13:57:37 2016 From: report at bugs.python.org (Ned Deily) Date: Wed, 23 Nov 2016 18:57:37 +0000 Subject: [issue28783] Embedded/nuget packages incorrectly reference bdist_wininst In-Reply-To: <1479925784.02.0.834073933599.issue28783@psf.upfronthosting.co.za> Message-ID: <1479927457.19.0.986576106445.issue28783@psf.upfronthosting.co.za> Ned Deily added the comment: I'd like one of the other Windows folks to review it but, in principle, LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 14:00:53 2016 From: report at bugs.python.org (Irmen de Jong) Date: Wed, 23 Nov 2016 19:00:53 +0000 Subject: [issue28673] pyro4 with more than 15 threads often crashes 2.7.12 In-Reply-To: <1478939498.33.0.0967391900201.issue28673@psf.upfronthosting.co.za> Message-ID: <1479927653.06.0.420000520711.issue28673@psf.upfronthosting.co.za> Irmen de Jong added the comment: Due to lack of example code to reproduce the issue, and because I'm mildly interested in this bug because it mentions Pyro4 (because I'm the author of that) I've tried to crash my system myself using Pyro4 and a simple torture test but it trucked on just fine. Pyro4 is not doing any "strange" things as far as I am aware. It does have its own (simple) thread pool of regular Python threads that are handling incoming proxy connections. (Had Pyro4 been doing weird things I suppose Python itself still should never core dump on the user but rather raise a regular exception if something was wrong) ---------- nosy: +irmen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 14:06:13 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Nov 2016 19:06:13 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1479927973.02.0.180812825451.issue28781@psf.upfronthosting.co.za> Steve Dower added the comment: Do you see a "Repair" option when running the installer again? If not, open Programs and Features and find Python there, double-click it and select "Repair". Otherwise, you should have a set of log files in your %TEMP% directory (sort by date and they all start with "Python"). If you can bundle those up and attach them to this issue, I can take a closer look. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 14:17:31 2016 From: report at bugs.python.org (Paul Moore) Date: Wed, 23 Nov 2016 19:17:31 +0000 Subject: [issue28783] Embedded/nuget packages incorrectly reference bdist_wininst In-Reply-To: <1479925784.02.0.834073933599.issue28783@psf.upfronthosting.co.za> Message-ID: <1479928651.74.0.622388466599.issue28783@psf.upfronthosting.co.za> Paul Moore added the comment: I've had a look. I agree in principle with the change, and the code looks OK on inspection, although I can't really test it. As it's only a change to one of the scripts in tools/msi, this seems like a low-risk change to me, so I'm OK with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 14:25:30 2016 From: report at bugs.python.org (Ned Deily) Date: Wed, 23 Nov 2016 19:25:30 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> Message-ID: <1479929130.92.0.584385730611.issue28782@psf.upfronthosting.co.za> Ned Deily added the comment: FWIW, hg bisect finds: changeset 103444:a77756e480c2: bad The first bad revision is: changeset: 103444:a77756e480c2 parent: 103442:914a81781291 user: Victor Stinner date: Fri Sep 09 10:17:08 2016 -0700 summary: Rework CALL_FUNCTION* opcodes Also, FWIW, the successful runs prior to this revision report: base_events.py:481: ResourceWarning: unclosed event loop <_UnixSelectorEventLoop running=False closed=False debug=False> ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 14:38:49 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Nov 2016 19:38:49 +0000 Subject: [issue28783] Embedded/nuget packages incorrectly reference bdist_wininst In-Reply-To: <1479925784.02.0.834073933599.issue28783@psf.upfronthosting.co.za> Message-ID: <1479929929.9.0.85666740019.issue28783@psf.upfronthosting.co.za> Steve Dower added the comment: A convenient test is: python.exe -c "import distutils.core; distutils.core.setup()" --help-comm ands Without the fix, it raises "distutils.errors.DistutilsModuleError: invalid command 'bdist_wininst'". But yes, unfortunately the fix is not particularly direct here. I've validated that it works, and since it really only has to work on my machine (right now) that's actually pretty good coverage :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 15:23:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Nov 2016 20:23:33 +0000 Subject: [issue28783] Embedded/nuget packages incorrectly reference bdist_wininst In-Reply-To: <1479925784.02.0.834073933599.issue28783@psf.upfronthosting.co.za> Message-ID: <20161123202329.90294.6770.21ED450C@psf.io> Roundup Robot added the comment: New changeset f7aa200bed8d by Steve Dower in branch '3.5': Issue #28783: Embedded and nuget packages incorrect reference missing bdist_wininst command. https://hg.python.org/cpython/rev/f7aa200bed8d New changeset a3755890545c by Steve Dower in branch '3.6': Issue #28783: Embedded and nuget packages incorrect reference missing bdist_wininst command. https://hg.python.org/cpython/rev/a3755890545c New changeset 831f73efe3a6 by Steve Dower in branch 'default': Issue #28783: Embedded and nuget packages incorrect reference missing bdist_wininst command. https://hg.python.org/cpython/rev/831f73efe3a6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 15:25:02 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Nov 2016 20:25:02 +0000 Subject: [issue28783] Embedded/nuget packages incorrectly reference bdist_wininst In-Reply-To: <1479925784.02.0.834073933599.issue28783@psf.upfronthosting.co.za> Message-ID: <1479932702.84.0.0883811365114.issue28783@psf.upfronthosting.co.za> Steve Dower added the comment: Thanks. For reference, the setuptools issue is https://github.com/pypa/setuptools/issues/857 A setuptools install from source should be fixed by this change, though an install from a wheel (which is now typical, unfortunately) requires a separate fix. But we've done our part now. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 15:57:26 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Wed, 23 Nov 2016 20:57:26 +0000 Subject: [issue10379] locale.format() input regression In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za> Message-ID: <1479934646.85.0.0802745210488.issue10379@psf.upfronthosting.co.za> Changes by Wolfgang Maier : ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 16:14:52 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 23 Nov 2016 21:14:52 +0000 Subject: [issue28532] Show sys.version when -V option is supplied twice. In-Reply-To: <1477417861.44.0.42778795289.issue28532@psf.upfronthosting.co.za> Message-ID: <1479935692.39.0.557814884748.issue28532@psf.upfronthosting.co.za> Martin Panter added the comment: Looks good to me ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 16:26:30 2016 From: report at bugs.python.org (Zac Medico) Date: Wed, 23 Nov 2016 21:26:30 +0000 Subject: [issue28682] Bytes support in os.fwalk() In-Reply-To: <1479029050.5.0.426622691368.issue28682@psf.upfronthosting.co.za> Message-ID: <1479936390.07.0.68711067675.issue28682@psf.upfronthosting.co.za> Changes by Zac Medico : ---------- nosy: +zmedico _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 16:40:08 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 23 Nov 2016 21:40:08 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> Message-ID: <1479937208.51.0.176466790047.issue28782@psf.upfronthosting.co.za> Yury Selivanov added the comment: Wow, Martin, this is a very interesting one. Thanks so much for tracking this down and reducing the test case. So far this doesn't seem to be related to async/await: the interpreter stack seems to enter some strange state under some conditions, and async/await just happens to be the thing that explodes. To those trying to debug this: you don't need asyncio, just replace `loop.run_until_complete(main())` with `main().send(None)`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 16:42:46 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 23 Nov 2016 21:42:46 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> Message-ID: <1479937366.25.0.597268924825.issue28782@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 17:03:43 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Nov 2016 22:03:43 +0000 Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup and groupindex In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za> Message-ID: <1479938623.47.0.392808211305.issue28765@psf.upfronthosting.co.za> STINNER Victor added the comment: > I don't like it because it adds a cumbersome code for guarding against a case that doesn't happen in practice. Hum, sorry, I don't understand what is the issue with adding a few addition checks in the constructor? Is it a matter of speed? > This is just unpythonic. Wait, what? I asked you to add checks to not break the Python semantics. If you want to be "Pythonic": you must support the Python semantics, so support when __getitem__, __len__, etc. are replaced. I don't understand your "unpythonic" argument. > _sre.compile() is a private function and it is called only with exact types. Right. So what is the problem with adding more sanity checks? > Even if it would called with subtypes, most subtypes don't override __len__ and __getitem__. This restriction is too strong. It's a matter of respecting the Python semantics. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 17:04:10 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Nov 2016 22:04:10 +0000 Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup and groupindex In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za> Message-ID: <1479938650.89.0.0225022995445.issue28765@psf.upfronthosting.co.za> STINNER Victor added the comment: An optimization must not change the behaviour of Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 17:15:56 2016 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 23 Nov 2016 22:15:56 +0000 Subject: [issue10379] locale.format() input regression In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za> Message-ID: <1479939356.57.0.836739689668.issue10379@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 18:03:27 2016 From: report at bugs.python.org (paul j3) Date: Wed, 23 Nov 2016 23:03:27 +0000 Subject: [issue28742] argparse.ArgumentDefaultsHelpFormatter sometimes provides inaccurate documentation of defaults, so they should be overrideable In-Reply-To: <1479514629.23.0.218870455687.issue28742@psf.upfronthosting.co.za> Message-ID: <1479942207.14.0.969948632755.issue28742@psf.upfronthosting.co.za> paul j3 added the comment: I might accept a patch that tweaks the ArgumentDefaultsHelpFormatter class, but adding a parameter that must propagate through all the Action classes in just plain wrong. Users are confused by the many Action parameters as it is. And based on StackOverFlow questions, I'd say there are lots of custom Action classes. We cannot make a change that might break those! One possibility is to tweak the `%(default)s` test to something like: if '(default` not in action.help: Then the user who is not happy with the '%(default)s` display could just write a help like: help = 'my help text (default: mycustomvalue)' In other words, embed the bypass mechanism entirely in the 'help' string and the Formatter class. The mechanism would have to be something that is simple to explain, and be unlikely to interfere with existing uses of this Formatter. And to play it safe, I'd suggest field testing a SmarterDefaultsHelpFormatter class first - one that implements a change like this, without touching the existing class. Keep in mind that ArgumentDefaultsHelpFormatter is never essential. The argparse developer can always add the '%(default)s` strings to selected 'help' lines. He can even do this in utility functions that know more about the underlying program semantics. I don't think this proposed enhancement gives the end user any added control. If you want to make a stronger case for this enhancement, find other cases where it would be useful. So far you are just arguing that '(default= True)' for a 'store_false' Action may convey the wrong sense to users. As r.david.murray argued, this problem can be minimized with a proper phrasing of the help string. Another thought - 'store_false' is just a subclass of 'store_const'. You could use that class instead with a different set of 'const' and 'default' values. e.g. ('Yes','No', or 'not-False', 'not-True'). ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 18:11:25 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Nov 2016 23:11:25 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> Message-ID: <1479942685.52.0.69692262522.issue28782@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh wow, the bug is tricky. _PyGen_yf() checks if the next instruction is YIELD_FROM using code[f_lasti+2]. The problem is that WORDCODE kept f_lasti == -1 for a frame not executed yet: f_lasti+2 is 1 in this case. Problem: code[1] is not an operation code, but the argment. Python 3.6 bytecode now uses the "wordcode" format: 16-bit units of (operation, argument). The obvious and simple fix is to add a special case for f_lasti==-1 in _PyGen_yf(): see attached patch. pygen_yf.patch fixes the crash. -- Another much larger change would be to change f_lasti to -2... In the rewiew of the huge WORDCODE patch, if I recall correctly, I asked Demur to use -1 for backward compatibility. Or maybe I asked to kept the backward compatibility at the Python level using a getter converting -2 to -1... I don't recall correctly. See http://bugs.python.org/issue26647 for wordcode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 18:11:37 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Nov 2016 23:11:37 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> Message-ID: <1479942697.66.0.382149955725.issue28782@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- keywords: +patch Added file: http://bugs.python.org/file45614/pygen_yf.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 18:12:34 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Nov 2016 23:12:34 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> Message-ID: <1479942754.8.0.440249810733.issue28782@psf.upfronthosting.co.za> STINNER Victor added the comment: It would be nice if Demur Rumed and/or Serhiy Storchaka can review pygen_yf.patch since Demur wrote the wordcode patch and Serhiy reviewed the wordcode patch. ---------- nosy: +Demur Rumed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 18:19:47 2016 From: report at bugs.python.org (paul j3) Date: Wed, 23 Nov 2016 23:19:47 +0000 Subject: [issue27153] Default value shown by argparse.ArgumentDefaultsHelpFormatter is backwards for action='store_false' In-Reply-To: <1464539974.48.0.860363682331.issue27153@psf.upfronthosting.co.za> Message-ID: <1479943187.87.0.475854019868.issue27153@psf.upfronthosting.co.za> Changes by paul j3 : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 18:57:51 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Nov 2016 23:57:51 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> Message-ID: <1479945471.27.0.71643660635.issue28782@psf.upfronthosting.co.za> STINNER Victor added the comment: > Another much larger change would be to change f_lasti to -2... Attached lasti.patch implements this idea. I consider that it makes the C code simpler because getting the next instruction (f_lasti + 2) doesn't require a special case anymore. My patch keeps f_lasti == -1 at the Python level for backward compatibility. lasti.patch is only a backward incompatible change at the C level. -- Between pygen_yf.patch and lasti.patch, I prefer lasti.patch even if 3.6 is at its last beta version before the final version. I prefer to fix the C API. Later it will be much harder to fix it. -- I read again the wordcode issue #26647: I wrote on the review of wpy7.patch: "The overall change LGTM, but I'm no more 100% sure that starting f_lasti=-1 is safe." http://bugs.python.org/review/26647/#msg17 I wrote: "IMHO it's ok to break the C API, but I would prefer to keep the backward compatibility for the Python API (replace any negative number with -1 for the Python API)." http://bugs.python.org/issue26647#msg262758 Serhiy: "I think we should make yet few related changes: (...) * Change f_lasti, tb_lasti etc to count code units instead of bytes." http://bugs.python.org/issue26647#msg262758 ---------- Added file: http://bugs.python.org/file45615/lasti.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 19:38:00 2016 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 24 Nov 2016 00:38:00 +0000 Subject: [issue10379] locale.format() input regression In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za> Message-ID: <1479947880.24.0.155203545507.issue10379@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- assignee: docs at python -> keywords: +easy stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 19:53:02 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 24 Nov 2016 00:53:02 +0000 Subject: [issue28773] typing.FrozenSet missing in documentation. In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za> Message-ID: <1479948782.54.0.669748526271.issue28773@psf.upfronthosting.co.za> Guido van Rossum added the comment: Ned: does the ban on non-critical commits to the 3.6 branch also apply to doc patches? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 20:06:24 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 24 Nov 2016 01:06:24 +0000 Subject: [issue25701] Document that tp_setattro and tp_setattr are used for deleting attributes In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za> Message-ID: <1479949584.0.0.762705484703.issue25701@psf.upfronthosting.co.za> Martin Panter added the comment: The 2.7 patch looks okay to me. I confirmed that sq_ass_slice gets called to delete slices, and I presume the other stuff is similar to Python 3. Do you want to commit this to 2.7 Serhiy? ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 20:19:07 2016 From: report at bugs.python.org (Ned Deily) Date: Thu, 24 Nov 2016 01:19:07 +0000 Subject: [issue28773] typing.FrozenSet missing in documentation. In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za> Message-ID: <1479950347.55.0.658217507055.issue28773@psf.upfronthosting.co.za> Ned Deily added the comment: Guido, doc fixes are welcome! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 21:02:49 2016 From: report at bugs.python.org (Demur Rumed) Date: Thu, 24 Nov 2016 02:02:49 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> Message-ID: <1479952969.03.0.170645181163.issue28782@psf.upfronthosting.co.za> Demur Rumed added the comment: I had considered this, for some reason I didn't realize code[1] could be equal to YIELD_FROM, felt it'd always be false f_lasti being -2 has always been my preference, lasti.patch lgtm ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 21:06:27 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 24 Nov 2016 02:06:27 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> Message-ID: <1479953187.72.0.122878991978.issue28782@psf.upfronthosting.co.za> Yury Selivanov added the comment: > f_lasti being -2 has always been my preference, lasti.patch lgtm How about we commit pygen_yf.patch to 3.6 and whatever else in 3.7? lasti.patch is too invasive for 3.6 at this point, -1 for it in 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 21:36:45 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 24 Nov 2016 02:36:45 +0000 Subject: [issue28771] Update documented signatures of tp_get/setattr In-Reply-To: <1479815588.93.0.810601241454.issue28771@psf.upfronthosting.co.za> Message-ID: <1479955005.21.0.298201834021.issue28771@psf.upfronthosting.co.za> Martin Panter added the comment: In Python 2, charbufferproc was changed to use non-const char ** in revision dba6494735d0 (perhaps by accident). Otherwise, this patch is the same as for Python 3. I have added a sentence about using NULL for deletion in the patch. ---------- Added file: http://bugs.python.org/file45616/typeobj-sigs.v2.py2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 21:40:29 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 24 Nov 2016 02:40:29 +0000 Subject: [issue28771] Update documented signatures of tp_get/setattr In-Reply-To: <1479815588.93.0.810601241454.issue28771@psf.upfronthosting.co.za> Message-ID: <1479955229.44.0.770911134131.issue28771@psf.upfronthosting.co.za> Martin Panter added the comment: Python 2 patch is on top of the patch for Issue 25701 ---------- dependencies: +Document that tp_setattro and tp_setattr are used for deleting attributes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 22:10:59 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 24 Nov 2016 03:10:59 +0000 Subject: [issue10721] Remove HTTP 0.9 server support In-Reply-To: <1292523705.43.0.300913774105.issue10721@psf.upfronthosting.co.za> Message-ID: <1479957059.36.0.0221879793632.issue10721@psf.upfronthosting.co.za> Martin Panter added the comment: V4 patch adjusting to recent code change. Raymond: Given the problems caused by the current code, would you reconsider your opposition? Otherwise, what do you think should be the future of the code? Should we fix it so that it handles real HTTP 0.9 requests, or just admit that it doesn?t implement the protocol properly. ---------- Added file: http://bugs.python.org/file45617/http09server.v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 23:13:00 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 24 Nov 2016 04:13:00 +0000 Subject: [issue27100] Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za> Message-ID: <1479960780.76.0.11734070071.issue27100@psf.upfronthosting.co.za> Martin Panter added the comment: The tests changes also produce a DeprecationWarning: ====================================================================== ERROR: testEnterAttributeError1 (test.test_with.FailureTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/proj/python/cpython/Lib/test/test_with.py", line 120, in testEnterAttributeError1 self.assertRaisesRegexp(AttributeError, '__enter__', fooLacksEnter) File "/home/proj/python/cpython/Lib/unittest/case.py", line 1311, in deprecated_func DeprecationWarning, 2) DeprecationWarning: Please use assertRaisesRegex instead. The fix is simple and just affects the tests, but since most people don?t seem to worry about warnings, I guess this can wait for 3.6 to be released before committing the fix. ---------- Added file: http://bugs.python.org/file45618/regexp-deprecated.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 23:21:25 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 24 Nov 2016 04:21:25 +0000 Subject: [issue27172] Undeprecate inspect.getfullargspec() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1479961285.52.0.00637911434233.issue27172@psf.upfronthosting.co.za> Nick Coghlan added the comment: This just came up in a discussion on a urllib3 patch, so I'd like to fix it for 3.6.0rc1. Ned, given that the code change here is just deleting the deprecation warning from getfullargspec() and rewording the one for getargspec(), does that seem OK for 3.6.0? ---------- assignee: -> ncoghlan nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 23 23:35:06 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 24 Nov 2016 04:35:06 +0000 Subject: [issue27172] Undeprecate inspect.getfullargspec() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1479962106.32.0.978660570548.issue27172@psf.upfronthosting.co.za> Nick Coghlan added the comment: When we undeprecate this, we should remove and reword the deprecation warnings in the next 3.5 maintenance release as well. I'll need to decide on a way to indicate in the docs that some versions of 3.x.y will report a deprecation warning for getfullargspec() though - probably a "Changed in" note. ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 00:12:02 2016 From: report at bugs.python.org (Ned Deily) Date: Thu, 24 Nov 2016 05:12:02 +0000 Subject: [issue27172] Undeprecate inspect.getfullargspec() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1479964322.31.0.0690787398126.issue27172@psf.upfronthosting.co.za> Ned Deily added the comment: Nick, that seems like the right thing to do. Thanks for following up on it. ---------- nosy: +larry priority: normal -> release blocker versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 00:45:32 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Nov 2016 05:45:32 +0000 Subject: [issue27100] Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za> Message-ID: <1479966332.32.0.0934655197512.issue27100@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, how I missed this? I usually run tests with -Wa. Since the patch is simple and fixes a regression introduced just before releasing beta 4, I'm fine with fixing it. We are trying to support tests warnings-free. Some buildbots can run tests with -We. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 00:58:43 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Nov 2016 05:58:43 +0000 Subject: [issue25701] Document that tp_setattro and tp_setattr are used for deleting attributes In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za> Message-ID: <1479967123.9.0.13314102975.issue25701@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Please do this yourself. This is mainly your patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 01:08:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Nov 2016 06:08:52 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> Message-ID: <1479967732.25.0.41030187452.issue28782@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I prefer pygen_yf.patch (with addressing Yury's suggestions). It is much simpler, and in any case I want to change f_lasti to count words rather than bytes (issue27129). It would be again -1 at the start. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 01:51:19 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 24 Nov 2016 06:51:19 +0000 Subject: [issue28728] test_host_resolution in test_socket fails In-Reply-To: <1479407743.41.0.909577209709.issue28728@psf.upfronthosting.co.za> Message-ID: <1479970279.88.0.840648912247.issue28728@psf.upfronthosting.co.za> Xiang Zhang added the comment: Hi SilentGhost. I'm also using Ubuntu 16.10 but the test case doesn't fail. cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.10 DISTRIB_CODENAME=yakkety DISTRIB_DESCRIPTION="Ubuntu 16.10" ./python -Wa -m test -v test_socket | grep test_host_resolution test_host_resolution (test.test_socket.GeneralModuleTests) ... ok ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 01:55:25 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 24 Nov 2016 06:55:25 +0000 Subject: [issue27100] Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za> Message-ID: <1479970525.91.0.762830243259.issue27100@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Since the patch is simple and fixes a regression introduced > just before releasing beta 4, I'm fine with fixing it. We are > trying to support tests warnings-free. Some buildbots can run > tests with -We. +1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 02:04:33 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 24 Nov 2016 07:04:33 +0000 Subject: [issue28728] test_host_resolution in test_socket fails In-Reply-To: <1479407743.41.0.909577209709.issue28728@psf.upfronthosting.co.za> Message-ID: <1479971073.78.0.366095135726.issue28728@psf.upfronthosting.co.za> Martin Panter added the comment: Maybe worth looking at what name resolution stuff is enabled in /etc/nsswitch.conf. On the hosts line, my current computer (v basic setup) has hosts: files dns myhostname My guess is you have a plugin which is resolving these ip-address lookalikes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 02:44:10 2016 From: report at bugs.python.org (Evan) Date: Thu, 24 Nov 2016 07:44:10 +0000 Subject: [issue28784] shlex.shlex punctuation_chars documentation should use posix=True Message-ID: <1479973450.22.0.44978748963.issue28784@psf.upfronthosting.co.za> New submission from Evan: (This discussion started on issue28595.) The new punctuation_chars keyword argument is intended to provide "compatibility with the parsing performed by common Unix shells like bash, dash, and sh", however the documentation and examples do not mention that the user should also set posix=True (which defaults to False for shlex.shlex but True for shlex.split). Longer term (over several releases), perhaps the default for posix could be changed from False to True. Alternatively, the punctuation_chars argument could also be added to shlex.split, which would avoid having to interact with shlex.shlex directly. ---------- assignee: docs at python components: Documentation messages: 281612 nosy: docs at python, evan_, r.david.murray, vinay.sajip priority: normal severity: normal status: open title: shlex.shlex punctuation_chars documentation should use posix=True type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 02:47:55 2016 From: report at bugs.python.org (Evan) Date: Thu, 24 Nov 2016 07:47:55 +0000 Subject: [issue28595] shlex.shlex should not augment wordchars In-Reply-To: <1478166136.94.0.995190174918.issue28595@psf.upfronthosting.co.za> Message-ID: <1479973675.35.0.0467721777374.issue28595@psf.upfronthosting.co.za> Evan added the comment: I've created issue28784 to capture the documentation fixes. When I have more spare time, I'll work on a more complete patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 03:06:43 2016 From: report at bugs.python.org (SilentGhost) Date: Thu, 24 Nov 2016 08:06:43 +0000 Subject: [issue28728] test_host_resolution in test_socket fails In-Reply-To: <1479407743.41.0.909577209709.issue28728@psf.upfronthosting.co.za> Message-ID: <1479974803.94.0.0331154682253.issue28728@psf.upfronthosting.co.za> SilentGhost added the comment: > My guess is you have a plugin which is resolving these ip-address lookalikes. That probably is the reason. My hosts line looks like: hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns I guess there isn't much that could be done on Python side then and we can close the issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 03:13:37 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 24 Nov 2016 08:13:37 +0000 Subject: [issue28728] test_host_resolution in test_socket fails In-Reply-To: <1479407743.41.0.909577209709.issue28728@psf.upfronthosting.co.za> Message-ID: <1479975217.17.0.256522071545.issue28728@psf.upfronthosting.co.za> Xiang Zhang added the comment: > hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns I think this is the default config. Same as mine. Does test_host_resolution still stably fails? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 03:14:24 2016 From: report at bugs.python.org (Max) Date: Thu, 24 Nov 2016 08:14:24 +0000 Subject: [issue28785] Clarify the behavior of NotImplemented Message-ID: <1479975264.5.0.247033798803.issue28785@psf.upfronthosting.co.za> New submission from Max: Currently, there's no clear statement as to what exactly the fallback is in case `__eq__` returns `NotImplemented`. It would be good to clarify the behavior of `NotImplemented`; at least for `__eq__`, but perhaps also other rich comparison methods. For example: "When `NotImplemented` is returned from a rich comparison method, the interpreter behaves as if the rich comparison method was not defined in the first place." See http://stackoverflow.com/questions/40780004/returning-notimplemented-from-eq for more discussion. ---------- assignee: docs at python components: Documentation messages: 281616 nosy: docs at python, max priority: normal severity: normal status: open title: Clarify the behavior of NotImplemented type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 03:21:58 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Nov 2016 08:21:58 +0000 Subject: [issue28532] Show sys.version when -V option is supplied twice. In-Reply-To: <1477417861.44.0.42778795289.issue28532@psf.upfronthosting.co.za> Message-ID: <20161124082155.774.13022.ECE485D4@psf.io> Roundup Robot added the comment: New changeset 5a29ab5a4785 by INADA Naoki in branch '3.6': Issue #28532: Add what's new entry for python -VV option https://hg.python.org/cpython/rev/5a29ab5a4785 New changeset 3f9f13077ca8 by INADA Naoki in branch 'default': Issue #28532: Add what's new entry for python -VV option https://hg.python.org/cpython/rev/3f9f13077ca8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 03:22:19 2016 From: report at bugs.python.org (INADA Naoki) Date: Thu, 24 Nov 2016 08:22:19 +0000 Subject: [issue28532] Show sys.version when -V option is supplied twice. In-Reply-To: <1477417861.44.0.42778795289.issue28532@psf.upfronthosting.co.za> Message-ID: <1479975739.2.0.00237592013175.issue28532@psf.upfronthosting.co.za> Changes by INADA Naoki : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 03:27:44 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Nov 2016 08:27:44 +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: <1479976064.98.0.158979247277.issue28564@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Benchmarks show about 20% speed up. ---------- Added file: http://bugs.python.org/file45619/bench_rmtree.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 03:28:58 2016 From: report at bugs.python.org (SilentGhost) Date: Thu, 24 Nov 2016 08:28:58 +0000 Subject: [issue28728] test_host_resolution in test_socket fails In-Reply-To: <1479407743.41.0.909577209709.issue28728@psf.upfronthosting.co.za> Message-ID: <1479976137.99.0.850080287965.issue28728@psf.upfronthosting.co.za> SilentGhost added the comment: > Does test_host_resolution still stably fails? Yes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 03:42:06 2016 From: report at bugs.python.org (SilentGhost) Date: Thu, 24 Nov 2016 08:42:06 +0000 Subject: [issue28786] Warnings in Misc/NEWS Message-ID: <1479976926.46.0.685904317893.issue28786@psf.upfronthosting.co.za> New submission from SilentGhost: Couple of entries in Misc/NEWS are causing warnings due to use of double quotes instead of backticks for code segments. This patches fixes the formatting. ---------- assignee: docs at python components: Documentation files: escape.diff keywords: patch messages: 281620 nosy: SilentGhost, docs at python priority: normal severity: normal stage: patch review status: open title: Warnings in Misc/NEWS type: behavior versions: Python 3.7 Added file: http://bugs.python.org/file45620/escape.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 04:03:58 2016 From: report at bugs.python.org (Mark Harris) Date: Thu, 24 Nov 2016 09:03:58 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1479978238.73.0.579946514938.issue28781@psf.upfronthosting.co.za> Mark Harris added the comment: Thanks for the message. I've tried using repair, reinstalling etc to no effect. I've ziped up the files I could find starting with Python in the temp file you mentioned. Thanks again for the help, Mark ---------- Added file: http://bugs.python.org/file45621/Python Text Documents.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 04:07:49 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 24 Nov 2016 09:07:49 +0000 Subject: [issue28728] test_host_resolution in test_socket fails In-Reply-To: <1479407743.41.0.909577209709.issue28728@psf.upfronthosting.co.za> Message-ID: <1479978469.57.0.12902532004.issue28728@psf.upfronthosting.co.za> Martin Panter added the comment: I?m curious what the result of gethostbyaddr() is in your case, Silent Ghost. import socket socket.gethostbyaddr("::1q") socket.gethostbyaddr("::1::2") socket.gethostbyaddr("1:1:1:1:1:1:1:1:1") On my computer, I get ?socket.gaierror: [Errno -2] Name or service not known? from each call. Perhaps this is similar to the problems encountered with test_bad_address() at Lib/test/test_urllibnet.py:102 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 04:15:39 2016 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 24 Nov 2016 09:15:39 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1479978938.99.0.0800097655135.issue2771@psf.upfronthosting.co.za> Ezio Melotti added the comment: Test ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 04:27:18 2016 From: report at bugs.python.org (SilentGhost) Date: Thu, 24 Nov 2016 09:27:18 +0000 Subject: [issue28728] test_host_resolution in test_socket fails In-Reply-To: <1479407743.41.0.909577209709.issue28728@psf.upfronthosting.co.za> Message-ID: <1479979638.57.0.4295808627.issue28728@psf.upfronthosting.co.za> SilentGhost added the comment: I get either ('ec2-54-88-107-140.compute-1.amazonaws.com', [], ['54.88.107.140']) or ('ec2-54-84-80-173.compute-1.amazonaws.com', [], ['54.84.80.173']). It indeed seems to be related to ISP, as I get a regular socket.gaierror raised when I try this on another machine with a different provider. Naturally, it's not related to either 3.6 or 3.7, as I get the same behaviour even with 3.5. Skipping test might be an option, but one would probably need to wrap all uses of gethostbyaddr into a test helper? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 04:46:24 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 24 Nov 2016 09:46:24 +0000 Subject: [issue28785] Clarify the behavior of NotImplemented In-Reply-To: <1479975264.5.0.247033798803.issue28785@psf.upfronthosting.co.za> Message-ID: <1479980784.8.0.681804241221.issue28785@psf.upfronthosting.co.za> Martin Panter added the comment: The documentation of this that comes to mind is spread over and . My understanding of how it works in general is that NotImplemented is just a simple object like None. It doesn?t have any special behaviour on its own. Similarly, if you call a special method like __eq__() manually, there is no fallback, you just get the NotImplemented object. The interpreter calls special methods like __eq__() when evaluating expressions, but the specific behaviour and how NotImplemented is interpreted varies subtly. To evaluate a == b, if b?s class is a strict subclass of a?s class, b.__eq__(a) is tried first, otherwise a.__eq__(b) is tried first. If that call returns NotImplemented, the first fallback is to try the call. Failing that, the final fallback is the default behaviour for object() instances. To evaluate a != b, there is another set of fallbacks in the chain, which is to try ?not a.__eq__(b)?. So for __eq__(), the fallback depends on the class hierarchy, on whether a reversed call has already been made, and on whether you are evaluating == or !=. The documentation for comparison operations was cleaned up a while ago (Issue 12067). But there is probably more room for improvement. I think the best thing would be to document the above sort of behaviour as being directly associated with operations like as == and !=, and only indirectly associated with the NotImplemented object and the __eq__() method. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 05:01:36 2016 From: report at bugs.python.org (Florian Schulze) Date: Thu, 24 Nov 2016 10:01:36 +0000 Subject: [issue28518] execute("begin immediate") throwing OperationalError In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za> Message-ID: <1479981696.63.0.0203590621053.issue28518@psf.upfronthosting.co.za> Florian Schulze added the comment: How do we proceed from here? The Python 3.6.0rc1 is looming. If this is a bug in sqlite, then we need a workaround. We can't wait for a fix in sqlite, because it's not bundled with Python and without the fix Python 3.6 breaks with older sqlite versions. I'd like to help, but don't know how. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 05:10:45 2016 From: report at bugs.python.org (Charalampos Stratakis) Date: Thu, 24 Nov 2016 10:10:45 +0000 Subject: [issue28787] Out of tree --with--dtrace builds fail with a traceback Message-ID: <1479982245.65.0.843842109576.issue28787@psf.upfronthosting.co.za> New submission from Charalampos Stratakis: By invoking an out of tree build of python with the --with-dtrace flag enabled, make fails with an error. Create a new folder at the source directory: $ mkdir _build && cd _build $ ../configure --with-dtrace $ make /usr/bin/dtrace -o Include/pydtrace_probes.h -h -s ../Include/pydtrace.d Traceback (most recent call last): File "/usr/bin/dtrace", line 440, in sys.exit(main()) File "/usr/bin/dtrace", line 385, in main providers.probe_write(s_filename, filename + suffix) File "/usr/bin/dtrace", line 181, in probe_write hdr = open(header, mode='w') FileNotFoundError: [Errno 2] No such file or directory: 'Include/pydtrace_probes.h' Makefile:896: recipe for target 'Include/pydtrace_probes.h' failed make: *** [Include/pydtrace_probes.h] Error 1 This is because the Include directory doesn't exist. Attaching a patch to fix this. ---------- components: Build files: create-Include-dir-to-properly-generate-pydtrace_probes.h-file.patch keywords: patch messages: 281627 nosy: cstratak priority: normal severity: normal status: open title: Out of tree --with--dtrace builds fail with a traceback versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45622/create-Include-dir-to-properly-generate-pydtrace_probes.h-file.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 05:38:11 2016 From: report at bugs.python.org (Max) Date: Thu, 24 Nov 2016 10:38:11 +0000 Subject: [issue28785] Clarify the behavior of NotImplemented In-Reply-To: <1479975264.5.0.247033798803.issue28785@psf.upfronthosting.co.za> Message-ID: <1479983891.05.0.0678444061526.issue28785@psf.upfronthosting.co.za> Max added the comment: Martin - what you suggest is precisely what I had in mind (but didn't phrase it as well): > to document the above sort of behaviour as being directly associated with operations like as == and !=, and only indirectly associated with the NotImplemented object and the __eq__() method Also a minor typo: you meant "If that call returns NotImplemented, the first fallback is to try the *reverse* call." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 06:38:50 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Nov 2016 11:38:50 +0000 Subject: [issue28749] Fixed the documentation of the mapping codec APIs In-Reply-To: <1479637798.25.0.994184606714.issue28749@psf.upfronthosting.co.za> Message-ID: <1479987530.56.0.808474524157.issue28749@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch addresses Xiang's and Victor's comments. ---------- Added file: http://bugs.python.org/file45623/docs-PyUnicode_Translate-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 06:58:59 2016 From: report at bugs.python.org (INADA Naoki) Date: Thu, 24 Nov 2016 11:58:59 +0000 Subject: [issue28673] pyro4 with more than 15 threads often crashes 2.7.12 In-Reply-To: <1478939498.33.0.0967391900201.issue28673@psf.upfronthosting.co.za> Message-ID: <1479988739.19.0.805171387818.issue28673@psf.upfronthosting.co.za> INADA Naoki added the comment: I can't get same C traceback yet. But attached script segfaults by different C traceback. I think this issue is dup of #1856 ---------- Added file: http://bugs.python.org/file45624/28673-reproduce.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 08:04:00 2016 From: report at bugs.python.org (George Fischhof) Date: Thu, 24 Nov 2016 13:04:00 +0000 Subject: [issue28714] Addition to Documentation of configparser.ConfigParser.write() In-Reply-To: <1479308435.4.0.112292626323.issue28714@psf.upfronthosting.co.za> Message-ID: <1479992640.61.0.857113468497.issue28714@psf.upfronthosting.co.za> George Fischhof added the comment: Hi Berker, It is true, I agree ;-) But this way ConfigParser works different than xml parsers (for example elementtree from system lib), as when I use elementtree.write it wil create a file with full and valid xml content. But ConfigParser is "able" ;-) to create file with invalid content (for example (this was my findings) creates duplicated sections. So it could be a feature request for ConfigParser: It should be able to write config to a given filename, not only into file object. (Like xml parser) Kind regards, George ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 09:25:29 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Nov 2016 14:25:29 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> Message-ID: <1479997529.07.0.678233970348.issue28782@psf.upfronthosting.co.za> STINNER Victor added the comment: Updated patch. I added a NEWS entry and the two assertions from lasti.patch. These assertions are basic sanity checks, not directly related to this issue, they shouldn't harm. A started frame must never go back to the not-started state (f_lasti < 0). Yury: "How about we commit pygen_yf.patch to 3.6 and whatever else in 3.7?" Wordcode is already a massive change in our bytecode, I would prefer to not touch f_lasti just as a late update of WORDCODE in 3.7. I'm ok to keep f_lasti == -1 for frames not started yet. Serhiy: "I prefer pygen_yf.patch (with addressing Yury's suggestions)." Ok, fine. I'm also more confident in smaller changes when we are very close to the final release! So let's forget lasti.patch ;-) (Sorry Demur!) -- FYI attached test.py reproduces the bug because Cursor._read_data() starts with the instruction "SETUP_LOOP 72" and 72 is the code of the operation YIELD_FROM :-) To reproduce the bug, you must have a code object where the second byte is 72. It's not easy to control the generated bytecode from the Python code, so I decided to not write an unit test for this bug. ---------- Added file: http://bugs.python.org/file45625/pygen_yf-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 09:38:48 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 24 Nov 2016 14:38:48 +0000 Subject: [issue28518] execute("begin immediate") throwing OperationalError In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za> Message-ID: <1479998328.13.0.503147782781.issue28518@psf.upfronthosting.co.za> R. David Murray added the comment: I'm going to mark this as a release blocker because it is a regression. Ned may or may not agree. What is needed is for someone to propose a patch. ---------- nosy: +ned.deily, r.david.murray priority: normal -> release blocker versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 09:42:58 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 24 Nov 2016 14:42:58 +0000 Subject: [issue28714] Addition to Documentation of configparser.ConfigParser.write() In-Reply-To: <1479308435.4.0.112292626323.issue28714@psf.upfronthosting.co.za> Message-ID: <1479998578.65.0.351350429267.issue28714@psf.upfronthosting.co.za> R. David Murray added the comment: That would be a separate issue (a feature request). It would make sense, since there is already a read_file method. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 09:52:48 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Nov 2016 14:52:48 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> Message-ID: <1479999168.81.0.470169445061.issue28782@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: pygen_yf-2.patch LGTM. Agreed about tests. ---------- assignee: -> haypo stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 10:01:58 2016 From: report at bugs.python.org (George Fischhof) Date: Thu, 24 Nov 2016 15:01:58 +0000 Subject: [issue28788] Feature request: ConfigParser should be able to write config to a given filename, not only into file object Message-ID: <1479999718.88.0.148590995726.issue28788@psf.upfronthosting.co.za> New submission from George Fischhof: Hi There, I started to use ConfigParser, and found that it has no write to file_name option, but xml paarser (ElementTree) has. This way ConfigParser works different than xml parsers, as when I use elementtree.write it will create a file with full and valid xml content. But ConfigParser is "able" ;-) to create file with invalid content (for example (this was my findings) creates duplicated sections. Because the handling of the file is in the user's hand. So it would be good for ConfigParser to handle file writing and the user!s code would became simplier: Feature request: ConfigParser should be able to write config to a given filename, not only into file object. (Like xml parser) Kind regards, George Fischhof ---------- components: Library (Lib) messages: 281636 nosy: georgefischhof priority: normal severity: normal status: open title: Feature request: ConfigParser should be able to write config to a given filename, not only into file object type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 10:03:46 2016 From: report at bugs.python.org (George Fischhof) Date: Thu, 24 Nov 2016 15:03:46 +0000 Subject: [issue28714] Addition to Documentation of configparser.ConfigParser.write() In-Reply-To: <1479308435.4.0.112292626323.issue28714@psf.upfronthosting.co.za> Message-ID: <1479999826.63.0.160517007198.issue28714@psf.upfronthosting.co.za> George Fischhof added the comment: Hi, issue 28788 created as feature request BR, George ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 10:07:02 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Nov 2016 15:07:02 +0000 Subject: [issue28518] execute("begin immediate") throwing OperationalError In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za> Message-ID: <1480000022.79.0.458931213781.issue28518@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, I'm not experienced with sqlite3, but in what circumstances conn.execute('begin immediate') makes sense? Could you please provide a larger example where it is needed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 10:17:48 2016 From: report at bugs.python.org (Ned Deily) Date: Thu, 24 Nov 2016 15:17:48 +0000 Subject: [issue28518] execute("begin immediate") throwing OperationalError In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za> Message-ID: <1480000668.63.0.973313928063.issue28518@psf.upfronthosting.co.za> Ned Deily added the comment: Also, if there is indeed a suspected error in the underlying library, has the issue been reported to the SQLite project? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 11:19:25 2016 From: report at bugs.python.org (Julien Palard) Date: Thu, 24 Nov 2016 16:19:25 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480004365.5.0.543678983192.issue28754@psf.upfronthosting.co.za> Changes by Julien Palard : Added file: http://bugs.python.org/file45626/issue28754-4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 11:32:00 2016 From: report at bugs.python.org (Mathieu Duponchelle) Date: Thu, 24 Nov 2016 16:32:00 +0000 Subject: [issue28789] valgrind shows "invalid file descriptor" when calling platform.system() on my machine. Message-ID: <1480005120.89.0.855588033442.issue28789@psf.upfronthosting.co.za> New submission from Mathieu Duponchelle: I'm using Fedora 23. ?meh???~???1???valgrind python3 -c "import platform; print(platform.system())" ==10093== Memcheck, a memory error detector ==10093== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==10093== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==10093== Command: python3 -c import\ platform;\ print(platform.system()) ==10093== ==10094== Warning: invalid file descriptor 1024 in syscall close() ==10094== Warning: invalid file descriptor 1025 in syscall close() ==10094== Warning: invalid file descriptor 1026 in syscall close() ==10094== Warning: invalid file descriptor 1027 in syscall close() ==10094== Use --log-fd= to select an alternative log fd. ==10094== Warning: invalid file descriptor 1028 in syscall close() ==10094== Warning: invalid file descriptor 1029 in syscall close() Linux ==10093== ==10093== HEAP SUMMARY: ==10093== in use at exit: 861,318 bytes in 5,903 blocks ==10093== total heap usage: 71,738 allocs, 65,835 frees, 10,611,196 bytes allocated ==10093== ==10093== LEAK SUMMARY: ==10093== definitely lost: 0 bytes in 0 blocks ==10093== indirectly lost: 0 bytes in 0 blocks ==10093== possibly lost: 326,619 bytes in 1,420 blocks ==10093== still reachable: 534,699 bytes in 4,483 blocks ==10093== suppressed: 0 bytes in 0 blocks ==10093== Rerun with --leak-check=full to see details of leaked memory ==10093== ==10093== For counts of detected and suppressed errors, rerun with: -v ==10093== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ?meh???~???1???python3 --version Python 3.4.3 ?meh???~???1??? ---------- components: Library (Lib) messages: 281640 nosy: Mathieu_Du priority: normal severity: normal status: open title: valgrind shows "invalid file descriptor" when calling platform.system() on my machine. versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 12:44:54 2016 From: report at bugs.python.org (Lance Ware) Date: Thu, 24 Nov 2016 17:44:54 +0000 Subject: [issue28694] tkinter interface to fontchooser In-Reply-To: <1479174800.7.0.200377827869.issue28694@psf.upfronthosting.co.za> Message-ID: <1480009494.91.0.532686873116.issue28694@psf.upfronthosting.co.za> Lance Ware added the comment: Good points, Zachary. Regarding the commondialog.Dialog class, I think it would need to be enhanced to make sense using it with Fontchooser. It really doesn't do a whole lot, and the awful kludge in the show method (creating a Frame widget just so that some low-level operations can be performed) is repugnant to me. I think the whole thing is pretty out-of-date. With the Font class, perhaps some of its functionality can be used. I will need to better understand the architecture of Font and see what I can do with it. I think another issue that needs to be addressed is the modal/non-modal aspect of Tk fontchooser. I have access only to Windows OS, where it is modal. I have read that it is non-modal on Mac and perhaps other platforms. If that is the case, then the show method may not work properly on those other platforms. On Windows, the Tk command "tk fontchooser show" does not return control to the caller until after the user has clicked the OK or Cancel buttons. If it does return immediately on other platforms, then the show method may need do an update loop (or something better?) to keep the behavior consistent on the Python side. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 13:22:27 2016 From: report at bugs.python.org (Steve Dower) Date: Thu, 24 Nov 2016 18:22:27 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1480011747.76.0.215284149902.issue28781@psf.upfronthosting.co.za> Steve Dower added the comment: Oh wow, I've never seen anything like this before. It looks like it's really confused about whether you've installed for all users or not. I wish I knew how you got into this state, because I'd like to be able to prevent it. I guess it's related to the current issue where the install registration is always for the current user, even when the install is for all users, but it still shouldn't be possible to get into this state. As far as cleaning up goes, try running the following commands from an elevated command prompt and then doing another install/repair. (Some of them may fail, which is okay.) msiexec /quiet /x {EB0611B2-7F10-4D97-BCF2-DCAAB1199498} msiexec /quiet /x {5DB2183B-62D3-407F-BBC1-EAD2F36283FA} msiexec /quiet /x {33B10015-A9B1-4210-B50A-26C6443979B0} msiexec /quiet /x {FCBB04F4-D2CF-4F55-BE92-B3898696B318} msiexec /quiet /x {9D50A6D7-410A-4469-87B7-35FA84CBD479} msiexec /quiet /x {1FBA5182-78DD-4940-9F06-96E5042B7061} msiexec /quiet /x {E6DEBF43-7ACF-4E88-9BBF-9B5945683281} msiexec /quiet /x {C1153533-FDC4-4922-892D-B71810F69566} msiexec /quiet /x {9ADF9987-3327-48C6-91B3-B10900366491} msiexec /quiet /x {7E08C4EE-B1C7-4138-8227-7CD3837636AA} reg delete HKCU\Software\Python\PythonCore\3.5-32\InstalledFeatures /f reg delete HKLM\Software\Python\PythonCore\3.5-32\InstalledFeatures /f /reg:32 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 13:51:06 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Nov 2016 18:51:06 +0000 Subject: [issue27100] Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za> Message-ID: <20161124185103.16654.37788.EEEB45DA@psf.io> Roundup Robot added the comment: New changeset e11df6aa5bf1 by Raymond Hettinger in branch '3.6': Issue #27100: Silence deprecation warning in Lib/test/test_with.py https://hg.python.org/cpython/rev/e11df6aa5bf1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 13:52:37 2016 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 24 Nov 2016 18:52:37 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> Message-ID: <1480013557.22.0.406539270003.issue28782@psf.upfronthosting.co.za> Yury Selivanov added the comment: LGTM ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 14:20:18 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 24 Nov 2016 19:20:18 +0000 Subject: [issue28775] Option to set startup directory in IDLE In-Reply-To: <1479837252.01.0.0581172301847.issue28775@psf.upfronthosting.co.za> Message-ID: <1480015218.97.0.925808057297.issue28775@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Terry, if you're open to it, I would like to have one of our new aspiring core developers work on this patch under your direction. Nofar Schnider has expressed an interest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 14:34:57 2016 From: report at bugs.python.org (Nofar Schnider) Date: Thu, 24 Nov 2016 19:34:57 +0000 Subject: [issue28775] Option to set startup directory in IDLE In-Reply-To: <1479837252.01.0.0581172301847.issue28775@psf.upfronthosting.co.za> Message-ID: <1480016097.24.0.160639303225.issue28775@psf.upfronthosting.co.za> Changes by Nofar Schnider : ---------- nosy: +Nofar Schnider _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 14:56:16 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Nov 2016 19:56:16 +0000 Subject: [issue28773] typing.FrozenSet missing in documentation. In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za> Message-ID: <20161124195612.844.1748.7F2586EA@psf.io> Roundup Robot added the comment: New changeset 5d83b6a9b568 by Guido van Rossum in branch '3.5': Issue #28773: Add typing.FrozenSet docs. (Manuel Krebber) https://hg.python.org/cpython/rev/5d83b6a9b568 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 14:57:19 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Nov 2016 19:57:19 +0000 Subject: [issue28773] typing.FrozenSet missing in documentation. In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za> Message-ID: <20161124195718.29050.72017.CF13D22C@psf.io> Roundup Robot added the comment: New changeset 7059e68db068 by Guido van Rossum in branch '3.6': Issue #28773: Add typing.FrozenSet docs. (Manuel Krebber) (3.5->3.6) https://hg.python.org/cpython/rev/7059e68db068 New changeset 00bfe5bd3553 by Guido van Rossum in branch 'default': Issue #28773: Add typing.FrozenSet docs. (Manuel Krebber) (3.6->3.7) https://hg.python.org/cpython/rev/00bfe5bd3553 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 14:58:38 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 24 Nov 2016 19:58:38 +0000 Subject: [issue28773] typing.FrozenSet missing in documentation. In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za> Message-ID: <1480017518.25.0.316659727448.issue28773@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks! I pushed this into 3.5, then merged into 3.6 and default. Is that the right procedure still? ---------- resolution: -> fixed stage: patch review -> commit review status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 15:04:07 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 24 Nov 2016 20:04:07 +0000 Subject: [issue28790] Error when using Generic and __slots__ Message-ID: <1480017847.05.0.904574090231.issue28790@psf.upfronthosting.co.za> New submission from Guido van Rossum: Proxy for https://github.com/python/typing/issues/332 (issue) and https://github.com/python/typing/pull/334 (fix). """ from typing import Generic, TypeVar class C(Generic[TypeVar('T')]): __slots__ = ('potato',) # ValueError: 'potato' in __slots__ conflicts with class variable C[int] This is because bare C is created with a class member descriptor potato, and instantiating it tries to create a class with all the attributes in C. """ @ned, I'll leave it up to you whether this is of sufficient severity to put in 3.6rc1 or not. Do I need to attach the fix as a diff to this bug? ---------- assignee: gvanrossum messages: 281649 nosy: gvanrossum, ned.deily priority: normal severity: normal status: open title: Error when using Generic and __slots__ versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 15:05:28 2016 From: report at bugs.python.org (Big Stone) Date: Thu, 24 Nov 2016 20:05:28 +0000 Subject: [issue28791] update sqlite to 3.14.2 Message-ID: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> New submission from Big Stone: I fear it's too late for Python-3.6, but sqlite-3.15.1 fixes an old annoying bug (hidden since 3.8.0), and arriving tomorrow (nov.24th) sqlite-3.15.2 should be the well ".2" stabilized version of recent 3.15 improvements towards SQL standard (support for row values) If there is no special bugs left in Python-3.6.0b4 and everybody is happy, I would suggest you upgrade from sqlite-3.14.2 to sqlite-3.15.2 ---------- messages: 281650 nosy: Big Stone priority: normal severity: normal status: open title: update sqlite to 3.14.2 versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 15:05:34 2016 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 24 Nov 2016 20:05:34 +0000 Subject: [issue28790] Error when using Generic and __slots__ In-Reply-To: <1480017847.05.0.904574090231.issue28790@psf.upfronthosting.co.za> Message-ID: <1480017934.14.0.0684990632159.issue28790@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 16:00:33 2016 From: report at bugs.python.org (Big Stone) Date: Thu, 24 Nov 2016 21:00:33 +0000 Subject: [issue28791] update sqlite to 3.15.2 In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1480021233.2.0.123206658795.issue28791@psf.upfronthosting.co.za> Changes by Big Stone : ---------- title: update sqlite to 3.14.2 -> update sqlite to 3.15.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 16:07:47 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Nov 2016 21:07:47 +0000 Subject: [issue28792] bisect: implement aliases in Python, remove C aliases Message-ID: <1480021667.81.0.489541330256.issue28792@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch simplifies the _bisect module: remove _bisect.bisect and _bisect.insort aliases. Aliases are created in Lib/bisect.py. I wrote the patch to prepare the C code for Argument Clinic, see issue #28754. Note: Lib/test/test_bisect.py already contains two unit tests: def test_backcompatibility(self): self.assertEqual(self.module.bisect, self.module.bisect_right) def test_backcompatibility(self): self.assertEqual(self.module.insort, self.module.insort_right) ---------- files: bisect.patch keywords: patch messages: 281651 nosy: haypo, larry, mdk, rhettinger priority: normal severity: normal status: open title: bisect: implement aliases in Python, remove C aliases versions: Python 3.7 Added file: http://bugs.python.org/file45627/bisect.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 16:08:51 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Nov 2016 21:08:51 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480021731.75.0.555720354721.issue28754@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, I dislike your changes on test_bisect.py: I don't see why Argument Clinic would have to modify tests!? I created issue #28792: "bisect: implement aliases in Python, remove C aliases". ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 16:10:42 2016 From: report at bugs.python.org (Julien Palard) Date: Thu, 24 Nov 2016 21:10:42 +0000 Subject: [issue28792] bisect: implement aliases in Python, remove C aliases In-Reply-To: <1480021667.81.0.489541330256.issue28792@psf.upfronthosting.co.za> Message-ID: <1480021842.11.0.03973880843.issue28792@psf.upfronthosting.co.za> Julien Palard added the comment: LGTM ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 16:31:35 2016 From: report at bugs.python.org (Mingye Wang) Date: Thu, 24 Nov 2016 21:31:35 +0000 Subject: [issue28693] No EUDC (HKSCS) support in Windows cp950 In-Reply-To: <1479154148.6.0.43343383532.issue28693@psf.upfronthosting.co.za> Message-ID: <1480023095.49.0.897467946892.issue28693@psf.upfronthosting.co.za> Mingye Wang added the comment: Windows cp950's EUDC<->PUA mapping is not specific to HKSCS. ---------- title: No HKSCS support in Windows cp950 -> No EUDC (HKSCS) support in Windows cp950 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 16:31:57 2016 From: report at bugs.python.org (Mingye Wang) Date: Thu, 24 Nov 2016 21:31:57 +0000 Subject: [issue28343] Bad encoding alias cp936 -> gbk: euro sign In-Reply-To: <1475464291.36.0.0934021228231.issue28343@psf.upfronthosting.co.za> Message-ID: <1480023117.82.0.807208146072.issue28343@psf.upfronthosting.co.za> Changes by Mingye Wang : ---------- versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 16:33:19 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Nov 2016 21:33:19 +0000 Subject: [issue12844] Support more than 255 arguments In-Reply-To: <1314326578.49.0.0651529898349.issue12844@psf.upfronthosting.co.za> Message-ID: <1480023199.04.0.414343083478.issue12844@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Since issue27213 the bytecode no longer have a limitation for numbers of positional or keyword arguments. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 16:35:18 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Nov 2016 21:35:18 +0000 Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za> Message-ID: <20161124213515.90487.7150.20F0420C@psf.io> Roundup Robot added the comment: New changeset 303cedfb9e7a by Victor Stinner in branch '3.6': Fix _PyGen_yf() https://hg.python.org/cpython/rev/303cedfb9e7a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 16:35:18 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Nov 2016 21:35:18 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> Message-ID: <20161124213515.90487.83066.3044C74C@psf.io> Roundup Robot added the comment: New changeset 303cedfb9e7a by Victor Stinner in branch '3.6': Fix _PyGen_yf() https://hg.python.org/cpython/rev/303cedfb9e7a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 16:37:27 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 24 Nov 2016 21:37:27 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1480023447.2.0.309479781861.issue20185@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- dependencies: +Argument Clinic for bisect.bisect_left _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 16:42:43 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Thu, 24 Nov 2016 21:42:43 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1480023763.37.0.818050957409.issue15533@psf.upfronthosting.co.za> Wolfgang Maier added the comment: Ping. This still isn't fixed several years later, i.e., the documentation still describes the POSIX, but not the Windows behavior. See also issue20927, which reports this as a bug. ---------- nosy: +wolma versions: +Python 3.5, Python 3.6, Python 3.7 -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 16:48:56 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Nov 2016 21:48:56 +0000 Subject: [issue28792] bisect: implement aliases in Python, remove C aliases In-Reply-To: <1480021667.81.0.489541330256.issue28792@psf.upfronthosting.co.za> Message-ID: <1480024136.71.0.604341549292.issue28792@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, bisect() was renamed to bisect_right() and insort() renamed to insort_right() in the changeset 67b3ac439f64 of Python 2.1. The aliases created for "backward compatibility" are for compatibility with... Python 2.0 :-) The aliases were never deprecated. Maybe we can also remove/rephrase the "backward compatibility" comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 16:53:41 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Nov 2016 21:53:41 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> Message-ID: <1480024421.16.0.880915645652.issue28782@psf.upfronthosting.co.za> STINNER Victor added the comment: Thanks Martin Richard to continue to find (and report!) crazy corner cases ;-) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 16:57:01 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Nov 2016 21:57:01 +0000 Subject: [issue28792] bisect: implement aliases in Python, remove C aliases In-Reply-To: <1480021667.81.0.489541330256.issue28792@psf.upfronthosting.co.za> Message-ID: <1480024621.43.0.608231074686.issue28792@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 16:57:14 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Nov 2016 21:57:14 +0000 Subject: [issue28792] bisect: implement aliases in Python, remove C aliases In-Reply-To: <1480021667.81.0.489541330256.issue28792@psf.upfronthosting.co.za> Message-ID: <1480024634.07.0.727008264966.issue28792@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 17:01:06 2016 From: report at bugs.python.org (Nathaniel Smith) Date: Thu, 24 Nov 2016 22:01:06 +0000 Subject: [issue28793] Copy-paste error in collections.abc docs for AsyncGenerator Message-ID: <1480024866.24.0.433904664953.issue28793@psf.upfronthosting.co.za> New submission from Nathaniel Smith: There's a small copy-paste error in the docs for collections.abc.AsyncGenerator -- it's called collections.abc.Generator: "class collections.abc.Generator ABC for asynchronous generator classes that implement the protocol defined in PEP 525 and PEP 492. New in version 3.6. " I can't link directly to it, because sphinx is confused about there being multiple definitions for collections.abc.Generator, but this link is close: https://docs.python.org/3.7/library/collections.abc.html#collections.abc.AsyncIterator ---------- messages: 281661 nosy: njs, yselivanov priority: normal severity: normal status: open title: Copy-paste error in collections.abc docs for AsyncGenerator versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 17:10:04 2016 From: report at bugs.python.org (Nathaniel Smith) Date: Thu, 24 Nov 2016 22:10:04 +0000 Subject: [issue28794] inspect.isasyncgen and inspect.isasyncgenfunction aren't documented Message-ID: <1480025404.72.0.713291262903.issue28794@psf.upfronthosting.co.za> New submission from Nathaniel Smith: The string "isasync" does not appear to occur on this page: https://docs.python.org/3.6/library/inspect.html ---------- assignee: docs at python components: Documentation messages: 281662 nosy: docs at python, njs, yselivanov priority: normal severity: normal status: open title: inspect.isasyncgen and inspect.isasyncgenfunction aren't documented versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 17:20:31 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Nov 2016 22:20:31 +0000 Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za> Message-ID: <1480026031.16.0.396857026266.issue26647@psf.upfronthosting.co.za> STINNER Victor added the comment: This issue is done: see issue #27129 for the next step. ---------- dependencies: -Wordcode, part 2 resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 17:25:57 2016 From: report at bugs.python.org (=?utf-8?q?Jan_Veleck=C3=BD?=) Date: Thu, 24 Nov 2016 22:25:57 +0000 Subject: [issue28795] Misleading stating, that SIGINT handler is installed by default Message-ID: <1480026357.5.0.735730414686.issue28795@psf.upfronthosting.co.za> New submission from Jan Veleck?: Hello, documentation (https://docs.python.org/2/library/signal.html) states, that Python by default installs SIGINT handler which cause KeyboardInterrupt. This is not true everytime according to implementation. "Python installs a small number of signal handlers by default: SIGPIPE ... and SIGINT is translated into a KeyboardInterrupt exception." It should also mention this "SIGINT is installed only, when default handler is set at startup.". Because user can run python script from non-interative shell as background task and SIGINT handler is not installed, regardless although user does not change Python default behaviour. Related SO: http://stackoverflow.com/questions/40775054/capturing-sigint-using-keyboardinterrupt-exception-works-in-terminal-not-in-scr/40785230?noredirect=1 ---------- assignee: docs at python components: Documentation messages: 281664 nosy: Jan Veleck?, docs at python priority: normal severity: normal status: open title: Misleading stating, that SIGINT handler is installed by default type: behavior versions: 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 Thu Nov 24 17:28:24 2016 From: report at bugs.python.org (Irmen de Jong) Date: Thu, 24 Nov 2016 22:28:24 +0000 Subject: [issue28673] pyro4 with more than 15 threads often crashes 2.7.12 In-Reply-To: <1478939498.33.0.0967391900201.issue28673@psf.upfronthosting.co.za> Message-ID: <1480026504.77.0.760751162245.issue28673@psf.upfronthosting.co.za> Irmen de Jong added the comment: The 28673-reproduce.py didn't crash on any of the systems I've tried it on. Are you sure it is complete? It looks like a part is missing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 17:35:45 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Nov 2016 22:35:45 +0000 Subject: [issue28792] bisect: implement aliases in Python, remove C aliases In-Reply-To: <1480021667.81.0.489541330256.issue28792@psf.upfronthosting.co.za> Message-ID: <20161124223542.817.48322.029AEA0E@psf.io> Roundup Robot added the comment: New changeset 45713818fd81 by Victor Stinner in branch 'default': Issue #28792: Remove aliases from _bisect https://hg.python.org/cpython/rev/45713818fd81 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 17:42:43 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Nov 2016 22:42:43 +0000 Subject: [issue28792] bisect: implement aliases in Python, remove C aliases In-Reply-To: <1480021667.81.0.489541330256.issue28792@psf.upfronthosting.co.za> Message-ID: <1480027363.69.0.046395675186.issue28792@psf.upfronthosting.co.za> STINNER Victor added the comment: I pushed quickly my patch, so Julien can rebase his patch on top of that. I like his patch because it changes bisect to use FASTCALL which makes bisect faster! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 17:42:50 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Nov 2016 22:42:50 +0000 Subject: [issue28792] bisect: implement aliases in Python, remove C aliases In-Reply-To: <1480021667.81.0.489541330256.issue28792@psf.upfronthosting.co.za> Message-ID: <1480027370.65.0.126528980093.issue28792@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 17:53:18 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Nov 2016 22:53:18 +0000 Subject: [issue28685] Optimizing list.sort() by performing safety checks in advance In-Reply-To: <1479071980.11.0.232140584241.issue28685@psf.upfronthosting.co.za> Message-ID: <1480027998.57.0.8587380886.issue28685@psf.upfronthosting.co.za> STINNER Victor added the comment: list.sort() is a very sensitive function. Maybe (dummy idea?), you may start with a project on PyPI, play with it and try it on large applications (Django?). And come back later once it's battle tested? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 18:37:00 2016 From: report at bugs.python.org (Julien Palard) Date: Thu, 24 Nov 2016 23:37:00 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480030620.23.0.229310006875.issue28754@psf.upfronthosting.co.za> Julien Palard added the comment: New simplier patch thanks to https://bugs.python.org/issue28792. Also corrected docstrings. Also ran a micro-benchmark of `bisect.bisect(foo, "c")` with `foo = list("abcdef")`: Median +- std dev: [before] 434 ns +- 17 ns -> [after] 369 ns +- 22 ns: 1.18x faster FTR: ./python -m perf timeit -s 'import bisect; foo = list("abdef")' 'bisect.bisect(foo, "c")' -o after.json --inherit=PYTHONPATH --affinity=2,3 ---------- Added file: http://bugs.python.org/file45628/issue28754-5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 18:45:24 2016 From: report at bugs.python.org (Julien Palard) Date: Thu, 24 Nov 2016 23:45:24 +0000 Subject: [issue28793] Copy-paste error in collections.abc docs for AsyncGenerator In-Reply-To: <1480024866.24.0.433904664953.issue28793@psf.upfronthosting.co.za> Message-ID: <1480031124.28.0.223990017912.issue28793@psf.upfronthosting.co.za> Julien Palard added the comment: Proposed a simple patch. Error was introduced by "Issue #28720: Add collections.abc.AsyncGenerator.", git commit c75c1f44, hg changeset 105163. I reread it and did not find other occurrences of the error. ---------- keywords: +patch nosy: +mdk Added file: http://bugs.python.org/file45629/issue28793.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 19:13:05 2016 From: report at bugs.python.org (Julien Palard) Date: Fri, 25 Nov 2016 00:13:05 +0000 Subject: [issue28795] Misleading stating, that SIGINT handler is installed by default In-Reply-To: <1480026357.5.0.735730414686.issue28795@psf.upfronthosting.co.za> Message-ID: <1480032785.28.0.517820918689.issue28795@psf.upfronthosting.co.za> Julien Palard added the comment: Maybe something like: > Python installs a small number of signal handlers by default: SIGPIPE is ignored (so write errors on pipes and sockets can be reported as ordinary Python exceptions) and SIGINT (if parent process has not changed it) is translated into a KeyboardInterrupt exception. All of these can be overridden. ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 19:30:48 2016 From: report at bugs.python.org (Julien Palard) Date: Fri, 25 Nov 2016 00:30:48 +0000 Subject: [issue28753] Clinic: Converting Your First Function is not up to date In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za> Message-ID: <1480033848.6.0.299822943821.issue28753@psf.upfronthosting.co.za> Julien Palard added the comment: After a discussion with Victor, I propose a patch to update the documentation allowing users strictly following the doc to let Clinic use FASTCALLs, it's a nice performance gain, and it's safe to let clinic use it. ---------- Added file: http://bugs.python.org/file45630/issue28753.fastcall.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 19:43:58 2016 From: report at bugs.python.org (Julien Palard) Date: Fri, 25 Nov 2016 00:43:58 +0000 Subject: [issue28796] FIX warnings in documentation build Message-ID: <1480034638.89.0.480412503325.issue28796@psf.upfronthosting.co.za> New submission from Julien Palard: Just a little patch to fix 4 doc build warning. ---------- messages: 281673 nosy: mdk priority: normal severity: normal status: open title: FIX warnings in documentation build _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 19:44:09 2016 From: report at bugs.python.org (Julien Palard) Date: Fri, 25 Nov 2016 00:44:09 +0000 Subject: [issue28796] FIX warnings in documentation build In-Reply-To: <1480034638.89.0.480412503325.issue28796@psf.upfronthosting.co.za> Message-ID: <1480034649.33.0.34756871336.issue28796@psf.upfronthosting.co.za> Changes by Julien Palard : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 19:44:26 2016 From: report at bugs.python.org (Julien Palard) Date: Fri, 25 Nov 2016 00:44:26 +0000 Subject: [issue28796] FIX warnings in documentation build In-Reply-To: <1480034638.89.0.480412503325.issue28796@psf.upfronthosting.co.za> Message-ID: <1480034666.49.0.272256490267.issue28796@psf.upfronthosting.co.za> Changes by Julien Palard : ---------- keywords: +patch Added file: http://bugs.python.org/file45631/issue28796.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 21:48:29 2016 From: report at bugs.python.org (Wombatz) Date: Fri, 25 Nov 2016 02:48:29 +0000 Subject: [issue28797] Modifying class __dict__ inside __set_name__ Message-ID: <1480042109.13.0.341330811366.issue28797@psf.upfronthosting.co.za> New submission from Wombatz: This behavior occurs at least in python-3.6.0b3 and python-3.6.0b4. Modifying the class __dict__ inside the __set_name__ method of a descriptor that is used inside that class can lead to a bug that possibly prevents other descriptors from being initialized (the call to their __set_name__ is prevented). That happens because internally the cpython interpreter iterates the class __dict__ when calling all the __set_name__ methods. Changing the class __dict__ while iterating it leads to undefined behavior. This is the line in the source code https://github.com/python/cpython/blob/master/Objects/typeobject.c#L7010 See the attached file for an example where the bug can be observed. It defines a "desc" class that implements the __set_name__ method where it prints the name and modifies the class __dict__ of the containing class. Later a class is defined that has multiple instances of the "desc" class as class attributes. Depending on the number of attributes not all of them are initialized. When you see the underlying C-Code the reason for this behavior is obvious but in python itself the problem might not be apparent. To fix this bug the class __dict__ could be cashed and then the __set_name__ methods could be called while iterating over that copy. ---------- components: Interpreter Core files: reproduce.py messages: 281674 nosy: Wombatz priority: normal severity: normal status: open title: Modifying class __dict__ inside __set_name__ type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file45632/reproduce.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 21:54:12 2016 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 25 Nov 2016 02:54:12 +0000 Subject: [issue28797] Modifying class __dict__ inside __set_name__ In-Reply-To: <1480042109.13.0.341330811366.issue28797@psf.upfronthosting.co.za> Message-ID: <1480042452.05.0.942302227957.issue28797@psf.upfronthosting.co.za> Emanuel Barry added the comment: Ow! I can confirm the bug still happens on latest trunk. Nice finding! ---------- nosy: +ebarry, ned.deily, rhettinger, serhiy.storchaka priority: normal -> release blocker stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 21:58:48 2016 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 25 Nov 2016 02:58:48 +0000 Subject: [issue28797] Modifying class __dict__ inside __set_name__ In-Reply-To: <1480042109.13.0.341330811366.issue28797@psf.upfronthosting.co.za> Message-ID: <1480042728.65.0.881406409295.issue28797@psf.upfronthosting.co.za> Changes by Emanuel Barry : ---------- nosy: +Martin.Teichmann _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 22:07:22 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 25 Nov 2016 03:07:22 +0000 Subject: [issue28673] pyro4 with more than 15 threads often crashes 2.7.12 In-Reply-To: <1478939498.33.0.0967391900201.issue28673@psf.upfronthosting.co.za> Message-ID: <1480043242.75.0.671018926871.issue28673@psf.upfronthosting.co.za> INADA Naoki added the comment: I'm sorry, I had uploaded script with wrong parameter. Additionally, this script fails by chance. $ while true; do python2 28673-reproduce2.py || break; echo -n .; done .....Segmentation fault (core dumped) ---------- Added file: http://bugs.python.org/file45633/28673-reproduce2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 22:34:51 2016 From: report at bugs.python.org (Xiang Zhang) Date: Fri, 25 Nov 2016 03:34:51 +0000 Subject: [issue28749] Fixed the documentation of the mapping codec APIs In-Reply-To: <1479637798.25.0.994184606714.issue28749@psf.upfronthosting.co.za> Message-ID: <1480044891.13.0.650816574269.issue28749@psf.upfronthosting.co.za> Xiang Zhang added the comment: v2 LGTM. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 24 23:29:35 2016 From: report at bugs.python.org (Liang-Bo Wang) Date: Fri, 25 Nov 2016 04:29:35 +0000 Subject: [issue28798] Describe character as a string of length one instead of size one in tutorial Message-ID: <1480048175.03.0.163854418884.issue28798@psf.upfronthosting.co.za> New submission from Liang-Bo Wang: In Tutorial "An Informal Introduction" section, character is introduced as a string of size one. It may be true for python 2.x, where str can be interpreted as bytes. However in Python 3, strings are unicode thus the size and the length of a string are usually not the same. Also, using size of a string can be confused with the result returned by sys.getsizeof(mystr), where sys.getsizeof('a') != 1. Therefore using "a string of length one" to describe a character may be less confusing. The patch attached changes the wording. ---------- assignee: docs at python components: Documentation files: docs_tutorial_introduction_str.diff keywords: patch messages: 281678 nosy: ccwang002, docs at python priority: normal severity: normal status: open title: Describe character as a string of length one instead of size one in tutorial versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45634/docs_tutorial_introduction_str.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 01:44:44 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 25 Nov 2016 06:44:44 +0000 Subject: [issue28798] Describe character as a string of length one instead of size one in tutorial In-Reply-To: <1480048175.03.0.163854418884.issue28798@psf.upfronthosting.co.za> Message-ID: <1480056284.97.0.980403872926.issue28798@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I think the current wording is fine and do not want to start an unnecessary misadventure of finding every place we say size and replacing it with length. In general, we use either term almost interchangeable (i.e. the size of dictionary is determined by "len(d)"). The name of sys.getsizeof() may not have been apt, but it seems to have caused no confusion in practice. We do appreciate the suggestion, but will respectfully decline. ---------- nosy: +rhettinger resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 01:52:40 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 25 Nov 2016 06:52:40 +0000 Subject: [issue28673] pyro4 with more than 15 threads often crashes 2.7.12 In-Reply-To: <1478939498.33.0.0967391900201.issue28673@psf.upfronthosting.co.za> Message-ID: <1480056760.44.0.674374245626.issue28673@psf.upfronthosting.co.za> INADA Naoki added the comment: Python 3 would have #21963 too. If we can fix it, we can fix this issue too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 02:04:49 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 25 Nov 2016 07:04:49 +0000 Subject: [issue28797] Modifying class __dict__ inside __set_name__ In-Reply-To: <1480042109.13.0.341330811366.issue28797@psf.upfronthosting.co.za> Message-ID: <1480057489.21.0.629326227855.issue28797@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch iterates a copy of __dict__. ---------- keywords: +patch stage: needs patch -> patch review versions: +Python 3.7 Added file: http://bugs.python.org/file45635/set_name-dict-copy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 02:39:54 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Fri, 25 Nov 2016 07:39:54 +0000 Subject: [issue28794] inspect.isasyncgen and inspect.isasyncgenfunction aren't documented In-Reply-To: <1480025404.72.0.713291262903.issue28794@psf.upfronthosting.co.za> Message-ID: <1480059594.14.0.14059683903.issue28794@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Hi, attached is the patch with docs for inspect.isasyncgen and inspect.isasyncgenfunction Please review, and let me know if this works. Thanks :) ---------- keywords: +patch nosy: +Mariatta Added file: http://bugs.python.org/file45636/issue28794.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 02:44:51 2016 From: report at bugs.python.org (Stefan Scherfke) Date: Fri, 25 Nov 2016 07:44:51 +0000 Subject: [issue28772] Bus error in Python 3.6.0beta In-Reply-To: <1479818142.38.0.0931531711664.issue28772@psf.upfronthosting.co.za> Message-ID: <1480059891.05.0.460430301718.issue28772@psf.upfronthosting.co.za> Stefan Scherfke added the comment: The cause for this issue was a backwards incompatible change between conda-build v1 and conda-build v2. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 03:15:58 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 25 Nov 2016 08:15:58 +0000 Subject: [issue28753] Clinic: Converting Your First Function is not up to date In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za> Message-ID: <1480061758.06.0.160285291543.issue28753@psf.upfronthosting.co.za> STINNER Victor added the comment: issue28753.fastcall.diff LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 03:20:53 2016 From: report at bugs.python.org (SilentGhost) Date: Fri, 25 Nov 2016 08:20:53 +0000 Subject: [issue28772] Bus error in Python 3.6.0beta In-Reply-To: <1479818142.38.0.0931531711664.issue28772@psf.upfronthosting.co.za> Message-ID: <1480062053.83.0.0204568078968.issue28772@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- resolution: not a bug -> third party stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 03:29:46 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 25 Nov 2016 08:29:46 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480062586.76.0.68170859816.issue28754@psf.upfronthosting.co.za> STINNER Victor added the comment: issue28754-4.diff does 3 things: * convert C code to Argument Clinic * change docstrings of the C code * change unit tests issue28754-5.diff doesn't touch tests, but still does 2 things. Sadly, I dislike the changes on docstrings because it makes the C docstring and the Python docstring inconsistent. I suggest to copy/paste docstring between C and Python code. By the way, why do we have a docstring different from Doc/library/bisect.rst? Maybe we can simply use the same doc everywhere, but just add reST formatting in Doc/library/bisect.rst? Julien: I suggest to first restrict your change to Argument Clinic, and later write a new patch to update docstrings. I prefer to only do one thing per commit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 03:55:54 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Fri, 25 Nov 2016 08:55:54 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1480064154.53.0.156012673177.issue15533@psf.upfronthosting.co.za> Wolfgang Maier added the comment: Before I forget again what I've gathered yesterday about this issue, here's a summary of the problem: When the the first element of args or the executable argument of subprocess.Popen does not specify an absolute path, the way the executable gets discovered is platform-dependent. On POSIX platforms, if the argument contains a directory part, the executable gets looked for relative to the current working directory. If the argument is just a basename, the PATH is searched. On Windows, the executable argument and the first element of args are treated in different ways: If the executable is specified through the executable argument, it is always looked for relative to the current working directory only, but if it's specified through args, it's searched for using Windows-specific rules as documented for the underlying CreateProcess function (see https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx). Now, on top of all this, if the cwd argument of Popen is used, then, in Python3 on POSIX-platforms, the current working directory gets changed to cwd *before* the above interpretation happens, i.e., if executable or args[0] contains a dirname, the executable is looked for relative to cwd. On Windows, however, cwd becomes the current working directory of the new process, but is *not* used during the executable lookup. I guess with this being rather complicated it would be nice to have a dedicated section explaining the interpretation of relative paths as arguments instead of trying to get only the cwd wording right. ---------- components: +Library (Lib) type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 04:02:53 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 25 Nov 2016 09:02:53 +0000 Subject: [issue28799] Drop CALL_PROFILE special build? Message-ID: <1480064573.69.0.905508550534.issue28799@psf.upfronthosting.co.za> New submission from STINNER Victor: Python/ceval.c contains conditional code to compute statistics on function calls when CALL_PROFILE is defined. Extract of Misc/SpecialBuilds.txt: CALL_PROFILE ------------ Count the number of function calls executed. When this symbol is defined, the ceval mainloop and helper functions count the number of function calls made. It keeps detailed statistics about what kind of object was called and whether the call hit any of the special fast paths in the code. Statistics can later be collected by sys.callstats(). I'm unable to find any unit test on this feature. The feature was added in Python 2.3.1 by the changeset 16856c9514e0 in 2003: --- changeset: 27712:16856c9514e0 branch: legacy-trunk user: Jeremy Hylton date: Wed Feb 05 23:13:00 2003 +0000 files: Include/ceval.h Include/compile.h Misc/SpecialBuilds.txt Python/ceval.c Python/compile.c Python/sysmodule.c description: Small function call optimization and special build option for call stats. -DCALL_PROFILE: Count the number of function calls executed. When this symbol is defined, the ceval mainloop and helper functions count the number of function calls made. It keeps detailed statistics about what kind of object was called and whether the call hit any of the special fast paths in the code. Optimization: When we take the fast_function() path, which seems to be taken for most function calls, and there is minimal frame setup to do, avoid call PyEval_EvalCodeEx(). The eval code ex function does a lot of work to handle keywords args and star args, free variables, generators, etc. The inlined version simply allocates the frame and copies the arguments values into the frame. The optimization gets a little help from compile.c which adds a CO_NOFREE flag to code objects that don't have free variables or cell variables. This change allows fast_function() to get into the fast path with fewer tests. I measure a couple of percent speedup in pystone with this change, but there's surely more that can be done. --- The changeset adds an optimization using CO_NOFREE and the CALL_PROFILE feature. My problem is that with my work on FASTCALL, it became harder to track where the functions are called in practice. It maybe out of the Python/ceval.c file. I'm not sure that statistics are still computed correctly after my FASTCALL changes, and I don't know how to check it. Python has already sys.setprofile(), cProfile and profile modules. There is also sys.settrace(). Do we still need CALL_PROFILE? Attached patch removes the feature: * Calling the the untested and undocumented sys.callstats() function now emits a DeprecationWarning warning * Remove the PyEval_GetCallStats() function and its documentation PyEval_GetCallStats() seems to be part of the stable API, but I don't expect that anyone uses it outside the CPython source code since it requires to rebuild CPython with a special build flag (-D CALL_PROFILE). ---------- messages: 281687 nosy: haypo priority: normal severity: normal status: open title: Drop CALL_PROFILE special build? versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 04:03:23 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 25 Nov 2016 09:03:23 +0000 Subject: [issue28799] Drop CALL_PROFILE special build? In-Reply-To: <1480064573.69.0.905508550534.issue28799@psf.upfronthosting.co.za> Message-ID: <1480064603.23.0.821854144974.issue28799@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- keywords: +patch Added file: http://bugs.python.org/file45637/remove_call_profile.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 04:27:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 25 Nov 2016 09:27:13 +0000 Subject: [issue12844] Support more than 255 arguments In-Reply-To: <1314326578.49.0.0651529898349.issue12844@psf.upfronthosting.co.za> Message-ID: <1480066033.42.0.428973293709.issue12844@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No longer changes to Python/compile.c are needed. Here is a patch against 3.7 that just removes the limit of the number of passed arguments in Python/ast.c and adds tests. But still there is a limitation on the number of function parameters. It is caused by using a bytes objects as co_cell2arg. ---------- stage: -> patch review versions: +Python 3.7 Added file: http://bugs.python.org/file45638/no-args-limit.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 04:29:32 2016 From: report at bugs.python.org (Mark Harris) Date: Fri, 25 Nov 2016 09:29:32 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1480066172.05.0.312383959967.issue28781@psf.upfronthosting.co.za> Mark Harris added the comment: Hi Steve, Thanks looking into this for me. I tried the below and ran the lines in cmd with admin privileges. Then I tried running repair again. I'm afraid when I type python in the command prompt it has the same message as before about missing python35.dll. I know you said that not all the commands would work, however when I ran "reg delete HKLM\Software\Python\PythonCore\3.5-32\InstalledFeatures /f /reg:32" it couldn't find the file. I don't know if that helps at all. If you wanted to know how I caused this issue, I was having problems getting pip to work, so tried re-installing a few times(clicking generic user a few times in installation), into various locations, thinking it was something to do with the PATH. It didn't seem to be updating the path in the installation. Hence why it's a bit of a mess! Any suggestions on further cleaning I could do? Thanks again for all your help on this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 04:33:50 2016 From: report at bugs.python.org (Julius Lehmann-Richter) Date: Fri, 25 Nov 2016 09:33:50 +0000 Subject: [issue22298] Lib/warnings.py _show_warning does not protect against being called with a file like object which is closed In-Reply-To: <1409315343.62.0.0672695786427.issue22298@psf.upfronthosting.co.za> Message-ID: <1480066430.36.0.982804704909.issue22298@psf.upfronthosting.co.za> Julius Lehmann-Richter added the comment: Hey Wolfgang, thank you for looking into this old one again ;) The argument you are making does not answer the original bug report though as far as I can see. My initial problem was not the AttributeError about the missing write but a ValueError (I/O operation on closed file). Also this seems to have started a discussion about good programming practice between Terry and Antoine, my initial argument though was that, when you are catching an IOError for an invalid file, why not catch the ValueError for the closed file (since a closed file is surely not a valid target for a write operation). I would really like to be educated on this if I am missing something, why does the argument for not silencing errors and expecting good programming practice apply to the ValueError of a closed standard error which has not been set to None but not to an IOError of a passed in file object? Cheers Julius ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 04:45:29 2016 From: report at bugs.python.org (Aviv Palivoda) Date: Fri, 25 Nov 2016 09:45:29 +0000 Subject: [issue28518] execute("begin immediate") throwing OperationalError In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za> Message-ID: <1480067129.93.0.292232641562.issue28518@psf.upfronthosting.co.za> Aviv Palivoda added the comment: I searched in the sqlite tickets from something related to this issue and I couldn't find anything. I wanted to check the sqlite-users mailing list to see if anyone had already reported it but there is a problem in gmane archives. I tried to find a good way to solve this problem but I couldn't. I am adding a patch that should solve this problem but it is for sure not a good way :(. ---------- keywords: +patch Added file: http://bugs.python.org/file45639/28518.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 04:58:33 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Fri, 25 Nov 2016 09:58:33 +0000 Subject: [issue22298] Lib/warnings.py _show_warning does not protect against being called with a file like object which is closed In-Reply-To: <1409315343.62.0.0672695786427.issue22298@psf.upfronthosting.co.za> Message-ID: <1480067913.03.0.954619802003.issue22298@psf.upfronthosting.co.za> Wolfgang Maier added the comment: Hi Julius, I guess it's a question of control and responsibilities. If you write a program that may issue warnings under some conditions, that program may, for example, be used with stderr redirected to a file. Now it is possible that file gets removed while your program is running, then, upon the next warning, the program would crash with an IOError. In effect, this would let external cirumstances that are not under control by the programmer escalate a non-critical warning message to a true exception. It's debatable whether that should be prevented or not, but that seems to be the decision that Mark Hammond made long ago. If, OTOH, your program chooses to close sys.stderr, that is a deliberate decision and it's the programmers responsibility then not to try to write to it anymore. Suppressing the resulting ValueError would only hide the fact that due to a programming error no warnings can be issued anymore. Not sure if this makes any sense to you or others, but that's how I came to think about this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 05:18:16 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Fri, 25 Nov 2016 10:18:16 +0000 Subject: [issue22298] Lib/warnings.py _show_warning does not protect against being called with a file like object which is closed In-Reply-To: <1409315343.62.0.0672695786427.issue22298@psf.upfronthosting.co.za> Message-ID: <1480069096.69.0.848964710597.issue22298@psf.upfronthosting.co.za> Wolfgang Maier added the comment: Ah, I just found Issue607668, which discusses the changeset 2e7fe55c0e11 that introduced IOError suppression. The actual use case at the time was different and I have no idea whether it would still be a problem today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 05:28:56 2016 From: report at bugs.python.org (Martin Richard) Date: Fri, 25 Nov 2016 10:28:56 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1480024421.16.0.880915645652.issue28782@psf.upfronthosting.co.za> Message-ID: Martin Richard added the comment: Thank you all for fixing this so quickly, it's been done amazingly fast! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 05:31:49 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 25 Nov 2016 10:31:49 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> Message-ID: <1480069909.93.0.657824467546.issue28782@psf.upfronthosting.co.za> STINNER Victor added the comment: Martin Richard: "Thank you all for fixing this so quickly, it's been done amazingly fast!" Even if I didn't write the commit a77756e480c2 which introduced the regression, I pushed it and so I felt responsible. It's a good motivation to fix it quickly. So nobody notice :-D ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 05:55:16 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 25 Nov 2016 10:55:16 +0000 Subject: [issue28800] Add RETURN_NONE Message-ID: <1480071315.87.0.448012344283.issue28800@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch adds a new bytecode instruction: RETURN_NONE. It is similar to "LOAD_CONST; RETURN_VALUE" but it avoids the need of adding None to constants of the code object. For function with an empty body, it reduces the stack size from 1 to 0. Example on reference Python 3.7: >>> def func(): return ... >>> import dis; dis.dis(func) 1 0 LOAD_CONST 0 (None) 2 RETURN_VALUE >>> func.__code__.co_stacksize 1 Example on patched Python 3.7: >>> def func(): return ... >>> import dis; dis.dis(func) 1 0 RETURN_CONST >>> func.__code__.co_stacksize 0 If the function has a docstring, RETURN_CONST avoids adding None to code constants: >>> def func(): ... "docstring" ... return ... >>> func.__code__.co_consts ('docstring',) I will now run benchmarks on the patch. ---------- files: return_none.patch keywords: patch messages: 281696 nosy: haypo, matrixise, serhiy.storchaka priority: normal severity: normal status: open title: Add RETURN_NONE versions: Python 3.7 Added file: http://bugs.python.org/file45640/return_none.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 05:55:24 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 25 Nov 2016 10:55:24 +0000 Subject: [issue28800] Add RETURN_NONE bytecode instruction In-Reply-To: <1480071315.87.0.448012344283.issue28800@psf.upfronthosting.co.za> Message-ID: <1480071324.55.0.682294697801.issue28800@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Add RETURN_NONE -> Add RETURN_NONE bytecode instruction _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 05:55:51 2016 From: report at bugs.python.org (Richard Prosser) Date: Fri, 25 Nov 2016 10:55:51 +0000 Subject: [issue28801] configparser: before_get() method of class Interpolation has positional 'parser' parameter that is not used. Message-ID: <1480071351.83.0.49150116079.issue28801@psf.upfronthosting.co.za> New submission from Richard Prosser: >From https://hg.python.org/cpython/file/3.5/Lib/configparser.py (for example): 358class Interpolation: 359 """Dummy interpolation that passes the value through with no changes.""" 360 361 def before_get(self, parser, section, option, value, defaults): 362 return value but a typical invocation misses out the 'parser' parameter: 796 return self._interpolation.before_get(self, section, option, value, 797 d) As far as I can see, this is not a keyword-only parameter, yet PyCharm seems to treat it as one. So maybe this is some new behaviour that I don't understand yet but there seems to be a fault here, IMO. I am using Python 3.5.2 on Windows 7, after using the 'futurize' tool on some legacy 2.7 code that extended self._interpolate (which no longer exists in 3+). ---------- hgrepos: 362 messages: 281697 nosy: rprosser priority: normal severity: normal status: open title: configparser: before_get() method of class Interpolation has positional 'parser' parameter that is not used. type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 05:59:43 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 25 Nov 2016 10:59:43 +0000 Subject: [issue28800] Add RETURN_NONE bytecode instruction In-Reply-To: <1480071315.87.0.448012344283.issue28800@psf.upfronthosting.co.za> Message-ID: <1480071583.45.0.82774017719.issue28800@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Interpreter Core nosy: +rhettinger stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 06:05:34 2016 From: report at bugs.python.org (Julius Lehmann-Richter) Date: Fri, 25 Nov 2016 11:05:34 +0000 Subject: [issue22298] Lib/warnings.py _show_warning does not protect against being called with a file like object which is closed In-Reply-To: <1409315343.62.0.0672695786427.issue22298@psf.upfronthosting.co.za> Message-ID: <1480071934.54.0.963520136312.issue22298@psf.upfronthosting.co.za> Julius Lehmann-Richter added the comment: Hey Wolfgang, thank you for the clarification. I would never write such code of course, I stumbled across this with a third-party program. I understand your point of view and I actually agree. I would not have even opened this report if it had not been for that comment. If the error is still reproducable in the software I will open a bug with them instead and tell them to please fix it :P As far as I am concerned this is not a bug (any more) Cheers Julius ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 06:05:41 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 25 Nov 2016 11:05:41 +0000 Subject: [issue28800] Add RETURN_NONE bytecode instruction In-Reply-To: <1480071315.87.0.448012344283.issue28800@psf.upfronthosting.co.za> Message-ID: <1480071941.65.0.866008898773.issue28800@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm proposing this patch because I noticed that reducing the number of opcodes makes Python faster in my old registervm project: a fork of CPython which uses a register-based bytecode: http://faster-cpython.readthedocs.io/registervm.html I also plan to propose a CALL_PROCEDURE method to replace CALL_FUNCTION+POP_TOP. Only for the the simple CALL_FUNCTION, not for complex CALL_FUNCTION_KW nor CALL_FUNCTION_EX. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 06:20:29 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 25 Nov 2016 11:20:29 +0000 Subject: [issue28518] execute("begin immediate") throwing OperationalError In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za> Message-ID: <1480072829.11.0.168735397982.issue28518@psf.upfronthosting.co.za> Berker Peksag added the comment: I haven't had a time to investigate this yet, but I don't think there is an issue with SQLite itself. Note that pysqlite behaves the same way since version 2.8.0 and I couldn't find a similar report in their issue tracker. Like Serhiy, I'm also a little puzzled with the reproducer. I think if you want to start an explicit transaction, the preferred way would be to set isolation_level to None. Otherwise, the sqlite3 module will start one implicitly for you (or perhaps I still don't understand PEP 249's transaction model 100% correctly :)) (If we decide that this is not a regression, we should add a test case to cover this use case.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 06:21:59 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Fri, 25 Nov 2016 11:21:59 +0000 Subject: [issue28801] configparser: before_get() method of class Interpolation has positional 'parser' parameter that is not used. In-Reply-To: <1480071351.83.0.49150116079.issue28801@psf.upfronthosting.co.za> Message-ID: <1480072919.48.0.437743558199.issue28801@psf.upfronthosting.co.za> Wolfgang Maier added the comment: Ah, that's kind of confusing at first! the 'self' in the method calls (like on line 796) refers to the ConfigParser instance and will be bound to the parser parameter. The first parameter, the 'self' in the interpolation method definition, is not provided as usual because the method is called on an _interpolation instance. => Nothing special here except the names of the arguments ---------- nosy: +wolma type: compile error -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 06:27:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 25 Nov 2016 11:27:24 +0000 Subject: [issue28800] Add RETURN_NONE bytecode instruction In-Reply-To: <1480071315.87.0.448012344283.issue28800@psf.upfronthosting.co.za> Message-ID: <1480073244.48.0.39752344243.issue28800@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Do you want to add RETURN_NONE or RETURN_CONST? Or both? Adding new special opcodes can decrease the size of the code and increase performance of some cases. But it adds maintenance burden, increases the complexity of the compiler and peephole optimizer, and increases the size of ceval loop. The latter can have negative effect on the performance. I think we should add new specialized opcodes only if they adds measurable gain to global performance or large speed up of important particular cases. It would help if you gather the statistics of RETURN_* opcodes. How many RETURN_VALUE, RETURN_CONST and RETURN_NONE instructions are compiled and executed during running Python tests? Compare it with total number of compiled and executed instructions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 06:33:14 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 25 Nov 2016 11:33:14 +0000 Subject: [issue22298] Lib/warnings.py _show_warning does not protect against being called with a file like object which is closed In-Reply-To: <1409315343.62.0.0672695786427.issue22298@psf.upfronthosting.co.za> Message-ID: <1480073594.26.0.445070116625.issue22298@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In 3.6, the code in question is def _showwarnmsg_impl(msg): file = msg.file if file is None: file = sys.stderr if file is None: # sys.stderr is None when run with pythonw.exe: # warnings get lost return text = _formatwarnmsg(msg) try: file.write(text) except OSError: # the file (probably stderr) is invalid - this warning gets lost. pass When the write is attempted, *file* is not None. It can either be sys.stderr or something else, successfully opened. If writing to sys.stderr fails, we properly should give up. If writing to something else fails, I now think we should try to write an exception to stderr. So I thing the bug here, if any, is unconditionally passing. Perhaps the exception clause should be replaced (in a new issue) with something like except (OSError, ValueError): if msg.file is not sys.stderr: raise ---------- resolution: -> not a bug stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 07:17:54 2016 From: report at bugs.python.org (Florian Schulze) Date: Fri, 25 Nov 2016 12:17:54 +0000 Subject: [issue28518] execute("begin immediate") throwing OperationalError In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za> Message-ID: <1480076274.07.0.155198653114.issue28518@psf.upfronthosting.co.za> Florian Schulze added the comment: Ok, I reread https://docs.python.org/3/library/sqlite3.html#controlling-transactions several times now. I think it's confusing. I want explicit transaction handling, but ``isolation_level = None`` turns on "autocommit mode". Unfortunately I don't have suggestions on how to improve the documentation. For us, ``isolation_level = None`` and the explicit ``begin immediate`` seems to be the correct way and it works with all Python versions, including 3.6.0. So, I would say this is "not a bug" in Python, but my understanding of the sqlite3 module is flawed. The documentation could be better, but I don't know how to make it better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 07:27:50 2016 From: report at bugs.python.org (Richard Prosser) Date: Fri, 25 Nov 2016 12:27:50 +0000 Subject: [issue28801] configparser: before_get() method of class Interpolation has positional 'parser' parameter that is not used. In-Reply-To: <1480071351.83.0.49150116079.issue28801@psf.upfronthosting.co.za> Message-ID: <1480076870.45.0.0375883424956.issue28801@psf.upfronthosting.co.za> Richard Prosser added the comment: Thanks for the prompt reply. I still don't fully understand yet but there aren't any errors reported so I presume that it is OK. There is another related matter however: PyCharm (2016.2.3) indicates that a get() method signature does not match that of the Mapping class one ... 557 558class RawConfigParser(MutableMapping): 761 762 def get(self, section, option, *, raw=False, vars=None, fallback=_UNSET): There are other similar cases I believe. So I am not sure what to make of that, either. ---------- hgrepos: +363 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 07:30:14 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 25 Nov 2016 12:30:14 +0000 Subject: [issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function In-Reply-To: <1367269025.02.0.400879045482.issue17870@psf.upfronthosting.co.za> Message-ID: <1480077014.96.0.882591325282.issue17870@psf.upfronthosting.co.za> STINNER Victor added the comment: New attempt to support C intmax_t type, since Python 3.6 now supports a subset of C99: intmax_t-4.patch. Changes: Add support for C intmax_t type: Add new conversions functions for PyLong: PyLong_FromIntMax() PyLong_FromUIntMax() PyLong_AsIntMax() PyLong_AsIntMaxAndOverflow() PyLong_AsUIntMax() getargs: add 'm' format New _testcapi constants: INTMAX_MAX, INTMAX_MIN, UINTMAX_MAX, SIZEOF_INTMAX_T Add _testcapi.getargs_m() and _testcapi.test_long_intmax_api() PyLong_FromVoidPtr() uses PyLong_FromUIntMax() Use intmax_t in various modules array, struct, ctypes and memoryview are not modified yet to support intmax_t. -- To ease the review of this large patch, I created a GitHub pull request: https://github.com/python/cpython/pull/46 ---------- Added file: http://bugs.python.org/file45641/intmax_t-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 07:30:22 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 25 Nov 2016 12:30:22 +0000 Subject: [issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function In-Reply-To: <1367269025.02.0.400879045482.issue17870@psf.upfronthosting.co.za> Message-ID: <1480077022.94.0.619824102494.issue17870@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 07:31:36 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 25 Nov 2016 12:31:36 +0000 Subject: [issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function In-Reply-To: <1367269025.02.0.400879045482.issue17870@psf.upfronthosting.co.za> Message-ID: <1480077096.92.0.369959992653.issue17870@psf.upfronthosting.co.za> STINNER Victor added the comment: intmax_t-4.patch is a single combined patch for Mercurial. To see individual changes, see the GitHub pull request: https://github.com/python/cpython/pull/46/commits ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 07:34:04 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 25 Nov 2016 12:34:04 +0000 Subject: [issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function In-Reply-To: <1367269025.02.0.400879045482.issue17870@psf.upfronthosting.co.za> Message-ID: <1480077244.73.0.0929965086987.issue17870@psf.upfronthosting.co.za> STINNER Victor added the comment: I guess that the main question is if all platforms supported by Python do support intmax_t? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 07:39:33 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 25 Nov 2016 12:39:33 +0000 Subject: [issue28518] execute("begin immediate") throwing OperationalError In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za> Message-ID: <1480077573.71.0.375100298559.issue28518@psf.upfronthosting.co.za> Berker Peksag added the comment: There is a patch in issue 8145 to improve that part of the documentation. It would be great if you could take a look at it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 07:40:53 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 25 Nov 2016 12:40:53 +0000 Subject: [issue8145] Documentation about sqlite3 isolation_level In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za> Message-ID: <1480077653.63.0.709834394657.issue8145@psf.upfronthosting.co.za> Berker Peksag added the comment: The patch needs to be updated to address changes in issue 10740 so I'm moving the stage field back to 'patch review'. ---------- stage: commit review -> patch review versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 07:46:39 2016 From: report at bugs.python.org (Richard Prosser) Date: Fri, 25 Nov 2016 12:46:39 +0000 Subject: [issue28801] configparser: before_get() method of class Interpolation has positional 'parser' parameter that is not used. In-Reply-To: <1480071351.83.0.49150116079.issue28801@psf.upfronthosting.co.za> Message-ID: <1480077999.14.0.490115542304.issue28801@psf.upfronthosting.co.za> Richard Prosser added the comment: Ah. Something like self._interpolation.before_get(self, section, option, value, d) could be better written as self._interpolation.before_get(parser=self, ...) - but that would require keyword arguments to be used throughout. I still don't grock the apparent 'get()' signature mis-match however. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 08:00:17 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 25 Nov 2016 13:00:17 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480078817.11.0.803330675674.issue28754@psf.upfronthosting.co.za> Martin Panter added the comment: Victor, what changes to the doc strings are you talking about? Adding descriptions of the parameters, maybe? Other than that they look very similar to me. I haven?t looked closely, but the Python doc strings have been updated at least once more than the C doc strings: r54666 and Issue 1602378. So if you are copying anything, it might be better to copy from Py to C. But I would do that separately. The doc strings and reference documentation just seem to have been added independently: ce2d120c3903 (main documentation) vs 67b3ac439f64 (doc strings) ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 08:07:21 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 25 Nov 2016 13:07:21 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480079241.03.0.69240012398.issue28754@psf.upfronthosting.co.za> STINNER Victor added the comment: Martin: "Victor, what changes to the doc strings are you talking about?" See attached check_bisect_doc.py script. Before: --- === bisect_right === bisect_right(a, x[, lo[, hi]]) -> index Return the index where to insert item x in list a, assuming a is sorted. The return value i is such that all e in a[:i] have e <= x, and all e in a[i:] have e > x. So if x already appears in the list, i points just beyond the rightmost x already there Optional args lo (default 0) and hi (default len(a)) bound the slice of a to be searched. === insort_right === insort_right(a, x[, lo[, hi]]) Insert item x in list a, and keep it sorted assuming a is sorted. If x is already in a, insert it to the right of the rightmost x. Optional args lo (default 0) and hi (default len(a)) bound the slice of a to be searched. === bisect_left === bisect_left(a, x[, lo[, hi]]) -> index Return the index where to insert item x in list a, assuming a is sorted. The return value i is such that all e in a[:i] have e < x, and all e in a[i:] have e >= x. So if x already appears in the list, i points just before the leftmost x already there. Optional args lo (default 0) and hi (default len(a)) bound the slice of a to be searched. === insort_left === insort_left(a, x[, lo[, hi]]) Insert item x in list a, and keep it sorted assuming a is sorted. If x is already in a, insert it to the left of the leftmost x. Optional args lo (default 0) and hi (default len(a)) bound the slice of a to be searched. --- After: --- === bisect_right === Return the index where to insert item x in list a, assuming a is sorted. a The list in which x is to be inserted. x The value to be inserted. lo Lower bound, defaults to 0. hi Upper bound, defaults to -1 (meaning len(a)). The return value i is such that all e in a[:i] have e <= x, and all e in a[i:] have e > x. So if x already appears in the list, i points just beyond the rightmost x already there. Optional args lo and hi bound the slice of a to be searched. === insort_right === Insert item x in list a, and keep it sorted assuming a is sorted. a The list in which x will be inserted. x The value to insert. lo Lower bound, defaults to 0. hi Upper bound, defaults to -1 (meaning len(a)). If x is already in a, insert it to the right of the rightmost x. Optional args lo and hi bound the slice of a to be searched. === bisect_left === Return the index where to insert item x in list a, assuming a is sorted. a The list in which x is to be inserted. x The value to be inserted. lo Lower bound, defaults to 0. hi Upper bound, defaults to -1 (meaning len(a)). The return value i is such that all e in a[:i] have e < x, and all e in a[i:] have e >= x. So if x already appears in the list, i points just before the leftmost x already there. Optional args lo and hi bound the slice of a to be searched. === insort_left === Insert item x in list a, and keep it sorted assuming a is sorted. a The list in which x will be inserted. x The value to insert. lo Lower bound, defaults to 0. hi Upper bound, defaults to -1 (meaning len(a)). If x is already in a, insert it to the left of the leftmost x. Optional args lo and hi bound the slice of a to be searched. --- The output is different. I suggest to not touch the docstring in the patch upgrading _bisect.c to Argument Clinic to ease the review. ---------- Added file: http://bugs.python.org/file45642/check_bisect_doc.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 08:15:05 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 25 Nov 2016 13:15:05 +0000 Subject: [issue28785] Clarify the behavior of NotImplemented In-Reply-To: <1479975264.5.0.247033798803.issue28785@psf.upfronthosting.co.za> Message-ID: <1480079705.7.0.0927221880677.issue28785@psf.upfronthosting.co.za> Martin Panter added the comment: Correct, I meant to say the first fallback is the other call. BTW your suggested text might hold for __eq__(), but for __ne__(), returning NotImplemented seems to bypass the ?not a.__eq__(b)? fallback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 08:21:33 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Fri, 25 Nov 2016 13:21:33 +0000 Subject: [issue28801] configparser: before_get() method of class Interpolation has positional 'parser' parameter that is not used. In-Reply-To: <1480071351.83.0.49150116079.issue28801@psf.upfronthosting.co.za> Message-ID: <1480080093.12.0.433718733379.issue28801@psf.upfronthosting.co.za> Wolfgang Maier added the comment: > Ah. Something like self._interpolation.before_get(self, section, option, value, d) could be better written as self._interpolation.before_get(parser=self, ...) Yep, that's roughly what I was trying to explain. > I still don't grock the apparent 'get()' signature mis-match however. There is not much special here either. RawConfigParser inherits from MutableMapping, which in turn inherits from Mapping, which defines a get method, which RawConfigParser overwrites. The overwritten and the overwriting method *do* have different parameters, but I don't see why that matters. In general, this does not look like a topic for the Python bug tracker (you are not reporting a bug, but you try to understand how correctly working code does its job), but rather for news:comp.lang.python or a PyCharm mailing list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 08:21:46 2016 From: report at bugs.python.org (Florian Schulze) Date: Fri, 25 Nov 2016 13:21:46 +0000 Subject: [issue8145] Documentation about sqlite3 isolation_level In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za> Message-ID: <1480080106.57.0.461428669655.issue8145@psf.upfronthosting.co.za> Florian Schulze added the comment: The documentation patch is a definite improvement. ---------- nosy: +fschulze _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 08:35:20 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 25 Nov 2016 13:35:20 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480080920.72.0.915421735565.issue28754@psf.upfronthosting.co.za> Martin Panter added the comment: Taking the first function, bisect_right(), as an example, I see these differences: * bisect_right(a, x[, lo[, hi]]) -> index This signature is removed. I think removing it is reasonable, because pydoc can extract the proper signature from the Arg Clinic metadata. * Additional descriptions of each parameter. I tend to think these are redundant with the main text, so agree with removing them from the patch now. * Addition of full stop (.) at end of first paragraph. I suggested this as a minor cleanup, but it could be fixed later if you prefer. * Removal of default values in last paragraph. The first is redundant with the Arg Clinic signature, so I suggested to remove it. For the second, I would add it back if we remove the list of parameters, since it explains what the special value -1 means. Do you want to revert all these differences? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 08:39:14 2016 From: report at bugs.python.org (INADA Naoki) Date: Fri, 25 Nov 2016 13:39:14 +0000 Subject: [issue28673] pyro4 with more than 15 threads often crashes 2.7.12 In-Reply-To: <1478939498.33.0.0967391900201.issue28673@psf.upfronthosting.co.za> Message-ID: <1480081154.73.0.735827907914.issue28673@psf.upfronthosting.co.za> INADA Naoki added the comment: This script can cause deadlock on Python 3.6. 1. Other threads can register traceback to sys module after sys module dict is cleaned up. 2. In Py_Finalize, __del__ method of arbitrary object in the traceback can be called. 3. The __del__ method calls threading.Thread.start() 4. Thread.start() waits self.__started event which is set by Thread.__bootstrap 5. While finalizing, threads other than main thread exits when getting GIL. So Thread.__bootstrap() won't be called. 6. Thread.start() in main thread waits self.__started event forever. I suggest thread_PyThread_start_new_thread() raise RuntimeError("can't start thread: finalizing") ---------- Added file: http://bugs.python.org/file45643/finish-deadlock.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 08:45:10 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 25 Nov 2016 13:45:10 +0000 Subject: [issue28800] Add RETURN_NONE bytecode instruction In-Reply-To: <1480071315.87.0.448012344283.issue28800@psf.upfronthosting.co.za> Message-ID: <1480081510.57.0.440050642423.issue28800@psf.upfronthosting.co.za> STINNER Victor added the comment: Results of performance 0.5.0 on speed-python: haypo at speed-python$ python3 -m perf compare_to -G --min-speed=3 2016-11-23_19-34-default-3d660ed2a60e.json patch.json Slower (3): - spectral_norm: 265 ms +- 2 ms -> 277 ms +- 7 ms: 1.04x slower - xml_etree_iterparse: 217 ms +- 2 ms -> 226 ms +- 4 ms: 1.04x slower - nqueens: 261 ms +- 2 ms -> 269 ms +- 3 ms: 1.03x slower Faster (3): - scimark_sor: 519 ms +- 10 ms -> 496 ms +- 7 ms: 1.05x faster - mako: 43.0 ms +- 0.8 ms -> 41.5 ms +- 0.2 ms: 1.04x faster - call_method: 16.2 ms +- 0.2 ms -> 15.7 ms +- 0.3 ms: 1.03x faster Benchmark hidden because not significant (58): 2to3, call_method_slots, call_method_unknown, (...) Hum, boring result. This change alone doesn't change any significant speedup, even some slowndon. Maybe it's just a bad idea. Maybe it should be combined with other new bytecode instructions. Maybe only a full new instruction set using registers show significant speedup. I don't know :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 09:08:21 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 25 Nov 2016 14:08:21 +0000 Subject: [issue28800] Add RETURN_NONE bytecode instruction In-Reply-To: <1480071315.87.0.448012344283.issue28800@psf.upfronthosting.co.za> Message-ID: <1480082901.4.0.232296609913.issue28800@psf.upfronthosting.co.za> STINNER Victor added the comment: > Do you want to add RETURN_NONE or RETURN_CONST? Or both? Only RETURN_NONE because on some corner cases it allow to avoid completely the None constant from code.co_consts and reduce the stack size. I'm not sure that I want to start taking the same road of WPython which added a *lot* of specialized instructions (combining two or more existing instructions). As you said, it has a cost on the maintenance, and might have a negative impact if _PyEval_EvalFrameDefault() becomes too big. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 09:25:22 2016 From: report at bugs.python.org (STINNER Victor) Date: Fri, 25 Nov 2016 14:25:22 +0000 Subject: [issue28673] pyro4 with more than 15 threads often crashes 2.7.12 In-Reply-To: <1480081154.73.0.735827907914.issue28673@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > I suggest thread_PyThread_start_new_thread() raise RuntimeError("can't start thread: finalizing") Where *exactly*? Py_FinalizeEx() first calls wait_for_thread_shutdown() and *then* sets _Py_Finalizing to tstate. Does wait_for_thread_shutdown() complete on this bug? Note: It's not the first time that I noticed a deadlock around this code :-/ I recall a silly bug when you press CTRL+c while wait_for_thread_shutdown() is running. See for example threading_shutdown_interrupted.py attached to the issue #20526. Run it and quickly press CTRL+c. Sometime, it does crash Python with a segfault... --- haypo at selma$ ./python threading_shutdown_interrupted.py ..........................................................................................................................................................................................................Exception ignored in: Traceback (most recent call last): File "/home/haypo/prog/python/default/Lib/threading.py", line 1290, in _shutdown t.join() File "/home/haypo/prog/python/default/Lib/threading.py", line 1056, in join . self._wait_for_tstate_lock() File "/home/haypo/prog/python/default/Lib/threading.py", line 1072, in _wait_for_tstate_lock ... elif lock.acquire(block, timeout): File "threading_shutdown_interrupted.py", line 29, in killer .. raise KeyboardInterrupt() KeyboardInterrupt: ^CSegmentation fault (core dumped) --- Python finalization is a very fragile and complex task :-/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 09:31:37 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Nov 2016 14:31:37 +0000 Subject: [issue28793] Copy-paste error in collections.abc docs for AsyncGenerator In-Reply-To: <1480024866.24.0.433904664953.issue28793@psf.upfronthosting.co.za> Message-ID: <20161125143130.116150.57207.CC44649D@psf.io> Roundup Robot added the comment: New changeset 078c037b1571 by Berker Peksag in branch '3.6': Issue #28793: Fix c/p error in AsyncGenerator documentation https://hg.python.org/cpython/rev/078c037b1571 New changeset 0bf7c2d99bf1 by Berker Peksag in branch 'default': Issue #28793: Merge from 3.6 https://hg.python.org/cpython/rev/0bf7c2d99bf1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 09:32:33 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 25 Nov 2016 14:32:33 +0000 Subject: [issue28793] Copy-paste error in collections.abc docs for AsyncGenerator In-Reply-To: <1480024866.24.0.433904664953.issue28793@psf.upfronthosting.co.za> Message-ID: <1480084353.2.0.470841495132.issue28793@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! ---------- assignee: -> docs at python components: +Documentation nosy: +berker.peksag, docs at python resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 09:35:54 2016 From: report at bugs.python.org (Aviv Palivoda) Date: Fri, 25 Nov 2016 14:35:54 +0000 Subject: [issue28518] execute("begin immediate") throwing OperationalError In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za> Message-ID: <1480084554.6.0.938096100893.issue28518@psf.upfronthosting.co.za> Aviv Palivoda added the comment: There are already a few test's that start a transaction explicitly: In dbapi.SqliteOnConflictTests CheckOnConflictRollbackWithExplicitTransaction, CheckOnConflictAbortRaisesWithExplicitTransactions which set ``isolation_level = None``. On the other hand in transaction.TransactionalDDL.CheckTransactionalDDL the test do not set the isolation_level to None but start a transaction explicitly. The test pass because sqlite3_stmt_readonly return true for "begin" and "begin deferred". I think that if we say that in order to start a transaction implicitly the isolation_level needs to be None CheckTransactionalDDL should be changed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 09:36:18 2016 From: report at bugs.python.org (Richard s. Gordon) Date: Fri, 25 Nov 2016 14:36:18 +0000 Subject: [issue28802] Python 3.6.0b4 Reports ncurses present in Cygwin but fails to build for cygwin Message-ID: <1480084578.87.0.616449400889.issue28802@psf.upfronthosting.co.za> Changes by Richard s. Gordon : ---------- nosy: eclectic9509 priority: normal severity: normal status: open title: Python 3.6.0b4 Reports ncurses present in Cygwin but fails to build for cygwin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 09:37:50 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Nov 2016 14:37:50 +0000 Subject: [issue28796] FIX warnings in documentation build In-Reply-To: <1480034638.89.0.480412503325.issue28796@psf.upfronthosting.co.za> Message-ID: <20161125143747.28917.79486.D93EBB2C@psf.io> Roundup Robot added the comment: New changeset f16f0500b49b by Berker Peksag in branch 'default': Issue #28796: Silence Sphinx warnings https://hg.python.org/cpython/rev/f16f0500b49b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 09:38:07 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 25 Nov 2016 14:38:07 +0000 Subject: [issue28796] FIX warnings in documentation build In-Reply-To: <1480034638.89.0.480412503325.issue28796@psf.upfronthosting.co.za> Message-ID: <1480084687.89.0.455885300154.issue28796@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 09:42:05 2016 From: report at bugs.python.org (Richard S. Gordon) Date: Fri, 25 Nov 2016 14:42:05 +0000 Subject: [issue28803] Python 3.6.0b4 Reports ncurses present in Cygwin but fails to build for Cygwin Message-ID: <1480084925.94.0.108029880914.issue28803@psf.upfronthosting.co.za> Changes by Richard S. Gordon : ---------- components: Build nosy: rigordo priority: normal severity: normal status: open title: Python 3.6.0b4 Reports ncurses present in Cygwin but fails to build for Cygwin versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 09:47:29 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 25 Nov 2016 14:47:29 +0000 Subject: [issue28803] Python 3.6.0b4 Reports ncurses present in Cygwin but fails to build for Cygwin Message-ID: <1480085249.12.0.457642726353.issue28803@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Python 3.6.0b4 Reports ncurses present in Cygwin but fails to build for cygwin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 10:33:56 2016 From: report at bugs.python.org (Charalampos Stratakis) Date: Fri, 25 Nov 2016 15:33:56 +0000 Subject: [issue28689] OpenSSL 1.1.0c test failures In-Reply-To: <1479132647.76.0.450425015981.issue28689@psf.upfronthosting.co.za> Message-ID: <1480088036.91.0.172536264803.issue28689@psf.upfronthosting.co.za> Charalampos Stratakis added the comment: Tested this in Fedora Rawhide virtual machine, where the fix for the problematic openssl commit was backported, and now the tests hang at test_poplib. Exception in thread Thread-982: Traceback (most recent call last): File "/home/harris/dev/cpython/_install/lib/python3.6/threading.py", line 916, in _bootstrap_inner self.run() File "/home/harris/dev/cpython/_install/lib/python3.6/test/test_poplib.py", line 222, in run asyncore.loop(timeout=0.1, count=1) File "/home/harris/dev/cpython/_install/lib/python3.6/asyncore.py", line 207, in loop poll_fun(timeout, map) File "/home/harris/dev/cpython/_install/lib/python3.6/asyncore.py", line 150, in poll read(obj) File "/home/harris/dev/cpython/_install/lib/python3.6/asyncore.py", line 87, in read obj.handle_error() File "/home/harris/dev/cpython/_install/lib/python3.6/asyncore.py", line 83, in read obj.handle_read_event() File "/home/harris/dev/cpython/_install/lib/python3.6/asyncore.py", line 423, in handle_read_event self.handle_read() File "/home/harris/dev/cpython/_install/lib/python3.6/test/test_poplib.py", line 192, in handle_read asynchat.async_chat.handle_read(self) File "/home/harris/dev/cpython/_install/lib/python3.6/asynchat.py", line 121, in handle_read self.handle_error() File "/home/harris/dev/cpython/_install/lib/python3.6/asynchat.py", line 117, in handle_read data = self.recv(self.ac_in_buffer_size) File "/home/harris/dev/cpython/_install/lib/python3.6/asyncore.py", line 374, in recv data = self.socket.recv(buffer_size) File "/home/harris/dev/cpython/_install/lib/python3.6/ssl.py", line 987, in recv return self.read(buflen) File "/home/harris/dev/cpython/_install/lib/python3.6/ssl.py", line 865, in read return self._sslobj.read(len, buffer) File "/home/harris/dev/cpython/_install/lib/python3.6/ssl.py", line 627, in read v = self._sslobj.read(len) OSError: [Errno 0] Error ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 11:05:53 2016 From: report at bugs.python.org (SilentGhost) Date: Fri, 25 Nov 2016 16:05:53 +0000 Subject: [issue28786] Warnings in Misc/NEWS In-Reply-To: <1479976926.46.0.685904317893.issue28786@psf.upfronthosting.co.za> Message-ID: <1480089953.87.0.163556659899.issue28786@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- resolution: -> out of date stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 11:19:41 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 25 Nov 2016 16:19:41 +0000 Subject: [issue28801] configparser: before_get() method of class Interpolation has positional 'parser' parameter that is not used. In-Reply-To: <1480071351.83.0.49150116079.issue28801@psf.upfronthosting.co.za> Message-ID: <1480090781.18.0.914894911932.issue28801@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 11:32:40 2016 From: report at bugs.python.org (=?utf-8?q?Jan_Veleck=C3=BD?=) Date: Fri, 25 Nov 2016 16:32:40 +0000 Subject: [issue28795] Misleading stating, that SIGINT handler is installed by default In-Reply-To: <1480026357.5.0.735730414686.issue28795@psf.upfronthosting.co.za> Message-ID: <1480091560.08.0.0775338892332.issue28795@psf.upfronthosting.co.za> Jan Veleck? added the comment: That's good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 11:47:51 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 25 Nov 2016 16:47:51 +0000 Subject: [issue28738] Document SIGBREAK as argument for signal() under Windows. In-Reply-To: <1479497916.69.0.534558560438.issue28738@psf.upfronthosting.co.za> Message-ID: <20161125164741.21336.26802.83E0D3AD@psf.io> Roundup Robot added the comment: New changeset dddce0f539dd by Berker Peksag in branch '3.5': Issue #28738: Document SIGBREAK as an acceptable value on Windows https://hg.python.org/cpython/rev/dddce0f539dd New changeset 43856eb83dc1 by Berker Peksag in branch '3.6': Issue #28738: Merge from 3.6 https://hg.python.org/cpython/rev/43856eb83dc1 New changeset 04eba322be92 by Berker Peksag in branch 'default': Issue #28738: Merge from 3.6 https://hg.python.org/cpython/rev/04eba322be92 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 11:48:31 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 25 Nov 2016 16:48:31 +0000 Subject: [issue28738] Document SIGBREAK as argument for signal() under Windows. In-Reply-To: <1479497916.69.0.534558560438.issue28738@psf.upfronthosting.co.za> Message-ID: <1480092511.73.0.533154986163.issue28738@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report and for the patch, Wojtek! ---------- nosy: +berker.peksag resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 12:05:50 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 25 Nov 2016 17:05:50 +0000 Subject: [issue28733] Show how to use mock_open in modules other that __main__ In-Reply-To: <1479475072.8.0.338397997846.issue28733@psf.upfronthosting.co.za> Message-ID: <1480093550.74.0.501635354094.issue28733@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report and for the patch. I think expanding the "Where to patch" [1] section would be better. We can then refer to it from the mock_open() documentation. [1] https://docs.python.org/3.6/library/unittest.mock.html#where-to-patch ---------- nosy: +berker.peksag, michael.foord stage: -> patch review versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 12:13:14 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 25 Nov 2016 17:13:14 +0000 Subject: [issue28288] Expose environment variable for Py_Py3kWarningFlag In-Reply-To: <1474993446.86.0.709676160725.issue28288@psf.upfronthosting.co.za> Message-ID: <1480093994.95.0.465434402632.issue28288@psf.upfronthosting.co.za> Berker Peksag added the comment: Roy's patch looks good to me in general. Benjamin, as the RM of 2.7, do you have any objections? ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 12:29:42 2016 From: report at bugs.python.org (Masayuki Yamamoto) Date: Fri, 25 Nov 2016 17:29:42 +0000 Subject: [issue28802] Python 3.6.0b4 Reports ncurses present in Cygwin but fails to build for cygwin Message-ID: <1480094982.05.0.769470082506.issue28802@psf.upfronthosting.co.za> New submission from Masayuki Yamamoto: We're discussing a cause of this issue at #25720. ---------- nosy: +masamoto _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 13:15:42 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 25 Nov 2016 18:15:42 +0000 Subject: [issue28802] Python 3.6.0b4 Reports ncurses present in Cygwin but fails to build for cygwin In-Reply-To: <1480094982.05.0.769470082506.issue28802@psf.upfronthosting.co.za> Message-ID: <1480097742.79.0.283998400306.issue28802@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Fix curses module compilation with ncurses6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 13:24:28 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 25 Nov 2016 18:24:28 +0000 Subject: [issue8145] Documentation about sqlite3 isolation_level In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za> Message-ID: <1480098268.8.0.481294950506.issue8145@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: -terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 14:37:06 2016 From: report at bugs.python.org (Julien Palard) Date: Fri, 25 Nov 2016 19:37:06 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480102626.83.0.20256880747.issue28754@psf.upfronthosting.co.za> Julien Palard added the comment: Quoting @martin > * bisect_right(a, x[, lo[, hi]]) -> index > This signature is removed. I think removing it is reasonable, because pydoc can extract the proper signature from the Arg Clinic metadata. In fact, http://docs.python.org/howto/clinic.html, bullet ".4", told me do remove it: > If the old docstring had a first line that looked like a function signature, throw that line away. (The docstring doesn?t need it anymore?when you use help() on your builtin in the future, the first line will be built automatically based on the function?s signature.) > * Additional descriptions of each parameter. I tend to think these are redundant with the main text, so agree with removing them from the patch now. OK, will remove them. * Addition of full stop (.) at end of first paragraph. I suggested this as a minor cleanup, but it could be fixed later if you prefer. Can remove it to simplify verification, but as doctests will be different as doc told me to remove the signature, so is it work removing this dot ? I don't think so. * Removal of default values in last paragraph. The first is redundant with the Arg Clinic signature, so I suggested to remove it. For the second, I would add it back if we remove the list of parameters, since it explains what the special value -1 means. I'll revert it too as I'll remove the documentation in the parameter list. Will upload a patch later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 14:43:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 25 Nov 2016 19:43:54 +0000 Subject: [issue28518] execute("begin immediate") throwing OperationalError In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za> Message-ID: <1480103034.98.0.168557398554.issue28518@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that allows executing "begin immediate" explicitly with any isolation_level. I don't know what behavior is more preferable. ---------- Added file: http://bugs.python.org/file45644/sqlite-explicit-begin.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 15:08:53 2016 From: report at bugs.python.org (Steve Dower) Date: Fri, 25 Nov 2016 20:08:53 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1480104533.56.0.745962445354.issue28781@psf.upfronthosting.co.za> Steve Dower added the comment: I was hoping that Repair wouldn't be an option after doing that cleaning. Maybe try uninstalling through Programs and Features, then run those commands again, go into the places you installed it and delete the files, and then run a fresh install. If you still get the Modify/Repair/Uninstall page when you run the installer, keep doing Uninstall until you get back to the Install/Customize page. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 15:09:28 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 25 Nov 2016 20:09:28 +0000 Subject: [issue28288] Expose environment variable for Py_Py3kWarningFlag In-Reply-To: <1474993446.86.0.709676160725.issue28288@psf.upfronthosting.co.za> Message-ID: <1480104568.29.0.0367691906516.issue28288@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PYTHON3WARNINGS looks as Python 3 variant of PYTHONWARNINGS. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 15:19:57 2016 From: report at bugs.python.org (Big Stone) Date: Fri, 25 Nov 2016 20:19:57 +0000 Subject: [issue28518] execute("begin immediate") throwing OperationalError In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za> Message-ID: <1480105197.85.0.261074050367.issue28518@psf.upfronthosting.co.za> Big Stone added the comment: Comment kindly provided by D. Richard Hipp himself: """"" I don't have a login for the python bug tracker so I cannot comment there. But I think I see the problem. This is as Aviv Polivoda remarks at https://bugs.python.org/issue28518#msg279808 I think this is a error in sqlite as the documentation says: "ransaction control statements such as BEGIN, COMMIT, ROLLBACK, SAVEPOINT, and RELEASE cause sqlite3_stmt_readonly() to return true," Except it is not a bug in SQLite, but rather an ambiguity in the documentation. In his quote, Aviv omitted the second clause from the documentation: "since the statements themselves do not actually modify the database but rather they control the timing of when other statements modify the database." (Full text here: https://www.sqlite.org/c3ref/stmt_readonly.html) For a plain BEGIN statement, there are no changes to the database file, so sqlite3_stmt_readonly() does indeed return TRUE. But for a BEGIN IMMEDIATE statement, there are database changes, because the extra IMMEDIATE keyword causes the statement to go ahead and start transaction "immediately". So technically, the documentation is correct, though I can certainly understand that it is misleading and ambiguous as currently worded. Clarification will be checked in shortly and will appear in the 3.16.0 release. Note also that behavior of sqlite3_stmt_readonly() has not changed since that interface was first added for the 3.7.5 release on 2011-02-01. So this is not an SQLite regression. Rather, I presume that Python has recently started using the sqlite3_stmt_readonly() interface in a new way. -- D. Richard Hipp drh at sqlite.org """"" ---------- nosy: +Big Stone _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 15:28:01 2016 From: report at bugs.python.org (Big Stone) Date: Fri, 25 Nov 2016 20:28:01 +0000 Subject: [issue28518] execute("begin immediate") throwing OperationalError In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za> Message-ID: <1480105681.5.0.628211176013.issue28518@psf.upfronthosting.co.za> Big Stone added the comment: rewording of sqlite documentation: http://www.sqlite.org/src/info/a4205a83e4ed977a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 17:00:36 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 25 Nov 2016 22:00:36 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za> Message-ID: <1480111236.17.0.771684035276.issue28739@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Much of this discussion seems to duplicate and effectively re-open of #25179, wherein it was decided/accepted that true, non-degenerate, non-trivial, non-constant, f-strings that actually do formatting are not constants and do not and should not become docstrings. I agree. I think this issue should either be closed as 'not a bug' or redefined as a doc issue. It was noted by Martin P. in #25179 that "a constant f-string without any interpolations does become a doc string." That is because such is really a string literal and not really an f-string, in the same sense that 'circle of radius 0' is really a point and not a circle. The current glossary entry is "docstring A string literal which appears as the first expression in a class, function or module. While ignored when the suite is executed, it is recognized by the compiler and put into the __doc__ attribute of the enclosing class, function or module. Since it is available via introspection, it is the canonical place for documentation of the object." I suggest adding "Bytestring literals and non-trivial f-strings do not become docstrings." as the second sentence. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 17:03:33 2016 From: report at bugs.python.org (Davin Potts) Date: Fri, 25 Nov 2016 22:03:33 +0000 Subject: [issue28699] Imap from ThreadPool behaves unexpectedly In-Reply-To: <1479234139.82.0.483433491582.issue28699@psf.upfronthosting.co.za> Message-ID: <1480111413.78.0.824555670371.issue28699@psf.upfronthosting.co.za> Davin Potts added the comment: @xiang.zhang: Nice catch -- thank you for pointing out the additional issue that arises when trying to provoke the issue twice in a row. The module attribute `job_counter` helped, in this situation, point out what might have otherwise been overlooked. I didn't like any of my previously suggested approaches, but I think there's a 4th option: 4. Guard against misbehaving generators/iterables *before* they are put into the taskqueue. Now when we provide a problematic generator/iterable to imap, the exception it triggers is caught and the resulting exception passed through the system to make use of the logic that is already in place. This same issue can arise for imap_unordered() as well as imap() and can be addressed in the same manner. Attaching another preliminary patch that still lacks formal tests but I'll attach crude versions of tests momentarily. If we're still missing some use case or other logic path, now's the time to find it. ---------- Added file: http://bugs.python.org/file45645/issue_28699_guards_iterable_still_lacks_formal_test_py3x.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 17:05:27 2016 From: report at bugs.python.org (Davin Potts) Date: Fri, 25 Nov 2016 22:05:27 +0000 Subject: [issue28699] Imap from ThreadPool behaves unexpectedly In-Reply-To: <1479234139.82.0.483433491582.issue28699@psf.upfronthosting.co.za> Message-ID: <1480111527.21.0.562575652368.issue28699@psf.upfronthosting.co.za> Davin Potts added the comment: Attaching promised crude tests. ---------- Added file: http://bugs.python.org/file45646/issue_28699_repro.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 17:06:42 2016 From: report at bugs.python.org (Davin Potts) Date: Fri, 25 Nov 2016 22:06:42 +0000 Subject: [issue28696] imap from ThreadPool hangs by an exception in a generator function In-Reply-To: <1479214370.8.0.751710549169.issue28696@psf.upfronthosting.co.za> Message-ID: <1480111602.86.0.778243666216.issue28696@psf.upfronthosting.co.za> Davin Potts added the comment: Closing this issue -- all further discussion moves to issue28699 ---------- resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 17:07:05 2016 From: report at bugs.python.org (Davin Potts) Date: Fri, 25 Nov 2016 22:07:05 +0000 Subject: [issue28625] multiprocessing.Pool.imap swallows exceptions thrown by generators In-Reply-To: <1478449003.58.0.0873174644967.issue28625@psf.upfronthosting.co.za> Message-ID: <1480111625.53.0.0256728688162.issue28625@psf.upfronthosting.co.za> Davin Potts added the comment: Closing this issue -- all further discussion moves to issue28699 ---------- resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 17:11:56 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 25 Nov 2016 22:11:56 +0000 Subject: [issue28758] UnicodeDecodeError: 'gbk' codec can't decode byte 0xab in position 74: illegal multibyte sequence In-Reply-To: <1479705448.56.0.0763380057233.issue28758@psf.upfronthosting.co.za> Message-ID: <1480111916.62.0.447537776682.issue28758@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I don't see what this has to do with Python. Perhaps out Windows experts can, or can ask for more info. The last I knew, code page 65001 was buggy, but that is not a Python issue. ---------- components: +Windows nosy: +paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 17:22:35 2016 From: report at bugs.python.org (John Helour) Date: Fri, 25 Nov 2016 22:22:35 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1480112555.71.0.0467612330165.issue24339@psf.upfronthosting.co.za> John Helour added the comment: PEP8 compliant, added missing codepoints, utf-8 to \uXXXX rewrited ---------- Added file: http://bugs.python.org/file45647/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 17:23:35 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 25 Nov 2016 22:23:35 +0000 Subject: [issue28763] Use en-dashes for ranges in docs In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za> Message-ID: <1480112615.69.0.0131655518673.issue28763@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I checked the patch with Rietveld and all the changes are '-' to '--' in numeric ranges in text. LGTM. ---------- nosy: +terry.reedy stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 17:26:48 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 25 Nov 2016 22:26:48 +0000 Subject: [issue28777] Add asyncio.Queue __aiter__, __anext__ methods In-Reply-To: <1479877132.48.0.693527153069.issue28777@psf.upfronthosting.co.za> Message-ID: <1480112808.97.0.059228123193.issue28777@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> test needed title: asinc iter queue -> Add asyncio.Queue __aiter__, __anext__ methods versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 17:29:48 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 25 Nov 2016 22:29:48 +0000 Subject: [issue28788] ConfigParser should be able to write config to a given filename, not only into file object In-Reply-To: <1479999718.88.0.148590995726.issue28788@psf.upfronthosting.co.za> Message-ID: <1480112988.16.0.520163577259.issue28788@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: Feature request: ConfigParser should be able to write config to a given filename, not only into file object -> ConfigParser should be able to write config to a given filename, not only into file object _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 17:35:21 2016 From: report at bugs.python.org (John Helour) Date: Fri, 25 Nov 2016 22:35:21 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1480113321.98.0.956592761263.issue24339@psf.upfronthosting.co.za> John Helour added the comment: @mdk Big thanks for the checker. >Looks like your implementation is missing some codepoints, like "\t": > > >>> >print("\t".encode(encoding='iso6937')) > [...] > UnicodeError: encoding with 'iso6937' codec failed (UnicodeError: Unacceptable utf-8 character) The '\t' character is undefined in the iso6937 table, like all chars within the range 0x00 - 0x1F. I don't know how to handle such input for conversion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 18:56:28 2016 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 25 Nov 2016 23:56:28 +0000 Subject: [issue28777] Add asyncio.Queue __aiter__, __anext__ methods In-Reply-To: <1479877132.48.0.693527153069.issue28777@psf.upfronthosting.co.za> Message-ID: <1480118188.71.0.0532657017571.issue28777@psf.upfronthosting.co.za> Guido van Rossum added the comment: This should be an upstream PR first (GitHub.com/python/asyncio). Also, too late for 3.6. ---------- versions: -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 19:29:38 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 26 Nov 2016 00:29:38 +0000 Subject: [issue28777] Add asyncio.Queue __aiter__, __anext__ methods In-Reply-To: <1479877132.48.0.693527153069.issue28777@psf.upfronthosting.co.za> Message-ID: <1480120178.26.0.43430619483.issue28777@psf.upfronthosting.co.za> Guido van Rossum added the comment: Also it's not clear that it's a good idea without more thought -- there's no way to end the loop on the producing side. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 21:11:16 2016 From: report at bugs.python.org (Steve Dower) Date: Sat, 26 Nov 2016 02:11:16 +0000 Subject: [issue28758] UnicodeDecodeError: 'gbk' codec can't decode byte 0xab in position 74: illegal multibyte sequence In-Reply-To: <1479705448.56.0.0763380057233.issue28758@psf.upfronthosting.co.za> Message-ID: <1480126276.12.0.466545801241.issue28758@psf.upfronthosting.co.za> Steve Dower added the comment: For something as low level as os.popen you should read bytes and decode them manually with the correct encoding. If you use subprocess.Popen instead you can specify encoding="utf-8" in the call (on 3.6). Unfortunately, it's a very bad idea to rely on the default encoding for inter-process communication, but it's also impossible for us to change the defaults without breaking existing code unnecessarily. I'm not particularly aware of code-page 65001 itself being buggy, but there are certainly issues in the ANSI-mode console when you select it. On 3.6 we use the Unicode APIs directly for the console, but that has no impact on pipes or redirected handles, which is what this issue is encountering. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 23:00:10 2016 From: report at bugs.python.org (liugang) Date: Sat, 26 Nov 2016 04:00:10 +0000 Subject: [issue28804] file tell() report incorrect file position (Windows, Linux is OK) Message-ID: <1480132809.99.0.636633604449.issue28804@psf.upfronthosting.co.za> New submission from liugang: D:\Python35\python.exe "D:\PyCharm Community Edition 2016.3\helpers\pydev\pydevconsole.py" 8871 8872 PyDev console: starting. import sys; print('Python %s on %s' % (sys.version, sys.platform)) sys.path.extend(['C:\\Users\\liugang10\\PycharmProjects\\untitled', 'C:/Users/liugang10/PycharmProjects/untitled']) Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)] on win32 >>> f = open('e:\\1.txt') >>> f.readline() '1\n' >>> f.tell() 340282367000166625996085689099021713410 >>> f.readline() '2\n' >>> f.tell() 340282367000166625996085689099021713412 ---------- assignee: terry.reedy components: IDLE files: 1.txt messages: 281752 nosy: liugang10, terry.reedy priority: normal severity: normal status: open title: file tell() report incorrect file position (Windows, Linux is OK) type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file45648/1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 23:06:51 2016 From: report at bugs.python.org (liugang) Date: Sat, 26 Nov 2016 04:06:51 +0000 Subject: [issue28804] file tell() report incorrect file position on Windows (but Linux is OK) In-Reply-To: <1480132809.99.0.636633604449.issue28804@psf.upfronthosting.co.za> Message-ID: <1480133211.43.0.239478935257.issue28804@psf.upfronthosting.co.za> liugang added the comment: Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)] on win32 Type "copyright", "credits" or "license()" for more information. >>> f = open('e:\\1.txt') >>> f.readline() '1\n' >>> f.tell() 340282367000166625996085689099021713410 >>> f.readline() '2\n' >>> f.tell() 340282367000166625996085689099021713412 >>> ---------- title: file tell() report incorrect file position (Windows, Linux is OK) -> file tell() report incorrect file position on Windows (but Linux is OK) Added file: http://bugs.python.org/file45649/1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 25 23:59:44 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 26 Nov 2016 04:59:44 +0000 Subject: [issue28804] file tell() report incorrect file position on Windows (but Linux is OK) In-Reply-To: <1480132809.99.0.636633604449.issue28804@psf.upfronthosting.co.za> Message-ID: <1480136384.58.0.272905554881.issue28804@psf.upfronthosting.co.za> Martin Panter added the comment: Is this a duplicate of Issue 26016? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 01:10:03 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 26 Nov 2016 06:10:03 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za> Message-ID: <1480140603.32.0.982761401895.issue28739@psf.upfronthosting.co.za> Raymond Hettinger added the comment: [TJR] > I think this issue should either be closed as 'not a bug' > or redefined as a doc issue. I concur. FWIW, here are some comparisons. Not allowed: 'Not counted as' + ' a docstring' 'Not a docstring ' * 10 b'Also not a docstring' Allowed: 'This is a ' 'docstring' r'This is a docstring' ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 01:24:28 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 26 Nov 2016 06:24:28 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za> Message-ID: <1480141468.51.0.145242571915.issue28739@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't really care that much, but I personally think that it would be more consistent (and a simpler rule) if *no* f-string (not even ones without substitutions) were to be allowed as docstrings. In all other examples that Raymond shows it's the syntactic form that matters -- no on b-strings, yes on r-strings, yes on concatenation (using space), no on +, etc. The language reference clearly defines f-strings as all strings with an f-prefix, and says that they *may* contain replacement fields. So it's clear that an f-string without replacements is still an f-string, and it is still distinguished from other strings. Hence I think it should not be allowed as a docstring. (Also, what purpose could using the f-prefix for a docstring possibly have? All the other allowable combinations do have a use.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 02:25:20 2016 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 26 Nov 2016 07:25:20 +0000 Subject: [issue28288] Expose environment variable for Py_Py3kWarningFlag In-Reply-To: <1480093994.95.0.465434402632.issue28288@psf.upfronthosting.co.za> Message-ID: <1480145117.2445385.799513089.391B418F@webmail.messagingengine.com> Benjamin Peterson added the comment: Yes, I suppose this falls under the general exemption in 2.x for -3 warning changes. On Fri, Nov 25, 2016, at 09:13, Berker Peksag wrote: > > Berker Peksag added the comment: > > Roy's patch looks good to me in general. Benjamin, as the RM of 2.7, do > you have any objections? > > ---------- > nosy: +benjamin.peterson > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 02:39:37 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 26 Nov 2016 07:39:37 +0000 Subject: [issue28758] UnicodeDecodeError: 'gbk' codec can't decode byte 0xab in position 74: illegal multibyte sequence In-Reply-To: <1479705448.56.0.0763380057233.issue28758@psf.upfronthosting.co.za> Message-ID: <1480145977.58.0.819238302672.issue28758@psf.upfronthosting.co.za> Terry J. Reedy added the comment: So, does there appear to be a Python bug to fix or should this be closed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 03:23:21 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Nov 2016 08:23:21 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za> Message-ID: <1480148601.64.0.175988788288.issue28739@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Adding more confusion, the expression ``('This is a docstring')`` is accepted as a docstring despite the fact that it is not a string literal. The cases f'string' and ('string') looks similar to me. Both are simple expressions that become indistinguishable from string literals due to some optimization at parser level. It would be nice to disallow them as docstrings, but it may be not easy to do. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 03:27:34 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 26 Nov 2016 08:27:34 +0000 Subject: [issue28799] Drop CALL_PROFILE special build? In-Reply-To: <1480064573.69.0.905508550534.issue28799@psf.upfronthosting.co.za> Message-ID: <1480148854.95.0.151834328197.issue28799@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +Jeremy.Hylton _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 04:02:22 2016 From: report at bugs.python.org (Antti Haapala) Date: Sat, 26 Nov 2016 09:02:22 +0000 Subject: [issue28682] Bytes support in os.fwalk() In-Reply-To: <1479029050.5.0.426622691368.issue28682@psf.upfronthosting.co.za> Message-ID: <1480150942.23.0.132176852997.issue28682@psf.upfronthosting.co.za> Antti Haapala added the comment: shouldn't this get in sooner, as the 3.5.2 documentation says that it behaves exactly like `os.walk`, with some additions, none of which says "bytes paths are not supported". This looks like a bug to me. ---------- nosy: +ztane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 04:23:22 2016 From: report at bugs.python.org (Julien Palard) Date: Sat, 26 Nov 2016 09:23:22 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480152202.22.0.81565837268.issue28754@psf.upfronthosting.co.za> Julien Palard added the comment: Here is the new patch, I ran a diff between "./python -m pydoc _bisect" before and after my patch, here it is: 13,15c13 < bisect_left(...) < bisect_left(a, x[, lo[, hi]]) -> index < --- > bisect_left(a, x, lo=0, hi=-1) 25,27c23 < bisect_right(...) < bisect_right(a, x[, lo[, hi]]) -> index < --- > bisect_right(a, x, lo=0, hi=-1) 32c28 < beyond the rightmost x already there --- > beyond the rightmost x already there. 37,39c33 < insort_left(...) < insort_left(a, x[, lo[, hi]]) < --- > insort_left(a, x, lo=0, hi=-1) 47,49c41 < insort_right(...) < insort_right(a, x[, lo[, hi]]) < --- > insort_right(a, x, lo=0, hi=-1) So I kept my addition of the missing full stop, and dropped the handwritten signature as Argument Clinic generates it. ---------- Added file: http://bugs.python.org/file45650/issue28754-6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 04:27:42 2016 From: report at bugs.python.org (Julien Palard) Date: Sat, 26 Nov 2016 09:27:42 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480152462.73.0.465056006742.issue28754@psf.upfronthosting.co.za> Julien Palard added the comment: Should we also update howto/clinic, bullet "11.", to be explicit about not adding per-parameter in the same patch? Like a: > If you're porting existing function to Argument clinic, skip this step to simplify code review. ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 05:19:50 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 26 Nov 2016 10:19:50 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480155590.08.0.901636725856.issue28754@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Curiously, this patch gives about a 10% to 15% speedup. Any sense of how that improvement arises? $ py3.7 -m timeit -s 'from bisect import bisect' -s 'a=list(range(100))' 'bisect(a, 10)' 229 nsec # Clang baseline 202 nsec # Clang with patch 189 nsec # GCC-6 baseline 156 nsec # Gcc-6 with patch ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 05:26:37 2016 From: report at bugs.python.org (Julien Palard) Date: Sat, 26 Nov 2016 10:26:37 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480155997.31.0.690632174709.issue28754@psf.upfronthosting.co.za> Julien Palard added the comment: Hi Raymond, > Curiously, this patch gives about a 10% to 15% speedup. Any sense of how that improvement arises? That's because Argument Clinic is generating methoddef with METH_FASTCALL: $ grep FASTCALL Modules/clinic/_bisectmodule.c.h {"bisect_right", (PyCFunction)bisect_bisect_right, METH_FASTCALL, bisect_bisect_right__doc__}, {"insort_right", (PyCFunction)bisect_insort_right, METH_FASTCALL, bisect_insort_right__doc__}, {"bisect_left", (PyCFunction)bisect_bisect_left, METH_FASTCALL, bisect_bisect_left__doc__}, {"insort_left", (PyCFunction)bisect_insort_left, METH_FASTCALL, bisect_insort_left__doc__}, Instead of METH_VARARGS|METH_KEYWORDS: - {"bisect_right", (PyCFunction)bisect_right, - METH_VARARGS|METH_KEYWORDS, bisect_right_doc}, - {"insort_right", (PyCFunction)insort_right, - METH_VARARGS|METH_KEYWORDS, insort_right_doc}, - {"bisect_left", (PyCFunction)bisect_left, - METH_VARARGS|METH_KEYWORDS, bisect_left_doc}, - {"insort_left", (PyCFunction)insort_left, - METH_VARARGS|METH_KEYWORDS, insort_left_doc}, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 05:45:07 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Nov 2016 10:45:07 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480157107.03.0.0721984946723.issue28754@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Julien, you can declare the hi parameter as hi: Py_ssize_t(py_default="len(a)") = -1 if you want the signature be matching the documentation. In general, it is better to use converter names rather than format codes. > Curiously, this patch gives about a 10% to 15% speedup. Any sense of how that improvement arises? This is rather a random difference. Try to run the bench several times. With using Victor's perf module the difference is not significant. Maybe using FASTCALL have some positive effect, but it is unlikely noticeable with such complex function. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 06:08:54 2016 From: report at bugs.python.org (Stefan Krah) Date: Sat, 26 Nov 2016 11:08:54 +0000 Subject: [issue28805] Add documentation for METH_FASTCALL Message-ID: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za> New submission from Stefan Krah: It looks like METH_FASTCALL gives nice speedups (#28754). Is this an internal interface or can it be documented like METH_KEYWORDS etc.? ---------- assignee: docs at python components: Documentation messages: 281766 nosy: docs at python, haypo, serhiy.storchaka, skrah priority: normal severity: normal stage: needs patch status: open title: Add documentation for METH_FASTCALL type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 06:13:30 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 26 Nov 2016 11:13:30 +0000 Subject: [issue28806] Improve the netrc library Message-ID: <1480158810.39.0.736994382472.issue28806@psf.upfronthosting.co.za> New submission from Xiang Zhang: netrc library now gets some problems: 1. All tokens are mandatory. (#28780) 2. Token values are limited to a limited set of characters. (#557704) 3. Does not complain about macro definition without a null line. 4. If the login name is anonymous, security check is not needed. Propose a patch to handle these. I treat it as an enhancement of the existing library instead of bug fix. ---------- components: Library (Lib) files: netrc.patch keywords: patch messages: 281767 nosy: haypo, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Improve the netrc library type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45651/netrc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 06:15:20 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sat, 26 Nov 2016 11:15:20 +0000 Subject: [issue28780] netrc throws NetrcParseError for record without 'password' In-Reply-To: <1479917903.22.0.642970878487.issue28780@psf.upfronthosting.co.za> Message-ID: <1480158920.53.0.328779764152.issue28780@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- dependencies: +Improve the netrc library _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 06:44:19 2016 From: report at bugs.python.org (Julien Palard) Date: Sat, 26 Nov 2016 11:44:19 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480160659.73.0.626134786491.issue28754@psf.upfronthosting.co.za> Julien Palard added the comment: Hi Serhiy, > Julien, you can declare the hi parameter as > hi: Py_ssize_t(py_default="len(a)") = -1 Looks like a good idea, I was aware of its existance but did not took the time to read the doc about it, kind of learning step by stpe. But as you provided the syntax, I tested it, thanks for this! But it fails with a RuntimeError during python -m pydoc _bisect, I'm currently trying to understand why: $ ./python -m pydoc _bisect Traceback (most recent call last): File "/home/mdk/cpython-git/Lib/runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "/home/mdk/cpython-git/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/mdk/cpython-git/Lib/pydoc.py", line 2663, in cli() File "/home/mdk/cpython-git/Lib/pydoc.py", line 2628, in cli help.help(arg) File "/home/mdk/cpython-git/Lib/pydoc.py", line 1908, in help elif request: doc(request, 'Help on %s:', output=self._output) File "/home/mdk/cpython-git/Lib/pydoc.py", line 1645, in doc pager(render_doc(thing, title, forceload)) File "/home/mdk/cpython-git/Lib/pydoc.py", line 1638, in render_doc return title % desc + '\n\n' + renderer.document(object, name) File "/home/mdk/cpython-git/Lib/pydoc.py", line 382, in document if inspect.ismodule(object): return self.docmodule(*args) File "/home/mdk/cpython-git/Lib/pydoc.py", line 1172, in docmodule contents.append(self.document(value, key, name)) File "/home/mdk/cpython-git/Lib/pydoc.py", line 384, in document if inspect.isroutine(object): return self.docroutine(*args) File "/home/mdk/cpython-git/Lib/pydoc.py", line 1357, in docroutine signature = inspect.signature(object) File "/home/mdk/cpython-git/Lib/inspect.py", line 2994, in signature return Signature.from_callable(obj, follow_wrapped=follow_wrapped) File "/home/mdk/cpython-git/Lib/inspect.py", line 2744, in from_callable follow_wrapper_chains=follow_wrapped) File "/home/mdk/cpython-git/Lib/inspect.py", line 2223, in _signature_from_callable skip_bound_arg=skip_bound_arg) File "/home/mdk/cpython-git/Lib/inspect.py", line 2055, in _signature_from_builtin return _signature_fromstr(cls, func, s, skip_bound_arg) File "/home/mdk/cpython-git/Lib/inspect.py", line 2003, in _signature_fromstr p(name, default) File "/home/mdk/cpython-git/Lib/inspect.py", line 1985, in p default_node = RewriteSymbolics().visit(default_node) File "/home/mdk/cpython-git/Lib/ast.py", line 253, in visit return visitor(node) File "/home/mdk/cpython-git/Lib/ast.py", line 317, in generic_visit new_node = self.visit(old_value) File "/home/mdk/cpython-git/Lib/ast.py", line 253, in visit return visitor(node) File "/home/mdk/cpython-git/Lib/inspect.py", line 1977, in visit_Name return wrap_value(node.id) File "/home/mdk/cpython-git/Lib/inspect.py", line 1959, in wrap_value raise RuntimeError() RuntimeError > > Curiously, this patch gives about a 10% to 15% speedup. Any sense of how that improvement arises? > This is rather a random difference. Try to run the bench several times. With using Victor's perf module the difference is not significant. If you search for "perf" in the history of this issue you'll see that I already tested with Victor's perf module and it yielded a consistent 18% improvement on bisect.bisect("abcdef", "c") on two different machines. Clearly with more than 5 items, it will start to fade, and with a lot of items, it's not significand, obviously as it's an optimization about the call and not the implementation. So Raymond's test with 100 items may still see a speedup. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 06:50:47 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 26 Nov 2016 11:50:47 +0000 Subject: [issue28763] Use en-dashes for ranges in docs In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za> Message-ID: <20161126115043.81585.65967.66B7F6B7@psf.io> Roundup Robot added the comment: New changeset 77307437ae15 by Serhiy Storchaka in branch '3.5': Issue #28763: Use double hyphens (rendered as en-dashes) in numerical ranges https://hg.python.org/cpython/rev/77307437ae15 New changeset 59bd48afa1bc by Serhiy Storchaka in branch '2.7': Issue #28763: Use double hyphens (rendered as en-dashes) in numerical ranges https://hg.python.org/cpython/rev/59bd48afa1bc New changeset 3434d84efdd4 by Serhiy Storchaka in branch '3.6': Issue #28763: Use double hyphens (rendered as en-dashes) in numerical ranges https://hg.python.org/cpython/rev/3434d84efdd4 New changeset dc407f50e823 by Serhiy Storchaka in branch 'default': Issue #28763: Use double hyphens (rendered as en-dashes) in numerical ranges https://hg.python.org/cpython/rev/dc407f50e823 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 06:51:30 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Nov 2016 11:51:30 +0000 Subject: [issue28763] Use en-dashes for ranges in docs In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za> Message-ID: <1480161090.82.0.661253028992.issue28763@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Terry. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: +Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 06:59:42 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Nov 2016 11:59:42 +0000 Subject: [issue28805] Add documentation for METH_FASTCALL In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za> Message-ID: <1480161582.33.0.0686266640963.issue28805@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I suggest to keep it internal. It's meaning may be changed in future. I have some ideas about making it more convenient and faster (but I'm not sure that they would work). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 07:10:07 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 26 Nov 2016 12:10:07 +0000 Subject: [issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition In-Reply-To: <1471355745.98.0.805545529346.issue27777@psf.upfronthosting.co.za> Message-ID: <1480162207.46.0.348646798926.issue27777@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 07:52:19 2016 From: report at bugs.python.org (Julien Palard) Date: Sat, 26 Nov 2016 12:52:19 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480164739.39.0.909729178031.issue28754@psf.upfronthosting.co.za> Julien Palard added the comment: Hi Serhiy, hi: Py_ssize_t(py_default="len(a)") = -1 Won't works, as pydoc will use the inspect module (_signature_fromstr) to get the signature. _signature_fromstr expects a valid python signature, but `def foo(a, x, lo=0, high=len(a)): pass` is not valid (SyntaxError). Should we note that in the clinic documentation: > py_default > default as it should appear in Python code, as a string. Or None if there is no default. > py_default > default as it should appear in valid Python code, as a string. Or None if there is no default. ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 08:17:32 2016 From: report at bugs.python.org (Oskar Skog) Date: Sat, 26 Nov 2016 13:17:32 +0000 Subject: [issue28807] [NetBSD] interpreter hangs on exit after call to subprocess.Popen() Message-ID: <1480166252.16.0.187923291691.issue28807@psf.upfronthosting.co.za> New submission from Oskar Skog: This is a platform specific bug. Only noticed this on NetBSD 6.1 x86-32 on a VirtualBox machine. To me, the patches for NetBSD do not look relevant to subprocess or core stuff. http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/python27/patches/?only_with_tag=MAIN Test: #!/usr/pkg/bin/python import subprocess subprocess.Popen(['true']) print('Program finished.') # END OF FILE On an unaffected platform it will print "Program finished." and exit, on an affected platform it will print "Program finished." and hang. ---------- components: Interpreter Core messages: 281773 nosy: oskog97 priority: normal severity: normal status: open title: [NetBSD] interpreter hangs on exit after call to subprocess.Popen() type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 08:21:30 2016 From: report at bugs.python.org (Julien Palard) Date: Sat, 26 Nov 2016 13:21:30 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1480166490.74.0.660375695716.issue24339@psf.upfronthosting.co.za> Julien Palard added the comment: According to https://webstore.iec.ch/preview/info_isoiec6937%7Bed3.0%7Den.pdf: > NOTE: The shaded positions 00/00 to 01/15 and 07/15 to 09/15 are outside the scope of this International Standard. So it's clear to me that they are not undefined, they are just described elsewhere. According to https://en.wikipedia.org/wiki/ISO/IEC_6937: >ISO/IEC 6937:2001, [...] is a multibyte extension of ASCII Also, the glibc charmap for ISO_6937 define them: $ head -n 20 localedata/charmaps/ISO_6937 ISO_6937 % / % version: 1.0 % source: ECMA registry and ISO/IEC 6937:1992 % alias ISO-IR-156 % alias ISO_6937:1992 % alias ISO6937 CHARMAP /x00 NULL (NUL) /x01 START OF HEADING (SOH) /x02 START OF TEXT (STX) /x03 END OF TEXT (ETX) /x04 END OF TRANSMISSION (EOT) /x05 ENQUIRY (ENQ) /x06 ACKNOWLEDGE (ACK) /x07 BELL (BEL) /x08 BACKSPACE (BS) /x09 CHARACTER TABULATION (HT) Finally, if we're not implementing this range, this mean we have _no_ way to encode a new line, which looks highly strange to me, newline being a commonly used character. But I found _no_ line in the whole ISO/IEC6937 about its ASCII inheritance, I may have just missed it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 09:35:00 2016 From: report at bugs.python.org (Julien Palard) Date: Sat, 26 Nov 2016 14:35:00 +0000 Subject: [issue26363] __builtins__ propagation is misleading described in exec and eval documentation In-Reply-To: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za> Message-ID: <1480170900.75.0.0714267606463.issue26363@psf.upfronthosting.co.za> Julien Palard added the comment: Hi Xavier, thanks for reporting, Your first point is right, the implementation being: if (PyDict_GetItemString(globals, "__builtins__") == NULL) { if (PyDict_SetItemString(globals, "__builtins__", PyEval_GetBuiltins()) != 0) return NULL; } See proposed diff. For the second point, it looks right to me in the documentation, literally: "A reference to the dictionary of the builtin module builtins is inserted", so: It's a dict: >>> exec('print(type(globals()["__builtins__"]))', {}) It's the reference to the dict of the builtins module: >>> exec('globals()["__builtins__"]["len"] = "foo"', {}) >>> len 'foo' If you still think there's inconsistencies, please provide some code to reproduce it. ---------- keywords: +patch Added file: http://bugs.python.org/file45652/issue26363.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 09:41:22 2016 From: report at bugs.python.org (Oskar Skog) Date: Sat, 26 Nov 2016 14:41:22 +0000 Subject: [issue28807] [NetBSD] interpreter hangs on exit after call to subprocess.Popen() In-Reply-To: <1480166252.16.0.187923291691.issue28807@psf.upfronthosting.co.za> Message-ID: <1480171282.12.0.643920521588.issue28807@psf.upfronthosting.co.za> Oskar Skog added the comment: I really need a "stupid"-helmet today. Reopen if you can experience the same bug on a different platform. ---------- resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 09:59:44 2016 From: report at bugs.python.org (Julien Palard) Date: Sat, 26 Nov 2016 14:59:44 +0000 Subject: [issue26483] docs unclear on difference between str.isdigit() and str.isdecimal() In-Reply-To: <1457121897.81.0.495681677897.issue26483@psf.upfronthosting.co.za> Message-ID: <1480172384.5.0.423475699582.issue26483@psf.upfronthosting.co.za> Julien Palard added the comment: Proposing a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file45653/issue26483.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 10:06:44 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 26 Nov 2016 15:06:44 +0000 Subject: [issue28805] Add documentation for METH_FASTCALL In-Reply-To: Message-ID: STINNER Victor added the comment: Is it possible to use Argument Clinic for third party extensions? If yes, I suggest to use it. It would also be nice if Cython could use it automatically. So we can suggest to use Cython. I don't know well Cython, maybe your idea is very dumb :-) Serhiy Storchaka added the comment: > I suggest to keep it internal. It's meaning may be changed in future. I have some ideas about making it more convenient and faster (but I'm not sure that they would work). Ah? Can you please elaborate your secret plan? :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 10:06:44 2016 From: report at bugs.python.org (STINNER Victor) Date: Sat, 26 Nov 2016 15:06:44 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1480164739.39.0.909729178031.issue28754@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Argument Clinic adds a signature and a better docstring. So I like it! Speedup for tiny lists is just a nice side effect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 10:18:23 2016 From: report at bugs.python.org (Aviv Palivoda) Date: Sat, 26 Nov 2016 15:18:23 +0000 Subject: [issue8145] Documentation about sqlite3 isolation_level In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za> Message-ID: <1480173503.23.0.913008935088.issue8145@psf.upfronthosting.co.za> Changes by Aviv Palivoda : ---------- nosy: +palaviv _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 10:38:32 2016 From: report at bugs.python.org (John Helour) Date: Sat, 26 Nov 2016 15:38:32 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1480174712.64.0.931527826522.issue24339@psf.upfronthosting.co.za> Changes by John Helour : Removed file: http://bugs.python.org/file45647/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 10:41:43 2016 From: report at bugs.python.org (John Helour) Date: Sat, 26 Nov 2016 15:41:43 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1480174903.94.0.51612577793.issue24339@psf.upfronthosting.co.za> John Helour added the comment: If I take the ISO_6937 file as a template for encoding table then increasing the range 0x20..0x7f to 0x00..0xA0 is the simplest solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 10:43:31 2016 From: report at bugs.python.org (John Helour) Date: Sat, 26 Nov 2016 15:43:31 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1480175011.15.0.944219717535.issue24339@psf.upfronthosting.co.za> John Helour added the comment: If I take the ISO_6937 file as a template for encoding table then increasing the range 0x20..0x7f to 0x00..0xA0 is the simplest solution. ---------- Added file: http://bugs.python.org/file45654/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 10:47:39 2016 From: report at bugs.python.org (Steve Dower) Date: Sat, 26 Nov 2016 15:47:39 +0000 Subject: [issue28758] UnicodeDecodeError: 'gbk' codec can't decode byte 0xab in position 74: illegal multibyte sequence In-Reply-To: <1479705448.56.0.0763380057233.issue28758@psf.upfronthosting.co.za> Message-ID: <1480175259.17.0.859011521528.issue28758@psf.upfronthosting.co.za> Steve Dower added the comment: Unless the reporter comes back with more information, I'll assume it's not a bug. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 10:48:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Nov 2016 15:48:34 +0000 Subject: [issue28808] Make PyUnicode_CompareWithASCIIString() never failing Message-ID: <1480175314.71.0.35688135657.issue28808@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: PyUnicode_CompareWithASCIIString() never set an exception in 3.2 and earlier versions. Since 3.3 it sets an exception and returns -1 if the first argument is not ready Unicode object, but this was not documented until issue28701. Due to undocumenting this behavior many (if not all) callers don't check whether it returned an error. Proposed patch restores old behavior of PyUnicode_CompareWithASCIIString(). ---------- components: Interpreter Core, Unicode files: PyUnicode_CompareWithASCIIString-no-errors.patch keywords: patch messages: 281783 nosy: ezio.melotti, haypo, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Make PyUnicode_CompareWithASCIIString() never failing type: behavior versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45655/PyUnicode_CompareWithASCIIString-no-errors.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 11:05:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Nov 2016 16:05:20 +0000 Subject: [issue28808] Make PyUnicode_CompareWithASCIIString() never failing In-Reply-To: <1480175314.71.0.35688135657.issue28808@psf.upfronthosting.co.za> Message-ID: <1480176320.33.0.870133895351.issue28808@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file45655/PyUnicode_CompareWithASCIIString-no-errors.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 11:06:06 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Nov 2016 16:06:06 +0000 Subject: [issue28808] Make PyUnicode_CompareWithASCIIString() never failing In-Reply-To: <1480175314.71.0.35688135657.issue28808@psf.upfronthosting.co.za> Message-ID: <1480176366.08.0.261565878322.issue28808@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file45656/PyUnicode_CompareWithASCIIString-no-errors.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 12:32:49 2016 From: report at bugs.python.org (Stefan Krah) Date: Sat, 26 Nov 2016 17:32:49 +0000 Subject: [issue28805] Add documentation for METH_FASTCALL In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za> Message-ID: <1480181569.7.0.966069831242.issue28805@psf.upfronthosting.co.za> Stefan Krah added the comment: There are a couple of problems with using Argument Clinic for third party projects. First, it makes no stability promises: "Currently Argument Clinic is considered internal-only for CPython. ..." Then, for large projects that already use some generated code (like NumPy), IMO the result would be unmaintainable. So it would be nice to have a public stable API -- of course there is no hurry if Serhiy has plans to improve it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 12:43:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Nov 2016 17:43:54 +0000 Subject: [issue28805] Add documentation for METH_FASTCALL In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za> Message-ID: <1480182233.99.0.782201008628.issue28805@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Ah? Can you please elaborate your secret plan? :-) I already said about this. Move the part of parsing keyword argument outside of the function. The caller should unpack keyword arguments and pass just a raw array of PyObject*. Missed arguments are set to NULL. This could make _PyArg_ParseStack() simpler and might even allow to inline arguments parsing code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 12:47:46 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 26 Nov 2016 17:47:46 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1480148601.64.0.175988788288.issue28739@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: OK, clearly the code that sets __doc__ is too closely tied to the generated code (or to the reduced AST used to generate code). I still think code that uses any of these is on thin ice and should expect to be broken in the future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 13:05:22 2016 From: report at bugs.python.org (Soren Solari) Date: Sat, 26 Nov 2016 18:05:22 +0000 Subject: [issue28809] mention asyncio.gather non-deterministic task starting order Message-ID: <1480183522.09.0.687431688906.issue28809@psf.upfronthosting.co.za> New submission from Soren Solari: https://github.com/python/asyncio/issues/432 asyncio.gather documentation states: "the returned future?s result is the list of results (in the order of the original sequence, not necessarily the order of results arrival)" An additional statement like "tasks are not guaranteed to be started in a predicable order" would aid users and slove the discussion in issue 432 above. ---------- assignee: docs at python components: Documentation messages: 281787 nosy: Soren Solari, docs at python priority: normal severity: normal status: open title: mention asyncio.gather non-deterministic task starting order type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 13:24:04 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Nov 2016 18:24:04 +0000 Subject: [issue28810] Document bytecode changes in 3.6 Message-ID: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: There are many bytecode changes in 3.6, but seems most of them are not documented (besides short line in _bootstrap_external.py). * The bytecode now uses 16 bit units (wordcode) (issue26647). * Added FORMAT_VALUE opcode (issue25483). * Added BUILD_CONST_KEY_MAP opcode (issue27140). * Added BUILD_STRING opcode (issue27078). * Added BUILD_TUPLE_UNPACK_WITH_CALL opcode (issue28257). * Added SETUP_ANNOTATIONS and STORE_ANNOTATION opcodes (issue27985). * Changed CALL_FUNCTION, CALL_FUNCTION_KW and BUILD_MAP_UNPACK_WITH_CALL opcodes, removed CALL_FUNCTION_VAR, CALL_FUNCTION_VAR_KW opcodes, added CALL_FUNCTION_EX opcode (issue27213). * Changed MAKE_FUNCTION opcode, removed MAKE_CLOSURE opcode (issue27095). * Not related to the bytecode itself: lineno delta of code.co_lnotab now is signed (issue26107). There are third-party projects that need correct information about bytecode changes. ---------- assignee: docs at python components: Documentation messages: 281788 nosy: docs at python, serhiy.storchaka priority: high severity: normal stage: needs patch status: open title: Document bytecode changes in 3.6 type: enhancement versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 13:26:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Nov 2016 18:26:24 +0000 Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za> Message-ID: <1480184784.83.0.572193327815.issue26647@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I left this issue open for documenting the wordcode. Now opened separate issue28810 for this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 13:27:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Nov 2016 18:27:52 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1480184872.91.0.417710499176.issue28635@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Please take a look at issue28810. Most bytecode changes are not documented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 14:00:04 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 26 Nov 2016 19:00:04 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480186804.57.0.240227274652.issue28754@psf.upfronthosting.co.za> Raymond Hettinger added the comment: [SS] > This is rather a random difference. Try to run the bench several times. I did run several times. The results were perfectly stable (+/- 1ns). It tells us that METH_FASTCALL is something we want to use as broadly as possible. [JP] > it yielded a consistent 18% improvement on bisect.bisect("abcdef", "c") > on two different machines. Thanks for running timings. When you do timing in the future, try to select timings that are indicative of actual use. No one uses bisect to search strings for a character -- the typical use case is searching a list of range breakpoints like the example shown in the docs: def grade(score, breakpoints=[60, 70, 80, 90], grades='FDCBA'): i = bisect(breakpoints, score) return grades[i] Hash tables are faster for exact lookup. Bisect is mainly used for searching ranges (i.e. tax brackets or position in a cumulative distribution). [VS] > Speedup for tiny lists is just a nice side effect. To you perhaps; however, the entire reason I put this code in many years ago was for performance. The existing pure python code was already very fast. Anyway, this patch is a nice improvement in that regard. [Everyone] What to do about the "hi" argument is a sticky point. This is a long-standing API, so any API changes would likely break some code or lock us into exposing unintuitive implementation details (like hi=-1). The point of view of the existing C code, the pure Python version, and the docs is that the "hi" argument is an optional argument that when omitted will default to "len(a)". It was not intended that a user would explicitly pass in "hi=None" as allowed by the pure python version but not by the C version, nor was it intended to have the user pass in "hi=-1" as allowed by the C version but causes incorrect behavior on the pure Python version. It is unfortunate that the argument clinic has not yet grown support for the concept of "there is special meaning for an omitted argument that cannot be simulated by passing in a particular default value". I believe when this issue has arisen elsewhere, the decision was to skip applying argument clinic at all. See: builtin_getattr, builtin_next, dict_pop, etc. In this case though, we already have a conflict, so it may be possible to resolve the issue through clear parameter descriptions, indicating that "hi=-1" and "hi=None" are implementation details and that it is intended that the user never explicitly pass in either of those values, and that only the guaranteed ways to get the default is to omit the argument entirely or to pass in "hi=len(a)" as a numeric argument. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 14:18:14 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Nov 2016 19:18:14 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480187894.47.0.499497782762.issue28754@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I would suggest to use sys.maxsize for default value in Argument Clinic, but right now bisect functions don't support well hi > len(a). This needs adding an equivalent of hi = min(hi, len(a)) in C code. -1 could be explicitly supported for backward compatibility. But it could be deprecated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 14:30:54 2016 From: report at bugs.python.org (Ned Deily) Date: Sat, 26 Nov 2016 19:30:54 +0000 Subject: [issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition In-Reply-To: <1471355745.98.0.805545529346.issue27777@psf.upfronthosting.co.za> Message-ID: <1480188654.79.0.49349254046.issue27777@psf.upfronthosting.co.za> Ned Deily added the comment: Berker asks in IRC whether this change should go into 3.6.0 (at rc1). While it is affecting a relatively self-contained part of the standard library (cgi), the issue doesn't seem to be "release critical". Further, it is changing behavior that was changed barely a year ago for Issue24764. My preference would be to try to have this change reviewed and/or tested by at least some of the people involved with the earlier issue and, if there is a consensus for it, target the change for 3.6.1. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 14:44:39 2016 From: report at bugs.python.org (Bert JW Regeer) Date: Sat, 26 Nov 2016 19:44:39 +0000 Subject: [issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition In-Reply-To: <1471355745.98.0.805545529346.issue27777@psf.upfronthosting.co.za> Message-ID: <1480189479.75.0.518919950055.issue27777@psf.upfronthosting.co.za> Bert JW Regeer added the comment: Unfortunately I need to spin another patch, the one I created didn't solve the issue for one of WebOb's users: https://github.com/Pylons/webob/pull/300 (Thanks Julien Meyer!) I have his permission to grab his test/patch and update this patch, I will get this done later today. That being said, this is a real issue, and WebOb will be shipping a fix for Python less than 3.6 anyway, so whether this gets released in 3.6 or not doesn't matter to me. I'd prefer this to be fixed in the standard library for all users, rather than just for WebOb users. Even if this were released for 3.6.1, WebOb will have to carry the fix for the foreseeable future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 14:48:14 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sat, 26 Nov 2016 19:48:14 +0000 Subject: [issue28810] Document bytecode changes in 3.6 In-Reply-To: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za> Message-ID: <1480189694.51.0.568222612534.issue28810@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: SETUP_ANNOTATIONS and STORE_ANNOTATION opcodes are documented in documentation for dis module. Should they be documented also somewhere else? ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 15:10:11 2016 From: report at bugs.python.org (Elvis Pranskevichus) Date: Sat, 26 Nov 2016 20:10:11 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1480191011.42.0.495231489933.issue28635@psf.upfronthosting.co.za> Elvis Pranskevichus added the comment: Here's a patch to add opcode changes to the What's New document. Thanks for pointing this out Serhiy. ---------- Added file: http://bugs.python.org/file45657/0001-Issue-28635-Document-Python-3.6-opcode-changes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 15:25:44 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Nov 2016 20:25:44 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <1480191944.39.0.614542998073.issue28635@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. Thanks Elvis! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 15:29:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Nov 2016 20:29:35 +0000 Subject: [issue28810] Document bytecode changes in 3.6 In-Reply-To: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za> Message-ID: <1480192175.45.0.368023443153.issue28810@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think only the mention in What's News is needed. Elvis already provided a patch in issue28635. But the documentation of other opcodes may be missed or outdated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 15:33:54 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 26 Nov 2016 20:33:54 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za> Message-ID: <1480192434.32.0.286892010005.issue28739@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I withdraw my previously suggested addition to the Docstring glossary entry (msg281740). It implies that trivial f-strings are acceptable and I agree that other implementations and future Cpython should be free to strictly follow the literal meaning of the first sentence: docstring = initial string literal expression. I suggest instead that 'string literal' in the first sentence link to https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals. This would make it clearer that 'string literal' is being used the the Python technical sense rather than in any more informal English sense. We could possibly add a version of what Guido said above, such as: "(Acceptance of anything other than a string literal as a docstring is an implementation accident and should not be relied upon.)" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 15:46:26 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Nov 2016 20:46:26 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za> Message-ID: <1480193186.05.0.8066187955.issue28739@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch makes f-strings not be accepted as docstrings. It also disallow f-strings in ast.literal_eval(). ---------- keywords: +patch Added file: http://bugs.python.org/file45658/fstring-no-docstring.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 16:00:10 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 26 Nov 2016 21:00:10 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1480193186.05.0.8066187955.issue28739@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I think such a patch is fine -- for 3.6.1. Also note that linking to the definition of "string literal" is insufficient, assuming we will want to continue supporting literal concatenation ( https://docs.python.org/3/reference/lexical_analysis.html#string-literal-concatenation). (And I want to, because I can see a use case.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 17:05:47 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 26 Nov 2016 22:05:47 +0000 Subject: [issue24142] ConfigParser._read doesn't join multi-line values collected while reading if a ParsingError occured In-Reply-To: <1431014086.96.0.315028213592.issue24142@psf.upfronthosting.co.za> Message-ID: <20161126220544.77859.81289.68E69677@psf.io> Roundup Robot added the comment: New changeset 40567b8e3478 by ?ukasz Langa in branch '3.5': Fixes #24142: [configparser] always join multiline values to not leave the parser in an invalid state https://hg.python.org/cpython/rev/40567b8e3478 New changeset 306cfb866399 by ?ukasz Langa in branch '3.6': Merge 3.5, fix for #24142 https://hg.python.org/cpython/rev/306cfb866399 New changeset 876bee0bd0ba by ?ukasz Langa in branch 'default': Merge 3.6, fix for #24142 https://hg.python.org/cpython/rev/876bee0bd0ba ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 17:06:53 2016 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Sat, 26 Nov 2016 22:06:53 +0000 Subject: [issue24142] ConfigParser._read doesn't join multi-line values collected while reading if a ParsingError occured In-Reply-To: <1431014086.96.0.315028213592.issue24142@psf.upfronthosting.co.za> Message-ID: <1480198013.11.0.298646925254.issue24142@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Thanks for your patch! As you can see, 2.7 is no longer touched as the codebases diverged. I'll release a 3.6 backport on PyPI sometime this weekend that you can use. ---------- resolution: -> fixed status: open -> closed versions: +Python 3.5, Python 3.6, Python 3.7 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 18:27:00 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 26 Nov 2016 23:27:00 +0000 Subject: [issue24142] ConfigParser._read doesn't join multi-line values collected while reading if a ParsingError occured In-Reply-To: <1431014086.96.0.315028213592.issue24142@psf.upfronthosting.co.za> Message-ID: <1480202820.2.0.620645670495.issue24142@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is this release critical for 3.6.0? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 19:18:41 2016 From: report at bugs.python.org (Thomas Waldmann) Date: Sun, 27 Nov 2016 00:18:41 +0000 Subject: [issue28494] is_zipfile false positives In-Reply-To: <1476997729.0.0.643464084789.issue28494@psf.upfronthosting.co.za> Message-ID: <1480205921.05.0.975617779682.issue28494@psf.upfronthosting.co.za> Thomas Waldmann added the comment: Well, if you have a better idea how to fix is_zipfile, go on. I even suggested an alternative, how about that? It is a miserable state when the is_zipfile function in the stdlib detects random crap as a zip file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 19:55:21 2016 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 27 Nov 2016 00:55:21 +0000 Subject: [issue28804] file tell() report incorrect file position on Windows (but Linux is OK) In-Reply-To: <1480132809.99.0.636633604449.issue28804@psf.upfronthosting.co.za> Message-ID: <1480208121.85.0.0967685105015.issue28804@psf.upfronthosting.co.za> Eric V. Smith added the comment: Yes, it's a duplicate. The only valid operation on the value of calling tell() from a text-mode file is to pass it to seek(). As long as that works, there's no bug here. ---------- nosy: +eric.smith resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> io.TextIOWrapper.tell() report 65bit number when mix readline() + tell() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 20:16:23 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 27 Nov 2016 01:16:23 +0000 Subject: [issue28775] Option to set startup directory in IDLE In-Reply-To: <1479837252.01.0.0581172301847.issue28775@psf.upfronthosting.co.za> Message-ID: <1480209383.09.0.59661579787.issue28775@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Raymond: yes, I am definitely open to collaboration on this issue. The timing is good as I just started, a month ago, expanding configure dialog testing beyond the trivial one of creating an instance without raising. Real tests are needed preparation for making other changes, including adding other new options in 3.6+. I would like to include this one in 3.6.1, 4 to 6 months from now. Doing so may require more information about IDLE on *nix and Mac than I currently have. Which of those have you run IDLE on? Or helped people with in your classes? Nofar: welcome. I have two immediate questions. 1) Which OS do you primarily work with? (I am using Win 10.) Can you test on anything else? 2) Are you only interested in this issue, or might you be open to working on other issues if this one is successful? Idlelib is not an easy codebase to get into. The +-60 modules are listed in README.txt. There is also a mapping from menu items to implementation code. However, the README does not cover the addition of a new option. I will write and upload a design document or roadmap for this one. ---------- stage: -> test needed type: -> enhancement versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 20:22:47 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 27 Nov 2016 01:22:47 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za> Message-ID: <1480209767.02.0.50424938027.issue28739@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I considered concatenated string literals to be included in 'string literal'. If that is not obvious, then it should be made so. Replace 'string literal' with 'string literal or concatenated strings literals' and link each part to their respective (and successive) sections. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 26 22:18:10 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 27 Nov 2016 03:18:10 +0000 Subject: [issue24142] ConfigParser._read doesn't join multi-line values collected while reading if a ParsingError occured In-Reply-To: <1431014086.96.0.315028213592.issue24142@psf.upfronthosting.co.za> Message-ID: <1480216690.36.0.477785118398.issue24142@psf.upfronthosting.co.za> Ned Deily added the comment: After discussing this offline with ?ukasz, I'm going to take the risk of allowing the non-conforming 3.6 checkin to remain in for 3.6.0. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 00:19:38 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 27 Nov 2016 05:19:38 +0000 Subject: [issue28739] PEP 498: docstrings as f-strings In-Reply-To: <1480209767.02.0.50424938027.issue28739@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I was just noticing that the formal grammar in the reference manual first defines a single string literal and then separately describes concatenation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 02:38:24 2016 From: report at bugs.python.org (INADA Naoki) Date: Sun, 27 Nov 2016 07:38:24 +0000 Subject: [issue28673] pyro4 with more than 15 threads often crashes 2.7.12 In-Reply-To: <1478939498.33.0.0967391900201.issue28673@psf.upfronthosting.co.za> Message-ID: <1480232304.09.0.156314007892.issue28673@psf.upfronthosting.co.za> INADA Naoki added the comment: > Where *exactly*? See attached patch. But python with this patch can deadlock in other state. Main thread wait GIL but no other living threads have GIL. It seems caused by other issue around finalization and multithreading. > Py_FinalizeEx() first calls wait_for_thread_shutdown() and *then* sets _Py_Finalizing to tstate. > Does wait_for_thread_shutdown() complete on this bug? Yes. wait_for_thread_shutdown() waits only daemon threads. After _Py_Finalizing = tstate, main thread calls many __del__ methods while shutdown. If one of them starts new thread, this deadlock happens. ---------- keywords: +patch Added file: http://bugs.python.org/file45659/28673-fix-deadlock.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 04:33:13 2016 From: report at bugs.python.org (Ram Rachum) Date: Sun, 27 Nov 2016 09:33:13 +0000 Subject: [issue28811] Make pathlib.PurePath.__str__ use shlex.quote Message-ID: <1480239193.34.0.752695388399.issue28811@psf.upfronthosting.co.za> New submission from Ram Rachum: I have a a PurePath object like so: path = PurePath('/home/my awesome user/file.txt') I'm SSHing into a server and I want to remove the file. So I have to do this: ssh_client.run(f'/bin/rm {shlex.quote(str(path))}') Which is really long and ugly. (I might have been able to remove the str from there if #28623 wasn't rejected.) I wish I could do this: ssh_client.run(f'/bin/rm {path}') But since my path has a space, that would only be possible if PurePath.__str__ were to use shlex.quote, and put quotes around my path (only if it includes a space). What do you think about that? ---------- components: Library (Lib) messages: 281812 nosy: cool-RR, pitrou priority: normal severity: normal status: open title: Make pathlib.PurePath.__str__ use shlex.quote type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 04:44:46 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Nov 2016 09:44:46 +0000 Subject: [issue27647] Update Windows build to Tcl/Tk 8.6.6 In-Reply-To: <1469737194.88.0.144648917966.issue27647@psf.upfronthosting.co.za> Message-ID: <1480239886.49.0.269165645746.issue27647@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Larry, Benjamin, what do you think about updating the version of Tcl/Tk shipped with 3.5 and 2.7 on Windows? Tcl/Tk 8.6.6 Jul 27, 2016 Tcl/Tk 8.5.19 Feb 12, 2016 Currently used releases: In 3.5: 8.6.4.2 In 2.7: 8.5.15.0 ---------- nosy: +benjamin.peterson, larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 05:09:11 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Nov 2016 10:09:11 +0000 Subject: [issue28811] Make pathlib.PurePath.__str__ use shlex.quote In-Reply-To: <1480239193.34.0.752695388399.issue28811@psf.upfronthosting.co.za> Message-ID: <1480241351.54.0.390463132153.issue28811@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This will break any code that pass str(path) to API that doesn't support pathlib. In your case you can introduce a short alias: q = shlex.quote ssh_client.run(f'/bin/rm {q(str(path))}') Or add more convenient helper: def q(path): return shlex.quote(str(path)) ssh_client.run(f'/bin/rm {q(path)}') ---------- nosy: +serhiy.storchaka resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 05:11:28 2016 From: report at bugs.python.org (Ram Rachum) Date: Sun, 27 Nov 2016 10:11:28 +0000 Subject: [issue28811] Make pathlib.PurePath.__str__ use shlex.quote In-Reply-To: <1480239193.34.0.752695388399.issue28811@psf.upfronthosting.co.za> Message-ID: <1480241488.21.0.277889474935.issue28811@psf.upfronthosting.co.za> Ram Rachum added the comment: "This will break any code that pass str(path) to API that doesn't support pathlib." I don't understand. Can you give a concrete example of code it would break? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 05:13:18 2016 From: report at bugs.python.org (INADA Naoki) Date: Sun, 27 Nov 2016 10:13:18 +0000 Subject: [issue28812] Deadlock between GIL and pystate head_mutex. Message-ID: <1480241598.29.0.901358230906.issue28812@psf.upfronthosting.co.za> New submission from INADA Naoki: While investigating #28673, I found another deadlock relating to finalization and threading. deadlocked thread (holding gil / waiting head_mutex): #0 0x00007f35dd400a07 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x5557e6d3eeb0) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 #1 do_futex_wait (sem=sem at entry=0x5557e6d3eeb0, abstime=0x0) at sem_waitcommon.c:111 #2 0x00007f35dd400ab4 in __new_sem_wait_slow (sem=0x5557e6d3eeb0, abstime=0x0) at sem_waitcommon.c:181 #3 0x00007f35dd400b5a in __new_sem_wait (sem=sem at entry=0x5557e6d3eeb0) at sem_wait.c:29 #4 0x00005557e64ec01b in PyThread_acquire_lock_timed (lock=0x5557e6d3eeb0, microseconds=-1, intr_flag=intr_flag at entry=0) at Python/thread_pthread.h:352 #5 0x00005557e64ec148 in PyThread_acquire_lock (lock=, waitflag=waitflag at entry=1) at Python/thread_pthread.h:556 #6 0x00005557e64d8dbb in tstate_delete_common (tstate=tstate at entry=0x7f35cc002a80) at Python/pystate.c:426 #7 0x00005557e64d9e8d in PyThreadState_DeleteCurrent () at Python/pystate.c:462 #8 0x00005557e662d339 in t_bootstrap (boot_raw=0x7f35dc186628) at ./Modules/_threadmodule.c:1027 #9 0x00007f35dd3f870a in start_thread (arg=0x7f35c3fff700) at pthread_create.c:333 #10 0x00007f35dca220af in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 main thread (waiting gil / holding head_mutex): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225 #1 0x00005557e65f1758 in PyCOND_TIMEDWAIT (us=5000, mut=0x5557e69cc860 , cond=0x5557e69cc8a0 ) at Python/condvar.h:103 #2 take_gil (tstate=tstate at entry=0x5557e6d3f840) at Python/ceval_gil.h:224 #3 0x00005557e65f3b14 in _PyEval_EvalFrameDefault (f=Frame 0x7f35d0001878, for file finish-deadlock.py, line 7, in __del__ (self=), throwflag=) at Python/ceval.c:1140 #4 0x00005557e65f1dcf in PyEval_EvalFrameEx (f=f at entry=Frame 0x7f35d0001878, for file finish-deadlock.py, line 7, in __del__ (self=), throwflag=throwflag at entry=0) at Python/ceval.c:718 #5 0x00005557e65f1eab in _PyFunction_FastCall (co=co at entry=0x7f35dc50eac0, args=0x7fff1a1e2878, args at entry=0x7fff1a1e2870, nargs=nargs at entry=1, globals=globals at entry={'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': , '__spec__': None, '__annotations__': {}, '__builtins__': , '__cached__': None, 'sys': , 'time': , 'threading': , 'C': , 'worker': , '_': 4, 't': , _name='Thread-11', _args=(), _kwargs={}, _daemonic=True, _ident=139869249451776, _tstate_lock=<_thread.lock at remote 0x7f35dc4739e0>, _started=, acquire=, release=, _waiters=) at remote 0x7f35dc191538>,...(truncated)) at Python/ceval.c:4881 #6 0x00005557e65feb04 in _PyFunction_FastCallDict (func=func at entry=, args=args at entry=0x7fff1a1e2870, nargs=nargs at entry=1, kwargs=kwargs at entry=0x0) at Python/ceval.c:4983 #7 0x00005557e6500386 in _PyObject_FastCallDict (func=func at entry=, args=args at entry=0x7fff1a1e2870, nargs=nargs at entry=1, kwargs=kwargs at entry=0x0) at Objects/abstract.c:2301 #8 0x00005557e6500644 in _PyObject_Call_Prepend (func=, obj=obj at entry=, args=args at entry=(), kwargs=kwargs at entry=0x0) at Objects/abstract.c:2364 #9 0x00005557e651c2e4 in method_call (method=method at entry=, args=args at entry=(), kwargs=kwargs at entry=0x0) at Objects/classobject.c:317 #10 0x00005557e6500247 in _PyObject_FastCallDict (func=func at entry=, args=args at entry=0x0, nargs=nargs at entry=0, kwargs=kwargs at entry=0x0) at Objects/abstract.c:2322 #11 0x00005557e65f34a2 in PyEval_CallObjectWithKeywords (func=func at entry=, args=args at entry=0x0, kwargs=kwargs at entry=0x0) at Python/ceval.c:4705 #12 0x00005557e6577f0d in slot_tp_finalize (self=) at Objects/typeobject.c:6416 #13 0x00005557e655a07c in PyObject_CallFinalizer (self=self at entry=) at Objects/object.c:297 #14 0x00005557e655adb7 in PyObject_CallFinalizerFromDealloc (self=self at entry=) at Objects/object.c:314 #15 0x00005557e656cfde in subtype_dealloc (self=self at entry=) at Objects/typeobject.c:1151 #16 0x00005557e655ae75 in _Py_Dealloc (op=) at Objects/object.c:1786 #17 0x00005557e65312c5 in frame_dealloc (f=f at entry=Frame 0x7f35c40026a8, for file finish-deadlock.py, line 22, in worker ()) at Objects/frameobject.c:423 #18 0x00005557e655ae75 in _Py_Dealloc (op=Frame 0x7f35c40026a8, for file finish-deadlock.py, line 22, in worker ()) at Objects/object.c:1786 #19 0x00005557e64e88c1 in tb_dealloc (tb=tb at entry=0x7f35dc193f38) at Python/traceback.c:55 #20 0x00005557e655ae75 in _Py_Dealloc (op=) at Objects/object.c:1786 #21 0x00005557e64d98f3 in PyThreadState_Clear (tstate=tstate at entry=0x5557e6e307f0) at Python/pystate.c:403 #22 0x00005557e64d99cf in PyInterpreterState_Clear (interp=interp at entry=0x5557e6d3f390) at Python/pystate.c:119 #23 0x00005557e64d7b0f in Py_FinalizeEx () at Python/pylifecycle.c:672 #24 0x00005557e64eed2f in Py_Main (argc=2, argv=0x5557e6d3e010) at Modules/main.c:800 #25 0x00005557e64d3ad5 in main (argc=2, argv=0x7fff1a1e2d78) at ./Programs/python.c:69 ---------- components: Interpreter Core files: finish-deadlock.py messages: 281816 nosy: inada.naoki priority: normal severity: normal status: open title: Deadlock between GIL and pystate head_mutex. versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45660/finish-deadlock.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 05:29:35 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Nov 2016 10:29:35 +0000 Subject: [issue28494] is_zipfile false positives In-Reply-To: <1476997729.0.0.643464084789.issue28494@psf.upfronthosting.co.za> Message-ID: <1480242575.86.0.314296144584.issue28494@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No, checking the first bytes of the file is not appropriate option. zipfile should support the Python zip application format [1]. I see two options: 1. Make is_zipfile() more strict that the ZipFile constructor. The later supports ZIP files with a data past the comment or with truncated comments, but the former should reject them. 2. Make both is_zipfile() and the ZipFile constructor more robust. They should check not just the EOCD signature, but check the Zip64 end of central directory record (if exists) and the first central file header signature (if the ZIP file is not empty). It may be that PDF files contain PK\005\006 not accidentally, but because they contain embedded ZIP files (I don't know if this is a case). In that circumstances is_zipfile() returning True is correct. [1] https://docs.python.org/3/library/zipapp.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 05:31:01 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Nov 2016 10:31:01 +0000 Subject: [issue28811] Make pathlib.PurePath.__str__ use shlex.quote In-Reply-To: <1480239193.34.0.752695388399.issue28811@psf.upfronthosting.co.za> Message-ID: <1480242661.8.0.282170087208.issue28811@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: open(str(path)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 06:00:28 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Nov 2016 11:00:28 +0000 Subject: [issue28682] Bytes support in os.fwalk() In-Reply-To: <1479029050.5.0.426622691368.issue28682@psf.upfronthosting.co.za> Message-ID: <1480244428.53.0.432110246719.issue28682@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Bytes path support is os.walk() is not documented. Actual behavior of os.fwalk() doesn't contradict the documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 06:05:47 2016 From: report at bugs.python.org (Adrian Wielgosik) Date: Sun, 27 Nov 2016 11:05:47 +0000 Subject: [issue28813] Remove unneeded folded consts after peephole Message-ID: <1480244746.98.0.558504847162.issue28813@psf.upfronthosting.co.za> New submission from Adrian Wielgosik: The attached patch adds new logic to peephole compiler to remove constants that are no longer needed after the main peephole pass. For example: def f(): var = 'te' + 'xt' num = -12 num = -6 * 2 return (1, (3, 4), 6) print(f.__code__.co_consts) Without the patch: (None, 'te', 'xt', 12, 6, 2, 1, 3, 4, 'text', -12, -6, -12, (3, 4), (1, (3, 4), 6)) With patch: (None, 'text', -12, -12, (1, (3, 4), 6)) (unfortunately, I couldn't get rid of None because that would make 'text' a docstring) For convenience, I've written the patch in two parts. The first one just changes the CONST_STACK_* macros to store the co_const indices instead of the constants themselves, the second one is the actual implementation of the new logic. Aside from simply having to store less objects around, this also makes co_consts contents closer together. This may help the cache a little bit. --------- I did run benchmarks multiple times, but it looked like all the results were random noise. That makes sense, since I didn't directly affect the runtime. The only consistently faster benchmark is: - regex_dna: 288 ms +- 7 ms -> 275 ms +- 5 ms: 1.05x faster I tried to measure the difference in compile time, but it too was lost in the noise. --------- I also compared size of compiled .pyc files in the Lib/ directory. The gains are mostly very small. _compat_pickle.cpython-37.pyc | 6554 -> 5851 | -10.7% sre_compile.cpython-37.pyc | 10275 -> 10025 | -2.43% hashlib.cpython-37.pyc | 6624 -> 6514 | -1.66% pstats.cpython-37.pyc | 21755 -> 21435 | -1.47% _markupbase.cpython-37.pyc | 7979 -> 7864 | -1.44% pydoc.cpython-37.pyc | 83899 -> 82712 | -1.41% _strptime.cpython-37.pyc | 15951 -> 15751 | -1.25% __future__.cpython-37.pyc | 4155 -> 4105 | -1.2% opcode.cpython-37.pyc | 5401 -> 5341 | -1.11% colorsys.cpython-37.pyc | 3299 -> 3263 | -1.09% signal.cpython-37.pyc | 2503 -> 2478 | -0.999% _osx_support.cpython-37.pyc | 9663 -> 9568 | -0.983% gettext.cpython-37.pyc | 13990 -> 13854 | -0.972% getpass.cpython-37.pyc | 4223 -> 4183 | -0.947% compare.cpython-37.pyc | 541 -> 536 | -0.924% warnings.cpython-37.pyc | 13328 -> 13208 | -0.9% platform.cpython-37.pyc | 27931 -> 27681 | -0.895% imaplib.cpython-37.pyc | 42019 -> 41653 | -0.871% webbrowser.cpython-37.pyc | 15836 -> 15702 | -0.846% this.cpython-37.pyc | 1253 -> 1243 | -0.798% rlcompleter.cpython-37.pyc | 5768 -> 5723 | -0.78% zipfile.cpython-37.pyc | 48024 -> 47672 | -0.733% imghdr.cpython-37.pyc | 4138 -> 4108 | -0.725% turtle.cpython-37.pyc | 131600 -> 130653 | -0.72% timeit.cpython-37.pyc | 11676 -> 11596 | -0.685% lzma.cpython-37.pyc | 11980 -> 11900 | -0.668% bz2.cpython-37.pyc | 11270 -> 11195 | -0.665% aifc.cpython-37.pyc | 25821 -> 25651 | -0.658% gzip.cpython-37.pyc | 16215 -> 16110 | -0.648% uuid.cpython-37.pyc | 20382 -> 20260 | -0.599% plistlib.cpython-37.pyc | 27354 -> 27191 | -0.596% cProfile.cpython-37.pyc | 4199 -> 4174 | -0.595% tarfile.cpython-37.pyc | 62437 -> 62076 | -0.578% sysconfig.cpython-37.pyc | 15819 -> 15728 | -0.575% profile.cpython-37.pyc | 13889 -> 13814 | -0.54% random.cpython-37.pyc | 19177 -> 19074 | -0.537% _threading_local.cpython-37.pyc | 6609 -> 6574 | -0.53% _dummy_thread.cpython-37.pyc | 4839 -> 4814 | -0.517% datetime.cpython-37.pyc | 53722 -> 53445 | -0.516% tracemalloc.cpython-37.pyc | 17218 -> 17131 | -0.505% // remaining 129 files are < 0.5% smaller, 33 of them didn't change their size ---------- components: Interpreter Core messages: 281820 nosy: Adrian Wielgosik priority: normal severity: normal status: open title: Remove unneeded folded consts after peephole type: resource usage versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 06:06:08 2016 From: report at bugs.python.org (Adrian Wielgosik) Date: Sun, 27 Nov 2016 11:06:08 +0000 Subject: [issue28813] Remove unneeded folded consts after peephole In-Reply-To: <1480244746.98.0.558504847162.issue28813@psf.upfronthosting.co.za> Message-ID: <1480244768.89.0.0831226939378.issue28813@psf.upfronthosting.co.za> Changes by Adrian Wielgosik : ---------- keywords: +patch Added file: http://bugs.python.org/file45661/indices_tweak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 06:07:26 2016 From: report at bugs.python.org (Adrian Wielgosik) Date: Sun, 27 Nov 2016 11:07:26 +0000 Subject: [issue28813] Remove unneeded folded consts after peephole In-Reply-To: <1480244746.98.0.558504847162.issue28813@psf.upfronthosting.co.za> Message-ID: <1480244846.29.0.541278700866.issue28813@psf.upfronthosting.co.za> Changes by Adrian Wielgosik : Added file: http://bugs.python.org/file45662/clean_co_consts.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 06:15:21 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Nov 2016 11:15:21 +0000 Subject: [issue28800] Add RETURN_NONE bytecode instruction In-Reply-To: <1480071315.87.0.448012344283.issue28800@psf.upfronthosting.co.za> Message-ID: <1480245321.87.0.427964123665.issue28800@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The pair LOAD_CONST/RETURN_VALUE is on 19th place of the top of opcode pairs (see msg269391 in issue27255). Not all of these constants are None. And since the time of LOAD_CONST is much smaller then the time of RETURN_VALUE (the latter includes destroying a frame and should be in a pair with CALL_FUNCTION), I think the performance effect of RETURN_NONE is much less than 1%. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 06:59:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 27 Nov 2016 11:59:24 +0000 Subject: [issue28813] Remove unneeded folded consts after peephole In-Reply-To: <1480244746.98.0.558504847162.issue28813@psf.upfronthosting.co.za> Message-ID: <1480247964.37.0.539688784015.issue28813@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your patch Adrian. I haven't close look, but at first glance your patch looks correct, and the idea looks great. But moving constant folding from the peephole optimizer to the AST level (issue1346238, issue11549) would totally eliminate the need in your patch. I'll push your patch if AST optimizer will be not implemented in 3.7. On other hand, your patch looks simple enough, and my be pushed first. It would be easy to review if provide your changes as one patch. ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka priority: normal -> low stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 07:55:56 2016 From: report at bugs.python.org (Nofar Schnider) Date: Sun, 27 Nov 2016 12:55:56 +0000 Subject: [issue28775] Option to set startup directory in IDLE In-Reply-To: <1479837252.01.0.0581172301847.issue28775@psf.upfronthosting.co.za> Message-ID: <1480251356.39.0.183958628999.issue28775@psf.upfronthosting.co.za> Nofar Schnider added the comment: Thanks Terry. I am working on my Macbook Pro so my OS is macOS Sierra. Would love to test on it and also, I am able to test on several VMs with different Unix distributions. I am interested in anything that: 1) can help the Python community. 2) I could learn from. So the answer is YES. Just let me know where to start! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 08:07:32 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 27 Nov 2016 13:07:32 +0000 Subject: [issue28814] Deprecation notice on inspect.getargvalues() is incorrect Message-ID: <1480252052.94.0.16018093739.issue28814@psf.upfronthosting.co.za> New submission from Nick Coghlan: inspect.getargvalues() and inspect.formatargvalues() were deprecated in Python 3.5 as part of implementing issue 20438 This is incorrect, as these are *frame* introspection related functions, not callable introspection ones. The documentation and implementation layout is confusing though, as they're interleaved with the callable introspection operations. ---------- assignee: docs at python components: Documentation messages: 281824 nosy: docs at python, ncoghlan, yselivanov priority: normal severity: normal stage: needs patch status: open title: Deprecation notice on inspect.getargvalues() is incorrect type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 08:13:20 2016 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 27 Nov 2016 13:13:20 +0000 Subject: [issue27172] Undeprecate inspect.getfullargspec() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1480252400.54.0.572140549295.issue27172@psf.upfronthosting.co.za> Nick Coghlan added the comment: Initial patch attached. Key missing pieces: - needs a What's New note - needs to undeprecate inspect.getcallargs() as well (more on that below) As my last couple of comments indicate, I'd forgotten that only getargspec() was programmatically deprecated, which means the sole code change is a rewording of the getargspec() warning to mention both signature() and getfullargspec(). The documentation changes are a bit more extensive, as I couldn't resist fixing the longstanding terminology error in the docs and docstrings, where these functions are mostly reporting *parameter* names, not argument names (callable arguments have values, not names). I think the "versionchanged" note works well for indicating that folks aren't imagining things if they remembered seeing this function marked as deprecated. However, I also went back and checked the 3.5 What's New, and that does mention the deprecations, so I'll need to do another version of this patch that includes a 3.6 What's New notice retracting those deprecations. That check also reveals some other documented deprecations that should probably be reverted. Firstly, getargvalues() and formatargvalues() are *frame* introspection functions, and hence have nothing whatsoever to do with inspect.signature(). The code and docs are just a bit confusing as they're interleaved with the callable introspection functions. I've filed that as a new issue: http://bugs.python.org/issue28814 Secondly, https://bugs.python.org/issue20438#msg254892 notes that inspect.getcallargs() has some behaviours that differ from Signature.bind in a way that's a bit of a pain to replicate on top of the latter. Similar to getfullargspec(), what do folks think of the idea of reverting that deprecation at least until 2.7 goes EOL? (Noting for the record so folks don't wonder if it's an accidental oversight: I think formatargspec should retain its documented deprecation, as folks really are better off writing their own formatting function based on the data returned or switching to the new signature API) ---------- keywords: +patch Added file: http://bugs.python.org/file45663/issue27172_undeprecate_getfullargspec.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 08:13:30 2016 From: report at bugs.python.org (Adrian Wielgosik) Date: Sun, 27 Nov 2016 13:13:30 +0000 Subject: [issue28813] Remove unneeded folded consts after peephole In-Reply-To: <1480244746.98.0.558504847162.issue28813@psf.upfronthosting.co.za> Message-ID: <1480252410.36.0.369569211972.issue28813@psf.upfronthosting.co.za> Adrian Wielgosik added the comment: Attached squashed patch. > But moving constant folding from the peephole optimizer to the AST level (...) would totally eliminate the need in your patch. I'm aware of that and I'm okay with it. I chose an unfortunate moment for implementing this :) ---------- Added file: http://bugs.python.org/file45664/clean_co_consts_squashed.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 08:56:32 2016 From: report at bugs.python.org (Eric N. Vander Weele) Date: Sun, 27 Nov 2016 13:56:32 +0000 Subject: [issue19521] parallel build race condition on AIX since python-3.2 In-Reply-To: <1383840294.95.0.0890053719997.issue19521@psf.upfronthosting.co.za> Message-ID: <1480254992.52.0.467185417956.issue19521@psf.upfronthosting.co.za> Changes by Eric N. Vander Weele : ---------- nosy: +ericvw versions: +Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 09:26:10 2016 From: report at bugs.python.org (Eric N. Vander Weele) Date: Sun, 27 Nov 2016 14:26:10 +0000 Subject: [issue19521] Parallel build race condition on AIX since python-2.7 In-Reply-To: <1383840294.95.0.0890053719997.issue19521@psf.upfronthosting.co.za> Message-ID: <1480256770.57.0.181517898159.issue19521@psf.upfronthosting.co.za> Eric N. Vander Weele added the comment: I also have found this goes back since Python 2.7. I have refreshed the patched for the tip of CPython. What can I do to help push this forward? ---------- title: parallel build race condition on AIX since python-3.2 -> Parallel build race condition on AIX since python-2.7 Added file: http://bugs.python.org/file45665/aix-parallel-build-race-refresh.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 11:16:19 2016 From: report at bugs.python.org (patrila) Date: Sun, 27 Nov 2016 16:16:19 +0000 Subject: [issue28815] test_socket fails if /proc/modules is existent but not readable Message-ID: <1480263378.99.0.648069549511.issue28815@psf.upfronthosting.co.za> New submission from patrila: Dear Python developers The test_socket test fails if /proc/modules is existent but not readable by the user (this is for example the case with the grsecurity patchset of the kernel). The method reading /proc/modules is isTipcAvailable(), which is not a test but a guard for other tests. It seems reasonable to return False in the case that /proc/modules is not readable (but existent). The method isTipcAvailable() already returns False if /proc/modules is non existent (but fails to return False if it's not readable). Attached a proposed test. Feel free to remove the EISDIR in case you feel uncomfortable and want a it be a "real" error. The patch should be applied to both Python-2.7 and Python-3.x. Kind regards Here is the inline version of the patch; it's also attached. diff -r 876bee0bd0ba Lib/test/test_socket.py --- a/Lib/test/test_socket.py Sat Nov 26 14:04:40 2016 -0800 +++ b/Lib/test/test_socket.py Sun Nov 27 17:00:55 2016 +0100 @@ -4779,12 +4779,21 @@ """ if not hasattr(socket, "AF_TIPC"): return False - if not os.path.isfile("/proc/modules"): - return False - with open("/proc/modules") as f: - for line in f: - if line.startswith("tipc "): - return True + try: + f = open("/proc/modules") + except IOError as e: + # It's ok if the file does not exist, is a directory or if we + # have not the permission to read it. In any other case it's a + # real error, so raise it again. + if e.errno in (ENOENT, EISDIR, EACCES): + return False + else: + raise + else: + with f: + for line in f: + if line.startswith("tipc "): + return True return False @unittest.skipUnless(isTipcAvailable(), ---------- files: test_socket_isTipcAvailable_proc_modules.patch keywords: patch messages: 281828 nosy: patrila priority: normal severity: normal status: open title: test_socket fails if /proc/modules is existent but not readable versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45666/test_socket_isTipcAvailable_proc_modules.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 12:07:17 2016 From: report at bugs.python.org (Xiang Zhang) Date: Sun, 27 Nov 2016 17:07:17 +0000 Subject: [issue28728] test_host_resolution in test_socket fails In-Reply-To: <1479407743.41.0.909577209709.issue28728@psf.upfronthosting.co.za> Message-ID: <1480266437.21.0.310597445032.issue28728@psf.upfronthosting.co.za> Xiang Zhang added the comment: The three ipv6 addresses are all invalid addresses if we conform to spec. "::1q" non hex characteres "::1::2" two "::" but at most one is allowed "1:1:1:1:1:1:1:1:1" 144 bits > 128 bits > Perhaps this is similar to the problems encountered with test_bad_address() at Lib/test/test_urllibnet.py:102 I think they are the similar situations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 13:09:45 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 27 Nov 2016 18:09:45 +0000 Subject: [issue28813] Remove unneeded folded consts after peephole In-Reply-To: <1480244746.98.0.558504847162.issue28813@psf.upfronthosting.co.za> Message-ID: <1480270185.86.0.345388371109.issue28813@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, we intentionally decided not to do this when constant folding was added. The idea was to keep the peephole optimizer simple and to have it do the minimum work necessary to get its job done (optimizing the constants table takes extra time to do but doesn't result in faster code). Another reason was that aside from contrived examples (such as the OP's example), very little real-world code gets any benefit and the benefit tends to be very small. (In other words, no one will actually notice or benefit from this patch, but their compilation times will all slow down slightly). Lastly, the intention is to stop building out constant folding. The correct place for constant folding is upstream, using AST prior to code generation. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 13:17:19 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 27 Nov 2016 18:17:19 +0000 Subject: [issue28800] Add RETURN_NONE bytecode instruction In-Reply-To: <1480071315.87.0.448012344283.issue28800@psf.upfronthosting.co.za> Message-ID: <1480270639.8.0.157324970908.issue28800@psf.upfronthosting.co.za> Raymond Hettinger added the comment: When we added LIST_APPEND (the first of the custom opcodes intended for optimization), it was done only because it was frequently used in inner loops where it provided real benefits to users. In contrast this opcode seems like a waste. Historically for opcodes, we've valued orthogonality and parsimony. The opcode set was intentionally kept simple and minimal. The recent opcode additions have disregarded these values. ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 13:37:28 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 27 Nov 2016 18:37:28 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480271848.87.0.573400052773.issue28754@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > I would suggest to use sys.maxsize for default value in Argument Clinic No thanks. I don't want to subtly change the API for this module or even suggest to users that it might be a good idea to set hi > len. Further, we don't want to slow the pure python code for this pointless extension. Really, we're dancing around the issue that argument clinic and signatures need to become more expressive, allowing for omitted arguments without requiring a default value. Waiting for this to be done is far preferable to mangling long-standing APIs to force fit them to into argument clinic. Elsewhere, we've shown self discipline and restraint when applying AC, skipping over cases where it doesn't fit. If we can't find a way to apply AC without changing this API, this issue should be closed and deferred until AC grows the requisite expressive power. ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 13:53:54 2016 From: report at bugs.python.org (Eric N. Vander Weele) Date: Sun, 27 Nov 2016 18:53:54 +0000 Subject: [issue19521] Parallel build race condition on AIX since python-2.7 In-Reply-To: <1383840294.95.0.0890053719997.issue19521@psf.upfronthosting.co.za> Message-ID: <1480272834.28.0.618419073061.issue19521@psf.upfronthosting.co.za> Eric N. Vander Weele added the comment: I may be able to simplify the build on AIX by removing ld_so_aix and python.exp entirely. Would this be a preferred solution if I am able to get something working? If so, should I create a separate issue to track the change? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 15:12:25 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 27 Nov 2016 20:12:25 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480277545.01.0.202425396945.issue28754@psf.upfronthosting.co.za> Raymond Hettinger added the comment: After some further thought, I am open to changing the C API to accept either hi=None or hi=-1 to reconcile the implementation details without breaking any existing code that relies on either. That would let the argument clinic expose a default value of hi=None. That isn't perfect because it complicates the code and it exposes an implementation detail contrary to what the API originally intended. Short of that, this module ought to be skipped for the argument clinic pending a build-out of signature objects to handle signatures that vary depending on the number of arguments supplied. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 16:30:45 2016 From: report at bugs.python.org (Brett Cannon) Date: Sun, 27 Nov 2016 21:30:45 +0000 Subject: [issue28800] Add RETURN_NONE bytecode instruction In-Reply-To: <1480071315.87.0.448012344283.issue28800@psf.upfronthosting.co.za> Message-ID: <1480282245.51.0.30297954151.issue28800@psf.upfronthosting.co.za> Brett Cannon added the comment: My vote is to close this issue since the performance isn't panning out. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 16:31:06 2016 From: report at bugs.python.org (Brett Cannon) Date: Sun, 27 Nov 2016 21:31:06 +0000 Subject: [issue28810] Document bytecode changes in 3.6 In-Reply-To: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za> Message-ID: <1480282266.27.0.813196530663.issue28810@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 16:32:20 2016 From: report at bugs.python.org (Brett Cannon) Date: Sun, 27 Nov 2016 21:32:20 +0000 Subject: [issue12844] Support more than 255 arguments In-Reply-To: <1314326578.49.0.0651529898349.issue12844@psf.upfronthosting.co.za> Message-ID: <1480282340.56.0.288940561224.issue12844@psf.upfronthosting.co.za> Brett Cannon added the comment: Patch LGTM. ---------- assignee: -> serhiy.storchaka stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 16:43:07 2016 From: report at bugs.python.org (Tim Peters) Date: Sun, 27 Nov 2016 21:43:07 +0000 Subject: [issue28800] Add RETURN_NONE bytecode instruction In-Reply-To: <1480071315.87.0.448012344283.issue28800@psf.upfronthosting.co.za> Message-ID: <1480282987.37.0.188950034564.issue28800@psf.upfronthosting.co.za> Tim Peters added the comment: I also don't see a good reason to keep this open now - adds complication for no quantifiable payoff. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 19:25:05 2016 From: report at bugs.python.org (Davin Potts) Date: Mon, 28 Nov 2016 00:25:05 +0000 Subject: [issue28779] set_forkserver_preload() can crash the forkserver if preloaded module instantiate multiprocessing classes In-Reply-To: <1479914801.47.0.114591938702.issue28779@psf.upfronthosting.co.za> Message-ID: <1480292705.92.0.534408558147.issue28779@psf.upfronthosting.co.za> Davin Potts added the comment: Antoine: I'm still unclear on what's going on here but I noticed something by accident when trying your example script. Specifically, when I ran your script from the directory where it exists on disk, I could successfully reproduce what you described but if I ran your script from a different working directory (e.g. 'python3.5 ../tmp/issue_28779_repro.py') then I did not see the misbehavior and it instead ran through to completion without any exceptions reported. I saw this phenomenon (all that I described above) on both OSX and Ubuntu 16.04 systems. Secondly, looking at the file you attached, did everything make it into the patch? I ask because unless I'm missing something it looks like the patch adds arguments to the function signature but does not act upon them in any new way? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 19:34:29 2016 From: report at bugs.python.org (=?utf-8?q?Florian_H=C3=B6ch?=) Date: Mon, 28 Nov 2016 00:34:29 +0000 Subject: [issue24142] ConfigParser._read doesn't join multi-line values collected while reading if a ParsingError occured In-Reply-To: <1480198013.11.0.298646925254.issue24142@psf.upfronthosting.co.za> Message-ID: <0fe1d768-ad4c-8df0-59bb-718a37159a37@gmx.de> Florian H?ch added the comment: > Thanks for your patch! As you can see, 2.7 is no longer touched as the codebases diverged. Thanks, although I have to say it's a little bit unfortunate that Python 2.7 will be left in a worse state than 2.6 where this bug did not exist. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 19:52:54 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Nov 2016 00:52:54 +0000 Subject: [issue28779] set_forkserver_preload() can crash the forkserver if preloaded module instantiate multiprocessing classes In-Reply-To: <1479914801.47.0.114591938702.issue28779@psf.upfronthosting.co.za> Message-ID: <1480294374.25.0.0582719051053.issue28779@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I noticed something by accident when trying your example script That's due to the way I wrote the script (the use of __file__ to deduce the module name to preload), not anything inherent in the bug described here. > looking at the file you attached, did everything make it into the patch? Yes. > I ask because unless I'm missing something it looks like the patch adds arguments to the function signature but does not act upon them in any new way? It does not. It's only fixing the signature of the method in the base class (which raises NotImplementedError) to match the signature of the method in the derived class (which is the only one actually called). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 19:56:12 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Nov 2016 00:56:12 +0000 Subject: [issue28779] set_forkserver_preload() can crash the forkserver if preloaded module instantiate multiprocessing classes In-Reply-To: <1479914801.47.0.114591938702.issue28779@psf.upfronthosting.co.za> Message-ID: <1480294572.38.0.491491115973.issue28779@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Slight mistake in my explanation: the method in the base class raises ValueError, not NotImplementedError. Still, the basic explanation stands. (that said, if you think this is out of scope for this issue, I can revert that part of the patch) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 27 23:51:35 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 28 Nov 2016 04:51:35 +0000 Subject: [issue28808] Make PyUnicode_CompareWithASCIIString() never failing In-Reply-To: <1480175314.71.0.35688135657.issue28808@psf.upfronthosting.co.za> Message-ID: <1480308695.96.0.814368235443.issue28808@psf.upfronthosting.co.za> Xiang Zhang added the comment: LGTM. Although at first I am not in favour of this change but searching Github it seems all usages of this API doesn't check the possible error. ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 00:03:36 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 28 Nov 2016 05:03:36 +0000 Subject: [issue14844] netrc does not handle accentuated characters In-Reply-To: <1337289825.27.0.400304162278.issue14844@psf.upfronthosting.co.za> Message-ID: <1480309416.21.0.171424687907.issue14844@psf.upfronthosting.co.za> Xiang Zhang added the comment: I opened #28806 to improve netrc library. This could be solved if it's merged. ---------- dependencies: +Improve the netrc library nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 00:08:39 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 28 Nov 2016 05:08:39 +0000 Subject: [issue28334] netrc does not work if $HOME is not set In-Reply-To: <1475336154.44.0.44449733804.issue28334@psf.upfronthosting.co.za> Message-ID: <1480309719.36.0.549383164672.issue28334@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 02:14:00 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Nov 2016 07:14:00 +0000 Subject: [issue28808] Make PyUnicode_CompareWithASCIIString() never failing In-Reply-To: <1480175314.71.0.35688135657.issue28808@psf.upfronthosting.co.za> Message-ID: <1480317240.81.0.810616936306.issue28808@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Xiang. Ned, I ask your permission for committing this patch in 3.6. This is not critical neither new bug, it was introduced in 3.3 and is rarely reproducible. But 3.6b4 is the first version in which the changed behavior was documented, and this patch reverts the documentation change together with fixing the behavior. If release 3.6.0 without this patch, this will encourage users to change their code for handling possible error in PyUnicode_CompareWithASCIIString(), but these changes will be not needed when commit the patch. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 03:07:33 2016 From: report at bugs.python.org (Stefan Krah) Date: Mon, 28 Nov 2016 08:07:33 +0000 Subject: [issue20767] Some python extensions can't be compiled with clang 3.4 In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za> Message-ID: <1480320453.48.0.682621949311.issue20767@psf.upfronthosting.co.za> Stefan Krah added the comment: I guess the FreeBSD people are happy with the solution. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 03:20:57 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Nov 2016 08:20:57 +0000 Subject: [issue24142] ConfigParser._read doesn't join multi-line values collected while reading if a ParsingError occured In-Reply-To: <1431014086.96.0.315028213592.issue24142@psf.upfronthosting.co.za> Message-ID: <1480321257.79.0.490755199033.issue24142@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Would be nice to add Misc/NEWS entry for this patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 03:22:21 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 28 Nov 2016 08:22:21 +0000 Subject: [issue28699] Imap from ThreadPool behaves unexpectedly In-Reply-To: <1479234139.82.0.483433491582.issue28699@psf.upfronthosting.co.za> Message-ID: <1480321341.87.0.5422627059.issue28699@psf.upfronthosting.co.za> Xiang Zhang added the comment: > 4. Guard against misbehaving generators/iterables *before* they are put into the taskqueue. This approach is good. 2 points about the patch: 1. How about _map_async(map)? Does it need the same strategy? For an iterator with __len__ defined it seems to get the same issue as here. from multiprocessing import Pool def double(x): return 2 * x class buggy: def __iter__(self): return self def __next__(self): raise Exception('oops') def __len__(self): return 1 list(Pool(processes=2).map(double, buggy())) list(Pool(processes=2).map(double, buggy())) # hangs 2. The logic in _handle_tasks to handle task, i to could be removed I think. With _guarded_task_generation the for loop cannot fail and the logic itself is buggy now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 03:52:21 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 28 Nov 2016 08:52:21 +0000 Subject: [issue12844] Support more than 255 arguments In-Reply-To: <1314326578.49.0.0651529898349.issue12844@psf.upfronthosting.co.za> Message-ID: <20161128085218.22917.26557.9B4BD5F5@psf.io> Roundup Robot added the comment: New changeset 5c1bb72c0f5d by Serhiy Storchaka in branch 'default': Issue #12844: More than 255 arguments can now be passed to a function. https://hg.python.org/cpython/rev/5c1bb72c0f5d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 04:35:07 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Nov 2016 09:35:07 +0000 Subject: [issue28728] test_host_resolution in test_socket fails In-Reply-To: <1479407743.41.0.909577209709.issue28728@psf.upfronthosting.co.za> Message-ID: <1480325707.11.0.778339244248.issue28728@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 04:39:56 2016 From: report at bugs.python.org (Mark Harris) Date: Mon, 28 Nov 2016 09:39:56 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1480325996.84.0.619429976061.issue28781@psf.upfronthosting.co.za> Mark Harris added the comment: Hi Steve, I did as you suggested, removed following add remove programs, removed every instance of python I could find(folders etc.), cleared out the temp folder. Then I ran the commands you suggested(it couldn't find any of the registry keys this time), reinstalled from scratch and again when it was coming to the end of the installation the same message as before appeared "The program can't start because python35.dll is missing from your computer. Try reinstalling the program to fix this problem". I'm still getting the same issue. I was installing for all users, was that part of the problem? Thanks, Mark ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 04:45:40 2016 From: report at bugs.python.org (Decorater) Date: Mon, 28 Nov 2016 09:45:40 +0000 Subject: [issue28816] Document if zipimport can respect import hooks to load custom files from zip. Message-ID: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za> New submission from Decorater: I am wondering so lets say for example if I was to make a json import hook (code below): from importlib.machinery import FileFinder import json import sys class ExtensionImporter(object): """Base Importer Class.""" def __init__(self, extension_list): self.extensions = extension_list def find_loader(self, name, path): """Filds some loaders for importing the module.""" self.path = path return self def load_module(self, fullname): if fullname in sys.modules: return sys.modules[fullname] return None class JsonImporter(ExtensionImporter): """JSON importer Class.""" def __init__(self): super(JsonImporter, self).__init__(['.json']) def load_module(self, fullname): """Loads modules found with the extension""" premodule = super(JsonImporter, self).load_module(fullname) if premodule is None: with open(self.path, 'r') as f: module = json.load(f) sys.modules[fullname] = module return module raise ImportError('Couldn't open path') extension_importers = [JsonImporter()] hook_list = [] for importer in extension_importers: hook_list.append((importer.find_loader, importer.extensions)) sys.path_hooks.insert(0, FileFinder.path_hook(*hook_list)) sys.path_importer_cache.clear() What if I had those json files in a zip file and used ZipImport on that zip file would it use that import hook that I shared above if all other import methods fail to import those json files (obvously they would fail though)? There should be documentation to explain if it supports user created import hooks that they create using importlib. This is because I would be very happy if zipimport supports my own import hook if any other method of importing files from that zip file fails but mine ends up working. It also allows people to load up many other formats (provided they know the format) as if it was a python script. (of if they compressed it in a custom file like for example a RAR file that WinRAR can create. And yes I would support a RARImport for rar files. ---------- components: Interpreter Core, Windows messages: 281850 nosy: Decorater, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Document if zipimport can respect import hooks to load custom files from zip. versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 04:46:38 2016 From: report at bugs.python.org (Decorater) Date: Mon, 28 Nov 2016 09:46:38 +0000 Subject: [issue28816] Document if zipimport can respect import hooks to load custom files from zip. In-Reply-To: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za> Message-ID: <1480326398.58.0.535502055488.issue28816@psf.upfronthosting.co.za> Changes by Decorater : ---------- assignee: -> docs at python components: +Documentation -Interpreter Core nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 04:53:58 2016 From: report at bugs.python.org (Decorater) Date: Mon, 28 Nov 2016 09:53:58 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1480326838.0.0.954071869856.issue28781@psf.upfronthosting.co.za> Decorater added the comment: Normally when you install python systemwide it installs python35.dll in %SystemDrive%\Windows\System32\. Try looking there maybe you can use regsvr to register python35.dll in the registry or find where python.exe is and copy python35.dll to there. ---------- nosy: +Decorater _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 05:02:09 2016 From: report at bugs.python.org (Decorater) Date: Mon, 28 Nov 2016 10:02:09 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1480327329.63.0.550172568522.issue28781@psf.upfronthosting.co.za> Decorater added the comment: You could also download the embeded build which ships with python35.dll to put it in the folder you installed python to alongside python.exe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 05:05:20 2016 From: report at bugs.python.org (Eryk Sun) Date: Mon, 28 Nov 2016 10:05:20 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1480327520.4.0.906783608591.issue28781@psf.upfronthosting.co.za> Eryk Sun added the comment: No, Python 3.5 is the first version to always place the interpreter DLL in the installation directory, beside python.exe. Installing for all users does not place python35.dll in "%SystemRoot%\System32". ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 05:22:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Nov 2016 10:22:52 +0000 Subject: [issue18896] Remove namedtuple 255 arguments restriction In-Reply-To: <1377972310.66.0.567176219008.issue18896@psf.upfronthosting.co.za> Message-ID: <1480328572.98.0.543341002881.issue18896@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Currently it is not possible to declare a Python function with more than 255 parameters. There were two historical causes of this: 1. Opcodes MAKE_FUNCTION and MAKE_CLOSURE packed the number of default values for positional and keyword parameters in the opcode argument as 8-bit numbers. 2. co_cell2arg was of type "unsigned char *". It's mapped a cell index to an argument index and didn't support arguments with index > 254. The first limitation is disappeared in 3.6 after changing the format of MAKE_FUNCTION (issue27095). Proposed patch gets rid of the second cause by changing the type of co_cell2arg and removes explicit check in the compiler. ---------- components: +Interpreter Core keywords: +patch nosy: +serhiy.storchaka stage: -> patch review versions: +Python 3.7 -Python 3.4 Added file: http://bugs.python.org/file45667/no-params-limit.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 05:25:17 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Nov 2016 10:25:17 +0000 Subject: [issue12844] Support more than 255 arguments In-Reply-To: <1314326578.49.0.0651529898349.issue12844@psf.upfronthosting.co.za> Message-ID: <1480328717.46.0.569806604718.issue12844@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Brett. See issue18896 for supporting functions with more than 255 parameters. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 05:25:38 2016 From: report at bugs.python.org (Ram Rachum) Date: Mon, 28 Nov 2016 10:25:38 +0000 Subject: [issue28811] Make pathlib.PurePath.__str__ use shlex.quote In-Reply-To: <1480239193.34.0.752695388399.issue28811@psf.upfronthosting.co.za> Message-ID: <1480328738.49.0.837844940089.issue28811@psf.upfronthosting.co.za> Ram Rachum added the comment: I understand now, you're completely right. This change would break the entire world :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 05:27:09 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Mon, 28 Nov 2016 10:27:09 +0000 Subject: [issue9938] Documentation for argparse interactive use In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za> Message-ID: <1480328829.14.0.923186356904.issue9938@psf.upfronthosting.co.za> Changes by Wolfgang Maier : ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 05:28:34 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 28 Nov 2016 10:28:34 +0000 Subject: [issue28749] Fixed the documentation of the mapping codec APIs In-Reply-To: <1479637798.25.0.994184606714.issue28749@psf.upfronthosting.co.za> Message-ID: <1480328914.71.0.52811299574.issue28749@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Why are you removing the introductory section on how mappings work ? Also, this wording needs to be corrected: "bytes (integers in the range from 0 to 255)". Bytes are not integers. I'd suggest to use the more correct wording "bytes strings of length 1". ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 05:41:44 2016 From: report at bugs.python.org (Ram Rachum) Date: Mon, 28 Nov 2016 10:41:44 +0000 Subject: [issue28817] Provide method PurePath.quote() that calls shlex.quote Message-ID: <1480329704.42.0.830196974731.issue28817@psf.upfronthosting.co.za> New submission from Ram Rachum: I have a a PurePath object like so: path = PurePath('/home/my awesome user/file.txt') I'm SSHing into a server and I want to remove the file. So I have to do this: ssh_client.run(f'/bin/rm {shlex.quote(str(path))}') Which is really long and ugly. I suggested in issue28623 that shlex.quote could just take a Path argument, and in issue28811 that __str__ would use shlex.quote, and it was rejected too. My next suggestion: Implement PurePath.quote() method that calls shlex.quote() on the path. What do you think? ---------- components: Library (Lib) messages: 281858 nosy: cool-RR, pitrou priority: normal severity: normal status: open title: Provide method PurePath.quote() that calls shlex.quote type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 05:41:50 2016 From: report at bugs.python.org (Ram Rachum) Date: Mon, 28 Nov 2016 10:41:50 +0000 Subject: [issue28817] Provide method PurePath.quote() that calls shlex.quote In-Reply-To: <1480329704.42.0.830196974731.issue28817@psf.upfronthosting.co.za> Message-ID: <1480329710.82.0.131792542239.issue28817@psf.upfronthosting.co.za> Changes by Ram Rachum : ---------- versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 05:55:25 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Nov 2016 10:55:25 +0000 Subject: [issue28817] Provide method PurePath.quote() that calls shlex.quote In-Reply-To: <1480329704.42.0.830196974731.issue28817@psf.upfronthosting.co.za> Message-ID: <1480330525.91.0.622903863201.issue28817@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Please no. The interface of pathlib is already overburdened. We shouldn't add every function that is applicable to string paths as a Path method. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 05:56:04 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Nov 2016 10:56:04 +0000 Subject: [issue28799] Drop CALL_PROFILE special build? In-Reply-To: <1480064573.69.0.905508550534.issue28799@psf.upfronthosting.co.za> Message-ID: <1480330564.14.0.20534798727.issue28799@psf.upfronthosting.co.za> STINNER Victor added the comment: Jeremy Hylton, the author of the feature, approved the removal of CALL_PROFILE: https://mail.python.org/pipermail/python-dev/2016-November/146866.html Raymond Hettinger is also ok to remove it: "This seems reasonable to me. I've never used or needed this special build; StackOverflow has no mention of it; and a Google search comes up nearly empty. That said, it might be worthwhile to check with Jeremy to get his thoughts before removing his code." https://mail.python.org/pipermail/python-dev/2016-November/146864.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 06:03:41 2016 From: report at bugs.python.org (INADA Naoki) Date: Mon, 28 Nov 2016 11:03:41 +0000 Subject: [issue28818] simplify lookdict functions Message-ID: <1480331020.89.0.515440713784.issue28818@psf.upfronthosting.co.za> New submission from INADA Naoki: This patch reduces indirect access to improve readability. benchmark: Slower (14): - logging_format: 29.9 us +- 2.7 us -> 31.2 us +- 2.8 us: 1.04x slower - scimark_monte_carlo: 227 ms +- 5 ms -> 235 ms +- 16 ms: 1.03x slower - dulwich_log: 149 ms +- 10 ms -> 153 ms +- 14 ms: 1.03x slower - json_dumps: 23.9 ms +- 1.5 ms -> 24.5 ms +- 2.4 ms: 1.03x slower - scimark_lu: 490 ms +- 12 ms -> 501 ms +- 33 ms: 1.02x slower - deltablue: 16.4 ms +- 0.6 ms -> 16.7 ms +- 0.6 ms: 1.02x slower - call_simple: 13.3 ms +- 0.5 ms -> 13.6 ms +- 0.5 ms: 1.02x slower - sqlalchemy_declarative: 323 ms +- 11 ms -> 330 ms +- 26 ms: 1.02x slower - regex_compile: 389 ms +- 12 ms -> 394 ms +- 28 ms: 1.01x slower - python_startup: 16.4 ms +- 0.5 ms -> 16.6 ms +- 0.9 ms: 1.01x slower - regex_dna: 284 ms +- 7 ms -> 286 ms +- 20 ms: 1.01x slower - pidigits: 297 ms +- 7 ms -> 299 ms +- 17 ms: 1.01x slower - raytrace: 1.18 sec +- 0.02 sec -> 1.18 sec +- 0.03 sec: 1.00x slower - python_startup_no_site: 9.96 ms +- 0.25 ms -> 9.98 ms +- 0.45 ms: 1.00x slower Faster (11): - pickle_dict: 65.7 us +- 1.4 us -> 63.1 us +- 2.0 us: 1.04x faster - call_method_unknown: 19.4 ms +- 1.1 ms -> 18.8 ms +- 0.9 ms: 1.03x faster - xml_etree_parse: 248 ms +- 11 ms -> 244 ms +- 14 ms: 1.02x faster - xml_etree_generate: 225 ms +- 13 ms -> 221 ms +- 10 ms: 1.02x faster - call_method_slots: 16.9 ms +- 0.8 ms -> 16.6 ms +- 0.7 ms: 1.02x faster - logging_silent: 725 ns +- 41 ns -> 715 ns +- 35 ns: 1.01x faster - xml_etree_iterparse: 210 ms +- 16 ms -> 208 ms +- 12 ms: 1.01x faster - json_loads: 53.7 us +- 3.4 us -> 53.0 us +- 1.7 us: 1.01x faster - call_method: 17.2 ms +- 0.8 ms -> 17.0 ms +- 0.6 ms: 1.01x faster - nbody: 227 ms +- 14 ms -> 226 ms +- 8 ms: 1.00x faster - pickle_pure_python: 1.07 ms +- 0.04 ms -> 1.07 ms +- 0.07 ms: 1.00x faster Benchmark hidden because not significant (39): 2to3, chameleon, chaos, crypto_pyaes, django_template, fannkuch, float, genshi_text, genshi_xml, go, hexiom, html5lib, logging_simple, mako, meteor_contest, nqueens, pathlib, pickle, pickle_list, regex_effbot, regex_v8, richards, scimark_fft, scimark_sor, scimark_sparse_mat_mult, spectral_norm, sqlalchemy_imperative, sqlite_synth, sympy_expand, sympy_integrate, sympy_str, sympy_sum, telco, tornado_http, unpack_sequence, unpickle, unpickle_list, unpickle_pure_python, xml_etree_process ---------- components: Interpreter Core files: simplify-lookdict.patch keywords: patch messages: 281861 nosy: inada.naoki priority: normal severity: normal stage: patch review status: open title: simplify lookdict functions type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45668/simplify-lookdict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 06:05:17 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 28 Nov 2016 11:05:17 +0000 Subject: [issue28799] Drop CALL_PROFILE special build? In-Reply-To: <1480064573.69.0.905508550534.issue28799@psf.upfronthosting.co.za> Message-ID: <20161128110513.82176.14206.484BBC17@psf.io> Roundup Robot added the comment: New changeset 5aa2171ee43f by Victor Stinner in branch 'default': Remove CALL_PROFILE special build https://hg.python.org/cpython/rev/5aa2171ee43f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 06:06:20 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 28 Nov 2016 11:06:20 +0000 Subject: [issue28799] Drop CALL_PROFILE special build? In-Reply-To: <1480064573.69.0.905508550534.issue28799@psf.upfronthosting.co.za> Message-ID: <20161128110618.23165.46865.C8D24795@psf.io> Roundup Robot added the comment: New changeset 07d8272d61e7 by Victor Stinner in branch 'default': Issue #28799: Update Misc/SpecialBuilds.txt https://hg.python.org/cpython/rev/07d8272d61e7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 06:24:57 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Nov 2016 11:24:57 +0000 Subject: [issue28749] Fixed the documentation of the mapping codec APIs In-Reply-To: <1479637798.25.0.994184606714.issue28749@psf.upfronthosting.co.za> Message-ID: <1480332297.62.0.991320149527.issue28749@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Xiang. I forgot about comments in headers, the updated path updates them too. > Why are you removing the introductory section on how mappings work ? Because it is not correct. I copied it to descriptions of concrete functions with correcting it according to the peculiarity of particular function. > Also, this wording needs to be corrected: "bytes (integers in the range from 0 to 255)". Bytes are not integers. I'd suggest to use the more correct wording "bytes strings of length 1". The word "bytes" means here not Python bytes object, but is used in more common meaning: an integer in the range from 0 to 255. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 06:25:11 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Nov 2016 11:25:11 +0000 Subject: [issue28749] Fixed the documentation of the mapping codec APIs In-Reply-To: <1479637798.25.0.994184606714.issue28749@psf.upfronthosting.co.za> Message-ID: <1480332311.1.0.839487726624.issue28749@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file45669/docs-PyUnicode_Translate-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 06:26:21 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Nov 2016 11:26:21 +0000 Subject: [issue28818] simplify lookdict functions In-Reply-To: <1480331020.89.0.515440713784.issue28818@psf.upfronthosting.co.za> Message-ID: <1480332381.6.0.855149124039.issue28818@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +rhettinger, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 06:53:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Nov 2016 11:53:13 +0000 Subject: [issue28818] simplify lookdict functions In-Reply-To: <1480331020.89.0.515440713784.issue28818@psf.upfronthosting.co.za> Message-ID: <1480333993.76.0.507982148764.issue28818@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. I don't expect significant performance difference, but the code looks simpler. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 06:54:04 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 28 Nov 2016 11:54:04 +0000 Subject: [issue28749] Fixed the documentation of the mapping codec APIs In-Reply-To: <1480332297.62.0.991320149527.issue28749@psf.upfronthosting.co.za> Message-ID: <583C1AD7.7020206@egenix.com> Marc-Andre Lemburg added the comment: On 28.11.2016 12:24, Serhiy Storchaka wrote: >> Why are you removing the introductory section on how mappings work ? > > Because it is not correct. I copied it to descriptions of concrete functions with correcting it according to the peculiarity of particular function. The only part that is not correct is "single string characters". This should read "single bytes" or "bytes strings of length 1". I also don't see where you copied the description. Without some description of what "mappings" are in the context of the charmap codec, it's not easy to understand what the purpose of these APIs is. Please just fix the bytes wording instead of removing the whole intro. >> Also, this wording needs to be corrected: "bytes (integers in the range from 0 to 255)". Bytes are not integers. I'd suggest to use the more correct wording "bytes strings of length 1". > > The word "bytes" means here not Python bytes object, but is used in more common meaning: an integer in the range from 0 to 255. That's confusing, since we use the term "bytes" as referring to the bytes object in Python. Please use "integers in the range 0-255". Aside: The deprecation of PyUnicode_EncodeCharmap() also seems misplaced in this context, since only the Py_UNICODE version of the API is deprecated. The functionality still exists and is useful. An API similar to the _PyUnicode_EncodeCharmap() API should be made publicly available to accommodate for the deprecation, since the mentioned PyUnicode_AsCharmapString() and PyUnicode_AsEncodedString() APIs are not suitable as replacement. PyUnicode_AsCharmapString() doesn't support error handling (strange, BTW) and PyUnicode_AsEncodedString() has a completely unrelated meaning (no idea why it's mentioned here at all). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 07:34:30 2016 From: report at bugs.python.org (B. Liu) Date: Mon, 28 Nov 2016 12:34:30 +0000 Subject: [issue28819] tzinfo class spacing bug Message-ID: <1480336470.38.0.585299184386.issue28819@psf.upfronthosting.co.za> New submission from B. Liu: In Python 2.7, the following works: import datetime ZERO = timedelta(0) class UTC(datetime.tzinfo): """UTC""" # can be configured here def utcoffset(self, dt): return ZERO def tzname(self, dt): return "UTC" def dst(self, dt): return ZERO def extraMethod(self): return "here is an extra method" utc = UTC() epoch = datetime.datetime.utcfromtimestamp(0) print datetime.datetime.fromtimestamp(epoch, utc) But, the following does not work: import datetime ZERO = timedelta(0) class UTC(datetime.tzinfo): """UTC""" # can be configured here def utcoffset(self, dt): return ZERO def tzname(self, dt): return "UTC" def dst(self, dt): return ZERO def extraMethod(self): return "here is an extra method" utc = UTC() epoch = datetime.datetime.utcfromtimestamp(0) print datetime.datetime.fromtimestamp(epoch, utc) The difference is that there is a space after the class line. Is this an issue with grammar or some issue with the library's C code? If it is an issue with grammar, I appear to have not run into this issue with non-datetime-related code. If this not an issue, please correct me. Thanks! Brian ---------- components: Library (Lib) files: bug.py messages: 281867 nosy: bzliu94 priority: normal severity: normal status: open title: tzinfo class spacing bug Added file: http://bugs.python.org/file45670/bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 07:34:34 2016 From: report at bugs.python.org (Mark Harris) Date: Mon, 28 Nov 2016 12:34:34 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1480336474.15.0.139813043866.issue28781@psf.upfronthosting.co.za> Mark Harris added the comment: Thanks for the advice, I downloaded the Python35.dll in the file located here https://www.python.org/downloads/release/python-352/ which was called "Windows x86 embeddable zip file". With this file when I enter python.exe the program crashes. I tried Windows x86-64 embeddable zip file however it said it was the wrong version. Am I using the wrong link? I tried repairing python and the installation processes deletes the python35.dll file in the directory and then the end of the installation says the same error as befere (python35.dll being missing etc.) Sorry about all the posts, would really like to get python working again! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 07:36:20 2016 From: report at bugs.python.org (B. Liu) Date: Mon, 28 Nov 2016 12:36:20 +0000 Subject: [issue28819] tzinfo class spacing bug In-Reply-To: <1480336470.38.0.585299184386.issue28819@psf.upfronthosting.co.za> Message-ID: <1480336580.73.0.923549516238.issue28819@psf.upfronthosting.co.za> Changes by B. Liu : ---------- type: -> behavior versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 07:40:36 2016 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 28 Nov 2016 12:40:36 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1480336836.1.0.893057658555.issue24339@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: The codec code has a few (performance) issues: * nonspacing_diacritical_marks should be a set for fast lookup * ord(c) in range(0x00, 0xA0) should be rewritten using < and >= * result += bytes([ord(c)]) has exponential timing (it copies the whole bytes string for every single operation); better use a bytearray and convert this to bytes in one final step * the error messages should include more useful information about the cause and location of the error, instead of just UnicodeError("Unacceptable unicode character") and raise KeyError Please also check whether it's not possible to reuse the charmap codec functions we have. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 07:47:25 2016 From: report at bugs.python.org (Rares Aioanei) Date: Mon, 28 Nov 2016 12:47:25 +0000 Subject: [issue28820] Typo in section 6 of the Python 3.4 documentation Message-ID: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za> New submission from Rares Aioanei: In section 6.4.1. it's said "Although certain modules are designed to export only names that follow certain patterns when you use import *, it is still considered bad practise in production code." "practise" should be "practice", as it's a noun. ---------- assignee: docs at python components: Documentation messages: 281870 nosy: Rares Aioanei, docs at python priority: normal severity: normal status: open title: Typo in section 6 of the Python 3.4 documentation type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 07:51:21 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 28 Nov 2016 12:51:21 +0000 Subject: [issue28819] tzinfo class spacing bug In-Reply-To: <1480336470.38.0.585299184386.issue28819@psf.upfronthosting.co.za> Message-ID: <1480337481.97.0.321794054061.issue28819@psf.upfronthosting.co.za> SilentGhost added the comment: What do you mean by "work" and "does not work"? Both versions raise TypeError, because you're passing epoch to fromtimestamp, but once that's fixed both versions return identical output. Python is not sensitive to empty lines in class definitions, so I'd be surprised if anyone was able to reproduce your issue. ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 07:51:42 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Nov 2016 12:51:42 +0000 Subject: [issue28749] Fixed the documentation of the mapping codec APIs In-Reply-To: <583C1AD7.7020206@egenix.com> Message-ID: <2044899.0GaGWQQ6m7@xarax> Serhiy Storchaka added the comment: > The only part that is not correct is "single string characters". > This should read "single bytes" or "bytes strings of length 1". This is not correct. Decoding mappings map not bytes strings, but integers. And this is not the only incorrect part. Decoding mappings can map to multicharacter Unicode strings, not to single Unicode characters. Not just None, but the integer 0xfffe and Unicode string '\ufffe' mean "undefined mapping". There are similar incorrectnesses about encoding mappings. > I also don't see where you copied the description. Without some > description of what "mappings" are in the context of the charmap > codec, it's not easy to understand what the purpose of these > APIs is. Please just fix the bytes wording instead of removing the > whole intro. Decoding mappings were desribed in the introduction and in the description of PyUnicode_DecodeCharmap() (both are outdated and incomplete). I merged and corrected descriptions and left it only in one place, since PyUnicode_DecodeCharmap() is the only function that needs this. Same for encoding mappings. Both decoding and encoding mappings do not have a relation to PyUnicode_Translate(). The paragraph about a LookupError in the introduction was totally wrong. I left in the introduction only common part. Other details are too different in decoding, encoding and translation mappings. > >> Also, this wording needs to be corrected: "bytes (integers in the range > >> from 0 to 255)". Bytes are not integers. I'd suggest to use the more > >> correct wording "bytes strings of length 1".> > > The word "bytes" means here not Python bytes object, but is used in more > > common meaning: an integer in the range from 0 to 255. > That's confusing, since we use the term "bytes" as referring > to the bytes object in Python. Please use "integers in the range > 0-255". Okay, I'll remove the word "bytes" here. But how would you formulate the following sentence: "Unmapped bytes (ones which cause a :exc:`LookupError`) as well as mapped to ``None``, ``0xFFFE`` or ``'\ufffe'`` are treated as "undefined mapping" and cause an error."? > Aside: The deprecation of PyUnicode_EncodeCharmap() also seems misplaced > in this context, since only the Py_UNICODE version of the API is > deprecated. The functionality still exists and is useful. An API > similar to the _PyUnicode_EncodeCharmap() API should be made publicly > available to accommodate for the deprecation, since the mentioned > PyUnicode_AsCharmapString() and PyUnicode_AsEncodedString() > APIs are not suitable as replacement. PyUnicode_AsCharmapString() > doesn't support error handling (strange, BTW) and > PyUnicode_AsEncodedString() has a completely unrelated meaning (no > idea why it's mentioned here at all). Only PyUnicode_EncodeCharmap() is deprecated, PyUnicode_AsCharmapString() is not deprecated. I placed the deprecated function just after its non-deprecated counerpart following the pattern for other deprecated functions. If you prefer I'll move both deprecated functions (PyUnicode_EncodeCharmap and PyUnicode_TranslateCharmap) together at the end of this section. I don't know why PyUnicode_AsCharmapString() don't support the errors argument. I added PyUnicode_AsEncodedString() as a replacement (issue19569) because this is the only public non-deprecated way to do a charmap encoding with errors handling. There is no exact equivalent, but PyUnicode_AsCharmapString() and PyUnicode_AsEncodedString() cover different areas of using PyUnicode_EncodeCharmap(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 07:52:51 2016 From: report at bugs.python.org (B. Liu) Date: Mon, 28 Nov 2016 12:52:51 +0000 Subject: [issue28819] tzinfo class spacing bug In-Reply-To: <1480336470.38.0.585299184386.issue28819@psf.upfronthosting.co.za> Message-ID: <1480337571.49.0.954778096863.issue28819@psf.upfronthosting.co.za> B. Liu added the comment: Nevermind, the code I submitted was incomplete/buggy. This is embarrassing. The issue was that I was using an interpreter and a class definition that had spaces was happy to be read incompletely. Attached is working demonstration code that doesn't work as expected when entered in an interpreter. Sorry, SilentGhost. As fast as I tried to edit this, you still beat me. ---------- resolution: -> not a bug status: open -> closed Added file: http://bugs.python.org/file45671/example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 07:57:06 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 28 Nov 2016 12:57:06 +0000 Subject: [issue28819] tzinfo class spacing bug In-Reply-To: <1480336470.38.0.585299184386.issue28819@psf.upfronthosting.co.za> Message-ID: <1480337826.18.0.693916360382.issue28819@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 08:28:18 2016 From: report at bugs.python.org (Mark Harris) Date: Mon, 28 Nov 2016 13:28:18 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1480339698.59.0.169374606239.issue28781@psf.upfronthosting.co.za> Mark Harris added the comment: Sorry realized I didn't say I put the python35.dll in the python 35-32 folder of the c drive with the above results. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 08:31:27 2016 From: report at bugs.python.org (Decorater) Date: Mon, 28 Nov 2016 13:31:27 +0000 Subject: [issue28816] Document if zipimport can respect import hooks to load custom files from zip. In-Reply-To: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za> Message-ID: <1480339887.03.0.985519432053.issue28816@psf.upfronthosting.co.za> Changes by Decorater : ---------- components: -Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 08:51:03 2016 From: report at bugs.python.org (Julien Palard) Date: Mon, 28 Nov 2016 13:51:03 +0000 Subject: [issue28820] Typo in section 6 of the Python 3.4 documentation In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za> Message-ID: <1480341063.8.0.697688228323.issue28820@psf.upfronthosting.co.za> Julien Palard added the comment: Hi Rares thanks for reporting. While building a patch for this issue I found another occurrence of the error. ---------- keywords: +patch nosy: +mdk Added file: http://bugs.python.org/file45672/issue28820.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 08:59:16 2016 From: report at bugs.python.org (Zachary Ware) Date: Mon, 28 Nov 2016 13:59:16 +0000 Subject: [issue28817] Provide method PurePath.quote() that calls shlex.quote In-Reply-To: <1480329704.42.0.830196974731.issue28817@psf.upfronthosting.co.za> Message-ID: <1480341556.44.0.879732978075.issue28817@psf.upfronthosting.co.za> Zachary Ware added the comment: You already have a short, simple, one-line solution, and have had suggestions for shortening it yourself if you absolutely need to do so. If you can provide proof that this is an extremely common use case (and considering how short the solution already is, it would need to be completely ubiquitous), we might reconsider this, but in the absence of such proof these suggestions are trying to solve a problem that doesn't exist. ---------- nosy: +zach.ware resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 09:10:59 2016 From: report at bugs.python.org (Eryk Sun) Date: Mon, 28 Nov 2016 14:10:59 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1480342259.69.0.677584380489.issue28781@psf.upfronthosting.co.za> Eryk Sun added the comment: Please zip and upload the installation logs since your most recent attempt in msg281849. They might help to figure out why it's doing a per-user uninstall that removes python35.dll. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 09:22:17 2016 From: report at bugs.python.org (Julien Palard) Date: Mon, 28 Nov 2016 14:22:17 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480342937.59.0.572853150733.issue28754@psf.upfronthosting.co.za> Julien Palard added the comment: Hi Raymond, About Argument Clinic ##################### Just to clarify the situation, Argument Clinic allows for clear method signature, typically: `hi: Py_ssize_t(py_default="len(a)") = -1` gives the expected "hi=len(a)" signature successfully. The problem is that it's not a legal signature (it's a syntax error), so pydoc crashes while parsing it (search for RuntimeError in the history of the issue for a full stacktrace). About what should we put in the signature ######################################### Question is: Should we allow "semantically precise, but frustrating*" signatures to be documented or should we be move the semantic away from the signature? *: I mean, is a new user sees "hi=len(a)" in a signature in a docstring he will immediately flag this syntax as valid and usable later, which lead him to a syntax error and some frustration. Something else to keep in mind is that I expect users be able to call those methods indirectly, like: def whatever_they_need(self, lo=0, hi=?): ? bisect.bisect(?, ?, lo, hi) ? Currently, to follow strictly the documentation they have to write: def whatever_they_need(self, lo=0, hi=None): ? if hi is not None: bisect.bisect(?, ?, lo, hi) else: bisect.bisect(?, ?, lo) ? Which looks bad to me. So from my point of view we *have to* tell them what is the real default value for this parameter so they can use it in their implementations. Should we generalize and say that depending on the number of arguments is a bad practice? I think so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 09:30:45 2016 From: report at bugs.python.org (Mark Harris) Date: Mon, 28 Nov 2016 14:30:45 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1480343445.95.0.875728112892.issue28781@psf.upfronthosting.co.za> Mark Harris added the comment: I've attached all the files I could find in the temp file. Hope that helps. Mark ---------- Added file: http://bugs.python.org/file45673/Python 3.5.2 log files.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 09:40:13 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 28 Nov 2016 14:40:13 +0000 Subject: [issue28816] Document if zipimport can respect import hooks to load custom files from zip. In-Reply-To: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za> Message-ID: <1480344013.12.0.929077984024.issue28816@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- nosy: +brett.cannon, eric.snow, ncoghlan, twouters -steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 11:16:14 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 28 Nov 2016 16:16:14 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480349774.36.0.987857287786.issue28754@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry Julien, you don't to decide that long-standing APIs that have worked just fine for users are now a bad practice. Some of these APIs (range, dict.pop, type) we designed by Guido and work fine in practice. The expression, "don't have the tail wag the dog" comes to mind (where "tail" is the existing successful language and "dog" is the argument clinic). Besides, API change is very disruptive to users (especially those trying to migrate to Python 3). For the case of bisect, I've given a way forward. It is okay to make the documented default value for "hi" to be "None" while internally still allowing -1 so that we don't break code that happens to depend on it. In the clinic, use "hi: 'O' = None". Then in the dispatch code, handle both the None case and the numeric case (see islice_new() in itertoolsmodule.c for some ideas on how to do this. What isn't okay is to document and expose "hi=-1" because that is a confusing and error-prone default value that is just an awkward hack to express "hi=len(a)". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 11:19:49 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 28 Nov 2016 16:19:49 +0000 Subject: [issue28818] simplify lookdict functions In-Reply-To: <1480331020.89.0.515440713784.issue28818@psf.upfronthosting.co.za> Message-ID: <1480349989.49.0.718472191981.issue28818@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Can you make the patch without the unnecessary variable name change from "value_addr" to "pvalue". The former name is more communicative and is self-describing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 11:22:16 2016 From: report at bugs.python.org (Florin Papa) Date: Mon, 28 Nov 2016 16:22:16 +0000 Subject: [issue28821] generate_opcode_h.py crash when run with python2 Message-ID: <1480350136.76.0.0346939338673.issue28821@psf.upfronthosting.co.za> New submission from Florin Papa: Hello, This is Florin Papa from the Dynamic Scripting Languages Optimizations team in Intel Corporation. In changeset 105360:46e2755b022c [1] the generate_opcode_h.py script was modified to use tokenize.open() in order to avoid a Resource Warning. The tokenize module does not have an 'open' attribute in python2, therefore the build will crash if python3 is not present on the system. The patch attached checks if the tokenize module has the 'open' attribute. If it does, the current implementation will be used. Otherwise, it will fall back to the old implementation. Thank you, Florin [1] https://hg.python.org/cpython/rev/46e2755b022c ---------- components: Build files: generate_opcode_h.patch keywords: patch messages: 281882 nosy: florin.papa priority: normal severity: normal status: open title: generate_opcode_h.py crash when run with python2 type: crash versions: Python 3.7 Added file: http://bugs.python.org/file45674/generate_opcode_h.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 11:29:18 2016 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 28 Nov 2016 16:29:18 +0000 Subject: [issue28822] Fix indices handling in PyUnicode_FindChar Message-ID: <1480350558.9.0.582516213925.issue28822@psf.upfronthosting.co.za> New submission from Xiang Zhang: PyUnicode_FindChar declares in the doc it treats its *start* and *end* parameters as str[start:end], same as other APIs like PyUnicode_Find, PyUnicode_Count. But it doesn't allow negative indices like others so violates the doc. ---------- components: Interpreter Core files: PyUnicode_FindChar.patch keywords: patch messages: 281883 nosy: haypo, serhiy.storchaka, xiang.zhang priority: normal severity: normal stage: patch review status: open title: Fix indices handling in PyUnicode_FindChar type: behavior versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45675/PyUnicode_FindChar.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 11:31:28 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 28 Nov 2016 16:31:28 +0000 Subject: [issue27172] Undeprecate inspect.getfullargspec() In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za> Message-ID: <1480350688.34.0.782731838207.issue27172@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, your patch LGTM. I'd only add to the getargspec section that getfullargspec is usually a drop-in replacement (I've yet to see code where it's not the case). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 11:35:03 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 28 Nov 2016 16:35:03 +0000 Subject: [issue28821] generate_opcode_h.py crash when run with python2 In-Reply-To: <1480350136.76.0.0346939338673.issue28821@psf.upfronthosting.co.za> Message-ID: <1480350903.12.0.798528099365.issue28821@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 11:45:09 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Nov 2016 16:45:09 +0000 Subject: [issue28823] Simplify compiling to BUILD_MAP_UNPACK Message-ID: <1480351509.39.0.820702291303.issue28823@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Currently the compiler produces BUILD_MAP_UNPACK with an argument at most 255. If needed to merge more than 255 dictionaries, BUILD_MAP_UNPACK is called several times. But this is unneeded complication since BUILD_MAP_UNPACK doesn't have a limitation on its argument. Seems this code is the remnants from the patches when there was not the opcode BUILD_MAP_UNPACK_WITH_CALL, and BUILD_MAP_UNPACK packed the position of function name in higher bits of its argument. Proposed patch simplifies the compiler, makes the bytecode faster if merge more than 255 dictionaries and more compact if merge more than 509 dictionaries. BUILD_MAP_UNPACK was introduced in issue2292. ---------- components: Interpreter Core files: BUILD_MAP_UNPACK-unlimited-arg.patch keywords: patch messages: 281885 nosy: Joshua.Landau, benjamin.peterson, brett.cannon, georg.brandl, ncoghlan, neil.g, serhiy.storchaka, yselivanov priority: normal severity: normal stage: patch review status: open title: Simplify compiling to BUILD_MAP_UNPACK type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45676/BUILD_MAP_UNPACK-unlimited-arg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 11:46:05 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 28 Nov 2016 16:46:05 +0000 Subject: [issue28635] Update What's New for 3.6 In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za> Message-ID: <20161128164602.13835.47205.2113DA2F@psf.io> Roundup Robot added the comment: New changeset 52038705827d by Yury Selivanov in branch '3.6': Issue #28635: Document Python 3.6 opcode changes https://hg.python.org/cpython/rev/52038705827d New changeset 48fb6a4cb5f8 by Yury Selivanov in branch 'default': Merge 3.6 (issue #28635) https://hg.python.org/cpython/rev/48fb6a4cb5f8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 11:48:25 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 28 Nov 2016 16:48:25 +0000 Subject: [issue28823] Simplify compiling to BUILD_MAP_UNPACK In-Reply-To: <1480351509.39.0.820702291303.issue28823@psf.upfronthosting.co.za> Message-ID: <1480351705.58.0.424883736502.issue28823@psf.upfronthosting.co.za> Yury Selivanov added the comment: While I don't think that merging more than 256 dicts is a common task, the code does become much simpler. LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 11:51:11 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Nov 2016 16:51:11 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480351871.13.0.412498716247.issue28754@psf.upfronthosting.co.za> STINNER Victor added the comment: Sorry, I didn't follow the discussion, but why not using "/" magic separator in Argument Clinic to mark arguments as optional but don't document their default value? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 11:56:35 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Nov 2016 16:56:35 +0000 Subject: [issue28822] Fix indices handling in PyUnicode_FindChar In-Reply-To: <1480350558.9.0.582516213925.issue28822@psf.upfronthosting.co.za> Message-ID: <1480352195.75.0.852033992266.issue28822@psf.upfronthosting.co.za> STINNER Victor added the comment: PyUnicode_FindChar.patch is a new feature, it cannot be applied to stable branches (py < 3.7). I'm not sure that it's worth it to support negative indexes for end. Why not simply documenting that end must be positive? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 12:00:23 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 28 Nov 2016 17:00:23 +0000 Subject: [issue28288] Expose environment variable for Py_Py3kWarningFlag In-Reply-To: <1474993446.86.0.709676160725.issue28288@psf.upfronthosting.co.za> Message-ID: <1480352423.14.0.968259046928.issue28288@psf.upfronthosting.co.za> Berker Peksag added the comment: > PYTHON3WARNINGS looks as Python 3 variant of PYTHONWARNINGS. Sadly, I can't think of a better name. Do you have a suggestion? > Yes, I suppose this falls under the general exemption in 2.x for -3 warning changes. Thanks, Benjamin! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 12:02:21 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 28 Nov 2016 17:02:21 +0000 Subject: [issue28800] Add RETURN_NONE bytecode instruction In-Reply-To: <1480071315.87.0.448012344283.issue28800@psf.upfronthosting.co.za> Message-ID: <1480352541.17.0.76302746743.issue28800@psf.upfronthosting.co.za> Yury Selivanov added the comment: -1; we have too many opcodes already. Let's not complicate the code if there's no performance improvement. ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 12:03:21 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Nov 2016 17:03:21 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480352601.85.0.651438599213.issue28754@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yet one option is to introduce the constant UNBOUND = -1 in the bisect module and use it as a default value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 12:07:17 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Nov 2016 17:07:17 +0000 Subject: [issue28800] Add RETURN_NONE bytecode instruction In-Reply-To: <1480071315.87.0.448012344283.issue28800@psf.upfronthosting.co.za> Message-ID: <1480352837.76.0.0745895586958.issue28800@psf.upfronthosting.co.za> STINNER Victor added the comment: Sorry, I didn't want to bother you. I should run the benchmark *before* opening an issue next time :-) I agree that the speedup is negligible, so it's not worth it. The main purpose of the patch was an optimization. I close the issue. Thanks ;-) ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 12:09:00 2016 From: report at bugs.python.org (Christian Heimes) Date: Mon, 28 Nov 2016 17:09:00 +0000 Subject: [issue28689] OpenSSL 1.1.0c test failures In-Reply-To: <1479132647.76.0.450425015981.issue28689@psf.upfronthosting.co.za> Message-ID: <1480352940.45.0.671776859913.issue28689@psf.upfronthosting.co.za> Christian Heimes added the comment: The test suite is passing with OpenSSL 1.1.0d-dev (OpenSSL_1_1_0-stable branch). I consider 1.1.0c a broken and unsupported release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 12:15:35 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Nov 2016 17:15:35 +0000 Subject: [issue28821] generate_opcode_h.py crash when run with python2 In-Reply-To: <1480350136.76.0.0346939338673.issue28821@psf.upfronthosting.co.za> Message-ID: <1480353335.45.0.36096488339.issue28821@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't understand why do you run Tools/scripts/generate_opcode_h.py. It seems like Makefile wants to run it if Lib/opcode.py is more recent than Include/opcode.h. Can you please try the "make touch" command to not recompile Include/opcode.h? Include/opcode.h is already up to date. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 12:16:00 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 28 Nov 2016 17:16:00 +0000 Subject: [issue28821] generate_opcode_h.py crash when run with python2 In-Reply-To: <1480350136.76.0.0346939338673.issue28821@psf.upfronthosting.co.za> Message-ID: <20161128171556.13649.66189.F37EB011@psf.io> Roundup Robot added the comment: New changeset a6ea34c8b413 by Victor Stinner in branch 'default': Reintroduce Python2 support in generate_opcode_h.py https://hg.python.org/cpython/rev/a6ea34c8b413 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 12:19:03 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Nov 2016 17:19:03 +0000 Subject: [issue28821] generate_opcode_h.py crash when run with python2 In-Reply-To: <1480350136.76.0.0346939338673.issue28821@psf.upfronthosting.co.za> Message-ID: <1480353543.74.0.0249526255308.issue28821@psf.upfronthosting.co.za> STINNER Victor added the comment: Anyway, I reintroduced the Python 2, just for practical reasons :-) I knew that my change dropped Python 2 support, but I didn't notice that the Makefile might have to run the script to be able to build the ./python binary. So the script can be used on python2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 12:19:11 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Nov 2016 17:19:11 +0000 Subject: [issue28821] generate_opcode_h.py crash when run with python2 In-Reply-To: <1480350136.76.0.0346939338673.issue28821@psf.upfronthosting.co.za> Message-ID: <1480353551.25.0.309326527765.issue28821@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 12:21:16 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Nov 2016 17:21:16 +0000 Subject: [issue28288] Expose environment variable for Py_Py3kWarningFlag In-Reply-To: <1474993446.86.0.709676160725.issue28288@psf.upfronthosting.co.za> Message-ID: <1480353676.68.0.290633090599.issue28288@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What about PYTHON_OPT and allowing to pass any options via an environment variable? There is a number of precedences (gzip, less, etc). export PYTHON_OPT="-t -b -3" Or PYTHON3COMP[ATIBILITY]? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 12:23:22 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Nov 2016 17:23:22 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480353802.39.0.0502299082993.issue28754@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Sorry, I didn't follow the discussion, but why not using "/" magic separator in Argument Clinic to mark arguments as optional but don't document their default value? '/' marks positional-only arguments, not optional arguments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 12:23:31 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Nov 2016 17:23:31 +0000 Subject: [issue28799] Drop CALL_PROFILE special build? In-Reply-To: <1480064573.69.0.905508550534.issue28799@psf.upfronthosting.co.za> Message-ID: <1480353811.96.0.104265782916.issue28799@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 12:35:03 2016 From: report at bugs.python.org (Roy Williams) Date: Mon, 28 Nov 2016 17:35:03 +0000 Subject: [issue28288] Expose environment variable for Py_Py3kWarningFlag In-Reply-To: <1474993446.86.0.709676160725.issue28288@psf.upfronthosting.co.za> Message-ID: <1480354503.59.0.602273077763.issue28288@psf.upfronthosting.co.za> Roy Williams added the comment: > What about PYTHON_OPT and allowing to pass any options via an environment > > variable? There is a number of precedences (gzip, less, etc). > > export PYTHON_OPT="-t -b -3" I'd be open to this, but it seems like a much wider change than something that I'd have time to build in time for Python 2.7.12. I agree that this is a better long term direction (similarly, I'd like to enable the `-bb` flag in Python 3). I'd have to put a bunch of thought into how this would merge with command line flags. > Or PYTHON3COMP[ATIBILITY]? I'm open to whichever. lemburg had suggested `PYTHON3WARNINGS` so that's what I went with. If that's a blocker for this patch happy to change it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 12:50:08 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 28 Nov 2016 17:50:08 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1480353802.39.0.0502299082993.issue28754@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Ah right, _bisect.bisect_right() support keywords. I expected that it doesn't support keywords yet ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 13:05:11 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 28 Nov 2016 18:05:11 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1480356311.46.0.174731070958.issue28781@psf.upfronthosting.co.za> Steve Dower added the comment: Looking at those logs, it seems like we think the per-user packages are already installed. When you go to do an all-users install, it "removes" the per-user packages, but passes in the same options as it does for the all user packages. Under the hood, these packages are actually identical, and we run them with different options depending on what sort of install you're doing. One of these options is the install directory. When we install the all users package to C:\Program Files, then remove the per user package from C:\Program Files, it's actually just removing itself immediately. I *think* the best way to deal with this, given that running the msiexec commands didn't work, is to do a Just for Me install first, and then uninstall that and do the All Users install. --- You can see in the main log file lines like this: [1B20:05AC][2016-11-28T11:44:53]i301: Applying execute package: core_AllUsers, action: Install, path: C:\ProgramData\Package Cache\{EB0611B2-7F10-4D97-BCF2-DCAAB1199498}v3.5.2150.0\core.msi, arguments: ' ALLUSERS="1" ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program Files\Python35-32\" OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.5-32\InstalledFeatures"' [1064:274C][2016-11-28T11:44:59]i319: Applied execute package: core_AllUsers, result: 0x0, restart: None [1064:274C][2016-11-28T11:44:59]i329: Removed package dependency provider: {EB0611B2-7F10-4D97-BCF2-DCAAB1199498}, package: core_JustForMe [1064:274C][2016-11-28T11:44:59]i301: Applying execute package: core_JustForMe, action: Uninstall, path: (null), arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program Files\Python35-32\" OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.5-32\InstalledFeatures"' [1064:274C][2016-11-28T11:44:59]i319: Applied execute package: core_JustForMe, result: 0x0, restart: None Notice that the package names (core_AllUsers, core_JustForMe) are different, but TARGETDIR is the same. It also seems that the packages are always ordered all users first - possibly this issue could be avoided if we did not interleave the packages, though you'd likely still not get a working install at the end. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 13:09:40 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 28 Nov 2016 18:09:40 +0000 Subject: [issue28288] Expose environment variable for Py_Py3kWarningFlag In-Reply-To: <1474993446.86.0.709676160725.issue28288@psf.upfronthosting.co.za> Message-ID: <1480356580.02.0.843573662381.issue28288@psf.upfronthosting.co.za> Brett Cannon added the comment: I agree with Roy: while PYTHON_OPT might be nice long-term, I think that scopes it beyond a py3k change in Python 2.7 and into new feature territory. As for a better name, PY3KWARNINGS is also possible and minimizes typo issues if that's what people are worried about. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 13:17:30 2016 From: report at bugs.python.org (Brett Cannon) Date: Mon, 28 Nov 2016 18:17:30 +0000 Subject: [issue28288] Expose environment variable for Py_Py3kWarningFlag In-Reply-To: <1474993446.86.0.709676160725.issue28288@psf.upfronthosting.co.za> Message-ID: <1480357050.44.0.277358710173.issue28288@psf.upfronthosting.co.za> Brett Cannon added the comment: Benjamin just announced 2.7.13rc1 is going to be Dec 3, so this patch needs to land before then if it's going to make it in the next release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 13:31:46 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 28 Nov 2016 18:31:46 +0000 Subject: [issue28288] Expose environment variable for Py_Py3kWarningFlag In-Reply-To: <1474993446.86.0.709676160725.issue28288@psf.upfronthosting.co.za> Message-ID: <1480357906.78.0.94413834019.issue28288@psf.upfronthosting.co.za> Berker Peksag added the comment: I can commit the patch this week if there are no objections to the name of the variable. I like Brett's PY3KWARNINGS suggestion, but I'm fine with either of the suggested names. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 13:55:46 2016 From: report at bugs.python.org (tzickel) Date: Mon, 28 Nov 2016 18:55:46 +0000 Subject: [issue28824] os.environ should preserve the case of the OS keys ? Message-ID: <1480359346.4.0.287394822331.issue28824@psf.upfronthosting.co.za> New submission from tzickel: In Windows, python's os.environ currently handles the case sensitivity different that the OS. While it's true that the OS is case insensitive, it does preserve the case that you first set it as. For example: C:\Users\user>set aSD=Blah C:\Users\user>set asd aSD=Blah But in python: >>> import os >>> 'aSD' in os.environ.keys() False Today as more people pass environment variables to processes, it's better to behave as the OS does. Basically I think that os.environ (both in 2.7 and 3) should preserve the case as well (for when you need to access / iterate over the keys or set a key), but ignore it when you get a key. https://github.com/python/cpython/blob/b82a5a65caa5b0f0efccaf2bbea94f1eba19a54d/Lib/os.py#L733 ---------- components: Windows messages: 281906 nosy: larry, loewis, paul.moore, steve.dower, tim.golden, tzickel, zach.ware priority: normal severity: normal status: open title: os.environ should preserve the case of the OS keys ? versions: Python 2.7, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 13:56:54 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 28 Nov 2016 18:56:54 +0000 Subject: [issue28823] Simplify compiling to BUILD_MAP_UNPACK In-Reply-To: <1480351509.39.0.820702291303.issue28823@psf.upfronthosting.co.za> Message-ID: <20161128185651.13624.96771.41124A1C@psf.io> Roundup Robot added the comment: New changeset 9ded2433dc2c by Serhiy Storchaka in branch 'default': Issue #28823: Simplified compiling with opcode BUILD_MAP_UNPACK. https://hg.python.org/cpython/rev/9ded2433dc2c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 13:58:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Nov 2016 18:58:12 +0000 Subject: [issue28823] Simplify compiling to BUILD_MAP_UNPACK In-Reply-To: <1480351509.39.0.820702291303.issue28823@psf.upfronthosting.co.za> Message-ID: <1480359492.92.0.418228192999.issue28823@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Yury. Simplifying the code was the main purpose. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 14:03:39 2016 From: report at bugs.python.org (R. David Murray) Date: Mon, 28 Nov 2016 19:03:39 +0000 Subject: [issue28824] os.environ should preserve the case of the OS keys ? In-Reply-To: <1480359346.4.0.287394822331.issue28824@psf.upfronthosting.co.za> Message-ID: <1480359819.24.0.161745439852.issue28824@psf.upfronthosting.co.za> R. David Murray added the comment: That unfortunately would probably break existing code. It does seem reasonable that case should be ignored on get, though, if the OS does so. So making your 'in' statement work might be acceptable, backward compatibility wise. Probably only in 3.7, though. Is it the OS that ignores case, or just the shell? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 14:11:48 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 28 Nov 2016 19:11:48 +0000 Subject: [issue28824] os.environ should preserve the case of the OS keys ? In-Reply-To: <1480359346.4.0.287394822331.issue28824@psf.upfronthosting.co.za> Message-ID: <1480360308.58.0.0237419734579.issue28824@psf.upfronthosting.co.za> Steve Dower added the comment: This works fine in Python 3, and also Python 2.7 *unless* you call .keys(). PS D:\> py -2.7 Python 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:24:40) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> 'path' in os.environ, 'path' in os.environ.keys() (True, False) PS D:\> py Python 3.6.0b4 (default, Nov 22 2016, 05:30:12) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> 'path' in os.environ, 'path' in os.environ.keys() (True, True) I suspect at this point, we aren't going to change this in Python 2.7 unless someone comes up with an incredibly motivating issue. ---------- versions: -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 14:17:08 2016 From: report at bugs.python.org (Victor Porton) Date: Mon, 28 Nov 2016 19:17:08 +0000 Subject: [issue28825] socket.SO_KEEPALIVE does not work on FreeBSD Message-ID: <1480360628.41.0.790647323663.issue28825@psf.upfronthosting.co.za> New submission from Victor Porton: When I connect telnet XXX 9000 to the server in attached file, the connection breaks after 5 min (and a few seconds), as if SO_KEEPALIVE were not specified. I run my server on FreeBSD 9.2-RELEASE-p15 (GENERIC) So SO_KEEPALIVE does not work in Python 2.7 and 3.5 on FreeBSD. Specifically, I need my TCP connection not to break in extended periods of time and cannot do this with Python. It seems that similar code does work with PHP (I am going to write a short PHP example), so it is likely a Python bug, not FreeBSD bug. ---------- components: FreeBSD, IO, Library (Lib) files: bug.py messages: 281911 nosy: koobs, porton priority: normal severity: normal status: open title: socket.SO_KEEPALIVE does not work on FreeBSD type: behavior versions: Python 2.7, Python 3.5 Added file: http://bugs.python.org/file45677/bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 14:29:04 2016 From: report at bugs.python.org (tzickel) Date: Mon, 28 Nov 2016 19:29:04 +0000 Subject: [issue28824] os.environ should preserve the case of the OS keys ? In-Reply-To: <1480359346.4.0.287394822331.issue28824@psf.upfronthosting.co.za> Message-ID: <1480361344.57.0.850258146435.issue28824@psf.upfronthosting.co.za> tzickel added the comment: My issue is that somebody wants to pass a few dict like environment variables as some prefix_key=value but he wants to preserve the case of the key for usage in python so the .keys() space needs to be enumerated. A workaround for this issue can be importing nt and using nt.environ which preserves the cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 14:43:42 2016 From: report at bugs.python.org (Victor Porton) Date: Mon, 28 Nov 2016 19:43:42 +0000 Subject: [issue28825] socket.SO_KEEPALIVE does not work on FreeBSD In-Reply-To: <1480360628.41.0.790647323663.issue28825@psf.upfronthosting.co.za> Message-ID: <1480362222.8.0.629352359476.issue28825@psf.upfronthosting.co.za> Victor Porton added the comment: Weird, after I minimized the PHP example, it also has the same bug as the Python one. (The real long code in PHP was working without this bug.) I attach the PHP code for your reference. Maybe it is a FreeBSD bug? Please write to porton at narod.ru with advice how to make the server not to disconnect after 5 minutes of idle connection. ---------- Added file: http://bugs.python.org/file45678/bug.php _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 15:35:54 2016 From: report at bugs.python.org (Eryk Sun) Date: Mon, 28 Nov 2016 20:35:54 +0000 Subject: [issue28824] os.environ should preserve the case of the OS keys ? In-Reply-To: <1480359346.4.0.287394822331.issue28824@psf.upfronthosting.co.za> Message-ID: <1480365354.67.0.893338813396.issue28824@psf.upfronthosting.co.za> Eryk Sun added the comment: I've come across a few problems when passing a modified os.environ.copy() to a child process via subprocess.Popen. Ideally it shouldn't be an issue, as long as the OS or C runtime functions are used, but some troublesome programs do their own case-sensitive search for environment variables (definitely a bug). In such cases the simplest workaround is to use nt.environ.copy(), but this doesn't include any changes in the environment since startup. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 15:39:59 2016 From: report at bugs.python.org (tzickel) Date: Mon, 28 Nov 2016 20:39:59 +0000 Subject: [issue28824] os.environ should preserve the case of the OS keys ? In-Reply-To: <1480359346.4.0.287394822331.issue28824@psf.upfronthosting.co.za> Message-ID: <1480365599.29.0.615811671415.issue28824@psf.upfronthosting.co.za> tzickel added the comment: Steve, I've checked in Python 3.5.2, and os.environ.keys() still uppercases everything when scanning (for my use case). Has it changed since then ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 16:15:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Nov 2016 21:15:12 +0000 Subject: [issue24469] Py2.x int free list can grow without bounds In-Reply-To: <1434695478.8.0.352869011826.issue24469@psf.upfronthosting.co.za> Message-ID: <1480367712.46.0.392832051675.issue24469@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It seems to me, that all builtin and extension types set tp_free to PyObject_Del, PyObject_GC_Del, or 0. The int class is the only exception. int_free() was introduced in 200559fcc664: > Make sure that tp_free frees the int the same way as tp_dealloc would. > This fixes the problem that Barry reported on python-dev: > >>> 23000 .__class__ = bool > crashes in the deallocator. This was because int inherited tp_free > from object, which uses the default allocator. The above example no longer works: >>> 23000 .__class__ = bool Traceback (most recent call last): File "", line 1, in TypeError: __class__ assignment: only for heap types I think int_free should be removed and tp_free should be reverted to 0 (as in float type). ---------- assignee: -> serhiy.storchaka keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file45679/int-tp_free-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 16:34:09 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 28 Nov 2016 21:34:09 +0000 Subject: [issue24469] Py2.x int free list can grow without bounds In-Reply-To: <1480367712.46.0.392832051675.issue24469@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: OK, SGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 16:35:42 2016 From: report at bugs.python.org (Decorater) Date: Mon, 28 Nov 2016 21:35:42 +0000 Subject: [issue28816] Document if zipimport can respect import hooks to load custom files from zip. In-Reply-To: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za> Message-ID: <1480368942.71.0.1338760205.issue28816@psf.upfronthosting.co.za> Changes by Decorater : ---------- nosy: -brett.cannon, eric.snow, ncoghlan, paul.moore, tim.golden, twouters, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 16:38:02 2016 From: report at bugs.python.org (Decorater) Date: Mon, 28 Nov 2016 21:38:02 +0000 Subject: [issue28816] Document if zipimport can respect import hooks to load custom files from zip. In-Reply-To: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za> Message-ID: <1480369082.96.0.0968578657042.issue28816@psf.upfronthosting.co.za> Changes by Decorater : ---------- nosy: +twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 16:38:12 2016 From: report at bugs.python.org (Steve Dower) Date: Mon, 28 Nov 2016 21:38:12 +0000 Subject: [issue28824] os.environ should preserve the case of the OS keys ? In-Reply-To: <1480359346.4.0.287394822331.issue28824@psf.upfronthosting.co.za> Message-ID: <1480369092.79.0.152938927454.issue28824@psf.upfronthosting.co.za> Steve Dower added the comment: Ah, I see what you mean. In this case, we could change how the case-insensitivity is handled here, but it would only be applicable to 3.7. I'm not opposed to changing the default behavior here, but it does kind of bring up the mapping dict discussion again. If case is important to your application, environment variables are probably the wrong way to go about passing them in anyway. Either use the value of the variable rather than the key, or find a different approach. Given 'nt.environ' is available without case remapping, I think that's the best workaround. ---------- versions: +Python 3.7 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 17:04:44 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Mon, 28 Nov 2016 22:04:44 +0000 Subject: [issue28818] simplify lookdict functions In-Reply-To: <1480331020.89.0.515440713784.issue28818@psf.upfronthosting.co.za> Message-ID: <1480370684.44.0.183214084909.issue28818@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 17:12:29 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Mon, 28 Nov 2016 22:12:29 +0000 Subject: [issue14845] list() != [] In-Reply-To: <1337294857.69.0.824992743087.issue14845@psf.upfronthosting.co.za> Message-ID: <1480371149.27.0.246720463638.issue14845@psf.upfronthosting.co.za> Wolfgang Maier added the comment: Isn't the difference between generator expressions and comprehensions what's dealt with by PEP479? So it seems this issue is outdated enough to deserve being closed? ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 17:18:39 2016 From: report at bugs.python.org (Big Stone) Date: Mon, 28 Nov 2016 22:18:39 +0000 Subject: [issue28791] update sqlite to 3.15.2 In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1480371519.29.0.771572467815.issue28791@psf.upfronthosting.co.za> Big Stone added the comment: too late for sqlite-0.15.2 in Python-3.6.0rc ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 17:22:18 2016 From: report at bugs.python.org (Allen David Frankel) Date: Mon, 28 Nov 2016 22:22:18 +0000 Subject: [issue28826] Programming with Python 3.6 Message-ID: <1480371738.23.0.459754503807.issue28826@psf.upfronthosting.co.za> New submission from Allen David Frankel: On the Python Tutorial for beginners, the Python 3.6 gives me a syntax error with strings and does not respond to print and/or nothing comes up. ---------- components: Demos and Tools messages: 281921 nosy: ADFGUR priority: normal severity: normal status: open title: Programming with Python 3.6 type: performance versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 18:04:26 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Mon, 28 Nov 2016 23:04:26 +0000 Subject: [issue28826] Programming with Python 3.6 In-Reply-To: <1480371738.23.0.459754503807.issue28826@psf.upfronthosting.co.za> Message-ID: <1480374266.41.0.11920419845.issue28826@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Maybe you can post your code snippet and the error? ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 18:30:01 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 28 Nov 2016 23:30:01 +0000 Subject: [issue28820] Typo in section 6 of the Python 3.4 documentation In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za> Message-ID: <1480375801.62.0.430795656764.issue28820@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks, this looks good to me, although let?s not touch the blank line at the end of the file. ---------- nosy: +martin.panter stage: -> commit review versions: +Python 2.7, Python 3.5, Python 3.6, Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 18:31:48 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Nov 2016 23:31:48 +0000 Subject: [issue21134] Segfault when stringifying UnicodeEncodeError (or UnicodeDecodeError) created with __new__() In-Reply-To: <1396447837.72.0.201261233456.issue21134@psf.upfronthosting.co.za> Message-ID: <1480375908.11.0.889434007006.issue21134@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 18:35:56 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 28 Nov 2016 23:35:56 +0000 Subject: [issue19159] 2to3 incorrectly converts two parameter unicode() constructor to str() In-Reply-To: <1380848221.34.0.113318109219.issue19159@psf.upfronthosting.co.za> Message-ID: <1480376156.41.0.299966896962.issue19159@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 19:24:42 2016 From: report at bugs.python.org (Eric N. Vander Weele) Date: Tue, 29 Nov 2016 00:24:42 +0000 Subject: [issue18235] _sysconfigdata.py wrong on AIX installations In-Reply-To: <1371429201.94.0.372851990361.issue18235@psf.upfronthosting.co.za> Message-ID: <1480379082.19.0.248264937654.issue18235@psf.upfronthosting.co.za> Changes by Eric N. Vander Weele : ---------- nosy: +ericvw _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 19:26:26 2016 From: report at bugs.python.org (Eric N. Vander Weele) Date: Tue, 29 Nov 2016 00:26:26 +0000 Subject: [issue27632] build on AIX fails when builddir != srcdir, more than bad path to ld_so_aix In-Reply-To: <1469608112.86.0.803958819971.issue27632@psf.upfronthosting.co.za> Message-ID: <1480379186.39.0.216312148157.issue27632@psf.upfronthosting.co.za> Changes by Eric N. Vander Weele : ---------- nosy: +ericvw _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 19:31:38 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 29 Nov 2016 00:31:38 +0000 Subject: [issue28827] f-strings: format spec should not accept unicode escapes Message-ID: <1480379497.98.0.444236262661.issue28827@psf.upfronthosting.co.za> New submission from Yury Selivanov: Right now, Python 3.6b4 happily accepts the following: >>> f'{10:02\N{LATIN CAPITAL LETTER X}}' '0A' >>> f'{10:02X}' '0A' I think that the first line should not be accepted (as we now don't accept escaped open curly brace). At least this should be documented in the PEP as a thing that shouldn't be relied upon, i.e. something that might not be supported in the future versions. ---------- components: Interpreter Core messages: 281924 nosy: eric.smith, gvanrossum, serhiy.storchaka, yselivanov priority: normal severity: normal status: open title: f-strings: format spec should not accept unicode escapes type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 19:35:32 2016 From: report at bugs.python.org (Decorater) Date: Tue, 29 Nov 2016 00:35:32 +0000 Subject: [issue28816] Document if zipimport can respect import hooks to load custom files from zip. In-Reply-To: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za> Message-ID: <1480379732.85.0.946611814105.issue28816@psf.upfronthosting.co.za> Changes by Decorater : ---------- nosy: +brett.cannon, eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 19:37:06 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 29 Nov 2016 00:37:06 +0000 Subject: [issue28827] f-strings: format spec should not accept unicode escapes In-Reply-To: <1480379497.98.0.444236262661.issue28827@psf.upfronthosting.co.za> Message-ID: <1480379826.72.0.392697960351.issue28827@psf.upfronthosting.co.za> Yury Selivanov added the comment: Also this inconsistency: we already don't accept escaped letters after `!`: >>> f'{min!\N{LATIN SMALL LETTER R}}' File "", line 1 SyntaxError: f-string: invalid conversion character: expected 's', 'r', or 'a' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 20:01:44 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 29 Nov 2016 01:01:44 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480381304.71.0.255281457993.issue28754@psf.upfronthosting.co.za> Martin Panter added the comment: Regarding the problem with the default value, can we use ?unspecified?, as documented at , or is that an old relic that no longer exists (hinted at the end of Issue 20293)? Failing that, I prefer Raymond?s earlier suggestion: say that any support for ?1 or None are implementation details, and not part of the API. The same statement could be added to the native Python doc strings as well. BTW I am not opposed to the proposal for proper hi=None support either, although it does complicate the change. IMO allowing hi=None could be done as a second step. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 20:11:51 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 29 Nov 2016 01:11:51 +0000 Subject: [issue28827] f-strings: format spec should not accept unicode escapes In-Reply-To: <1480379497.98.0.444236262661.issue28827@psf.upfronthosting.co.za> Message-ID: <1480381911.56.0.521774530759.issue28827@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t have Py 3.6 to test on, but won?t that make it unnecessarily inconvenient to use certain format codes? I.e. codes that involve non-ASCII characters, control codes, quote signs, or backslashes. Slightly silly use case: >>> "The time is {:%I\N{DEGREE SIGN} %M\N{PRIME} %S\N{DOUBLE PRIME} %p}".format(datetime.datetime.now()) 'The time is 01? 07? 41? AM' ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 20:13:51 2016 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 29 Nov 2016 01:13:51 +0000 Subject: [issue28827] f-strings: format spec should not accept unicode escapes In-Reply-To: <1480379497.98.0.444236262661.issue28827@psf.upfronthosting.co.za> Message-ID: <1480382031.72.0.783551723103.issue28827@psf.upfronthosting.co.za> Eric V. Smith added the comment: I think this is documented. This is a result of supported nested expressions in the format_spec: >>> an_x = "X" >>> f'{10:02{an_x}}' '0A' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 20:23:30 2016 From: report at bugs.python.org (Decorater) Date: Tue, 29 Nov 2016 01:23:30 +0000 Subject: [issue28827] f-strings: format spec should not accept unicode escapes In-Reply-To: <1480379497.98.0.444236262661.issue28827@psf.upfronthosting.co.za> Message-ID: <1480382610.38.0.203422179752.issue28827@psf.upfronthosting.co.za> Decorater added the comment: there is also the most common. '{10:02{0}}'.format(an_x) ---------- nosy: +Decorater _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 20:24:24 2016 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 29 Nov 2016 01:24:24 +0000 Subject: [issue28827] f-strings: format spec should not accept unicode escapes In-Reply-To: <1480379497.98.0.444236262661.issue28827@psf.upfronthosting.co.za> Message-ID: <1480382664.42.0.477669949614.issue28827@psf.upfronthosting.co.za> Eric V. Smith added the comment: Specifically, see: https://www.python.org/dev/peps/pep-0498/#format-specifiers str.format() also works this way: >>> '{0:02{1}}'.format(10, an_x) '0A' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 20:45:32 2016 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 29 Nov 2016 01:45:32 +0000 Subject: [issue17038] multiprocessing only use one core when C module are imported In-Reply-To: <1359193163.5.0.985528068255.issue17038@psf.upfronthosting.co.za> Message-ID: <1480383932.44.0.991282679084.issue17038@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Ended up here by accident. For whoever bumps into this same issue, psutil allows to get an set CPU affinity, so you can avoid using taskset. >>> import psutil >>> psutil.cpu_count() 4 >>> p = psutil.Process() >>> p.cpu_affinity() # get [0, 1, 2, 3] >>> p.cpu_affinity([0]) # set; from now on, process will run on CPU #0 only >>> p.cpu_affinity() [0] >>> >>> # reset affinity against all CPUs >>> all_cpus = list(range(psutil.cpu_count())) >>> p.cpu_affinity(all_cpus) >>> ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 21:21:07 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 29 Nov 2016 02:21:07 +0000 Subject: [issue14845] list() != [] In-Reply-To: <1337294857.69.0.824992743087.issue14845@psf.upfronthosting.co.za> Message-ID: <1480386067.73.0.412670550575.issue14845@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 21:22:56 2016 From: report at bugs.python.org (Rohit Khairnar) Date: Tue, 29 Nov 2016 02:22:56 +0000 Subject: [issue28828] Connection reset by peer error when installing python packages Message-ID: <1480386176.32.0.070663406061.issue28828@psf.upfronthosting.co.za> New submission from Rohit Khairnar: We are seeing intermittent "connection reset by peer" connecting to pypi.python.org. Pip install "connection reset by peer" I am a Network Engineer at Hulu and our Devs are seeing error 104 connection resets by peer errors. We thought it was a firewall issue but even after upgrading it we are still seeing the issues. I can get more details from Devs if needed. regards, Rohit ---------- components: Build files: pypi.pcap messages: 281932 nosy: Rohit Khairnar priority: normal severity: normal status: open title: Connection reset by peer error when installing python packages type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file45680/pypi.pcap _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 21:39:58 2016 From: report at bugs.python.org (Decorater) Date: Tue, 29 Nov 2016 02:39:58 +0000 Subject: [issue28828] Connection reset by peer error when installing python packages In-Reply-To: <1480386176.32.0.070663406061.issue28828@psf.upfronthosting.co.za> Message-ID: <1480387198.32.0.981769544524.issue28828@psf.upfronthosting.co.za> Decorater added the comment: Try using the new pypi instead: https://pypi.org/ locate the package then override pip to look for that package with the direct link to find the package with a command line arg of : -f ex: pip3 install -f [direct url to pypi page to package in question here] According to pip's documentation is says this about -f If a url or path to an html file, then parse for links to archives. If a local path or file:// url that's a directory, then look for archives in the directory listing. Hope this helps. ---------- nosy: +Decorater _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 21:42:04 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 29 Nov 2016 02:42:04 +0000 Subject: [issue28808] Make PyUnicode_CompareWithASCIIString() never failing In-Reply-To: <1480175314.71.0.35688135657.issue28808@psf.upfronthosting.co.za> Message-ID: <1480387324.73.0.579736648672.issue28808@psf.upfronthosting.co.za> Ned Deily added the comment: I'd like @haypo to review and approve this change as well since he was involved in the predecessor (Issue28701). Victor? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 21:42:30 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 29 Nov 2016 02:42:30 +0000 Subject: [issue28808] Make PyUnicode_CompareWithASCIIString() never failing In-Reply-To: <1480175314.71.0.35688135657.issue28808@psf.upfronthosting.co.za> Message-ID: <1480387350.23.0.549625151593.issue28808@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +larry priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 21:45:47 2016 From: report at bugs.python.org (Decorater) Date: Tue, 29 Nov 2016 02:45:47 +0000 Subject: [issue28828] Connection reset by peer error when installing python packages In-Reply-To: <1480386176.32.0.070663406061.issue28828@psf.upfronthosting.co.za> Message-ID: <1480387547.93.0.68216195055.issue28828@psf.upfronthosting.co.za> Decorater added the comment: Also why python 2.7? Python 2.7 does not include asyncio which is absolutely awesome to use. It can allow doing multiple different things at the same time. So, it is and will be a good thing to upgrade. Note: a lot of things since 2.7 and 3.x was removed (some exception classes included). But after the change you should be fine. Note print from python 2 is a function in python 3.x. Not only that but 2.x would reach EOL on about 2020 and with it security updates for it would close. All the more reasons to use 3.6 when it is released officially. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 21:56:36 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 29 Nov 2016 02:56:36 +0000 Subject: [issue28782] SEGFAULT when running a given coroutine In-Reply-To: <1479924207.48.0.511908736136.issue28782@psf.upfronthosting.co.za> Message-ID: <1480388196.82.0.7652155568.issue28782@psf.upfronthosting.co.za> Ned Deily added the comment: (Victor also merged this into default branch for 3.7.0 in 6453ff3328b8) ---------- priority: release blocker -> stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 22:00:00 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 29 Nov 2016 03:00:00 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1480388400.77.0.189144521172.issue15533@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +paul.moore, steve.dower, tim.golden, zach.ware versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 22:01:03 2016 From: report at bugs.python.org (Emanuel Barry) Date: Tue, 29 Nov 2016 03:01:03 +0000 Subject: [issue28828] Connection reset by peer error when installing python packages In-Reply-To: <1480386176.32.0.070663406061.issue28828@psf.upfronthosting.co.za> Message-ID: <1480388463.55.0.412310309749.issue28828@psf.upfronthosting.co.za> Emanuel Barry added the comment: Decorater: For very large projects, the switch from Python 2 to 3 is a non-trivial task that can take up years of work, and there are many reasons why one cannot switch. On the issue, however, for all PyPi-related issues, please go to the PyPa GitHub: https://github.com/pypa/pypi-legacy/ ---------- nosy: +ebarry resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 22:09:51 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 29 Nov 2016 03:09:51 +0000 Subject: [issue28822] Fix indices handling in PyUnicode_FindChar In-Reply-To: <1480350558.9.0.582516213925.issue28822@psf.upfronthosting.co.za> Message-ID: <1480388991.97.0.0120474056253.issue28822@psf.upfronthosting.co.za> Xiang Zhang added the comment: Other APIs like PyUnicode_Find and PyUnicode_Count support it. Their docs are almost the same so I think PyUnicode_FindChar does not need to be the special one. After change, its behaviour and implementation are more consistent with other APIs. ---------- versions: -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 22:10:54 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 29 Nov 2016 03:10:54 +0000 Subject: [issue28797] Modifying class __dict__ inside __set_name__ In-Reply-To: <1480042109.13.0.341330811366.issue28797@psf.upfronthosting.co.za> Message-ID: <1480389054.96.0.0202062014723.issue28797@psf.upfronthosting.co.za> Ned Deily added the comment: Nick, as the original shepherd of PEP 487 (Issue27366), can you review Serhiy's proposed patch for 3.6.0rc1? Thanks! ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 22:35:59 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 29 Nov 2016 03:35:59 +0000 Subject: [issue28790] Error when using Generic and __slots__ In-Reply-To: <1480017847.05.0.904574090231.issue28790@psf.upfronthosting.co.za> Message-ID: <1480390559.6.0.370076598389.issue28790@psf.upfronthosting.co.za> Ned Deily added the comment: I don't have a good sense of the severity of this issue but it doesn't seem like it qualifies as release critical. On the other hand, the changes are isolated to typing and typing is more fluid than older, more established modules. If you think it should go in 3.6.0rc1, I won't object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 22:37:15 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 29 Nov 2016 03:37:15 +0000 Subject: [issue28773] typing.FrozenSet missing in documentation. In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za> Message-ID: <1480390635.11.0.624482112761.issue28773@psf.upfronthosting.co.za> Ned Deily added the comment: > Is that the right procedure still? Yes, thanks! ---------- stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 22:45:41 2016 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 29 Nov 2016 03:45:41 +0000 Subject: [issue28797] Modifying class __dict__ inside __set_name__ In-Reply-To: <1480042109.13.0.341330811366.issue28797@psf.upfronthosting.co.za> Message-ID: <1480391141.65.0.895420067872.issue28797@psf.upfronthosting.co.za> Nick Coghlan added the comment: Rather than taking a snapshot of the whole class namespace, I think it will make more sense to make a new empty dictionary of descriptors to notify, and then split the current loop into two loops: - the first loop adds descriptors with __set_name__ attributes to the notification dict - the second loop calls __set_name__ on all the descriptors in the notification dict Serhiy's patch effectively already does that via the initial PyDict_Copy, but that approach also redundantly copies items that don't define __set_name__ into the snapshot and then filters them out on the second pass. Reviewing the patch also made me realise we're currently missing a specification of the expected behaviour in https://docs.python.org/dev/reference/datamodel.html#creating-the-class-object. I suggest adding the following paragraph between the one about setting __class__ and the one about calling class descriptors: """ When using the default metaclass :cls:`type`, or any metaclass that ultimately calls ``type.__new__``, the following additional customisation steps are invoked: * first, ``type.__new__`` collects all of the descriptors in the class namespace that define a ``__set_name__`` method * second, all of these ``__set_name__`` methods are called with the class being defined and the assigned name of that particular descriptor * finally, the ``__init_subclass__`` hook is called on the immediate parent of the new class in its method resolution order """ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 22:55:31 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 29 Nov 2016 03:55:31 +0000 Subject: [issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za> Message-ID: <1480391731.97.0.0456358492603.issue28450@psf.upfronthosting.co.za> Ned Deily added the comment: Where do we stand on this issue? At the moment, 3.6.0 is on track to be released as is. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 23:09:33 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 29 Nov 2016 04:09:33 +0000 Subject: [issue27945] Various segfaults with dict In-Reply-To: <1472852008.61.0.354257945943.issue27945@psf.upfronthosting.co.za> Message-ID: <1480392573.23.0.928254774779.issue27945@psf.upfronthosting.co.za> Ned Deily added the comment: Where do we stand on this issue? At the moment, 3.6.0 is going to be released without these fixes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 23:47:31 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 04:47:31 +0000 Subject: [issue28797] Modifying class __dict__ inside __set_name__ In-Reply-To: <1480042109.13.0.341330811366.issue28797@psf.upfronthosting.co.za> Message-ID: <1480394851.73.0.922554571195.issue28797@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I considered this option, but if save only descriptors with the __set_name__ attribute, this would need either double looking up the __set_name__ attribute or packing it in a tuple with a value. All this too cumbersome. I chose copying all dictionary as the simplest way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 28 23:58:23 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 04:58:23 +0000 Subject: [issue27945] Various segfaults with dict In-Reply-To: <1472852008.61.0.354257945943.issue27945@psf.upfronthosting.co.za> Message-ID: <1480395503.72.0.812637781054.issue27945@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This issue is severe, but I don't consider it as release critical for 3.6.0. The patch fixes segfaults, but it can add unneeded overhead, and the dict performance is critical for Python core. The segfaults are not new. I'm trying to minimize the overhead of changes, but this doesn't suffer a haste. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 00:02:15 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 05:02:15 +0000 Subject: [issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za> Message-ID: <1480395735.2.0.599122284314.issue28450@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think we should discuss this on Python-Dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 00:21:01 2016 From: report at bugs.python.org (Davin Potts) Date: Tue, 29 Nov 2016 05:21:01 +0000 Subject: [issue28779] set_forkserver_preload() can crash the forkserver if preloaded module instantiate multiprocessing classes In-Reply-To: <1479914801.47.0.114591938702.issue28779@psf.upfronthosting.co.za> Message-ID: <1480396861.88.0.960992647071.issue28779@psf.upfronthosting.co.za> Davin Potts added the comment: I don't see any negative consequences for the helpers if the `force=True` is made in spawn.prepare's invocation of set_start_method(). In tracing backwards to figure out why this wasn't done already, it seems unchanged since sbt's patch in issue18999. This change may impact users of execution-bundling tools like cx-freeze -- issue22255 suggests this could make freezing things easier for some. I admit I don't fully appreciate the details of how these tools are implemented. > (that said, if you think this is out of scope for this issue, I can revert that part of the patch) Given the nature of BaseContext's implementation, I don't see a problem with keeping your change. In case I was missing something, I spent some time searching for code possibly depending upon BaseContext.set_start_method's calling arguments but turned up nothing (no surprises). It feels cleaner to update it to be in sync with DefaultContext. Overall, LGTM the way you have it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 00:27:05 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 29 Nov 2016 05:27:05 +0000 Subject: [issue5225] OS X "Update Shell Profile" may not update $PATH if run more than once In-Reply-To: <1234440346.58.0.444916712806.issue5225@psf.upfronthosting.co.za> Message-ID: <1480397225.39.0.410075013345.issue5225@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- resolution: out of date -> stage: -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 01:06:34 2016 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 29 Nov 2016 06:06:34 +0000 Subject: [issue28797] Modifying class __dict__ inside __set_name__ In-Reply-To: <1480042109.13.0.341330811366.issue28797@psf.upfronthosting.co.za> Message-ID: <1480399594.75.0.616941586554.issue28797@psf.upfronthosting.co.za> Nick Coghlan added the comment: I was thinking that the notification dict could consist of mappings from attribute names to already bound __set_name__ methods, so the double lookup would be avoided that way (but hadn't actually sent the review where I suggested that). That is, on the second loop, the actual method call would be: tmp = PyObject_CallFunctionObjArgs(value, type, key, NULL); Have I missed something that would prevent that from working? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 01:46:22 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 06:46:22 +0000 Subject: [issue28797] Modifying class __dict__ inside __set_name__ In-Reply-To: <1480042109.13.0.341330811366.issue28797@psf.upfronthosting.co.za> Message-ID: <1480401982.99.0.853993069282.issue28797@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Have I missed something that would prevent that from working? Error message contains value->ob_type->tp_name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 01:56:30 2016 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 29 Nov 2016 06:56:30 +0000 Subject: [issue28797] Modifying class __dict__ inside __set_name__ In-Reply-To: <1480042109.13.0.341330811366.issue28797@psf.upfronthosting.co.za> Message-ID: <1480402590.98.0.873024229415.issue28797@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ah, I'd missed that. In that case, I think my suggestion to change the name of the local variable is still valid, while the specific approach just needs a comment saying it's handled as a full namespace snapshot so the descriptor type name can be reported in any error messages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 02:05:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 07:05:37 +0000 Subject: [issue28797] Modifying class __dict__ inside __set_name__ In-Reply-To: <1480042109.13.0.341330811366.issue28797@psf.upfronthosting.co.za> Message-ID: <1480403137.21.0.995496137955.issue28797@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is much more complex patch that implements Nick's suggestion. ---------- Added file: http://bugs.python.org/file45681/set_name-filtered-copy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 02:22:31 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 29 Nov 2016 07:22:31 +0000 Subject: [issue28818] simplify lookdict functions In-Reply-To: <1480331020.89.0.515440713784.issue28818@psf.upfronthosting.co.za> Message-ID: <1480404151.76.0.75408017822.issue28818@psf.upfronthosting.co.za> INADA Naoki added the comment: > Can you make the patch without the unnecessary variable name change from "value_addr" to "pvalue". The former name is more communicative and is self-describing. Done. I have changed the variable name to distinguish `PyObject**` with `PyObject***`. But there are no meaning for now because I removed all `PyObject ***`. ---------- Added file: http://bugs.python.org/file45682/simplify-lookdict2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 02:30:25 2016 From: report at bugs.python.org (Martin Teichmann) Date: Tue, 29 Nov 2016 07:30:25 +0000 Subject: [issue28797] Modifying class __dict__ inside __set_name__ In-Reply-To: <1480042109.13.0.341330811366.issue28797@psf.upfronthosting.co.za> Message-ID: <1480404625.19.0.194382434381.issue28797@psf.upfronthosting.co.za> Martin Teichmann added the comment: I personally prefer the first patch, which iterates over a copy of __dict__. Making a copy of a dict is actually a pretty fast operation, I would even expect that it is faster than the proposed alternative, creating tuples. Even if the second approach should be faster, the added code complexity is not worth the effort, as this is a code path where speed shouldn't matter much. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 02:31:45 2016 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 29 Nov 2016 07:31:45 +0000 Subject: [issue28797] Modifying class __dict__ inside __set_name__ In-Reply-To: <1480042109.13.0.341330811366.issue28797@psf.upfronthosting.co.za> Message-ID: <1480404705.42.0.926804142141.issue28797@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'd be OK with starting with the simpler patch, and only looking at the more complex one if the benchmark suite shows a significant slowdown (I'd be surprised if it did, as it should mainly impact start-up, and class dicts generally aren't that big) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 02:32:43 2016 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 29 Nov 2016 07:32:43 +0000 Subject: [issue28797] Modifying class __dict__ inside __set_name__ In-Reply-To: <1480042109.13.0.341330811366.issue28797@psf.upfronthosting.co.za> Message-ID: <1480404763.76.0.478384913114.issue28797@psf.upfronthosting.co.za> Nick Coghlan added the comment: (Plus, as Martin noted, the tuple creation overhead could easily make the more complex patch slower in many cases) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 02:42:36 2016 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 29 Nov 2016 07:42:36 +0000 Subject: [issue28825] socket.SO_KEEPALIVE does not work on FreeBSD In-Reply-To: <1480360628.41.0.790647323663.issue28825@psf.upfronthosting.co.za> Message-ID: <1480405356.2.0.66589297423.issue28825@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Python just passes socket options to the operating system, so whatever behavior you're seeing is likely part of the OS. ---------- nosy: +benjamin.peterson resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 02:46:19 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 07:46:19 +0000 Subject: [issue28808] Make PyUnicode_CompareWithASCIIString() never failing In-Reply-To: <1480175314.71.0.35688135657.issue28808@psf.upfronthosting.co.za> Message-ID: <1480405579.41.0.639146549631.issue28808@psf.upfronthosting.co.za> STINNER Victor added the comment: I reviewed PyUnicode_CompareWithASCIIString-no-errors.patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 02:52:07 2016 From: report at bugs.python.org (Florin Papa) Date: Tue, 29 Nov 2016 07:52:07 +0000 Subject: [issue28821] generate_opcode_h.py crash when run with python2 In-Reply-To: <1480350136.76.0.0346939338673.issue28821@psf.upfronthosting.co.za> Message-ID: <1480405927.36.0.842025346735.issue28821@psf.upfronthosting.co.za> Florin Papa added the comment: Whenever I did a fresh clone, the Tools/scripts/generate_opcode_h.py would be called. Thank you for fixing this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 02:56:26 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Nov 2016 07:56:26 +0000 Subject: [issue28797] Modifying class __dict__ inside __set_name__ In-Reply-To: <1480042109.13.0.341330811366.issue28797@psf.upfronthosting.co.za> Message-ID: <20161129075622.30331.46054.C8A71B75@psf.io> Roundup Robot added the comment: New changeset 6b8f7d1e2ba4 by Serhiy Storchaka in branch '3.6': Issue #28797: Modifying the class __dict__ inside the __set_name__ method of https://hg.python.org/cpython/rev/6b8f7d1e2ba4 New changeset 18ed518d2eef by Serhiy Storchaka in branch 'default': Issue #28797: Modifying the class __dict__ inside the __set_name__ method of https://hg.python.org/cpython/rev/18ed518d2eef ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 02:59:38 2016 From: report at bugs.python.org (Parviz Karimli) Date: Tue, 29 Nov 2016 07:59:38 +0000 Subject: [issue28829] Tkinter messagebox cx_freeze Python 3.4 Message-ID: <1480406378.43.0.92141568421.issue28829@psf.upfronthosting.co.za> New submission from Parviz Karimli: Tkinter messagebox doesn't work when trying to make an exectuable by cx_freeze in Python 3.4. It works fine with Python 3.4 alone. But after I create an exe of this file, the messagebox does not pop up. ---------- components: Tkinter files: messagebox cx_freeze python 3.4.py messages: 281961 nosy: ParvizKarimli priority: normal severity: normal status: open title: Tkinter messagebox cx_freeze Python 3.4 type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file45683/messagebox cx_freeze python 3.4.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 03:02:01 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 08:02:01 +0000 Subject: [issue28822] Fix indices handling in PyUnicode_FindChar In-Reply-To: <1480350558.9.0.582516213925.issue28822@psf.upfronthosting.co.za> Message-ID: <1480406521.19.0.979867635756.issue28822@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy: I don't think that it's worth it to add a new function to _testcapi to test PyUnicode_FindChar. The implementation of the function seems simple. At least, I would prefer to only see a few unit tests, not 17 test for this simple function! I mean "character in str" is already tested by a *lot* of unit tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 03:03:00 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 08:03:00 +0000 Subject: [issue28821] generate_opcode_h.py crash when run with python2 In-Reply-To: <1480405927.36.0.842025346735.issue28821@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Whenever I did a fresh clone, the Tools/scripts/generate_opcode_h.py would be called. Can you please test "make touch"? This command "fixes" timestamps. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 03:07:28 2016 From: report at bugs.python.org (Florin Papa) Date: Tue, 29 Nov 2016 08:07:28 +0000 Subject: [issue28821] generate_opcode_h.py crash when run with python2 In-Reply-To: <1480350136.76.0.0346939338673.issue28821@psf.upfronthosting.co.za> Message-ID: <1480406848.26.0.739285989416.issue28821@psf.upfronthosting.co.za> Florin Papa added the comment: I tested and the script is no longer called if you do a "make touch" beforehand. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 03:13:43 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 08:13:43 +0000 Subject: [issue28821] generate_opcode_h.py crash when run with python2 In-Reply-To: <1480406848.26.0.739285989416.issue28821@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Florin Papa added the comment: > I tested and the script is no longer called if you do a "make touch" beforehand. Oh ok, thanks for the test. It confirms that you don't need to run the script to build Python 3. It's a side effect of the Mercurial clone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 03:17:59 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 08:17:59 +0000 Subject: [issue28808] Make PyUnicode_CompareWithASCIIString() never failing In-Reply-To: <1480175314.71.0.35688135657.issue28808@psf.upfronthosting.co.za> Message-ID: <1480407479.11.0.959871810455.issue28808@psf.upfronthosting.co.za> STINNER Victor added the comment: >> The function was already documented in Python 3.5, so please add a ".. >> versionchanged:: 3.6" to document the API chnange. > No, this behavior is not documented in any released Python version. The note about the failure was added in issue28701. Ah wait, you want to push this change into Python 3.5? I would prefer to leave Python 3.5 unchanged. Even if you modify Python 3.5, you still have to mention the "versionchanged", since it's a behaviour change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 03:20:24 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 08:20:24 +0000 Subject: [issue28822] Fix indices handling in PyUnicode_FindChar In-Reply-To: <1480350558.9.0.582516213925.issue28822@psf.upfronthosting.co.za> Message-ID: <1480407624.62.0.523267783682.issue28822@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think it is nice to add tests for C API. Especially if there is no direct mapping between Python and C API ("character in str" don't call PyUnicode_FindChar()). Tests should cover all corner cases, otherwise we can miss bugs. Some C API can be not used in CPython at all, just in third-party extensions, and special tests is the only way to test them. The implementation of PyUnicode_FindChar() is not so simple (for example see issue24821). I don't have an opinion about supporting negative indices. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 03:21:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 08:21:58 +0000 Subject: [issue28808] Make PyUnicode_CompareWithASCIIString() never failing In-Reply-To: <1480175314.71.0.35688135657.issue28808@psf.upfronthosting.co.za> Message-ID: <1480407718.72.0.503519770134.issue28808@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Usually we don't add "versionchanged" for every fixed bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 03:30:21 2016 From: report at bugs.python.org (Masayuki Yamamoto) Date: Tue, 29 Nov 2016 08:30:21 +0000 Subject: [issue28441] Change sys.executable to include executable suffix In-Reply-To: <1476452085.73.0.180033377767.issue28441@psf.upfronthosting.co.za> Message-ID: <1480408221.6.0.114751369521.issue28441@psf.upfronthosting.co.za> Masayuki Yamamoto added the comment: I updated a patch to check the made path because previous patch has added suffix even to symbolic link. New patch works that If made path is invalid, revert to original. ---------- Added file: http://bugs.python.org/file45684/sys-executable-suffix-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 03:30:25 2016 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 29 Nov 2016 08:30:25 +0000 Subject: [issue14845] list() != [] In-Reply-To: <1337294857.69.0.824992743087.issue14845@psf.upfronthosting.co.za> Message-ID: <1480408225.72.0.659679620715.issue14845@psf.upfronthosting.co.za> Mark Dickinson added the comment: @wolma: I don't think PEP 479 is relevant here: we're not raising StopIteration inside a generator function, which is the situation that PEP 479 covers. The behaviour in 3.6 matches that originally reported: Python 3.6.0b3 (default, Nov 2 2016, 08:15:32) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def five(x): ... for _ in range(5): ... yield x ... >>> F = five('x') >>> [next(F) for _ in range(10)] Traceback (most recent call last): File "", line 1, in File "", line 1, in StopIteration >>> F = five('x') >>> list(next(F) for _ in range(10)) ['x', 'x', 'x', 'x', 'x'] ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 03:34:18 2016 From: report at bugs.python.org (Masayuki Yamamoto) Date: Tue, 29 Nov 2016 08:34:18 +0000 Subject: [issue28441] Change sys.executable to include executable suffix In-Reply-To: <1476452085.73.0.180033377767.issue28441@psf.upfronthosting.co.za> Message-ID: <1480408458.28.0.442768572886.issue28441@psf.upfronthosting.co.za> Changes by Masayuki Yamamoto : Removed file: http://bugs.python.org/file45684/sys-executable-suffix-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 03:34:25 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Tue, 29 Nov 2016 08:34:25 +0000 Subject: [issue14845] list() != [] In-Reply-To: <1337294857.69.0.824992743087.issue14845@psf.upfronthosting.co.za> Message-ID: <1480408465.55.0.764509876525.issue14845@psf.upfronthosting.co.za> Wolfgang Maier added the comment: Mark, PEP479 is not fully in effect in 3.6 yet. 3.7 will raise the RuntimeError, but 3.6 still only gives a DeprecationWarning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 03:37:12 2016 From: report at bugs.python.org (Masayuki Yamamoto) Date: Tue, 29 Nov 2016 08:37:12 +0000 Subject: [issue28441] Change sys.executable to include executable suffix In-Reply-To: <1476452085.73.0.180033377767.issue28441@psf.upfronthosting.co.za> Message-ID: <1480408632.33.0.826019451331.issue28441@psf.upfronthosting.co.za> Changes by Masayuki Yamamoto : Added file: http://bugs.python.org/file45685/sys-executable-suffix-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 03:38:26 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 08:38:26 +0000 Subject: [issue28822] Fix indices handling in PyUnicode_FindChar In-Reply-To: <1480350558.9.0.582516213925.issue28822@psf.upfronthosting.co.za> Message-ID: <1480408706.48.0.237611666038.issue28822@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Would be nice to test corner cases: 1. Search UCS2 or UCS4 character with zero lower 8 bits: U+XX00. 2. Search UCS2 or UCS4 character with lower 8 bits that match high bits of string characters. For example search U+0404 in the string that consists of U+04XX (Ukrainian text). I think you can find similar Chinese example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 03:46:42 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Tue, 29 Nov 2016 08:46:42 +0000 Subject: [issue14845] list() != [] In-Reply-To: <1337294857.69.0.824992743087.issue14845@psf.upfronthosting.co.za> Message-ID: <1480409202.63.0.333074302689.issue14845@psf.upfronthosting.co.za> Wolfgang Maier added the comment: running with "-W always": >>> def five(x): ... for _ in range(5): ... yield x ... >>> F = five('x') >>> [next(F) for _ in range(10)] Traceback (most recent call last): File "", line 1, in File "", line 1, in StopIteration >>> list(next(F) for _ in range(10)) __main__:1: DeprecationWarning: generator '' raised StopIteration [] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 04:06:30 2016 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 29 Nov 2016 09:06:30 +0000 Subject: [issue14845] list() != [] In-Reply-To: <1337294857.69.0.824992743087.issue14845@psf.upfronthosting.co.za> Message-ID: <1480410390.0.0.365521847945.issue14845@psf.upfronthosting.co.za> Mark Dickinson added the comment: Wolfgang: ah, thanks, that makes more sense. I misunderstood; sorry for the noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 04:12:40 2016 From: report at bugs.python.org (Michael Foord) Date: Tue, 29 Nov 2016 09:12:40 +0000 Subject: [issue28733] Show how to use mock_open in modules other that __main__ In-Reply-To: <1479475072.8.0.338397997846.issue28733@psf.upfronthosting.co.za> Message-ID: <1480410760.17.0.402814892379.issue28733@psf.upfronthosting.co.za> Michael Foord added the comment: open shouldn't always be patched in builtins, it's much better to patch it in the specific namespace it's being called from. So the doc patch here shouldn't be applied as is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 05:10:10 2016 From: report at bugs.python.org (Julien Palard) Date: Tue, 29 Nov 2016 10:10:10 +0000 Subject: [issue28820] Typo in section 6 of the Python 3.4 documentation In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za> Message-ID: <1480414210.17.0.105644497281.issue28820@psf.upfronthosting.co.za> Julien Palard added the comment: Hi Martin, Removed the removing of the double new line at end of file. ---------- Added file: http://bugs.python.org/file45686/issue28820-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 05:12:22 2016 From: report at bugs.python.org (Lele Gaifax) Date: Tue, 29 Nov 2016 10:12:22 +0000 Subject: [issue28830] Typo in whatsnew entry for 3.6 Message-ID: <1480414342.52.0.93217667841.issue28830@psf.upfronthosting.co.za> New submission from Lele Gaifax: At https://hg.python.org/cpython/rev/52038705827d#l1.18 there is an "as part" where probably a "are part" was meant. ---------- assignee: docs at python components: Documentation messages: 281977 nosy: docs at python, lelit priority: normal severity: normal status: open title: Typo in whatsnew entry for 3.6 versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 05:14:43 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 29 Nov 2016 10:14:43 +0000 Subject: [issue28830] Typo in whatsnew entry for 3.6 In-Reply-To: <1480414342.52.0.93217667841.issue28830@psf.upfronthosting.co.za> Message-ID: <1480414483.15.0.145327564415.issue28830@psf.upfronthosting.co.za> SilentGhost added the comment: Reads just fine to me. ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 05:19:11 2016 From: report at bugs.python.org (Mark Harris) Date: Tue, 29 Nov 2016 10:19:11 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1480414751.41.0.718678992809.issue28781@psf.upfronthosting.co.za> Mark Harris added the comment: I installed python just for my user, attempted to run python just out of interest in the command line and again the same error appeared (missing python35.dll). I uninstalled that then reinstalled for all users, and again during installation the message missing python35.dll appeared. Any other suggestions? Thanks for the help so far. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 06:36:36 2016 From: report at bugs.python.org (Lele Gaifax) Date: Tue, 29 Nov 2016 11:36:36 +0000 Subject: [issue28830] Typo in whatsnew entry for 3.6 In-Reply-To: <1480414342.52.0.93217667841.issue28830@psf.upfronthosting.co.za> Message-ID: <1480419396.5.0.932715597098.issue28830@psf.upfronthosting.co.za> Lele Gaifax added the comment: Ok, thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 06:37:24 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 29 Nov 2016 11:37:24 +0000 Subject: [issue28830] Typo in whatsnew entry for 3.6 In-Reply-To: <1480414342.52.0.93217667841.issue28830@psf.upfronthosting.co.za> Message-ID: <1480419444.42.0.231916236182.issue28830@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 06:50:38 2016 From: report at bugs.python.org (=?utf-8?b?RGFuIOKAnGxvY2FsbHljb21wYWN04oCdIEZpcnRo?=) Date: Tue, 29 Nov 2016 11:50:38 +0000 Subject: [issue28831] Python 3's shutil.make_archive is truncating filenames Message-ID: <1480420238.68.0.491004262326.issue28831@psf.upfronthosting.co.za> New submission from Dan ?locallycompact? Firth: I have made an example of this bug here: https://github.com/locallycompact/py3_make_archive_bug Using shutil.make_archive() in python2 works fine, where as in python3 one of the filenames has been truncated by five characters after unpacking the resulting archive. This is the same every time. ---------- messages: 281981 nosy: Dan ?locallycompact? Firth priority: normal severity: normal status: open title: Python 3's shutil.make_archive is truncating filenames type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 06:58:26 2016 From: report at bugs.python.org (Decorater) Date: Tue, 29 Nov 2016 11:58:26 +0000 Subject: [issue28831] Python 3's shutil.make_archive is truncating filenames In-Reply-To: <1480420238.68.0.491004262326.issue28831@psf.upfronthosting.co.za> Message-ID: <1480420706.39.0.850273808716.issue28831@psf.upfronthosting.co.za> Decorater added the comment: hmm This shows a bug in shutil.make_archive in python3. Run ./test.sh to run shutil.make_archive in both python2 and python3 on the wdir and then extract each of them for comparison. The file called '/usr/share/ca-certificates/mozilla/T?B?TAK_UEKAE_K?k_Sertifika_Hizmet_Sa?lay?c?s?_-_S?r?m_3.crt' has been truncated by five characters in the python3 archive, becoming: '/usr/share/ca-certificates/mozilla/T?B?TAK_UEKAE_K?k_Sertifika_Hizmet_Sa?lay?c?s?_-_S?r?m_' Something makes me wonder if it counts the # of chars in the file name specified and strips anything larger. ---------- nosy: +Decorater _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 07:02:10 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 12:02:10 +0000 Subject: [issue28831] Python 3's shutil.make_archive is truncating filenames In-Reply-To: <1480420238.68.0.491004262326.issue28831@psf.upfronthosting.co.za> Message-ID: <1480420930.84.0.963817826816.issue28831@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This looks as a duplicate of issue24838. ---------- nosy: +serhiy.storchaka resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> tarfile.py: fix GNU and USTAR formats to properly handle paths with special characters that are encoded with more than one byte each _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 07:02:29 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 12:02:29 +0000 Subject: [issue28831] Python 3's shutil.make_archive is truncating filenames In-Reply-To: <1480420238.68.0.491004262326.issue28831@psf.upfronthosting.co.za> Message-ID: <1480420949.6.0.818847056511.issue28831@psf.upfronthosting.co.za> STINNER Victor added the comment: An entry in a TAR archive has a name. The name field has a size of 100 bytes. The field is padded with zero bytes. I don't know if it must or must not end with a zero byte. '/usr/share/ca-certificates/mozilla/T?B?TAK_UEKAE_K?k_Sertifika_Hizmet_Sa?lay?c?s?_-_S?r?m_3.crt' string encoded to UTF-8 takes 104 bytes. Python should emit a warning or even fail with an error if a name is longer than 100 *bytes* (not 100 *characters*). ---------- nosy: +haypo, lars.gustaebel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 07:02:44 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 12:02:44 +0000 Subject: [issue28831] Python 3's shutil.make_archive is truncating filenames In-Reply-To: <1480420238.68.0.491004262326.issue28831@psf.upfronthosting.co.za> Message-ID: <1480420964.11.0.337482239627.issue28831@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, Serhiy just closed the issue as a duplicate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 07:04:09 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 12:04:09 +0000 Subject: [issue24838] tarfile.py: fix GNU and USTAR formats to properly handle paths with special characters that are encoded with more than one byte each In-Reply-To: <1439229863.39.0.118048991617.issue24838@psf.upfronthosting.co.za> Message-ID: <1480421049.42.0.213573256217.issue24838@psf.upfronthosting.co.za> STINNER Victor added the comment: FYI the first release including the fix 78ede2baa146 is Python 3.5.2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 07:04:16 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 12:04:16 +0000 Subject: [issue28831] Python 3's shutil.make_archive is truncating filenames In-Reply-To: <1480420238.68.0.491004262326.issue28831@psf.upfronthosting.co.za> Message-ID: <1480421056.32.0.0223641422626.issue28831@psf.upfronthosting.co.za> STINNER Victor added the comment: FYI the first release including the fix 78ede2baa146 is Python 3.5.2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 07:21:02 2016 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 29 Nov 2016 12:21:02 +0000 Subject: [issue13721] ssl.wrap_socket on a connected but failed connection succeeds and .peer_certificate gives AttributeError In-Reply-To: <1325871512.71.0.286774610121.issue13721@psf.upfronthosting.co.za> Message-ID: <1480422062.67.0.478895942246.issue13721@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: fyi, I just observed this in the field in 2.7.3 using requests 2.5.3 I don't think requests has a workaround for 2.7 from reading the release logs. ---------- nosy: +kristjan.jonsson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 07:56:55 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 29 Nov 2016 12:56:55 +0000 Subject: [issue28832] Reduce memset in dict creation Message-ID: <1480424215.77.0.617126562471.issue28832@psf.upfronthosting.co.za> New submission from INADA Naoki: This patch delays initialization of dk_entries. Entries are initialized when first use (when dk_netries is incremented). Minimum dk_entries of 64bit arch is 5 * 8 * 3 = 120bytes. So it can save 4 cache lines! I'm running benchmark for now. ---------- assignee: inada.naoki components: Interpreter Core files: reduce-memset.patch keywords: patch messages: 281989 nosy: inada.naoki priority: normal severity: normal stage: patch review status: open title: Reduce memset in dict creation type: performance versions: Python 3.7 Added file: http://bugs.python.org/file45687/reduce-memset.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 09:08:56 2016 From: report at bugs.python.org (Erik Bray) Date: Tue, 29 Nov 2016 14:08:56 +0000 Subject: [issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX In-Reply-To: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za> Message-ID: <1480428536.36.0.364466849771.issue25658@psf.upfronthosting.co.za> Erik Bray added the comment: To me, Masayuki's patch is an acceptable work-around for the time being. I don't *like* it because the fact remains that native TLS can work on these platforms and falling back on Python's slower implementation isn't necessary. That said, the previous patch attempts also add additional overhead that shouldn't be necessary. I agree the best thing to do would be to change this API, but that is a bigger issue I guess... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 09:44:20 2016 From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Bultrowicz?=) Date: Tue, 29 Nov 2016 14:44:20 +0000 Subject: [issue28733] Show how to use mock_open in modules other that __main__ In-Reply-To: <1479475072.8.0.338397997846.issue28733@psf.upfronthosting.co.za> Message-ID: <1480430660.57.0.601360033042.issue28733@psf.upfronthosting.co.za> Micha? Bultrowicz added the comment: Then where it should be patched in? Can you give an example? From what I've checked patching only works in __main__ and builtins. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 09:48:13 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 29 Nov 2016 14:48:13 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1480430893.01.0.889589296325.issue28781@psf.upfronthosting.co.za> Steve Dower added the comment: Could you attach those three sets of logs? I'm running low on ideas and need all the inspiration I can get :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 09:51:41 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 29 Nov 2016 14:51:41 +0000 Subject: [issue28833] cross compilation of third-party extension modules Message-ID: <1480431100.4.0.611325572748.issue28833@psf.upfronthosting.co.za> New submission from Xavier de Gaye: With this patch, cross compiling a third-party extension module is done with the command: XBUILD_PYTHON_DIR=/path/to/python/dir python setup.py build where XBUILD_PYTHON_DIR is the location of the directory of the cross-compiled python executable. It may be: a) The build tree, which is the source tree when the cross compilation is not out of the source tree. b) '$DESTDIR/$exec_prefix/bin' when the cross built python has been installed with 'make DESTDIR=/some/path install'. In that case 'prefix' and 'exec_prefix' may be different. c) When the result of the cross compilation has been manually copied (for example to /some/path) and if 'prefix' and 'exec_prefix' are identical, this is /some/path/bin. In case b), one can use the 'install' setup.py command instead of the 'build' command, to build and install the extension module to '$DESTDIR/$exec_prefix/lib/python$VERSION/site-packages' with the appropriate 'egg-info' file. The patch uses the 'python-config' shell script (created at issue 16235 [1]) that is initialized with the proper variables at the configure stage to provide the minimum information required by the sysconfig module to create (with the option --generate-posix-vars) the sysconfigdata file or to import the sysconfigdata module. The patch also fixes issue 22724 [2] as sys.path is only modified during the time needed to import the sysconfigdata module. The patch fixes two minor problems: * '_PYTHON_HOST_PLATFORM' in Makefile.pre.in was not added to the sysconfig variables as intended, since those variables may not be prefixed with an underscore. * The sysconfigdata file name was terminated with a dangling underscore when 'multiarch' is not defined. Patch also tested with pyephem on an Android emulator. The patch misses the documentation. Please run autoconf after installing the patch. [1] issue 16235: add python-config.sh for use during cross compilation http://bugs.python.org/issue16235 [2] issue 22724: byte-compile fails for cross-builds http://bugs.python.org/issue22724 ---------- assignee: xdegaye components: Cross-Build files: cross-build-extension.patch keywords: patch messages: 281993 nosy: Alex.Willmer, doko, dstufft, eric.araujo, haypo, martin.panter, xdegaye, zach.ware priority: normal severity: normal stage: patch review status: open title: cross compilation of third-party extension modules type: behavior versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45688/cross-build-extension.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 09:58:37 2016 From: report at bugs.python.org (Mark Harris) Date: Tue, 29 Nov 2016 14:58:37 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1480431517.28.0.33117024272.issue28781@psf.upfronthosting.co.za> Mark Harris added the comment: I've attached the logs, Thanks, Mark ---------- Added file: http://bugs.python.org/file45689/Python logs 3.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 10:10:59 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 29 Nov 2016 15:10:59 +0000 Subject: [issue14845] list() != [] In-Reply-To: <1337294857.69.0.824992743087.issue14845@psf.upfronthosting.co.za> Message-ID: <1480432259.66.0.800725783606.issue14845@psf.upfronthosting.co.za> R. David Murray added the comment: OK, then this issue can be closed unless someone thinks it is worth documenting the lack of PEP 479 in 3.5 and 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 10:41:08 2016 From: report at bugs.python.org (Matthias Klose) Date: Tue, 29 Nov 2016 15:41:08 +0000 Subject: [issue28833] cross compilation of third-party extension modules In-Reply-To: <1480431100.4.0.611325572748.issue28833@psf.upfronthosting.co.za> Message-ID: <1480434068.21.0.222533237842.issue28833@psf.upfronthosting.co.za> Matthias Klose added the comment: This approach will not work with a "multiarch" enabled environment, and break cross builds on Debian and Ubuntu. Afaics, the proposal assumes that the python executable for the target architecture is installed (which it is not for the multiarch cross-build layout), and that each target architecture has to be identified by it's own directory tree (again, not in the multiarch environment, you can install multiple targets into the same path). I don't think that identifying the target by some path is the right way to go, and you should be able to identify the target by giving the target triplet as used by the configure parameters and then deduce the location from the target (or have an explicit location given). The idea here is to use the platform identifier which we already had in the trunk before the PLATDIR was removed (the multiarch id or if not defined the platform). So by having a specifier, you could deduce a path, or a -python-config executable and you're done. No need to know about a path directly. Of course python cross builds would have to install the -python-config executable or symlink. Minor issue: please s/xbuild/cross_build/. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 10:44:58 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Nov 2016 15:44:58 +0000 Subject: [issue26273] Expose TCP_CONGESTION and TCP_USER_TIMEOUT to the socket module In-Reply-To: <1454489684.49.0.598051421532.issue26273@psf.upfronthosting.co.za> Message-ID: <1480434298.81.0.0484499261181.issue26273@psf.upfronthosting.co.za> Antoine Pitrou added the comment: +1 for this. The patch looks fine, and there's no need to add any documentation or tests. ---------- nosy: +pitrou stage: -> patch review versions: +Python 3.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 10:47:43 2016 From: report at bugs.python.org (Matthias Klose) Date: Tue, 29 Nov 2016 15:47:43 +0000 Subject: [issue28833] cross compilation of third-party extension modules In-Reply-To: <1480431100.4.0.611325572748.issue28833@psf.upfronthosting.co.za> Message-ID: <1480434463.08.0.035069118063.issue28833@psf.upfronthosting.co.za> Matthias Klose added the comment: > * The sysconfigdata file name was terminated with a dangling > underscore when 'multiarch' is not defined. That only solves part of the problem in that the kernel/os version gets encoded as well, e.g. gnukfreebsd9, gnukfreebsd10, which is nasty when the version of your runtime and build time kernel differ. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 10:49:06 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Nov 2016 15:49:06 +0000 Subject: [issue28663] Higher virtual memory usage on recent Linux versions In-Reply-To: <1478853233.74.0.582487882076.issue28663@psf.upfronthosting.co.za> Message-ID: <1480434545.99.0.0152778286524.issue28663@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Your script works fine here (Ubuntu 16.04). Besides, if you're seeing differences between two Linux versions with the same Python version, it is quite unlikely to be a Python issue. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 10:51:28 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 29 Nov 2016 15:51:28 +0000 Subject: [issue28822] Fix indices handling in PyUnicode_FindChar In-Reply-To: <1480350558.9.0.582516213925.issue28822@psf.upfronthosting.co.za> Message-ID: <1480434688.93.0.162178779261.issue28822@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks for your reviews. :-) v2 updated the test codes. ---------- Added file: http://bugs.python.org/file45690/PyUnicode_FindChar-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 10:55:35 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Nov 2016 15:55:35 +0000 Subject: [issue26273] Expose TCP_CONGESTION and TCP_USER_TIMEOUT to the socket module In-Reply-To: <1454489684.49.0.598051421532.issue26273@psf.upfronthosting.co.za> Message-ID: <20161129155527.23900.61643.ACE51134@psf.io> Roundup Robot added the comment: New changeset 674fb9644eaa by Victor Stinner in branch 'default': Add TCP_CONGESTION and TCP_USER_TIMEOUT https://hg.python.org/cpython/rev/674fb9644eaa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 10:57:15 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 15:57:15 +0000 Subject: [issue26273] Expose TCP_CONGESTION and TCP_USER_TIMEOUT to the socket module In-Reply-To: <1454489684.49.0.598051421532.issue26273@psf.upfronthosting.co.za> Message-ID: <1480435035.62.0.815891847075.issue26273@psf.upfronthosting.co.za> STINNER Victor added the comment: @Ned Deily: Would you be ok to add these two constants to Python 3.6? I cannot image any regression if 674fb9644eaa is backported to Python 3.6. @Serhiy, Yury: Any opinion on the backport? ---------- nosy: +haypo, ned.deily, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 10:59:08 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 15:59:08 +0000 Subject: [issue26273] Expose TCP_CONGESTION and TCP_USER_TIMEOUT to the socket module In-Reply-To: <1454489684.49.0.598051421532.issue26273@psf.upfronthosting.co.za> Message-ID: <1480435148.93.0.547642701422.issue26273@psf.upfronthosting.co.za> STINNER Victor added the comment: Sorry, I missed this issue. TCP_USER_TIMEOUT is super useful! It helps a lot to detect when a server is down, especially when using keep alive: at kernel level (TCP keepalive) or application level (ex: RabbitMQ heart beat). Linux default timeout is more something like 15 minutes. A few years ago, it was longer than 2 days :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 11:05:48 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Nov 2016 16:05:48 +0000 Subject: [issue26273] Expose TCP_CONGESTION and TCP_USER_TIMEOUT to the socket module In-Reply-To: <1480435148.93.0.547642701422.issue26273@psf.upfronthosting.co.za> Message-ID: Antoine Pitrou added the comment: Le 29/11/2016 ? 16:59, STINNER Victor a ?crit : > > TCP_USER_TIMEOUT is super useful! It is :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 11:09:18 2016 From: report at bugs.python.org (INADA Naoki) Date: Tue, 29 Nov 2016 16:09:18 +0000 Subject: [issue28832] Reduce memset in dict creation In-Reply-To: <1480424215.77.0.617126562471.issue28832@psf.upfronthosting.co.za> Message-ID: <1480435758.67.0.961848230161.issue28832@psf.upfronthosting.co.za> INADA Naoki added the comment: $ ./python-default -m perf compare_to default.json patched.json -G Slower (2): - xml_etree_iterparse: 328 ms +- 26 ms -> 350 ms +- 29 ms: 1.07x slower - fannkuch: 1.58 sec +- 0.09 sec -> 1.65 sec +- 0.09 sec: 1.05x slower Faster (9): - scimark_sor: 870 ms +- 59 ms -> 800 ms +- 54 ms: 1.09x faster - deltablue: 28.0 ms +- 2.1 ms -> 26.4 ms +- 1.6 ms: 1.06x faster - regex_dna: 423 ms +- 26 ms -> 399 ms +- 26 ms: 1.06x faster - scimark_sparse_mat_mult: 13.9 ms +- 1.0 ms -> 13.2 ms +- 0.9 ms: 1.06x faster - raytrace: 2.16 sec +- 0.12 sec -> 2.07 sec +- 0.11 sec: 1.05x faster - unpickle_pure_python: 1.36 ms +- 0.11 ms -> 1.31 ms +- 0.07 ms: 1.04x faster - pickle_dict: 103 us +- 11 us -> 99.7 us +- 7.7 us: 1.03x faster - scimark_monte_carlo: 408 ms +- 35 ms -> 397 ms +- 25 ms: 1.03x faster - scimark_lu: 765 ms +- 49 ms -> 746 ms +- 55 ms: 1.03x faster Benchmark hidden because not significant (53): 2to3, call_method, call_method_slots, call_method_unknown, call_simple, chameleon, chaos, crypto_pyaes, django_template, dulwich_log, float, genshi_text, gen shi_xml, go, hexiom, html5lib, json_dumps, json_loads, logging_format, logging_silent, logging_simple, mako, meteor_contest, nbody, nqueens, pathlib, pickle, pickle_list, pickle_pure_python, pidigits, pyt hon_startup, python_startup_no_site, regex_compile, regex_effbot, regex_v8, richards, scimark_fft, spectral_norm, sqlalchemy_declarative, sqlalchemy_imperative, sqlite_synth, sympy_expand, sympy_integrate , sympy_str, sympy_sum, telco, tornado_http, unpack_sequence, unpickle, unpickle_list, xml_etree_generate, xml_etree_parse, xml_etree_process ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 11:13:01 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 16:13:01 +0000 Subject: [issue28663] Higher virtual memory usage on recent Linux versions In-Reply-To: <1478853233.74.0.582487882076.issue28663@psf.upfronthosting.co.za> Message-ID: <1480435981.36.0.812998475683.issue28663@psf.upfronthosting.co.za> STINNER Victor added the comment: It's very hard to estimate the water high-mark for memory because the memory includes different things: read-only memory, mmap() on files, read-only memory pages shared between multiple processes for libraries, etc. I suggest to use the tracemalloc module to have a better idea of the memory usage of the memory directly allocated by Python. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 11:16:23 2016 From: report at bugs.python.org (Omar Sandoval) Date: Tue, 29 Nov 2016 16:16:23 +0000 Subject: [issue26273] Expose TCP_CONGESTION and TCP_USER_TIMEOUT to the socket module In-Reply-To: <1454489684.49.0.598051421532.issue26273@psf.upfronthosting.co.za> Message-ID: <1480436183.16.0.231324736517.issue26273@psf.upfronthosting.co.za> Omar Sandoval added the comment: Glad to see this finally get in :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 11:29:51 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 16:29:51 +0000 Subject: [issue28663] Higher virtual memory usage on recent Linux versions In-Reply-To: <1478853233.74.0.582487882076.issue28663@psf.upfronthosting.co.za> Message-ID: <1480436991.99.0.921409743956.issue28663@psf.upfronthosting.co.za> STINNER Victor added the comment: rlimit_tracemalloc.txt: Oh, my idea was only to see the total, https://docs.python.org/dev/library/tracemalloc.html#tracemalloc.get_traced_memory Current and peak memory usage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 11:31:36 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 16:31:36 +0000 Subject: [issue28832] Reduce memset in dict creation In-Reply-To: <1480424215.77.0.617126562471.issue28832@psf.upfronthosting.co.za> Message-ID: <1480437096.77.0.103753672897.issue28832@psf.upfronthosting.co.za> STINNER Victor added the comment: Can you please attached the two JSON files, compressed with gzip (.gz files). perf is also to read gzipped JSON. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 11:33:47 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 16:33:47 +0000 Subject: [issue26273] Expose TCP_CONGESTION and TCP_USER_TIMEOUT to the socket module In-Reply-To: <1454489684.49.0.598051421532.issue26273@psf.upfronthosting.co.za> Message-ID: <1480437227.35.0.289557781062.issue26273@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Shouldn't we add something like versionadded/versionchanged or a mentioning in What's New? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 11:37:52 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 29 Nov 2016 16:37:52 +0000 Subject: [issue26273] Expose TCP_CONGESTION and TCP_USER_TIMEOUT to the socket module In-Reply-To: <1454489684.49.0.598051421532.issue26273@psf.upfronthosting.co.za> Message-ID: <1480437472.16.0.551083911143.issue26273@psf.upfronthosting.co.za> Yury Selivanov added the comment: Would be nice to have in 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 11:42:13 2016 From: report at bugs.python.org (ProgVal) Date: Tue, 29 Nov 2016 16:42:13 +0000 Subject: [issue28663] Higher virtual memory usage on recent Linux versions In-Reply-To: <1480436991.99.0.921409743956.issue28663@psf.upfronthosting.co.za> Message-ID: <73d5eb8c-dcdf-6e23-7e30-45990298a385@gmail.com> ProgVal added the comment: (4350362, 4376669) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 11:44:18 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 16:44:18 +0000 Subject: [issue28832] Reduce memset in dict creation In-Reply-To: <1480424215.77.0.617126562471.issue28832@psf.upfronthosting.co.za> Message-ID: <1480437858.18.0.976805905602.issue28832@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think that clearing 120 bytes at a time is faster than clear it later entry-by-entry. Your patch removes some asserts, this looks not good. Could your provide microbenchmarks that show the largest speed up and the largest slow down? So we would see what type of code gets the benefit. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 11:56:02 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 16:56:02 +0000 Subject: [issue28663] Higher virtual memory usage on recent Linux versions In-Reply-To: <1478853233.74.0.582487882076.issue28663@psf.upfronthosting.co.za> Message-ID: <1480438562.06.0.651256318332.issue28663@psf.upfronthosting.co.za> STINNER Victor added the comment: ProgVal: "(4350362, 4376669)" is it the same result on Python 3.4 and Python 3.5? I don't understand your comment :-/ Can you please elaborate? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 12:15:27 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 17:15:27 +0000 Subject: [issue28822] Fix indices handling in PyUnicode_FindChar In-Reply-To: <1480350558.9.0.582516213925.issue28822@psf.upfronthosting.co.za> Message-ID: <1480439727.28.0.63661209746.issue28822@psf.upfronthosting.co.za> STINNER Victor added the comment: PyUnicode_FindChar-v2.patch LGTM with a minor comment on the review, but I would prefer that Serhiy also reviews it ;-) Remaining question: what is the behaviour for direction=0, direction=100 or direction=-2? Maybe we can add a few unit tests for strange values of direction? (Not sure if it's worth it.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 12:15:29 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 29 Nov 2016 17:15:29 +0000 Subject: [issue26273] Expose TCP_CONGESTION and TCP_USER_TIMEOUT to the socket module In-Reply-To: <1454489684.49.0.598051421532.issue26273@psf.upfronthosting.co.za> Message-ID: <1480439729.13.0.387799512815.issue26273@psf.upfronthosting.co.za> Ned Deily added the comment: OK for 3.6.0rc1 (before it times out) ---------- stage: patch review -> commit review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 12:19:37 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 17:19:37 +0000 Subject: [issue28832] Reduce memset in dict creation In-Reply-To: <1480424215.77.0.617126562471.issue28832@psf.upfronthosting.co.za> Message-ID: <1480439977.28.0.468206107873.issue28832@psf.upfronthosting.co.za> STINNER Victor added the comment: You might experiment Python_Calloc(). I'm not sure that this allocator is well optimized (especially the pymalloc allocator) :-/ Last time I played with it, it was slower, especially for allocations smaller than 1 MB. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 12:22:17 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 29 Nov 2016 17:22:17 +0000 Subject: [issue28791] update sqlite to 3.15.2 In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1480440137.77.0.158143452366.issue28791@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- components: +Installation, Windows, macOS nosy: +ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 12:22:53 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Nov 2016 17:22:53 +0000 Subject: [issue26273] Expose TCP_CONGESTION and TCP_USER_TIMEOUT to the socket module In-Reply-To: <1454489684.49.0.598051421532.issue26273@psf.upfronthosting.co.za> Message-ID: <20161129172247.30026.38120.C17C6FA0@psf.io> Roundup Robot added the comment: New changeset 6d69da76be6a by Victor Stinner in branch '3.6': Add TCP_CONGESTION and TCP_USER_TIMEOUT https://hg.python.org/cpython/rev/6d69da76be6a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 12:26:59 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 17:26:59 +0000 Subject: [issue26273] Expose TCP_CONGESTION and TCP_USER_TIMEOUT to the socket module In-Reply-To: <1454489684.49.0.598051421532.issue26273@psf.upfronthosting.co.za> Message-ID: <1480440419.49.0.241375326794.issue26273@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy Storchaka: "Shouldn't we add something like versionadded/versionchanged or a mentioning in What's New?" Oh right, we did that for other new constants added to Python 3.6 like SO_DOMAIN. Attached socket_doc.patch documents the additional of the two new constants. It seems like "hg transplant" putted the NEWS entry in the wrong section :-/ The patch also fixes that. ---------- Added file: http://bugs.python.org/file45692/socket_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 12:29:52 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 29 Nov 2016 17:29:52 +0000 Subject: [issue28822] Fix indices handling in PyUnicode_FindChar In-Reply-To: <1480350558.9.0.582516213925.issue28822@psf.upfronthosting.co.za> Message-ID: <1480440592.35.0.752858692944.issue28822@psf.upfronthosting.co.za> Xiang Zhang added the comment: > Remaining question: what is the behaviour for direction=0, direction=100 or direction=-2? Maybe we can add a few unit tests for strange values of direction? (Not sure if it's worth it.) It's not documented so I also doubt it. Expect Serhiy's comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 12:35:51 2016 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 29 Nov 2016 17:35:51 +0000 Subject: [issue28208] update sqlite to 3.14.2 In-Reply-To: <1474317408.19.0.662096879681.issue28208@psf.upfronthosting.co.za> Message-ID: <1480440951.74.0.280483968461.issue28208@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: sqlite 3.15.2 was just released. I can prepare a patch if that's what we want. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 12:44:14 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 29 Nov 2016 17:44:14 +0000 Subject: [issue28790] Error when using Generic and __slots__ In-Reply-To: <1480017847.05.0.904574090231.issue28790@psf.upfronthosting.co.za> Message-ID: <1480441454.91.0.353646999551.issue28790@psf.upfronthosting.co.za> Guido van Rossum added the comment: OK, having thought about it some more, given that you don't seem to object too strenuously, I'm going to merge the fix. May it be the last one! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 12:48:07 2016 From: report at bugs.python.org (Ed Schouten) Date: Tue, 29 Nov 2016 17:48:07 +0000 Subject: [issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX In-Reply-To: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za> Message-ID: <1480441687.87.0.721821814671.issue25658@psf.upfronthosting.co.za> Ed Schouten added the comment: Looks good to me! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 12:51:22 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Nov 2016 17:51:22 +0000 Subject: [issue28790] Error when using Generic and __slots__ In-Reply-To: <1480017847.05.0.904574090231.issue28790@psf.upfronthosting.co.za> Message-ID: <20161129174658.9841.30654.5561AE28@psf.io> Roundup Robot added the comment: New changeset 0bbd29405c9d by Guido van Rossum in branch '3.5': Issue #28790: Fix error when using Generic and __slots__ (Ivan L) https://hg.python.org/cpython/rev/0bbd29405c9d New changeset 2dd08b5b5ee6 by Guido van Rossum in branch '3.6': Issue #28790: Fix error when using Generic and __slots__ (Ivan L) (3.5->3.6) https://hg.python.org/cpython/rev/2dd08b5b5ee6 New changeset b9915ca4b3da by Guido van Rossum in branch 'default': Issue #28790: Fix error when using Generic and __slots__ (Ivan L) (3.6->3.7) https://hg.python.org/cpython/rev/b9915ca4b3da ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 12:51:44 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 29 Nov 2016 17:51:44 +0000 Subject: [issue28790] Error when using Generic and __slots__ In-Reply-To: <1480017847.05.0.904574090231.issue28790@psf.upfronthosting.co.za> Message-ID: <1480441904.97.0.890711943137.issue28790@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- resolution: -> fixed stage: -> commit review status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 13:32:13 2016 From: report at bugs.python.org (Steve Dower) Date: Tue, 29 Nov 2016 18:32:13 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1480444333.58.0.487452832974.issue28781@psf.upfronthosting.co.za> Steve Dower added the comment: That's only the most recent set, and all it shows is that the per-user install didn't help. Do you have the earlier sets of install logs for the per-user install and uninstall? I'd like to see why those didn't have the effect I expected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 13:39:53 2016 From: report at bugs.python.org (ProgVal) Date: Tue, 29 Nov 2016 18:39:53 +0000 Subject: [issue28663] Higher virtual memory usage on recent Linux versions In-Reply-To: <1480438562.06.0.651256318332.issue28663@psf.upfronthosting.co.za> Message-ID: ProgVal added the comment: Sorry. That's the result of |||get_traced_memory|on Python 3.5 and Linux 4.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 13:43:30 2016 From: report at bugs.python.org (Julien Palard) Date: Tue, 29 Nov 2016 18:43:30 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480445010.97.0.527386581729.issue28754@psf.upfronthosting.co.za> Julien Palard added the comment: I tried myself at Argument Clinic custom converters to create the "optional ssize_t converter" and it works, so as advised by Raymond, pydoc now shows None, and the C implementation now allows for both default values None and -1, as the custom converter returns -1 for none. ---------- Added file: http://bugs.python.org/file45693/issue28754-7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 13:49:37 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 29 Nov 2016 18:49:37 +0000 Subject: [issue24469] Py2.x int free list can grow without bounds In-Reply-To: <1434695478.8.0.352869011826.issue24469@psf.upfronthosting.co.za> Message-ID: <20161129184930.24204.14279.DAB747D2@psf.io> Roundup Robot added the comment: New changeset fd0842f34602 by Serhiy Storchaka in branch '2.7': Issue #24469: Fixed memory leak caused by int subclasses without overridden https://hg.python.org/cpython/rev/fd0842f34602 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 13:50:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 18:50:20 +0000 Subject: [issue24469] Py2.x int free list can grow without bounds In-Reply-To: <1434695478.8.0.352869011826.issue24469@psf.upfronthosting.co.za> Message-ID: <1480445420.34.0.265753297999.issue24469@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 14:01:27 2016 From: report at bugs.python.org (Stefan Krah) Date: Tue, 29 Nov 2016 19:01:27 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480446087.58.0.651702619577.issue28754@psf.upfronthosting.co.za> Stefan Krah added the comment: Julien, the syntax converters look pretty clever. Do we need AC everywhere though? I wonder (once again) if this is really more readable than the existing code. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 14:17:59 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 19:17:59 +0000 Subject: [issue11145] '%o' % user-defined instance In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za> Message-ID: <1480447079.23.0.964346303195.issue11145@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I read the code multiple times but still don't see any issues with the last path. If anybody know issues with it, please point on them. Otherwise I'll commit the patch. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 14:19:37 2016 From: report at bugs.python.org (Big Stone) Date: Tue, 29 Nov 2016 19:19:37 +0000 Subject: [issue28208] update sqlite to 3.14.2 In-Reply-To: <1474317408.19.0.662096879681.issue28208@psf.upfronthosting.co.za> Message-ID: <1480447177.83.0.306212525172.issue28208@psf.upfronthosting.co.za> Big Stone added the comment: As far as I test, the novelties from 0.15.2 don't break any API (just nice SQL-syntax sugar), and correct some old 3.8.0 bugs. and ".2" is the same level of stabilisation as current "0.14.2" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 14:29:13 2016 From: report at bugs.python.org (Masayuki Yamamoto) Date: Tue, 29 Nov 2016 19:29:13 +0000 Subject: [issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX In-Reply-To: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za> Message-ID: <1480447753.15.0.986197833441.issue25658@psf.upfronthosting.co.za> Masayuki Yamamoto added the comment: Elik, Ed, I have overlooked tracemalloc module raises deadlock if apply the patch. I found out a source comment on Modules/_tracemalloc.c:161 /* If your OS does not provide native thread local storage, you can implement it manually using a lock. Functions of thread.c cannot be used because they use PyMem_RawMalloc() which leads to a reentrant call. */ #if !(defined(_POSIX_THREADS) || defined(NT_THREADS)) # error "need native thread local storage (TLS)" #endif Py_HAVE_NATIVE_TLS is used only on thread source code. Therefore C Compiler couldn't report error about tracemalloc. I'm sorry that I didn't check test. Currently I'm trying to implement new API based on msg281227. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 14:33:12 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 19:33:12 +0000 Subject: [issue21818] cookielib documentation references Cookie module, not cookielib.Cookie class In-Reply-To: <1403306887.99.0.626699628104.issue21818@psf.upfronthosting.co.za> Message-ID: <1480447992.1.0.919789180378.issue21818@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thus the only way to fix links is to specify full names? Does docs_class_links-2.7.patch look good to you? ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 14:34:51 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 19:34:51 +0000 Subject: [issue22039] PyObject_SetAttr doesn't mention value = NULL In-Reply-To: <1406051790.64.0.0676928180206.issue22039@psf.upfronthosting.co.za> Message-ID: <1480448091.1.0.987793753537.issue22039@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 14:39:10 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 19:39:10 +0000 Subject: [issue20612] cElementTree has problems with StringIO object containing unicode content In-Reply-To: <1392236199.28.0.287931665829.issue20612@psf.upfronthosting.co.za> Message-ID: <1480448350.31.0.183593570286.issue20612@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 14:41:23 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 29 Nov 2016 19:41:23 +0000 Subject: [issue28790] Error when using Generic and __slots__ In-Reply-To: <1480017847.05.0.904574090231.issue28790@psf.upfronthosting.co.za> Message-ID: <1480448483.62.0.891832398596.issue28790@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 14:45:54 2016 From: report at bugs.python.org (Ned Deily) Date: Tue, 29 Nov 2016 19:45:54 +0000 Subject: [issue28791] update sqlite to 3.15.2 In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1480448754.03.0.380443733367.issue28791@psf.upfronthosting.co.za> Ned Deily added the comment: Yes, we're not going to change library versions for the 3.6.0 installers at this point. Upgrade for 3.7.0 is fine and possibly for a 3.6.x maintenance release if warranted. I suggest holding off on any patches until we're closer to those releases as there may be subsequent SQLite updates. ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 14:53:07 2016 From: report at bugs.python.org (nyoshimizu) Date: Tue, 29 Nov 2016 19:53:07 +0000 Subject: [issue28834] Type checking in set comparisons. Message-ID: <1480449187.13.0.345778529202.issue28834@psf.upfronthosting.co.za> New submission from nyoshimizu: The non-operator versions of set comparisons (intersection(), union(), etc.) exhibit inconsistent type checking. They only check the first input before deciding whether or not to raise a TypeError exception. Therefore, it's possible to pass a set first, then other objects (e.g. lists, dicts, tuples) and a correct 'intersection' is returned (apparently by ignoring ordering and using the keys in dicts). I've attached demonstrative example for Python 3.5, although Python 2.7 appears to exhibit the same behavior. I'm not sure what the intended behavior was (whether or not to require sets). 8.7.1 Set Objects states: "Note, the non-operator versions of union(), intersection(), difference(), and symmetric_difference() will accept any iterable as an argument." Note that #8743 and #17626 appear to confirm that the operator versions should not accept non-sets and matches the observed behavior. As the latter issue points out, it's documented -- again in 8.7.1 -- that "...their operator based counterparts require their arguments to be sets." Is this behavior necessary but just not documented? The documentation states that "This precludes error-prone constructions like Set('abc') & 'cbs' in favor of the more readable Set('abc').intersection('cbs')." In the second example, a first set is needed to do the intersection, then 'cbs' gets typecast into a set (although I guess so was 'abc'). Then should the first inputs also be typecast as sets? ---------- files: test_comparison.py messages: 282036 nosy: nyoshimizu priority: normal severity: normal status: open title: Type checking in set comparisons. type: behavior versions: Python 2.7, Python 3.5 Added file: http://bugs.python.org/file45694/test_comparison.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 14:54:36 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 19:54:36 +0000 Subject: [issue24015] timeit should start with 1 loop, not 10 In-Reply-To: <1429536484.03.0.469371276206.issue24015@psf.upfronthosting.co.za> Message-ID: <1480449276.56.0.411685395777.issue24015@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: That was implemented in issue28240. $ time ./python -m timeit "import time; time.sleep(1.0)" 1 loop, best of 5: 1 sec per loop real 0m6.176s user 0m0.160s sys 0m0.004s ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Enhance the timeit module: display average +- std dev instead of minimum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 15:00:52 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 29 Nov 2016 20:00:52 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1480446087.58.0.651702619577.issue28754@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Stefan Krah added the comment: > Julien, the syntax converters look pretty clever. Do we need AC > everywhere though? Please see previous comments for advantages of AC (signature object, docstring, speed). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 15:02:27 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 29 Nov 2016 20:02:27 +0000 Subject: [issue28834] Type checking in set comparisons. In-Reply-To: <1480449187.13.0.345778529202.issue28834@psf.upfronthosting.co.za> Message-ID: <1480449747.22.0.891984102113.issue28834@psf.upfronthosting.co.za> SilentGhost added the comment: You seem to be misunderstanding how the intersection/union/etc are supposed to be used: >>> ab = {'a', 'b'} >>> ab.intersection('bc') {'b'} Using set.intersection (where set is a built-in class, rather than an instance thereof) requires the first argument to be set (which is the actual instance of set class). This is no different from usage of any other class / object across Python, however, it is highly uncommon. ---------- nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 15:14:35 2016 From: report at bugs.python.org (nyoshimizu) Date: Tue, 29 Nov 2016 20:14:35 +0000 Subject: [issue28834] Type checking in set comparisons. In-Reply-To: <1480449187.13.0.345778529202.issue28834@psf.upfronthosting.co.za> Message-ID: <1480450475.46.0.785085786878.issue28834@psf.upfronthosting.co.za> nyoshimizu added the comment: I see. Sorry & thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 15:14:56 2016 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 29 Nov 2016 20:14:56 +0000 Subject: [issue28833] cross compilation of third-party extension modules In-Reply-To: <1480431100.4.0.611325572748.issue28833@psf.upfronthosting.co.za> Message-ID: <1480450496.27.0.991135817978.issue28833@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 15:22:37 2016 From: report at bugs.python.org (Stefan Krah) Date: Tue, 29 Nov 2016 20:22:37 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480450957.93.0.680914477048.issue28754@psf.upfronthosting.co.za> Stefan Krah added the comment: Signature and docstring can be done manually with very little effort. Currently METH_FASTCALL is AC only, but I hope that will change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 15:32:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 20:32:13 +0000 Subject: [issue26861] shutil.copyfile() doesn't close the opened files In-Reply-To: <1461678435.64.0.223785102956.issue26861@psf.upfronthosting.co.za> Message-ID: <1480451533.1.0.0392584029327.issue26861@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As I see, shutil.copyfile() uses the "with" statements and closes files just after copying. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 15:36:56 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 29 Nov 2016 20:36:56 +0000 Subject: [issue28820] Typo in section 6 of the Python 3.4 documentation In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za> Message-ID: <1480451816.92.0.648785521188.issue28820@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Just OOC, what version of English are the docs supposed to use? In American English, noun vs. verb doesn't matter, it's always "practice" (there is no such word as "practise"). In this case it doesn't matter (it's a noun, and everyone agrees on the spelling), but is there a defined standard? ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 15:40:45 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 29 Nov 2016 20:40:45 +0000 Subject: [issue28833] cross compilation of third-party extension modules In-Reply-To: <1480431100.4.0.611325572748.issue28833@psf.upfronthosting.co.za> Message-ID: <1480452045.62.0.824247134318.issue28833@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > This approach will not work with a "multiarch" enabled environment, and break cross builds on Debian and Ubuntu. No, the patch does not break cross builds on Debian and Ubuntu, unless you can demonstrate it does. > Afaics, the proposal assumes that the python executable for the target architecture is installed (which it is not for the multiarch cross-build layout), and that each target architecture has to be identified by it's own directory tree (again, not in the multiarch environment, you can install multiple targets into the same path). No, you are mistaken, the path name of the build tree may be used to cross build third-party extension modules as stated in case a) of msg281993, and this should also work with debian. BTW the same code is run to cross build a standard library extension module and a third-party extension module, and obviously python is not yet installed by the time the standard library extension modules are built ;-) > The idea here is to use the platform identifier which we already had in the trunk before the PLATDIR was removed (the multiarch id or if not defined the platform). So by having a specifier, you could deduce a path, or a -python-config executable and you're done. No need to know about a path directly. Of course python cross builds would have to install the -python-config executable or symlink. It is not clear why, because debian has this multiarch design, this should constrain our build system to follow their paradigm. After all, debian has already found some ways to cross-build the extension modules for their supported multiarch platforms since it is not possible, as of today, with upstream CPython. > Minor issue: please s/xbuild/cross_build/. Agreed. > > * The sysconfigdata file name was terminated with a dangling > > underscore when 'multiarch' is not defined. > > That only solves part of the problem in that the kernel/os version gets encoded as well, e.g. gnukfreebsd9, gnukfreebsd10, which is nasty when the version of your runtime and build time kernel differ. No idea what is the problem you are refering to. It cannot be the "dangling underscore" problem since this is a cosmetic issue. Please explain. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 15:43:23 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 29 Nov 2016 20:43:23 +0000 Subject: [issue28833] cross compilation of third-party extension modules In-Reply-To: <1480431100.4.0.611325572748.issue28833@psf.upfronthosting.co.za> Message-ID: <1480452203.94.0.0993069754066.issue28833@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- nosy: +Chi Hsuan Yen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 15:43:32 2016 From: report at bugs.python.org (R. David Murray) Date: Tue, 29 Nov 2016 20:43:32 +0000 Subject: [issue28820] Typo in section 6 of the Python 3.4 documentation In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za> Message-ID: <1480452212.4.0.598146958378.issue28820@psf.upfronthosting.co.za> R. David Murray added the comment: We at least used to point to Apple's style guide. I'm not sure where we point at the moment (it's in the documentation somewhere :). But yes, it's pretty much formal American English, though I'm sure there are places where other spelling has crept in. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 15:46:06 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 20:46:06 +0000 Subject: [issue27142] Default int value with xmlrpclib / xmlrpc.client In-Reply-To: <1464387462.23.0.765030008479.issue27142@psf.upfronthosting.co.za> Message-ID: <1480452366.34.0.197100787197.issue27142@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This format doesn't conform the XML-RPC specification. Adding the support of it is a new feature. The question is whether there is a need of this feature. Are there some common XML-RPC servers or clients that produce such format? ---------- type: behavior -> enhancement versions: +Python 3.7 -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 15:52:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 29 Nov 2016 20:52:34 +0000 Subject: [issue25750] tp_descr_get(self, obj, type) is called without owning a reference to "self" In-Reply-To: <1448654213.28.0.807225788685.issue25750@psf.upfronthosting.co.za> Message-ID: <1480452754.94.0.890700693116.issue25750@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 16:17:43 2016 From: report at bugs.python.org (Julien Palard) Date: Tue, 29 Nov 2016 21:17:43 +0000 Subject: [issue28795] Misleading stating, that SIGINT handler is installed by default In-Reply-To: <1480026357.5.0.735730414686.issue28795@psf.upfronthosting.co.za> Message-ID: <1480454263.77.0.888548154382.issue28795@psf.upfronthosting.co.za> Julien Palard added the comment: Proposed as patches but english is not my native language so please review carefully. ---------- keywords: +patch Added file: http://bugs.python.org/file45695/issue28795-tip.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 16:17:55 2016 From: report at bugs.python.org (Julien Palard) Date: Tue, 29 Nov 2016 21:17:55 +0000 Subject: [issue28795] Misleading stating, that SIGINT handler is installed by default In-Reply-To: <1480026357.5.0.735730414686.issue28795@psf.upfronthosting.co.za> Message-ID: <1480454275.55.0.946108338161.issue28795@psf.upfronthosting.co.za> Changes by Julien Palard : Added file: http://bugs.python.org/file45696/issue28795-2.7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 16:32:36 2016 From: report at bugs.python.org (John Helour) Date: Tue, 29 Nov 2016 21:32:36 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1480455156.18.0.136420773176.issue24339@psf.upfronthosting.co.za> John Helour added the comment: > Please also check whether it's not possible to reuse the charmap codec functions we have I've found nothing useful, maybe you (as the author) can find something really useful which can improve code readability or increase the performance. Please look at the newest codec version, particularly on line: tmp += bytearray(encoding_map[c], 'latin1', 'ignore') It is about extended ascii inheritance. Is it reliable and fast enough? ---------- Added file: http://bugs.python.org/file45697/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 16:34:29 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 29 Nov 2016 21:34:29 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480455269.3.0.16642617986.issue28754@psf.upfronthosting.co.za> Martin Panter added the comment: If adding proper support for hi=None, maybe lo=None should also be supported. Also, I would think the main Doc/library/bisect.rst documentation needs updating, and a test and What?s New entry added. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 17:26:10 2016 From: report at bugs.python.org (Wolfgang Maier) Date: Tue, 29 Nov 2016 22:26:10 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1480458370.87.0.464804467858.issue15533@psf.upfronthosting.co.za> Wolfgang Maier added the comment: Just found issue15451, which reports a similar inconsistency between Windows and POSIX for 'PATH' provided through the Popen env parameter as for cwd. It seems that, on POSIX-platforms, the PATH environment variable passed through env affects the executable lookup if executable does *not* contain a dirname, but on Windows the new PATH never affects executable lookup. So, again, relative executable paths are causing platform-specific behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 17:55:39 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 29 Nov 2016 22:55:39 +0000 Subject: [issue26861] shutil.copyfile() doesn't close the opened files In-Reply-To: <1461678435.64.0.223785102956.issue26861@psf.upfronthosting.co.za> Message-ID: <1480460139.64.0.358793478544.issue26861@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Agreed. 2.7 source is definitely using with: https://hg.python.org/cpython/file/2.7/Lib/shutil.py#l82 ---------- nosy: +josh.r status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 18:12:42 2016 From: report at bugs.python.org (Jan Lachnitt) Date: Tue, 29 Nov 2016 23:12:42 +0000 Subject: [issue15533] subprocess.Popen(cwd) documentation In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za> Message-ID: <1480461162.86.0.593170800296.issue15533@psf.upfronthosting.co.za> Jan Lachnitt added the comment: Thank Wolfgang Maier for reminding this issue and providing various details and observations. Having taken a look at my old comments (and at others' comments, too), I feel that the cwd issue deserves a clearer description. Let's use the following simple C program as the callee: #include #include int main(int argc, char* argv[]) { char cwd[FILENAME_MAX+1]; for (int i = 0; i < argc; ++i) printf("argv[%d] = %s\n", i, argv[i]); getcwd(cwd, FILENAME_MAX); printf("cwd = %s\n", cwd); return 0; } As is evident, this program merely prints its arguments and working directory. I have built it using gcc, called it "print_argv+cwd", and placed it in the "subdir" subdirectory of the current directory. Next, let's use the following Python 3 script for testing: import os from subprocess import run # substitute run->call in Python < 3.5 prg_name = 'print_argv+cwd' if os.name == 'nt': prg_name += '.exe' else: prg_name = os.path.join('.',prg_name) dir_name = 'subdir' def execute(path, cwd): print('Executing "{}" in "{}":'.format(path,cwd)) try: run([path], cwd=cwd) # substitute run->call in Python < 3.5 except Exception as err: print(type(err).__qualname__+':', err) print('Script\'s cwd =', os.getcwd()) execute(prg_name, dir_name) execute(os.path.join(dir_name,prg_name), dir_name) execute(os.path.abspath(os.path.join(dir_name,prg_name)), dir_name) Output on Linux with Python 3.5.2: Script's cwd = /home/jenda/Bug reports/Python/subprocess Executing "./print_argv+cwd" in "subdir": argv[0] = ./print_argv+cwd cwd = /home/jenda/Bug reports/Python/subprocess/subdir Executing "subdir/./print_argv+cwd" in "subdir": FileNotFoundError: [Errno 2] No such file or directory: 'subdir/./print_argv+cwd' Executing "/home/jenda/Bug reports/Python/subprocess/subdir/print_argv+cwd" in "subdir": argv[0] = /home/jenda/Bug reports/Python/subprocess/subdir/print_argv+cwd cwd = /home/jenda/Bug reports/Python/subprocess/subdir Output on Windows with Python 3.5.2: Script's cwd = C:\Users\Jenda\Bug reports\Python\subprocess Executing "print_argv+cwd.exe" in "subdir": FileNotFoundError: [WinError 2] Syst?m nem??e nal?zt uveden? soubor Executing "subdir\print_argv+cwd.exe" in "subdir": argv[0] = subdir\print_argv+cwd.exe cwd = C:\Users\Jenda\Bug reports\Python\subprocess\subdir Executing "C:\Users\Jenda\Bug reports\Python\subprocess\subdir\print_argv+cwd.exe" in "subdir": argv[0] = C:\Users\Jenda\Bug reports\Python\subprocess\subdir\print_argv+cwd.exe cwd = C:\Users\Jenda\Bug reports\Python\subprocess\subdir Summary: On Linux, subprocess.run (or call or Popen) behaves correctly, in accordance with current documentation. On Windows, both possible relative paths produce incorrect results. With the first one, relative to "subdir", Python fails to find the executable. With the other one, relative to the script's cwd, Python actually executes the program, but argv[0] is inconsistent with cwd. Imagine that the called program wants to resolve its own path: It joins cwd and argv[0] and gets "C:\Users\Jenda\Bug reports\Python\subprocess\subdir\subdir\print_argv+cwd.exe", which is an incorrect (and nonexistent) path. This is why the cwd issue is not just a documentation issue. The only option working correctly on Windows is the last one, using absolute path of the executable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 18:39:00 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Nov 2016 23:39:00 +0000 Subject: [issue28427] WeakValueDictionary next bug (with multithreading) In-Reply-To: <1476354989.22.0.575160455599.issue28427@psf.upfronthosting.co.za> Message-ID: <1480462739.99.0.875633426357.issue28427@psf.upfronthosting.co.za> Antoine Pitrou added the comment: One possibility would be to always delay removals (always put them in _pending_removals). We would then have to enforce removals from time to time, but synchronously. ---------- nosy: +pitrou, tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 18:39:52 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 29 Nov 2016 23:39:52 +0000 Subject: [issue28427] WeakValueDictionary next bug (with multithreading) In-Reply-To: <1476354989.22.0.575160455599.issue28427@psf.upfronthosting.co.za> Message-ID: <1480462792.73.0.294833949976.issue28427@psf.upfronthosting.co.za> Antoine Pitrou added the comment: (or we bite the bullet and add a C helper function for the atomic test-and-delete thing) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 18:54:50 2016 From: report at bugs.python.org (=?utf-8?q?Jan_Pokorn=C3=BD?=) Date: Tue, 29 Nov 2016 23:54:50 +0000 Subject: [issue20215] socketserver.TCPServer can not listen IPv6 address In-Reply-To: <1389319382.42.0.481013787618.issue20215@psf.upfronthosting.co.za> Message-ID: <1480463690.24.0.745087749943.issue20215@psf.upfronthosting.co.za> Changes by Jan Pokorn? : ---------- nosy: +jpokorny _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 19:27:39 2016 From: report at bugs.python.org (Xavier Combelle) Date: Wed, 30 Nov 2016 00:27:39 +0000 Subject: [issue26363] __builtins__ propagation is misleading described in exec and eval documentation In-Reply-To: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za> Message-ID: <1480465659.63.0.455369110798.issue26363@psf.upfronthosting.co.za> Xavier Combelle added the comment: It is not the dictionary of builtin module, which is inserted in , but the current __builtin__ global which happen to be normally the dictionnary of builtin. Hence in the following code, the builtins propagation works has expected. >>> eval("""eval('spam("hello world")',{})""",{"__builtins__":{"eval":eval,"spam":print}}) hello world ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 19:29:28 2016 From: report at bugs.python.org (Thomas Robitaille) Date: Wed, 30 Nov 2016 00:29:28 +0000 Subject: [issue28835] Change in behavior when overriding warnings.showwarning and with catch_warnings(record=True) Message-ID: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za> New submission from Thomas Robitaille: In Python 3.5, the following code: import warnings def deal_with_warning(*args, **kwargs): print("warning emitted") with warnings.catch_warnings(record=True): warnings.showwarning = deal_with_warning warnings.warn("This is a warning") results in "warning emitted" being printed to the terminal. In Python 3.6 however (at least in 3.6b1), nothing is printed, meaning that ``deal_with_warning`` is not getting called. I bisected the CPython history and tracked it down to the changes in this issue: https://bugs.python.org/issue26568 However it doesn't look like this was an intentional change in behavior, since it says in the description of that issue: "For backward compatibility, warnings.showmsg() calls warnings.showwarning() if warnings.showwarning() was replaced. Same for warnings.formatmsg(): call warnings.formatwarning() if replaced." So I believe this is a bug? (since backward-compatibility is not preserved). If not, should the change in behavior be mentioned in the changelog? ---------- messages: 282056 nosy: Thomas.Robitaille priority: normal severity: normal status: open title: Change in behavior when overriding warnings.showwarning and with catch_warnings(record=True) versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 20:52:58 2016 From: report at bugs.python.org (Decorater) Date: Wed, 30 Nov 2016 01:52:58 +0000 Subject: [issue28836] Throw concurrent.futures.TimeoutError instead of concurrent.futures.__base.TimeoutError Message-ID: <1480470778.51.0.100994440264.issue28836@psf.upfronthosting.co.za> New submission from Decorater: So, concurrent.futures.TimeoutError subclasses concurrent.futures.__base.TimeoutError. Why not have asyncio throw that instead of the __base class for Timeout Error? There is a huge issue with this for starters for those know knows this they cannot handle it easily without having to use that private class in the Error handler which is totally unclean practice. It is also unclean to raise that exception in asyncio at least change it to concurrent.futures.TimeoutError or asyncio.TimeoutError. This change would be much beneficial for projects that has to handle as many exceptions as possible to tell the end user that an exception happens custom based on what was thrown. With this it could benefit everyone who use the parts of asyncio that can throw such exceptions. I hope you guys would agree with my idea to clean up the parts of asyncio that throws these as it becomes tricky if people don't like to use private functions of another python code file in the standard library in their code or even as little as possible. It happens in python versions from 3.4 to 3.5.2 and can get annoying. ---------- components: Library (Lib), asyncio messages: 282057 nosy: Decorater, gvanrossum, yselivanov priority: normal severity: normal status: open title: Throw concurrent.futures.TimeoutError instead of concurrent.futures.__base.TimeoutError versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 21:07:35 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 30 Nov 2016 02:07:35 +0000 Subject: [issue28836] Throw concurrent.futures.TimeoutError instead of concurrent.futures.__base.TimeoutError In-Reply-To: <1480470778.51.0.100994440264.issue28836@psf.upfronthosting.co.za> Message-ID: <1480471655.37.0.327337450581.issue28836@psf.upfronthosting.co.za> Guido van Rossum added the comment: concurrent.futures.TimeoutError and concurrent.futures.__base.TimeoutError are the same class. So there is nothing to do here. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 21:09:13 2016 From: report at bugs.python.org (Decorater) Date: Wed, 30 Nov 2016 02:09:13 +0000 Subject: [issue28836] Throw concurrent.futures.TimeoutError instead of concurrent.futures.__base.TimeoutError In-Reply-To: <1480470778.51.0.100994440264.issue28836@psf.upfronthosting.co.za> Message-ID: <1480471753.85.0.340167112729.issue28836@psf.upfronthosting.co.za> Decorater added the comment: I handle concurrent.futures.TimeoutError on my coroutine that is fired with create_task yet it sitll don't handle it though... so it still is a issue.... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 21:11:31 2016 From: report at bugs.python.org (Decorater) Date: Wed, 30 Nov 2016 02:11:31 +0000 Subject: [issue28836] Throw concurrent.futures.TimeoutError instead of concurrent.futures.__base.TimeoutError In-Reply-To: <1480470778.51.0.100994440264.issue28836@psf.upfronthosting.co.za> Message-ID: <1480471891.53.0.314087407944.issue28836@psf.upfronthosting.co.za> Decorater added the comment: Here is my corouytine and the traceback on it to verify my issue too: Task exception was never retrieved future: exception=TimeoutError()> Traceback (most recent call last): File "asyncio\tasks.py", line 239, in _step File "E:\Users\Elsword\Desktop\DecoraterBot\Async\resources\Dependencies\DecoraterBotCore\commands\botvoicecommands.py", line 257, in __load self.voice = yield from self.bot.join_voice_channel(self.vchannel) File "discord\client.py", line 3166, in join_voice_channel File "asyncio\tasks.py", line 396, in wait_for concurrent.futures._base.TimeoutError @async def __load(self): """ Makes bot able to join a voice channel when the commands are loaded. """ try: vchannel_2 = str(self.botvoicechannel['Bot_Current_Voice_Channel'][0]) vmserver = str(self.botvoicechannel['Bot_Current_Voice_Channel'][1]) vmchannel = str(self.botvoicechannel['Bot_Current_Voice_Channel'][2]) self.voice_message_server_name = str(self.botvoicechannel['Bot_Current_Voice_Channel'][3]) self.vchannel_name = str(self.botvoicechannel['Bot_Current_Voice_Channel'][4]) self.vchannel = discord.Object(id=vchannel_2) self.voice_message_server = discord.Object(id=vmserver) self.voice_message_channel = discord.Object(id=vmchannel) try: self.voice = yield from self.bot.join_voice_channel(self.vchannel) self.verror = False except discord.errors.ConnectionClosed: pass except discord.errors.InvalidArgument: self.voice_message_server_name = None self.vchannel_name = None self.vchannel = None self.voice_message_server = None self.voice_message_channel = None self.voice = None self.verror = True except BotErrors.CommandTimeoutError: yield from self.bot.send_message(self.voice_message_channel, content=str( self.bot.botmessages['reload_commands_voice_channels_bypass2'][0])) self.voice_message_server_name = None self.vchannel_name = None self.vchannel = None self.voice_message_server = None self.voice_message_channel = None self.voice = None self.verror = True except RuntimeError: self.voice_message_server_name = None self.vchannel_name = None self.vchannel = None self.voice_message_server = None self.voice = None self.verror = True msgdata = str(self.bot.botmessages['reload_commands_voice_channels_bypass2'][1]) yield from self.bot.send_message(self.voice_message_channel, content=msgdata) self.voice_message_channel = None if self.verror is not True: message_data = str(self.bot.botmessages['reload_commands_voice_channels_bypass2'][2]).format( self.vchannel_name) yield from self.bot.send_message(self.voice_message_channel, content=message_data) except IndexError: self.voice_message_server_name = None self.vchannel_name = None self.vchannel = None self.voice_message_server = None self.voice_message_channel = None self.voice = None except discord.errors.ClientException: pass # already in a voice channel so lots not set those values to None. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 21:12:20 2016 From: report at bugs.python.org (Decorater) Date: Wed, 30 Nov 2016 02:12:20 +0000 Subject: [issue28836] Throw concurrent.futures.TimeoutError instead of concurrent.futures.__base.TimeoutError In-Reply-To: <1480470778.51.0.100994440264.issue28836@psf.upfronthosting.co.za> Message-ID: <1480471940.36.0.306093778531.issue28836@psf.upfronthosting.co.za> Decorater added the comment: oh wait nvm ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 21:13:48 2016 From: report at bugs.python.org (Decorater) Date: Wed, 30 Nov 2016 02:13:48 +0000 Subject: [issue28836] Throw concurrent.futures.TimeoutError instead of concurrent.futures.__base.TimeoutError In-Reply-To: <1480470778.51.0.100994440264.issue28836@psf.upfronthosting.co.za> Message-ID: <1480472028.44.0.10520024557.issue28836@psf.upfronthosting.co.za> Decorater added the comment: Wait actually BotErrors.CommandTimeoutError cubaclasses concurrent.futures.TimeoutError ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 23:01:14 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 30 Nov 2016 04:01:14 +0000 Subject: [issue28754] Argument Clinic for bisect.bisect_left In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za> Message-ID: <1480478474.79.0.536067535396.issue28754@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > If adding proper support for hi=None, maybe lo=None should > also be supported. That would be gratuitous. Lo already has a reasonable, useful, and self-explanatory value. This would add more complexity to the signature while reducing clarity. I really don't want to see calls like bisect(arr, x, None). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 29 23:53:13 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 30 Nov 2016 04:53:13 +0000 Subject: [issue27142] Default int value with xmlrpclib / xmlrpc.client In-Reply-To: <1464387462.23.0.765030008479.issue27142@psf.upfronthosting.co.za> Message-ID: <1480481593.73.0.877197536972.issue27142@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 02:26:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 30 Nov 2016 07:26:37 +0000 Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection faulty In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za> Message-ID: <1480490797.59.0.491593207756.issue5322@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 02:46:21 2016 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 30 Nov 2016 07:46:21 +0000 Subject: [issue27647] Update Windows build to Tcl/Tk 8.6.6 In-Reply-To: <1469737194.88.0.144648917966.issue27647@psf.upfronthosting.co.za> Message-ID: <1480491981.37.0.571859549827.issue27647@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Doesn't seem terribly urgent, so maybe not 2.7.13. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 03:01:34 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 30 Nov 2016 08:01:34 +0000 Subject: [issue27647] Update Windows build to Tcl/Tk 8.6.6 In-Reply-To: <1469737194.88.0.144648917966.issue27647@psf.upfronthosting.co.za> Message-ID: <1480492894.95.0.734204087595.issue27647@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why not? 8.5.15 is 3 years old. There were 4 bugfix releases since it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 04:18:55 2016 From: report at bugs.python.org (Armin Rigo) Date: Wed, 30 Nov 2016 09:18:55 +0000 Subject: [issue11145] '%o' % user-defined instance In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za> Message-ID: <1480497535.81.0.366279160331.issue11145@psf.upfronthosting.co.za> Armin Rigo added the comment: I reviewed your patch again. It does look good after all: I find only one issue---it seems I implied there were several ones but I can't find more. The issue is that PyString_AsString(result) will succeed if 'result' is a unicode. Then you call PyString_GET_SIZE(result), which gives nonsense for unicode objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 04:28:03 2016 From: report at bugs.python.org (Mark Harris) Date: Wed, 30 Nov 2016 09:28:03 +0000 Subject: [issue28781] On Installation of 3.5 Python get error message In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za> Message-ID: <1480498083.89.0.713366808924.issue28781@psf.upfronthosting.co.za> Mark Harris added the comment: This is everything I have in my temp file that I could possibly send you, hope it helps. ---------- Added file: http://bugs.python.org/file45698/Python 4.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 04:34:57 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 30 Nov 2016 09:34:57 +0000 Subject: [issue28832] Reduce memset in dict creation In-Reply-To: <1480424215.77.0.617126562471.issue28832@psf.upfronthosting.co.za> Message-ID: <1480498497.22.0.961429775785.issue28832@psf.upfronthosting.co.za> Changes by INADA Naoki : Added file: http://bugs.python.org/file45699/default.json.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 04:37:38 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 30 Nov 2016 09:37:38 +0000 Subject: [issue28832] Reduce memset in dict creation In-Reply-To: <1480424215.77.0.617126562471.issue28832@psf.upfronthosting.co.za> Message-ID: <1480498658.01.0.743236525524.issue28832@psf.upfronthosting.co.za> INADA Naoki added the comment: I ran pyperformance again on more large machine (Azure D2 -> D4) for more robust result. $ ./python-default -m perf compare_to default.json.gz patched.json.gz -G Slower (4): - xml_etree_generate: 425 ms +- 18 ms -> 442 ms +- 19 ms: 1.04x slower - call_method: 25.7 ms +- 0.9 ms -> 26.1 ms +- 1.3 ms: 1.02x slower - xml_etree_iterparse: 345 ms +- 17 ms -> 349 ms +- 20 ms: 1.01x slower - chameleon: 44.9 ms +- 1.9 ms -> 45.5 ms +- 2.1 ms: 1.01x slower Faster (39): - scimark_sor: 874 ms +- 32 ms -> 811 ms +- 33 ms: 1.08x faster - unpickle_pure_python: 1.41 ms +- 0.07 ms -> 1.31 ms +- 0.08 ms: 1.08x faster - raytrace: 2.19 sec +- 0.07 sec -> 2.05 sec +- 0.04 sec: 1.07x faster - sympy_integrate: 78.3 ms +- 9.2 ms -> 73.1 ms +- 4.8 ms: 1.07x faster - pickle_dict: 105 us +- 11 us -> 98.5 us +- 4.4 us: 1.06x faster - html5lib: 385 ms +- 21 ms -> 362 ms +- 16 ms: 1.06x faster - pathlib: 80.5 ms +- 5.1 ms -> 76.1 ms +- 3.4 ms: 1.06x faster - pickle: 38.1 us +- 2.7 us -> 36.0 us +- 2.9 us: 1.06x faster - sqlite_synth: 15.7 us +- 0.8 us -> 14.8 us +- 0.9 us: 1.06x faster - meteor_contest: 318 ms +- 18 ms -> 301 ms +- 12 ms: 1.06x faster - hexiom: 37.4 ms +- 1.9 ms -> 35.5 ms +- 1.8 ms: 1.05x faster - telco: 34.6 ms +- 2.1 ms -> 32.9 ms +- 1.4 ms: 1.05x faster - go: 957 ms +- 35 ms -> 914 ms +- 36 ms: 1.05x faster - regex_compile: 702 ms +- 24 ms -> 671 ms +- 23 ms: 1.05x faster - regex_dna: 421 ms +- 14 ms -> 403 ms +- 15 ms: 1.04x faster - genshi_xml: 314 ms +- 9 ms -> 301 ms +- 13 ms: 1.04x faster - tornado_http: 664 ms +- 29 ms -> 636 ms +- 27 ms: 1.04x faster - sqlalchemy_imperative: 103 ms +- 9 ms -> 98.6 ms +- 7.8 ms: 1.04x faster - dulwich_log: 265 ms +- 16 ms -> 254 ms +- 10 ms: 1.04x faster - richards: 291 ms +- 15 ms -> 279 ms +- 14 ms: 1.04x faster - json_dumps: 45.2 ms +- 2.5 ms -> 43.5 ms +- 1.8 ms: 1.04x faster - scimark_lu: 768 ms +- 40 ms -> 738 ms +- 32 ms: 1.04x faster - mako: 65.9 ms +- 3.9 ms -> 63.4 ms +- 2.1 ms: 1.04x faster - logging_simple: 52.9 us +- 3.5 us -> 51.0 us +- 2.0 us: 1.04x faster - regex_effbot: 7.64 ms +- 0.48 ms -> 7.36 ms +- 0.43 ms: 1.04x faster - pickle_pure_python: 2.08 ms +- 0.13 ms -> 2.01 ms +- 0.09 ms: 1.04x faster - scimark_monte_carlo: 414 ms +- 26 ms -> 399 ms +- 20 ms: 1.04x faster - unpack_sequence: 196 ns +- 11 ns -> 189 ns +- 6 ns: 1.04x faster - logging_silent: 1.17 us +- 0.07 us -> 1.13 us +- 0.05 us: 1.04x faster - sympy_expand: 1.68 sec +- 0.06 sec -> 1.62 sec +- 0.06 sec: 1.03x faster - call_simple: 20.9 ms +- 1.0 ms -> 20.3 ms +- 0.9 ms: 1.03x faster - nqueens: 411 ms +- 19 ms -> 401 ms +- 19 ms: 1.03x faster - sympy_str: 762 ms +- 29 ms -> 743 ms +- 23 ms: 1.03x faster - pidigits: 488 ms +- 18 ms -> 476 ms +- 12 ms: 1.02x faster - logging_format: 62.2 us +- 3.2 us -> 60.8 us +- 3.0 us: 1.02x faster - sympy_sum: 351 ms +- 18 ms -> 343 ms +- 16 ms: 1.02x faster - spectral_norm: 413 ms +- 21 ms -> 405 ms +- 18 ms: 1.02x faster - float: 464 ms +- 18 ms -> 456 ms +- 19 ms: 1.02x faster - python_startup_no_site: 15.2 ms +- 0.8 ms -> 15.0 ms +- 0.7 ms: 1.01x faster Benchmark hidden because not significant (21): 2to3, call_method_slots, call_method_unknown, chaos, crypto_pyaes, deltablue, django_template, fannkuch, genshi_text, json_loads, nbody, pickle_list, python_startup, regex_v8, scimark_fft, scimark_sparse_mat_mult, sqlalchemy_declarative, unpickle, unpickle_list, xml_etree_parse, xml_etree_process ---------- Added file: http://bugs.python.org/file45700/patched.json.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 04:47:59 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 30 Nov 2016 09:47:59 +0000 Subject: [issue11145] '%o' % user-defined instance In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za> Message-ID: <1480499279.58.0.599680206476.issue11145@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Good catch Armin! Thank you for your review. Updated patch uses PyString_AsStringAndSize() and adds a check that result is exact str before changing it in-place. ---------- Added file: http://bugs.python.org/file45701/issue11145_5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 04:51:10 2016 From: report at bugs.python.org (Armin Rigo) Date: Wed, 30 Nov 2016 09:51:10 +0000 Subject: [issue11145] '%o' % user-defined instance In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za> Message-ID: <1480499470.91.0.574758694997.issue11145@psf.upfronthosting.co.za> Armin Rigo added the comment: Looks ok now! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 05:08:01 2016 From: report at bugs.python.org (INADA Naoki) Date: Wed, 30 Nov 2016 10:08:01 +0000 Subject: [issue28832] Reduce memset in dict creation In-Reply-To: <1480424215.77.0.617126562471.issue28832@psf.upfronthosting.co.za> Message-ID: <1480500481.1.0.711914034845.issue28832@psf.upfronthosting.co.za> INADA Naoki added the comment: > I think that clearing 120 bytes at a time is faster than clear it later entry-by-entry. Ah, my word was wrong. This patch skips zero clear entirely. In pseudo code: // When allocating PyDictKeyObject. - memset(dk_entries, 0, sizeof(dk_entries)); // When inserting new item. n = dk_nentries++ e = &dk_entries[dk_nentries++]; e->me_hash = hash; e->me_key = key; if (split_table) { + e->me_value = NULL; ma_values[n] = value; } else { e->me_value = value; } > Your patch removes some asserts, this looks not good. This patch fills dk_entries with 0xcc when Py_DEBUG is enabled. It can find unintentional access to value which comes from reused memory. I'll search more points I can insert effective asserts. > Could your provide microbenchmarks that show the largest speed up and the largest slow down? So we would see what type of code gets the benefit. Avoiding cache pollution is more important than avoiding 120byte memset in this case. It's difficult to write simple micro benchmark to show effects of cache pollution... $ ./python-patched -m perf timeit --rigorous --compare-to `pwd`/python-default --duplicate 8 -- '{}' python-default: ......................................... 44.6 ns +- 2.4 ns python-patched: ......................................... 44.1 ns +- 1.8 ns Median +- std dev: [python-default] 44.6 ns +- 2.4 ns -> [python-patched] 44.1 ns +- 1.8 ns: 1.01x faster ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 05:21:14 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 30 Nov 2016 10:21:14 +0000 Subject: [issue28820] Typo in section 6 of the Python 3.4 documentation In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za> Message-ID: <20161130102111.27153.96982.D28F87D7@psf.io> Roundup Robot added the comment: New changeset 4f24641cd030 by Martin Panter in branch '2.7': Issue #28820: Fix spelling of ?practice? as a noun https://hg.python.org/cpython/rev/4f24641cd030 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 05:34:13 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 30 Nov 2016 10:34:13 +0000 Subject: [issue28820] Typo in section 6 of the Python 3.4 documentation In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za> Message-ID: <1480502053.87.0.0852076039279.issue28820@psf.upfronthosting.co.za> Martin Panter added the comment: I?m waiting for the 3.6 release candidate before pushing to the Py 3 branches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 05:55:40 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 30 Nov 2016 10:55:40 +0000 Subject: [issue22039] PyObject_SetAttr doesn't mention value = NULL In-Reply-To: <1406051790.64.0.0676928180206.issue22039@psf.upfronthosting.co.za> Message-ID: <1480503340.27.0.349839333598.issue22039@psf.upfronthosting.co.za> Martin Panter added the comment: As of Issue 25701, the null-to-delete feature is documented as being deprecated in favour of calling the related Del functions or macros. There was a python-dev thread at . I?m not sure if that is good enough, or do we need to e.g. clarify that the deprecation is only at the API (C header) level, and not the ABI level? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 06:04:58 2016 From: report at bugs.python.org (Carsten) Date: Wed, 30 Nov 2016 11:04:58 +0000 Subject: [issue28837] 2to3 does not wrap zip correctly Message-ID: <1480503898.29.0.0471565347052.issue28837@psf.upfronthosting.co.za> New submission from Carsten: The following Python 2.7 code is not converted correctly to Python 3 by 2to3: c = [(1, 10), (2, 20)] # get a tuple with the first entries of every tuple in c, # i.e. (1, 2) x = zip(*c)[0] print x The result is c = [(1, 10), (2, 20)] # get a tuple with the first entries of every tuple in c, # i.e. (1, 2) x = zip(*c)[0] print(x) However running it with python3 gives the following exception Traceback (most recent call last): File "result.py", line 7, in x = zip(*c)[0] TypeError: 'zip' object is not subscriptable Tested with 2to3-2.7 and 2to3-3.4 on debian stable (jessie) ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 282075 nosy: cvk priority: normal severity: normal status: open title: 2to3 does not wrap zip correctly type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 06:06:32 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 30 Nov 2016 11:06:32 +0000 Subject: [issue25701] Document that tp_setattro and tp_setattr are used for deleting attributes In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za> Message-ID: <20161130110629.31378.53383.7941CC84@psf.io> Roundup Robot added the comment: New changeset 83e3c863594c by Martin Panter in branch '2.7': Issue #25701: Document that some C APIs can both set and delete items https://hg.python.org/cpython/rev/83e3c863594c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 06:11:14 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 30 Nov 2016 11:11:14 +0000 Subject: [issue25701] Document that tp_setattro and tp_setattr are used for deleting attributes In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za> Message-ID: <1480504274.3.0.579101216476.issue25701@psf.upfronthosting.co.za> Martin Panter added the comment: I made one minor change: element ? slice ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 06:13:57 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 30 Nov 2016 11:13:57 +0000 Subject: [issue28838] Uniformize argument names of "call" functions Message-ID: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za> New submission from STINNER Victor: See python-dev thread about my changeset 7efddbf1aa70: https://mail.python.org/pipermail/python-dev/2016-November/146885.html Serhiy asked me to revert it. It's now reverted by the revision 20bb8babc505. So, here is my change as a patch to review it. See the thread for my rationale on argument names. -- Uniformize argument names of "call" functions * Callable object: callable, o, callable_object => func * Object for method calls: o => obj * Method name: name or nameid => method Cleanup also the C code: * Don't initialize variables to NULL if they are not used before their first assignement * Add braces for readability ---------- components: Interpreter Core files: call.patch keywords: patch messages: 282078 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: Uniformize argument names of "call" functions type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file45702/call.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 06:14:06 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 30 Nov 2016 11:14:06 +0000 Subject: [issue28838] Uniformize argument names of "call" functions (C API) In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za> Message-ID: <1480504446.43.0.0285992433585.issue28838@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Uniformize argument names of "call" functions -> Uniformize argument names of "call" functions (C API) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 06:32:47 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 30 Nov 2016 11:32:47 +0000 Subject: [issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with PyMem_Malloc() Message-ID: <1480505567.26.0.13388381207.issue28839@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch is a minor optimization for _PyFunction_FastCallDict(): avoid the creation of a tuple to pass keyword arguments, use a simple C array allocated by PyMem_Malloc(). It also uses a small stack of 80 bytes (2*5*sizeof(PyObject*)) allocated on the C stack to pass up to 5 keyword arguments (5 key+value pairs): it avoids completely the allocation on the heap memory I wrote _PyFunction_FastCallDict() (issue #27809): the code was based on function_call() which also uses PyTuple_New(). When I wrote the function, I didn't notice that PyEval_EvalCodeEx() doesn't expect a Python tuple object, but a C array. The patch also modifies function_call() to call _PyFunction_FastCallDict(), so it gets _PyFunction_FastCallDict() optimizations. ---------- files: fastcalldict.patch keywords: patch messages: 282079 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: _PyFunction_FastCallDict(): replace PyTuple_New() with PyMem_Malloc() type: performance versions: Python 3.7 Added file: http://bugs.python.org/file45703/fastcalldict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 06:49:26 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 30 Nov 2016 11:49:26 +0000 Subject: [issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with PyMem_Malloc() In-Reply-To: <1480505567.26.0.13388381207.issue28839@psf.upfronthosting.co.za> Message-ID: <1480506566.65.0.668770988141.issue28839@psf.upfronthosting.co.za> STINNER Victor added the comment: fastcalldict.patch avoided INCREF/DECREF on keyword keys and values. This is wrong: we must hold strong references because the keyword dictionary can be technically modified: see issue #2016 and test_extcall. Hum, I'm quite sure that it's not the first time that I was bitten by this bug. That's maybe why I didn't try to implement this optimization the first time. fastcalldict-2.patch keeps INCREF/DECREF and so doesn't crash on test_extcall. ---------- Added file: http://bugs.python.org/file45704/fastcalldict-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 07:27:13 2016 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 30 Nov 2016 12:27:13 +0000 Subject: [issue28838] Uniformize argument names of "call" functions (C API) In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za> Message-ID: <1480508833.61.0.377617270605.issue28838@psf.upfronthosting.co.za> Nick Coghlan added the comment: Independently of anything else, any changes made to the parameter names in the implementation should be reflected in the API docs: https://docs.python.org/3/c-api/object.html#c.PyCallable_Check A style guide addition to PEP 7 would also be useful as a record of the preferred naming scheme. That said, one of the problems you're up against inside the C code base is that we really do have some code evaluation APIs that only work with true Python functions, while a abstract APIs handle arbitrary callables. Reserving "func" for the former cases helps make it clear which is which. By contrast, end user code (and even the standard library) can usually get away with saying "func" even when they mean "arbitrary callable" without causing confusion, as there's only the one Python-level call syntax. So perhaps one way to start here would be to propose an addition to https://www.python.org/dev/peps/pep-0007/#naming-conventions specifically for dealing with callable parameters in APIs that covers parameters that are: - arbitrary callables - specifically a synchronous Python function - method names (whether as const char *, PyObject *, or _Py_Identifier) ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 09:05:00 2016 From: report at bugs.python.org (piotr.sk) Date: Wed, 30 Nov 2016 14:05:00 +0000 Subject: [issue28840] IDLE not handling long lines correctly Message-ID: <1480514700.66.0.957548851102.issue28840@psf.upfronthosting.co.za> New submission from piotr.sk: IDLE included in Python 3.5.2 does not display correctly files with very long lines under Windows 7. Attached example file does not show the third line correctly in Windows 7. These lines are part of a script that attempts to parse the messages. Even though very long lines are not according to Python convention, they should be displayed correctly in the editor. If Notepad does it correctly, I would assume IDLE can handle long lines too ;-) ---------- assignee: terry.reedy components: IDLE files: test.py messages: 282082 nosy: piotr.sk, terry.reedy priority: normal severity: normal status: open title: IDLE not handling long lines correctly type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file45705/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 09:19:38 2016 From: report at bugs.python.org (John Helour) Date: Wed, 30 Nov 2016 14:19:38 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1480515578.14.0.546256143082.issue24339@psf.upfronthosting.co.za> Changes by John Helour : Removed file: http://bugs.python.org/file45697/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 09:22:36 2016 From: report at bugs.python.org (John Helour) Date: Wed, 30 Nov 2016 14:22:36 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1480515756.67.0.751204363225.issue24339@psf.upfronthosting.co.za> Changes by John Helour : Added file: http://bugs.python.org/file45706/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 09:23:19 2016 From: report at bugs.python.org (John Helour) Date: Wed, 30 Nov 2016 14:23:19 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1480515799.81.0.402311255306.issue24339@psf.upfronthosting.co.za> Changes by John Helour : Removed file: http://bugs.python.org/file45706/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 09:24:21 2016 From: report at bugs.python.org (John Helour) Date: Wed, 30 Nov 2016 14:24:21 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1480515861.8.0.608036479212.issue24339@psf.upfronthosting.co.za> Changes by John Helour : Added file: http://bugs.python.org/file45707/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 09:29:26 2016 From: report at bugs.python.org (James Matthews) Date: Wed, 30 Nov 2016 14:29:26 +0000 Subject: [issue18777] Cannot compile _ssl.c using openssl > 1.0 In-Reply-To: <1376890287.78.0.562230025847.issue18777@psf.upfronthosting.co.za> Message-ID: <1480516166.56.0.630745016078.issue18777@psf.upfronthosting.co.za> James Matthews added the comment: This is marked as fixed but am still seeing this error in 2.7.12 on HP-UX 11.31. /opt/hp-gcc64-4.7.1/bin/gcc -pthread -shared build/temp.hp-ux-B.11.31-9000-800-2.7/root/build/Python-2.7.12/Modules/_ssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.hp-ux-B.11.31-9000-800-2.7/_ssl.sl /usr/lib/pa20_64/dld.sl: Unsatisfied code symbol 'CRYPTO_THREADID_set_callback' in load module 'build/lib.hp-ux-B.11.31-9000-800-2.7/_ssl.sl'. /bin/sh: 23510 Killed gmake: *** [sharedmods] Error 137 ---------- nosy: +James Matthews _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 09:38:49 2016 From: report at bugs.python.org (John Helour) Date: Wed, 30 Nov 2016 14:38:49 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1480516729.77.0.0476777035206.issue24339@psf.upfronthosting.co.za> Changes by John Helour : Removed file: http://bugs.python.org/file45707/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 09:46:18 2016 From: report at bugs.python.org (John Helour) Date: Wed, 30 Nov 2016 14:46:18 +0000 Subject: [issue24339] iso6937 encoding missing In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za> Message-ID: <1480517178.1.0.462765740237.issue24339@psf.upfronthosting.co.za> John Helour added the comment: Please ignore my previous question about: tmp += bytearray(encoding_map[c], 'latin1', 'ignore') The latest version don't needs such encoding ... ---------- Added file: http://bugs.python.org/file45708/iso6937.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 10:33:04 2016 From: report at bugs.python.org (STINNER Victor) Date: Wed, 30 Nov 2016 15:33:04 +0000 Subject: [issue28838] Uniformize argument names of "call" functions (C API) In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za> Message-ID: <1480519984.28.0.962265546832.issue28838@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy: Can you please elaborate "Other changes looks not well justified too."? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 10:57:05 2016 From: report at bugs.python.org (Amrith Kumar) Date: Wed, 30 Nov 2016 15:57:05 +0000 Subject: [issue28841] urlparse.urlparse() parses invalid URI without generating an error (examples provided) Message-ID: <1480521425.85.0.782501279738.issue28841@psf.upfronthosting.co.za> New submission from Amrith Kumar: The urlparse library incorrectly accepts a URI which specifies an invalid host identifier. Example: http://www.example.com:/abc Looking at the URI specifications, this is an invalid URI. By definition, you are supposed to specify a "hostport" and a hostport is defined as: https://www.w3.org/Addressing/URL/uri-spec.html hostport host [ : port ] The BNF indicates that : is only valid if a port is also specified. See current behavior; I submit to you that this should generate an exception. https://gist.github.com/anonymous/8504f160ff90649890b5a2a82f8028b0 ---------- components: Library (Lib) messages: 282086 nosy: amrith priority: normal severity: normal status: open title: urlparse.urlparse() parses invalid URI without generating an error (examples provided) type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 12:23:09 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Nov 2016 17:23:09 +0000 Subject: [issue28427] WeakValueDictionary next bug (with multithreading) In-Reply-To: <1476354989.22.0.575160455599.issue28427@psf.upfronthosting.co.za> Message-ID: <1480526589.86.0.404648102167.issue28427@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a pure Python patch. ---------- Added file: http://bugs.python.org/file45709/issue28427-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 12:24:15 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Nov 2016 17:24:15 +0000 Subject: [issue28427] WeakValueDictionary next bug (with multithreading) In-Reply-To: <1476354989.22.0.575160455599.issue28427@psf.upfronthosting.co.za> Message-ID: <1480526655.18.0.824581510989.issue28427@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note the issue with this patch is that it may keep keys (with dead values) alive longer than necessary: - this may prevent memory consumption from decreasing - this may keep alive some system resources This is ok when keys are small simple objects (strings or tuples), though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 12:31:20 2016 From: report at bugs.python.org (SilentGhost) Date: Wed, 30 Nov 2016 17:31:20 +0000 Subject: [issue28841] urlparse.urlparse() parses invalid URI without generating an error (examples provided) In-Reply-To: <1480521425.85.0.782501279738.issue28841@psf.upfronthosting.co.za> Message-ID: <1480527080.18.0.550022630644.issue28841@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +orsenthil versions: +Python 3.5, Python 3.6, Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 13:05:09 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Nov 2016 18:05:09 +0000 Subject: [issue28427] WeakValueDictionary next bug (with multithreading) In-Reply-To: <1476354989.22.0.575160455599.issue28427@psf.upfronthosting.co.za> Message-ID: <1480529109.64.0.404245326716.issue28427@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch showing the "atomic C function" approach. It will avoid the aforementioned memory growth in the common case, in exchange for a small bit of additional C code. ---------- Added file: http://bugs.python.org/file45710/issue28427-atomic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 13:05:15 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 30 Nov 2016 18:05:15 +0000 Subject: [issue28427] WeakValueDictionary next bug (with multithreading) In-Reply-To: <1476354989.22.0.575160455599.issue28427@psf.upfronthosting.co.za> Message-ID: <1480529115.79.0.475812643054.issue28427@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 13:26:14 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 30 Nov 2016 18:26:14 +0000 Subject: [issue28840] IDLE not handling long lines correctly In-Reply-To: <1480514700.66.0.957548851102.issue28840@psf.upfronthosting.co.za> Message-ID: <1480530374.13.0.3843557259.issue28840@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The lengths of the strings on the 3 lines are 644, 432, and 7728, as determined by adding 4th line to print them. In Win10, the editor window shows. MESSAGE_1 = '02.... MESSAGE_2 = 'Ag.... MESSAGE_1 = The problem is the blank after '=' on line 3. If I put the cursor anywhere in the false blank, the line is filled in up to the cursor. IDLE uses tkinter, which wraps tk. It is known that tk Text widgets do not handle long lines well. There is a previous issue (which I cannot find at the moment) about long lines (in Shell) making scrolling slow, Printing the third line in Shell, where long lines are wrapped, works. I do not remember seeing this disappearing text problem before. Putting the string without blanks on a line by itself, the limit for correct behavior (the beginning of the line appears when the file is freshly loaded) is 2730 chars, including the quotes. I guess no one inclined to report a problem has tried anything longer before. The need for such long literals in a code file is unusual, but definitely legitimate for testing. On stackoverflow, I constantly urge people to develop programs that read and parse data by putting sample data in the code file. (If not in a separate test file.) The workaround for literals over 2728 chars is to use Python's implicit string literal concatenation. For instance, "s = 'a' 'b' 'c'" results in "s == 'abc'". Using this, you could define your third string thusly: m3 = ( '' '' '' '' ) # 7728 chars IDLE's column indicator makes this easy enough. Not wrapping longs lines in the editor is intentional. So is not adding a horizontal scrollbar (not my decision). But if adding one solves this problem, I will reconsider. In the meanwhile, I will consider a new IDLE doc section "2.6 Tkinter limitations", which could also mention non-display of astral characters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 13:26:34 2016 From: report at bugs.python.org (David Wolever) Date: Wed, 30 Nov 2016 18:26:34 +0000 Subject: [issue28842] PyInstanceMethod_Type isn't hashable Message-ID: <1480530394.0.0.669928514028.issue28842@psf.upfronthosting.co.za> New submission from David Wolever: The PyInstanceMethod_Type, unlike all other method types, isn't hashable. It seems like the code exists, it's just been commented out: https://github.com/python/cpython/blame/c30098c8c6014f3340a369a31df9c74bdbacc269/Objects/classobject.c#L569 This came up here: https://github.com/wolever/pprintpp/issues/18 And Christian Heimes doesn't remember why it was commented out: https://twitter.com/ChristianHeimes/status/803900655324790784 ---------- messages: 282091 nosy: wolever priority: normal severity: normal status: open title: PyInstanceMethod_Type isn't hashable type: behavior versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 13:44:53 2016 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 30 Nov 2016 18:44:53 +0000 Subject: [issue28843] asyncio.Task implemented in C loses __traceback__ for exceptions Message-ID: <1480531493.68.0.0437538826486.issue28843@psf.upfronthosting.co.za> New submission from Yury Selivanov: When a coroutine wrapped in a C asyncio.Task raises an Exception, the Task fails to correctly save the __traceback__. ---------- assignee: yselivanov components: asyncio files: task_tb.patch keywords: patch messages: 282092 nosy: gvanrossum, inada.naoki, ned.deily, yselivanov priority: release blocker severity: normal status: open title: asyncio.Task implemented in C loses __traceback__ for exceptions versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45711/task_tb.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 14:20:25 2016 From: report at bugs.python.org (Big Stone) Date: Wed, 30 Nov 2016 19:20:25 +0000 Subject: [issue28791] update sqlite to 3.15.2 In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1480533625.39.0.665765245394.issue28791@psf.upfronthosting.co.za> Big Stone added the comment: I understand the decision. Yet it always baffles me that a version correcting known bugs is not included at beta stage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 14:32:56 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 30 Nov 2016 19:32:56 +0000 Subject: [issue28842] PyInstanceMethod_Type isn't hashable In-Reply-To: <1480530394.0.0.669928514028.issue28842@psf.upfronthosting.co.za> Message-ID: <1480534376.72.0.179545873923.issue28842@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Note: It's a little strange that instancemethod as a type sticks around even though literally nothing in Python uses it. Is there some reason we kept it in the 3.x transition? Extension types are using it, so I guess we can't drop it now, but I'm trying to figure out why it was kept around, allowing the extensions to develop dependencies on it. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 14:35:18 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 30 Nov 2016 19:35:18 +0000 Subject: [issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with PyMem_Malloc() In-Reply-To: <1480505567.26.0.13388381207.issue28839@psf.upfronthosting.co.za> Message-ID: <1480534518.55.0.809357320208.issue28839@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Given you can't avoid the refcounting overhead, how much does this really help? Are there meaningful benefits in microbenchmarks? I'd worry that unconditional allocation from PyMem_Malloc might lose out relative to PyTuple_New, which is likely to not involve memory allocation at all (pulling from tuple free list). ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 14:37:04 2016 From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Bultrowicz?=) Date: Wed, 30 Nov 2016 19:37:04 +0000 Subject: [issue28733] Show how to use mock_open in modules other that __main__ In-Reply-To: <1479475072.8.0.338397997846.issue28733@psf.upfronthosting.co.za> Message-ID: <1480534624.21.0.0201346075346.issue28733@psf.upfronthosting.co.za> Micha? Bultrowicz added the comment: Ok, I've checked again and now patching "file_writer.open" works. I have no idea what I was doing wrong the last time I checked... So I guess I'll close the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 14:37:19 2016 From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Bultrowicz?=) Date: Wed, 30 Nov 2016 19:37:19 +0000 Subject: [issue28733] Show how to use mock_open in modules other that __main__ In-Reply-To: <1479475072.8.0.338397997846.issue28733@psf.upfronthosting.co.za> Message-ID: <1480534639.43.0.688789960283.issue28733@psf.upfronthosting.co.za> Changes by Micha? Bultrowicz : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 14:46:35 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 30 Nov 2016 19:46:35 +0000 Subject: [issue28791] update sqlite to 3.15.2 In-Reply-To: <1480017928.89.0.263397799958.issue28791@psf.upfronthosting.co.za> Message-ID: <1480535195.34.0.790561721612.issue28791@psf.upfronthosting.co.za> Steve Dower added the comment: I don't think we have anyone actively tracking SQLite right now, like we do for OpenSSL. All it really needs is someone to prepare and test the patch during the beta period, and to be available in case more fixes are required. At this stage, we're in the RC period, so there really needs to be a recall-level issue to justify a change, and even then we'd prefer a maintenance update rather than a feature update (e.g. 3.14.3 vs. 3.15.x - if it's not a recall-level issue for SQLite, then it's hard to call it a recall-level issue for Python). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 14:49:16 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 30 Nov 2016 19:49:16 +0000 Subject: [issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with PyMem_Malloc() In-Reply-To: <1480505567.26.0.13388381207.issue28839@psf.upfronthosting.co.za> Message-ID: <1480535356.11.0.367289245835.issue28839@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Minor correction: No allocation when small stack used, so you'd only see (possibly) regressions with 6+ keyword arguments (assuming the tuple free list applies for tuples that large). Admittedly a minor concern; keyword processing is already pretty slow, and large numbers of keywords being passed are likely a tiny fraction of call cases, so I'd guess microbenchmarks wouldn't show a big change, and broad benchmarks would be completely unaffected, but worth checking. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 15:25:08 2016 From: report at bugs.python.org (Adam) Date: Wed, 30 Nov 2016 20:25:08 +0000 Subject: [issue28844] Pickling units Message-ID: <1480537508.92.0.871816124551.issue28844@psf.upfronthosting.co.za> New submission from Adam: See below code to show you can't round-trip units through pickle: Python 3.5.1 |Anaconda 4.0.0 (64-bit)| (default, Feb 16 2016, 09:49:46) [MSC v.1900 64 bit AMD64)] import units u = units.unit('myUnit') x = u(3.0) import pickle f = open('C:/temp/what.pkl', 'wb') pickle.dump(x, f) f.close() f = open('C:/temp/what.pkl', 'rb') y = pickle.load(f) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) in () ----> 1 y = pickle.load(f) TypeError: __new__() missing 2 required positional arguments: 'num' and 'unit' ---------- messages: 282099 nosy: abz64 priority: normal severity: normal status: open title: Pickling units type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 15:28:29 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 30 Nov 2016 20:28:29 +0000 Subject: [issue28844] Pickling units In-Reply-To: <1480537508.92.0.871816124551.issue28844@psf.upfronthosting.co.za> Message-ID: <1480537709.25.0.690246008508.issue28844@psf.upfronthosting.co.za> R. David Murray added the comment: unit is not part of the stdlib. Please report this to whatever the upstream is for the package and/or to Anaconda. ---------- nosy: +r.david.murray resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 15:29:20 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 30 Nov 2016 20:29:20 +0000 Subject: [issue28844] Pickling units In-Reply-To: <1480537508.92.0.871816124551.issue28844@psf.upfronthosting.co.za> Message-ID: <1480537760.55.0.92861556071.issue28844@psf.upfronthosting.co.za> R. David Murray added the comment: To clarify: it looks from your report like units hasn't implemented pickling support. It isn't automatic for all classes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 16:09:56 2016 From: report at bugs.python.org (Peter Eckersley) Date: Wed, 30 Nov 2016 21:09:56 +0000 Subject: [issue28742] argparse.ArgumentDefaultsHelpFormatter sometimes provides inaccurate documentation of defaults, so they should be overrideable In-Reply-To: <1479514629.23.0.218870455687.issue28742@psf.upfronthosting.co.za> Message-ID: <1480540196.36.0.392825644385.issue28742@psf.upfronthosting.co.za> Peter Eckersley added the comment: Thanks for your feedback Paul! I agree your proposed implementation strategy would probably be saner; I'll revise the patch to use that approach or something like it. As for the question of necessity, there are definitely more cases than just the store_false ones -- I documented these in the linked Certbot bug but very briefly they include: * Programs where the default value of a variable is "Ask interactively" if no flag is provided * Cases where the default value is the result of some complicated computation (for instance, reading it from a defaults file) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 16:14:04 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 30 Nov 2016 21:14:04 +0000 Subject: [issue28833] cross compilation of third-party extension modules In-Reply-To: <1480431100.4.0.611325572748.issue28833@psf.upfronthosting.co.za> Message-ID: <1480540444.73.0.942847413404.issue28833@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > I don't think that identifying the target by some path is the right way to go, and you should be able to identify the target by giving the target triplet as used by the configure parameters and then deduce the location from the target (or have an explicit location given). > > The idea here is to use the platform identifier which we already had in the trunk before the PLATDIR was removed (the multiarch id or if not defined the platform). So by having a specifier, you could deduce a path, or a -python-config executable and you're done. No need to know about a path directly. Of course python cross builds would have to install the -python-config executable or symlink. Hum, you still need to provide the native python interpreter with the _path_ to the -python-config executable that can be anywhere on the file system (its location is relative to the cross compiled build, not the native interpreter), so it seems that this contradicts your previous sentence saying "I don't think that identifying the target by some path is the right way to go". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 16:32:22 2016 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 30 Nov 2016 21:32:22 +0000 Subject: [issue28833] cross compilation of third-party extension modules In-Reply-To: <1480431100.4.0.611325572748.issue28833@psf.upfronthosting.co.za> Message-ID: <1480541542.68.0.294125189944.issue28833@psf.upfronthosting.co.za> Xavier de Gaye added the comment: So I suggest we start with this patch as it works for: * The standard library extension modules (for debian as well). * The third-party extension modules on platforms that have multiarch defined and on platforms that do not have multiarch defined (on debian systems one can only use the build directory for XBUILD_PYTHON_DIR, the other systems can use the three options described in msg281993). Then we can later extend the semantics of XBUILD_PYTHON_DIR to include the multiarch triplet if this is necessary for debian systems, unless the debian developers want to continue using the system they have developed and are currently using to cross compile third-party extension modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 16:40:33 2016 From: report at bugs.python.org (Eric N. Vander Weele) Date: Wed, 30 Nov 2016 21:40:33 +0000 Subject: [issue28845] Clean up known issues for AIX Message-ID: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za> New submission from Eric N. Vander Weele: This patch cleans up Misc/README.AIX for addressed known issues. Issues that have been marked fixed: #11184, #11185 Issues resolved by new AIX version: #1745108 Issues resolved, but not yet marked fixed/closed: #11188 Additionally, it looks like #10709 can be closed out as well. For #1745108 and #11188, I have verified they are addressed as of Python 3.5.2 on AIX 7.1 locally. The Python Buildbot is failing to build the curses module, but I believe Setup.local is needed for _curses and _curses_panel. I have gotten the aforementioned curses modules building locally and will figure out the appropriate channels getting Python's PPC64 AIX Buildbot updated independently. ---------- assignee: docs at python components: Documentation files: cleanup-readme-aix.patch keywords: patch messages: 282105 nosy: David.Edelsohn, docs at python, ericvw priority: normal severity: normal status: open title: Clean up known issues for AIX type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45712/cleanup-readme-aix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 16:42:13 2016 From: report at bugs.python.org (Zachary Ware) Date: Wed, 30 Nov 2016 21:42:13 +0000 Subject: [issue28845] Clean up known issues for AIX In-Reply-To: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za> Message-ID: <1480542133.88.0.539480880486.issue28845@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +Michael.Felt stage: -> patch review versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 16:55:01 2016 From: report at bugs.python.org (Julien Palard) Date: Wed, 30 Nov 2016 21:55:01 +0000 Subject: [issue28755] Rework syntax highlighing in howto/clinic.rst In-Reply-To: <1479679317.44.0.842687607942.issue28755@psf.upfronthosting.co.za> Message-ID: <1480542901.05.0.15877160458.issue28755@psf.upfronthosting.co.za> Julien Palard added the comment: Bump, 10 days later, hope this diff is still straightforward to merge. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 16:58:10 2016 From: report at bugs.python.org (Julien Palard) Date: Wed, 30 Nov 2016 21:58:10 +0000 Subject: [issue10444] A mechanism is needed to override waiting for Python threads to finish In-Reply-To: <1290002661.34.0.535369286873.issue10444@psf.upfronthosting.co.za> Message-ID: <1480543090.05.0.358368178106.issue10444@psf.upfronthosting.co.za> Julien Palard added the comment: If nobody has nothing to add on this issue, I think it just should be closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 17:17:28 2016 From: report at bugs.python.org (Julien Palard) Date: Wed, 30 Nov 2016 22:17:28 +0000 Subject: [issue26363] __builtins__ propagation is misleading described in exec and eval documentation In-Reply-To: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za> Message-ID: <1480544248.17.0.651044035028.issue26363@psf.upfronthosting.co.za> Julien Palard added the comment: Hi Xavier, > It is not the dictionary of builtin module, which is inserted in , but the current __builtin__ global It looks wrong, I'll even say the exact contrary: It _is_ the dictionary of builtin module which is inserted in, not the current __builtin__ global, with this proof: $ ./python Python 3.7.0a0 (default, Nov 29 2016, 11:20:17) [GCC 5.4.1 20161019] on linux Type "help", "copyright", "credits" or "license" for more information. >>> print(id(__builtins__), id(__builtins__.__dict__)) 140325888797784 140325888840368 >>> eval("""print(id(__builtins__))""", {}) 140325888840368 > the current __builtin__ global which happen to be normally the dictionnary of builtin. That's not necessarily true, according to [the builtins doc](https://docs.python.org/dev/library/builtins.html): > The value of __builtins__ is normally either this module or the value of this module?s __dict__ attribute. Typically: $ ./python Python 3.7.0a0 (default, Nov 29 2016, 11:20:17) [GCC 5.4.1 20161019] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import builtins >>> id(builtins), id(builtins.__dict__), id(__builtins__) (139706743340120, 139706743382704, 139706743340120) Here, __builtins__ is the module, not its dict. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 17:33:42 2016 From: report at bugs.python.org (Julien Palard) Date: Wed, 30 Nov 2016 22:33:42 +0000 Subject: [issue28845] Clean up known issues for AIX In-Reply-To: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za> Message-ID: <1480545222.91.0.976203842149.issue28845@psf.upfronthosting.co.za> Julien Palard added the comment: You're also removing: > * Python has not been fully tested on AIX when compiled as a 64 bit > application. I do not have an AIX at hand but can someone at least confirm that all test passes? Having a few issues fixed does not mean that Python has been fully tested. ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 17:44:38 2016 From: report at bugs.python.org (Julien Palard) Date: Wed, 30 Nov 2016 22:44:38 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1480545878.6.0.882484580881.issue20185@psf.upfronthosting.co.za> Julien Palard added the comment: Look like this has never been applied, any reason for this? Tip has probably highly diverged, but I may try to rebase it, should I? ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 18:00:02 2016 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 30 Nov 2016 23:00:02 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1480546802.53.0.202088945023.issue2771@psf.upfronthosting.co.za> Ezio Melotti added the comment: Testing PR linking ---------- pull_requests: +1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 18:00:47 2016 From: report at bugs.python.org (Eric N. Vander Weele) Date: Wed, 30 Nov 2016 23:00:47 +0000 Subject: [issue28845] Clean up known issues for AIX In-Reply-To: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za> Message-ID: <1480546847.88.0.417651304135.issue28845@psf.upfronthosting.co.za> Eric N. Vander Weele added the comment: > Having a few issues fixed does not mean that Python has been fully tested. I uploaded cleanup-readme-aix2.patch, which revives back the line removed in question and only removes lines which reference issues. I just noticed the results of Python's tests on my AIX box differ from Python's PPC64 Buildbot. I'll investigate separately and submit patches for getting the tests to pass, which then it may be more appropriate to remove that line. ---------- Added file: http://bugs.python.org/file45713/cleanup-readme-aix2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 18:18:41 2016 From: report at bugs.python.org (Julien Palard) Date: Wed, 30 Nov 2016 23:18:41 +0000 Subject: [issue17490] Improve ast.literal_eval test suite coverage In-Reply-To: <1363746875.32.0.0832947039866.issue17490@psf.upfronthosting.co.za> Message-ID: <1480547921.76.0.746483567505.issue17490@psf.upfronthosting.co.za> Julien Palard added the comment: > I also discovered several holes in the test suite coverage while refactoring it. Are they all tested in the current diff? ---------- nosy: +mdk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 18:26:09 2016 From: report at bugs.python.org (Julien Palard) Date: Wed, 30 Nov 2016 23:26:09 +0000 Subject: [issue28845] Clean up known issues for AIX In-Reply-To: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za> Message-ID: <1480548369.37.0.806025862563.issue28845@psf.upfronthosting.co.za> Julien Palard added the comment: Look like issue1745108 has only be closed for being "outdated" (msg240919 ), it does not clearly mean that the bug does no longer exists. Have you been able to test the example in it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 18:34:53 2016 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 30 Nov 2016 23:34:53 +0000 Subject: [issue28838] Uniformize argument names of "call" functions (C API) In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za> Message-ID: <1480548893.01.0.797665364086.issue28838@psf.upfronthosting.co.za> Eric V. Smith added the comment: Isn't this just a lot of churn for not a lot of benefit? I'm all for consistency, but you'll break patches on the bug tracker and externally maintained patches. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 18:37:26 2016 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 30 Nov 2016 23:37:26 +0000 Subject: [issue28841] urlparse.urlparse() parses invalid URI without generating an error (examples provided) In-Reply-To: <1480521425.85.0.782501279738.issue28841@psf.upfronthosting.co.za> Message-ID: <1480549046.22.0.683853733077.issue28841@psf.upfronthosting.co.za> Eric V. Smith added the comment: Can you please paste your code into a comment on this issue? Gist content has a habit of vanishing. Thanks! ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 18:47:12 2016 From: report at bugs.python.org (Amrith Kumar) Date: Wed, 30 Nov 2016 23:47:12 +0000 Subject: [issue28841] urlparse.urlparse() parses invalid URI without generating an error (examples provided) In-Reply-To: <1480521425.85.0.782501279738.issue28841@psf.upfronthosting.co.za> Message-ID: <1480549632.72.0.627777388824.issue28841@psf.upfronthosting.co.za> Amrith Kumar added the comment: As requested ... >>> urlparse.urlparse('http://www.google.com:/abc') ParseResult(scheme='http', netloc='www.google.com:', path='/abc', params='', query='', fragment='') I submit to you that this should generate an error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 18:57:38 2016 From: report at bugs.python.org (Steve Dower) Date: Wed, 30 Nov 2016 23:57:38 +0000 Subject: [issue28846] Add a ProviderKey to the installer bundle Message-ID: <1480550258.58.0.874105613934.issue28846@psf.upfronthosting.co.za> New submission from Steve Dower: Currently the installer bundles for 3.5 and later have an automatically generated dependency provider key. This makes it difficult for other installers to correctly depend on the bundle. For example, Visual Studio 2017 has an option to install CPython 3.5, but it cannot accurately determine when it is already installed, which may lead to Python being uninstalled unexpectedly. This is the purpose of the provider key - to provide a reliable key by which to reference the bundle. For 3.5.2 and earlier, the key is a GUID that changes each release, but really the key should be stable for each version that cannot be installed side-by-side. The change is to Tools/msi/bundle/bundle.wxs and adds the last attribute to this element: This will produce keys like "CPython-3.5", "CPython-3.5-32", "CPython-3.5-test" and "CPython-3.5-32-test" (the "-test" suffixed installers are never released, but may be produced by Tools/msi/build.bat). I haven't tested it yet, but I believe this change will also fix a minor issue where the web and non-web installers conflict, even when the versions match. Since it is important this metadata be consistent throughout the lifetime of a release, I'd like to get the change into Python 3.6.0rc1 after I've spent the time testing it. Ned - your thoughts? ---------- assignee: steve.dower components: Windows messages: 282118 nosy: ned.deily, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: Add a ProviderKey to the installer bundle type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 19:31:11 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 01 Dec 2016 00:31:11 +0000 Subject: [issue28841] urlparse.urlparse() parses invalid URI without generating an error (examples provided) In-Reply-To: <1480521425.85.0.782501279738.issue28841@psf.upfronthosting.co.za> Message-ID: <1480552271.92.0.614790089808.issue28841@psf.upfronthosting.co.za> Martin Panter added the comment: The Python documentation refers to RFC 3986, which allows an empty port string introduced by a colon, although it recommends against it: The ?port? subcomponent of ?authority? is designated by an optional port number in decimal following the host and delimited from it by a single colon. . . . URI producers and normalizers should omit the port component and its ?:? delimiter if ?port? is empty . . . What problem are you trying to solve by raising an error? See also Issue 20059, where accessing the ?port? field now raises ValueError for out-of-range values, and Issue 20271, discussing invalid URL handling more generally. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 19:33:37 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 01 Dec 2016 00:33:37 +0000 Subject: [issue28841] urlparse.urlparse() parses invalid URI without generating an error (examples provided) In-Reply-To: <1480521425.85.0.782501279738.issue28841@psf.upfronthosting.co.za> Message-ID: <1480552417.51.0.23857069814.issue28841@psf.upfronthosting.co.za> Martin Panter added the comment: Also, this is in direct contradiction to Issue 20270. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 19:39:41 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 01 Dec 2016 00:39:41 +0000 Subject: [issue28820] Typo in section 6 of the Python 3.4 documentation In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za> Message-ID: <1480552781.33.0.915874894055.issue28820@psf.upfronthosting.co.za> Berker Peksag added the comment: Ned can correct me if I'm wrong, but you can push documentation patches without waiting for 3.6.0rc1. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 19:41:28 2016 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 01 Dec 2016 00:41:28 +0000 Subject: [issue28841] urlparse.urlparse() parses invalid URI without generating an error (examples provided) In-Reply-To: <1480521425.85.0.782501279738.issue28841@psf.upfronthosting.co.za> Message-ID: <1480552888.96.0.222298127028.issue28841@psf.upfronthosting.co.za> Eric V. Smith added the comment: And note that there are tests that explicitly check that the colon with no port works (via issue 20270). Given that this behavior has been around for a while, and is explicitly allowed, I would recommend against changing this to an error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 20:18:20 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 01 Dec 2016 01:18:20 +0000 Subject: [issue28755] Rework syntax highlighing in howto/clinic.rst In-Reply-To: <1479679317.44.0.842687607942.issue28755@psf.upfronthosting.co.za> Message-ID: <1480555100.9.0.082298810073.issue28755@psf.upfronthosting.co.za> Martin Panter added the comment: It will apply to the 3.5 and 3.6 branches if I first backport revision 0a18d2cfeb52 (Issue 28753), which I think is valid. But I would wait until there is a branch for 3.6.1, and then commit to all three branches. (Ned asked for only release-critical changes to go into 3.6 at the moment.) On the other hand, Larry only applied the other patch to 3.7, so we could just do that again if people prefer. ---------- nosy: +martin.panter stage: -> commit review versions: +Python 3.5 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 20:33:16 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 01 Dec 2016 01:33:16 +0000 Subject: [issue28771] Update documented signatures of tp_get/setattr In-Reply-To: <1479815588.93.0.810601241454.issue28771@psf.upfronthosting.co.za> Message-ID: <20161201013312.31378.8835.BC83F9B7@psf.io> Roundup Robot added the comment: New changeset 2fd070fa6c15 by Martin Panter in branch '2.7': Issue #28771: Correct documentation of signatures using const https://hg.python.org/cpython/rev/2fd070fa6c15 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 20:52:36 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 01 Dec 2016 01:52:36 +0000 Subject: [issue28728] test_host_resolution in test_socket fails In-Reply-To: <1479407743.41.0.909577209709.issue28728@psf.upfronthosting.co.za> Message-ID: <1480557156.75.0.313006815724.issue28728@psf.upfronthosting.co.za> Martin Panter added the comment: Maybe you could factor out the first part of test_bad_address() that skips the test. It would only need to be used by negative test cases (that purposefully test invalid names). I presume positive tests would not need to be wrapped. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 21:12:44 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 01 Dec 2016 02:12:44 +0000 Subject: [issue28815] test_socket fails if /proc/modules is existent but not readable In-Reply-To: <1480263378.99.0.648069549511.issue28815@psf.upfronthosting.co.za> Message-ID: <1480558364.02.0.447214554385.issue28815@psf.upfronthosting.co.za> Martin Panter added the comment: This seems reasonable in general. Did you test this exact patch Patrila? It looks to me like you need to change ENOENT ? errno.ENOENT, etc. ---------- components: +Tests nosy: +martin.panter stage: -> patch review type: -> behavior versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 21:17:25 2016 From: report at bugs.python.org (Ned Deily) Date: Thu, 01 Dec 2016 02:17:25 +0000 Subject: [issue28846] Add a ProviderKey to the installer bundle In-Reply-To: <1480550258.58.0.874105613934.issue28846@psf.upfronthosting.co.za> Message-ID: <1480558645.07.0.382863235736.issue28846@psf.upfronthosting.co.za> Ned Deily added the comment: Sounds good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 21:28:15 2016 From: report at bugs.python.org (Ned Deily) Date: Thu, 01 Dec 2016 02:28:15 +0000 Subject: [issue28820] Typo in section 6 of the Python 3.4 documentation In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za> Message-ID: <1480559295.8.0.940921942212.issue28820@psf.upfronthosting.co.za> Ned Deily added the comment: Yes, there is no restriction on doc changes at the moment as long as they are relevant to 3.6.0. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 21:33:50 2016 From: report at bugs.python.org (Amrith Kumar) Date: Thu, 01 Dec 2016 02:33:50 +0000 Subject: [issue28841] urlparse.urlparse() parses invalid URI without generating an error (examples provided) In-Reply-To: <1480521425.85.0.782501279738.issue28841@psf.upfronthosting.co.za> Message-ID: <1480559630.06.0.810319384059.issue28841@psf.upfronthosting.co.za> Amrith Kumar added the comment: Eric, Martin, I'm sure this is an interpretation (and I'll be fair and give you both) that a URL of the form: http://hostname.domain.tld:/path should be held invalid. The rationale is per the section of the spec you quoted. The other side of the argument is that the hostname and port are defined as: hostname [ : port ] where port is defined as *DIGIT This implies that 0 digits is also valid. I submit to you that the ambiguity would be removed if they: - removed the paragraph telling people not to emit a : if there was no port, or - changing the port definition to 1*DIGIT Absent that, I believe that the paragraph implies that the intent was 1*DIGIT. And therefore a : with no following number should generate an error. I raise this because the behavior of urlparse() (the way it does things now) is being cited as the reason why other routines in OpenStack should handle this when the reason we were getting URL's with a : and no port was in fact an oversight. So, in hearing the rationalization as being that "urlparse() does it, so ..." I figured I'd come to the source and see if we could make urlparse() do things unambiguously. Now, if the reason it does this is because someone who came before me made the argument that a : with no port should be accepted, I guess I'm out of luck. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 22:02:02 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 01 Dec 2016 03:02:02 +0000 Subject: [issue28837] 2to3 does not wrap zip correctly In-Reply-To: <1480503898.29.0.0471565347052.issue28837@psf.upfronthosting.co.za> Message-ID: <1480561322.65.0.255390718025.issue28837@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- nosy: +benjamin.peterson versions: +Python 3.6, Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 22:12:44 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 01 Dec 2016 03:12:44 +0000 Subject: [issue26483] docs unclear on difference between str.isdigit() and str.isdecimal() In-Reply-To: <1457121897.81.0.495681677897.issue26483@psf.upfronthosting.co.za> Message-ID: <1480561964.97.0.622378458339.issue26483@psf.upfronthosting.co.za> Martin Panter added the comment: ?digits which do not form decimal radix forms? I see you have taken this from a Unicode document, but ?forming a form? seems a long way of saying very little. The difference seems a bit vague, but I gather that digits not in the Unicode ?decimal digit? category are often (always?) still decimal digits, but primarily used for a symbolic or typographical meaning more than in a plain number, e.g. superscripts, subscripts and other fonts, added circles and other decorations. ---------- stage: needs patch -> patch review versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 22:27:05 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 01 Dec 2016 03:27:05 +0000 Subject: [issue28728] test_host_resolution in test_socket fails In-Reply-To: <1479407743.41.0.909577209709.issue28728@psf.upfronthosting.co.za> Message-ID: <1480562825.09.0.745429901702.issue28728@psf.upfronthosting.co.za> Changes by Xiang Zhang : Added file: http://bugs.python.org/file45714/test_host_resolution.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 22:30:34 2016 From: report at bugs.python.org (Eryk Sun) Date: Thu, 01 Dec 2016 03:30:34 +0000 Subject: [issue26363] __builtins__ propagation is misleading described in exec and eval documentation In-Reply-To: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za> Message-ID: <1480563034.74.0.478986569543.issue26363@psf.upfronthosting.co.za> Eryk Sun added the comment: As shown above, exec and eval default to calling PyEval_GetBuiltins when the globals dict doesn't define '__builtins__'. PyEval_GetBuiltins uses the current frame's f_builtins. If there isn't a current frame, it defaults to the interpreter's builtins, which should be the dict of the builtins module. If exec and eval didn't do this, the default behavior would be to create a minimal f_builtins dict for the new frame. This dict only contains a reference to None, and it doesn't get set as '__builtins__' in globals. For example: from inspect import currentframe from ctypes import pythonapi, py_object g = py_object({'currentframe': currentframe}) code = py_object(compile('currentframe()', '', 'eval')) frame = pythonapi.PyEval_EvalCode(code, g, g) >>> frame.f_builtins {'None': None} >>> frame.f_globals {'currentframe': } This minimalist default isn't useful in general. exec and eval are saving people from the tedium of having to manually define a useful __builtins__ when passing a new globals. The frame object uses this __builtins__ to initialize its f_builtins. Also, it knows to look for __builtins__ as a module, as used by __main__: g = py_object({'currentframe': currentframe, '__builtins__': __builtins__}) frame = pythonapi.PyEval_EvalCode(code, g, g) >>> frame.f_builtins is vars(__builtins__) True ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 22:50:06 2016 From: report at bugs.python.org (Jonathan Ng) Date: Thu, 01 Dec 2016 03:50:06 +0000 Subject: [issue28847] dumbdbm should not commit if Message-ID: <1480564206.07.0.235501921998.issue28847@psf.upfronthosting.co.za> Changes by Jonathan Ng : ---------- nosy: Jonathan Ng priority: normal severity: normal status: open title: dumbdbm should not commit if type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 22:51:36 2016 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 01 Dec 2016 03:51:36 +0000 Subject: [issue17490] Improve ast.literal_eval test suite coverage In-Reply-To: <1363746875.32.0.0832947039866.issue17490@psf.upfronthosting.co.za> Message-ID: <1480564296.37.0.39874050679.issue17490@psf.upfronthosting.co.za> Nick Coghlan added the comment: I don't know if the suggested test suite diff gives full coverage, but unless other improvements have been made to those tests in the meantime, it should give more coverage than we have right now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 22:53:47 2016 From: report at bugs.python.org (Jonathan Ng) Date: Thu, 01 Dec 2016 03:53:47 +0000 Subject: [issue28847] dumbdbm should not commit if in read mode Message-ID: <1480564427.92.0.600594500998.issue28847@psf.upfronthosting.co.za> New submission from Jonathan Ng: Or at the very least, if there is an OSError in _update, an error should be raised instead of ignoring this error. In the current state of the code, if there was an OSError while reading the dirfile, the dirfile would be overwritten with a blank file when it is closed. ---------- title: dumbdbm should not commit if -> dumbdbm should not commit if in read mode _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 22:59:10 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 01 Dec 2016 03:59:10 +0000 Subject: [issue28728] test_host_resolution in test_socket fails In-Reply-To: <1479407743.41.0.909577209709.issue28728@psf.upfronthosting.co.za> Message-ID: <1480564750.33.0.424000440934.issue28728@psf.upfronthosting.co.za> Martin Panter added the comment: I think the original test is trying to ensure that an invalid numeric IP address results in an OSError. So changing it to skip the test on OSError does not seem wise. Also, Silent Ghost said that the problem was with gethostbyaddr(), not gethostbyname(). I was wondering if there was a separate way to detect the troublesome ISP environment, e.g. trying gethostbyname(bogus_domain). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 30 23:40:56 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 01 Dec 2016 04:40:56 +0000 Subject: [issue28841] urlparse.urlparse() parses invalid URI without generating an error (examples provided) In-Reply-To: <1480521425.85.0.782501279738.issue28841@psf.upfronthosting.co.za> Message-ID: <1480567256.24.0.451977773277.issue28841@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, I'm afraid so. But the rationale is presumably the same as it is in many RFCs: you should accept broken stuff if it can be interpreted unambiguously, but you should not *produce* the broken stuff. So I'd say the RFC is correct as quoted. It is then up to openstack whether or not it wants to accept such URLs in a given interface, and it if were me I'd base that decision on whether it was an 'internal' interface or an 'external' one. But you can also argue that even an external interface could be strict, depending on the application domain of the interface. urllib, on the other hand, needs to accept it, and we can't change it at this point for backward compatibility reasons if nothing else. Based on the RFC, one could argue that urlunsplit should omit the colon. That could break backward compatibility, too, though will a lot less likelyhood. So we could still fix it in 3.7 if we decide we should. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________