From report at bugs.python.org Tue Dec 1 00:31:34 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 01 Dec 2015 05:31:34 +0000 Subject: [issue25771] importlib: '.submodule' is not a relative name (no leading dot) Message-ID: <1448947894.1.0.971575571341.issue25771@psf.upfronthosting.co.za> New submission from Martin Panter: >>> import importlib.util >>> importlib.util.resolve_name(".submodule", None) Traceback (most recent call last): File "", line 1, in File "/home/proj/python/cpython/Lib/importlib/util.py", line 26, in resolve_name '(no leading dot)'.format(name)) ValueError: '.submodule' is not a relative name (no leading dot) This message sounds like nonsense. Perhaps the it should say something like: '.submodule' should be an absolute name (no leading dot) or: relative import of '.submodule' not allowed outside of a package ---------- keywords: easy messages: 255642 nosy: martin.panter priority: normal severity: normal status: open title: importlib: '.submodule' is not a relative name (no leading dot) type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 03:02:50 2015 From: report at bugs.python.org (Juchen Zeng) Date: Tue, 01 Dec 2015 08:02:50 +0000 Subject: [issue25772] Misleading descriptions about built-in type `super.` Message-ID: <1448956970.84.0.677978683679.issue25772@psf.upfronthosting.co.za> New submission from Juchen Zeng: A few days ago, I was learning built-in type `super` through [python official doc](https://docs.python.org/2/library/functions.html#super). And I was mislead by its documentation, in the part of how `__mro__` resolution works. Below is the part which confuse me: """ super(type[, object-or-type]) # ISSUE IRRELEVANT DOC OMITTED The __mro__ attribute of the type lists the method resolution search order used by both getattr() and super(). The attribute is dynamic and can change whenever the inheritance hierarchy is updated. """ >From the description of the doc we can see that `super()` takes two arguments, the first is `type` and the second is an optional `object-or-type`. So, when I saw the doc statement: `The __mro__ attribute of the type lists the method resolution search order used by both getattr() and super(). `, I naturally thought here the `type` refers to the compulsory first `type` argument. But after doing a series of [experiments][EXP_REF]. It turns out in `super()` was using the second `type`'s `__mro__` attribute! And if the second argument is an object, it will use `object.__class__.__mro__` as its resolution order. Unless a learner experimented it throughly like me, he will have lots of difficulty to figured out that `type` mentioned in the doc refers to the second optional argument. I think here the doc should be clearly specified that the second argument's `__mro__` is what super relies on. I suggest to add distinctions on arguments name or add more clarification informations in the doc here. By the way, the python3 document has the same issue. If you decided to fix this, maybe you want to fix its python3 version, too. [EXP_REF]: http://stackoverflow.com/questions/33890918/how-does-super-interacts-with-a-classs-mro-attribute-in-multiple-inheri/33891281#33891281 ---------- assignee: docs at python components: Documentation messages: 255643 nosy: Juchen Zeng, docs at python, eric.araujo, ezio.melotti, georg.brandl priority: normal severity: normal status: open title: Misleading descriptions about built-in type `super.` versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 04:09:42 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 01 Dec 2015 09:09:42 +0000 Subject: [issue25770] expose name, args, and kwargs from methodcaller In-Reply-To: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za> Message-ID: <1448960982.76.0.862615429286.issue25770@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Hi, I just tried your patch with the last revision and I have an error with the tests. stephane at sg1 ~/s/h/cpython> ./python -m test test_operator [1/1] test_operator Fatal Python error: ./Modules/_operator.c:975 object at 0x7ff804c2e3d8 has negative ref count -1 Current thread 0x00007ff806ee8700 (most recent call first): File "/home/stephane/src/hg.python.org/cpython/Lib/unittest/case.py", line 600 in run File "/home/stephane/src/hg.python.org/cpython/Lib/unittest/case.py", line 648 in __call__ File "/home/stephane/src/hg.python.org/cpython/Lib/unittest/suite.py", line 122 in run File "/home/stephane/src/hg.python.org/cpython/Lib/unittest/suite.py", line 84 in __call__ File "/home/stephane/src/hg.python.org/cpython/Lib/unittest/suite.py", line 122 in run File "/home/stephane/src/hg.python.org/cpython/Lib/unittest/suite.py", line 84 in __call__ File "/home/stephane/src/hg.python.org/cpython/Lib/unittest/suite.py", line 122 in run File "/home/stephane/src/hg.python.org/cpython/Lib/unittest/suite.py", line 84 in __call__ File "/home/stephane/src/hg.python.org/cpython/Lib/test/support/__init__.py", line 1679 in run File "/home/stephane/src/hg.python.org/cpython/Lib/test/support/__init__.py", line 1780 in _run_suite File "/home/stephane/src/hg.python.org/cpython/Lib/test/support/__init__.py", line 1814 in run_unittest File "/home/stephane/src/hg.python.org/cpython/Lib/test/libregrtest/runtest.py", line 161 in test_runner File "/home/stephane/src/hg.python.org/cpython/Lib/test/libregrtest/runtest.py", line 162 in runtest_inner File "/home/stephane/src/hg.python.org/cpython/Lib/test/libregrtest/runtest.py", line 126 in runtest File "/home/stephane/src/hg.python.org/cpython/Lib/test/libregrtest/main.py", line 295 in run_tests_sequential File "/home/stephane/src/hg.python.org/cpython/Lib/test/libregrtest/main.py", line 356 in run_tests File "/home/stephane/src/hg.python.org/cpython/Lib/test/libregrtest/main.py", line 392 in main File "/home/stephane/src/hg.python.org/cpython/Lib/test/libregrtest/main.py", line 433 in main File "/home/stephane/src/hg.python.org/cpython/Lib/test/libregrtest/main.py", line 455 in main_in_temp_cwd File "/home/stephane/src/hg.python.org/cpython/Lib/test/__main__.py", line 3 in File "/home/stephane/src/hg.python.org/cpython/Lib/runpy.py", line 85 in _run_code File "/home/stephane/src/hg.python.org/cpython/Lib/runpy.py", line 170 in _run_module_as_main fish: ?./python -m test test_operator? terminated by signal SIGABRT (Abort) stephane at sg1 ~/s/h/cpython> stephane at sg1 ~/s/h/cpython> hg tip changeset: 99407:734247d5d0f9 tag: tip parent: 99404:ac0f7ed0e94d parent: 99406:fee19d2d7713 user: Zachary Ware date: Mon Nov 30 22:57:22 2015 -0600 summary: Closes #25767: Merge with 3.5 ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 04:54:47 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 01 Dec 2015 09:54:47 +0000 Subject: [issue25772] Misleading descriptions about built-in type `super.` In-Reply-To: <1448956970.84.0.677978683679.issue25772@psf.upfronthosting.co.za> Message-ID: <1448963687.79.0.697216515749.issue25772@psf.upfronthosting.co.za> Martin Panter added the comment: I agree. I think Issue 23674 already covers this. I will try to propose some changes there. ---------- nosy: +martin.panter resolution: -> duplicate status: open -> closed superseder: -> super() documentation isn't very clear _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 04:57:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 Dec 2015 09:57:00 +0000 Subject: [issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448963820.71.0.787035997047.issue25698@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: http://buildbot.python.org/all/builders/PPC64LE%20Fedora%202.7/builds/164/steps/test/logs/stdio Failed a number of tests that directly or indirectly use copy_reg. First failed test is test_cpickle. ---------- title: test regressions introduced with the fix for #22995 -> The copy_reg module becomes unexpectedly empty in test_cpickle type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 06:00:16 2015 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Tue, 01 Dec 2015 11:00:16 +0000 Subject: [issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount In-Reply-To: <1448339024.55.0.65158482353.issue25717@psf.upfronthosting.co.za> Message-ID: <1448967616.41.0.689174404591.issue25717@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: The patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 06:40:40 2015 From: report at bugs.python.org (Xiadong Zhu) Date: Tue, 01 Dec 2015 11:40:40 +0000 Subject: [issue22138] patch.object doesn't restore function defaults In-Reply-To: <1407212040.69.0.583222239779.issue22138@psf.upfronthosting.co.za> Message-ID: <1448970040.02.0.851048421296.issue22138@psf.upfronthosting.co.za> Xiadong Zhu added the comment: How's the issue going on? The situation to mock function's ``__defaults__`` attribute is general, as default argument is determinate after function definition, when we need to test a function such as: def access_db(statement, backend=default_db_backend): return default_db_backend.execute(statement) that we must mock ``__defaults__`` attribute if we want to invoke it with default backend. It has one year past, though I could patch the ``_patch`` class but it's dirty, is the issue a defect can be fixed or unsolvable? ---------- nosy: +mailto1587 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 07:08:14 2015 From: report at bugs.python.org (Henry Gomersall) Date: Tue, 01 Dec 2015 12:08:14 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1448971694.46.0.0632911131831.issue4709@psf.upfronthosting.co.za> Henry Gomersall added the comment: I want to second Ralf's comments about both the need for this and it being easy to get. What is required to make this happen (specifically the easy to install build chain - pip install...)? It would be good to enumerate the outstanding issues. The current difficulty of building extensions on Windows should not be underestimated. Microsoft seem to change how their various tools work, with different updated SDKs and removing tools and changing things (even retrospectively) quite regularly. I've wasted quite a bit of time setting up windows machines to build the various flavours (bits and python version), only to find that the same strategy doesn't for some reason beyond my comprehension doesn't work on a different machine. Throw in different windows versions and the problem is pretty insurmountable and unsustainable. To be clear, the current situation surely cannot be worse than a MinGW situation. ---------- nosy: +Henry Gomersall _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 07:10:18 2015 From: report at bugs.python.org (Henry Gomersall) Date: Tue, 01 Dec 2015 12:10:18 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1448971818.11.0.146689417969.issue4709@psf.upfronthosting.co.za> Henry Gomersall added the comment: Of course, I mean: *To be clear, the MinGW situation surely cannot be worse than the current situation.* ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 08:16:07 2015 From: report at bugs.python.org (Duncan McBryde) Date: Tue, 01 Dec 2015 13:16:07 +0000 Subject: [issue4709] Mingw-w64 and python on windows x64 In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za> Message-ID: <1448975767.9.0.0825007949553.issue4709@psf.upfronthosting.co.za> Changes by Duncan McBryde : ---------- nosy: +Duncan McBryde _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 09:11:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 Dec 2015 14:11:18 +0000 Subject: [issue25177] OverflowError in statistics.mean when summing large floats In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za> Message-ID: <20151201141108.87889.39051@psf.io> Roundup Robot added the comment: New changeset 4bc9405c4f7b by Steven D'Aprano in branch '3.4': Fix for issue #25177 with the mean of very small and very large numbers. https://hg.python.org/cpython/rev/4bc9405c4f7b New changeset ed45a09e5a69 by Steven D'Aprano in branch '3.5': Fixed issue #25177, problems with the mean of very small and very large numbers. https://hg.python.org/cpython/rev/ed45a09e5a69 New changeset 0eeb39fc8ff5 by Steven D'Aprano in branch 'default': Issue #25177: Fixed problem with the mean of very small and very large numbers. https://hg.python.org/cpython/rev/0eeb39fc8ff5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 09:23:34 2015 From: report at bugs.python.org (Michael Foord) Date: Tue, 01 Dec 2015 14:23:34 +0000 Subject: [issue22138] patch.object doesn't restore function defaults In-Reply-To: <1407212040.69.0.583222239779.issue22138@psf.upfronthosting.co.za> Message-ID: <1448979814.14.0.0168024355085.issue22138@psf.upfronthosting.co.za> Michael Foord added the comment: Sean's patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 10:36:31 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 01 Dec 2015 15:36:31 +0000 Subject: [issue25768] compileall functions do not document return values In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za> Message-ID: <1448984191.33.0.669223517365.issue25768@psf.upfronthosting.co.za> Brett Cannon added the comment: At this point the return values are probably as official as they are going to be since these are such old functions. If you want to write a patch, Nicholas, please see https://docs.python.org/devguide/ for instructions on how to do that. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 10:42:22 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 01 Dec 2015 15:42:22 +0000 Subject: [issue25771] importlib: '.submodule' is not a relative name (no leading dot) In-Reply-To: <1448947894.1.0.971575571341.issue25771@psf.upfronthosting.co.za> Message-ID: <1448984542.84.0.278135442786.issue25771@psf.upfronthosting.co.za> Brett Cannon added the comment: So both proposed messages are correct depending on what you want to accomplish; it all depends on whether the leading dot was the mistake or the missing package was. And the message does make some sense if you read it more like "'.submodule' is not a relative name (drop the leading dot)". I do agree, though, it's hard to read as written. ---------- assignee: -> brett.cannon nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 10:44:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 Dec 2015 15:44:28 +0000 Subject: [issue25773] Deprecate deleting with PyObject_SetAttr, PyObject_SetAttrString and PySequence_SetItem Message-ID: <1448984668.36.0.0444302662987.issue25773@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: If the third argument of PyObject_SetAttr(), PyObject_SetAttrString() or PySequence_SetItem() is NULL, these functions delete an attribute or an item. This is rather undocumented implementation detail. There are special counterparts for deleting: PyObject_DelAttr(), PyObject_DelAttrString() and PySequence_DelItem(). May be worth to depre Proposed patch deprecates using these Set* functions for deleting and replaces them with appropriate Del* functions if needed. Discussion on Python-Dev: http://comments.gmane.org/gmane.comp.python.devel/155474 Issue that documents deleting with Set* APIs: issue25701. ---------- components: Interpreter Core files: PyObject_SetAttr_deleting.patch keywords: patch messages: 255655 nosy: gvanrossum, martin.panter, ncoghlan, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Deprecate deleting with PyObject_SetAttr, PyObject_SetAttrString and PySequence_SetItem type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file41200/PyObject_SetAttr_deleting.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 11:07:36 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 01 Dec 2015 16:07:36 +0000 Subject: [issue25772] Misleading descriptions about built-in `super.` In-Reply-To: <1448956970.84.0.677978683679.issue25772@psf.upfronthosting.co.za> Message-ID: <1448986056.01.0.504770223127.issue25772@psf.upfronthosting.co.za> R. David Murray added the comment: Just FYI, 'super' is not a type, it is a function that returns a proxy. (In python3 there is also compiler magic involved in the no-argument form, but it is still a function :) ---------- nosy: +r.david.murray title: Misleading descriptions about built-in type `super.` -> Misleading descriptions about built-in `super.` _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 11:10:43 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 01 Dec 2015 16:10:43 +0000 Subject: [issue22138] patch.object doesn't restore function defaults In-Reply-To: <1407212040.69.0.583222239779.issue22138@psf.upfronthosting.co.za> Message-ID: <1448986243.7.0.106084748979.issue22138@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 11:25:48 2015 From: report at bugs.python.org (Joe Jevnik) Date: Tue, 01 Dec 2015 16:25:48 +0000 Subject: [issue25770] expose name, args, and kwargs from methodcaller In-Reply-To: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za> Message-ID: <1448987148.57.0.107245318686.issue25770@psf.upfronthosting.co.za> Joe Jevnik added the comment: Thanks for review, looking into the reference count issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 11:27:30 2015 From: report at bugs.python.org (Nicholas Chammas) Date: Tue, 01 Dec 2015 16:27:30 +0000 Subject: [issue25768] compileall functions do not document return values In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za> Message-ID: <1448987250.86.0.462593892885.issue25768@psf.upfronthosting.co.za> Nicholas Chammas added the comment: Exciting! I'm on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 11:36:48 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 01 Dec 2015 16:36:48 +0000 Subject: [issue25601] test_cpickle failure on the ware-gentoo-x86 buildbot In-Reply-To: <1447230695.36.0.35114709633.issue25601@psf.upfronthosting.co.za> Message-ID: <1448987808.62.0.556396657694.issue25601@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I'm duping this one to issue25698 because while it came later, it has a lot more information. They are clearly the same bug. ---------- nosy: +barry superseder: -> The copy_reg module becomes unexpectedly empty in test_cpickle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 11:38:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 Dec 2015 16:38:42 +0000 Subject: [issue25601] test_cpickle failure on the ware-gentoo-x86 buildbot In-Reply-To: <1447230695.36.0.35114709633.issue25601@psf.upfronthosting.co.za> Message-ID: <1448987922.94.0.717239518857.issue25601@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 11:51:03 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 01 Dec 2015 16:51:03 +0000 Subject: [issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448988663.97.0.545018750602.issue25698@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Well, one thing I noticed is that init_stuff() in cPickle.c can leak the copy_reg module object, if any of the subsequent PyObject_GetAttr*() calls fail. They return -1 without decref'ing copyreg. Probably not a horrible leak since it's probably rare, but it should be fixed on principle. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 11:54:46 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 01 Dec 2015 16:54:46 +0000 Subject: [issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448988886.45.0.872827585364.issue25698@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: At the problematic breakpoint mentioned in msg255630, copy_reg is nearly empty. (Pdb) sys.modules['copy_reg'] (Pdb) dir(sys.modules['copy_reg']) ['__builtins__', '__doc__', '__file__', '__name__', '__package__'] (Pdb) sys.modules['copy_reg'].__file__ '/build/python2.7-96oGYh/python2.7-2.7.11~rc1/Lib/copy_reg.pyc' (Pdb) sys.modules['copy_reg'].__doc__ (Pdb) sys.modules['copy_reg'].__name__ 'copy_reg' (Pdb) sys.modules['copy_reg'].__package__ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 11:58:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 Dec 2015 16:58:00 +0000 Subject: [issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448989080.85.0.673089592822.issue25698@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Was it empty before running any test_cpickle tests? Could you find after what test it becomes empty? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 11:59:08 2015 From: report at bugs.python.org (Eryk Sun) Date: Tue, 01 Dec 2015 16:59:08 +0000 Subject: [issue25772] Misleading descriptions about built-in `super.` In-Reply-To: <1448956970.84.0.677978683679.issue25772@psf.upfronthosting.co.za> Message-ID: <1448989148.91.0.738811162565.issue25772@psf.upfronthosting.co.za> Eryk Sun added the comment: > Just FYI, 'super' is not a type No, super is a type: >>> super It's one of 3 types defined in Objects/typeobject.c: PyBaseObject_Type : "object" PyType_Type : "type" PySuper_Type : "super" A super instance (CPython superobject) has the following members: __thisclass__ : the class invoking super() __self__ : the instance invoking super() __self_class__ : the type of the instance invoking super() super has a cutsom __getattribute__ (tp_getattro) slot, super_getattro, which proxies attribute access starting at the parent/sibling of __thisclass__ in the __mro__ of __self_class__. super even defines a __get__ descriptor (tp_descr_get) method, super_descr_get, though I've never used it as such. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 12:05:51 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 01 Dec 2015 17:05:51 +0000 Subject: [issue25772] Misleading descriptions about built-in `super.` In-Reply-To: <1448956970.84.0.677978683679.issue25772@psf.upfronthosting.co.za> Message-ID: <1448989551.5.0.597369707325.issue25772@psf.upfronthosting.co.za> R. David Murray added the comment: Heh. OK, learn something new every day. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 12:51:52 2015 From: report at bugs.python.org (Nicholas Chammas) Date: Tue, 01 Dec 2015 17:51:52 +0000 Subject: [issue25768] compileall functions do not document return values In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za> Message-ID: <1448992312.31.0.192333235621.issue25768@psf.upfronthosting.co.za> Nicholas Chammas added the comment: OK, here's a patch. I reviewed the doc style guide [0] but I'm not 100% sure if I'm using the appropriate tense. There are also a couple of lines that go a bit over 80 characters, but the file already had a few of those. Am happy to make any adjustments, if necessary. [0] https://docs.python.org/devguide/documenting.html#style-guide ---------- keywords: +patch Added file: http://bugs.python.org/file41201/compileall-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 12:55:53 2015 From: report at bugs.python.org (Nicholas Chammas) Date: Tue, 01 Dec 2015 17:55:53 +0000 Subject: [issue25768] compileall functions do not document return values In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za> Message-ID: <1448992553.06.0.403398573688.issue25768@psf.upfronthosting.co.za> Nicholas Chammas added the comment: And I just signed the contributor agreement. (Some banner showed up when I attached the patch to this issue asking me to do so.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 13:26:05 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 01 Dec 2015 18:26:05 +0000 Subject: [issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448994365.58.0.114381006438.issue25698@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: This just gets weirder. I've narrowed it down to running this command: build-static/python Lib/test/regrtest.py test_doctest test_cpickle fails every time. What's even weirder is that I hacked regrtest to print some useful information before and after each test run. It prints the id(sys.modules['copy_reg']) and len(dir(sys.modules['copy_reg']))). Here's the output for two test runs. You can see that if test_doctest is run before test_cpickle, regrtest sees a different module in sys.modules['copy_reg'], but only *after* test_cpickle runs. Using test_doctest2 instead is fine. I'll note one other thing. Doko mentioned that in our build environment, cPickle is built in, not an extension. # build-static/python Lib/test/regrtest.py test_doctest test_cpickle [1/2] test_doctest ('BEFORE =====>', 140559940644712, 22) ('AFTER =====>', 140559940644712, 22) [2/2] test_cpickle ('BEFORE =====>', 140559940644712, 22) test test_cpickle failed -- multiple errors occurred; run in verbose mode for details ('AFTER =====>', 140559897320928, 5) 1 test OK. 1 test failed: test_cpickle # build-static/python Lib/test/regrtest.py test_doctest2 test_cpickle [1/2] test_doctest2 ('BEFORE =====>', 139794866929512, 22) ('AFTER =====>', 139794866929512, 22) [2/2] test_cpickle ('BEFORE =====>', 139794866929512, 22) ('AFTER =====>', 139794866929512, 22) All 2 tests OK. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 13:29:01 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 01 Dec 2015 18:29:01 +0000 Subject: [issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle In-Reply-To: <1448994365.58.0.114381006438.issue25698@psf.upfronthosting.co.za> Message-ID: <20151201132854.33d45675@anarchist.wooz.org> Barry A. Warsaw added the comment: On Dec 01, 2015, at 06:26 PM, Barry A. Warsaw wrote: >I'll note one other thing. Doko mentioned that in our build environment, >cPickle is built in, not an extension. Which may be relevant because in a from-hg-head build of Python 2.7, this problem doesn't occur. I haven't tried 2.7.11 tarball yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 13:31:56 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 01 Dec 2015 18:31:56 +0000 Subject: [issue25774] [benchmarks] Adjust to allow uploading benchmark data to codespeed Message-ID: <1448994715.99.0.967922145164.issue25774@psf.upfronthosting.co.za> New submission from Zachary Ware: Here's a patch to the benchmarks repo that allows running a benchmark on a single interpreter and returning raw data, and provides a script to upload the raw data to a codespeed instance. It's a bit of a quick hack, but is effective. This is a prerequisite to getting speed.python.org running. ---------- components: Benchmarks files: benchmarks.diff hgrepos: 323 keywords: patch messages: 255669 nosy: brett.cannon, pitrou, zach.ware priority: normal severity: normal stage: patch review status: open title: [benchmarks] Adjust to allow uploading benchmark data to codespeed type: enhancement Added file: http://bugs.python.org/file41202/benchmarks.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 13:33:42 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 01 Dec 2015 18:33:42 +0000 Subject: [issue25768] compileall functions do not document return values In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za> Message-ID: <1448994822.61.0.172650194423.issue25768@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks, Nicholas! I'll have a look when I have a chance (hopefully no later than Friday). ---------- assignee: docs at python -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 13:47:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 Dec 2015 18:47:40 +0000 Subject: [issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448995660.25.0.739114431934.issue25698@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Barry. Running test_cpickle after test_doctest I now can reproduce the problem in a from-hg-head build of Python 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 13:53:34 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 01 Dec 2015 18:53:34 +0000 Subject: [issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle In-Reply-To: <1448995660.25.0.739114431934.issue25698@psf.upfronthosting.co.za> Message-ID: <20151201135329.1c58d2e0@limelight.wooz.org> Barry A. Warsaw added the comment: On Dec 01, 2015, at 06:47 PM, Serhiy Storchaka wrote: >Thanks Barry. Running test_cpickle after test_doctest I now can reproduce the >problem in a from-hg-head build of Python 2.7. That's interesting because I can't! (Neither from the 2.7.11rc1 tarball.) Did you make cPickle a built-in like Doko did? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 14:09:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 Dec 2015 19:09:16 +0000 Subject: [issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448996956.64.0.369051899119.issue25698@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, sorry, I missed and mislead you. My tests were specially hacked to simulate a bug (sys.modules['copy_reg'] = object()). No, actually I can't reproduce it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 14:28:33 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 01 Dec 2015 19:28:33 +0000 Subject: [issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle In-Reply-To: <1448218706.46.0.334921108763.issue25698@psf.upfronthosting.co.za> Message-ID: <1448998113.73.0.0267079038039.issue25698@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I added cPickle to Modules/Setup.local and rebuilt from hg. cPickle's a built-in but I still can't reproduce the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 14:33:40 2015 From: report at bugs.python.org (Nicholas Chammas) Date: Tue, 01 Dec 2015 19:33:40 +0000 Subject: [issue25768] compileall functions do not document return values In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za> Message-ID: <1448998420.77.0.502911189725.issue25768@psf.upfronthosting.co.za> Nicholas Chammas added the comment: :thumbsup: Take your time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 14:38:33 2015 From: report at bugs.python.org (Nicholas Chammas) Date: Tue, 01 Dec 2015 19:38:33 +0000 Subject: [issue25775] Bug tracker emails go to spam Message-ID: <1448998713.15.0.646298994549.issue25775@psf.upfronthosting.co.za> New submission from Nicholas Chammas: Not sure where to report this. Is there a component for the bug tracker itself? Anyway, Gmail sends emails from this bug tracker to spam and flags each one with the following message: > Why is this message in Spam? It is in violation of Google's recommended email sender guidelines. Learn more > https://support.google.com/mail/answer/81126?hl=en#authentication Is this actionable? Is this a known issue? ---------- messages: 255676 nosy: Nicholas Chammas priority: normal severity: normal status: open title: Bug tracker emails go to spam type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 14:40:38 2015 From: report at bugs.python.org (Nicholas Chammas) Date: Tue, 01 Dec 2015 19:40:38 +0000 Subject: [issue25768] compileall functions do not document return values In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za> Message-ID: <1448998838.82.0.516847583335.issue25768@psf.upfronthosting.co.za> Nicholas Chammas added the comment: Oh derp. It appears this is dup of issue24386. Apologies. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 14:41:05 2015 From: report at bugs.python.org (Nicholas Chammas) Date: Tue, 01 Dec 2015 19:41:05 +0000 Subject: [issue25768] compileall functions do not document return values In-Reply-To: <1448837055.66.0.314303073696.issue25768@psf.upfronthosting.co.za> Message-ID: <1448998865.46.0.267817292528.issue25768@psf.upfronthosting.co.za> Nicholas Chammas added the comment: Whoops, wrong issue. Reopening. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 14:41:26 2015 From: report at bugs.python.org (Nicholas Chammas) Date: Tue, 01 Dec 2015 19:41:26 +0000 Subject: [issue25775] Bug tracker emails go to spam In-Reply-To: <1448998713.15.0.646298994549.issue25775@psf.upfronthosting.co.za> Message-ID: <1448998886.27.0.273641494007.issue25775@psf.upfronthosting.co.za> Nicholas Chammas added the comment: Oh derp. It appears this is dup of issue24386. Apologies. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 14:48:37 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 01 Dec 2015 19:48:37 +0000 Subject: [issue25775] Bug tracker emails go to spam In-Reply-To: <1448998713.15.0.646298994549.issue25775@psf.upfronthosting.co.za> Message-ID: <1448999317.35.0.804642538857.issue25775@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> duplicate stage: -> resolved superseder: -> Bug Tracker emails going to gmail spam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 15:36:10 2015 From: report at bugs.python.org (Eryk Sun) Date: Tue, 01 Dec 2015 20:36:10 +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: <1449002170.78.0.323949152282.issue25731@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- nosy: +benjamin.peterson, twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 17:08:38 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 01 Dec 2015 22:08:38 +0000 Subject: [issue25770] expose name, args, and kwargs from methodcaller In-Reply-To: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za> Message-ID: <1449007718.85.0.587414388542.issue25770@psf.upfronthosting.co.za> Martin Panter added the comment: Left a review comment which may help you chase that refleak Also, as a new feature, surely it should be documented? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 17:39:16 2015 From: report at bugs.python.org (Matt Bogosian) Date: Tue, 01 Dec 2015 22:39:16 +0000 Subject: [issue25714] Consider isinstance(..., numbers.Integral) instead of isinstance(..., int) or isinstance(..., (int, long)) in datetime.py In-Reply-To: <1448304139.86.0.253570018979.issue25714@psf.upfronthosting.co.za> Message-ID: <1449009556.6.0.0183499566351.issue25714@psf.upfronthosting.co.za> Matt Bogosian added the comment: > I consider this as a bug and think that we should weak some of checks isinstance(..., int) to isinstance(..., (int, long)). numbers.Integral is too wide type, C implementation doesn't support it. Oddly enough, the C implementation is what is working with `future` in this case (although I take your point regarding `numbers.Integral` being too wide; `future.types.newint` effectively behaves like a `long`, and `isinstance(future.types.newint(1), long)` returns `True`). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 18:05:18 2015 From: report at bugs.python.org (Joe Jevnik) Date: Tue, 01 Dec 2015 23:05:18 +0000 Subject: [issue25770] expose name, args, and kwargs from methodcaller In-Reply-To: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za> Message-ID: <1449011118.32.0.643217042376.issue25770@psf.upfronthosting.co.za> Joe Jevnik added the comment: Thanks for pointing me at the refleak, uploading an update ---------- Added file: http://bugs.python.org/file41203/methodcaller-attrs-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 18:25:40 2015 From: report at bugs.python.org (Kevin Modzelewski) Date: Tue, 01 Dec 2015 23:25:40 +0000 Subject: [issue24731] Incorrect assert in str_subtype_new In-Reply-To: <1437952885.56.0.72690112679.issue24731@psf.upfronthosting.co.za> Message-ID: <1449012340.86.0.952775507745.issue24731@psf.upfronthosting.co.za> Kevin Modzelewski added the comment: Awesome, thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 18:28:52 2015 From: report at bugs.python.org (Joe Jevnik) Date: Tue, 01 Dec 2015 23:28:52 +0000 Subject: [issue25770] expose name, args, and kwargs from methodcaller In-Reply-To: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za> Message-ID: <1449012532.12.0.0229295601048.issue25770@psf.upfronthosting.co.za> Joe Jevnik added the comment: Added a test case for the mutation of keywords. ---------- Added file: http://bugs.python.org/file41204/methodcaller-attrs-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 19:52:56 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Dec 2015 00:52:56 +0000 Subject: [issue23674] super() documentation isn't very clear In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za> Message-ID: <1449017576.56.0.117345798389.issue23674@psf.upfronthosting.co.za> Martin Panter added the comment: Here are some specific changes I suggest: 1. Most confusing: super() uses the MRO of the second argument, not the first. 2. Clarify that is is not just the first argument that is skipped in the MRO, it is all preceding classes as well. The first argument does not have to be the class at the start of the MRO. 3. Revise signature and use consistent parameter names in text. Currently, ?obj? and ?type2? are only defined in the doc string. Perhaps super(subclass[, self]). Or maybe super(type[, obj]), matching error messages, or super(thisclass[, self]), matching the special attributes. Type and type2 are too confusing for my taste. 4. Link to the glossary rather than getattr(). 5. Explain more about unbound super objects, when the second argument is omitted. Apparently they are descriptors; when you set them on a class and then ?get? them in an instance, you get a new version bound to that instance. This is obscure, but I feel it might help the general understanding. [It seems you cannot bind a super() object to a class this way; maybe that is a bug.] 6. Explain more about ?bound? super objects: getting a method from the super object binds the method to the second argument. [This also works for getting data properties, but not setting or deleting them; see Issue 14965.] 7. Not only isinstance() or issubclass() must be satisfied, but the first argument must be a concrete class. Virtual subclassing is not sufficient if the subclass is not in the MRO. This would address Issue 20503. Also, the first argument should be a derived class, not ?object? itself. ---------- versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 20:02:16 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Dec 2015 01:02:16 +0000 Subject: [issue20503] super behaviour and abstract base classes (either implementation or documentation/error message is wrong) In-Reply-To: <1391441802.61.0.557224247712.issue20503@psf.upfronthosting.co.za> Message-ID: <1449018136.44.0.105473893382.issue20503@psf.upfronthosting.co.za> Martin Panter added the comment: I am proposing some documentation changes in Issue 23674 which would address this. ---------- assignee: -> docs at python components: +Documentation -Interpreter Core dependencies: +super() documentation isn't very clear nosy: +docs at python, martin.panter versions: +Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 20:18:33 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 02 Dec 2015 01:18:33 +0000 Subject: [issue25177] OverflowError in statistics.mean when summing large floats In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za> Message-ID: <1449019113.14.0.386905486401.issue25177@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Larry, Is it too late to get this into 3.5rc1? changeset 99407:ed45a09e5a69 Thanks. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 20:18:36 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Dec 2015 01:18:36 +0000 Subject: [issue25770] expose name, args, and kwargs from methodcaller In-Reply-To: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za> Message-ID: <1449019116.09.0.0802888191847.issue25770@psf.upfronthosting.co.za> Martin Panter added the comment: This is a bit odd. You can mutate the keyword arguments, but you are not allowed to change the positional arguments (?args? is readonly). If you want this to be part of the supported API, it should be documented, but it seems like bad design IMO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 22:32:04 2015 From: report at bugs.python.org (Joe Jevnik) Date: Wed, 02 Dec 2015 03:32:04 +0000 Subject: [issue25770] expose name, args, and kwargs from methodcaller In-Reply-To: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za> Message-ID: <1449027124.8.0.87449389825.issue25770@psf.upfronthosting.co.za> Joe Jevnik added the comment: I only want this feature to keep the usage close to functools.partial. I was actually sort of surprised to see that mutation of the dict held in partial, but I would rather be consistent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 22:44:44 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Dec 2015 03:44:44 +0000 Subject: [issue14285] Traceback wrong on ImportError while executing a package In-Reply-To: <1331621436.28.0.000669565075438.issue14285@psf.upfronthosting.co.za> Message-ID: <1449027884.73.0.712796260194.issue14285@psf.upfronthosting.co.za> Martin Panter added the comment: Now I have a deeper understanding I think this can be handled separately to Issue 16217. This patch pulls together my previous two patches, and adds a fix. There are two aspects of my fix: 1. Import the package before calling find_spec() on the __main__ submodule. This means exceptions raised by the initialization code can be differentiated from exceptions from find_spec(). 2. Change all the special ImportError exceptions raised inside runpy [and also one raised by InspectLoader.get_code()] to an internal _Error exception known only to runpy. Now I can be sure that all _Error exceptions are not caused by the initialization code, and I can stop catching ImportError, but still catch _Error and suppress the traceback. When runpy is invoked from the documented run_module() or run_path() APIs, _Error is not used, and it still raises ImportError to maintain backwards compatibility. I think my patch should avoid the main problem in Issue 19771 as well. Please review my patch. There are so many error possibilities; it is hard to be sure I have got them all right. ---------- components: +Library (Lib) stage: -> patch review versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 22:47:57 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Dec 2015 03:47:57 +0000 Subject: [issue14285] Traceback wrong on ImportError while executing a package In-Reply-To: <1331621436.28.0.000669565075438.issue14285@psf.upfronthosting.co.za> Message-ID: <1449028077.51.0.173682881433.issue14285@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file41205/internal-error.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 1 22:53:33 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Dec 2015 03:53:33 +0000 Subject: [issue19771] runpy should check ImportError.name before wrapping it In-Reply-To: <1385383187.11.0.803942496087.issue19771@psf.upfronthosting.co.za> Message-ID: <1449028412.99.0.508807039063.issue19771@psf.upfronthosting.co.za> Martin Panter added the comment: My new patch for Issue 14285 should avoid the main problem. However there would still be at least one leftover minor fix worth appyling: fix the exception message to use type(ex).__name__, not repr(type(ex)). ---------- dependencies: +Traceback wrong on ImportError while executing a package versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 00:24:55 2015 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 02 Dec 2015 05:24:55 +0000 Subject: [issue14285] Traceback wrong on ImportError while executing a package In-Reply-To: <1331621436.28.0.000669565075438.issue14285@psf.upfronthosting.co.za> Message-ID: <1449033895.82.0.62989969688.issue14285@psf.upfronthosting.co.za> Nick Coghlan added the comment: Martin, your patch looks good to me, and is at the very least an improvement over the status quo (which clearly traps exceptions that it shouldn't), so I'd say go ahead and apply it. Thanks for digging into this and figuring out a clean solution. ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 01:49:10 2015 From: report at bugs.python.org (Sonali Gupta) Date: Wed, 02 Dec 2015 06:49:10 +0000 Subject: [issue25735] math.factorial doc should mention integer return type In-Reply-To: <1448480671.49.0.139605050425.issue25735@psf.upfronthosting.co.za> Message-ID: <1449038950.05.0.152894607644.issue25735@psf.upfronthosting.co.za> Sonali Gupta added the comment: States that math.factorial(x) returns x factorial as an integer. ---------- keywords: +patch nosy: +mine0901 Added file: http://bugs.python.org/file41206/bug.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 02:39:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Dec 2015 07:39:30 +0000 Subject: [issue25770] expose name, args, and kwargs from methodcaller In-Reply-To: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za> Message-ID: <1449041970.53.0.30411325967.issue25770@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: "keywords" is unusual name. The most used name for the dict of keyword arguments is "kwargs". $ find Lib/ -name '*.py' -exec egrep -ho '\*\*[a-zA-Z_0-9]+' '{}' + | sort | uniq -c | sort -nr | head 803 **kwargs 442 **kw 244 **kwds ... If you want to have keyword arguments non-mutable, you can use types.MappingProxyType. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 02:52:37 2015 From: report at bugs.python.org (Joe Jevnik) Date: Wed, 02 Dec 2015 07:52:37 +0000 Subject: [issue25770] expose name, args, and kwargs from methodcaller In-Reply-To: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za> Message-ID: <1449042757.34.0.987214915065.issue25770@psf.upfronthosting.co.za> Joe Jevnik added the comment: I agree that it is a strange name and I also think that it could be immutable or a copy of the internal dict; however, I think that consistency with existing APIs in the standard library is more important. 'keywords' is still very clear in context and is used in 'functools.partial'. This feature is very similar to 'partial' so I would like to follow the example set there. I would not mind changing 'partial' to reflect this feedback; but, I imagine that will break people's code and be a harder sell. I would find it frustrating if 'partial' and 'methodcaller' spelled 'keywords' differently or had slightly different behavior when it comes to the keyword argument dictionary. Allowing the mutation is not that unintuitive if you look at the simple python translation I added to the docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 03:00:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Dec 2015 08:00:32 +0000 Subject: [issue25770] expose name, args, and kwargs from methodcaller In-Reply-To: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za> Message-ID: <1449043232.45.0.662742964596.issue25770@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: functools.partial() is unique in it's usage of name "keywords". ---------- nosy: +ncoghlan, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 05:03:31 2015 From: report at bugs.python.org (Robert Kuska) Date: Wed, 02 Dec 2015 10:03:31 +0000 Subject: [issue19527] Test failures with COUNT_ALLOCS In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za> Message-ID: <1449050611.86.0.556083202769.issue19527@psf.upfronthosting.co.za> Robert Kuska added the comment: With Python-3.5 and COUNT_ALLOCS enabled following new tests fail also: FAIL: test_is_finalizing (test.test_sys.SysModuleTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/Python-3.5.0/Lib/test/test_sys.py", line 767, in test_is_finalizing self.assertEqual(stdout.rstrip(), b'True') AssertionError: b'' != b'True' --------------------------------- ====================================================================== FAIL: test_print_traceback_at_exit (test.test_traceback.SyntaxTracebackCases) ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/Python-3.5.0/Lib/test/test_traceback.py", line 210, in test_print_traceback_at_exit self.assertEqual(stderr.splitlines(), expected) AssertionError: Lists differ: [] != [b'Traceback (most recent call last):', b'[75 chars]ero'] Second list contains 3 additional elements. First extra element 0: b'Traceback (most recent call last):' - [] + [b'Traceback (most recent call last):', + b' File "", line 8, in __init__', + b'ZeroDivisionError: division by zero'] ---------- nosy: +rkuska _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 05:28:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Dec 2015 10:28:45 +0000 Subject: [issue19527] Test failures with COUNT_ALLOCS In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za> Message-ID: <1449052125.55.0.694784340963.issue19527@psf.upfronthosting.co.za> STINNER Victor added the comment: COUNT_ALLOCS was added 22 years ago. I guess that the usecase is to track memory leaks, right? branch: legacy-trunk user: Sjoerd Mullender date: Mon Oct 11 12:54:31 1993 +0000 files: Include/object.h Modules/arraymodule.c Modules/config.c.in Modules/imageop.c Modules/imgfile.c Objects/floatobject.c Objects/intobject.c Objects/listobj description: * Extended X interface: pixmap objects, colormap objects visual objects, image objects, and lots of new methods. * Added counting of allocations and deallocations of builtin types if COUNT_ALLOCS is defined. Had to move calls to NEWREF down in some files. * Bug fix in sorting lists. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 05:29:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Dec 2015 10:29:16 +0000 Subject: [issue25776] More compact pickle of iterators etc Message-ID: <1449052155.68.0.447852149746.issue25776@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch makes a number of classes produce more compact pickle data in common case. This includes iterators of list, tuple, str, bytes, bytearray, enumerate, array, deque, iterator object for classes with __getitem__, some itertools iterators, and non-iterator objects: slice, bytearray, deque. This is achieved by omitting default constructor arguments or state. Exhausted iterators are pickled as iter(()). This is not new, exhausted bytes, and bytearray iterators, and reversed list iterator are already pickled as iter('') or iter([]) correspondingly. iter(()) is just the simplest way to create an empty iterator and it has the most compact pickle representation. An example. Unpatched: >>> import pickle, pickletools, itertools >>> len(pickle.dumps(itertools.islice('abcdefgh', 4), 3)) 80 >>> len(pickletools.optimize(pickle.dumps(itertools.islice('abcdefgh', 4), 3))) 66 >>> pickletools.dis(pickletools.optimize(pickle.dumps(itertools.islice('abcdefgh', 4), 3))) 0: \x80 PROTO 3 2: c GLOBAL 'itertools islice' 20: ( MARK 21: c GLOBAL 'builtins iter' 36: X BINUNICODE 'abcdefgh' 49: \x85 TUPLE1 50: R REDUCE 51: K BININT1 0 53: b BUILD 54: K BININT1 0 56: K BININT1 4 58: K BININT1 1 60: t TUPLE (MARK at 20) 61: R REDUCE 62: K BININT1 0 64: b BUILD 65: . STOP highest protocol among opcodes = 2 Patched: >>> len(pickle.dumps(itertools.islice('abcdefgh', 4), 3)) 69 >>> len(pickletools.optimize(pickle.dumps(itertools.islice('abcdefgh', 4), 3))) 55 >>> pickletools.dis(pickletools.optimize(pickle.dumps(itertools.islice('abcdefgh', 4), 3))) 0: \x80 PROTO 3 2: c GLOBAL 'itertools islice' 20: c GLOBAL 'builtins iter' 35: X BINUNICODE 'abcdefgh' 48: \x85 TUPLE1 49: R REDUCE 50: K BININT1 4 52: \x86 TUPLE2 53: R REDUCE 54: . STOP highest protocol among opcodes = 2 ---------- components: Extension Modules, Interpreter Core files: iterators_pickle.diff keywords: patch messages: 255699 nosy: alexandre.vassalotti, pitrou, rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: More compact pickle of iterators etc type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file41207/iterators_pickle.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 05:33:16 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Dec 2015 10:33:16 +0000 Subject: [issue19527] Test failures with COUNT_ALLOCS In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za> Message-ID: <1449052396.37.0.632316347088.issue19527@psf.upfronthosting.co.za> STINNER Victor added the comment: 00141-fix-tests_with_COUNT_ALLOCS-v5.patch: please don't do that! It makes tests much more verbose for a compilation option which is hidden and probably almost never used in the wild. The option has no configuration option for example. *If* you really want to keep the feature, I would prefer to make it more visible (add a configuration option) and disable the output at exit by default. It's better to add a new "-X showcountallocs" as it was done with "-X showrefcount". Before, we had to fix a lot of unit tests (as 00141-fix-tests_with_COUNT_ALLOCS-v5.patch) to strip the "[xxx refs]" from stderr, it was very annoying. "Python 3.4 now has sys.getallocatedblocks() and a new tracemalloc module which are compiled by default." IMHO these two debug features superseded COUNT_ALLOCS. Please try to convince me of the use case of this very old debug feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 05:39:35 2015 From: report at bugs.python.org (Robert Kuska) Date: Wed, 02 Dec 2015 10:39:35 +0000 Subject: [issue19527] Test failures with COUNT_ALLOCS In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za> Message-ID: <1449052775.39.0.672581240951.issue19527@psf.upfronthosting.co.za> Robert Kuska added the comment: FYI There is also issue23034 where is proposed "-X showalloccount" option to suppress the output, we use (custom patch) environment variable to filter out the verbose output in Fedora. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 05:46:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Dec 2015 10:46:25 +0000 Subject: [issue19527] Test failures with COUNT_ALLOCS In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za> Message-ID: <1449053185.3.0.743388730466.issue19527@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, I also don't want to use 00141-fix-tests_with_COUNT_ALLOCS-v5.patch if there is better alternative. See issue23034 (I'm uncertain only in option name). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 05:47:19 2015 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Wed, 02 Dec 2015 10:47:19 +0000 Subject: [issue19527] Test failures with COUNT_ALLOCS In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za> Message-ID: <1449053239.74.0.599056107773.issue19527@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: > IMHO these two debug features superseded COUNT_ALLOCS. Please try to convince me of the use case of this very old debug feature. I no longer use this feature and I think that noone does. As you said, it seems to be obsoleted by other new features, so my vote would be to remove COUNT_ALLOCS altogether. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 05:53:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Dec 2015 10:53:25 +0000 Subject: [issue22039] PyObject_SetAttr doesn't mention value = NULL In-Reply-To: <1406051790.64.0.0676928180206.issue22039@psf.upfronthosting.co.za> Message-ID: <1449053605.61.0.146815473449.issue22039@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See two alternative issues: issue25701 for documenting existing behavior, and issue25773 for deprecating it (and converting PyObject_DelAttr to a function). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 05:57:49 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 02 Dec 2015 10:57:49 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1449053869.72.0.550091977224.issue25709@psf.upfronthosting.co.za> Larry Hastings added the comment: Is this going in soon? I want to cherry-pick this for 3.5.1, which I tag in about 80 hours. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 05:58:17 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 02 Dec 2015 10:58:17 +0000 Subject: [issue25715] Python 3.5.1 installer shows wrong upgrade path In-Reply-To: <1448310282.68.0.27697601288.issue25715@psf.upfronthosting.co.za> Message-ID: <1449053897.42.0.102560101812.issue25715@psf.upfronthosting.co.za> Larry Hastings added the comment: You can have it in 3.5.1, and we can negotiate about how to get it in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 06:09:05 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Dec 2015 11:09:05 +0000 Subject: [issue14285] Traceback wrong on ImportError while executing a package In-Reply-To: <1331621436.28.0.000669565075438.issue14285@psf.upfronthosting.co.za> Message-ID: <1449054545.75.0.855077409567.issue14285@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the review Nick. You removed Python 3.4 from the versions; do you think it is not worth the risk committing in 3.4? I understand the deadline for the final release of 3.4 is the end of this week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 06:24:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Dec 2015 11:24:58 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1449055498.25.0.299436181328.issue25709@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I wait only Greg's approving for 3.3. If I'll not get it in a day, I'll commit the patch for 3.4+. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 06:48:49 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 02 Dec 2015 11:48:49 +0000 Subject: [issue25756] asyncio WriteTransport documentation typo In-Reply-To: <1448666524.97.0.228973534452.issue25756@psf.upfronthosting.co.za> Message-ID: <1449056929.25.0.17298616557.issue25756@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I think the doc is correct. `pause_writing` is called when write buffer becomes non empty, empty buffer is precondition for `resume_writing` call. ---------- nosy: +asvetlov resolution: -> not a bug stage: -> resolved status: open -> closed versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 06:58:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Dec 2015 11:58:04 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1449055498.25.0.299436181328.issue25709@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Please commit right now to 3.4+. Backport to 3.3 can be done later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 07:00:03 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Dec 2015 12:00:03 +0000 Subject: [issue19527] Test failures with COUNT_ALLOCS In-Reply-To: <1449053239.74.0.599056107773.issue19527@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I propose to emit a compiler warning (or even an error?) in 3.5.x and drop the code in 3.6. I don't think that a long deprecation period is requied. The feature is not widely used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 07:22:21 2015 From: report at bugs.python.org (Juchen Zeng) Date: Wed, 02 Dec 2015 12:22:21 +0000 Subject: [issue25777] Misleading descriptions in docs about invoking descriptors. Message-ID: <1449058941.53.0.26351823319.issue25777@psf.upfronthosting.co.za> New submission from Juchen Zeng: [Doc Link](https://docs.python.org/2/howto/descriptor.html#invoking-descriptors) In descriptions about how to invoke descriptors with super(), it says: The call super(B, obj).m() searches obj.__class__.__mro__ for the base class A immediately following B and then returns A.__dict__['m'].__get__(obj, B). If not a descriptor, m is returned unchanged. If not in the dictionary, m reverts to a search using object.__getattribute__(). But the call ` super(B, obj).m()` will not return `A.__dict__['m'].__get__(obj, B)`, it will trigger the `__call__` method of ` A.__dict__['m'].__get__(obj, B)` if it has that attr, and return what this `__call__` method returns. It could be anything. It's actually `super(B, obj).m` returns `A.__dict__['m'].__get__(obj, B)` if m is a descriptor. In short, the original description in the doc can be abbreviated to: `The call super(B, obj).m() [did something] and returns A.__dict__['m'].__get__(obj, B).` Which is obviously misleading. As the method/function call isn't the core part in this sentence. I suggest the doc to be fixed like this: The action super(B, obj).m searches obj.__class__.__mro__ for the base class A immediately following B and then returns A.__dict__['m'].__get__(obj, B). ---------- assignee: docs at python components: Documentation messages: 255712 nosy: Juchen Zeng, docs at python, martin.panter priority: normal severity: normal status: open title: Misleading descriptions in docs about invoking descriptors. versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 07:58:08 2015 From: report at bugs.python.org (Rob Agar) Date: Wed, 02 Dec 2015 12:58:08 +0000 Subject: [issue16251] pickle special methods are looked up on the instance rather than the type In-Reply-To: <1350411894.01.0.763638555345.issue16251@psf.upfronthosting.co.za> Message-ID: <1449061088.33.0.572185790052.issue16251@psf.upfronthosting.co.za> Changes by Rob Agar : ---------- nosy: +robagar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 08:17:59 2015 From: report at bugs.python.org (Florin Papa) Date: Wed, 02 Dec 2015 13:17:59 +0000 Subject: [issue25719] Deprecate spitfire benchmark In-Reply-To: <1448362459.17.0.918374944074.issue25719@psf.upfronthosting.co.za> Message-ID: <1449062279.72.0.243292719925.issue25719@psf.upfronthosting.co.za> Florin Papa added the comment: No problem. Thank you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 08:36:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Dec 2015 13:36:32 +0000 Subject: [issue25177] OverflowError in statistics.mean when summing large floats In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za> Message-ID: <20151202133624.10710.74399@psf.io> Roundup Robot added the comment: New changeset a7d2307055e7 by Victor Stinner in branch 'default': Null merge 3.5, patch was already applied to default (isuse #25177) https://hg.python.org/cpython/rev/a7d2307055e7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 08:55:25 2015 From: report at bugs.python.org (Anshul Agrawal) Date: Wed, 02 Dec 2015 13:55:25 +0000 Subject: [issue25778] Error on import matplotlib.pyplot and seaborn (Python3 - Windows 10 64-bit issue) Message-ID: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> New submission from Anshul Agrawal: I have described the error message I got when I recently installed Python 3.5.0 (via Anaconda3) and then subsequently tried to import mathplotlib.pyplot and seaborn packages at this StackOverflow post (http://stackoverflow.com/questions/34004063/error-on-import-matplotlib-pyplot-on-anaconda3-for-windows-10-home-64-bit-pc) Another person responded to the above post with a simple 1-line patch to the file "fontList.py3k.cache" (please see the above post for details). This does appear to be a purely Python 3 issue on some Windows platforms. It would be nice if Python 3 developers could check the patch out for any possible side-effects, and incorporate a permanent fix in future versions. Thanks. ---------- components: Extension Modules messages: 255715 nosy: anshul6 priority: normal severity: normal status: open title: Error on import matplotlib.pyplot and seaborn (Python3 - Windows 10 64-bit issue) type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 09:10:43 2015 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 02 Dec 2015 14:10:43 +0000 Subject: [issue14285] Traceback wrong on ImportError while executing a package In-Reply-To: <1331621436.28.0.000669565075438.issue14285@psf.upfronthosting.co.za> Message-ID: <1449065443.18.0.311681541952.issue14285@psf.upfronthosting.co.za> Nick Coghlan added the comment: Right, while I agree this is a bug fix that makes sense to apply to 2.7 and 3.5, it's also a large enough change to runpy's control flow logic that I'm wary of including it in the final 3.4 binary release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 09:24:00 2015 From: report at bugs.python.org (SilentGhost) Date: Wed, 02 Dec 2015 14:24:00 +0000 Subject: [issue25778] Error on import matplotlib.pyplot and seaborn (Python3 - Windows 10 64-bit issue) In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449066240.61.0.913336163665.issue25778@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Library (Lib) nosy: +stutzbach stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 09:29:48 2015 From: report at bugs.python.org (SilentGhost) Date: Wed, 02 Dec 2015 14:29:48 +0000 Subject: [issue25778] Error on import matplotlib.pyplot and seaborn (Python3 - Windows 10 64-bit issue) In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449066588.92.0.636543852824.issue25778@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 09:59:10 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 02 Dec 2015 14:59:10 +0000 Subject: [issue25778] Error on import matplotlib.pyplot and seaborn (Python3 - Windows 10 64-bit issue) In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449068350.41.0.771864601644.issue25778@psf.upfronthosting.co.za> R. David Murray added the comment: The stackoverflow comment is this: "The issue is that winreg.EnumValue is not cutting string values at their length properly for some reason, and strings will include null characters which os.path.abspath is not able to process." The "one line patch" in the stackoverflow comment is against matplotlib, not python, so it doesn't help toward fixing this. What would be most useful toward fixing this is a reproducer, but since that will depend on data in the registry whoever creates the reproducer may as well do it as a unit test. I'm adding 2.7 to versions since it seems unlikely the code is different there, but I haven't checked. Anshul, if you have tested this on python2.7 and not seen the problem there, please update the issue with that info. ---------- keywords: +easy nosy: +r.david.murray versions: +Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 10:01:03 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 02 Dec 2015 15:01:03 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449068463.07.0.349458098349.issue25778@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: Error on import matplotlib.pyplot and seaborn (Python3 - Windows 10 64-bit issue) -> winreg.EnumValue does not truncate strings correctly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 10:18:16 2015 From: report at bugs.python.org (Anshul Agrawal) Date: Wed, 02 Dec 2015 15:18:16 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449069496.73.0.830675752755.issue25778@psf.upfronthosting.co.za> Anshul Agrawal added the comment: Before I got the "one line patch" on stackoverflow, I tried creating a new environment with Python 2.7.10 and did *not* get the error message I got with Python 3.5.0. Here's an outline of what I did: 1) Created a new environment to use Python 2.7.10: conda create --name python2.7.10 python=2.7.10 2) Installed matplotlib package within it: conda install --name python2.7.10 matplotlib 3) Installed seaborn package within it: conda install --name python2.7.10 seaborn When I started Python within this environment (verified it was version 2.7.10 with "print(sys.version)"), and did "import matplotlib.pyplot" and "import seaborn", the FileNotFoundError message did not appear. So the problem appears to be associated with Python3, not Python2. Hope this helps. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 10:37:25 2015 From: report at bugs.python.org (Jack O'Connor) Date: Wed, 02 Dec 2015 15:37:25 +0000 Subject: [issue25779] deadlock with asyncio+contextmanager+ExitStack Message-ID: <1449070645.76.0.674051861514.issue25779@psf.upfronthosting.co.za> New submission from Jack O'Connor: The following hangs at 100% CPU on Python 3.5, though not on Python 3.4: 1) Start an asyncio coroutine with run_until_complete(). 2) Inside the coroutine, enter an ExitStack using a with-statement. 3) Inside the with-statement, call ExitStack.enter_context() with a generator context manager. It doesn't matter what the generator yields. 4) After the enter_context() call, raise an exception. Here's an example script that does all of this and repros the hang: https://gist.github.com/oconnor663/483db2820bb5f877c9ed ---------- components: asyncio messages: 255719 nosy: gvanrossum, haypo, oconnor663, yselivanov priority: normal severity: normal status: open title: deadlock with asyncio+contextmanager+ExitStack type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 10:52:15 2015 From: report at bugs.python.org (Eryk Sun) Date: Wed, 02 Dec 2015 15:52:15 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449071535.26.0.607412180813.issue25778@psf.upfronthosting.co.za> Eryk Sun added the comment: Based on matplotlib's win32InstalledFonts function [1], I created a small test to check the data strings returned by winreg.EnumValue for the presence of null characters. I tested on Windows 7 and 10 but couldn't reproduce the problem. Please run nullcheck.py to check the results on your system. [1]: https://github.com/matplotlib/matplotlib/blob/v1.5.0/lib/matplotlib/font_manager.py#L200 ---------- nosy: +eryksun Added file: http://bugs.python.org/file41208/nullcheck.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 11:15:54 2015 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Dec 2015 16:15:54 +0000 Subject: [issue25779] deadlock with asyncio+contextmanager+ExitStack In-Reply-To: <1449070645.76.0.674051861514.issue25779@psf.upfronthosting.co.za> Message-ID: <1449072954.53.0.416505933375.issue25779@psf.upfronthosting.co.za> Guido van Rossum added the comment: Interestingly, it doesn't hang when you raise a different error. There's some new code dealing with the RuntimeError coming out of a generator if it raises StopIteration (instead of returning) introduced by issue #22906. Yury, it looks like you introduced that? (The diff is this: changeset: 95932:36a8d935c322 user: Yury Selivanov date: Sat May 09 11:44:30 2015 -0400 summary: PEP 479: Change StopIteration handling inside generators. ---------- assignee: -> yselivanov keywords: +3.5regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 11:30:26 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 16:30:26 +0000 Subject: [issue25779] deadlock with asyncio+contextmanager+ExitStack In-Reply-To: <1449070645.76.0.674051861514.issue25779@psf.upfronthosting.co.za> Message-ID: <1449073826.65.0.96544366411.issue25779@psf.upfronthosting.co.za> Yury Selivanov added the comment: Trying to reproduce without contextstack. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 11:34:57 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 02 Dec 2015 16:34:57 +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: <1449074097.31.0.751328002299.issue18987@psf.upfronthosting.co.za> Changes by Jason R. Coombs : ---------- stage: -> needs patch versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 11:40:49 2015 From: report at bugs.python.org (Stefan Tatschner) Date: Wed, 02 Dec 2015 16:40:49 +0000 Subject: [issue25780] Add support for CAN_RAW_JOIN_FILTERS Message-ID: <1449074447.29.0.213464499345.issue25780@psf.upfronthosting.co.za> New submission from Stefan Tatschner: Here is a patch, which adds support for CAN_RAW_JOIN_FILTERS which is available since linux 4.1 [1]. My patch fixes trailing whitespace issues as well. Since I have a newer version of autotools, running "autoreconf" generates a lot of changes, so I left that out for the time being. [1]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a5581ef4c2eac6449188862e903eb46c7233582a ---------- components: Library (Lib) files: can_raw_join_filters.diff keywords: patch messages: 255723 nosy: rumpelsepp priority: normal severity: normal status: open title: Add support for CAN_RAW_JOIN_FILTERS versions: Python 3.6 Added file: http://bugs.python.org/file41210/can_raw_join_filters.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 11:42:00 2015 From: report at bugs.python.org (Stefan Tatschner) Date: Wed, 02 Dec 2015 16:42:00 +0000 Subject: [issue25780] Add support for CAN_RAW_JOIN_FILTERS In-Reply-To: <1449074447.29.0.213464499345.issue25780@psf.upfronthosting.co.za> Message-ID: <1449074520.76.0.0169368391291.issue25780@psf.upfronthosting.co.za> Stefan Tatschner added the comment: in case you don't like whitespace cleanups, here is the patch with "git diff --ignore-space-changes". ---------- Added file: http://bugs.python.org/file41211/can_raw_join_filters-no-whitespace.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 11:57:24 2015 From: report at bugs.python.org (Joe Jevnik) Date: Wed, 02 Dec 2015 16:57:24 +0000 Subject: [issue25770] expose name, args, and kwargs from methodcaller In-Reply-To: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za> Message-ID: <1449075444.08.0.111393666772.issue25770@psf.upfronthosting.co.za> Joe Jevnik added the comment: partial's unique usage is why I feel like it would be so jarring for them do be named differently. I would be happiest having this feature at all so I will change the name to 'kwargs' if you would like. I just want to be sure that my reasons for choosing this name in the first place ere understood. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 11:59:02 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 16:59:02 +0000 Subject: [issue25779] deadlock with asyncio+contextmanager+ExitStack In-Reply-To: <1449070645.76.0.674051861514.issue25779@psf.upfronthosting.co.za> Message-ID: <1449075542.27.0.69375824538.issue25779@psf.upfronthosting.co.za> Yury Selivanov added the comment: Here's a minimal test to reproduce: import reprlib def main(): if 0: yield raise RuntimeError m = main() try: m.send(None) except RuntimeError as ex: ex.__context__ = ex reprlib.repr(ex) Looks like it's a bug in reprlib. It's not related to PEP 492/479. It's also reproducible in Python 3.4 and 3.3. Nick, ExitStack does this (indirectly) 'ex.__context__ = ex' thing -- I think that's a bug of contextlib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:01:44 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 17:01:44 +0000 Subject: [issue25781] infinite loop in reprlib Message-ID: <1449075704.09.0.711720305555.issue25781@psf.upfronthosting.co.za> New submission from Yury Selivanov: The below code blocks Python eval loop and makes it unresponsive to signals (like ^C). import reprlib try: raise RuntimeError except RuntimeError as ex: ex.__context__ = ex reprlib.repr(ex) ---------- components: Library (Lib) messages: 255727 nosy: yselivanov priority: normal severity: normal status: open title: infinite loop in reprlib versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:03:22 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 17:03:22 +0000 Subject: [issue25779] deadlock with asyncio+contextmanager+ExitStack In-Reply-To: <1449070645.76.0.674051861514.issue25779@psf.upfronthosting.co.za> Message-ID: <1449075802.89.0.450025797427.issue25779@psf.upfronthosting.co.za> Yury Selivanov added the comment: Created another issue for the reprlib bug: issue 25781. It appears we don't even need a generator: import reprlib try: raise RuntimeError except RuntimeError as ex: ex.__context__ = ex reprlib.repr(ex) Closing this one with "not a bug". ---------- resolution: -> not a bug status: open -> closed superseder: -> infinite loop in reprlib _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:12:06 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 17:12:06 +0000 Subject: [issue25781] infinite loop in reprlib In-Reply-To: <1449075704.09.0.711720305555.issue25781@psf.upfronthosting.co.za> Message-ID: <1449076326.18.0.291394488739.issue25781@psf.upfronthosting.co.za> Yury Selivanov added the comment: This isn't a bug of reprlib -- it's something in the core. Will create a separate issue for this. try: raise Exception except Exception as ex: ex.__context__ = ex hasattr(1, 'aa') ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:12:49 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 17:12:49 +0000 Subject: [issue25779] deadlock with asyncio+contextmanager+ExitStack In-Reply-To: <1449070645.76.0.674051861514.issue25779@psf.upfronthosting.co.za> Message-ID: <1449076369.08.0.790135986268.issue25779@psf.upfronthosting.co.za> Yury Selivanov added the comment: It's not even a reprlib bug: try: raise Exception except Exception as ex: ex.__context__ = ex hasattr(1, 'aa') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:14:01 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 17:14:01 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself Message-ID: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> New submission from Yury Selivanov: try: raise Exception except Exception as ex: ex.__context__ = ex hasattr(1, 'aa') ---------- components: Interpreter Core messages: 255731 nosy: gvanrossum, haypo, ncoghlan, yselivanov priority: normal severity: normal status: open title: CPython hangs on error __context__ set to the error itself versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:14:19 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 17:14:19 +0000 Subject: [issue25779] deadlock with asyncio+contextmanager+ExitStack In-Reply-To: <1449070645.76.0.674051861514.issue25779@psf.upfronthosting.co.za> Message-ID: <1449076459.39.0.218501935749.issue25779@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- superseder: infinite loop in reprlib -> CPython hangs on error __context__ set to the error itself _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:14:34 2015 From: report at bugs.python.org (Jack O'Connor) Date: Wed, 02 Dec 2015 17:14:34 +0000 Subject: [issue25779] deadlock with asyncio+contextmanager+ExitStack In-Reply-To: <1449070645.76.0.674051861514.issue25779@psf.upfronthosting.co.za> Message-ID: <1449076474.36.0.853095860656.issue25779@psf.upfronthosting.co.za> Jack O'Connor added the comment: Thanks for chasing this down. Yury, can you suggest a workaround? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:15:25 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 17:15:25 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449076525.34.0.0126774358079.issue25782@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +georg.brandl, larry priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:18:10 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 17:18:10 +0000 Subject: [issue25779] deadlock with asyncio+contextmanager+ExitStack In-Reply-To: <1449070645.76.0.674051861514.issue25779@psf.upfronthosting.co.za> Message-ID: <1449076690.66.0.837942897608.issue25779@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Thanks for chasing this down. Yury, can you suggest a workaround? I'm not sure how to workaround this :( Hopefully we can fix this in 3.5.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:19:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Dec 2015 17:19:32 +0000 Subject: [issue25715] Python 3.5.1 installer shows wrong upgrade path In-Reply-To: <1448310282.68.0.27697601288.issue25715@psf.upfronthosting.co.za> Message-ID: <20151202171923.14118.34274@psf.io> Roundup Robot added the comment: New changeset 8537ec50c254 by Steve Dower in branch '3.5': Issue #25715: Python 3.5.1 installer shows wrong upgrade path and incorrect logic for launcher detection. https://hg.python.org/cpython/rev/8537ec50c254 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:20:45 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 02 Dec 2015 17:20:45 +0000 Subject: [issue25715] Python 3.5.1 installer shows wrong upgrade path In-Reply-To: <1448310282.68.0.27697601288.issue25715@psf.upfronthosting.co.za> Message-ID: <1449076845.13.0.205832836866.issue25715@psf.upfronthosting.co.za> Steve Dower added the comment: As you can see, I've now pushed to the main 3.5 branch, so feel free to cherry-pick from there or give me the word and I'll graft it into the releasing repo for you. I also forward merged all the 3.5.1 NEWS into default. Not sure how that normally happens, but it was easier to do it with a big copy-past than try and figure out the merge conflicts... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:21:46 2015 From: report at bugs.python.org (Jack O'Connor) Date: Wed, 02 Dec 2015 17:21:46 +0000 Subject: [issue25781] infinite loop in reprlib In-Reply-To: <1449075704.09.0.711720305555.issue25781@psf.upfronthosting.co.za> Message-ID: <1449076906.52.0.114126773771.issue25781@psf.upfronthosting.co.za> Changes by Jack O'Connor : ---------- nosy: +oconnor663 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:30:20 2015 From: report at bugs.python.org (SilentGhost) Date: Wed, 02 Dec 2015 17:30:20 +0000 Subject: [issue25780] Add support for CAN_RAW_JOIN_FILTERS In-Reply-To: <1449074447.29.0.213464499345.issue25780@psf.upfronthosting.co.za> Message-ID: <1449077420.18.0.481012166014.issue25780@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:35:25 2015 From: report at bugs.python.org (Anshul Agrawal) Date: Wed, 02 Dec 2015 17:35:25 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449077725.93.0.248490385253.issue25778@psf.upfronthosting.co.za> Anshul Agrawal added the comment: Please tell me where I can find nullcheck.py and how I should run it (I assume something like "python nullcheck.py" in the Windows Command Prompt?) I'm relatively new to Python, so explicit instructions would be appreciated. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:44:33 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Dec 2015 17:44:33 +0000 Subject: [issue25783] test_traceback.test_walk_stack() fails when run directly (without regrtest) Message-ID: <1449078273.26.0.535537969115.issue25783@psf.upfronthosting.co.za> New submission from STINNER Victor: Tested on Python 3.6 (default branch): haypo at smithers$ ./python -m test test_traceback [1/1] test_traceback 1 test OK. haypo at smithers$ ./python Lib/test/test_traceback.py ..........................................F............... ====================================================================== FAIL: test_walk_stack (__main__.TestStack) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_traceback.py", line 684, in test_walk_stack self.assertGreater(len(s), 10) AssertionError: 10 not greater than 10 ---------------------------------------------------------------------- Ran 58 tests in 2.184s FAILED (failures=1) ---------- components: Tests messages: 255737 nosy: haypo priority: normal severity: normal status: open title: test_traceback.test_walk_stack() fails when run directly (without regrtest) versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:44:38 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Dec 2015 17:44:38 +0000 Subject: [issue25783] test_traceback.test_walk_stack() fails when run directly (without regrtest) In-Reply-To: <1449078273.26.0.535537969115.issue25783@psf.upfronthosting.co.za> Message-ID: <1449078278.48.0.994137508444.issue25783@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:44:46 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Dec 2015 17:44:46 +0000 Subject: [issue25783] test_traceback.test_walk_stack() fails when run directly (without regrtest) In-Reply-To: <1449078273.26.0.535537969115.issue25783@psf.upfronthosting.co.za> Message-ID: <1449078286.4.0.554829816945.issue25783@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:45:12 2015 From: report at bugs.python.org (SilentGhost) Date: Wed, 02 Dec 2015 17:45:12 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449078312.73.0.292917167418.issue25778@psf.upfronthosting.co.za> SilentGhost added the comment: Anshul, it's attached to this issue, before messages start under Files heading. Here is the direct link https://bugs.python.org/file41208/nullcheck.py ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:46:21 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 17:46:21 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449078381.94.0.976071005938.issue25782@psf.upfronthosting.co.za> Yury Selivanov added the comment: The bug is in "PyErr_SetObject": while ((context = PyException_GetContext(o))) { Py_DECREF(context); if (context == value) { PyException_SetContext(o, NULL); break; } o = context; } The loop can be infinite. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:52:26 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 17:52:26 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449078746.46.0.237622669503.issue25782@psf.upfronthosting.co.za> Yury Selivanov added the comment: Looks like this is the original code committed in CPython in 2ee09afee126. Patch by Antoine Pitrou. Antoine, how would you fix this? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:54:16 2015 From: report at bugs.python.org (Alexander Finkel) Date: Wed, 02 Dec 2015 17:54:16 +0000 Subject: [issue25784] Please consider integrating performance fix for ipaddress.py Message-ID: <1449078856.21.0.545889486519.issue25784@psf.upfronthosting.co.za> New submission from Alexander Finkel: I encountered a performance problem using the ipaddr library to merge over 10000 network addresses. I sent a patch upstream to fix it, and that patch has been merged: https://github.com/google/ipaddr-py/commit/6504b47a02739e853043f0a184f3c39462293e5c Since ipaddr is also included in the standard lib of Python 3 (I think since version 3.3?) and above, I'd like to ask that this patch be considered for committing here too. Background on including ipaddr into the std lib: https://bugs.python.org/issue14814 ---------- messages: 255741 nosy: Alexander Finkel priority: normal severity: normal status: open title: Please consider integrating performance fix for ipaddress.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 12:55:28 2015 From: report at bugs.python.org (Eryk Sun) Date: Wed, 02 Dec 2015 17:55:28 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449078928.09.0.356843460395.issue25778@psf.upfronthosting.co.za> Eryk Sun added the comment: You should be able to run nullcheck.py in the command prompt by changing to the directory where it's saved and entering nullcheck.py. For example, if you saved it in your Downloads folder: >cd /d C:\Users\Anshul\Downloads >nullcheck.py If that fails because the .py file association isn't set up properly, instead try >py nullcheck.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 13:02:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Dec 2015 18:02:57 +0000 Subject: [issue25784] Please consider integrating performance fix for ipaddress.py In-Reply-To: <1449078856.21.0.545889486519.issue25784@psf.upfronthosting.co.za> Message-ID: <1449079377.65.0.222585831878.issue25784@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you provide a patch? ---------- components: +Library (Lib) nosy: +ncoghlan, pmoody, serhiy.storchaka type: -> performance versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 13:06:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Dec 2015 18:06:14 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449079574.46.0.0695694107805.issue25782@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I would change __context__ setter to check if it creates a loop. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 13:16:34 2015 From: report at bugs.python.org (Anshul Agrawal) Date: Wed, 02 Dec 2015 18:16:34 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449080194.96.0.584077478748.issue25778@psf.upfronthosting.co.za> Anshul Agrawal added the comment: Ok thanks. Here's what I got: C:\Users\Anshul\Downloads\Python>conda info --envs # conda environments: # python2.7.10 C:\Anaconda3\envs\python2.7.10 root * C:\Anaconda3 C:\Users\Anshul\Downloads\Python>python -V Python 3.5.0 :: Anaconda 2.4.0 (64-bit) C:\Users\Anshul\Downloads\Python>python nullcheck.py Checking: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts ('tahoma.ttf\x000\x000\x00\x00\x00', 1) Tahoma (TrueType) ('verdref.ttf\x000\x000\x00PA\x00\x00\x00\x00', 1) Verdana Ref (TrueType) ('grgaref.ttf\x000\x000\x00PA\x00\x00\x00\x00', 1) Georgia Ref (TrueType) ('refspec.ttf\x000\x000\x00PA\x10\x00%APP', 1) RefSpecialty (TrueType) Cannot open: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Fonts done C:\Users\Anshul\Downloads\Python>activate python2.7.10 Activating environment "C:\Anaconda3\envs\python2.7.10"... [python2.7] C:\Users\Anshul\Downloads\Python>python -V Python 2.7.10 :: Continuum Analytics, Inc. [python2.7] C:\Users\Anshul\Downloads\Python>python nullcheck.py Traceback (most recent call last): File "nullcheck.py", line 3, in import winreg ImportError: No module named winreg [python2.7] C:\Users\Anshul\Downloads\Python> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 13:21:45 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 02 Dec 2015 18:21:45 +0000 Subject: [issue24934] django_v2 benchmark not working in Python 3.6 In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za> Message-ID: <1449080505.37.0.72853691471.issue24934@psf.upfronthosting.co.za> Brett Cannon added the comment: Django 1.9 is out, so when I have time I will create a django_v3 benchmark. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 13:32:16 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 18:32:16 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449081136.74.0.357231427979.issue25782@psf.upfronthosting.co.za> Yury Selivanov added the comment: Serhiy, good idea, thanks! Please review the attached patch. Larry, I view this as a very serious bug. Can we ship 3.5.1 with it fixed? ---------- keywords: +patch Added file: http://bugs.python.org/file41212/Issue25782.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 13:33:28 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 18:33:28 +0000 Subject: [issue25779] deadlock with asyncio+contextmanager+ExitStack In-Reply-To: <1449070645.76.0.674051861514.issue25779@psf.upfronthosting.co.za> Message-ID: <1449081208.89.0.526219313777.issue25779@psf.upfronthosting.co.za> Yury Selivanov added the comment: FWIW the bug was identified in issue 25782. I've drafted a patch to fix it, please review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 13:35:31 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 18:35:31 +0000 Subject: [issue25779] deadlock with asyncio+contextmanager+ExitStack In-Reply-To: <1449070645.76.0.674051861514.issue25779@psf.upfronthosting.co.za> Message-ID: <1449081331.74.0.0561852337952.issue25779@psf.upfronthosting.co.za> Yury Selivanov added the comment: The question is whether we should raise an exception or not: ex.__context__ = ex ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 13:44:17 2015 From: report at bugs.python.org (SilentGhost) Date: Wed, 02 Dec 2015 18:44:17 +0000 Subject: [issue25784] Please consider integrating performance fix for ipaddress.py In-Reply-To: <1449078856.21.0.545889486519.issue25784@psf.upfronthosting.co.za> Message-ID: <1449081857.11.0.375257551133.issue25784@psf.upfronthosting.co.za> SilentGhost added the comment: Perhaps I'm wrong, but a superficial inspection of the ipaddress.py seem to indicate that it's not affected by the same issue. _find_address_range is implemented as a generator, it doesn't restart comparison on every iteration. Alexander, did you experience any performance issues when using ipaddress module from standard library? ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 13:56:18 2015 From: report at bugs.python.org (Eryk Sun) Date: Wed, 02 Dec 2015 18:56:18 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449082578.29.0.265334701324.issue25778@psf.upfronthosting.co.za> Eryk Sun added the comment: I only wrote it for Python 3, but it would be interesting to see what you get with Python 2. Please try nullcheck2.py. ---------- Added file: http://bugs.python.org/file41213/nullcheck2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 13:59:08 2015 From: report at bugs.python.org (Jack O'Connor) Date: Wed, 02 Dec 2015 18:59:08 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449082748.3.0.500422092472.issue25782@psf.upfronthosting.co.za> Jack O'Connor added the comment: Yury, do we need to handle more complicated infinite loops, where "self" doesn't actually show up in the loop? Here's an example: try: raise Exception except Exception as ex: loop1 = Exception() loop2 = Exception() loop1.__context__ = loop2 loop2.__context__ = loop1 ex.__context__ = loop1 hasattr(1, 'aa') I'm unfamiliar with CPython, so I don't know whether full-blown loop detection belongs here. Maybe we could add a hardcoded limit like "fail if we loop more than X times"? ---------- nosy: +oconnor663 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 14:12:13 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 19:12:13 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449083533.35.0.319593697385.issue25782@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Yury, do we need to handle more complicated infinite loops, where "self" doesn't actually show up in the loop? Here's an example: My patch works for your example too. Since it checks for loops in __context__ setter, you shouldn't be able to create complicated loops. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 14:12:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Dec 2015 19:12:59 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449083579.08.0.00728099866902.issue25782@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Should we do the same for __cause__? Is it possible to create __context__ or __cause__ loop without assigning these attributes directly? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 14:13:11 2015 From: report at bugs.python.org (Anshul Agrawal) Date: Wed, 02 Dec 2015 19:13:11 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449083591.09.0.385159121578.issue25778@psf.upfronthosting.co.za> Anshul Agrawal added the comment: Here it is: [python2.7] C:\Users\Anshul\Downloads\Python>python -V Python 2.7.10 :: Continuum Analytics, Inc. [python2.7] C:\Users\Anshul\Downloads\Python>python nullcheck2.py Checking: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts (u'tahoma.ttf\x000\x000\x00\x00\x00', 1), Tahoma (TrueType) (u'verdref.ttf\x000\x000\x00PA\x00\x00\x00\x00', 1), Verdana Ref (TrueType) (u'grgaref.ttf\x000\x000\x00PA\x00\x00\x00\x00', 1), Georgia Ref (TrueType) (u'refspec.ttf\x000\x000\x00PA\x10\x00%APP', 1), RefSpecialty (TrueType) Cannot open: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Fonts done [python2.7] C:\Users\Anshul\Downloads\Python>activate Deactivating environment "C:\Anaconda3\envs\python2.7.10"... Activating environment "C:\Anaconda3\Scripts\..\"... C:\Users\Anshul\Downloads\Python>python -V Python 3.5.0 :: Anaconda 2.4.0 (64-bit) C:\Users\Anshul\Downloads\Python>python nullcheck2.py Checking: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts ('tahoma.ttf\x000\x000\x00\x00\x00', 1), Tahoma (TrueType) ('verdref.ttf\x000\x000\x00PA\x00\x00\x00\x00', 1), Verdana Ref (TrueType) ('grgaref.ttf\x000\x000\x00PA\x00\x00\x00\x00', 1), Georgia Ref (TrueType) ('refspec.ttf\x000\x000\x00PA\x10\x00%APP', 1), RefSpecialty (TrueType) Cannot open: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Fonts done C:\Users\Anshul\Downloads\Python> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 14:16:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Dec 2015 19:16:44 +0000 Subject: [issue6395] Infinite Recursion during Unpickling a codecs Object In-Reply-To: <1246463188.35.0.320675118154.issue6395@psf.upfronthosting.co.za> Message-ID: <1449083804.49.0.848808704207.issue6395@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > If the StreamWriter/Reader cannot pickle the underlying stream (which is probably always the case), why should the object itself be pickleable ? io.BytesIO() and io.StringIO() are pickleable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 14:27:52 2015 From: report at bugs.python.org (Felipe Cruz) Date: Wed, 02 Dec 2015 19:27:52 +0000 Subject: [issue25785] TimedRotatingFileHandler missing rotations Message-ID: <1449084472.03.0.0629669508216.issue25785@psf.upfronthosting.co.za> New submission from Felipe Cruz: I'm using TimedRotatingFileHandler to rotate a log file *every* minute. If I stop my program, in the middle of a minute, and start again, the next rotation will happen at (currentTime + 60). The result of this behavior is that I'll end up with files "log_01" and "log_03", instead of "log_01", "log_02" and "log_03". I'm using this class with a little modification which sets the next rollover time to (currentTime + (self.interval - currentSecond)). In this case, even If I stop and start my program in the middle a minute, the next rollover time will be the end of the current minute, not 60 seconds later and the result will be one file for each minute. To sum up, what happen is that the same program with the very same configuration, produces a different result if stopped for even just one second. If the interval was "rotate every 60 seconds" I would be ok, but If I'm configuring to rotate every minute I expect one file for each minute if the program was running the time the minutes changed. ---------- messages: 255757 nosy: felipecruz priority: normal severity: normal status: open title: TimedRotatingFileHandler missing rotations type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 14:31:58 2015 From: report at bugs.python.org (SilentGhost) Date: Wed, 02 Dec 2015 19:31:58 +0000 Subject: [issue25785] TimedRotatingFileHandler missing rotations In-Reply-To: <1449084472.03.0.0629669508216.issue25785@psf.upfronthosting.co.za> Message-ID: <1449084718.22.0.188578392062.issue25785@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Library (Lib) nosy: +vinay.sajip type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 14:41:55 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 19:41:55 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449085315.44.0.613326400579.issue25782@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Should we do the same for __cause__? Is it possible to create __context__ or __cause__ loop without assigning these attributes directly? Yes, let's mirror the __context__ behaviour for __cause__. New patch attached. Serhiy, Guido, The new patch raises a TypeError in __cause__ and __context__ setters when a cycle was introduced, so in pure Python the following won't work: # will throw TypeError("cycle in exception context chain") ex.__context__ = ex chain") # will throw TypeError("cycle in exception cause chain") ex.__cause__ = ex However, since PyException_SetContext and PyException_SetCause are public APIs, and their return type is 'void', I can't raise an error when a C code introduces a cycle, in that case, the exc->cause/exc->context will be set to NULL. Thoughts? I think that this approach is the only sane one here. We can certainly fix the infinite loop in PyErr_SetObject, but it will only be a matter of time until we discover a similar loop somewhere else. ---------- Added file: http://bugs.python.org/file41214/Issue25782_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 14:50:33 2015 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Dec 2015 19:50:33 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449085315.44.0.613326400579.issue25782@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Ouch, it's unfortunate those APIs don't have an error return. :-( Setting it to NULL is one option -- silently ignoring the assignment (leaving whatever was there) might also be good? In 90% of the cases it would be the same thing right? (I'm not familiar with this part of the code TBH.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 14:54:39 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 19:54:39 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449086079.66.0.491654232011.issue25782@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Setting it to NULL is one option -- silently ignoring the assignment (leaving whatever was there) might also be good? In 90% of the cases it would be the same thing right? But leaving the old __context__ there will completely mask the bug... And as for pure python code -- do you agree we better raise a TypeError if a cycle is about to be introduced? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 14:55:53 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 02 Dec 2015 19:55:53 +0000 Subject: [issue6395] Infinite Recursion during Unpickling a codecs Object In-Reply-To: <1449083804.49.0.848808704207.issue6395@psf.upfronthosting.co.za> Message-ID: <565F4CC4.1030405@egenix.com> Marc-Andre Lemburg added the comment: On 02.12.2015 20:16, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > >> If the StreamWriter/Reader cannot pickle the underlying stream (which is >> probably always the case), why should the object itself be pickleable ? > > io.BytesIO() and io.StringIO() are pickleable. Ok, but I still don't see the use case :-) I think all we need to do is add a .__reduce__() method to StreamWriter and StreamReader, which then raises a PickleError. Example: >>> import sys, codecs, pickle >>> r = codecs.getreader('latin-1') >>> class MyReader(r): ... def __reduce__(self, *args): ... raise pickle.PickleError ... >>> s = MyReader(sys.stdin) >>> pickle.dumps(s) Traceback (most recent call last): File "", line 1, in File "", line 3, in __reduce__ _pickle.PickleError > (3)__reduce__() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 14:58:45 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 19:58:45 +0000 Subject: [issue25786] contextlib.ExitStack introduces a cycle in exception __context__ Message-ID: <1449086325.2.0.703552973067.issue25786@psf.upfronthosting.co.za> New submission from Yury Selivanov: See http://bugs.python.org/issue25779 and http://bugs.python.org/issue25782 for details. ---------- components: Library (Lib) messages: 255762 nosy: gvanrossum, ncoghlan, serhiy.storchaka, yselivanov priority: release blocker severity: normal status: open title: contextlib.ExitStack introduces a cycle in exception __context__ versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 14:59:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Dec 2015 19:59:49 +0000 Subject: [issue6395] Infinite Recursion during Unpickling a codecs Object In-Reply-To: <1246463188.35.0.320675118154.issue6395@psf.upfronthosting.co.za> Message-ID: <1449086389.94.0.877421307555.issue6395@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added tests for pickling and deepcopying. ---------- Added file: http://bugs.python.org/file41215/codecs_stream_delegating_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 14:59:54 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 19:59:54 +0000 Subject: [issue25786] contextlib.ExitStack introduces a cycle in exception __context__ In-Reply-To: <1449086325.2.0.703552973067.issue25786@psf.upfronthosting.co.za> Message-ID: <1449086394.91.0.562131513972.issue25786@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, could you please take a look at the attached patch? ---------- keywords: +patch Added file: http://bugs.python.org/file41216/Issue25786.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 15:00:42 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 02 Dec 2015 20:00:42 +0000 Subject: [issue1927] raw_input behavior incorrect if readline not enabled In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za> Message-ID: <1449086442.48.0.27333943601.issue1927@psf.upfronthosting.co.za> Changes by Jason R. Coombs : ---------- nosy: +jason.coombs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 15:00:52 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 02 Dec 2015 20:00:52 +0000 Subject: [issue1927] raw_input behavior incorrect if readline not enabled In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za> Message-ID: <1449086452.31.0.283234461985.issue1927@psf.upfronthosting.co.za> Changes by Jason R. Coombs : ---------- versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 15:00:52 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 20:00:52 +0000 Subject: [issue25779] deadlock with asyncio+contextmanager+ExitStack In-Reply-To: <1449070645.76.0.674051861514.issue25779@psf.upfronthosting.co.za> Message-ID: <1449086452.72.0.325055698969.issue25779@psf.upfronthosting.co.za> Yury Selivanov added the comment: Another issue for contextlib: http://bugs.python.org/issue25786 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 15:03:58 2015 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Dec 2015 20:03:58 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449086079.66.0.491654232011.issue25782@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > But leaving the old __context__ there will completely mask the bug... OK, NULL is fine then. >we better raise a TypeError if a cycle is about to be introduced? Yes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 15:06:12 2015 From: report at bugs.python.org (Jack O'Connor) Date: Wed, 02 Dec 2015 20:06:12 +0000 Subject: [issue25786] contextlib.ExitStack introduces a cycle in exception __context__ In-Reply-To: <1449086325.2.0.703552973067.issue25786@psf.upfronthosting.co.za> Message-ID: <1449086772.61.0.46066867543.issue25786@psf.upfronthosting.co.za> Changes by Jack O'Connor : ---------- nosy: +oconnor663 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 15:06:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Dec 2015 20:06:57 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449086817.77.0.218988863381.issue25782@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yet one option is the emersion of the exception. Affected exception is removed from the chain and added at it head. If there is a chain A -> B -> C -> D -> E, after assignment C.__context__ = A we will get a chain C -> A -> B -> D -> E. No exception is lost. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 15:11:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Dec 2015 20:11:00 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449086817.77.0.218988863381.issue25782@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Larry, I view this as a very serious bug. Can we ship 3.5.1 with it fixed? Don't do that, a few hours (!) is not enough to test a fix. It's too late after a RC1 for such critical change (exceptions). The bug was here since at least Python 3.3, there is no urgency to fix it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 15:13:59 2015 From: report at bugs.python.org (desbma) Date: Wed, 02 Dec 2015 20:13:59 +0000 Subject: [issue25156] shutil.copyfile should internally use os.sendfile when possible In-Reply-To: <1442520485.03.0.419427125487.issue25156@psf.upfronthosting.co.za> Message-ID: <1449087239.76.0.259062989996.issue25156@psf.upfronthosting.co.za> desbma added the comment: Ping A small patch, but a good performance improvement :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 15:15:30 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 20:15:30 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449087330.0.0.471070360318.issue25782@psf.upfronthosting.co.za> Yury Selivanov added the comment: >Don't do that, a few hours (!) is not enough to test a fix. It's too late after a RC1 for such critical change (exceptions). Maybe we can add an RC2? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 15:21:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Dec 2015 20:21:42 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449087702.46.0.215668160384.issue25782@psf.upfronthosting.co.za> STINNER Victor added the comment: > Maybe we can add an RC2? Seriously? I'm waiting Python 3.5.1 since 3.5.0 was released. I'm amazed how much time it takes to release a first bugfix version, 3.5.0 was full a bugs (see the changelog). It's very easy to workaround this issue in pure Python. Why do you want the fix *RIGHT NOW*? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 15:21:50 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 20:21:50 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449087710.17.0.0404508927469.issue25782@psf.upfronthosting.co.za> Yury Selivanov added the comment: > If there is a chain A -> B -> C -> D -> E, after assignment C.__context__ = A we will get a chain C -> A -> B -> D -> E. No exception is lost. What to do when you try to chain "C -> C"? I'm not sure I like this reordering idea -- it might introduce some *very* hard to find bugs -- you expected one type of exception, then you used some external library, and after that you have a completely different exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 15:24:15 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 20:24:15 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449087855.08.0.398333822201.issue25782@psf.upfronthosting.co.za> Yury Selivanov added the comment: > It's very easy to workaround this issue in pure Python. Why do you want the fix *RIGHT NOW*? Please look at http://bugs.python.org/issue25779. I think we either should fix this issue, or fix http://bugs.python.org/issue25786 in 3.5.1, since I can't find a workaround for it. The latter issue is probably easier to get into 3.5.1? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 15:29:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Dec 2015 20:29:08 +0000 Subject: [issue6395] Infinite Recursion during Unpickling a codecs Object In-Reply-To: <1246463188.35.0.320675118154.issue6395@psf.upfronthosting.co.za> Message-ID: <1449088148.7.0.819396670898.issue6395@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > I think all we need to do is add a .__reduce__() > method to StreamWriter and StreamReader, which then > raises a PickleError. Rather TypeError. Yes, it is the least that we should to do in maintained releases. If codecs_stream_delegating_2.patch is considered too drastic for bugfix. But this can be only a part of problem. May be there are issues with other optional special methods. And adding __reduce_ex__ breaks subclass pickleability if it was implemented with __getstate__ and __getnewargs__. Here is a patch for this way. ---------- Added file: http://bugs.python.org/file41217/codecs_stream_forbid_pickling.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 15:33:38 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Dec 2015 20:33:38 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449087855.08.0.398333822201.issue25782@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Yury Selivanov added the comment: > Please look at http://bugs.python.org/issue25779. I think we either should fix this issue, or fix http://bugs.python.org/issue25786 in 3.5.1, since I can't find a workaround for it. The latter issue is probably easier to get into 3.5.1? It's a choice for the release manager. But IHMO there will always be bugs :-) It looks like you found a lot of issues related to exceptions handling. Maybe it would be better to fix all the them "at once" in 3.5.2? And then ask Larry to release it early? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 15:39:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Dec 2015 20:39:53 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449088793.33.0.766065863355.issue25782@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > What to do when you try to chain "C -> C"? Nothing. Or may be raise an exception (because C.__context__ can't be set to what you try). > you expected one type of exception, then you used some external library, and after that you have a completely different exception. I don't understand what new can add the reordering. It doesn't change original exception, it only changes __context__, but you change it in any case. If silently ignore the loop, you would get __context__ different from what you expected. If raise TypeError, you would get TypeError instead of expected exception. And if the decision will be to raise TypeError, may be RuntimeError is more appropriate? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 15:40:27 2015 From: report at bugs.python.org (Jack O'Connor) Date: Wed, 02 Dec 2015 20:40:27 +0000 Subject: [issue25779] deadlock with asyncio+contextmanager+ExitStack In-Reply-To: <1449070645.76.0.674051861514.issue25779@psf.upfronthosting.co.za> Message-ID: <1449088827.72.0.75277069663.issue25779@psf.upfronthosting.co.za> Jack O'Connor added the comment: Yury, can you help me understand why `hasattr("foo", "bar")` triggers the infinite loop there, but not `print("foo")`? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 15:42:08 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 20:42:08 +0000 Subject: [issue25779] deadlock with asyncio+contextmanager+ExitStack In-Reply-To: <1449070645.76.0.674051861514.issue25779@psf.upfronthosting.co.za> Message-ID: <1449088928.24.0.557699402309.issue25779@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Yury, can you help me understand why `hasattr("foo", "bar")` triggers the infinite loop there, but not `print("foo")`? hasattr uses getattr under the hood. getattr raises an AttributeError, and that triggers PyErr_SetError, which has an infinite "while" loop. Instead of "hasattr" you can use anything that raises an error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 15:52:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Dec 2015 20:52:04 +0000 Subject: [issue25783] test_traceback.test_walk_stack() fails when run directly (without regrtest) In-Reply-To: <1449078273.26.0.535537969115.issue25783@psf.upfronthosting.co.za> Message-ID: <1449089524.97.0.339803553015.issue25783@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 16:10:04 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 02 Dec 2015 21:10:04 +0000 Subject: [issue1927] raw_input behavior incorrect if readline not enabled In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za> Message-ID: <1449090604.88.0.873104349719.issue1927@psf.upfronthosting.co.za> Jason R. Coombs added the comment: +1 to applying this patch. After reviewing this and Issue 12869, I don't see any substantial objections or concerns. The status is "test needed". Is a test really needed? My instinct that simply aligning the implementation with the docs is sufficient. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 16:14:19 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 02 Dec 2015 21:14:19 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449090859.65.0.068915811484.issue25782@psf.upfronthosting.co.za> Larry Hastings added the comment: > Please look at http://bugs.python.org/issue25779. You closed that one and marked it "not a bug"...? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 16:16:24 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 21:16:24 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449090984.66.0.385319833453.issue25782@psf.upfronthosting.co.za> Yury Selivanov added the comment: > You closed that one and marked it "not a bug"...? That particular issue was about asyncio. After reducing it, I created two new issues -- this one, and another one about another bug in contextlib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 16:25:36 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Dec 2015 21:25:36 +0000 Subject: [issue25780] Add support for CAN_RAW_JOIN_FILTERS In-Reply-To: <1449074447.29.0.213464499345.issue25780@psf.upfronthosting.co.za> Message-ID: <1449091536.49.0.605847895632.issue25780@psf.upfronthosting.co.za> Martin Panter added the comment: Not sure what the general policy is, but IMO it is better to leave offensive white space as it is to avoid flooding the file history and diffs, unless you are editing nearby lines. I will leave some review comments for the documentation. ---------- nosy: +martin.panter stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 16:47:19 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 02 Dec 2015 21:47:19 +0000 Subject: [issue25780] Add support for CAN_RAW_JOIN_FILTERS In-Reply-To: <1449074447.29.0.213464499345.issue25780@psf.upfronthosting.co.za> Message-ID: <1449092839.84.0.514129569549.issue25780@psf.upfronthosting.co.za> R. David Murray added the comment: In this particular case, whether we want to do that to config.ac is a separate question and should be addressed in a separate issue. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 16:48:34 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 02 Dec 2015 21:48:34 +0000 Subject: [issue25500] docs claim __import__ checked for in globals, but IMPORT_NAME bytecode does not In-Reply-To: <1446068084.58.0.390651859443.issue25500@psf.upfronthosting.co.za> Message-ID: <1449092914.29.0.459130437835.issue25500@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: docs at python -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 16:50:46 2015 From: report at bugs.python.org (Stefan Tatschner) Date: Wed, 02 Dec 2015 21:50:46 +0000 Subject: [issue25780] Add support for CAN_RAW_JOIN_FILTERS In-Reply-To: <1449074447.29.0.213464499345.issue25780@psf.upfronthosting.co.za> Message-ID: <1449093046.16.0.0145956029262.issue25780@psf.upfronthosting.co.za> Stefan Tatschner added the comment: Because is the first time I work with this bugtracking system on python.org, how can I update my patch? :) Just upload a new one? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 16:52:15 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 02 Dec 2015 21:52:15 +0000 Subject: [issue25780] Add support for CAN_RAW_JOIN_FILTERS In-Reply-To: <1449074447.29.0.213464499345.issue25780@psf.upfronthosting.co.za> Message-ID: <1449093135.62.0.531865788018.issue25780@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 16:53:15 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 02 Dec 2015 21:53:15 +0000 Subject: [issue6395] Infinite Recursion during Unpickling a codecs Object In-Reply-To: <1449088148.7.0.819396670898.issue6395@psf.upfronthosting.co.za> Message-ID: <565F6846.5030303@egenix.com> Marc-Andre Lemburg added the comment: On 02.12.2015 21:29, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > >> I think all we need to do is add a .__reduce__() >> method to StreamWriter and StreamReader, which then >> raises a PickleError. > > Rather TypeError. Yes, it is the least that we should to do in maintained releases. If codecs_stream_delegating_2.patch is considered too drastic for bugfix. But this can be only a part of problem. May be there are issues with other optional special methods. And adding __reduce_ex__ breaks subclass pickleability if it was implemented with __getstate__ and __getnewargs__. > > Here is a patch for this way. Thanks. I think using __reduce__ instead of __reduce_ex__ is safer, since subclasses will more likely override __reduce__ than __reduce_ex__. The other approach will have too many backwards incompatible side effects, e.g. the repr() over StreamReader instances would change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 16:53:22 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 02 Dec 2015 21:53:22 +0000 Subject: [issue25780] Add support for CAN_RAW_JOIN_FILTERS In-Reply-To: <1449074447.29.0.213464499345.issue25780@psf.upfronthosting.co.za> Message-ID: <1449093202.69.0.41792843701.issue25780@psf.upfronthosting.co.za> R. David Murray added the comment: Yes. The review system will automatically include the new patch, regardless of its name (it looks at the content). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 16:56:06 2015 From: report at bugs.python.org (Stefan Tatschner) Date: Wed, 02 Dec 2015 21:56:06 +0000 Subject: [issue25780] Add support for CAN_RAW_JOIN_FILTERS In-Reply-To: <1449074447.29.0.213464499345.issue25780@psf.upfronthosting.co.za> Message-ID: <1449093366.97.0.749247899326.issue25780@psf.upfronthosting.co.za> Stefan Tatschner added the comment: Thanks! Here is an update. ---------- Added file: http://bugs.python.org/file41218/can_raw_join_filters-no-whitespace-v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 17:01:08 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Dec 2015 22:01:08 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449093668.83.0.700455876559.issue25782@psf.upfronthosting.co.za> Yury Selivanov added the comment: Serhiy, Victor, thank you for your reviews. Another version of the patch is attached. ---------- Added file: http://bugs.python.org/file41219/Issue25782_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 17:04:56 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Dec 2015 22:04:56 +0000 Subject: [issue25780] Add support for CAN_RAW_JOIN_FILTERS In-Reply-To: <1449074447.29.0.213464499345.issue25780@psf.upfronthosting.co.za> Message-ID: <1449093896.84.0.579509378561.issue25780@psf.upfronthosting.co.za> Martin Panter added the comment: The other thing for new features is test cases. I don?t know if there are any existing CAN socket tests (in fact I don?t know anything about CAN sockets). Is it possible to make a test for this? Even if it just ensures that the setting can be applied when supported. Though I guess if this is too hard it may not be worth it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 17:06:58 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 02 Dec 2015 22:06:58 +0000 Subject: [issue25782] CPython hangs on error __context__ set to the error itself In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za> Message-ID: <1449094018.99.0.395527359385.issue25782@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 17:07:48 2015 From: report at bugs.python.org (Stefan Tatschner) Date: Wed, 02 Dec 2015 22:07:48 +0000 Subject: [issue25780] Add support for CAN_RAW_JOIN_FILTERS In-Reply-To: <1449074447.29.0.213464499345.issue25780@psf.upfronthosting.co.za> Message-ID: <1449094068.3.0.88150377471.issue25780@psf.upfronthosting.co.za> Stefan Tatschner added the comment: Hmm. I just adapted this feature request from issue22631 for the new constant and I verified that my patch actually works. I could try to provide a test, but then I would have to open Pandora's box as I am not a CPython developer at all. :/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 17:09:22 2015 From: report at bugs.python.org (Alexander Finkel) Date: Wed, 02 Dec 2015 22:09:22 +0000 Subject: [issue25784] Please consider integrating performance fix for ipaddress.py In-Reply-To: <1449078856.21.0.545889486519.issue25784@psf.upfronthosting.co.za> Message-ID: <1449094162.87.0.302305568568.issue25784@psf.upfronthosting.co.za> Alexander Finkel added the comment: Thanks for the responses. I'm afraid I was looking at the Python 3.3 source code on my desktop, it looks like the problem was fixed in the Mercurial repo about 10 months ago by https://hg.python.org/cpython/rev/f7508a176a09 Marked this issue as a duplicate? Feel free to change the resolution if that isn't right. Cheers, Alex ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 17:16:32 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Dec 2015 22:16:32 +0000 Subject: [issue10141] SocketCan support In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za> Message-ID: <1449094592.58.0.0769933952788.issue10141@psf.upfronthosting.co.za> Martin Panter added the comment: Sounds like the last problem has been fixed, so can we close this? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 17:33:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Dec 2015 22:33:13 +0000 Subject: [issue25784] Please consider integrating performance fix for ipaddress.py In-Reply-To: <1449078856.21.0.545889486519.issue25784@psf.upfronthosting.co.za> Message-ID: <1449095593.87.0.0309809939535.issue25784@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: duplicate -> out of date stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 18:06:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Dec 2015 23:06:28 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <20151202230625.29962.21033@psf.io> Roundup Robot added the comment: New changeset 67718032badb by Serhiy Storchaka in branch '3.4': Issue #25709: Fixed problem with in-place string concatenation and utf-8 cache. https://hg.python.org/cpython/rev/67718032badb New changeset a0e2376768dc by Serhiy Storchaka in branch '3.5': Issue #25709: Fixed problem with in-place string concatenation and utf-8 cache. https://hg.python.org/cpython/rev/a0e2376768dc New changeset 9e800b2aeeac by Serhiy Storchaka in branch 'default': Issue #25709: Fixed problem with in-place string concatenation and utf-8 cache. https://hg.python.org/cpython/rev/9e800b2aeeac ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 18:18:14 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Dec 2015 23:18:14 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1449098293.99.0.417197997114.issue25709@psf.upfronthosting.co.za> STINNER Victor added the comment: > New changeset 67718032badb by Serhiy Storchaka in branch '3.4': Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 18:27:00 2015 From: report at bugs.python.org (Justin Patrin) Date: Wed, 02 Dec 2015 23:27:00 +0000 Subject: [issue6766] Cannot modify dictionaries inside dictionaries using Managers from multiprocessing In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za> Message-ID: <1449098820.46.0.335085232499.issue6766@psf.upfronthosting.co.za> Justin Patrin added the comment: I'm still running into these issues with Python 2.7.10. I'm trying to find a way to share dynamically allocated sub-dictionaries through multiprocessing as well as dynamically allocated RLock and Value instances. I can use the manager to create them but when I put them in a managed dict the various issues related in this ticket happen. ---------- nosy: +Justin Patrin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 18:40:03 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Dec 2015 23:40:03 +0000 Subject: [issue1927] raw_input behavior incorrect if readline not enabled In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za> Message-ID: <1449099603.62.0.931622573722.issue1927@psf.upfronthosting.co.za> Martin Panter added the comment: ?Test needed? is meant to mean someone needs help producing the problem, but people also seem use it to request a refined test case for the test suite. A test case is always nice, although in this case it is a bit tricky. I can try to knock one up use the existing infrastructure in test_builtin.PtyTests. A similar test case could probably be made for the interactive interpreter (Issue 12869), but might be more involved, and I don?t think there is any existing code to copy from. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 19:15:37 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 03 Dec 2015 00:15:37 +0000 Subject: [issue25777] Misleading descriptions in docs about invoking descriptors. In-Reply-To: <1449058941.53.0.26351823319.issue25777@psf.upfronthosting.co.za> Message-ID: <1449101737.29.0.99379430675.issue25777@psf.upfronthosting.co.za> Martin Panter added the comment: Agreed. The same problem is also present in the Python 3 documentation. (Beware there is another report somewhere about updating this how-to more generally for Python 3.) Maybe we could be more explicit and start off ?The attribute lookup super(B, obj).m searches .?.?.? Also, I find the last sentence confusing: ?If not in the dictionary, m reverts to a search using object.__getattribute__().? I guess it is describing how super(B, obj).__self__ accesses the internal attribute of the super object itself. Maybe it should say ?If not in any base class, the lookup resorts to attributes of the super instance itself using object.__getattribute__().? ---------- stage: -> needs patch versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 19:46:38 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 03 Dec 2015 00:46:38 +0000 Subject: [issue25786] contextlib.ExitStack introduces a cycle in exception __context__ In-Reply-To: <1449086325.2.0.703552973067.issue25786@psf.upfronthosting.co.za> Message-ID: <1449103598.19.0.0547976902362.issue25786@psf.upfronthosting.co.za> Martin Panter added the comment: If I understand this issue correctly, perhaps the test case should be augmented to check for a cycle: try: main() except RuntimeError as exc: self.assertIsNone(exc.__cause__) else: self.fail("Expected RuntimeError") ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 20:54:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Dec 2015 01:54:03 +0000 Subject: [issue14285] Traceback wrong on ImportError while executing a package In-Reply-To: <1331621436.28.0.000669565075438.issue14285@psf.upfronthosting.co.za> Message-ID: <20151203015359.6840.74138@psf.io> Roundup Robot added the comment: New changeset 784a64a21fd0 by Martin Panter in branch '3.5': Issue #14285: Do not catch __init__.py exceptions in runpy https://hg.python.org/cpython/rev/784a64a21fd0 New changeset 01397c11ebb8 by Martin Panter in branch 'default': Issue #14285: Merge runpy exception fix from 3.5 https://hg.python.org/cpython/rev/01397c11ebb8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 21:12:47 2015 From: report at bugs.python.org (Eryk Sun) Date: Thu, 03 Dec 2015 02:12:47 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449108767.98.0.566795750995.issue25778@psf.upfronthosting.co.za> Eryk Sun added the comment: Here's a patch for Python 3 that modifies the Reg2Py function in PC/winreg.c for the case of REG_SZ/REG_EXPAND_SZ. The existing code took a conservative approach by only removing a null character at the end of a buffer. I modified it to use wcsnlen instead. I added a test that depends on setting a string containing null values via winreg.SetValueEx. It could be rewritten using ctypes if it's desired to also prevent the setting of strings that contain null values. Note that the patch also fixes an error in the delete_tree method. The desired access for OpenKey was mistakenly being passed as the "reserved" argument. ---------- keywords: +patch stage: test needed -> patch review Added file: http://bugs.python.org/file41220/issue25778_py3_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 22:03:23 2015 From: report at bugs.python.org (Anshul Agrawal) Date: Thu, 03 Dec 2015 03:03:23 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449111803.18.0.738824787118.issue25778@psf.upfronthosting.co.za> Anshul Agrawal added the comment: Thanks Eryk, but I'm afraid I didn't follow most of what you said in your post. As an end-user, I just wanted to be able to install the packages, import them, and then use within Python. It is still not clear to me whether this is a problem with Python3, or a Matplotlib/Seaborn problem (and if it is the latter, are those folks informed?) Do you need me to do any further tests with your patch - if so, kindly give detailed step-by-step instructions. If not, please confirm that your patch will simply be incorporated in future releases of Python3, so that users wouldn't have to resort to the "one line patch" mentioned in my very first post. Thanks for all your help! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 22:29:39 2015 From: report at bugs.python.org (Karl Richter) Date: Thu, 03 Dec 2015 03:29:39 +0000 Subject: [issue25787] Add an explanation what happens with subprocess parent and child processes when signals are sent Message-ID: <1449113379.93.0.748465414277.issue25787@psf.upfronthosting.co.za> New submission from Karl Richter: The [documentation of subprocess](https://docs.python.org/3.6/library/subprocess.html) doesn't contain a substantial statement how signals are handled which are send to the python interpreter. After reading the referenced docs it should be clear * whether a signal is passed to both the parent and the child (If yes in which order? What happens if the child process spawns a process which isn't controlled by python?) * whether signal handlers are inherited (judging from the `restore_signals` parameter some are overwritten -> what's the purpose of this?). Are changes of a signal handler in the parent reflected in the child? ---------- assignee: docs at python components: Documentation messages: 255802 nosy: docs at python, krichter priority: normal severity: normal status: open title: Add an explanation what happens with subprocess parent and child processes when signals are sent versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 2 23:22:25 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Dec 2015 04:22:25 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449116545.25.0.390481463451.issue25778@psf.upfronthosting.co.za> Zachary Ware added the comment: Left one minor comment on Rietveld. However, I'm not yet convinced that this is a bug in Python. I can't find an authoritative source to say whether \0 is valid in a REG_SZ value, but the fact that you can set one and get it back makes me think it is (for certain values of 'valid'). I don't see why the original issue with matplotlib would only happen with Python 3 and not Python 2, though. Also, running nullcheck.py on my 8.1 VM gave no results. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 00:33:11 2015 From: report at bugs.python.org (random832) Date: Thu, 03 Dec 2015 05:33:11 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449120791.41.0.884521136101.issue25778@psf.upfronthosting.co.za> random832 added the comment: > I don't see why the original issue with matplotlib would only happen with Python 3 and not Python 2, though. Is it possible that Python 2 is using a non-unicode Windows API to get the values, and the non-unicode API is converting the string (which is, of course, in UTF-16 in the registry itself) in a way that ignores characters after the first null? (And presumably likewise after the first double null in a REG_MULTI_SZ) This would be a pretty strong argument that embedded nulls aren't meant to be acceptable in REG_SZ values (as anything other than ignored garbage). ---------- nosy: +random832 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 00:51:26 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Dec 2015 05:51:26 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449121886.43.0.399030280597.issue25778@psf.upfronthosting.co.za> Zachary Ware added the comment: > Is it possible that Python 2 is using a non-unicode Windows API to get the > values It does, but according to Anshul's nullcheck2.py output that doesn't matter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 01:00:56 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 03 Dec 2015 06:00:56 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449122456.0.0.359770214838.issue25778@psf.upfronthosting.co.za> Steve Dower added the comment: All registry values are blobs and it's up to the caller to decide how to read it - the "types" are hints and are not binding. I don't mind the default behavior being to trim at the first null, but it is a lossy operation on our side and so we really ought to provide an easy way to get the true value back. Otherwise, we couldn't easily write scripts in Python to detect registry values with embedded nulls :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 01:07:26 2015 From: report at bugs.python.org (random832) Date: Thu, 03 Dec 2015 06:07:26 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449122846.09.0.504342046973.issue25778@psf.upfronthosting.co.za> random832 added the comment: > All registry values are blobs and it's up to the caller to decide how to read it - the "types" are hints and are not binding. Just out of curiosity, what do we do if a REG_DWORD is more (or less?) than four bytes? Can that happen? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 01:30:27 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Dec 2015 06:30:27 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449124227.84.0.475227123469.issue25778@psf.upfronthosting.co.za> Zachary Ware added the comment: So then this is actually matplotlib's bug: Python is returning the blob as it should, but matplotlib is assuming too much about what it contains. However, I suspect that this particular issue isn't entirely matplotlib's fault; it looks to me like the entries nullcheck2.py turned up were inserted badly. Most of them look almost (but not quite...) like REG_MULTI_SZ entries. The winreg module is a low-level interface; I don't think we should change this behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 01:43:33 2015 From: report at bugs.python.org (random832) Date: Thu, 03 Dec 2015 06:43:33 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449125013.68.0.956466130789.issue25778@psf.upfronthosting.co.za> random832 added the comment: > The winreg module is a low-level interface High enough to return a string instead of bytes, an int for REG_DWORD, and to parse out REG_MULTI_SZ into a list. Maybe for if people really want the blob there should be an interface that always returns bytes and doesn't strip *any* null, even the one (if present) at the end. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 05:10:27 2015 From: report at bugs.python.org (Eryk Sun) Date: Thu, 03 Dec 2015 10:10:27 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449137427.89.0.752048836498.issue25778@psf.upfronthosting.co.za> Eryk Sun added the comment: REG_SZ and REG_EXPAND_SZ are documented as null-terminated strings [1], which shouldn't have an embedded null character. As such, the default result in the high-level environment of Python shouldn't have embedded nulls. However, since the buffer is sized, I think setting a REG_SZ or REG_EXPAND_SZ value with embedded nulls should be allowed. (My test function relies on this. :) winreg could add a QueryRawValue[Ex] function that always returns the data as bytes. It just has to pass the type as REG_BINARY to Reg2PY: case REG_BINARY: /* ALSO handle ALL unknown data types here. Even if we can't support it natively, we should handle the bits. */ default: if (retDataSize == 0) { Py_INCREF(Py_None); obData = Py_None; } else obData = PyBytes_FromStringAndSize( (char *)retDataBuf, retDataSize); The problem with REG_SZ also exists in Python 2, but I didn't backport the patch. However, Anshul's error occurs in os.path.abspath, which doesn't mind nulls in Python 2: >>> os.path.abspath(u'a string\x00 with a null') u'Z:\\Temp\\a string' whereas Python 3's implementation calls the built-in function os.path._getfullpathname. This uses the path_converter function defined in Modules/posixmodule.c, which rejects paths that have an embedded null: >>> os.path.abspath('a string\x00 with a null') Traceback (most recent call last): File "", line 1, in File "C:\Program Files\Python 3.5\lib\ntpath.py", line 535, in abspath path = _getfullpathname(path) ValueError: _getfullpathname: embedded null character [1]: https://msdn.microsoft.com/en-us/library/ms724884 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 05:17:35 2015 From: report at bugs.python.org (Florin Papa) Date: Thu, 03 Dec 2015 10:17:35 +0000 Subject: [issue24934] django_v2 benchmark not working in Python 3.6 In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za> Message-ID: <1449137855.76.0.719055430712.issue24934@psf.upfronthosting.co.za> Florin Papa added the comment: I have adapted the existent patch to the new benchmarks codebase. Please see the new patch (django_v3_2.patch) in the files section. The benchmark expects to have django in lib/Django-1.9 folder. The Django-1.9 sources are attached separately because of their size. hg clone https://hg.python.org/benchmarks cd benchmarks/ copy django_v3_2.patch to the current directory and Django-1.9.tar.gz to the lib/ directory hg import --no-commit django_v3_2.patch cd lib/ tar -xvf Django-1.9.tar.gz ---------- Added file: http://bugs.python.org/file41221/django_v3_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 05:17:49 2015 From: report at bugs.python.org (Florin Papa) Date: Thu, 03 Dec 2015 10:17:49 +0000 Subject: [issue24934] django_v2 benchmark not working in Python 3.6 In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za> Message-ID: <1449137869.19.0.469433920518.issue24934@psf.upfronthosting.co.za> Changes by Florin Papa : Added file: http://bugs.python.org/file41222/Django-1.9.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 05:27:46 2015 From: report at bugs.python.org (Florin Papa) Date: Thu, 03 Dec 2015 10:27:46 +0000 Subject: [issue24934] django_v2 benchmark not working in Python 3.6 In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za> Message-ID: <1449138466.17.0.407501071846.issue24934@psf.upfronthosting.co.za> Florin Papa added the comment: I have attached django_v3_3.patch, as the previous one did not include the added file (performance/bm_django_v3.py). ---------- Added file: http://bugs.python.org/file41223/django_v3_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 05:35:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Dec 2015 10:35:06 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1449138906.42.0.648784807131.issue15068@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Using readlines() instead of readline() was added in 4dbbf322a9df for performance. But it looks that now this is not needed. Naive implementation with readline() is about 2 times slower, but with careful optimization we can achieve the same performance (or better). Here are results of benchmarks. Unpatched: $ mkdir testdir $ for i in `seq 10`; do for j in `seq 1000`; do echo "$j"; done >"testdir/file$i"; done $ ./python -m timeit -s "import fileinput, glob; files = glob.glob('testdir/*')" -- "f = fileinput.input(files)" "while f.readline(): pass" 10 loops, best of 3: 56.4 msec per loop $ ./python -m timeit -s "import fileinput, glob; files = glob.glob('testdir/*')" -- "list(fileinput.input(files))"10 loops, best of 3: 68.4 msec per loop Patched: $ ./python -m timeit -s "import fileinput, glob; files = glob.glob('testdir/*')" -- "f = fileinput.input(files)" "while f.readline(): pass" 10 loops, best of 3: 47.4 msec per loop $ ./python -m timeit -s "import fileinput, glob; files = glob.glob('testdir/*')" -- "list(fileinput.input(files))" 10 loops, best of 3: 63.1 msec per loop The patch also fixes original issue. It also fixes yet one issue. Currently lines are buffered and you need to enter many lines first then get first line: >>> import fileinput >>> fi = fileinput.input() >>> line = fi.readline() qwerty asdfgh zxcvbn ^D >>> line 'qwerty\n' With the patch you get the line just as it entered. ---------- assignee: docs at python -> serhiy.storchaka stage: needs patch -> patch review versions: +Python 3.4, Python 3.5, Python 3.6 -Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file41224/fileinput_no_buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 05:45:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Dec 2015 10:45:23 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1449139523.41.0.274054299392.issue15068@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 05:49:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Dec 2015 10:49:25 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1449139765.96.0.403671889591.issue15068@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file41224/fileinput_no_buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 05:49:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Dec 2015 10:49:40 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1449139780.19.0.122863053654.issue15068@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file41225/fileinput_no_buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 06:00:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Dec 2015 11:00:30 +0000 Subject: [issue15068] fileinput requires two EOF when reading stdin In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za> Message-ID: <1449140430.14.0.457457042324.issue15068@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 2.7 Added file: http://bugs.python.org/file41226/fileinput_no_buffer-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 06:40:37 2015 From: report at bugs.python.org (Florin Papa) Date: Thu, 03 Dec 2015 11:40:37 +0000 Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za> Message-ID: <1449142837.27.0.550479189518.issue25300@psf.upfronthosting.co.za> Florin Papa added the comment: Hi Antoine, The Py_INIT_BOUNDS calls were used because MPX generated a very large number of error messages about pointer bounds violations at compile or run time, that made Python unusable. The approach was to analyze the errors and ignore checking if no obvious violation took place, in the hope to find the root cause. The problem is that the errors can come from an actual bug or from a false positive that can be propagated throughout the code. While we could not find evidence of actual bugs, we found 2 examples of the latter, in listobject.c (line 1100, in the binarysort function) and dictobject.c (line 1797 in dict_keys function and line 1892 in dict_items). The problem is caused by this coding pattern that is used in the two instances mentioned above: a pointer to an allocated memory zone is used to access a different allocated memory zone by adding the difference between their start addresses to that pointer. Although this newly formed address is valid, in the context of the pointer used for this operation it is outside its bounds so it?s signaled as a bounds violation. p *----------------* q *-------------------------------* <--------------------------------------> offset p and q point to valid memory zones, being separated by an offset. If we do something like new_pointer = q ? offset; // which is actually equal to p value = *new_pointer; // dereferencing will generate an MPX bounds violation, because // new_pointer will keep q?s original bounds I will rewrite the code for these cases and provide the new patch as soon as I have it. Regards, Florin ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 06:42:22 2015 From: report at bugs.python.org (Florin Papa) Date: Thu, 03 Dec 2015 11:42:22 +0000 Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za> Message-ID: <1449142942.88.0.327093836492.issue25300@psf.upfronthosting.co.za> Florin Papa added the comment: Hi Stefan, > Yes, I dislike that, too. The question is why gcc has supported > the "struct hack" for more than 20 years but needs an annotation > just for MPX. The "struct hack" represents a problem for MPX because it intentionally exceeds the bounds of the array declared inside in order to support a variable sized structure. Without the Py_VARIABLE_SIZE annotation, MPX will generate a bounds violation when accessing outside the declared size of the array. > Is the annotation also needed for the C99 version (ob_array[])? I tested and for the C99 version the annotation is not needed. Apparently ob_array inherits the bounds of the structure in this case. Regards, Florin ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 08:01:22 2015 From: report at bugs.python.org (Eryk Sun) Date: Thu, 03 Dec 2015 13:01:22 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449147682.51.0.715943170318.issue25778@psf.upfronthosting.co.za> Eryk Sun added the comment: > add a QueryRawValue[Ex] function Or QueryValueEx and EnumValue could take a boolean argument named "raw" or "binary", which if True forces the data to be returned as REG_BINARY regardless of its assigned type. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 08:26:37 2015 From: report at bugs.python.org (Ben) Date: Thu, 03 Dec 2015 13:26:37 +0000 Subject: [issue25144] 3.5 Win install fails with "TARGETDIR" In-Reply-To: <1442424932.17.0.0389991499722.issue25144@psf.upfronthosting.co.za> Message-ID: <1449149197.11.0.0489876274275.issue25144@psf.upfronthosting.co.za> Ben added the comment: Still a problem with python-2.7.10.amd64.msi. A bit surprising that this has not been addressed since 2015.05.23... ---------- nosy: +cbj4074 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 11:41:30 2015 From: report at bugs.python.org (Laura Creighton) Date: Thu, 03 Dec 2015 16:41:30 +0000 Subject: [issue25788] fileinput.hook_encoded has no way to pass arguments to codecs Message-ID: <1449160890.79.0.711012524776.issue25788@psf.upfronthosting.co.za> New submission from Laura Creighton: Right now there is no way, aside from writing your own openhook, to get around the limitation that openhook=fileinput.hook_encoded("utf") will open things with the default option for codecs.open() of errors=strict. Adding a way to pass the errors argument seems both easy to do and useful. ---------- components: IO messages: 255818 nosy: lac, serhiy.storchaka priority: normal severity: normal status: open title: fileinput.hook_encoded has no way to pass arguments to codecs versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 11:52:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Dec 2015 16:52:46 +0000 Subject: [issue25788] fileinput.hook_encoded has no way to pass arguments to codecs In-Reply-To: <1449160890.79.0.711012524776.issue25788@psf.upfronthosting.co.za> Message-ID: <1449161566.65.0.375271306755.issue25788@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It would be easy to add the errors parameter to fileinput.hook_encoded(). Do you want to provide a patch Laura? ---------- components: +Library (Lib) keywords: +easy stage: -> needs patch type: -> enhancement versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 11:54:55 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Dec 2015 16:54:55 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449161695.62.0.782692036863.issue25778@psf.upfronthosting.co.za> R. David Murray added the comment: Anshul: you don't need to worry about this technical discussion unless our windows experts decide this is in fact a bug in matplotlib and/or your machine's registry :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 12:16:05 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Thu, 03 Dec 2015 17:16:05 +0000 Subject: [issue23936] Wrong references to deprecated find_module instead of find_spec In-Reply-To: <1428945775.22.0.0538000929194.issue23936@psf.upfronthosting.co.za> Message-ID: <1449162965.38.0.648746883953.issue23936@psf.upfronthosting.co.za> Thomas Kluyver added the comment: I also ran into confusion with this while trying to write an import hook. Attached is my shot at a docs patch. I've done a slightly larger rewording, trying to make it easier to understand, and added more links between parts of the docs. I left mentions of the deprecated find_module and find_loader methods in the 'finder' glossary entry, but for sys.meta_path I have only described find_spec() - it does still fall back to the deprecated methods, but I thought that trying to explain that would make the description of meta_path harder to follow. ---------- nosy: +takluyver Added file: http://bugs.python.org/file41227/finders_and_specs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 12:17:45 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 03 Dec 2015 17:17:45 +0000 Subject: [issue23936] Wrong references to deprecated find_module instead of find_spec In-Reply-To: <1428945775.22.0.0538000929194.issue23936@psf.upfronthosting.co.za> Message-ID: <1449163065.3.0.0206317690004.issue23936@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: docs at python -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 12:17:52 2015 From: report at bugs.python.org (Todd Dembrey) Date: Thu, 03 Dec 2015 17:17:52 +0000 Subject: [issue11822] Improve disassembly to show embedded code objects In-Reply-To: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za> Message-ID: <1449163072.55.0.939955513271.issue11822@psf.upfronthosting.co.za> Changes by Todd Dembrey : ---------- nosy: +Todd Dembrey _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 12:22:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Dec 2015 17:22:39 +0000 Subject: [issue25709] Problem with string concatenation and utf-8 cache. In-Reply-To: <1448290639.34.0.0738045056565.issue25709@psf.upfronthosting.co.za> Message-ID: <1449163359.38.0.0343434265485.issue25709@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: -Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 12:25:52 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Thu, 03 Dec 2015 17:25:52 +0000 Subject: [issue25789] py launcher stderr is not piped to subprocess.Popen.stderr Message-ID: <1449163552.68.0.156481310646.issue25789@psf.upfronthosting.co.za> New submission from Wolfgang Maier: from the console: > py -3.7 or any other not installed Python version gives: Requested Python version (3.7) not installed However, when the launcher is executed from python via subprocess.Popen: >>>import subprocess >>>p=subprocess.Popen(['py', '-3.7'], stdout=subprocess.PIPE, stderr=subprocess.PIPE) >>>p.communicate() (b'', b'') the error message is not accessible. (Error messages from any successfully launched Python interpreter are available through p.stderr though.) ---------- components: Windows messages: 255822 nosy: paul.moore, steve.dower, tim.golden, wolma, zach.ware priority: normal severity: normal status: open title: py launcher stderr is not piped to subprocess.Popen.stderr type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 12:25:58 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Dec 2015 17:25:58 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449163558.35.0.859070219133.issue25778@psf.upfronthosting.co.za> Zachary Ware added the comment: There's also backward compatibility to consider here; someone somewhere is depending on getting back \0 in his REG_SZes. If we were to make a change, it could only go in 3.6. With that restriction, I don't see a particularly nice way to get the same behavior from 3.6+ and 3.5-. Also, I don't like the idea of having a mismatch between what we set and what we get, even if what we're setting technically shouldn't be allowed. I'm more inclined to just document that REG_SZ and REG_EXPAND_SZ values may contain nulls if the key was added improperly. ---------- versions: -Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 12:33:50 2015 From: report at bugs.python.org (Laura Creighton) Date: Thu, 03 Dec 2015 17:33:50 +0000 Subject: [issue25788] fileinput.hook_encoded has no way to pass arguments to codecs In-Reply-To: <1449160890.79.0.711012524776.issue25788@psf.upfronthosting.co.za> Message-ID: <1449164030.6.0.0641268575407.issue25788@psf.upfronthosting.co.za> Laura Creighton added the comment: I haven't made a patch to Python for over 10 years. Before mercurial. :) Where do you start in terms of 'how to submit a patch'? ---------- components: -Library (Lib) type: enhancement -> versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 12:36:04 2015 From: report at bugs.python.org (Anshul Agrawal) Date: Thu, 03 Dec 2015 17:36:04 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449164164.4.0.0699430761868.issue25778@psf.upfronthosting.co.za> Anshul Agrawal added the comment: Thanks David, and yes I had guessed as much. Will continue to monitor these emails for a while, in case action is needed from my side. >From an end user perspective, it was discouraging to encounter a bug like this at such an early stage of using Python3 (and associated packages) as a tool for Data Analysis, especially since it's been around for a few years. Glad to see such a spirited debugging effort. Hoping for a successful outcome. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 12:37:42 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Dec 2015 17:37:42 +0000 Subject: [issue25788] fileinput.hook_encoded has no way to pass arguments to codecs In-Reply-To: <1449160890.79.0.711012524776.issue25788@psf.upfronthosting.co.za> Message-ID: <1449164262.41.0.346372576477.issue25788@psf.upfronthosting.co.za> R. David Murray added the comment: Mercurial didn't change the patch submission process (we're talking about making such changes on python-workflow now...or rather enhancements as the current process should continue to work). The only thing that mercurial changed is how you get a copy of the current repo. After that (which is explained in the devguide), just make your changes, do 'hg diff', and attach the diff file to the issue as usual. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 12:40:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Dec 2015 17:40:24 +0000 Subject: [issue25788] fileinput.hook_encoded has no way to pass arguments to codecs In-Reply-To: <1449160890.79.0.711012524776.issue25788@psf.upfronthosting.co.za> Message-ID: <1449164424.8.0.23579315343.issue25788@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: https://docs.python.org/devguide/#contributing ---------- components: +Library (Lib) type: -> enhancement versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 12:41:55 2015 From: report at bugs.python.org (random832) Date: Thu, 03 Dec 2015 17:41:55 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449164515.07.0.337341223105.issue25778@psf.upfronthosting.co.za> random832 added the comment: Your "backward compatibility" argument makes me think of https://xkcd.com/1172/ 99% of programs written in C or other languages will cut the value off at the first null. One consequence of which is that no-one (except an unfortunate Python program) will _notice_ that one "was added improperly", which makes Python the squeaky wheel for breaking when encountering a value nothing else had any problem with. This behavior is "out-there" enough that I think the claim that someone is relying on it should be justified with a concrete example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 12:52:00 2015 From: report at bugs.python.org (Eryk Sun) Date: Thu, 03 Dec 2015 17:52:00 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449165120.58.0.312405443791.issue25778@psf.upfronthosting.co.za> Eryk Sun added the comment: > I don't like the idea of having a mismatch between what we set and > what we get, even if what we're setting technically shouldn't be > allowed. Currently if you set a string with null, you won't see it using either regedit.exe or reg.exe: >>> import os, winreg >>> data = "a string\x00 with a null" >>> HKCU = winreg.HKEY_CURRENT_USER >>> winreg.SetValueEx(HKCU, "test", 0, winreg.REG_SZ, data) >>> winreg.QueryValueEx(HKCU, "test") ('a string\x00 with a null', 1) >>> os.system('reg query HKCU /v test') HKEY_CURRENT_USER test REG_SZ a string 0 The registry saves the whole buffer, agnostic to the type, but clearly Microsoft has documented and treats REG_SZ as a null-terminated string. We should follow suit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 13:00:35 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Dec 2015 18:00:35 +0000 Subject: [issue25778] winreg.EnumValue does not truncate strings correctly In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za> Message-ID: <1449165635.51.0.897586266226.issue25778@psf.upfronthosting.co.za> Zachary Ware added the comment: Ok, that example is an argument I'll accept. I'll give the patch another couple of days for others to review, and commit if nobody beats me to it. It's too late for 3.5.1, but it can probably make 3.4.4. ---------- stage: patch review -> commit review versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 13:04:17 2015 From: report at bugs.python.org (Karl Richter) Date: Thu, 03 Dec 2015 18:04:17 +0000 Subject: [issue25787] Add an explanation what happens with subprocess parent and child processes when signals are sent In-Reply-To: <1449113379.93.0.748465414277.issue25787@psf.upfronthosting.co.za> Message-ID: <1449165857.8.0.947957421262.issue25787@psf.upfronthosting.co.za> Karl Richter added the comment: Please also explain how to deal with process replacement in child processes (assuming that http://stackoverflow.com/questions/34059576/how-to-register-a-signal-handler-for-a-subprocess/34065587#34065587 is correct). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 13:48:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Dec 2015 18:48:15 +0000 Subject: [issue19543] Add -3 warnings for codec convenience method changes In-Reply-To: <1384075247.27.0.0100141647279.issue19543@psf.upfronthosting.co.za> Message-ID: <20151203184812.29979.68754@psf.io> Roundup Robot added the comment: New changeset c89a0f24d5f6 by Serhiy Storchaka in branch '2.7': Issue #19543: Added Py3k warning for decoding unicode. https://hg.python.org/cpython/rev/c89a0f24d5f6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 13:50:47 2015 From: report at bugs.python.org (Eryk Sun) Date: Thu, 03 Dec 2015 18:50:47 +0000 Subject: [issue25789] py launcher stderr is not piped to subprocess.Popen.stderr In-Reply-To: <1449163552.68.0.156481310646.issue25789@psf.upfronthosting.co.za> Message-ID: <1449168647.28.0.809672352969.issue25789@psf.upfronthosting.co.za> Eryk Sun added the comment: The error() function in PC/launcher.c should call exit(rc) instead of ExitProcess(rc). This allows the CRT to terminate properly and flush the stderr FILE stream. With this change it works as expected: >>> import subprocess >>> p = subprocess.Popen(r'amd64\py_d -3.7', stderr=subprocess.PIPE) >>> p.stderr.read() b'Requested Python version (3.7) not installed\r\n' ---------- keywords: +patch nosy: +eryksun stage: -> patch review Added file: http://bugs.python.org/file41228/issue25789_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 14:18:30 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Dec 2015 19:18:30 +0000 Subject: [issue20954] Bug in subprocess._args_from_interpreter_flags causes MemoryError In-Reply-To: <1395049138.68.0.283816495419.issue20954@psf.upfronthosting.co.za> Message-ID: <1449170310.93.0.0777172278105.issue20954@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 14:21:16 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Dec 2015 19:21:16 +0000 Subject: [issue12923] test_urllib fails in refleak mode In-Reply-To: <1315352458.41.0.979039254957.issue12923@psf.upfronthosting.co.za> Message-ID: <1449170476.93.0.733156264443.issue12923@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 14:36:50 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Dec 2015 19:36:50 +0000 Subject: [issue24903] Do not verify destdir argument to compileall In-Reply-To: <1440090340.94.0.960846948858.issue24903@psf.upfronthosting.co.za> Message-ID: <1449171410.5.0.5392239452.issue24903@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 14:38:58 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Dec 2015 19:38:58 +0000 Subject: [issue22709] restore accepting detached stdin in fileinput binary mode In-Reply-To: <1414048560.8.0.0429092094688.issue22709@psf.upfronthosting.co.za> Message-ID: <1449171538.77.0.887874711638.issue22709@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 15:27:33 2015 From: report at bugs.python.org (YoSTEALTH) Date: Thu, 03 Dec 2015 20:27:33 +0000 Subject: [issue25790] shutil.chown function enhancement Message-ID: <1449174453.32.0.268528261377.issue25790@psf.upfronthosting.co.za> New submission from YoSTEALTH: A very simple but useful enhancement for shutil.chown function Currently "shutil.chown" function effects only one directory or file user/group permission by adding "recursive" parameter it can easily effect all sub-directories/files Source: https://hg.python.org/cpython/file/3.5/Lib/shutil.py#l1007 # Current: def chown(path, user=None, group=None): """Change owner user and group of the given path. user and group can be the uid/gid or the user/group names, and in that case, they are converted to their respective uid/gid. """ if user is None and group is None: raise ValueError("user and/or group must be set") _user = user _group = group # -1 means don't change it if user is None: _user = -1 # user can either be an int (the uid) or a string (the system username) elif isinstance(user, str): _user = _get_uid(user) if _user is None: raise LookupError("no such user: {!r}".format(user)) if group is None: _group = -1 elif not isinstance(group, int): _group = _get_gid(group) if _group is None: raise LookupError("no such group: {!r}".format(group)) os.chown(path, _user, _group) # Enhanced: import os.path # Internal Function def _dir_walk(path): ''' Get All Directories & Files''' for dir_path, dir_names, file_names in os.walk(path): # Directories for dir_name in dir_names: yield os.path.join(dir_path, dir_name) # Files for file_name in file_names: yield os.path.join(dir_path, file_name) def chown(path, user=None, group=None, recursive=False): """Change owner user and group of the given path. user and group can be the uid/gid or the user/group names, and in that case, they are converted to their respective uid/gid. """ if user is None and group is None: raise ValueError("user and/or group must be set") _user = user _group = group # -1 means don't change it if user is None: _user = -1 # user can either be an int (the uid) or a string (the system username) elif isinstance(user, str): _user = _get_uid(user) if _user is None: raise LookupError("no such user: {!r}".format(user)) if group is None: _group = -1 elif not isinstance(group, int): _group = _get_gid(group) if _group is None: raise LookupError("no such group: {!r}".format(group)) # Default Do First if not recursive: os.chown(path, _user, _group) else: for recursive_path in _dir_walk(path): os.chown(recursive_path, _user, _group) hope this helps :) ---------- hgrepos: 324 messages: 255834 nosy: YoSTEALTH priority: normal severity: normal status: open title: shutil.chown function enhancement type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 15:28:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Dec 2015 20:28:15 +0000 Subject: [issue6478] time.tzset does not reset _strptime's locale time cache In-Reply-To: <1247506425.36.0.284798334504.issue6478@psf.upfronthosting.co.za> Message-ID: <20151203202811.93654.94370@psf.io> Roundup Robot added the comment: New changeset 2ae5c51c5dea by Serhiy Storchaka in branch '2.7': Issue #6478: _strptime's regexp cache now is reset after changing timezone https://hg.python.org/cpython/rev/2ae5c51c5dea New changeset 4b0a4da1aa27 by Serhiy Storchaka in branch '3.4': Issue #6478: _strptime's regexp cache now is reset after changing timezone https://hg.python.org/cpython/rev/4b0a4da1aa27 New changeset 5fa855d20624 by Serhiy Storchaka in branch '3.5': Issue #6478: _strptime's regexp cache now is reset after changing timezone https://hg.python.org/cpython/rev/5fa855d20624 New changeset ea576db13827 by Serhiy Storchaka in branch 'default': Issue #6478: _strptime's regexp cache now is reset after changing timezone https://hg.python.org/cpython/rev/ea576db13827 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 15:34:16 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Dec 2015 20:34:16 +0000 Subject: [issue25790] shutil.chown function enhancement In-Reply-To: <1449174453.32.0.268528261377.issue25790@psf.upfronthosting.co.za> Message-ID: <1449174856.44.0.938895524464.issue25790@psf.upfronthosting.co.za> R. David Murray added the comment: Please submit this as a patch, and provide an explanation of the change you are proposing. ---------- nosy: +r.david.murray versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 15:39:09 2015 From: report at bugs.python.org (YoSTEALTH) Date: Thu, 03 Dec 2015 20:39:09 +0000 Subject: [issue25790] shutil.chown function enhancement In-Reply-To: <1449174453.32.0.268528261377.issue25790@psf.upfronthosting.co.za> Message-ID: <1449175149.15.0.915272057423.issue25790@psf.upfronthosting.co.za> YoSTEALTH added the comment: I am new to this, not exactly sure how to go about doing that! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 15:48:12 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 03 Dec 2015 20:48:12 +0000 Subject: [issue25791] Raise an ImportWarning when __spec__.parent/__package__ isn't defined for a relative import Message-ID: <1449175692.43.0.67090220632.issue25791@psf.upfronthosting.co.za> New submission from Brett Cannon: When you do a relative import, __package__ is used to help resolve it, but if it isn't defined we fall back on using __name__ and __path__. We should probably consider raising an ImportWarning if __package__ isn't defined so that some day we can consider cleaning up __import__ and its call signature to be a bit more sane and drop the `globals` argument. It would also help people catch errors where they went overboard deleting attributes off a module. We should probably even extend it to start using __spec__.parent and then falling back to __package__, and only after both are found missing do we raise the ImportWarning about needing to use __name__ and __path__. That way __import__ can simply start taking in the spec of the calling module to do all of its work instead of having to pass all of globals(). ---------- components: Interpreter Core messages: 255838 nosy: brett.cannon, eric.snow, ncoghlan priority: low severity: normal stage: test needed status: open title: Raise an ImportWarning when __spec__.parent/__package__ isn't defined for a relative import type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 15:54:03 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Dec 2015 20:54:03 +0000 Subject: [issue25790] shutil.chown function enhancement In-Reply-To: <1449174453.32.0.268528261377.issue25790@psf.upfronthosting.co.za> Message-ID: <1449176043.38.0.780719492931.issue25790@psf.upfronthosting.co.za> R. David Murray added the comment: Well, the prose description of the enhancement is just words added to this issue :) For the patch, you can use the unix 'diff -u' command or, if you want to get more involved in contributing, read the instructions for checking out the repository in docs.python.org/devguide, check it out, apply your changes, and then do 'hg diff' to produce the patch file. Either way, you attach the patch file to the issue with the 'File: browse' button. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 15:58:16 2015 From: report at bugs.python.org (Sam Obstgarten) Date: Thu, 03 Dec 2015 20:58:16 +0000 Subject: [issue25792] sorted() is not stable given key=len and large inputs Message-ID: <1449176296.73.0.525670564276.issue25792@psf.upfronthosting.co.za> New submission from Sam Obstgarten: Tested under MacOS 10.11.1 Python 2.7.8 When using sorted() with key=len, sorted() is not stable (i.e. it does not return the same sorting depending on the input file). I expected, that sorted() sorts (i) first according the string length and then (ii) alphabetically. I used as input Bitcoin addresses (Base58 encoding). First with 1 million Bitcoin addresses, and then with only 9. The results of the last addresses differ in their respective order. 1) Test with 1 million addresses, and these are the last ones: [...] 1W7ezLRaahQTRfgxwZjkyFASPqMcskeMi 1Jf5QEDgpdPYmj8VwKWcTQonwZqSfMvhA 1MttkWDPEgGRPrEfYD3awWfijWcKw6QJL 1QrH9dJexkL78T12B6LVm4yctFhFJS4S3 1pdbjAiEKVxUc1fudq3HtPzkxQxPxYxuN 1NgahguJexVUmW3FFhS4vQbfRkGHfbSn2 1111111AgxDnb8UWCwZnJGUNrX6cAzaL 11111116Jvg5YivHHTcuapzk5CtSEBVA 1111111111111111111114oLvT2 2) Test with only these 9 addresses: 1W7ezLRaahQTRfgxwZjkyFASPqMcskeMi 1QrH9dJexkL78T12B6LVm4yctFhFJS4S3 1pdbjAiEKVxUc1fudq3HtPzkxQxPxYxuN 1Jf5QEDgpdPYmj8VwKWcTQonwZqSfMvhA 1MttkWDPEgGRPrEfYD3awWfijWcKw6QJL 1NgahguJexVUmW3FFhS4vQbfRkGHfbSn2 1111111AgxDnb8UWCwZnJGUNrX6cAzaL 11111116Jvg5YivHHTcuapzk5CtSEBVA 1111111111111111111114oLvT2 I can provide more details and the full set of Bitcoin addresses if required. ---------- components: Interpreter Core messages: 255840 nosy: Sam Obstgarten priority: normal severity: normal status: open title: sorted() is not stable given key=len and large inputs type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 16:01:49 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Dec 2015 21:01:49 +0000 Subject: [issue25792] sorted() is not stable given key=len and large inputs In-Reply-To: <1449176296.73.0.525670564276.issue25792@psf.upfronthosting.co.za> Message-ID: <1449176509.24.0.738156449486.issue25792@psf.upfronthosting.co.za> R. David Murray added the comment: If you use key=len, then what you get out is the items sorted by length. key determines *exactly* the test used to sort the input. "Stable" in a sort means that in the absence of the sort key differentiating the entries, they remain in the same order as in the input. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 16:12:29 2015 From: report at bugs.python.org (SilentGhost) Date: Thu, 03 Dec 2015 21:12:29 +0000 Subject: [issue25790] shutil.chown function enhancement In-Reply-To: <1449174453.32.0.268528261377.issue25790@psf.upfronthosting.co.za> Message-ID: <1449177149.21.0.370901330638.issue25790@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 16:40:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Dec 2015 21:40:04 +0000 Subject: [issue22067] time_test fails after strptime() In-Reply-To: <1406300706.97.0.297116152609.issue22067@psf.upfronthosting.co.za> Message-ID: <1449178804.41.0.83393373991.issue22067@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If call time.localtime() with time before 1990-03-25T03:00, EET is turned to MSK. I guess this is a time when the Europe/Kiev timezone was introduced. >>> import os, time >>> os.environ['TZ'] = 'Europe/Kiev' >>> time.tzset() >>> time.localtime(638319599) time.struct_time(tm_year=1990, tm_mon=3, tm_mday=25, tm_hour=1, tm_min=59, tm_sec=59, tm_wday=6, tm_yday=84, tm_isdst=0) >>> time.strftime('%Z', time.gmtime()) 'MSK' >>> time.localtime(638319600) time.struct_time(tm_year=1990, tm_mon=3, tm_mday=25, tm_hour=3, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=84, tm_isdst=1) >>> time.strftime('%Z', time.gmtime()) 'EET' C function localtime() implicitly calls tzset() and sets global C variables tzname, timezone, and daylight, but these changes are not exposed as variables in the time module. C and Python ideas about timezone becomes different. This looks as a bug in time.localtime() and other functions that implicitly change timezone variables. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 3 16:40:31 2015 From: report at bugs.python.org (sami drif) Date: Thu, 03 Dec 2015 21:40:31 +0000 Subject: [issue25793] ">""

alert("Xss By \Sami")

---------- components: Build files: s.php messages: 255843 nosy: sami drif priority: normal severity: normal status: open title: ">""